Re: [U-Boot] da850evm: u-boot does not start without UBL since commit f1d2b313c9eb6808d30c16a9eb5251240452a56c
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
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
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
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&tabI...
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:
- ROM bootloader (RBL): starts reading from flash
- 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:
- ROM bootloader (RBL): starts reading from flash
- 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
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
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:
- ROM bootloader (RBL): starts reading from flash
- 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.
- 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:
- 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 ...
- 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.
- u-boot loads the Linux kernel.
bye, Heiko
[1]: http://focus.ti.com/lit/an/spraba5a/spraba5a.pdf
participants (4)
-
Ben Gardiner -
Christian Riesch -
Heiko Schocher -
Wolfgang Denk