On Thu, 21 Dec 2000, Reinoud Zandijk wrote:
> On Thu, 21 Dec 2000, Ben Harris wrote:
> > Incidentally, I think if we went for sys/cpu/*, it should all be bundled
> > away under sys/cpu/arm, so as to save clutter in sys/cpu.
>
> I agree ... then the ARM/Intel XScale can me under sys/cpu/arm/xscale or
> so... or sys/cpu/xscale ... i dunno

I agree we should put it into sys/cpu/arm, but not split it up more than 
needed, if we start to split out specific cpu cases we'll end up with:
sys/cpu/arm/arm2
sys/cpu/arm/arm250
sys/cpu/arm/arm3
sys/cpu/arm/arm600
sys/cpu/arm/arm610
sys/cpu/arm/arm700
sys/cpu/arm/arm710
sys/cpu/arm/arm7500
sys/cpu/arm/arm7500FE
sys/cpu/arm/arm800
sys/cpu/arm/arm810
sys/cpu/arm/arm900
sys/cpu/arm/arm910
sys/cpu/arm/sa110
sys/cpu/arm/thumb
sys/cpu/arm/xscale
sys/cpu/arm/fpa10
sys/cpu/arm/fpa11

(And I'm sure there are other arm cpu's I've missed, and some I've got wrong 
above)

Most of these are dealt with either in the arm26 or arm32 code, with some 
#ifdef's.  I believe that for the core of the cpu specific stuff a function 
ptr table is used.  xscale should be able to run the existing SA code.  It's 
more getting the bootloader and hardware support into the code, when the 
hardware actually becomes available.

Chris