Skip to main content
R
RBors.1
Associate II
April 23, 2021
Solved

Unable to boot from parallel NAND

  • April 23, 2021
  • 2 replies
  • 4196 views

Hello,

I'm trying the NAND boot on our STM32MP157AAB3 custom board but until today I could't make the ROM code load the tf-a image from this memory.

I'm yet able to boot from uSD (SDMMC1), eMMC (SDMMC2) and serial NOR (QUADSPI). For uSD I partitioned the device as described in wiki, for eMMC the only way I found to make the ROM code able to load the image is programming it via STM32CubeProgrammer (same procedure of uSD won't work), for NOR I wrote it from u-boot with sf commands.

Our board is equipped with Winbond W29N08GVSIAA parallel NAND, connected to the FMC default pins as stated in wiki. The NAND datasheet report all the ONFI parameters requested by the ROM code, none of the OTP is blown. I'm building tf-a, u-boot and linux kernel from the ST repos aligned to STM32MP15-ecosystem-v2.1.0 release, the dts are created starting from STM32CubeMX output with USER CODE added according to wiki.

When I boot from another device, in u-boot I'm able to detect, write and read the NAND device. Writing the tf-a image into the NAND at offset 0 does't seems to be accepted by the ROM code, trying to flash the NAND with the STM32CubeProgrammer make the tool endlessy loop (logs attached).

I also tried to download the ROM logs as explained in wiki but all the lines contain NAND tranfer errors (log attached), I make another test booting with the NAND diconnected from the board.

Can you help me pinpoint the problem here?

I'm available for any further detail.

Best regards,

Rosario

This topic has been closed for replies.
Best answer by PatrickF

Hi,

unfortunately, this sound linked to a know bug (see ES0438) on silicon Rev.B (solved in latest revision Rev.Z) which make Hamming 1-bit ECC not usable by BootROM (which is defined in ONFI byte 112).

To overcome this you should force ECC to a stronger one, e.g. BCH8 in two places:

Obviously, BootROM and uBoot ECC settings must be aligned, so this mean when you will use silicon Rev.Z in future, if you want to avoid setting OTP, you should put back uBoot to use Hamming 1-bit ECC.

Regards.

2 replies

PatrickF
PatrickFBest answer
Technical Moderator
April 23, 2021

Hi,

unfortunately, this sound linked to a know bug (see ES0438) on silicon Rev.B (solved in latest revision Rev.Z) which make Hamming 1-bit ECC not usable by BootROM (which is defined in ONFI byte 112).

To overcome this you should force ECC to a stronger one, e.g. BCH8 in two places:

Obviously, BootROM and uBoot ECC settings must be aligned, so this mean when you will use silicon Rev.Z in future, if you want to avoid setting OTP, you should put back uBoot to use Hamming 1-bit ECC.

Regards.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.NEW ! Sidekick STM32 AI agent, see here
R
RBors.1Author
Associate II
April 23, 2021

Hello Patrick,

thanks for the support.

I remebered a note in the wiki page about the ROM code flash memory boot (under the ONFI parameters table) that says that the ECC can be forced even while reading the other parameters from the ONFI. So I tried to program OTP WORD9 whith the value of 0x00018000 and the system boot correctly from NAND.

Is there any limitation in doing this?

Regards,

Rosario

PatrickF
PatrickF
Technical Moderator
April 23, 2021

Glad to see this was the issue.

You are right, no problem to leave with the OTP value you have tried, wiki is more reliable than me.

Regards.

"To help community to find solutions, please click on "Select as Best" for reply which solved your issue or answered your question."

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.NEW ! Sidekick STM32 AI agent, see here
Terms & ConditionsAccessibility statement