15:23 <qsx> hi

15:24 <qsx> i’m having an issue with my rockpro64: after updating from u-boot 2021.01 to 2021.10, it doesn’t boot any more (and it doesn’t seem to be the inno-usb2 issue)

15:24 <qsx> https://bpa.st/J77Q

15:25 <qsx> the relevant line seems to be: Card did not respond to voltage select! : -110

16:13 <Tartarus> That's unfortunate, and a number of releases, but sounds like an easy to reproduce problem? So git bisect should help at least

16:13 <Tartarus> I got my rockpro64 last week but haven't unboxed / installed to my lab yet

16:14 <Tartarus> https://armkeil.blob.core.windows.net/developer/Files/pdf/certificate-list/arm-systemready-ir-certification-rockchip.pdf says v2021.07 should work too

16:14 <Tartarus> Of course "plus patches" is a little worrisome, but hopefully not related to your issue but rather IR specific configuration

16:16 <qsx> eh, i can bisect it, but it’s tedious

16:18 <qsx> i need to build u-boot in a debian container, because the aarch64 gcc on my gentoo host produces binaries that don’t work at all (another issue i should tackle some time …), then copy the binaries out of the container, pull the eMMC out, flash it, put the eMMC back in (which is also finicky), …

16:20 <qsx> hmm. v2021.07 works, and i notice it says Trying to boot from MMC1

16:20 <qsx> while 2021.10 tries to boot from MMC2 and fails

16:23 <qsx> i wonder if 822556a934 is the issue, introducing /aliases/mmc{0..2} in the device tree

16:42 <alchemist> we got to celebrate our differences

17:06 <qsx> huh. bisected, apparently ac804143cf is the culprit

17:06 <qsx> off to the mailing list i guess

17:16 <qsx> nevermind, the solution is already there: https://lore.kernel.org/u-boot/20211101044347.17822-1-yifeng.zhao@rock-chips.com/

19:07 <samueldr> [qsx](https://matrix.to/#/@qsx:libera.chat): can you try running `mmc dev; mmc info; mmc dev; mmc info`, in my testing on another RK3399 board this breaks mmc

19:08 <samueldr> (from the same root cause)

19:08 <samueldr> well, same commit introducing issues

19:09 <samueldr> I traced it down to `rockchip_sdhci_set_ios_post`, which by default AFAICT doesn't get exercised at all

19:09 <samueldr> "by default" I mean when doing a default boot, without interacting with the device

19:10 <samueldr> (and frankly, I'm not sure how to report this correctly to the ML)