Board stops booting after udev start

Embedded Linux Discussions
, ,
1

I’ve made a bare minimum board using this. Because the software provided by the manufacturer is fairly old (kernel 5.4) I’ve been trying to update this to 6.x. Lets just say it was a fairly bumpy ride to get where I am now.

I’ve summarized the instructions found into a couple of documents. I had split those out in different links but because I’m new I can only post two per post so here is one that points to a github folder containing all of them. This contains md files starting with ‘build_’ about how I did the builds and one called troubleshooting.md that list all of the issues I’ve encountered so far but now I’m stuck on the latest ones.

The board manages to go through all the boot stages but then stops after getting to The main one is that the kernel boot stops after starting udev because it somewhow doesn’t find the rootfs partition.

Starting systemd-udevd version 253.1^
root '/dev/disk/by-partuuid/491f6117-415d-4f53-88c9-6e0de54deac6' doesn't exist or does not contain a /dev.

I’ve verified in u-boot that the partition indeed exists and contains a /dev. That /dev however doesn’t contain a disk subfolder. The other odd thing was that the rootfs wasn’t resized like it’s supposed to.
Turned on any sort of debugging I could, but provided more questions than answers.
Like is it normal that this part is repeating?

Loading Environment from MMC... PLL3_R clock is the parent SDMMC12 of clk id 119
id=18 clock = bebc200 : 200000 kHz
stm32mp1_clk rcc@50000000: computed rate for id clock 119 is 200000000 (parent is PLL3_R)
PLL3_R clock is the parent SDMMC12 of clk id 119
id=18 clock = bebc200 : 200000 kHz
stm32mp1_clk rcc@50000000: computed rate for id clock 119 is 200000000 (parent is PLL3_R)
PLL3_R clock is the parent SDMMC12 of clk id 119
id=18 clock = bebc200 : 200000 kHz
stm32mp1_clk rcc@50000000: computed rate for id clock 119 is 200000000 (parent is PLL3_R)
PLL3_R clock is the parent SDMMC12 of clk id 119
id=18 clock = bebc200 : 200000 kHz
stm32mp1_clk rcc@50000000: computed rate for id clock 119 is 200000000 (parent is PLL3_R)
PLL3_R clock is the parent SDMMC12 of clk id 119
id=18 clock = bebc200 : 200000 kHz
stm32mp1_clk rcc@50000000: computed rate for id clock 119 is 200000000 (parent is PLL3_R)
PLL3_R clock is the parent SDMMC12 of clk id 119
id=18 clock = bebc200 : 200000 kHz
stm32mp1_clk rcc@50000000: computed rate for id clock 119 is 200000000 (parent is PLL3_R)
OK

So I’m pretty stumped as to where i should actually start digging. Given that it can’t find the rootfs (and thus the udev rules) it must be something in the kernel? Or an error in the DT file?
I can’t use the guide on the forum because it’s not a dk nor the stm32mp157 family.
Any tips?

2

I’ve got one on order, didn’t realize we added them as MarketPlace… Can you share the full boot log, does it help if you hard-code /dev/mmcblkXpY?

Regards,

3

Euh, the modules requires some kind of baseboard, so unsure if ordering one will be useful.
Attached is the full log with both optee and u-boot debug enabled.
boot.log (272.8 KB)

Yes, tried changing that line to mmcblk and changed partuid to uuid, but didn’t make a difference. For some reason nothing about that hardware seems to be mentioned in the /dev/ folder. But couldn’t figure out which process is supposed to do that.

4

Yeap, got this one… https://www.digikey.com/en/products/detail/myir-tech-limited/MYD-YA157C-V3-4E512D-65-C/16680808

Yuck, this isn’t good here:

root '/dev/disk/by-partuuid/491f6117-415d-4f53-88c9-6e0de54deac6' doesn't exist or does not contain a /dev.

F/TC:? 1 invoke_command:63 rng.pta command 0 ptypes 0x7
F/TC:0 1 __clk_enable:1174 Clock 124 has been enabled
F/TC:0 1 __clk_disable:1187 Clock 124 has been disabled
[   15.849718] amba 58005000.mmc: deferred probe pending
[   15.853412] amba 58007000.mmc: deferred probe pending

So MMC is still not up (deferred probe pending), it’s either waiting for pinmux, dma, or even something else…

Regards,

5

Hm, well issue with that one might be that it’s a stm32mp157 instead of mp151. I’ve noticed this makes a difference in the devicetree and found atleast one issue because of that in the device tree’s from Myir (mmc bandwith is 8 bits on the 157 but 4 on the 151, their files don’t make a distinction).

Regarding mmc not being up.
If that’s the case, how did it manage to load the kernel?

6

For this architecture, u-boot initializes and loads files off of MMC/microSD, then we jump from u-boot into the kernel, where things get re-initialized again.

Regards,

7

Ah, good to know.
The device tree for u-boot and kernel are the same, so odd that it works once but not twice.

8

So I tried adding things that are in the Myir dts but not the cubemx created one. After a lot of trial and error, turns out that the following three missing lines were the cause:

interrupts-extended = <&exti 55 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <2>;

If those aren’t inside the pmic: stpmic@33 node, the above issues occur…
No idea on the why that everything seems to stop working (deffered probe pending) because of this, but you expect some clear error message instead…
Bad log

[    3.722324] stpmic1 0-0033: Failed to get main IRQ: -22
[    3.744915] stpmic1: probe of 0-0033 failed with error -22

Better log

[    3.734803] stpmic1 0-0033: PMIC Chip Version: 0x21
[    3.791026] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Failed to create device link (0x180) with 0-0033
[    3.814759] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Failed to create device link (0x180) with 0-0033
[    3.823589] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Failed to create device link (0x180) with 0-0033
[    3.855193] stm32f7-i2c 5c002000.i2c: STM32F7 I2C-0 bus adapter
[    3.861661] mmci-pl18x 58005000.mmc: Got CD GPIO
[    3.875789] mmci-pl18x 58005000.mmc: mmc0: PL180 manf 53 rev2 at 0x58005000 irq 47,0 (pio)
[    3.917873] mmci-pl18x 58007000.mmc: mmc1: PL180 manf 53 rev2 at 0x58007000 irq 49,0 (pio)

So yeah, pmic isn’t completely ok yet. But alteast it isn’t keeping the emmc hostage anymore…