2025-11-06 2:33 AM - last edited on 2025-11-06 2:55 AM by Andrew Neil
Hello ST team,
I’m working on a custom board based on STM32MP135F SoC, with GigaDevice GD5F4GM8UExxG (512 MiB SPI-NAND) connected on SPI1 interface.
I’ve successfully integrated this NAND flash in U-Boot and Linux (Yocto build), but the board fails to boot directly from SPI-NAND. Please find the attached text file which is having the all changes.
When booting from SD card, I can probe, erase, and write to the SPI-NAND successfully — data can be read back and verified. please check below logs:
stm32mp13x:~# dmesg | grep spi
[ 0.708654] spi-nand spi0.0: GigaDevice SPI NAND was found.
[ 0.708678] spi-nand spi0.0: 512 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
[ 0.708944] 9 fixed-partitions partitions found on MTD device spi-nand0
[ 0.708962] Creating 9 MTD partitions on "spi-nand0":
I can able to flash the image to spi-nand flash successfully after configuring in the uboot and tfa.
However, when I configure boot from QSPI-NAND, the boot ROM and TF-A logs indicate all blocks are bad. below is the log while booting from spi-nand
Exception mode=0x00000016 at: 0x2fff764c
NOTICE: CPU: STM32MP135D Rev.Y
NOTICE: Model: STMicroelectronics STM32MP135F-DK Discovery Board
INFO: Reset reason (0x34):
INFO: Pad Reset from NRST
INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe0000
INFO: FCONF: Reading firmware configuration information for: stm32mp_fuse
INFO: FCONF: Reading firmware configuration information for: stm32mp_io
INFO: Using SPI NAND
INFO: Instance 1
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.10-stm32mp1-r2.0(debug):MYD-YF13X_2.10_V2.0.0_RC_20250926(e6a6fd49)
NOTICE: BL2: Built : 06:09:33, Aug 11 2025
WARNING: Block 8 is bad
WARNING: Block 9 is bad
WARNING: Block 10 is bad
WARNING: Block 11 is bad
WARNING: Block 12 is bad
WARNING: Block 13 is bad
WARNING: Block 14 is bad
.....
WARNING: Block 2044 is bad
WARNING: Block 2045 is bad
WARNING: Block 2046 is bad
WARNING: Block 2047 is bad
ERROR: mtd_add_extra_offset: Seek error -5
WARNING: Failed to load image id id=12 (-5)
WARNING: loading of FWU-Metadata failed, using Bkup-FWU-Metadata
ASSERT: drivers/io/io_mtd.c:140
Exception mode=0x00000016 at: 0x2fff764c
SoC: STM32MP135F
Flash: GigaDevice GD5F4GM8UExxG (512 MiB, 2048 B page, 128 KiB block)
Interface: SPI1 @ 66 MHz (tried also 20 MHz, 104 MHz)
Boot source: SPI-NAND
# for 512 MiB GD5F4GM8UExxG
MKUBIFS_ARGS_nand_2_128_512 = "--min-io-size 2048 --leb-size 126976 --max-leb-cnt 4096"
UBINIZE_ARGS_nand_2_128_512 = "--min-io-size 2048 --peb-size 128KiB"
EXTRA_UBIFS_SIZE_nand_2_128_512 = "2816"
Could you please advise on:
Whether GD5F4GM8UExxG is officially supported by STM32MP135 boot ROM / TF-A SPI-NAND driver?
If the bad block scan mechanism or ECC layout needs adaptation for this device?
Whether TF-A expects any specific page / block geometry alignment for the bootloader region (fsbl1, fip-a1, etc.)?
Logs and configurations can be provided in full if needed.
Thanks,
Ganesh K
2025-11-06 2:43 AM
Hi,
Did you setup correct parameters in OTP (mandatory for serial NAND) ?
https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#nand_param_stored_in_otp
Regards.
2025-11-06 2:51 AM
Hi PatrickF,
Thanks for your quick response.
Yes, the original STM32MP135 evaluation board comes with the default 256 MB SPI-NAND (Micron MT29F2G01ABA), and the board was booting successfully from it.
For my evaluation, I have replaced this device with a 512 MB GigaDevice SPI-NAND (GD5F4GM8UExxG) on the same SPI interface, keeping the same hardware connections and pin configuration.
Since the board was already booting from SPI-NAND in its default configuration, I assumed the OTP parameters were already programmed for SPI-NAND boot.
Could you please confirm whether I still need to update the OTP with NAND parameters again when changing to a different SPI-NAND device (even if the interface and basic geometry — 2 KiB page, 128 KiB block — remain the same)?
If yes, could you please clarify:
Which exact OTP words must be updated for SPI-NAND boot configuration?
Whether the parameters (like manufacturer ID, page/block size) must match the new flash’s ID?
And if TF-A or U-Boot can override these OTP settings during initialization?
Thanks & Regards,
Ganesh K
2025-11-06 4:47 AM
Hi,
you cannot update OTP one programmed (OTP stand for One Time Programming).
You might try to dump existing OTP on the IC to figure out if this is suitable for your memory according to wiki information. The Micron might have specific plane selection.
As you put a log from TF-A (starting with "NOTICE: xxxxx") , I think the BOOTROM was able to load Serial-NAND FSBL. So it might be something else who fail inside TF-A (check differences Vs Micron).
Regards.