nandwriter.h Magic Numbers

KB2603 said:

I have noticed that nandwriter.h Magic Numbers from release 03.20.00.14 for OMAP-L138 does not match Magic Numbers from document SPRAB41C.

I am wondering whether nandwriter.h Magic Numbers should be updated accordingly?

Release 3.20.00.14 of what?

 The Magic number may be changed throughout the ROM revisions. You need to check which ROM revision of the OMAP-L138 you are using to determine what is the appropriate revision of the document to reference. Also - the software may be out of date.

Drew,

I was referring to DaVinci PSP Release 3.20.00.14 for OMAP-L138.

There is a NAND writer in the PSP that differs from the NAND writer found in the Flash_Boot_Utility version 2.31.

I also noticed that for the NAND writer from the PSP, there is a boot header written in page 0 of first NAND block. This boot header is using the UBL_MAGIC_ numbers.

Really my questions are:

- does the OMAP L138 need a special header to boot? I have created a AIS bin file  (from the LED blink application) for the L138 thinking that the the AIS gen would generate everything for the device to boot, but the device creates a ROM status error (Peripheral Open Failed) at the power up when booting from NAND.

I am using the Serial FLash NAND writer inside CCS to burn the NAND flash instead of using the Serial Flasher that does not seem to work (wait for sft on OMAP-L138).  I am using UART2 with Serial Flasher.

- does the OMAP L138 Ecc layout need to be changed in the NAND writer?

- does the AIS Gen hardware configuration stay after boot (PLL0, PLL1, PinMux, PSC, DDR2 config,...).

I am really confused with

My configuration is:

Omap L138 Rev: d800k006

Silcon Rev: 2

NAND (8-bit data)

DDR2 (16-bit data)

Rgds

KB

KB,

For NAND boot on OMAP-L138, you do not need a special header beyond what is created by AISgen.  The first 4 bytes of your binary AIS file are the AIS magic word, which is all that the bootloader expects to see there.  The only "gotcha" is that the boot image should be flashed to block 1 of the NAND chip, not block 0.

Any configuration you apply using the ROM bootloader (PLL, pinmux, PSC, EMIF config, etc.) should remain after boot completes.

Hope this helps.

Thx Joe for your answer. Helped me move forward.

I checked the location in NAND and the code is written in block 1, not 0.

I also read back byte by byte the content of the block to check if it was the same as the file generated by AIS.  the code is good.

In AIS Gen, I generate a .h file from the Arm application: armboot.out + dspapplication.out. I configured PLL, pinmux, PSC, EMIF, DDR2 for the custom board.

Does the RBL  read data in little endian mode? (everything is set-up for little endian).

None of the H/W configuration happens.

Any other idea what can be wrong?

Thx

KB

Are you generating a binary AIS file (.bin or .ais) or a C header file using AISgen?  If you are going to flash the contents of the generated file directly to NAND, then you should definitely generate a binary AIS file.

The ROM bootloader definitely expects the boot image to be written in little endian order.

Joe,

I tried the ais filed generated by AIS Gen.

I double check that what is written in NAND is good and match the content of the file.

Board did not boot, and I can still see the Peripheral Open Failed error.

Is AIS Gen the right tool to generate .ais file? I assumed it is.

Any other idea?

Thx

KB

Joe,

I debug step by step the RBL and found that the RBL was ending up to an infinite loop as described below:

0xFFFD3948:   68000060 STMVSED       R0, {R5-R6}
0xFFFD394C:   00130001 ANDEQS        R0, R3, R1
0xFFFD3950:   00010A0A ANDEQ         R0, R1, R10, LSL #20
0xFFFD3954:   00040B0B ANDEQ         R0, R4, R11, LSL #22
0xFFFD3958:   00010050 ANDEQ         R0, R1, R0, ASR R0
0xFFFD395C:   E24DD008 SUB           R13, R13, #0x8
0xFFFD3960:   E58D0000 STR           R0, [R13]
0xFFFD3964:   E59FC960 LDR           R12, 0xFFFD42CC
0xFFFD3968:   E58DC004 STR           R12, [R13, #0x4]
0xFFFD396C:   E5DDC000 LDRB          R12, [R13]
0xFFFD3970:   E59D0004 LDR           R0, [R13, #0x4]
0xFFFD3974:   E5C0C001 STRB          R12, [R0, #0x1]
--- Inifinite Loop ---
0xFFFD3978:   E1A00000 MOV           R0, R0
0xFFFD397C:   EAFFFFFD B             0xFFFD3978
-------------------------
0xFFFD3980:   E92D4010 STMFD         R13!, {R4, R14}
0xFFFD3984:   E59F4940 LDR           R4, 0xFFFD42CC
0xFFFD3988:   E3A02098 MOV           R2, #0x98
0xFFFD398C:   E3A01000 MOV           R1, #0x0
0xFFFD3990:   E1A00004 MOV           R0, R4
0xFFFD3994:   EB000CB0 BL            0xFFFD6C5C
0xFFFD3998:   EB000016 BL            0xFFFD39F8
0xFFFD399C:   E1D4C0B2 LDRH          R12, [R4, #0x2]

Joe,

What should be stored in block 0?

Thx

KB2603

KB,

It doesn't matter what you put in NAND block 0; the bootloader will never read it.

If you are still having trouble booting from NAND, I recommend creating a very simple boot image to eliminate potential issues and just test the basic boot process.  For example, you could generate an AIS file from a simple "while (1)" ARM application that runs out of L3RAM.  This would allow you to create an AIS image that has no EMIF or PLL configuration, and only one small section load opcode.  If that works, you can then add in your EMIF configuration and other complexities to see what is actually causing boot to fail.

Joe,

I just tested a simple application with only while(1); in the main().

PC is stuck somewhere in the RBL but not in main.

Do I have to specify a vector table for the ARM that will need to be loaded to address 0xFFFF0000?

Thx

KB

Joe,

I generated a vector table for the ARM and tried to place it into address 0xFFFF0000.

I can see the obj generated for the arm table code but the linker is getting rid of it. This is probably due to an optimization.

How can I tell the linker to keep the vector table?

Thx

KB

KB,

Your application doesn't need to place vectors at 0xFFFF0000.  The bootloader should automatically jump to the program entrypoint (i.e. _c_int00) immediately after boot completes.  In fact, your application generally should not contain code or data in ARM local RAM since this may be overwritten during boot.  Also, I neglected to mention this in my previous post, but you should avoid using the first 16K of L3RAM in your application.  In general, follow the guidelines from Section 9 of the bootloader app note:

• Memory Usage: The bootloader uses 16 KB of Shared RAM starting from 0x80000000 for multiple purposes. This memory should not be used by any initialized section of the user application.
• Non-NAND Memory Usage: The bootloader uses 2 KB of ARM local RAM starting from 0xFFFF0000. This memory should not be used by any initialized section of the user application.
• NAND Memory Usage: The bootloader uses 8 KB of ARM local RAM starting from 0xFFFF0000. This memory should not be used by any initialized section of the user application.

Joe,

Please find attached a simple project with an ARM application that does only while(1);

I can't have this application boot. Can you tell me if you see anything wrong?

Thx

KB

4274.BootL138Test.zip

KB,

I was able to boot your AIS successfully using NAND8 boot mode.  The biggest problem I ran into was getting the correct boot pin setting on my EVM.  I initially misread the schematic and made an incorrect selection.  The correct boot pin settings for NAND8 boot are as follows:

S7[1:8] = 00001000

Also, if you haven't downloaded the debug GEL file, I recommend that you check it out.  This can be a big help trying to identify any specific error conditions that you may encounter during boot.

• http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

Hope this helps.

Can you provide the complete output of the debug GEL file? It sounds like you are already reading this since you mentioned that you know it is a peripheral open failure that you are seeing.  Can you also please provide information on the exact NAND device that you are using?  In general, I would expect that if you can use the flashing utility to write the NAND, then the boot loader should be able to read it, but maybe that is not the case here.

Regards, Daniel

Daniel,

Your name sounds familiar. Not sure where I saw it.

Please find attached the output of the debug file.

ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |               BOOTROM Info                |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: ROM ID: d800k006 
ARM9_0: GEL Output: Silicon Revision 2.0
ARM9_0: GEL Output: Boot Mode: NAND 8
ARM9_0: GEL Output: 
ROM Status Code: 0x00000005 
Description:ARM9_0: GEL Output: Peripheral Open Failed
ARM9_0: GEL Output: 
Program Counter (PC) = 0xFFFD397C
ARM9_0: GEL Output: 
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |               BOOTROM Info                |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: ROM ID: d800k006 
ARM9_0: GEL Output: Silicon Revision 2.0
ARM9_0: GEL Output: Boot Mode: NAND 8
ARM9_0: GEL Output: 
ROM Status Code: 0x00000005 
Description:ARM9_0: GEL Output: Peripheral Open Failed
ARM9_0: GEL Output: 
Program Counter (PC) = 0xFFFD397C
ARM9_0: GEL Output: 
---------------------------------------------
ARM9_0: GEL Output: |             Device Information            |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: DEV_INFO_00 = 0x1B7D102F
ARM9_0: GEL Output: DEV_INFO_01 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_02 = 0x0000000E
ARM9_0: GEL Output: DEV_INFO_03 = 0x00000032
ARM9_0: GEL Output: DEV_INFO_04 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_05 = 0x000003E0
ARM9_0: GEL Output: DEV_INFO_06 = 0x00000080
ARM9_0: GEL Output: DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 0-0-5519985-17-19-8
ARM9_0: GEL Output: DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 2,0,0,13015
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_17 = 0x00030003
ARM9_0: GEL Output: DEV_INFO_18 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_19 =ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_20 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_21 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_22 = 0x30303864
ARM9_0: GEL Output: DEV_INFO_23 = 0x3630306B
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_24 = 0x11008013
ARM9_0: GEL Output: DEV_INFO_25 = 0x00543A71
ARM9_0: GEL Output: DEV_INFO_06 = 0x00000080
ARM9_0: GEL Output: DEV_INFO_26 = 0x65AE0002
ARM9_0: GEL Output: 
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: 
ARM9_0: GEL Output: PLL0_SYSCLK1 = 24 MHz
ARM9_0: GEL Output: PLL0_SYSCLK2 = 12 MHz
ARM9_0: GEL Output: PLL0_SYSCLK3 = 24 MHz
ARM9_0: GEL Output: PLL0_SYSCLK4 = 6 MHz
ARM9_0: GEL Output: PLL0_SYSCLK5 = 24 MHz
ARM9_0: GEL Output: PLL0_SYSCLK6 = 24 MHz
ARM9_0: GEL Output: PLL0_SYSCLK7 = 4 MHz
ARM9_0: GEL Output: 
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL1 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: 
ARM9_0: GEL Output: PLL1_SYSCLK1 = 24 MHz
ARM9_0: GEL Output: PLL1_SYSCLK2 = 12 MHz
ARM9_0: GEL Output: PLL1_SYSCLK3 = 24 MHz
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PSC0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: 
ARM9_0: GEL Output: State Decoder:
ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)
ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
ARM9_0: GEL Output: >3 = Transition in progress
ARM9_0: GEL Output: 
ARM9_0: GEL Output: Module 0:	EDMA3CC (0)        STATE = 0
ARM9_0: GEL Output: Module 1:	EDMA3 TC0          STATE = 0
ARM9_0: GEL Output: Module 2:	EDMA3 TC1          STATE = 0
ARM9_0: GEL Output: Module 3:	EMIFA (BR7)        STATE = 3
ARM9_0: GEL Output: Module 4:	SPI 0              STATE = 0
ARM9_0: GEL Output: Module 5:	MMC/SD 0           STATE = 0
ARM9_0: GEL Output: Module 6:	AINTC              STATE = 3
ARM9_0: GEL Output: Module 7:	ARM RAM/ROM        STATE = 3
ARM9_0: GEL Output: Module 9:	UART 0             STATE = 0
ARM9_0: GEL Output: Module 10:	SCR 0 (BR0/1/2/8)  STATE = 3
ARM9_0: GEL Output: Module 11:	SCR 1 (BR4)        STATE = 3
ARM9_0: GEL Output: Module 12:	SCR 2 (BR3/5/6)    STATE = 3
ARM9_0: GEL Output: Module 13:	PRUSS              STATE = 0
ARM9_0: GEL Output: Module 14:	ARM                STATE = 3
ARM9_0: GEL Output: Module 15:	DSP                STATE = 0
ARM9_0: GEL Output: 
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PSC1 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: 
ARM9_0: GEL Output: State Decoder:
ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)
ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
ARM9_0: GEL Output: >3 = Transition in progress
ARM9_0: GEL Output: 
ARM9_0: GEL Output: Module 0:	EDMA3CC (1)        STATE = 0
ARM9_0: GEL Output: Module 1:	USB0 (2.0)         STATE = 0
ARM9_0: GEL Output: Module 2:	USB1 (1.1)         STATE = 0
ARM9_0: GEL Output: Module 3:	GPIO               STATE = 0
ARM9_0: GEL Output: Module 4:	UHPI               STATE = 0
ARM9_0: GEL Output: Module 5:	EMAC               STATE = 0
ARM9_0: GEL Output: Module 6:	DDR2 and SCR F3    STATE = 0
ARM9_0: GEL Output: Module 7:	MCASP0 + FIFO      STATE = 0
ARM9_0: GEL Output: Module 8:	SATA               STATE = 0
ARM9_0: GEL Output: Module 9:	VPIF               STATE = 0
ARM9_0: GEL Output: Module 10:	SPI 1              STATE = 0
ARM9_0: GEL Output: Module 11:	I2C 1              STATE = 0
ARM9_0: GEL Output: Module 12:	UART 1             STATE = 0
ARM9_0: GEL Output: Module 13:	UART 2             STATE = 0
ARM9_0: GEL Output: Module 14:	MCBSP0 + FIFO      STATE = 0
ARM9_0: GEL Output: Module 15:	MCBSP1 + FIFO      STATE = 0
ARM9_0: GEL Output: Module 16:	LCDC               STATE = 0
ARM9_0: GEL Output: Module 17:	eHRPWM (all)       STATE = 0
ARM9_0: GEL Output: Module 18:	MMC/SD 1           STATE = 0
ARM9_0: GEL Output: Module 19:	UPP                STATE = 0
ARM9_0: GEL Output: Module 20:	eCAP (all)         STATE = 0
ARM9_0: GEL Output: Module 21:	EDMA3 TC2          STATE = 0
ARM9_0: GEL Output: Module 24:	SCR-F0 Br-F0       STATE = 3
ARM9_0: GEL Output: Module 25:	SCR-F1 Br-F1       STATE = 3
ARM9_0: GEL Output: Module 26:	SCR-F2 Br-F2       STATE = 3
ARM9_0: GEL Output: Module 27:	SCR-F6 Br-F3       STATE = 3
ARM9_0: GEL Output: Module 28:	SCR-F7 Br-F4       STATE = 3
ARM9_0: GEL Output: Module 29:	SCR-F8 Br-F5       STATE = 3
ARM9_0: GEL Output: Module 30:	Br-F7 (DDR Contr)  STATE = 3
ARM9_0: GEL Output: Module 31:	L3 RAM, SCR-F4, Br-F6 STATE = 3

I was not able to use the Serial Flasher, but what I retrieved the NAND writer from the Serial Flasher and created a specific project for it. we had too many issues compiling the Serial Flasher and adapt it to our board.

I open the .bin file from the NAND writer project, read it and flash the data into NAND. The NAND writer also reads back the data that have been written in flash and compared with the .bin data.

Here is the boot test project we are trying to flash and boot from.

6710.BootL138Test.zip

I can also try to post the NAND writer we are using if you need to look at it.

The ONFI-compliant NAND flash (MT29F16G08ABABAWP-IT:B) we are using is detected by the NAND writer as follows:

Base Address: 0x62000000 (CS3)

Bus Width: 1 (means = 8 bits)

ManfID: 0x2C

devID: 0x48

numBlocks: 4096

pagesPerBlock: 128

dataBytesPerPage: 4096

spareBytesPerPage: 224

dataBytesPerOp: 512

spareBytesPerOp: 16

numOpsPerPage: 8

numColAddBytes: 2

numRawAddrBytes: 3

CSOffset: 0

Rgds

KB

Daniel,

RBL reads correctly the boot Mode (0x0E = NAND boot) from SYSCFG0 register.

KB

Daniel,

Is there a list of SPI PROM known to work with the L138 RBL?

Thx

KB

KB,

We don't have a list of supported SPI EEPROM or Flash devices, but these are typical pretty simple (especially compared to NANDs) and there seems to be a default standard for these.  As long as it supports a read command of 0x03, followed by 2 (EEPROM) or 3 (Flash) address bytes, it should likely work.

Regards