Adrian Portelli | 6 Nov 20:38 2006
Picon

Improving net45xx performance

Hi,

I haven't tested any of the patches from the site but this URL just got
posted to the soekris-tech <at>  mailing list.

http://homepage.mac.com/quension/soekris/bsd/

By the looks of it he's been able to increase throughput by a noticeable
amount by hacking a NetBSD-4.0_BETA install on a net4501.

adrian.

David Young | 14 Nov 18:52 2006
Picon

Re: Improving net45xx performance

On Mon, Nov 06, 2006 at 07:38:50PM +0000, Adrian Portelli wrote:
> Hi,
> 
> I haven't tested any of the patches from the site but this URL just got
> posted to the soekris-tech <at>  mailing list.
> 
> http://homepage.mac.com/quension/soekris/bsd/
> 
> By the looks of it he's been able to increase throughput by a noticeable
> amount by hacking a NetBSD-4.0_BETA install on a net4501.

Cool!

Can somebody comment on the author's concern, "I'm not entirely
comfortable configuring the PCI bridge where I do in the code, as I'm not
sure the PCI bus is guaranteed to be idle at that point. ... A PXE booted
kernel trying such things may be a disaster."  On our outdoor wireless
testbed in Urbana, one of our last-ditch strategies for repairing a node
with a bad load of software, just short of sending somebody out with a
ladder :-( , is to boot known-good software with PXE.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933

Richard Kästner | 27 Nov 13:59 2006
Picon

Crosscompiling - Olimex EP9301

Pretty fresh into ARM and NetBSD (but experience with FreeBSD, Linux), I have 
some questions.
Hope to find some answers for my (hopefully not too stupid) questions:

I got the Olimex EP9301 board, booted into both Linux and NetBSD ( works out 
of the box like a charm!)
The provided NetBSD Kernel uses USB-Disk.

From the mail archives I can see, there is only a basic configuration (similar 
to TS7200 and to a certain extent to ARAMDILLO9).

From my understanding of chip and configuration files, there should not be too 
much to do to add support for GPIO and ADC (still need to study manuals!)

1.  how do I get the 'files.XY' into a configuration? 
    (Which - I think - get the GPIO-Drivers in)

    files.aramdillo9, files.tsarm:
        include "arch/arm/ep93xx/files.ep93xx"
    which should allow accessing GPIO drivers - but no devices in EP9301

2.  will it be enough to include files for GPIO in a configuration?
  ( I would copy TS7200, remove all 'pld' references and call it OLI9301)

3.  when I cross compile (running NetBSD Current)
  epia1(root) ~> uname -a
  NetBSD epia1 4.99.4 NetBSD 4.99.4 (RFK) #0: Sat Nov 25 20:27:08 CET 2006   
  root <at> epia1:/usr/obj/sys/arch/i386/compile/RFK i386

  I have problem doing :
(Continue reading)

Hubert Feyrer | 27 Nov 23:24 2006
Picon

Re: Crosscompiling - Olimex EP9301

On Mon, 27 Nov 2006, Richard Kästner wrote:
> 1.  how do I get the 'files.XY' into a configuration?
>    (Which - I think - get the GPIO-Drivers in)
>
>    files.aramdillo9, files.tsarm:
>        include "arch/arm/ep93xx/files.ep93xx"
>    which should allow accessing GPIO drivers - but no devices in EP9301
>
> 2.  will it be enough to include files for GPIO in a configuration?
>  ( I would copy TS7200, remove all 'pld' references and call it OLI9301)

I'm not sure what you mean here - in general, the question seems like 
someone on tech-kern <at>  could help you further.

The general idea is that the files.* files tell what devices exist and can 
be used by a certain architecture, and that the kernel config file then 
tells which device drivers really to build into the kernel. For each 
architecture, there's a std.<whatever> file in the 'conf' directory that 
pulls in in those files.* files that the architecture supports - see all 
the various std.* files in src/sys/arch/evbarm/conf as some examples.

Often, this is a bit of a maze to fine through, e.g. for gpio on 
armadillo9, the way is: std.armadillo9 -> files.armadillo9 -> files.ep93xx

I'm not sure about the details behind this...

> 3.  when I cross compile (running NetBSD Current)
>  epia1(root) ~> uname -a
>  NetBSD epia1 4.99.4 NetBSD 4.99.4 (RFK) #0: Sat Nov 25 20:27:08 CET 2006
>  root <at> epia1:/usr/obj/sys/arch/i386/compile/RFK i386
(Continue reading)

Jim Higgins | 28 Nov 17:56 2006

evbppc - IBM405EP - Intrinsyc Cerfcube

I am looking for some help/guidance to solve a problem porting NetBSD 
3.0 to the IBM405EP Intrinsyc Cerfcube.

The kernel boots and completes auto configuration, but init hangs 
(kernel continues to respond to pings).  If I break init and restart it 
then it reports signal 11.  When a simple statically linked test program 
is used in place of init, it runs correctly (system calls work, heap and 
stack allocations work).  If the same test program is dynamically linked 
it fails in various ways.  The NFS traffic shows it reading ld.elf_so 
and libc, but somewhere it breaks.  It does not trap on the same address 
everytime.  I have tried using a memory file system instead of NFS, but 
the same problem occurred.

Any insights? Anyone using NetBSD 3.x with a 405EP?

Thanks in advance,
Jim

PPCBoot 2.0.0 (Dec  5 2003 - 14:57:54)

CPU:   IBM PowerPC 405EP? (PVR=51210950) at 266.333 MHz (PLB=133, 
OPB=66, EBC=44 MHz)
            16 kB I-Cache 16 kB D-Cache
**************************************************
** PowerPC Boot 2.0.0 - 1.0                     **
** Copyright 2002,2003 Intrinsyc Software Inc.  **
** Version: 1.0-RELEASE                         **
** Support: http://support.intrinsyc.com        **
**************************************************
AMD NOR and NAND flash supported
(Continue reading)

Jachym Holecek | 28 Nov 19:51 2006

Re: evbppc - IBM405EP - Intrinsyc Cerfcube

Hello,

# Jim Higgins 2006-11-28:
> PPCBoot 2.0.0 (Dec  5 2003 - 14:57:54)
> 
> CPU:   IBM PowerPC 405EP? (PVR=51210950) at 266.333 MHz (PLB=133, 
> OPB=66, EBC=44 MHz)
>            16 kB I-Cache 16 kB D-Cache

The bootloader gets the cache right ...

> cpu0 at plb0: 266MHz Version 0x5121 (Revision 9.80)
> Instruction cache size 0 line size 4
> Data cache size 0 line size 4

... while the kernel is not. A case statement for the 405EP in

  sys/arch/powerpc/ibm4xx/cpu.c:cpu_probe_cache()

should solve the problem. The system really can't live without knowing
cache size & cacheline size, the code in -current will even panic() if
it can't fill meaningful cache params.

Hope this helps,
	-- Jachym

BTW: port-powerpc <at>  might be a better list to discuss this.


Gmane