08:40 <warpme> Kwiboo : re rock5-itx boot oops: maybe following observations will be helpful: 1)simple dd sd card to emmc makes boot from emmc ok (so issue seems to be close to sd card); 2)disabling DisplayPort in dts allows to boot from sd card.

09:42 <Kwiboo> warpme: maybe I do not understand the issue? the gist you link to seem to be booting from MMC1 (sdhci) and is followed by kernel oops, so what is the issue with sd-card? does U-Boot not boot into OS from sd-card or is the issue that kernel oops when booting from sd-card?

09:45 <Kwiboo> the commit c6bba31 "rockchip: spl-boot-order: Defer probe of boot device" changes so that U-Boot SPL will not try and probe all boot devices, e.g. in the gist you linked where it was booting from MMC1 (sdhci) only sdhci device is probed (pinctrl + clocks etc is applied)

09:48 <Kwiboo> prior to that commit all boot devices would be probed in SPL, so pinctrl + clocks would be applied also for sdmmc and fspi before it tried to load TF-A and U-Boot proper from emmc, with that commit is now only probe the boot device it tries to load next stage from

09:50 <warpme> well "seem to be booting from MMC1 (sdhci)" - this probably causing oops at early init we see. Situation is: i nave board with empty spi and empty emmc and with sd card having OS. Boot ends with oops - maybe because despite sd card presence - kernel tries to read rootfs from empty emmc? Kernel dts has mmc0 alias to sd card.

09:50 <Kwiboo> e.g. BootROM started SPL from SD-card -> only sdmmc device is probed in SPL before TF-A/U-Boot proper is loaded from sd-card, if it cannot find the FIT, it will probe sdhci and try to load from emmc etc

09:51 <Kwiboo> so if I understand correctly you can boot into U-Boot from any of sd-card, emmc or spi flash, but Linux may crash depending on what media U-Boot was starting from ?

09:52 <Kwiboo> please try to boot into U-Boot cli and run something like following: "mmc dev 0; mmc dev 1; sf probe; boot", that should ensure all devices are probed prior to entering Linux

10:01 <warpme> to summarise: with mainline 2026.01: 1)sd card case: spl loads from sd card; uboot from sd card reads fat part with kernel image & dts; uboot passes to kernel image, boots this image, goes wilt build-in modules then mounts ok rootfs part from sd card then starts early userspace init; early userspace oops. 2)emmc with dd binary copy of sd card: all works

10:01 <warpme> lat me try with "mmc dev 0; mmc dev 1; sf probe; boot"

10:11 <Kwiboo> warpme: so then my understanding was correct, and at top of mind the only differance would be that pinctrl for emmc or spi flash is never applied prior to jumping into linux, vs old version of u-boot

10:12 <warpme> to be sure: just rebuild 2026.01 and do "mmc dev 0; mmc dev 1; sf probe; boot" The same oops: https://gist.github.com/warpme/18bd90020ff7c334e20c5be59f61341d

10:13 <warpme> "vs old version of u-boot" - this might be as simple dd of 2025.10 makes all ok

10:13 <Kwiboo> "Trying to boot from MMC1", this still look like it loads SPL from emmc and not sd-card?, also try the specific rock 5 itx build

10:16 <warpme> but emmc/spi seems to empty as removing sd card gives silent uart....

10:16 <Kwiboo> even the generic DT have mmc0 = &sdhci; but your U-Boot shows: MMC: mmc@fe2c0000: 0, mmc@fe2e0000: 1, do you have any patches or modifications for U-Boot ?

10:17 <warpme> oh no - i chaneged tthis is uboot dts and in kernel dts: in all my boards mmc0 is ALWAYS sd card

10:17 <warpme> "do you have any patches or modifications for U-Boot" - yes - as above

10:20 <warpme> reason is user base maintenance for remote updates of uboot

10:21 <warpme> "also try the specific rock 5 itx build" - the same oops

10:26 <warpme> interesting is that with reverted c6bba31dbdd450081503dc0e20fcfb4328b347e4 i see time to userspace as 1.2sec while with this commit it is 25sec

10:29 <Kwiboo> can you try with following in u-boot: u-boot,spl-boot-order = &sfc, &sdhci, &sdmmc, "same-as-spl"; should help ensure all devices are probed in SPL similar to prior before tf-a/u-boot is loaded from sd-card

10:31 <Kwiboo> I have seen some slow boot times in Linux on e.g. rock-5a/rock-5c, and list a 10+ second delay during kernel init, maybe that is related to your issue

10:34 <Kwiboo> I can try to replicate you issue on my rock 5 itx board, still do not understand why not probing all boot devices (emmc, sdmmc and fspi) before entering TF-A/U-Boot proper would affect boot into Linux, and if it does there is some other issue that should really be solved

10:35 <warpme> for: u-boot,spl-boot-order = &sfc, &sdhci, &sdmmc, "same-as-spl" i'm getting syntax error

10:39 <Kwiboo> something like https://gist.github.com/Kwiboo/fd2d199240bfa6f3de4c1de4f09b25d2 does not work ?

10:47 <warpme> yes - above change helps :-)

11:06 <warpme> guys: after upgrade from working well 6.18.5 to 6.18.6 (or 7) i'm getting oops in kernel like this: https://termbin.com/jyin Ooos happens when i'm pressing key on ir remote - so it looks to me like .6/7 kernels have i.e. by default enabled gpio irq. simple recompile to 6.18.5 gives all ok - so for me it looks like .6/7 regressiuon. Is this known issue?

11:47 <Kwiboo> warpme: did the change to u-boot,spl-boot-order make it work better for sd-card even with the c6bba31 "rockchip: spl-boot-order: Defer probe of boot device" ?, just so that I know where to look closer

11:59 <warpme> oh - i'm not sure what means "better". I tested change of u-boot,spl-boot-order WITH c6bba31. But indeed "better" for me may mean less risks with testing new vers of uboot. Currently - when i have user with device with emmc holding old uboot - and we want to test/update to new uboot - i need ask user to flash new uboot to emmc. So if anything goes wrong - user just can't return to working state by simple removal of sd card to

11:59 <warpme> getting back with working device. For me this becomes problematic as all this happens remotely and users are started qualifying me as "his update bricks my device"

12:08 <Kwiboo> warpme: what I meant was, does the change to u-boot,spl-boot-order with c6bba31 make sd-card boot work same as without c6bba31 and unchanged u-boot,spl-boot-order, i.e. does forcing SPL to try booting from spi flash and emmc before it tries to load tf-a/u-boot proper from sd-card resolve the initial issue/oops when booting from sd-card with 2026.01 ?

12:11 <warpme> "forcing SPL to try booting from spi flash and emmc before it tries to load tf-a/u-boot proper from sd-card" - i not tested such scenario (need to switch to other board having flashed spi)

12:13 <warpme> i'll try test this today evening (or tomorrow)

12:46 <Kwiboo> no need to flash spi, what I want tested is just instead of reverting c6bba31 you include the u-boot,spl-boot-order and boot from sd-card

12:47 <Kwiboo> i.e. if use of the u-boot,spl-boot-order change instead of reverting c6bba31 works as a workaround to fix sd-card boot

12:52 <Kwiboo> effectively what will happen then is that you will see trying to boot from SPI + MMC2 (emmc) and fails, before it tries to boot from MMC1 (sd-card) and succeed, my expectation is that would restor similar behavoior that a revert of c6bba31 would

13:23 <warpme> "instead of reverting c6bba31 you include the u-boot,spl-boot-order and boot from sd-card" - ah sorry - i was unclear. This is exactly what i done and it works ok :-)

14:05 <Kwiboo> warpme: great, thanks for confirming, very strange, I suspect/guess that the emmc pins is left in fspi_m0 or gpio func and this is causing issues/oops in Linux, will try to reproduce on my rock 5 itx board

14:06 <warpme> many thx for looking on this!

14:06 <warpme> (took me some time with bisecting) :-)

16:06 <qschulz> i'm about to disable early UART debug console on OP-TEE OS, please speak your mind if you're against: https://github.com/OP-TEE/optee_os/pull/7688

16:29 <qschulz> also, if anyone has access to an rk322x device and want to test CFG_DTB_MAX_SIZE=0x60000 such that I don't need to exclude it from https://github.com/OP-TEE/optee_os/pull/7687 it'd be nice :)