[Bug 269181] sysutils/u-boot-rpi-arm64: RPi4/8G fails to boot: "** Reading file would overwrite reserved memory **"

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 06 Feb 2023 05:25:09 UTC

--- Comment #5 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
great idea for my test. So I explored more
reasonable numbers and discovered:

Exploring (decreasing decimal number order, not time sequence):

12 worked
10 worked (hmm: 10 == 3+7, matching memory.cnt+reserved.cnt below)
9 failed (less than memory.cnt+reserved.cnt below)
8 failed

When I looked at the bdinfo just before attempting a boot, what
I got was (8 GiByte RPi4B):

Hit any key to stop autoboot:
U-Boot> bdinfo
. . .
memory.cnt  = 0x3
memory[0]      [0x0-0x3b2fffff], 0x3b300000 bytes flags: 0
memory[1]      [0x40000000-0xfbffffff], 0xbc000000 bytes flags: 0
memory[2]      [0x100000000-0x1ffffffff], 0x100000000 bytes flags: 0
reserved.cnt  = 0x7
reserved[0]    [0x0-0x3fff], 0x00004000 bytes flags: 0
reserved[1]    [0x39c2b000-0x3b2fffff], 0x016d5000 bytes flags: 0
reserved[2]    [0x3ac3b4a0-0x3b0fffff], 0x004c4b60 bytes flags: 0
reserved[3]    [0x3ee62be0-0x3ee62fdf], 0x00000400 bytes flags: 4
reserved[4]    [0x3ee63020-0x3ee63055], 0x00000036 bytes flags: 4
reserved[5]    [0x40000000-0xfbffffff], 0xbc000000 bytes flags: 0
reserved[6]    [0x100000000-0x1ffffffff], 0x100000000 bytes flags: 0
devicetree  = board
arch_number = 0x0000000000000000
TLB addr    = 0x000000003b0f0000
irq_sp      = 0x000000003ac3f940
sp start    = 0x000000003ac3f940
Early malloc usage: 878 / 2000

(I've not yet seen in the code why memory and reserved are not
independent, each with CONFIG_LMB_MAX_REGIONS space available.)

Overall, this tends to indicate that the "implicit #else" case's
lack of initialization of the 2 max fields is not directly what has
been run into here.

Note: The "[0x0-0x3fff], 0x00004000" is because I have U-boot
reserve more than the first page for armstub8*.bin and related
run-time data (e.g., its stack). The standard port just reserves
the first page, not covering everything.

You are receiving this mail because:
You are the assignee for the bug.