stm32mp135D fails to find rootfs when booting from SD Card

[robo1340]

So first of all I'm working on creating a yocto image for this board.

https://www.seeedstudio.com/Odyssey-MP135D-eMMC-p-5728.html

My end goal is to create a meta-layer with an easy to follow yocto quick start guide for this board similar to the one Seeed Studio has for the stm32mp157 variant of their dev board here:

https://github.com/Seeed-Studio/meta-st-odyssey/tree/master

I'm not associated with Seeed studio, I'm just doing it because it relates to one of my current projects and think something like this would make this board more useful and approachable.

I started by following this guide to get my yocto environment set up to use st's latest branch (mickledore).

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

Next I patched the linux-stm32mp, optee-os-stm32mp, tf-a-stm32mp, and u-boot-stm32mp recipes to contain Seeed studio's device trees for the board located here.

https://github.com/Seeed-Studio/stm32mp1-manifest

There were various issues to work out getting arm trusted firmware, optee, and then finally U-boot to work, but now I'm finally at the point where I can finally get Uboot to start the linux image. It gets to this point, then apparently hangs after failing to find the rootfs partition at /dev/disk/by-partuuid/e91c4e10... (Full boot log attached)

Starting systemd-udevd version 253.1^
[ 5.130263] stm32-dwmac 5800a000.eth1 end0: renamed from eth0
root '/dev/disk/by-partuuid/e91c4e10-16e6-4c0e-bd0e-77becf4a3582' doesn't exist or does not contain a /dev.

[ 13.933334] mmci-pl18x 58005000.mmc: Got CD GPIO
[ 13.958693] stm32-dwmac 5800e000.eth2: IRQ eth_wake_irq not found
[ 13.971303] stm32-dwmac 5800e000.eth2: IRQ eth_lpi not found
[ 13.976228] stm32-dwmac 5800e000.eth2: PTP uses main clock
[ 13.981186] stm32-dwmac 5800e000.eth2: Unable to parse OF data
[ 13.987540] platform 49000000.usb-otg: deferred probe pending
[ 13.992620] i2c 1-005d: deferred probe pending
[ 13.997289] amba 58005000.mmc: deferred probe pending
[ 14.002150] amba 58007000.mmc: deferred probe pending
[ 14.007263] platform 5800d000.usbh-ehci: deferred probe pending
[ 14.013148] platform 5800c000.usbh-ohci: deferred probe pending
[ 14.019006] platform 5a006000.usbphyc: deferred probe pending
[ 14.024780] platform 5a001000.display-controller: deferred probe pending
[ 14.031441] platform panel-rgb: deferred probe pending
[ 14.036606] platform 5800e000.eth2: deferred probe pending

Googling around on this issue and within this forum seems to indicate that there is either a problem with my SDMMC settings in the device tree or an issue with the stpmic configuration in the device tree. I have had no luck getting much farther than that though.

One thing I should note is that I can find the rootfs partition in a U-boot terminal and can ls its files, so from the perspective of U-boot everything looks fine.

STM32MP> mmc part

Partition Map for MMC device 0 -- Partition Type: EFI

Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00000022 0x00000221 "fsbl1"
attrs: 0x0000000000000000
type: 8da63339-0007-60c0-c436-083ac8230908
guid: e12118b4-5b5c-4371-98f1-3af54d986803
2 0x00000222 0x00000421 "fsbl2"
attrs: 0x0000000000000000
type: 8da63339-0007-60c0-c436-083ac8230908
guid: dfab66f9-5e17-48ad-b263-cb39a86bafde
3 0x00000422 0x00000621 "metadata1"
attrs: 0x0000000000000000
type: 8a7a84a0-8387-40f6-ab41-a8b9a5a60d23
guid: 37a8dba8-2c67-4f6f-b247-637cd8a62578
4 0x00000622 0x00000821 "metadata2"
attrs: 0x0000000000000000
type: 8a7a84a0-8387-40f6-ab41-a8b9a5a60d23
guid: 24da0772-0374-4fa4-a62b-7d7c34a1b290
5 0x00000822 0x00002821 "fip-a"
attrs: 0x0000000000000000
type: 19d5df83-11b0-457b-be2c-7559c13142a5
guid: 4fd84c93-54ef-463f-a7ef-ae25ff887087
6 0x00002822 0x00004821 "fip-b"
attrs: 0x0000000000000000
type: 19d5df83-11b0-457b-be2c-7559c13142a5
guid: 09c54952-d5bf-45af-acee-335303766fb3
7 0x00004822 0x00004c21 "u-boot-env"
attrs: 0x0000000000000000
type: 3de21764-95bd-54bd-a5c3-4abe786f38a8
type: u-boot-env
guid: 56a415d6-e074-4502-80c5-a01383fa372b
8 0x00004c22 0x00024c21 "bootfs"
attrs: 0x0000000000000004
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
type: linux
guid: 22156b70-857b-4fd1-9340-595618bebb21
9 0x00024c22 0x0002cc21 "vendorfs"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
type: linux
guid: 377f7000-28b3-4e38-841e-9f5f8eb695e6
10 0x0002cc22 0x0082cc21 "rootfs"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
type: linux
guid: e91c4e10-16e6-4c0e-bd0e-77becf4a3582
11 0x0082cc22 0x009fffde "userfs"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
type: linux
guid: 0496807e-0a1e-4959-a997-2c63037a06a4
STM32MP> ls mmc 0:A dev
<DIR> 4096 .
<DIR> 4096 ..
STM32MP> ls mmc 0:A
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 bin
<DIR> 4096 boot
<DIR> 4096 dev
<DIR> 4096 etc
<DIR> 4096 home
<DIR> 4096 lib
<DIR> 4096 media
<DIR> 4096 mnt
<DIR> 4096 proc
<DIR> 4096 run
<DIR> 4096 sbin
<DIR> 4096 srv
<DIR> 4096 sys
<DIR> 4096 tmp
<DIR> 4096 usr
<DIR> 4096 var
<DIR> 4096 vendor
STM32MP>

Another thing I have noticed is that there is no stpmic entries in the U-boot or linux device tree files for the stm32mp135 (my odyssey board or st's stm32mp135f dev board) however there are stpmic entries in the U-boot and linux device tree files for all stm32mp15* examples I have found. 

I have looked over the stpmic entries in the tf and optee device tree files for the stm32mp135d-odyssey and found no glaring issues. I did see a guy post something about about needing to add interrupts to it here: https://community.st.com/t5/stm32-mpus-products/stm32mp151aac-custom-board-kernel-not-starting/td-p/587192

So I tried adding it to my tf and optee device tree files, however it had no affect on my log output.

Thanks in advance for any insights anyone here can provide.

[robo1340]

Update:

So I found out why there is no reference to the stpmic in any of the stm32mp13x dts files.

From ST's SCMI wiki page:

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

STM32MP13x lines More info.png software deliveries embed OP-TEE in the secure world. OP-TEE exposes SCMI services for the clock, a reset controller, voltage regulator resources, and a performance management service for CPU DVFS support.

STM32MP15x lines More info.png software deliveries embed OP-TEE in the secure world. OP-TEE exposes SCMI services for clock and reset controller resources.

So it looks like Optee controls more hardware resources on the STM32mp13x, which is weird since I originally thought the BSP's for the 15x and 13x MPU's would be the same just with the latter having one less core.

Seeing that, and a few other forum posts, I decided to increase my optee log level in optee-os-stm32mp/mk/config.mk

CFG_TEE_CORE_LOG_LEVEL ?= 4

Unfortunately, this didn't yield any additional log output though. At this point I'm still grasping at straws on what could be causing the kernel to not find the rootfs.

[robo1340 · Accepted solution]

Very interesting, it appears as though the cause of the problem was the brand of SD Card I was using.

The boot hangs with Kingston 16GB and SanDisk Edge 16GB cards. I thought I had previous ruled this out because the stm32mp135f-dk board st makes works fine with those cards. Apparently the stm32mp135d-odyssey is a little pickier though.

So far, it has only booted with a SanDisk Ultra plus 16GB and 64GB card. This fixes the immediate issue. I will update the thread when my layer is finished.