00:13 <qsx> samueldr: https://bpa.st/RPRA

00:14 <samueldr> thanks [qsx](https://matrix.to/#/@qsx:libera.chat), matches *exactly* with my observations on other boards

00:14 <qsx> (i think the MMC2 SPL wants to boot from at first is the wifi sdio, lol)

00:14 <samueldr> nah, naming is weird, and differs at that stage

00:15 <qsx> btw, the inno-usb2 issue does not appear when i boot linux using EFI

00:15 <samueldr> if you have a more specific use case, e.g. using USB Mass Storage with RK3399, removing the op here will help:

00:15 <samueldr> - https://source.denx.de/u-boot/u-boot/-/blob/v2021.10/drivers/mmc/rockchip_sdhci.c#L356

00:16 <samueldr> that's because the UMS bits in U-Boot will exercise that function which otherwise doesn't

00:16 <samueldr> I suspect it's possible you need to provide a "good enough" dtb for Linux that U-Boot can load

00:17 <qsx> well the dtb uboot uses is the one from linux, plus uboot additions linux doesn’t care about

00:17 <samueldr> with EFI boot, U-Boot will look, at the root of the ESP, in those folders for the dtb to load:

00:17 <samueldr> - https://source.denx.de/u-boot/u-boot/-/blob/v2021.10/include/config_distro_bootcmd.h#L154

00:18 <samueldr> it's possible it's not been synced for a while [unfounded guess]

00:18 <qsx> if there is none, uboot will provide the one it used itself, which works fine

00:18 <samueldr> I know that usually you'd want to use the exact dtb file built with the kernel you intend to boot on ARM, because of... reasons...

00:19 <qsx> in fact i examined rk3399.dtsi, rk3399-opp.dtsi, and rk3399-rockpro64* this afternoon, and the updates that have not propagated so far are irrelevant for me (some cosmetic naming, some hardware i don’t use)

00:19 <samueldr> (I won't go into details here as it's not the right venue, but while it's stated it should work, too often things are "fixed" in the device tree, which means an older device tree won't correctly work)

00:19 <qsx> yes i had that kind of fun with the vendor linux 4.4 vs. mainline linux 5.10

00:19 <samueldr> right, I was thinking solely about mainline :)

00:20 <samueldr> anyway, I can't exactly help, so I won't try much more to guess

00:21 <qsx> yeah backporting that fix already did it -- <qsx> nevermind, the solution is already there: https://lore.kernel.org/u-boot/20211101044347.17822-1-yifeng.zhao@rock-chips.com/

00:21 <samueldr> yeah, that I agree with: if the kernel is to decide what is the "correct" overview of the hardware, it should somehow handle loading the "correct" dtb file itself *grumbles and groans*

17:53 <rfried> Tartarus, sjg1: We're not going to support non DM drivers any longer right, so there's no reason to accept #ifndef DM_ETH statement. am I right ?

19:38 <Tartarus> rfried: SPL/TPL aren't in that category, and SPL+networking is a valid combination