[U-Boot] da850evm: u-boot does not start without UBL since commit f1d2b313c9eb6808d30c16a9eb5251240452a56c

Christian Riesch christian.riesch at omicron.at
Wed Jun 1 22:26:57 CEST 2011


Hello Ben,
Thank you very much for your response.

On Wednesday, June 1, 2011, Ben Gardiner <bengardiner at nanometrics.ca>
> On Wed, Jun 1, 2011 at 12:58 PM, Christian Riesch
> <christian.riesch at 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


More information about the U-Boot mailing list