Whether the size of FSBL is limited to one block of NAND, and shell we tailor the FSBL(tf-a) within 128KB to fit MT29F4G08，which block size is 128KB?

[SunnyGeGe]

Hello, we are using a NAND Flash MT29F4G08 as boot device, which block size is 128KB. We program the 245KB size of FSBL(tf-a.stm32) to it with cubeProgrammer successfully, it does not boot up. When we replace the NAND Flash with MT29F8G08 as boot device, which block size is 256KB, and program the same FSBL(tf-a.stm32) with cubeProgrammer successfully, it boots up.  So, I want to know whether the size of FSBL is limited to one block of NAND, and shell we tailor the FSBL(tf-a) within 128KB to fit MT29F4G08?  

[AntonioST]

I have checked the datasheet from Micron, and both MT29F4G08 and MT29F8G08 have the block size of 128k. Could you please provide the full part number of the two NAND?

Also, can you provide the flash layout? I mean, the content of the file FlashLayout_XXXX.tsv ?

[SunnyGeGe]

Thank you for your quick reply, the following pictures are datasheets of the two NAND, please check them.

Sorry, the full name is MT29F8G08ABABAWP-ITC , and it's block size is 512KB,

The full name of MT29F4G08 is MT29F4G08ABADAWP-ITD , and it's block size is 128KB.

The content of FlashLayout_***.tsv is shown blow, the two types of NAND can all be programmed successfully, but only the board with MT29F8G08ABABAWP-ITC works:

#Opt Id Name Type IP Offset Binary

- 0x01 fsbl1-boot Binary none 0x0 tf-a-stm32mp157c-dk2-trusted.stm32

- 0x03 ssbl-boot Binary none 0x0 u-boot-stm32mp157c-dk2-trusted.stm32

P 0x04 fsbl1 Binary(2) nand0 0x00000000 tf-a-stm32mp157c-dk2-trusted.stm32

P 0x06 ssbl Binary nand0 0x00200000 u-boot-stm32mp157c-dk2-trusted.stm32

P 0x07 ssbl2 Binary nand0 0x00400000 u-boot-stm32mp157c-dk2-trusted.stm32

P 0x21 ubifs System nand0 0x00600000 st-example-image-qt-openstlinux-eglfs-stm32mp1_nand_4_256_multivolume.ubi

[AntonioST · Accepted solution]

The issue should be caused by incorrect ECC.

The NAND 4G specifies in the parameter table that it supports only 4 bit ECC. The bootrom of STM32MP1 read and use the info from parameter table, so it expects the NAND to be programmed with 4 bit ECC.

The default behavior of U-Boot is instead to check for the most advanced ECC that can fit in the spare bits. On this flash it will use 8 bits ECC, causing a mismatch.

To fix the issue, you should recompile U-Boot adding the following lines in the device tree :

&nand {

nand-ecc-strength = <4>;

nand-ecc-step-size = <512>;

};

Then, of course, use this U-Boot for the flashing operations (second line in the tsv file)

More info on the devicetree properties are in the kernel file Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt

Not present in U-Boot documentation yet.

[SunnyGeGe]

Thank you for your wonderful reply, it works right now! :thumbs_up: :D

[AntonioST]

My proposal about changing U-Boot device tree is not the only option to solve this problem.

Plus, having to manage two U-Boot for different NAND is a complication, and it's also better using higher ECC if the NAND can support it, even if it's not "proposed" in the NAND parameter table.

It is possible to force the bootrom to use a specific ECC, overriding the value specified in the NAND parameter table. This method is in place to bypass incorrect parameter table, but it will work in this case too.

https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#OTP_WORD_9_-_NAND_configuration

By setting only the bits 17-15 to value "3" we can force the bootrom to ignore "only" the ECC value in the parameter table and always use 8 bit ECC. The other values from the parameter table will still be respected.

Please be aware that these are OTP (one time programmable) so once set you can not revert them.