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

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

[Ben Gardiner]

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

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

[Christian Riesch]

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

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

[Ben Gardiner]

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

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

[Heiko Schocher]

Hello Christian,

Christian Riesch 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

Never used AIS, so I could not say much (I read also the
response from Ben, so just one more idea):

> [General]
> busWidth=8            
> BootMode=SPIMASTER

Is this the same bootmode when using UBL?
By different bootmodes, the cpu inits different the
pinmux.

> 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

Maybe RAM init wrong? So RAM works not correct, or RAM size gets wrong
detected?

> 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.

I think, you need a debugger here, to find out, where u-boot
crashes (if it crashes), sorry!

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

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

[Ben Gardiner]

Hi again,

On Wed, Jun 1, 2011 at 12:58 PM, Christian Riesch
<christian.riesch@omicron.at> wrote:
> Hi,
>
> 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

I've been trying to reproduce here but not having any luck so far.

I'm using the 2.31 Davincii Serial Boot and flashing utilites [1],
Mono 2.10 and the parent of commit
f1d2b313c9eb6808d30c16a9eb5251240452a56c: '4fff329
nand_boot_fsl_nfc.c: make "nfc" a "static const" pointer'

I build u-boot with 'make mrproper; make da850evm_config; make -j9 all';
I create an ais_output.bin with 'mono
/media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/AISUtils/HexAIS_OMAP-L138.exe'
I erase the SPI flash with 'mono
/media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
-erase -p /dev/ttyS0'
I write the SPI flash with 'mono
/media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
-flash_noubl ais_output.bin'

and the contents of my OMAP-L138.ini are as yours:
[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

I would like to help you debug the operation of UBL-free boot with
relocation -- can you give me more details on your setup to help me
reproduce here?

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

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

[Christian Riesch]

Hello Ben,

On Fri, Jun 3, 2011 at 6:24 PM, Ben Gardiner <bengardiner@nanometrics.ca> wrote:
> I've been trying to reproduce here but not having any luck so far.

What are your results? Any error messages/different behavior than
described in my emails?

I just tried to reproduce what you did, everything worked as expected :-)

My hardware is the AM1808 experimenter's kit from LogicPD, base board
1015525 Rev. 2, the SOM is 1015232 Rev. 4. It is connected to a USB
serial port on my Linux box, /dev/ttyUSB0.

> I'm using the 2.31 Davincii Serial Boot and flashing utilites [1],
> Mono 2.10 and the parent of commit
> f1d2b313c9eb6808d30c16a9eb5251240452a56c: '4fff329
> nand_boot_fsl_nfc.c: make "nfc" a "static const" pointer'
>
> I build u-boot with 'make mrproper; make da850evm_config; make -j9 all';

$ cd u-boot
$ git checkout 4fff329
$ export CROSS_COMPILE=arm-none-linux-gnueabi-
$ make mrproper; make da850evm_config; make -j9 all

$ cd ..
$ mkdir ben
$ ln -s ../u-boot/u-boot.bin .
$ nano OMAP-L138.ini   (copy&pasted the configuration from your email
to the text editor)

> I create an ais_output.bin with 'mono
> /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/AISUtils/HexAIS_OMAP-L138.exe'
> I erase the SPI flash with 'mono
> /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
> -erase -p /dev/ttyS0'
> I write the SPI flash with 'mono
> /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
> -flash_noubl ais_output.bin'

I am using flash and boot utils 2.31 as well. Mono version is 2.4, I
had to rebuild the utilities to make them run with mono on my machine.
I modified the flash and boot utils' makefiles to build for the AM1808
target only (otherwise I would have to install the DSP compiler).

$ mono ../flash-2.31/HexAIS_OMAP-L138.exe

$ mono ../flash-2.31/sfh_OMAP-L138.exe -erase -targetType AM1808 -p /dev/ttyUSB0
(added the -targetType option, default is OMAP-L138)

$ mono ../flash-2.31/sfh_OMAP-L138.exe -targetType AM1808 -p
/dev/ttyUSB0 -flash_noubl ais_output.bin
(added -targetType and -p options)

$ minicom
-> reboot of the board with boot configuration set to "boot from SPI"
-> u-boot prompt appears on the serial console:

---snip---
U-Boot 2010.09-rc2-00028-g4fff329 (Jun 06 2011 - 08:10:46)

I2C:   ready
DRAM:  64 MiB
Using default environment

*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
DA850-evm >
---snip---

> and the contents of my OMAP-L138.ini are as yours:
> [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
>
> I would like to help you debug the operation of UBL-free boot with
> relocation -- can you give me more details on your setup to help me
> reproduce here?

If I try the same with git checkout ab86f72c354f9b2572, I get no
response on the serial console. Furthermore I also tried the most
recent u-boot, 6f4dd40cddbd69c56fec1285fee02cbd5a3833d8, Prepare
v2011.06-rc2, no response on the serial port console.

Thank you very much for your help! Hope the information above helps,
do you need anything else?
Regards, Christian

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

[Ben Gardiner]

Hi Christian,

On Mon, Jun 6, 2011 at 3:11 AM, Christian Riesch
<christian.riesch@omicron.at> wrote:
> Hello Ben,
>
> On Fri, Jun 3, 2011 at 6:24 PM, Ben Gardiner <bengardiner@nanometrics.ca> wrote:
>> I've been trying to reproduce here but not having any luck so far.
>
> What are your results? Any error messages/different behavior than
> described in my emails?

Same as you "(no sign of life on the serial port)"

> I just tried to reproduce what you did, everything worked as expected :-)

:) ok

> My hardware is the AM1808 experimenter's kit from LogicPD, base board
> 1015525 Rev. 2, the SOM is 1015232 Rev. 4. It is connected to a USB
> serial port on my Linux box, /dev/ttyUSB0.

So I guess there is a difference right off the bat here: I have
OMAPL138 evm from LogicPD, base board 1013527 rev 5; SOM 1014650 rev
A.

>> I'm using the 2.31 Davincii Serial Boot and flashing utilites [1],
>> Mono 2.10 and the parent of commit
>> f1d2b313c9eb6808d30c16a9eb5251240452a56c: '4fff329
>> nand_boot_fsl_nfc.c: make "nfc" a "static const" pointer'
>>
>> I build u-boot with 'make mrproper; make da850evm_config; make -j9 all';
>
> $ cd u-boot
> $ git checkout 4fff329
> $ export CROSS_COMPILE=arm-none-linux-gnueabi-
> $ make mrproper; make da850evm_config; make -j9 all
>
> $ cd ..
> $ mkdir ben
> $ ln -s ../u-boot/u-boot.bin .
> $ nano OMAP-L138.ini ? (copy&pasted the configuration from your email
> to the text editor)
>
>> I create an ais_output.bin with 'mono
>> /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/AISUtils/HexAIS_OMAP-L138.exe'
>> I erase the SPI flash with 'mono
>> /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
>> -erase -p /dev/ttyS0'
>> I write the SPI flash with 'mono
>> /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
>> -flash_noubl ais_output.bin'
>
> I am using flash and boot utils 2.31 as well. Mono version is 2.4, I
> had to rebuild the utilities to make them run with mono on my machine.
> I modified the flash and boot utils' makefiles to build for the AM1808
> target only (otherwise I would have to install the DSP compiler).

There's another difference -- I have tried rebuilding also but I
always gave up when 'timake' was not available. How are you working
around this? You are perhaps rebuilding in windows with CCSv3?

> $ mono ../flash-2.31/HexAIS_OMAP-L138.exe
>
> $ mono ../flash-2.31/sfh_OMAP-L138.exe -erase -targetType AM1808 -p /dev/ttyUSB0
> (added the -targetType option, default is OMAP-L138)
>
> $ mono ../flash-2.31/sfh_OMAP-L138.exe -targetType AM1808 -p
> /dev/ttyUSB0 -flash_noubl ais_output.bin
> (added -targetType and -p options)

I'll try the 'targetType' option also.

> $ minicom
> -> reboot of the board with boot configuration set to "boot from SPI"
> -> u-boot prompt appears on the serial console:
>
> ---snip---
> U-Boot 2010.09-rc2-00028-g4fff329 (Jun 06 2011 - 08:10:46)
>
> I2C: ? ready
> DRAM: ?64 MiB
> Using default environment
>
> *** Warning - bad CRC, using default environment
>
> In: ? ?serial
> Out: ? serial
> Err: ? serial
> DA850-evm >
> ---snip---

Ok well that's promising.

> Thank you very much for your help! Hope the information above helps,
> do you need anything else?
> Regards, Christian

I think it would be good to know how you're rebuilding the Flash and
Boot utilities and what compiler you are using for building u-boot. I
am using codesourcery's 2009q1 here.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

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

[Ben Gardiner]

Hi Christian,

On Mon, Jun 6, 2011 at 10:52 AM, Christian Riesch
<christian.riesch@omicron.at> wrote:
> Hi Ben,
> Thanks again for your help!

My pleasure, sorry I can't help more : I think It's the case that we
have incompatible HW.

> On Mon, Jun 6, 2011 at 3:11 PM, Ben Gardiner <bengardiner@nanometrics.ca> wrote:
>>> I am using flash and boot utils 2.31 as well. Mono version is 2.4, I
>>> had to rebuild the utilities to make them run with mono on my machine.
>>> I modified the flash and boot utils' makefiles to build for the AM1808
>>> target only (otherwise I would have to install the DSP compiler).
>>
>> There's another difference -- I have tried rebuilding also but I
>> always gave up when 'timake' was not available. How are you working
>> around this? You are perhaps rebuilding in windows with CCSv3?
>
> No, I build in Linux:
>
> * Download OMAP-L138_FlashAndBootUtils_2_31.tar.gz from
> https://sourceforge.net/projects/dvflashutils/files
>
> tar xvfz OMAP-L138_FlashAndBootUtils_2_31.tar.gz
> cd OMAP-L138_FlashAndBootUtils_2_31
>
> * Apply the attached patch
> patch -p1 <flasham1808.patch
>
> * Build
> cd OMAP-L138/GNU/
> make clean
> make

Thanks for the patch. I applied and built as you suggested to use mono
2.4; now the only difference between our setups is the SOM (which has
a difference SoC on it -- yours is AM1808 mine is OMAPL138) and
baseboard.

Following the steps, I get no serial activity when u-boot is built
from "4fff329 nand_boot_fsl_nfc.c: make "nfc" a "static const"
pointer."

I did notice that I can erase/flash using either -targetType AM1808 or
OMAPL138 and get serial console output by using either the OMAPL138 or
AM1808 UBL's; all of the following commands result in serial output
from the board.

mono /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
-targetType AM1808  -p /dev/ttyS0 -flash_noubl
/media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/ubl/ubl_AM1808_SPI_MEM.bin

mono /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
-targetType OMAPL138 -p /dev/ttyS0 -flash_noubl
/media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/ubl/ubl_AM1808_SPI_MEM.bin

mono /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
-targetType AM1808  -p /dev/ttyS0 -flash_noubl
/media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/ubl/ubl_OMAPL138_SPI_MEM.bin

mono /media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/sfh_OMAP-L138.exe
-targetType OMAPL138 -p /dev/ttyS0 -flash_noubl
/media/unixdata/src/OMAP-L138_FlashAndBootUtils_2_31/OMAP-L138/GNU/ubl/ubl_OMAPL138_SPI_MEM.bin

So it appears there is no incompatibility introduced by the AM1808 /
OMAPL138 variant in flashing.

It seems that there is something that your AM1808 RBL is performing
which is not being performed by my OMAPL138 here. This could be due to
a misinterpreted AIS command maybe. Whatever the case, the UBL that is
prebuilt with the flash and boot utilities seems to be doing the right
setup.

I think that the AIS script header is not critical; I noticed that the
arm ubl's are all being built with the simple -uart.ini :

$grep -r " -ini " CCS/UBL_ARM/
CCS/UBL_ARM/UBL_NAND.pjt:FinalBuildCmd=..\..\GNU\AISUtils\HexAIS_OMAP-L138.exe
-ini ..\..\GNU\AISUtils\OMAP-L138-uart.ini -o $(Proj_dir)\UBL_NAND.ais
$(Proj_dir)\NAND\UBL_NAND.out;Run=Always
Binary file CCS/UBL_ARM/UBL_SPI_MEM.paf2 matches
CCS/UBL_ARM/UBL_SPI_MEM.pjt:FinalBuildCmd=..\..\GNU\AISUtils\HexAIS_OMAP-L138.exe
-ini ..\..\GNU\AISUtils\OMAP-L138-uart.ini -o
$(Proj_dir)\UBL_SPI_MEM.ais
$(Proj_dir)\SPI_MEM\UBL_SPI_MEM.out;Run=Always
Binary file CCS/UBL_ARM/UBL_NAND.paf2 matches
CCS/UBL_ARM/UBL_NOR.pjt:FinalBuildCmd=..\..\GNU\AISUtils\HexAIS_OMAP-L138.exe
-ini ..\..\GNU\AISUtils\OMAP-L138-uart.ini -o $(Proj_dir)\UBL_NOR.ais
$(Proj_dir)\NOR\UBL_NOR.out;Run=Always
Binary file CCS/UBL_ARM/UBL_NOR.paf2 matches
CCS/UBL_ARM/cc_build_Debug.log:..\..\GNU\AISUtils\HexAIS_OMAP-L138.exe
-ini ..\..\GNU\AISUtils\OMAP-L138-uart.ini -o
C:\cat_flashutils\scripts\OMAP-L138_FlashAndBootUtils_2_31\OMAP-L138\CCS\UBL_ARM\UBL_NOR.ais
C:\cat_flashutils\scripts\OMAP-L138_FlashAndBootUtils_2_31\OMAP-L138\CCS\UBL_ARM\NOR\UBL_NOR.out

for reference the contents of OMAP-L138-uart.ini:
---
; General settings that can be overwritten in the host code
; that calls the AISGen library.
[General]

; Can be 8 or 16 - used in emifa
busWidth=8

; SPIMASTER,I2CMASTER,EMIFA,NAND,EMAC,UART,PCI,HPI,USB,MMC_SD,VLYNQ,RAW
BootMode=UART

; 8,16,24 - used for SPI,I2C
;AddrWidth=8

; NO_CRC,SECTION_CRC,SINGLE_CRC
crcCheckType=NO_CRC
---

Since the AIS generated does no setup relevant to the platform it
seems that it should be possible to stick all the UBL setup into
u-boot and sign it with simple AIS using the above ini.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

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

[Christian Riesch]

Hi Ben,

I had no hardware for a about a week but now I have an AM1808 experimenter's 
kit again and can continue investigating this issue.

On this board, older versions of u-boot (like v2009.11) boot perfectly,
even when TI's UBL boot loader is not used (instead the configuration of 
DDR memory was done using an AIS script). However, since commit 
f1d2b313c9eb6808d30c16a9eb5251240452a56c u-boot boots only when used in 
conjunction with TI's UBL boot loader. When used without UBL, u-boot showed
no sign of life on the serial port.

The content of the .ini file to build the AIS script using the
HexAIS tool was

[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

After investigating the problem today I figured out that the reason for 
the problem is the configuration of LPSC for UART2. To make u-boot work,
the following lines must be added to the .ini file to enable the UART2
PSC module:

[PSCCONFIG]
LPSCCFG = 0x010D0003

This seems odd, since LPSC configuration is already done by board_init()
in board/davinci/da8xxevm/da850evm.c. However, I guess this initialization
is done too late, since arch/arm/lib/board.c calls other serial port related
functions before board_init() is executed. When I move the LPSC configuration
of UART2 to a board_early_init_f() function, u-boot boots even without the
[PSCCONFIG] section in the .ini file. The patch below does the required
modifications.

Ben, would you mind testing this patch on your board?
Is this the correct way to address this problem?

Best regards, Christian

 board/davinci/da8xxevm/da850evm.c |    7 ++++++-
 include/configs/da850evm.h        |    1 +
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/board/davinci/da8xxevm/da850evm.c b/board/davinci/da8xxevm/da850evm.c
index 73eaa48..a864412 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -129,7 +129,6 @@ static const struct lpsc_resource lpsc[] = {
 	{ DAVINCI_LPSC_AEMIF },	/* NAND, NOR */
 	{ DAVINCI_LPSC_SPI1 },	/* Serial Flash */
 	{ DAVINCI_LPSC_EMAC },	/* image download */
-	{ DAVINCI_LPSC_UART2 },	/* console */
 	{ DAVINCI_LPSC_GPIO },
 };
 
@@ -166,6 +165,12 @@ u32 get_board_rev(void)
 	return rev;
 }
 
+int board_early_init_f(void)
+{
+	lpsc_on(DAVINCI_LPSC_UART2);
+	return 0;
+}
+
 int board_init(void)
 {
 #ifndef CONFIG_USE_IRQ
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index bbb5a9b..5d0f5bf 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -42,6 +42,7 @@
 #define CONFIG_SYS_HZ			1000
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE		0xc1080000
+#define CONFIG_BOARD_EARLY_INIT_F
 
 /*
  * Memory Info
-- 
1.7.0.4

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

[Wolfgang Denk]

Dear Christian Riesch,

In message <1308575272-30559-1-git-send-email-christian.riesch@omicron.at> you wrote:
> 
> On this board, older versions of u-boot (like v2009.11) boot perfectly,
> even when TI's UBL boot loader is not used (instead the configuration of 
> DDR memory was done using an AIS script). However, since commit 

What is AIS ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There you go man, Keep as cool as you can. It riles them  to  believe
that you perceive the web they weave. Keep on being free!

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

[Christian Riesch]

Hello Wolfgang,

On Mon, Jun 20, 2011 at 3:46 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Christian Riesch,
>
> In message <1308575272-30559-1-git-send-email-christian.riesch@omicron.at> you wrote:
>>
>> On this board, older versions of u-boot (like v2009.11) boot perfectly,
>> even when TI's UBL boot loader is not used (instead the configuration of
>> DDR memory was done using an AIS script). However, since commit
>
> What is AIS ?

I apologize for using that many abbreviations in my mail and not
explaining them :-/

AIS is short for Application Image Script [1]. It is a boot script
that is processed by the ROM bootloader on Texas Instrument's
AM1808/DA850/OMAP-L138 processors. The script allows configuration of
boot modes, PLLs, DDR memory, Pinmuxes etc and loading the an
application like u-boot from flash to RAM and executing it. Using a
suitable AIS one can configure PLL and DDR memory and then directly
start u-boot on these processors, without using Texas Instruments's
user boot loader (UBL) [2].

In the default configuration of the da850evm the boot sequence is like this:
1) ROM bootloader (RBL): starts reading from flash
2) In the SPI-flash, a very simple AIS is present. This AIS tells the
RBL to load the UBL from flash and to start it.
3) The UBL does a lot of hardware initialization and then loads u-boot
from flash and starts it.
4) u-boot does a lot of hardware initialization that has already been
done by the UBL and then loads the Linux kernel.

For my application I would like to get rid of the UBL since most of
the configuration it does is also done by u-boot (although there seems
to be a bug in it) or can be done by AIS (like PLL and DDR memory
configuration), the resulting boot sequence will be:
1) ROM bootloader (RBL): starts reading from flash
2) In the SPI-flash, an AIS is present. This AIS tells the RBL to
configure PLLs and DDR memory and to  load u-boot from flash and to
start it.
3) u-boot loads the Linux kernel.

Hope that helps :-)
Best regards, Christian


[1] Using the AM18xx Bootloader (Rev. A)
http://focus.ti.com/dsp/docs/litabsmultiplefilelist.tsp?sectionId=3&tabId=409&literatureNumber=spraba5a&docCategoryId=1&familyId=1877

[2] https://sourceforge.net/projects/dvflashutils/files

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

[Wolfgang Denk]

Dear Christian Riesch,

In message <BANLkTimhJSs_URkzB-q5y7GQzawSWe005g@mail.gmail.com> you wrote:
>
> > What is AIS ?
> 
> I apologize for using that many abbreviations in my mail and not
> explaining them :-/
> 
> AIS is short for Application Image Script [1]. It is a boot script
> that is processed by the ROM bootloader on Texas Instrument's
> AM1808/DA850/OMAP-L138 processors. The script allows configuration of
> boot modes, PLLs, DDR memory, Pinmuxes etc and loading the an
> application like u-boot from flash to RAM and executing it. Using a
> suitable AIS one can configure PLL and DDR memory and then directly
> start u-boot on these processors, without using Texas Instruments's
> user boot loader (UBL) [2].
> 
> In the default configuration of the da850evm the boot sequence is like this:
> 1) ROM bootloader (RBL): starts reading from flash
> 2) In the SPI-flash, a very simple AIS is present. This AIS tells the
> RBL to load the UBL from flash and to start it.
> 3) The UBL does a lot of hardware initialization and then loads u-boot
> from flash and starts it.
> 4) u-boot does a lot of hardware initialization that has already been
> done by the UBL and then loads the Linux kernel.
> 
> For my application I would like to get rid of the UBL since most of
> the configuration it does is also done by u-boot (although there seems
> to be a bug in it) or can be done by AIS (like PLL and DDR memory
> configuration), the resulting boot sequence will be:
> 1) ROM bootloader (RBL): starts reading from flash
> 2) In the SPI-flash, an AIS is present. This AIS tells the RBL to
> configure PLLs and DDR memory and to  load u-boot from flash and to
> start it.
> 3) u-boot loads the Linux kernel.

Thanks for the explanations.

You might want to synchronize your efforts with Heiko Schocher (on
cc:) who might be working on similar things.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any time things appear to be going better, you have overlooked  some-
thing.

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

[Christian Riesch]

Hello Wolfgang,

On Monday, June 20, 2011, Wolfgang Denk <wd@denx.de> wrote:
> You might want to synchronize your efforts with Heiko Schocher (on
> cc:) who might be working on similar things.

Thanks! I put Heiko on cc in my first email in this thread, but then
forgot it later. Sorry about that, Heiko, I am looking forward to your
comments.

Regards, Christian

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

[Heiko Schocher]

Hello Christian,

Sorry for the late answer ...

Wolfgang Denk wrote:
> Dear Christian Riesch,
> 
> In message <BANLkTimhJSs_URkzB-q5y7GQzawSWe005g@mail.gmail.com> you wrote:
>>> What is AIS ?
>> I apologize for using that many abbreviations in my mail and not
>> explaining them :-/
>>
>> AIS is short for Application Image Script [1]. It is a boot script
>> that is processed by the ROM bootloader on Texas Instrument's
>> AM1808/DA850/OMAP-L138 processors. The script allows configuration of
>> boot modes, PLLs, DDR memory, Pinmuxes etc and loading the an
>> application like u-boot from flash to RAM and executing it. Using a
>> suitable AIS one can configure PLL and DDR memory and then directly
>> start u-boot on these processors, without using Texas Instruments's
>> user boot loader (UBL) [2].
>>
>> In the default configuration of the da850evm the boot sequence is like this:
>> 1) ROM bootloader (RBL): starts reading from flash
>> 2) In the SPI-flash, a very simple AIS is present. This AIS tells the
>> RBL to load the UBL from flash and to start it.
>> 3) The UBL does a lot of hardware initialization and then loads u-boot
>> from flash and starts it.

Ok.

>> 4) u-boot does a lot of hardware initialization that has already been
>> done by the UBL and then loads the Linux kernel.

Hmm.. why does U-Boot code again such initialization? This is
wrong ... this should be cleaned up!

Ok, I do actually a similiar job for an TI DM368 based board,
booting from NAND flash. I am using instead the UBL, now the
nand_spl code from u-boot, bootsequence is:

1) ROM bootloader (RBL) searches for an UBL Header in NAND,
   which contains the info where to find in the NAND flash the
   "UBL" (User Boot Loader). If such an header is found:

2) loading the UBL(now nand_spl code) from NAND to internal RAM
   and start executing it.

3) The UBL (nand_spl code) inits RAM, clocks... and loads U-Boot
   from NAND to RAM and jumps to it ...


So I actually create with "make board_config" an u-boot.ubl image,
which contains this ubl header(created with mkimage), nand_spl code
and u-boot, burn this into nand, and boot it ...

>> For my application I would like to get rid of the UBL since most of
>> the configuration it does is also done by u-boot (although there seems
>> to be a bug in it) or can be done by AIS (like PLL and DDR memory
>> configuration), the resulting boot sequence will be:
>> 1) ROM bootloader (RBL): starts reading from flash

How detects the RBL that there is something in the SPI flash,
isn;t there such a header like on the DM368?

Ah, looked in [1] and there is nothing similiar ...

>> 2) In the SPI-flash, an AIS is present. This AIS tells the RBL to
>> configure PLLs and DDR memory and to  load u-boot from flash and to
>> start it.

Maybe you can use here the "simple AIS header" as above in step 2
(maybe create this simple header with the mkimage tool?) and use
something like the nand_spl code calling it spi_spl which do all
necessary setups (DDR, PLL,...) in C-Code? So we can get rid off
this external AIS tool, UBL and do *all* things in/with U-boot?

Please look also into the "SPL framework re-design" thread.

>> 3) u-boot loads the Linux kernel.

bye,
Heiko

[1]: http://focus.ti.com/lit/an/spraba5a/spraba5a.pdf
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany