On Wed, May 27, 2026 at 01:25:01PM -0600, Tom Rini wrote: > On Fri, May 15, 2026 at 04:52:21PM +0300, Ilias Apalodimas wrote: > > > Hi This is v4 of [1][2][3]! > > > > There was a discussion recently on the mailing lists regarding our > > management of memory above ram_top [0]. The tl;dr is that we have two > > problems. > > FWIW, you dropped the reference to [0] which is: > https://lore.kernel.org/u-boot/cac_iwjkfazpj3b_mew7-dnorcav-rfkhxxo8bv0kglnp2vj...@mail.gmail.com/ > > > The first one is that U-Boot always relocates to the top of the first > > available > > bank unless there's special board code to sidestep that. The second is we > > don't > > successfully deal with devices that can only do 32-bit DMA. > > > > This patch series deals with the first problem by adding a Kconfig option > > allowing platforms to relocate to the top of the last discovered bank. > > > > It's worth noting that this is easily testable with QEMU > > > > qemu-system-aarch64 -m 8192 -smp 2 -nographic -cpu cortex-a57 \ > > -machine virt,secure=off \ > > -bios u-boot.bin \ > > -device virtio-rng-pci \ > > -drive id=os,if=none,file="$image" \ > > -device virtio-blk-device,drive=os \ > > -object memory-backend-ram,id=ram0,size=4G \ > > -object memory-backend-ram,id=ram1,size=4G \ > > -numa node,memdev=ram0 \ > > -numa node,memdev=ram1 > > So, now all of the sandbox runs in CI are failing over at least one of > the existing tests, and the Pi 4 platforms over in the sage lab are also > now failing the tftp kernel test.
Ah, sorry, wrong failures. Sandbox is fine. Pi 4 is not and is a failure to boot: https://source.denx.de/u-boot/u-boot/-/jobs/1464655 U-Boot 2026.07-rc3-00156-gc5e6dbd538d2 (May 27 2026 - 19:08:11 +0000) DRAM: 1.9 GiB mbox: Header response code invalid RPI 4 Model B (0xb03115) mbox: Header response code invalid bcm2835: Could not set module 3 power state initcall_run_r(): initcall board_init() failed ### ERROR ### Please RESET the board ### -- Tom
signature.asc
Description: PGP signature
