Hi Milad, E,
On 8/24/26 6:14 AM, 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
Then the MMC driver for the JH-7110 SoC needs to select
LMB_LIMIT_DMA_BELOW_RAM_TOP, c.f. what we've done for Rockchip in
lib/Kconfig, or the Mediatek Ethernet controller (MEDIATEK_ETH) in
drivers/net/mtk_eth/Kconfig.
Cheers,
Quentin
