Subject: Re: NetBSD/hpcarm snap code
To: Reinoud Zandijk <firstname.lastname@example.org>
From: Jason R Thorpe <email@example.com>
Date: 02/16/2001 13:10:41
On Fri, Feb 16, 2001 at 09:40:53PM +0100, Reinoud Zandijk wrote:
> As Jason suggested a sys/arch/acorn would be a good idea; they all look
> alike and can share stuff. But technically they aren't all acorns though
> :) is the Imago a really new port or a variant on the Acorn theme?
> That would bring it down to :
> arch/arm <- for common code
> arch/acorn <- for RiscPC, A310/A410,A5000, A7000, RC7500, ....
> arch/hpcarm ? <- iPAQ, eval boards and other hand held devices?
> arch/armisapci <- for ARM boards using only std. PC pheriphals using
> ISA/PCI like CATS, EBSA, DNARD, ....
Nonono. You seem to be completely missing the point.
armisapci is completely nonsensical. You lump CATS/EBSA/DNARD in there.
DNARD is fundamentally incompatible with EBSA. They could not, and should
not, be reasonably in the same "port".
Let's take it from the top...
We support several ARM CPUs and ARM CPU core logic. That stuff should
go into sys/arch/arm/. Stuff that is CPU model specific should go
into a subdirectory of that directory. E.g.:
arch/arm/arm <- contains stuff that works on all ARM CPUs
arch/arm/arm2 <- contains e.g. the ARM2 pmap module
arch/arm/arm6 <- contains e.g. the ARM6 pmap module,
cache routines, TLB routines, etc.
arch/arm/arm7 <- contains all the ARM7-specific goo.
arch/arm/arm8 <- contains all the ARM8-specific goo.
arch/arm/sa110 <- contains e.g. the SA110 cache routines,
TLB routines, etc.
arch/arm/sa11x0 <- contains all the SA11x0-specific goo,
including drivers for the on-chip
arch/arm/ebsa285 <- Support for the '285 core logic, etc.
Note that "EBSA285" is really just an
ARM-specific board architecture, but
doesn't define e.g. firmware.
arch/arm/ofw <- Support for the ARM bindings for
OpenFirmware (i.e. the calling
convention that is defined by the
IEEE OpenFirmare ARM supplement, etc.).
arch/acorn26 <- port to the A310/A410/A5000 (did I get
those right?) Totally different memory
management architecture than the later
Acorn machines, tend to have small memory,
don't want to bog it down with the other
stuff in a GENERIC that supported the 32-bit
arch/acorn32 <- port to the RiscPC and A7000 (looks like
the RiscPC and A7000 could boot the same
kernel? Is that true? If so, why are
there separate kernels for them in the
current arm32 port?)
arch/cats <- port to the CATS and any other EBSA285
that uses the Cyclone firmware.
arch/dnard <- port to the DNARD platform, including the
dev/acorn/iomd <- Driver for the IOMD and IOMD attachments of
dev/acorn/vidc <- Driver for the VIDC and the WSCONS glue for it.
...etc. The way we currently treat all these VERY DIFFERENT platforms
as the same is really wrong-headed.
-- Jason R. Thorpe <firstname.lastname@example.org>