Not quite. A quick check reveals that the bcm7038 is a r5000 based mips64 bit at heart (I'm a little confused here, there seem to be also 32bit r5000?). So not only will you be doing a new cpu port (level 2), but really a new architecture , i.e. mips64 - so you enter the game at level 3 ;)
That's not quite correct. IIRC, the "purple" board also uses a 64bit MIPS processor (5Kc). So it's "just" anothe rnew board port.
The core in the BCM7038 is a 5Kf, I'm not sure how the minor revision effects something like UBoot, would any registers be different? As for it being 64bit, the current bootloader is being compiled with a 32bit version of mipsel-uclibc-gcc, so it runs 32bit code fine. Would this be easier, or does the fact it's a 64bit processor mean there's other changes which need to be taken into account in UBoot?
And of course there is a number of companies who are specialized in
performing such ports, um...
I'd prefer to perform this port myself (if possible!) it's no fun being a hobbiest when you get someone else to do all your work.
SATA drivers will go below drivers/block, but yes, this is the theory.
Ok I think I get it now, in the cpu directory goes the code specific for bringing up the cpu, using the cache, etc. So the board directory would contain code for accessing the flash, init'ing memory, etc. And drivers would go into drivers/ as you said.
There's one fundamental thing I still need to get sorted in my head, what exactly is the role of UBoot? Is it just there to assist in creating a bootloader? So the cpu code would do the main bringup, board specific code would init the memory then use drivers provided by UBoot to access what it needs to load the kernel, then calls code in UBoot to start it? Or does UBoot perform a more invasive role than that?
Thank you for your help so far.