Dear Peter Belm,
In message 574bb010908200229m7da12930s39f7bc40a2384f1d@mail.gmail.com you wrote:
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
Well, _all_ hardware differences affect U-Boot. You will need a really detailed understanding of the processor and your board.
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
Right. That's what we do in case of the "purple" board, too.
does the fact it's a 64bit processor mean there's other changes which need to be taken into account in UBoot?
This obviously depends on your hardware design. We cannot answer this question.
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.
Assuming you use standard flash chips, no code to access the flash should co to the board directory. You should use the existing standard drivers instead.
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
U-Boot _is_ the boot loader.
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?
All the tasks you mention here are performed by U-Boot. U-Boot _is_ the boot loader.
Best regards,
Wolfgang Denk