STM32MP151aac custom board kernel not starting

michiel.tjampens · ‎2023-09-03

I'm trying to get to know stm32mp1 while making a board for this thing.

While using the default image provided by manufacturer seems to work. The kernel used is old compared to the current ST BSP and support from them isn't exactly great so I'm trying to migrate to the latest BSP. This isn't going so well.

Following instructions found in the wiki. I've managed to compile it but when trying to run, it just stops at 'starting kernel'. Recompiling with LL_DEBUG and EARLY_PRINTK, resulted in some more info.

The lines that seems to show an issue are:

[    1.599531] i2c_dev: i2c /dev entries driver                                                                                                                                     [    1.606005] syscon-reboot: probe of reboot failed with error -22                                                                                                                                                                                                                              [    1.733737] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping ....                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         [    2.031116] irq: no irq domain found for gpio@54004000 !                                                                                                                         [    2.036565] gpio-keys joystick: Found button without gpio or irq                                                                                                                 [    2.057386] gpio-keys: probe of joystick failed with error -22                                                                                                                   [    3.458283] Warning: unable to open an initial console.                                                                                                                          [    3.465913] Freeing unused kernel image (initmem) memory: 1024K                                                                                                                  [    3.487792] Run /init as init process 
[    3.866045] udevd[133]: Starting version 244
[    3.893045] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:18 Unknown group 'tty', ignoring
[    3.917955] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:19 Unknown group 'tty', ignoring
[    3.926963] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:20 Unknown group 'tty', ignoring
[    3.947840] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:21 Unknown group 'tty', ignoring
[    3.956848] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:22 Unknown group 'tty', ignoring
[    3.988188] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:23 Unknown group 'tty', ignoring
[    3.997197] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:24 Unknown group 'tty', ignoring
[    4.028175] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:25 Unknown group 'dialout', ignoring
[    4.047834] udevd[134]: /lib/udev/rules.d/50-udev-default.rules:27 Unknown group 'kmem', ignoring
[   13.991414] arm-scmi firmware:scmi-0: Invalid channel descriptor for 'scmi-0'
[   13.998713] arm-scmi: probe of firmware:scmi-0 failed with error -22
[   14.011959] platform wifi-pwrseq: deferred probe pending
[   14.017331] amba 48004000.sdmmc: deferred probe pending
[   14.022685] amba 58005000.sdmmc: deferred probe pending
[   14.027978] amba 58007000.sdmmc: deferred probe pending
[   14.033239] platform led: deferred probe pending
[   14.037911] platform 4c001000.mailbox: deferred probe pending
[   14.043695] platform mlahb:m4@10000000: deferred probe pending
[   14.049587] platform 48002000.dma-router: deferred probe pending
[   14.055633] platform 4c000000.hwspinlock: deferred probe pending
[   14.061701] platform 50000000.rcc: deferred probe pending
[   14.067138] platform 50001020.pwr: deferred probe pending
[   14.072595] platform 5000d000.interrupt-controller: deferred probe pending
[   14.079536] platform soc:pin-controller@50002000: deferred probe pending
[   14.086282] platform soc:pin-controller-z@54004000: deferred probe pending
[   14.093221] platform 48000000.dma: deferred probe pending
[   14.098692] platform 48001000.dma: deferred probe pending
[   14.104128] platform 58000000.dma: deferred probe pending
[   14.109585] platform 5a006000.usbphyc: deferred probe pending
[   14.115368] platform 50001000.pwr: deferred probe pending
[   14.120822] platform 4000f000.serial: deferred probe pending
[   14.126520] platform 40010000.serial: deferred probe pending
[   14.132237] platform 40018000.serial: deferred probe pending
[   14.137954] platform 5c000000.serial: deferred probe pending
[   14.143652] platform 54003000.rng: deferred probe pending
[   14.149122] platform 58002000.nand-controller: deferred probe pending
[   14.155606] platform 5800a000.ethernet: deferred probe pending
[   14.161559] platform 49000000.usb-otg: deferred probe pending
[   14.167348] platform 5800d000.usbh-ehci: deferred probe pending
[   14.173332] platform 5c004000.rtc: deferred probe pending
[   14.178788] platform 40013000.i2c: deferred probe pending
[   14.184223] platform 5c002000.i2c: deferred probe pending
[   14.189677] platform 50028000.thermal: deferred probe pending
[   14.195463] platform 5a002000.watchdog: deferred probe pending
[   14.201356] platform cpufreq-dt: deferred probe pending

Based on that I found another post that might be related, so I checked the dts files. No mention of mco1.

Next step was compiling the original device tree files with the same BSP mentioned earlier...

The complains raised by the compiler were that it couldn't find the sram and optee group. Have those been removed from stm32mp151.dtsi? According to another post the sram was renamed to sram1 but can't find that either. If so, is there a changelog somewhere that helps with migrating from an old bsp version?

debugging · ‎2023-09-29

Perhaps you could hit a key to stop the autoboot to debug further from the u-boot command line,

I had the same question about PE it's zero. but I even can't get to the the step of ... loading the environment after the DDR 533Mhz.... because after clock #151 (UART4) enabled the boot freezes..

michiel.tjampens · ‎2023-09-30

I'm doing this as a hobby and the problem is that I probably lack the knowledge, don't know what I could do from the u-boot cli for this issue. The kernel doesn't find the rootfs but u-boot 'mmc' cmds clearly show it's there.

So far I've managed to solve various issues, but this time I haven't even got an idea where/how to start looking.

PE being zero might mean something but might totally be irrelevant. I do know that with the original image from the manufacturer PE wasn't 0. But the only peripherials used (i think) are the uart4 and i2c4, both use the same clksrc and the former seems to be working fine but the latter isn't (pmic issue in logs).

debugging · ‎2023-09-30

I know exactly how you feel, It takes a lot persistence and passion to try to get your board up and running where you invested so much time in to design, while having to workaround the lack of support (sources and knowledge...) to reach that goal for the software. I am learning along the way facing many roadblocks

I found that DTS generated with CubeMX set CLK_CKPER_DISABLED for OPP-TEE and TF-A instead of CLK_CKPER_HSE in DK boards while it's the same processor and almost all same peripherals although I only enabled UART4 and USB. After the change it became 24MHz, Don't know why CubeMX disabled PERI. MX also set the RTC clock divider to 0 while for DK1 boards it is 23.

Clocks:
- MPU : 650 MHz
id=32 clock = bebc200 : 200000 kHz
- MCU : 200 MHz
- AXI : 266.500 MHz
id=30 clock = 16e3600 : 24000 kHz
- PER : 24 MHz
- DDR : 533 MHz

no matter what it did not fix my UART4 clock 151 issue. There is a big difference in clock configuration between DTS generated for a custom board from MX compared to the DTS from ST's own boards. Perhaps ST tuned the DT's for the boards and for a custom board it make it very difficult to understand where a problem could be

michiel.tjampens · ‎2023-10-01

Kind of a let down expecting two replies only to get a proper one and a useless ai summary...

PER probably 0 because it's used for (q)spi,sai and lptim. So if not using those, no need for DT to activate it. So one possible cause i can scratch of the list.

debugging · ‎2023-10-05

What defconfig do you use for the kernel ? multi_v7_defconfig as mentioned in the ECO readme or the one used for u-boot ?

Which device tree, the same one from u-boot or a different customized one ?

your dts is quite close to mine but I do not use PMIC on I2C4 and your MMC2 is 4 bits wide?> In my board MMC2 is the EMMC width 8 bits

pinmux = <STM32_PINMUX('A', 8, AF9)>, /* SDMMC2_D4 */

<STM32_PINMUX('A', 9, AF10)>, /* SDMMC2_D5 */

<STM32_PINMUX('B', 3, AF9)>, /* SDMMC2_D2 */

<STM32_PINMUX('B', 4, AF9)>, /* SDMMC2_D3 */

<STM32_PINMUX('B', 14, AF9)>, /* SDMMC2_D0 */

<STM32_PINMUX('B', 15, AF9)>, /* SDMMC2_D1 */

<STM32_PINMUX('D', 3, AF9)>, /* SDMMC2_D7 */

<STM32_PINMUX('E', 5, AF9)>, /* SDMMC2_D6 */

<STM32_PINMUX('G', 6, AF10)>; /* SDMMC2_CMD */

michiel.tjampens · ‎2023-10-05

The multi_v7 one, but enabled LL_Debug & earlyprintk. Same device tree as u-boot, the lab mentioned that I should do this.

debugging · ‎2023-10-07

I am now close or at the same point where you are that Linux does not start. From your git, it seems you use the Debian rootfs. My approach was using the starter package and create and bootable SD card. (The starter package can also be used to create the data on the EMMC via USB). Then update the TF-A, U-boot, Optee build artifacts and update the bootfs with the kernel uImage and uboot files. IMHO I can just use the same rootfs as it's is also based on ECO 5.0.0 For further steps in debugging I got some inspiration from this https://medium.com/@villebaillie25/how-to-debug-your-linux-bsp-fd8bcb929544

michiel.tjampens · ‎2023-10-07

Well yes and no about the debian rootfs. I'd prefer to use it and tried to, but given that the issue is that the kernel can't find the rootfs, that doesn't make much difference.

Thats why rootfs used so far is the one you get from yocto (following the ST guide), thought it would be best to use ST stuff so I can get help here if it doesn't work...

Can't use a SD card yet because the carrier I made for the module hasn't got sd card slot populated.. Figured internal emmc was less error prone than external sd...

Currently tried following https://forum.digikey.com/t/debian-getting-started-with-the-stm32mp157/12459. This helps to do the building of the bootstages without the sdk, but it's for sd card.

michiel.tjampens · ‎2023-10-07

Ah, didn't see that edit before:

"your dts is quite close to mine but I do not use PMIC on I2C4 and your MMC2 is 4 bits wide?> In my board MMC2 is the EMMC width 8 bits"

Hm, I used that because the dts file from Myir (module manufacturer) didn't seem to refer to 8 bits so I figure the stm32mp151 has 4bit wide. Checked datasheet of the proc and has indeed 8 bits... So check the dts again and found it did specify 8 bit afterall (must have overlooked it somehow because the pinctrl was split).

Altered the CubeMX project accordingly and rebuilding stuff etc. Shouldn't make a difference to the issue given that the bus was specified at 4 bits... But if it ends up working, it will be faster.

Update: Rebuild the yocto dist with the changes, didn't make a difference.

michiel.tjampens · ‎2023-10-08

Finally solved it. Not that I understand the why nor the how...

Reason was missing interrupt information in the pmic: stpmic@33 node...

pmic: stpmic@33 {
	...
	interrupts-extended = <&exti 55 IRQ_TYPE_EDGE_FALLING>;
	interrupt-controller;
	#interrupt-cells = <2>;
        ...
};

Why would missing interrupt info inside the pmic -that clearly is providing power- cause the emmc to not be found?

Is there somewhere a piece of code that waits for the pmic before it does anything?

@debuggingMight explain the issue you also had with pmic enabled ...