On 8/23/26 21:14, E Shattow wrote: > 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
P.S. I don't know what I am doing CC'ing outdated e-mail address for Sughosh. CC'ing now from MAINTAINERS like I should have done a minute ago.
