Re: [U-Boot] da850evm: u-boot does not start without UBL since commit f1d2b313c9eb6808d30c16a9eb5251240452a56c
Hello Christian,
On Wed, Jun 1, 2011 at 12:58 PM, Christian Riesch christian.riesch@omicron.at wrote:
I have tried to run recent versions of u-boot on the da850evm (AM1808 eXperimenter's Kit) board. Using Texas Instrument's User Boot Loader (UBL) to start u-boot (the default configuration for the EVM) everything works fine. However, if I try to get rid of this UBL (I don't need to voltage scaling features that it provides, so it's useless for me, just additional code that needs maintenance), I run into trouble.
Instead of using UBL, I use AIS [1] to configure PLLs and mDDR timings. My AIS script is generated by the HexAIS tool [2], the settings in the input file of HexAIS are
[General] busWidth=8 BootMode=SPIMASTER crcCheckType=NO_CRC [PLLANDCLOCKCONFIG] PLL0CFG0 = 0x00180001 PLL0CFG1 = 0x00000205 PERIPHCLKCFG = 0x0000000a [EMIF3DDR] PLL1CFG0 = 0x15010001 PLL1CFG1 = 0x00000002 DDRPHYC1R = 0x000000C4 SDCR = 0x0A034622 SDTIMR = 0x184929C8 SDTIMR2 = 0xB80FC700 SDRCR = 0x00000406 CLK2XSRC = 0x00000000 [INPUTFILE] FILENAME=u-boot.bin LOADADDRESS=0xC1080000 ENTRYPOINTADDRESS=0xC1080000
While this configuration works fine for older versions of u-boot (like v2009.11), it fails with recent u-boot versions (no sign of life on the serial port). I have bisected down to the commits from
commit f1d2b313c9eb6808d30c16a9eb5251240452a56c ARM: add relocation support
to
commit ab86f72c354f9b2572340f72b74ca0a258c451bd ARM: implement relocation for ARM926
Since these commits u-boot does not boot without the help of UBL. So I guess these commits require some additional initialization that is done by UBL, but not by my AIS.
I have tried to figure out what I am missing, but without success so far.
Any ideas what I could try to get it running?
Last I heard about this [1] the AIS signer was unable to handle the dynamic elf format resulting from the introduction of arm relocation.
If that particular problem is no more, then I imagine that UBL would have been doing pinmux for serial port among other things. If you are able to debug with JTAG then you might be able to inspect where the execution goes wrong; otherwise maybe removing as much peripheral access from u-boot as is possible and adding it back incrementally could reveal what UBL setup is missing.
Best Regards, Ben Gardiner
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/95097
--- Nanometrics Inc. http://www.nanometrics.ca
Hello Ben, Thank you very much for your response.
On Wednesday, June 1, 2011, Ben Gardiner bengardiner@nanometrics.ca
On Wed, Jun 1, 2011 at 12:58 PM, Christian Riesch christian.riesch@omicron.at wrote:
I have tried to run recent versions of u-boot on the da850evm (AM1808 eXperimenter's Kit) board. Using Texas Instrument's User Boot Loader (UBL) to start u-boot (the default configuration for the EVM) everything works fine. However, if I try to get rid of this UBL (I don't need to voltage scaling features that it provides, so it's useless for me, just additional code that needs maintenance), I run into trouble.
Instead of using UBL, I use AIS [1] to configure PLLs and mDDR timings. My AIS script is generated by the HexAIS tool [2], the settings in the input file of HexAIS are
[General] busWidth=8 BootMode=SPIMASTER crcCheckType=NO_CRC [PLLANDCLOCKCONFIG] PLL0CFG0 = 0x00180001 PLL0CFG1 = 0x00000205 PERIPHCLKCFG = 0x0000000a [EMIF3DDR] PLL1CFG0 = 0x15010001 PLL1CFG1 = 0x00000002 DDRPHYC1R = 0x000000C4 SDCR = 0x0A034622 SDTIMR = 0x184929C8 SDTIMR2 = 0xB80FC700 SDRCR = 0x00000406 CLK2XSRC = 0x00000000 [INPUTFILE] FILENAME=u-boot.bin LOADADDRESS=0xC1080000 ENTRYPOINTADDRESS=0xC1080000
While this configuration works fine for older versions of u-boot (like v2009.11), it fails with recent u-boot versions (no sign of life on the serial port). I have bisected down to the commits from
commit f1d2b313c9eb6808d30c16a9eb5251240452a56c ARM: add relocation support
to
commit ab86f72c354f9b2572340f72b74ca0a258c451bd ARM: implement relocation for ARM926
Since these commits u-boot does not boot without the help of UBL. So I guess these commits require some additional initialization that is done by UBL, but not by my AIS.
I have tried to figure out what I am missing, but without success so far.
Any ideas what I could try to get it running?
Last I heard about this [1] the AIS signer was unable to handle the dynamic elf format resulting from the introduction of arm relocation.
I am not completely sure about this, but I had a look at some memory dumps today with u-boot's md command: I got the impression that these tools (aisgen as well as hexais) just copy the content of u-boot.bin into the image that is programmed to flash. Eventually they add some additional information but the u-boot.bin seems to be unmodified. Anyway, hexais did not complain about the u-boot format.
If that particular problem is no more, then I imagine that UBL would have been doing pinmux for serial port among other things.
Indeed UBL does a lot of pinmuxing, but the board init routines of u-boot seem to do the same. I tried to add pinmux settings to the AIS for the serial port (UART2), but it did not change things.
Anyway, with older u-boot version everything worked fine, even access to SPI memory and Ethernet from u-boot, no additional pinmuxing in the AIS was required.
Best regards, Christian
If you are able to debug with JTAG then you might be able to inspect where the execution goes wrong; otherwise maybe removing as much peripheral access from u-boot as is possible and adding it back incrementally could reveal what UBL setup is Best Regards, Ben Gardiner
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/95097
Hi Christian,
On Wed, Jun 1, 2011 at 4:26 PM, Christian Riesch christian.riesch@omicron.at wrote:
On Wednesday, June 1, 2011, Ben Gardiner bengardiner@nanometrics.ca
[...] Last I heard about this [1] the AIS signer was unable to handle the dynamic elf format resulting from the introduction of arm relocation.
I am not completely sure about this, but I had a look at some memory dumps today with u-boot's md command: I got the impression that these tools (aisgen as well as hexais) just copy the content of u-boot.bin into the image that is programmed to flash. Eventually they add some additional information but the u-boot.bin seems to be unmodified. Anyway, hexais did not complain about the u-boot format.
Good. Glad to be wrong about that.
If that particular problem is no more, then I imagine that UBL would have been doing pinmux for serial port among other things.
Indeed UBL does a lot of pinmuxing, but the board init routines of u-boot seem to do the same. I tried to add pinmux settings to the AIS for the serial port (UART2), but it did not change things.
Anyway, with older u-boot version everything worked fine, even access to SPI memory and Ethernet from u-boot, no additional pinmuxing in the AIS was required.
Ok. I started browsing the UBL source -- wow it does alot of things. Perhaps we should start at the top: One of the first things it does is disable the DSP. Which for the L138 seems to be:
/* assert DSP local reset */ PSC0->MDCTL[15] &= ~0x100;
/* Turn off DSP */ DEVICE_LPSCTransition(0, 15, 1, PSC_SWRSTDISABLE);
But I guess you don't need to worry about that since you're using the AM1808...
The next thing it does is unlock the KICK registers: // Unlock kick registers SYSTEM->KICKR[0] = 0x83e70b13; /* Kick0 register + data (unlock) */ SYSTEM->KICKR[1] = 0x95a4f1e0; /* Kick1 register + data (unlock) */
Hawkboard's nand_spl does this too, see board/davinci/da8xxevm/hawkboard_nand_spl.c.
Please keep me posted.
Best Regards, Ben Gardiner
--- Nanometrics Inc. http://www.nanometrics.ca
participants (2)
-
Ben Gardiner -
Christian Riesch