Thanks alot for the reply. I finished the bisect between v2026.04 (good) and v2026.07 (bad). Results are below.
commit a3075db94d49f415658bf7e961e1eae90d9abc33 Author: Marek Vasut <[email protected]> Date: Wed Jan 28 00:48:40 2026 +0100 lmb: Reinstate access to memory above ram_top Revert commit eb052cbb896f ("lmb: add and reserve memory above ram_top") and commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank"). These are based on incorrect assumption of the first commit, that "U-Boot does not use memory above ram_top". While U-Boot itself indeed does not and should not use memory above ram_top, user can perfectly well use that memory from the U-Boot shell for example to load content in there. Right now the attempt to use that memory to load large image using TFTP ends with "TFTP error: trying to overwrite reserved memory...". With this change in place, the memory can be used again. Fixes: eb052cbb896f ("lmb: add and reserve memory above ram_top") Fixes: 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank") Reported-by: Yuya Hamamachi <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Each commit was built and flash-tested on real hardware (VisionFive 2, v1.3B, 8GiB), boot result confirmed via serial console each round. Bisect log below for reference. Whats interesting is that the actual regressing commit isn't an MMC-subsystem change at all — it's an lmb (memory reservation) change reverting an earlier restriction on memory above ram_top. My guess (not verified, just an observation) is that the MMC driver's DMA buffer allocation may be relying on that memory being reserved or excluded and removing that reservation could be causing DMA into an unsafe or improperly handled memory region during SD card init which would line up with the "voltage select" / "Error reading cluster" failures I've been seeing right at the data transfer stage. Could well be unrelated to the actual mechanism since the voltage select error also shows when boot works fine. Happy to test a fix or patch if one comes up. --- bisect log --- git bisect start # status: waiting for both good and bad commits # bad: [ece349ade2973e220f524ce59e59711cc919263f] Prepare v2026.07 git bisect bad ece349ade2973e220f524ce59e59711cc919263f # status: waiting for good commit(s), bad commit known # good: [88dc2788777babfd6322fa655df549a019aa1e69] Prepare v2026.04 git bisect good 88dc2788777babfd6322fa655df549a019aa1e69 # bad: [f98f2e26125f111df60d1ebdab483f91cc1f8e71] ls1043a: add env variables to assist boot git bisect bad f98f2e26125f111df60d1ebdab483f91cc1f8e71 # bad: [0e16a814399510d1785cf87c4a9a1c66dd790487] Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi into next git bisect bad 0e16a814399510d1785cf87c4a9a1c66dd790487 # good: [fe6484b402759dba6024cf2f8c212b27f769a0d7] bootm: fix booting kernel_noload image git bisect good fe6484b402759dba6024cf2f8c212b27f769a0d7 # bad: [7f35a4251dae2b1c94c959ac15cf4d0814485a88] sandbox: symbol CONFIG_DM_SOUND does not exist git bisect bad 7f35a4251dae2b1c94c959ac15cf4d0814485a88 # good: [04e96eb693cdb26204143629c56d45a353390a75] disk: fix DOS_PARTITION dependencies git bisect good 04e96eb693cdb26204143629c56d45a353390a75 # good: [a5fcbd5a83553b3803df28422410c9fd22adaec6] net: Move network PHY under NETDEVICES git bisect good a5fcbd5a83553b3803df28422410c9fd22adaec6 # good: [6dc75d440dbdd3e2ac24ae5bb0ed51123bee8c33] Merge tag 'net-20260312' of https://source.denx.de/u-boot/custodians/u-boot-net into next git bisect good 6dc75d440dbdd3e2ac24ae5bb0ed51123bee8c33 # good: [2f52473884723751316388af30a95419905b1cd3] Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-riscv into next git bisect good 2f52473884723751316388af30a95419905b1cd3 # good: [c664b4d5f30a704003b97823a5ad6361cb16fbe8] spl: Make UFS available for SPL builds git bisect good c664b4d5f30a704003b97823a5ad6361cb16fbe8 # good: [dba21bf0b6ececa4bbc15ac93b3cdf4b09286ed7] Merge tag 'u-boot-ufs-20260313' of https://source.denx.de/u-boot/custodians/u-boot-ufs into next git bisect good dba21bf0b6ececa4bbc15ac93b3cdf4b09286ed7 # bad: [e7ad95aa3f1180823e07dd30c8c24494a07ca814] spl: spi: fix loss of spl_load() error on soft reset git bisect bad e7ad95aa3f1180823e07dd30c8c24494a07ca814 commit a3075db94d49f415658bf7e961e1eae90d9abc33 is the first bad commit On Fri, 21 Aug 2026, 20:49 Quentin Schulz, <[email protected]> wrote: > Hi Milad, > > On 7/29/26 12:29 PM, Milad wrote: > > [You don't often get email from [email protected]. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > > > Thanks to both for the replies. > > > > I built and tested both v2025.10 and v2026.01 on my board (VisionFive 2, > > v1.3B, 8GiB), and can confirm both boot the SD card correctly, no cluster > > read failure, straight into GRUB and Debian on both. Only v2026.07 fails > > for me. > > > > So the regression window looks to be somewhere between v2026.01 and > > v2026.07. Full serial logs for both below. > > > > Could you bisect which commit broke it? That would surely help people > have an idea of what could have gone wrong and get motivated to fix the > issue :) > > Cheers, > Quentin >
