STM32MP15 ECO 5.0.0 STM32MP151 boots from USB but not eMMC

[michiel.tjampens]

Still trying to get a custom board with a STM32MP151AAC and 512MB ram to boot from eMMC. Switched to using this guide.

After various new issues (one of them being this), I managed to bitbake a set that I'm able to fully program with CubeProgrammer.

However, that was the only good news about that. The board doesn't boot from eMMC, instead i get the following output.

NOTICE: Model: STMicroelectronics custom STM32CubeMX board - openstlinux-6.1-yocto-mickledore-mp1-v23.06.21
INFO: PMIC version = 0x21
INFO: Reset reason (0x15):
INFO: Power-on Reset (rst_por)
INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe2000
INFO: FCONF: Reading firmware configuration information for: stm32mp_io
INFO: Using EMMC
INFO: Instance 2
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.8-stm32mp1-r1.0(debug):lts-v2.8.6-dirty(ff0bd5f9)
NOTICE: BL2: Built : 17:57:15, Apr 21 2023
WARNING: Failed to access image id=3 (-2)
ERROR: Unable to find a metadata partition
WARNING: Failed to set reference to image id=12 (-2)
WARNING: loading of FWU-Metadata failed, using Bkup-FWU-Metadata
WARNING: Failed to access image id=3 (-2)
ERROR: Unable to find a metadata partition
WARNING: Failed to set reference to image id=13 (-2)
ERROR: loading of Bkup-FWU-Metadata failed
PANIC at PC : 0x2ffea1fb

I think it means it doesn't find the eMMC? But it did program fine...

The mmc part in the tf-a dts looks like this.

/* For SD Card */
&sdmmc1{
	pinctrl-names = "default";
	pinctrl-0 = <&sdmmc1_pins_mx>;
	status = "okay";

	/* USER CODE BEGIN sdmmc1 */
	disable-wp;
	st,neg-edge;
	bus-width = <4>;
	vmmc-supply = <&v3v3>;
	/* USER CODE END sdmmc1 */
};
/* eMMC storage */
&sdmmc2{
	pinctrl-names = "default";
	pinctrl-0 = <&sdmmc2_pins_mx>;
	status = "okay";

	/* USER CODE BEGIN sdmmc2 */
	non-removable;
	no-sd;
	no-sdio;
	st,neg-edge;
	bus-width = <8>;
	vmmc-supply = <&v3v3>;
	vqmmc-supply = <&v3v3>;
	mmc-ddr-3_3v;
	/* USER CODE END sdmmc2 */
};

Only thing I can think of is that the processor looks at sdmmc1 instead of sdmmc2. But haven't found any way to specify that yet. But given that 'Instance 2' is the console output, that's not it probably?

 

[debugging]

Did you build .TF-A .stm32 for USB boot  ? it looks like the layout is not correct .Did you have your CubeProgrammer partition/layout for USB/EMMC ? FIP does not have an entry with ID  3. so perhaps this id 3 could be EMMC partition 3 (FIP) that is next after ID 1 (TF-A) ? Meta data is id 6 & 7,

https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout

As an non-ST employee,  happy to see the DT problem was not unique and helped someone to get through one of the many ECO 5.0.0 roadblocks. I am still  stuck for days on the AXI 480, u-boot booting  from SD card,  which is also not a unique error, but zero replies on the community to help to find clues. Many days and night have gone to bring up as simple basic configuration with just an SD card and a UART.

Perhaps ST could make an attempt to build ECO 5.0.0 on custom boards instead ST's own DK/EV's (and not use just the  Makefiles.sdk) to bump into issues and  gain experience to be able to advise what could be wrong. Perhaps I am mistaken, but it looks like the intent for the community was only for community members to not have an  expectation for support from ST (yes, we did read the - on the fly updated - WIKI's)

it seems a 5.0.1 is coming, maybe that extra 0.0.1 will help. https://community.st.com/t5/stm32-mpus-products/bug-in-yocto-compiler-bug-in-stm32mp1-ecosystem-v5-0-0/td-p/57713 ST is probably aware of many issues, but there isn't a known issue list for ECO 5.0.0.

[michiel.tjampens]

The output is what I got when using everything build with bitbake according to that link. So I assume atleast that is correct. If the TF-A isn't build for USB then an error is raised (after that I did a clean between emmc and usb build)

This is how the tsv looks (tios is the name of the project).

#Opt	Id	Name	Type	IP	Offset	Binary
-	0x01	fsbl-boot	Binary		none	0x0	arm-trusted-firmware/tf-a-stm32mp151a-tios-mx-usb.stm32
-	0x03	fip-boot	FIP			none	0x0	fip/fip-stm32mp151a-tios-mx-optee.bin
P	0x04	fsbl1		Binary		mmc1	boot1	arm-trusted-firmware/tf-a-stm32mp151a-tios-mx-emmc.stm32
P	0x05	fsbl2		Binary		mmc1	boot2	arm-trusted-firmware/tf-a-stm32mp151a-tios-mx-emmc.stm32
P	0x06	metadata1	FWU_MDATA	mmc1	0x00080000	arm-trusted-firmware/metadata.bin
P	0x07	metadata2	FWU_MDATA	mmc1	0x00100000	arm-trusted-firmware/metadata.bin
P	0x08	fip-a		FIP			mmc1	0x00180000	fip/fip-stm32mp151a-tios-mx-optee.bin
PED	0x09	fip-b		FIP			mmc1	0x00580000	none
PED	0x0A	u-boot-env	ENV			mmc1	0x00980000	none
P	0x10	bootfs		System		mmc1	0x00A00000	st-image-bootfs-openstlinux-weston-stm32mp1-tios.ext4
P	0x11	vendorfs	FileSystem	mmc1	0x04A00000	st-image-vendorfs-openstlinux-weston-stm32mp1-tios.ext4
P	0x12	rootfs		FileSystem	mmc1	0x05A00000	st-image-core-openstlinux-weston-stm32mp1-tios.ext4
P	0x13	userfs		FileSystem	mmc1	0xC5A00000	st-image-userfs-openstlinux-weston-stm32mp1-tios.ext4

Also made by bitbake. I've compared that to the examples I could find and didn't notice anything off.

I'm indeed noticing that for every issue I encounter you have opened a thread about it... So something is certainly wrong with the documentation. They should edit the last pages of "Lab-MP15_FromPartNumber_To_BasicDeviceTree_with_CubeMx"  because now it does more bad than good.

I've been trying to write my own guides, but given that I haven't been able to get a working system...

I think i've hit a similar roadblock as you now, atleast before I had some idea about where to look. Who knows, maybe if I fix this one I'll have the AXI 480 issue. It would follow the current pattern...

Back to the current issue, I tried the same thing but with all the boot stages compiled manually with 'make'. Only thing I used from the bitbake is the metadata.bin, haven't figured out how to build that yet. With those files, the output is slightly different.

NOTICE: Model: STMicroelectronics custom STM32CubeMX board - openstlinux-6.1-yocto-mickledore-mp1-v23.06.21
NOTICE: BL2: v2.8-stm32mp1-r1.0(release):v2.8-stm32mp-r1(230b4d84)
NOTICE: BL2: Built : 23:03:15, Sep 18 2023
ERROR: Could NOT find the fip partition!
ERROR: BL2: Failure in pre image load handling (-2)

So pretty much the same error message but just giving up earlier.

[debugging]

I compared the layout with that I have for USB boot and looks ok. Also found this missing: how to build metadata.bin. I wanted to create a post about this, though I found the metadata it in the Makefile.sdk of TF-A, in the TF-A root:

$ TF_A_METADATA_JSON=plat/st/stm32mp1/default_metadata.json
$ tools/fwu_gen_metadata/fwumd_tool.py jsonparse $TF_A_METADATA_JSON -b build/stm32mp1/metadata.bin

But it's output only one metadata.bin while the ECO generates one for each boot device (sd, emmc etc..). it's a python script.I used the .bin to copy to my SD card. I could not find a spec or a tools to list the contents of metadata.bin either or any information how to verify it's contents  (and such validation  information counts for many outputs of ECO 5.0.0).

This seems all because, again, the whole ECO is made for ST board.    Just take a look at conf.mk for OPTEE and its a spaghetti of ST board "flavors" dependencies. I am not sure my problem may be related to that . Maybe add my own board there.   (no HOW-TO WIKI for that).

Perhaps wait for ECO 6.0 is better until ST has worked out all the quirks  and releases a more "open ECO system" that allows for easy add on of non-ST board. YMMV. Just IMHO.

Personally I do not to rely on those .sdk and other high level build scripts until I understand the whole underlying build process. I just use make with the command line options.  I can't find see the  cause (yet) of your current EMMC boot issue.  It seems stuck at TF-A. Perhaps you can edit TF-A source code and add some "NOTICE debug messages.  find the text

Could NOT find the fip partition!

and then debug backwards. That is how I found the DT voltage issue by debugging the source code. The default error messages do not explain  much.

Lab-MP15_FromPartNumber_To_BasicDeviceTree_with_CubeMx" for me was the big missing "WIKI" and a life saver to understand how to get the DT's done, even though there are some issues with that document.

[michiel.tjampens]

Thanks, I'll look into that bit about metadata.bin. Might indeed be useful to go through the makefile.sdk file to see what they actually do.

Like you suggested a couple threads ago, I stopped using the makefile.sdk's. Still using the ST github's but might try the original ones just to see if the issues persist.

Well, you'd think that if the board houses a ST processor, It's 'a ST board'. But the main reason to use the ECO is to have a base of components that work together (i think).

Regarding the TF-A issue, still not sure if it's something wrong/missing in the DT or something done wrong during flashing. Only thing i'm certain it's not a hardware issue and when booting through USB, I can acces the eMMC in U-Boot just fine.

STM32MP> mmc dev 1 0
switch to partitions #0, OK
mmc1(part 0) is current device

STM32MP> mmc info
Device: STM32 SD/MMC
Manufacturer ID: 1
OEM: 0
Name: S40004 
Bus Speed: 52000000
Mode: MMC High Speed (52MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 4-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected

[michiel.tjampens]

Found the cause, it was indeed in the DT file for TF-A.

I had copy pasted the piece below from the DT file made by the manufacturer of the module I'm using.

 

	/* USER CODE BEGIN sdmmc2 */
	non-removable;
	no-sd;
	no-sdio;
	st,neg-edge;
	bus-width = <8>;
	vmmc-supply = <&v3v3>;
	vqmmc-supply = <&v3v3>;
	mmc-ddr-3_3v;
	/* USER CODE END sdmmc2 */

 

I had fixed the buswidth from 8 to a 4 in the u-boot DT etc but not in the TF-A. That's probably the reason that programming works (because that's done by u-boot) but booting doesn't.

As usual, one issue turned in another. Now it's stuck at 'starting kernel'. Which means I've gone full circle.

 

 

[debugging]

I read that TF-A, OPTEE and U-boot use 1 bit SD card I/O. Actually I proved that by having one data line GPIO wrongly configured in CubeMX and it still booted. Thanks for the confirmation EMMC uses the full 8 bit.  I assumed you already had that  configured for SDMMC2 in CubeMX