OMAP-L138: RBL source code available to understand boot flash requirements?

Hi, Robert,

 We don't usually give out the RBL source code, but I'll need to check internally. It may need to go through the Sales Rep if it gets approved.

Rex

Hi Robert

Rex forward this post to me. Unfortunately OMAPL138 RBL will not be released publicly. You are right we do release the Keystone RBL , but the code structure is different and due to some IP and implementation issues same cannot be done for OMAPL138 RBL.

Surprisingly this has not been an issue much , and most customers are able to develop/debug based on the documentation and application notes. 

If you have any specific questions on particular boot mode or flash , we can try to see how best we can address. 

Regards

Mukul 

We're looking for your help booting from a NAND8 chip, the MT29F4G08ABAFAH4 (similar to the NAND8 MT29F4G08ABADAH4), with the only differences being 8-bit ECC vs 4-bit ECC, the page size is doubled, and the OOB size is 256 instead of 64.

The problem is with the initial booting up from the NAND, where the RBL is NOT able to jump to the U-boot image. On NAND bootup, there's NO printing from UART/Serial Console. The U-Boot image has been verified, along with proper read/write accesses to the NAND chip. In addition, once booted in U-Boot from SD Card, then there's no problem with executing the Linux Kernel/Busybox from NAND.

Things that have been tried as shown below in chronological order:

1) ECC
Seems that the RBL will not be able to perform the 8-bit ECC used by Micron's internal ECC engine.

Several changes were attempted...
For U-Boot, instead of using ecc mode of NAND_ECC_HW_OOB_FIRST, we used nand->ecc.mode = NAND_ECC_NONE;
nand->ecc.layout = &nand_davinci_8bit_ondie_oob_256;
For Linux, we changed ti,davinci-ecc-mode = "hw" to nand-ecc-mode = "on-die"

Per suggestion from Micron, added the new ecc layout to U-Boot. Enabled CONFIG_SYS_NAND_ONFI_DETECTION as well as changing CONFIG_SYS_NAND_PAGE_2K to CONFIG_SYS_NAND_PAGE_4K. The environment size, page size, and block size are also updated properly with U-Boot. The U-Boot version used is ti-u-boot-2019.01 built from Yocto.

The board didn't boot up from NAND, as well without the ECC changes. What we have found is that this means we've run out of room in the SRAM for the SPL. We need to try and shrink the SPL, and find something to remove from the SPL without breaking it. We found that disabling ECC is NOT an option.

2) Issues with TI ROM RBL
We are not entirely certain what TI's ROM RBL will do with the MT29F4G08ABAFAH4. The TI datasheet sprab41f lists MT29F4G08ABADA as a supported device in Appendix B. Its device ID is 0xDC, which is the same device ID for the MT29F4G08ABAFAH4 flash we are already using. However, the MT29F4G08ABADA device ID is not listed in the device ID table in appendix B, so the RBL would then default to using the fourth ID byte for NAND configuration.. this would then expose the 2KB versus 4KB difference between the two devices.

However... the TI flash utils for the OMAP-l138:

software-dl.ti.com/.../flash-utils-davinci.tar.gz

in file flash_utils/OMAP-L138/device_nand.c lists this:

// Table of ROM supported NAND devices
const NAND_CHIP_InfoObj DEVICE_NAND_CHIP_infoTable[] =

and in the table is the device ID 0xDC. So maybe the NAND chip would work, but one will have to set it up with the default NAND size settings. This way it will only use half of every NAND page. MT29F4G08ABAFAH4 has a 4KB page size and a 256KB block size. The default is 2KB page size and 128KB block size.

In summmary, it looks like people have had issues writing the SPL and u-boot to the NAND because of the funny OOB setup. People have had success following this:

e2e.ti.com/.../2482361

github.com/.../flashtool

./flashtool -w -s 0 --dm365-rbl --ubi /dev/mtd1 uboot_and_ubl.bin

So, not sure if this would work. But if the code from the TI flash utils is right, then the device ID of 0xDC should match and they can use half of every page. Obviously this cuts the NAND flash size in half.  After the Linux partition is loaded into DDR memory, one could have the Linux NAND driver configured to properly use all of the flash above TI's SPL, U-Boot, and Linux image partitions.

---

After further tests and all of the above, flashtool was tried, using the suggested parameters from before. It didn’t work unfortunately; the error we're seeing is "oobsize 256 not supported." Flashtool terminated after displaying this error.

In addition, we tried to modify/re-compile flashtool to by-pass this error (and another error relating 'writesize'). It still didn't work. That is, flashtool completed the writing of u-boot to NAND but the board still couldn't boot from NAND. It may work given correct modifications of flashtool. But we don't think that would be a good approach. If we can get it working, even with using half memory size for U-Boot partition, that's still a good solution.

In summary, to use the flashtool to write the SPL, u-boot and linux images to a 2k page size and 128k block size, one will have to use the flashtool in a linux environment where their nand driver is configured as a 2k page 128k block. Even if that is done, there is no guarantee this will boot because we have no way of knowing what the RBL will do since TI will not release the code.

Ideas?

Regards,
Robert

Hi, Robert, 

Please refer to this thread which uses similar part and had similar questions as yours. Hope it helps.

https://e2e.ti.com/support/processors/f/791/p/882108/3277628#3277628

Rex

Rex,

This link you sent CLEARLY SAYS **NO** 8 BIT BOOTING!! So it's a NO go.

So, are we dead in the water?

Regards,

Robert

Hi, Robert,

As the post said, 8-bit ECC is not supported.

Rex