Sorry for the delay in replying.

Chris Demetriou wrote:
> I wrote:
>> I would expect 'fb' to live in 'arch/arm32/dev/fb.c' since it should
>> be used by both SA11x0 and Cirrus Logic ports.

>uh, what's 'fb'?

I was going to start with the one from 'arch/hpcmipc/dev'.

>In general, you should have a device-specific driver, which then
>attaches the MI wscons frame buffer code, if you have a frame buffer.

Ok.

>> It would be nice to move the 'es' driver to arch/arm32/dev as well
>> since it is neeeded for the Neponset board.

>actually, if you're talking about the one named in if_es.c in the
>rc7500 dir, i note that it says:

> * Modified from Amiga's es driver for SMC 91C9x ethernet controller.
> * SMC 91C90 Single-Chip Ethernet Controller

>which says to me that it should probably be in dev/ic, as a generic
>driver with appropriate MD hooks, rather than anyplace else.

I took a look in dev/ic, the smc91cx6 driver there should cover this
chip.  It is missing support for a couple of the later members of this
family, but I can add them in.

I'll look at using this driver instead of the arm32 specific one.

>The arm32 port should be driven in one of two ways.  It should:
>
>	* be able to have a single GENERIC kernel that can boot on
>	  all of the machines that are supported by it (e.g. like
>	  alpha), or
>
>	* be split into multiple MACHINEs, leaving MACHINE_ARCH as
>	  arm32 and having common arm32 code shared, but otherwise
>	  be separate per type/family of machine that is supported.

>The hpcmips port does things the former way (as far as I know), which
>kind of makes sense: the booter, etc., will be common for all of those
>kernels, so it's _possible_ to have a single set of software that does
>the right thing.

>I'd say that the ARM should do the latter, like mips, m68k, powerpc,
>and sh3 have done.

I would prefer to just have one build of userland if possible.

I have a CATS as well as the Assabet board so I can just nfs mount
/ and /usr.

[device tree snipped]

>question for you: right now, IIRC, all of the existing ARM code
>expects things to be running w/ virtual memory turned on when you
>start.  Does your new code continue that?

The code in arm32/footbridge looks as if it expects vm turned off.
I was using this as my starting point since I can see what it does on
the CATS system. The Intel diagman code that I have been playing with
assumes vm is off too.

It would be nice to have a loader to run on top of CE as well, but
vm will be running then.

Robert Swindells