RBL source code

The ROM boot loader source is not available for distribution. I apologize for any inconvencience this might cause.  If you are having boot issues, please provide any pertinent details about your system and the complete output of using the debug GEL file after connecting with JTAG.

Regards, Daniel

Daniel,

I started to reverse engineer the RBL and I can see that the RBL is reading some data from NAND and transfer them or at least tries. But I am not able to see if it is successful.

Since there several long loops with many conditions, I am not able  to reach the point where the RBL moves to the infinite loop (0xFFFD397C).

I launch the TI debugger, connect to the L138 ARM, load the debug GEL. and launch the script.

L138 is connected to a 8-bit NAND and a DDR2. Power Regulator generates the ramp-up for voltage 1.2V, 1.8V and 3.3V, and reset is release 400ms after all supply voltages have reached the specified level.

Please find attached the adapted version of NAND writer I am using under CCSv4.2.

8863.NANDWriter_ARM.zip

You will need to create a workspace and import this project in the workspace.

You can change the name of any binary file in the NAND writer.c file and then compile. NAND parameters are detected automatically.

NAND writer checks also the data at the end. (I am checking for now only the first block).

Rgds

KB

KB,

Can you provide a dump of the memory contents from 0xFFFF0700-0xFFFF0800 and also from 0xFFFF1000-0xFFFF1100.  The first region contains data that the boot loader stores in a global structure, including the detected NAND parameters.  The second section is part of the buffer where a NAND page should be read to so it can be processed by the boot loader.

This could help use figure out where things are going wrong (detection vs reading, etc.).

Regards, Daniel

Daniel,

Please find attached the files.

1524.BinData.zip

We can see the AIS file in the section 0xFFFF1000. So it might mean that the NAND data has been loaded.

Thx

KB

KB,

Results from the data dump:

  Uint32    flashBase           = 0x62000000;          // Base address of CS memory space where NAND is connected
  Uint8     busWidth            = 0x01;           // NAND bus width
  Uint8     manfID              = 0x2C;             // NAND manufacturer ID (just for informational purposes)
  Uint8     devID               = 0x48;              // NAND_TABLE_Devices index (device ID)
  Uint32    numBlocks           = 0x00001000;          // block count per device
  Uint16    pagesPerBlock       = 0x80;      // page count per block
  Uint16    dataBytesPerPage    = 0x1000;   // Number of bytes in a page
  Uint16    spareBytesPerPage   = 0x00E0;  // Number of spare bytes in a page 
  Uint16    dataBytesPerOp      = 0x0200;     // Number of bytes per operation
  Uint16    spareBytesPerOp     = 0x0010;    // Number of spare bytes per operation
  Uint8     numOpsPerPage       = 0x08;      // Number of operations to complete a page read/write 
  Uint8     numColAddrBytes     = 0x02;    // Number of Column address cycles
  Uint8     numRowAddrBytes     = 0x03;    // Number of Row address cycles
  Uint8     CSOffset            = 0x01;           // 0 for CS2 space, 1 for CS3 space, 2 for CS4 space, 3 for CS5 space 
  Bool      isLargePage         = true;        // TRUE = Big block device, FALSE = small block device
  Bool      isONFI              = true;             // TRUE = ONFI-compatible device, FALSE = non-ONFI device
  Int32     currBlock           = 0x00000001;          // current Block in use
  Bool      isBlockGood         = true;        // TRUE=current block is good, FALSE=block is bad

Clearly the NAND is being identified and the first page of data looks like it is being read.  I think what we are seeing is an ECC failure on this first page, which gets read in the peripheral open function.  So the error that comes back when the first page read fails (in the open function) is peripheral open failed.

Is your flashing tool validating the ECC data? If it is based on our source, I'm guessing it is.

I suggest you check the region from 0xFFFF1000-0xFFFF1800.  That should be the entire contents of the first page of the NAND. Compare it to what you expect it to be from the file you flashed and see if you find any discrepancies.

Regards, Daniel

Daniel,

That's a good news.

NAND writer ECC processing is the same as the one provided in Serial Flasher. Same source code.

I noticed that CSOffset is at 0 in the NAND writer... It should be 1! I will check if it is used anywhere.

I am also going to check  the content of RAM.

Thx

KB

Daniel,

Good news. In the NAND writer, the CSOffset was set to 0, not 1.

CSOffset = 1 corresponds  to CS3.

So the board now boots.

Thx

KB

Do you also have a NAND attached to CS2?  I'm confused how the flashing tool worked if you were talking to the incorrect CSn.

Regards, Daniel

Daniel,

The base address was correct (0x62000000 for CS3), but CSOffset was wrong.

CSOffset is used in the NAND writer to process the ECC and tell the processor which Chip Select needs ECC.

NAND writer was probably not writing ECC in CS3.

I am using the base address to write in NAND flash, not CSOffset.

Rgds

KB

I see.  I guess none of the ECC operations were ever taking place correctly, so the ECC data written to the flash was wrong, but the verify step was also never seeing ECC errors since you were once again looking at the wrong register(s).

Well, glad things have now been cleared up.

Regards, Daniel

Daniel,

In the original NAND writer source code,  the CSOffset was set with the AsyncMemInfo field chipSelectNum. I am not sure why this chipSelectNum was not set.

So I manually set it in the NAND writer soure code.

Rgds

KB

Daniel,

I would be great if TI could make available the data structure stored in ARM RAM by the RBL. That would help a lot engineers debug the boot and save TI engineers' time.

Thx for your support.

Rgds

KB

Goodmorning,

I have a similar problem with a tms320dm6446 custom board.

I need to know the same informations about the structure that holds flash features and timings. If I dump them Daniel, could you please send me the structure?

Where is the memory zone in dm6446 to dump?

Every type of help will be apreciated because I cannot boot with this flash (MT29F4G16ABBDA) and I tried to debug rbl assembly code but I'm not good as KB.

Some extra informations:

-I can write it with serial flash loader but only changing in device_async_mem.h the DEVICE_ASYNC_MEM_NANDBOOT_BUSWIDTH define to 16bit

-I can write, read, accessing filesystem from linux with minimal changes to source code (relative to bus width)

-Rbl tries to read it because with an oscilloscope I found that ONFI and magic number are read from the bus. I don't know next reads because It's difficult to trigger without an emulator (that now instead I have).

Thanks a lot, Regards

Matteo

Goodmorning,

An extra information I left to write:

-I cannot boot because I see BOOTME (so the rbl switched to UART mode)

-I didn't found the ubl in IRAM so probably It doesn't try neither to copy from NAND

-With the emulator I found that Rbl changes the ASIZE bit only with relative dip-switch onboard so if I set it to 8 bit (and the nand is 16 bit) at the

end of the cycle (when I see BOOTME on uart) this bit remains set to 8..

Regards

hello I Need it Much。