Urgent: Cannot boot from NAND - OTP

[JOhn1]

Problem:

After configuring the OTP pins in word 3 to the following:

- Primary boot source : SD-card

- Secondary boot source : FMC NAND

And flashing the FMC nand with TF-A `tfa-*-nand.stm32` in the first sector using `nandwrite -p /dev/mtd0 /mnt/boot/tf-a-stm32mp153c-*-nand.stm32`

I have a working booting setup using SD-card and u-boot.

I have programmed OTP in the following way:

First sense the lock register:

`fuse sense 0 0x10000003`

Validate that the lock register is 0. If not, then it is no longer possible to write the register. This is usually a sign that the boot sources have already been set.

Read the value of word `3` in bank `0`. Either it is set or not.

If it is set. Do nothing

If it is not set all `0`, Do next step

Run the sense command, this must be 0 or 0x21000000

`fuse sense 0 3`

When the sensing is complete, and it is determined that no values in OTP word 3 is set, we can proceed with programming the fuses.

We choose:

- The primary boot source to = 4 SD card.

 These belong to bits [29:27]

- The secondary boot source = 1 FMC NAND

 These belong to bits [26:24]

Because the values belong in a 32-bit word. The First nibble will be set to 0x2 and the second nibble to 0x1.

This means that the first byte will be set to 0x21.

Therefore it must be set to `0x21000000`

⚠ **Warning: This is a permanent step**

`fuse prog -y 0 3 0x21000000`

`fuse override 0 3 0x21000000`

:glasses: We then read(sense) the register to confirm that the values are indeed correctly set, confirm that the value is 0x21000000 before continuing to the next step:

`fuse sense 0 3`

`fuse read 0 3`

After programming the fuse, we must lock the register. This is to avoid unintentional and intentional changes to the boot order. This amounts to freezing the word to its final value. Otherwise you run the risk of being able to fuse other bits, and making the system unbootable.

⚠ **Warning: This is a permanent step**

`fuse prog 0 0x10000003 0x40000000`

But locking the register emitted a warning.

The system does boot from SD-card but never form nand. When i try booting withouth SD-card nothing happens.

Is it possible to get any output from the rom boot?

[PatrickF]

Hi @JOhn​ ,

Before playing with primary/secondary boot sources in OTPs, did you succeeded to boot from NAND using Boot pins = 0b11 ?

Did you use ONFI compliant FMC NAND Flash ?

Is ONFI Flash data or OTP9 related to NAND characteristics aligned with FMC Device Tree settings (in particular ECC strength) ?

In case of boot failure, you could get BootROm trace from SYSRAM using openOCD:

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_trace_analyzer#On_STM32MP15x_lines

and analyze the trace using a small Python script:

https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_trace_analyzer#On_STM32MP15x_lines_2

Regards.

[JOhn1]

Hi @[PatrickF]​

It is a custom board based on STM32mp153CAC.

Unfortunately its a production prototype, so no way to set the boot pins.

However, before getting my hands on the prototype I developed and tested the software on STM32MP157D-ev1 with daughter board. There I correctly booted from nand flash using the boot pins.

The NAND flash should be ONFI compatible. We used it in a previous design with another MPU from microchip, I guess it fetches the relevant parameters from with ONFI automatically.

The flash we use is: MICRON MT29F4G08ABADAWP

The device tree used for TF-A
 
```c
 
 
 
/dts-v1/;
 
#include <dt-bindings/pinctrl/stm32-pinfunc.h>
 
#include <dt-bindings/clock/stm32mp1-clksrc.h>
 
#include <dt-bindings/soc/st,stm32-etzpc.h>
 
#include "stm32mp15-mx.dtsi"
 
 
 
#include "stm32mp153.dtsi"
 
#include "stm32mp15xc.dtsi"
 
#include "stm32mp15xxac-pinctrl.dtsi"
 
#include "stm32mp15-ddr.dtsi"
 
 
 
/* USER CODE BEGIN includes */
 
/* USER CODE END includes */
 
 
 
/ {
 
   model = "A7pll4q";
 
   compatible = "st,stm32mp153c-itc3_cpu_a7_rev5-mx", "st,stm32mp153";
 
 
 
   memory@c0000000 {
 
      device_type = "memory";
 
      reg = <0xc0000000 0x20000000>;
 
 
 
      /* USER CODE BEGIN memory */
 
      /* USER CODE END memory */
 
   };
 
 
 
   /* USER CODE BEGIN root */
 
   /* USER CODE END root */
 
 
 
   clocks {
 
      /* USER CODE BEGIN clocks */
 
      /* USER CODE END clocks */
 
 
 
      clk_lse: clk-lse {
 
 
 
         /* USER CODE BEGIN clk_lse */
 
         /* USER CODE END clk_lse */
 
      };
 
 
 
      clk_hse: clk-hse {
 
 
 
         #clock-cells = <0>;
 
          compatible = "fixed-clock";
 
          clock-frequency = <12000000>;
 
      };
 
   };
 
 
 
   chosen {
 
      stdout-path = "serial0:115200n8";
 
   };
 
 
 
   aliases {
 
      serial0 = &uart4;
 
   };
 
 
 
}; /*root*/
 
 
 
 
 
&bsec{
 
   status = "okay";
 
   secure-status = "okay";
 
 
 
   /* USER CODE BEGIN bsec */
 
   /* USER CODE END bsec */
 
};
 
 
 
 
 
&fmc{
 
   pinctrl-names = "default";
 
   pinctrl-0 = <&fmc_pins_mx>;
 
   status = "okay";
 
 
 
   /* USER CODE BEGIN fmc */
 
   nand-controller@4,0 {
 
      status = "okay";
 
      nand@0 {
 
         reg = <0>;
 
         nand-on-flash-bbt;
 
         #address-cells = <1>;
 
         #size-cells = <1>;
 
 
 
         nand-bus-width = <8>;
 
         nand-ecc-mode = "hw";
 
         status = "okay";
 
 
 
 
 
      };
 
   };
 
   /* USER CODE END fmc */
 
};
 
 
 
&rtc{
 
   status = "okay";
 
   secure-status = "okay";
 
 
 
   /* USER CODE BEGIN rtc */
 
   /* USER CODE END rtc */
 
};
 
 
 
 
 
&sdmmc1{
 
   pinctrl-names = "default";
 
   pinctrl-0 = <&sdmmc1_pins_mx>;
 
   status = "okay";
 
 
 
};
 
 
 
 
 
&tamp{
 
   status = "okay";
 
   secure-status = "okay";
 
 
 
   /* USER CODE BEGIN tamp */
 
   /* USER CODE END tamp */
 
};
 
 
 
&uart4{
 
   pinctrl-names = "default";
 
   pinctrl-0 = <&uart4_pins_mx>;
 
   status = "okay";
 
 
 
   /* USER CODE BEGIN uart4 */
 
   /* USER CODE END uart4 */
 
};
 
 
 
&usart6{
 
   pinctrl-names = "default";
 
   pinctrl-0 = <&usart6_pins_mx>;
 
   status = "okay";
 
 
 
   /* USER CODE BEGIN usart6 */
 
   /* USER CODE END usart6 */
 
};
 
 
 
/* USER CODE BEGIN addons */
 
/* USER CODE END addons */
 
 
 
 
 
```

I have redacted portions of the device tree to fit in the post.

I will take a look at the links you send me, thank you!

BR John

[JOhn1]

Furthermore, I have access to the nand via both u-boot and Linux, that is the reason I can write and read from the NAND flash using user-space tools.

[PatrickF · Accepted solution]

Please check your NAND datasheet ONFI parameters.

Your should have in mind that

• BootROM uses ONFI to determine NAND characteristics (especially ECC strenght)
• uBoot/Linux use Device tree parameters

Usual pitfall is to use different ECC used during uBoot/Linux flashing (from DT) than detected by BootROM during boot (from ONFI values) which mean the BootROM always fails due to uncorrectable errors (due to differend ECC).

MT29F4G08ABADAWP ONFI parameter define 4 bits ECC (byte 112 = 04h).

Then your DT must have:

nand-ecc-strength = <4>;

Regards.

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[JOhn1]

@PatrickF​ 

Thank you, this solved the issue.

I can now boot TF-A from the nand-flash, with no problems.