Information of SDMMC1 boot commands order

[DMårt]

My goal is to use USART6 as debug output because I haven't route the dedicated BootROM pins of the USART2.

Anyway! It seems that the BootROM is trying to read my SD card. 

First sequence:

CMD and CLK of SDMMC1 seems to be talking to the SD card in a very low speed. Here I'm talking about kHz. I don't know what they are saying. The signals are perfectly square waves.

Second sequence:

Suddenly the CLK become a fast sine wave. I still don't know the frequency, but it's defently much faster than the first sequence. Now, the D0 is a digital input of BootROM. This D0 looks like a sword shaped signal. I don't know if it's my configure at my osciloscope that cause this view.

After the second sequence as ended. There are no more data passing between the SD card and MP257. The clock is still running at the same frequency.

I don't know if the TF-A firmware has been read or not. I haven't tested the USART6.

Question:

Where can I find the commands/data that are passing between the SD card and the MP257? I'm guessing that the first sequence is CMD0.

I want to know every byte. Is this information included in the MP wiki?

Note:

VDD_SDCARD and VDDIO_SDCARD comes from LDO2 and are fixed at 3.3V. I haven't modify/remove the UHS-I speed from TF-A at the &sdmmc1 node yet 

[PatrickF]

Hi,

the SD-Card transaction start at about 400kHz, and once the card is correctly identified, clock is changed to 16MHz. This is quite low frequency and must show as clean on your oscilloscope.
See some details at https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#Boot_from_SD_card).

For more details of the whole SD-Card identification sequence and transactions, I recommend you to refer to the "SD Specifications Part 1 Physical Layer Specification".

There is two ways to verify if BootROM launched the loaded FSBL (with a valid header content, note that header version format for STM32MP25 is different than STM32MP15).

• PH4 should be high-z (Refer to AN5489 "Debug LED" for details)
• USB is not in DFU (which is the default fallback in case of FSBL not detected from selected boot flash)

In case USB is back in DFU (most case when FSBL failed to loaf), to help understanding what's going wrong, you could load with USB+CubeProg a small SW to dump and analyze Boot traces using https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_trace_analyzer (binary already provided for many UARTs, and code could be recompiled to any UART_TX pins without major changes).

https://github.com/STMicroelectronics/wiki-stm32mp-addons/tree/6.1.0/MP2RomTracesDump

For STM32MP23 or STM32MP25:
- MP2ROMtracesdump_USART2_PA4: traces output on USART2 using PA4 GPIO pin
- MP2ROMtracesdump_UART4_PH7: traces output on UART4 using PH7 GPIO pin
- MP2ROMtracesdump_UART5_PG9: traces output on UART5 using PG9 GPIO pin
- MP2ROMtracesdump_USART6_PF13: traces output on USART6 using PF13 GPIO pin
- MP2ROMtracesdump_UART7_PH4: traces output on UART7 using PH4 GPIO pin

 Regards.

[DMårt]

Hi @PatrickF 

Yes. It's correct that the CLK changes from 400 kHz to 16 MHz. It's my osciloscope that has bad tuning.

I didn't know that I could read debug messages from my USART6 PH13 pin! Thanks.

By the way! FSBL is the TF-A. From the Wiki of MP2.

Among other things, the first stage bootloader (FSBL) initializes (part of) the clock tree and the external RAM controller. Finally, the FSBL loads the second-stage bootloader (SSBL) into the external RAM and jumps to it.
The Trusted Firmware-A (TF-A BL2) is FSBL for Cortex-A developed by TrustedFirmware.org community.

 So, if TF-A is loaded, e.g FSBL. Couldn't I just select the USART6 as the debug output then?