Subject: Re: ARM port organisation (was: Re: NetBSD/hpcarm snap code)
To: Ben Harris <firstname.lastname@example.org>
From: Richard Earnshaw <email@example.com>
Date: 02/17/2001 13:47:49
> On Fri, 16 Feb 2001, Jason R Thorpe wrote:
> Having said that I think your proposed directory layout is sane in
> general, here are the few things I'm not sure about:
> > 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.
> I'm not sure that the differences among ARM6, ARM7, ARM8, ARM9, ARM10, SA1
> and Xscale really warrant a separate directory for each one. ARMs seem to
> have fairly orthogonal sets of features, and arbitrarily filing code under
> the name of the first CPU to contain the relevant feature seems wrong to
ARM 6 & 7 are identical from the programmers perspective. ARM8 I would
ignore, I personally doubt we will ever see a serious use of that with
NetBSD. SA1 is sufficiently different from ARM6 to warrant potentially
separate support (mainly that the CPU uses write-back caching instead of
write-through). This impacts the way the pmap is structured, and could
justify a different implementation for machines where it is know to be
only SA (or later) vs earlier chips. Chips like ARM9/10 SA11x0 have a FCS
(fast context switch) extension in the MMU. If you are prepared to
restrict (all?) processes to 32M of VM, then you can avoid cache flushes
on a context switch; this also warrants a separate configuration.
Maybe a more sensible arrangement would be by CPU architecture. Eg armv3
(for arm6, 7), armv4 (SA1, ARM8), armv4fcs (sa11x0 etc), armv5 (arm9E,