Porting Barebox to i.MX6QDL "Novena"
Hi,
After talking with people at 30C3, I've decided to try moving from U-Boot to Barebox. I've got things building to the point where I have a single ">" character being printed (after reading an earlier SOM porting message), but I'm starting to grasp at straws now when it comes to bringing DDR up.
Novena has an SO-DIMM slot. In U-Boot, we wrote a hook for setup_ddr() that got the SO-DIMM's SPD via I2C, performed calibration, and returned with DDR all configured.
In Barebox, I'm running into some trouble:
1) How do I access I2C routines from lowlevel.c? I need to be able
to query the EEPROM on the DDR module itself to get its timing parameters.
2) How much character printing can I get in lowlevel.c? I noticeputc_ll() works, but puts_ll() doesn't, presumably because I have the text offset incorrectly set.
3) How much functionality can I have in ~96 KiB? I believe that's
roughly the amount of space allowed in the OCRAM on an i.MX6DL once you allow for code in ROM that's actually doing the loading.
4) Failing that, is it possible to load some preboot code to set up
DDR? I realize the traditional method is a hardcoded pokefile, but since we support DDR3 modules, we can't rely on that.
Sean
_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Quoted 6 lines · Sean Cross
Hi,
After talking with people at 30C3, I've decided to try moving from U-Boot to Barebox. I've got things building to the point where I have a single ">" character being printed (after reading an earlier SOM porting message),
So the hardest part is already done ;)
Quoted 11 lines
but I'm starting to grasp at straws now when it comes to bringing DDR up.
Novena has an SO-DIMM slot. In U-Boot, we wrote a hook for
setup_ddr()that got the SO-DIMM's SPD via I2C, performed calibration, and returned with DDR all configured.In Barebox, I'm running into some trouble:
1) How do I access I2C routines from
lowlevel.c? I need to be able
to query the EEPROM on the DDR module itself to get its timing parameters.
There is no way to access the regular i2c functions that early. You are lucky that the mpc85xx has the same i2c controller and the same problem. See arch/ppc/mach-mpc85xx/fsl_i2c.c, it contains the lowlevel functions to access the i2c bus. We probably have some SPD EEPROM parsing code from U-Boot aswell.
Quoted 4 lines
2) How much character printing can I get in
lowlevel.c? I noticeputc_ll()works, butputs_ll()doesn't, presumably because I have the text offset incorrectly set.
Yes right. only putc_ll and puthex_ll can be used.
Quoted 8 lines
3) How much functionality can I have in ~96 KiB? I believe that's
roughly the amount of space allowed in the OCRAM on an i.MX6DL once you allow for code in ROM that's actually doing the loading.4) Failing that, is it possible to load some preboot code to set up
DDR? I realize the traditional method is a hardcoded pokefile, but since we support DDR3 modules, we can't rely on that.
You have several options here. First option is to compile a small first stage barebox which runs from OCRAM. This first stage loader would need i2c support and support for loading the 2nd stage barebox from whatever medium you boot from. 96KiB should be enough to accomplish this. The good about this way is that it's relatively straight forward. Also you could directly start a kernel instead of the 2nd stage barebox which makes your boot process really fast. The downside is that you have two barebox binaries and configs to handle. Also the available binary space in the 1st stage loader probably won't be enough to contain code for bootstrapping from say MMC and NAND and SPI, so you need additional binaries for each boot source.
Another option is to do what the phyCORE am335x does, see arch/arm/boards/pcm051/lowlevel.c. The ROM code loads the binary to internal SRAM. Then this board calls relocate_to_current_adr() and setup_c() right after startup. At this point you have a regular C environment and have everything in place to use fsl_i2c.c and gather information about your SDRAM. When done call barebox_arm_entry() with the amount of SDRAM you found. This will then uncompress the regular barebox to SDRAM and continue from there.
I recommend using the second approch, although it's probably harder to understand what is going on there. Feel free to ask when you encounter problems.
Sascha
Signature · 9 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox
Quoted 10 lines · Sascha Hauer
Quoted 9 lines · Sean Cross
but I'm starting to grasp at straws now when it comes to bringing DDR up.
Novena has an SO-DIMM slot. In U-Boot, we wrote a hook for
setup_ddr()that got the SO-DIMM's SPD via I2C, performed calibration, and returned with DDR all configured.In Barebox, I'm running into some trouble:
Quoted 7 lines
Quoted 2 lines
1) How do I access I2C routines from
lowlevel.c? I need to be able
to query the EEPROM on the DDR module itself to get its timing parameters.There is no way to access the regular i2c functions that early. You are lucky that the mpc85xx has the same i2c controller and the same problem. See
arch/ppc/mach-mpc85xx/fsl_i2c.c, it contains the lowlevel functions to access the i2c bus. We probably have some SPD EEPROM parsing code from U-Boot aswell.
Looks like there's some DDR2 code left over, but not much related to DDR3. Can't win 'em all, but that's a lucky break on the FSL I2C stuff.
Quoted 4 lines
Quoted 3 lines
2) How much character printing can I get in
lowlevel.c? I noticeputc_ll()works, butputs_ll()doesn't, presumably because I have the text offset incorrectly set.Yes right. only
putc_llandputhex_llcan be used.
Noted. putc_ll() it is. No printf for me, in bringing up DDR3.
Quoted 27 lines
Quoted 7 lines
3) How much functionality can I have in ~96 KiB? I believe that's
roughly the amount of space allowed in the OCRAM on an i.MX6DL once you allow for code in ROM that's actually doing the loading.4) Failing that, is it possible to load some preboot code to set up
DDR? I realize the traditional method is a hardcoded pokefile, but since we support DDR3 modules, we can't rely on that.You have several options here. First option is to compile a small first stage barebox which runs from OCRAM. This first stage loader would need i2c support and support for loading the 2nd stage barebox from whatever medium you boot from. 96KiB should be enough to accomplish this. The good about this way is that it's relatively straight forward. Also you could directly start a kernel instead of the 2nd stage barebox which makes your boot process really fast. The downside is that you have two barebox binaries and configs to handle. Also the available binary space in the 1st stage loader probably won't be enough to contain code for bootstrapping from say MMC and NAND and SPI, so you need additional binaries for each boot source.
Another option is to do what the phyCORE am335x does, seearch/arm/boards/pcm051/lowlevel.c. The ROM code loads the binary to internal SRAM. Then this board callsrelocate_to_current_adr()andsetup_c()right after startup. At this point you have a regular C environment and have everything in place to usefsl_i2c.cand gather information about your SDRAM. When done callbarebox_arm_entry()with the amount of SDRAM you found. This will then uncompress the regular barebox to SDRAM and continue from there.
Quoted 4 lines
I recommend using the second approch, although it's probably harder to understand what is going on there. Feel free to ask when you encounter problems.
Let me make sure I understand the mechanics of the two options.
For the first option -- a first-stage and a second-stage -- lowlevel.c would call barebox_arm_entry(), and the boot script would configure DDR, load a larger barebox off of MMC, and jump to it. The TEXT_ADDR of the first stage would point to somewhere like 0x00908000 (near the top of SRAM).
For the second option -- what the phyCORE am335x does -- it would run lowlevel.c with the stack in SRAM, which would set up DDR, then barebox_arm_entry would put the stack somewhere in SDRAM.
The second does sound more attractive, as it would allow us to continue using USB boot for factory tests. However, I'm having trouble getting barebox to be small enough. I've disabled most commands, most drivers, networking, USB, MMC, autocompletion, enabled Thumb2, and am using the simplified shell, and the size of images/barebox-kosagi-novena-6dl.img is still 87k. If this is the size of the stripped-down version, where would the regular barebox fit?
If I do go with the two-stage approach, is barebox.bin a binary that can simply be loaded into RAM and jumped to, assuming PIC is enabled? I suppose I could reuse the DTB file in memory by passing it to the second-stage bootloader at this point...
Sean
_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Quoted 11 lines · Sean Cross
Quoted 4 lines · Sascha Hauer
I recommend using the second approch, although it's probably harder to understand what is going on there. Feel free to ask when you encounter problems.
Let me make sure I understand the mechanics of the two options.
For the first option -- a first-stage and a second-stage --
lowlevel.cwould callbarebox_arm_entry(), and the boot script would configure DDR, load a larger barebox off of MMC, and jump to it. TheTEXT_ADDRof the first stage would point to somewhere like0x00908000(near the top of SRAM).
Yes. Only TEXT_BASE should point to the bottom of SRAM since it's the start address of the binary.
Quoted 4 lines
For the second option -- what the phyCORE am335x does -- it would run
lowlevel.cwith the stack in SRAM, which would set up DDR, thenbarebox_arm_entrywould put the stack somewhere in SDRAM.
Yes.
Quoted 8 lines
The second does sound more attractive, as it would allow us to continue using USB boot for factory tests. However, I'm having trouble getting barebox to be small enough. I've disabled most commands, most drivers, networking, USB, MMC, autocompletion, enabled Thumb2, and am using the simplified shell, and the size of images/barebox-kosagi-novena-6dl.img is still 87k. If this is the size of the stripped-down version, where would the regular barebox fit?
Sorry I was confused. Somehow I assumed that once your 1st stage loader can setup the SDRAM from lowlevel code it can be bigger than internal SRAM. That's nonsense of course.
Once you need code to setup SDRAM you are doomed to use the two staged approach (or a very limited single stage).
However, image compression can help you in this case to stretch the limits of the first stage a bit, see the attached config. With this you could:
- Let the ROM load the binary to SRAM
- configure SDRAM from lowlevel code
- uncompress to SDRAM
- execute from SDRAM
Quoted 5 lines
If I do go with the two-stage approach, is barebox.bin a binary that can simply be loaded into RAM and jumped to, assuming PIC is enabled? I suppose I could reuse the DTB file in memory by passing it to the second-stage bootloader at this point...
Yes. If you only want to test barebox without doing all the lowlevel stuff you can also jump to it from U-Boot. Just copy barebox.bin somewhere to SDRAM and jump to it using U-Boots 'go' command.
Sascha
Signature · 9 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox