Hi Milad, adding CC: Sughosh On 8/23/26 06:34, Milad wrote: > 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 >> >
MMC driver access on JH-7110 SoC from U-Boot does not tolerate beyond 32-bit address. I've now completely forgotten what the test procedure was for this earlier but it followed with a discussion via IRC (and further mailing list follow-up [1]) about the change in memory model access within u-boot that broke uSD access beyond the addressing limit for JH-7110 SoC. 1: https://lore.kernel.org/u-boot/[email protected]/ Search mailing list archives for my name and Sughosh together where you'll find the intersection of that discussion over a few threads. Initially we don't understand the problem and then when there are suggested fixes I then try to ensure enough testing has been done to confirm the corrections made by Sughosh. Probably we missed something? I was donated a Mars CM and a Star64 with eMMC module, so there is some testing I might be capable of doing with these hardware yet on request. Thanks, -E
