2023-09-17 06:07 PM
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?
Solved! Go to Solution.
2023-09-19 04:19 AM - edited 2023-09-19 04:52 AM
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.
2023-09-18 05:07 PM - edited 2023-09-18 05:27 PM
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.
2023-09-18 05:25 PM
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.
2023-09-18 06:25 PM - edited 2023-09-18 06:46 PM
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.
2023-09-19 02:31 AM
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
2023-09-19 04:19 AM - edited 2023-09-19 04:52 AM
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.
2023-09-19 09:55 PM
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