[U-Boot] Porting to Broadcom BCM7038 (Hermes board)
I posted a message before about this, but I didn't really give it the most descriptive subject (I went off to find the chip model and then forgot to add it to the subject, doh!)
Basically I'm trying to port uboot to the Broadcom BCM7038 chip, the current bootloader I have is specific to the board (Hermes), and loads the kernel from flash. I'd rather use uboot to start the SATA HDD and load the Linux kernel from there. I have the source code for the bootloader and all the Linux drivers, as well as documentation on the processor, but I'm not very good at low level code.
As far as I can see I need to create a cpu/bcm7038 directory, add the start.S from the original bootloader, and modify it to work with uboot (this is the part I'm really not sure on!). Then add a board/hermes directory with the rest of the original bootloader init code, and modify that to include the SATA drivers, bring up the SATA interface, then load the kernel. But theory is far from practice, and I'm already having trouble.
Would someone be able to assist me in porting to this cpu/board?
Hi Peter,
I posted a message before about this, but I didn't really give it the most descriptive subject (I went off to find the chip model and then forgot to add it to the subject, doh!)
Basically I'm trying to port uboot to the Broadcom BCM7038 chip, the current bootloader I have is specific to the board (Hermes), and loads the kernel from flash. I'd rather use uboot to start the SATA HDD and load the Linux kernel from there. I have the source code for the bootloader and all the Linux drivers, as well as documentation on the processor, but I'm not very good at low level code.
You will be, once you have finished this port :)
As far as I can see I need to create a cpu/bcm7038 directory, add the start.S from the original bootloader, and modify it to work with uboot (this is the part I'm really not sure on!).
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 ;)
So very likely you should start out by creating cpu/mips64. In here should go everything which is general enough to also be of use for the next mips64 ports that come along.
Then add a board/hermes directory with the rest of the original bootloader init code, and modify that to include the SATA drivers, bring up the SATA interface, then load the kernel. But theory is far from practice, and I'm already having trouble.
SATA drivers will go below drivers/block, but yes, this is the theory.
Would someone be able to assist me in porting to this cpu/board?
I'm not sure whether you fill find a single person, but I'm sure that the mailing list as such will at least try to point you in the right direction.
As always, post your ideas early and often not to invest too much time in a non-promising route.
It might also be worthwhile to give the MIPS U-Boot maintainer a ping whether he knows of anything with regard to your CPU or maybe even plans something in his tree[1].
Cheers Detlev
[1] http://www.denx.de/wiki/U-Boot/Custodians
Dear Detlev Zundel,
In message m2prardbo5.fsf@ohwell.denx.de you wrote:
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.
So very likely you should start out by creating cpu/mips64. In here should go everything which is general enough to also be of use for the next mips64 ports that come along.
I think this is not compulsory.
Would someone be able to assist me in porting to this cpu/board?
I'm not sure whether you fill find a single person, but I'm sure that the mailing list as such will at least try to point you in the right direction.
And of course there is a number of companies who are specialized in performing such ports, um...
Best regards,
Wolfgang Denk
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.
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
All the tasks you mention here are performed by U-Boot. U-Boot _is_ the boot loader.
Right, I'm just having trouble getting to grips with the code flow, the start.S in the CPU is the initial entry point, at what point does that hand over to U-Boot? Any chance you could give me a brief overview of the code flow? In particular where the code I need to write fits in with the boot process, i.e. where I need to interface with U-Boot.
Once I've got a better idea of how U-Boot boots, I should be able to get started at least.
Hi Peter,
All the tasks you mention here are performed by U-Boot. U-Boot _is_ the boot loader.Right, I'm just having trouble getting to grips with the code flow, the start.S in the CPU is the initial entry point, at what point does that hand over to U-Boot? Any chance you could give me a brief overview of the code flow? In particular where the code I need to write fits in with the boot process, i.e. where I need to interface with U-Boot.
Once I've got a better idea of how U-Boot boots, I should be able to get started at least.
Be sure to read the section "Implementation Internals" in the README. Other than that, simply trace the flow (on a piece of paper) for a comparable board, e.g. the "purple" board which seems to be pretty close to what you have.
Another hint is that functions in U-Boot ending with _f are run from flash, wherease functions ending in _r run already relocated from RAM.
I hope this gets you started.
Cheers Detlev
Hi Wolfgang,
Dear Detlev Zundel,
In message m2prardbo5.fsf@ohwell.denx.de you wrote:
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.
Yep, I've seen this. But as this board defines "CONFIG_MIPS32" in its config, I wasn't so sure about the real situation.
Cheers Detlev
participants (3)
-
Detlev Zundel -
Peter Belm -
Wolfgang Denk