On 21.11.24 09:04, Sughosh Ganu wrote:
On Wed, 20 Nov 2024 at 13:49, E Shattow <[email protected]> wrote:
Hi all, (on-list)
On Tue, Nov 19, 2024 at 9:14 PM Sughosh Ganu <[email protected]> wrote:
On Wed, 20 Nov 2024 at 10:09, E Shattow <[email protected]> wrote:
On Tue, Nov 19, 2024 at 6:42 PM Sughosh Ganu <[email protected]> wrote:
On Wed, 20 Nov 2024 at 04:48, E Shattow <[email protected]> wrote:
Hello,
On HEAD some commits after v2024.10 I encounter a regression for
`bootefi bootmgr` fail with error "Not a PE-COFF file"; The fall-thru
case of global EFI boot is successful.
Having run a git bisect I discover the first bad commit 22f2c9ed:
$ git checkout -b master origin/master
branch 'master' set up to track 'origin/master'.
Switched to a new branch 'master'
$ git bisect start
status: waiting for both good and bad commits
$ git bisect bad HEAD
status: waiting for good commit(s), bad commit known
$ git bisect good v2024.10
Bisecting: 850 revisions left to test after this (roughly 10 steps)
[82686e678e1587ddbd9570f82c58cdc3aecf2dbe] Merge branch 'staging' of
https://source.denx.de/u-boot/custodians/u-boot-tegra
$ git bisect good
Bisecting: 422 revisions left to test after this (roughly 9 steps)
[8963d433eb5d4a9f3a9def84e9c61a45c13e72bc] Merge tag
'u-boot-rockchip-20241026' of
https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip
$ git bisect bad
Bisecting: 214 revisions left to test after this (roughly 8 steps)
[0a504585d1cefeaf35ae8f860a5e5aa44dfffed5] arm: dts: k3-j722s-binman:
Add support for HS-SE
$ git bisect bad
Bisecting: 106 revisions left to test after this (roughly 7 steps)
[88057dab2cde8710ccc95d12fb312184e0b023ca] mtd: spi-nor: Allow flashes
to specify MTD writesize
$ git bisect good
Bisecting: 53 revisions left to test after this (roughly 6 steps)
[625d40ab120dbc6f45dbd975857f8f87e422bd0f] test: boot: fix
bootflow_cmd_label for when DSA_SANDBOX is disabled
$ git bisect bad
Bisecting: 26 revisions left to test after this (roughly 5 steps)
[5b9261fb0b1ed087387f2036d279fd3f4bb20a61] Makefile: Drop
SPL_FIT_GENERATOR support
$ git bisect good
Bisecting: 13 revisions left to test after this (roughly 4 steps)
[e1b6822d6522d94d579d53092342b542d368a04b] efi_memory: do not add RAM
memory to the memory map
$ git bisect bad
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[2f6191526a1325b6ddb59795a093eca69dbf8976] lmb: notify of any changes
to the LMB memory map
$ git bisect bad
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[3c6896ad2fb876b0a23202f62a83c0d44380c9ea] lmb: add a flag to allow
suppressing memory map change notification
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[22f2c9ed9f533a56bed09bd4e0e37852b6b9f3b1] efi: memory: use the lmb
API's for allocating and freeing memory
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[eb052cbb896fee6f947765b44b0d80a54b19ce1a] lmb: add and reserve memory
above ram_top
$ git bisect good
22f2c9ed9f533a56bed09bd4e0e37852b6b9f3b1 is the first bad commit
A commit is good if Star64 boots and absent the error about "Not a
PE-COFF file" (duly confirmed by eficonfig to adjust boot order
allowing removable media of an OS installer image on SD Card to be the
priority, verifying that the installer runs as expected). A commit is
bad if U-Boot crashes and/or has the error "Not a PE-COFF file".
Can you post the output of the following. Thanks.
1) running the 'bdinfo' command
U-Boot SPL 2024.10-00989-geb052cbb896f (Nov 19 2024 - 14:39:43 -0800)
...
StarFive # bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000040000000
-> size = 0x0000000100000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x00000000fff46000
reloc off = 0x00000000bfd46000
Build = 64-bit
current eth = ethernet@16030000
ethaddr = 6c:cf:39:00:75:63
IP addr = <NULL>
fdt_blob = 0x00000000ff72da20
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x13fffffff], 0x100000000 bytes flags: none
reserved.count = 0x2
reserved[0] [0x40000000-0x4005ffff], 0x00060000 bytes flags: no-map
reserved[1] [0xfe729630-0xffffffff], 0x018d69d0 bytes flags: no-overwrite
devicetree = board
serial addr = 0x0000000010000000
width = 0x0000000000000004
shift = 0x0000000000000002
offset = 0x0000000000000000
clock = 0x00000000016e3600
boot hart = 0x0000000000000001
firmware fdt= 0x0000000042200000
U-Boot SPL 2025.01-rc2-00129-g7fe55182d926 (Nov 19 2024 - 19:56:55 -0800)
...
StarFive # bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000040000000
-> size = 0x0000000100000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x00000000fff46000
reloc off = 0x00000000bfd46000
Build = 64-bit
current eth = ethernet@16030000
ethaddr = 6c:cf:39:00:75:63
IP addr = <NULL>
fdt_blob = 0x00000000ff72da10
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x13fffffff], 0x100000000 bytes, flags: none
reserved.count = 0x3
reserved[0] [0x40000000-0x4005ffff], 0x60000 bytes, flags: no-map
reserved[1] [0xfe72d620-0xffffffff], 0x18d29e0 bytes, flags: no-overwrite
reserved[2] [0x13fffb000-0x13fffffff], 0x5000 bytes, flags:
no-notify, no-overwrite
devicetree = board
serial addr = 0x0000000010000000
width = 0x0000000000000004
shift = 0x0000000000000002
offset = 0x0000000000000000
clock = 0x00000000016e3600
boot hart = 0x0000000000000001
firmware fdt= 0x0000000042200000
Differences in bdinfo output between working (parent of the
regression) and non-working (origin/master) version:
-fdt_blob = 0x00000000ff72da20
+fdt_blob = 0x00000000ff72da10
lmb_dump_all:
memory.count = 0x1
- memory[0] [0x40000000-0x13fffffff], 0x100000000 bytes flags: none
- reserved.count = 0x2
- reserved[0] [0x40000000-0x4005ffff], 0x00060000 bytes flags: no-map
- reserved[1] [0xfe729630-0xffffffff], 0x018d69d0 bytes flags: no-overwrite
+ memory[0] [0x40000000-0x13fffffff], 0x100000000 bytes, flags: none
+ reserved.count = 0x3
+ reserved[0] [0x40000000-0x4005ffff], 0x60000 bytes, flags: no-map
+ reserved[1] [0xfe72d620-0xffffffff], 0x18d29e0 bytes, flags: no-overwrite
+ reserved[2] [0x13fffb000-0x13fffffff], 0x5000 bytes, flags:
no-notify, no-overwrite
2) do you get any errors when running the 'bootefi bootmgr' command
other than what you mention above
U-Boot SPL 2024.10-00989-geb052cbb896f (Nov 19 2024 - 14:39:43 -0800)
...
StarFive # bootefi bootmgr
Booting: mmc 0
error: no suitable video mode found.
U-Boot SPL 2025.01-rc2-00129-g7fe55182d926 (Nov 19 2024 - 19:56:55 -0800)
...
StarFive # bootefi bootmgr
Card did not respond to voltage select! : -110
Not a PE-COFF file
Loading Boot0000 'mmc 0' failed
Loading Boot0001 'nvme 0' failed
EFI boot manager: Cannot load any image
3) What exactly do you mean by "global EFI boot is successful"
I don't know what the correct name of it is. EFI can boot with what I
am labeling as global EFI boot and searching for fixed path names (?),
or I guess it can decide from EFI variables what to do which I
consider to be the user-configured EFI boot. One of these (the
user-configured EFI boot) is broken since the regression.
U-Boot SPL 2024.10-00989-geb052cbb896f (Nov 19 2024 - 14:39:43 -0800)
...
Card did not respond to voltage select! : -110
Failed to load EFI variables
** Booting bootflow '<NULL>' with efi_mgr
Booting: mmc 0
error: no suitable video mode found.
U-Boot SPL 2025.01-rc2-00129-g7fe55182d926 (Nov 19 2024 - 19:56:55 -0800)
...
Card did not respond to voltage select! : -110
Failed to load EFI variables
** Booting bootflow '<NULL>' with efi_mgr
Not a PE-COFF file
Loading Boot0000 'mmc 0' failed
Loading Boot0001 'nvme 0' failed
EFI boot manager: Cannot load any image
Boot failed (err=-14)
** Booting bootflow '[email protected]_1' with efi
Booting /\EFI\BOOT\BOOTRISCV64.EFI
error: no suitable video mode found.
Based on the logs above, it seems like you are booting using the
bootmeth efi_mgr? If so, can you try disabling the bootstd config. I
might be wrong, but I remember some issues with the bootstd efi_mgr
method on some other platform. Also, are you available on irc?
-sughosh
-sughosh
For context, the Star64 eMMC contains here an installed Debian Linux
OS in the usual way with Grub2 EFI on the EFI System Partition there,
and that image boots fine from U-Boot v2024.10 also when loaded into
memory and using 'bootefi' directly on that memory address.
Thanks,
-E Shattow
Confirming that some discussion about this happened off-list with a
positive result and now awaiting a fix.
I tried to reproduce this issue on the qemu arm64 virt platform, with
4GB of DRAM memory starting from 0x4000_0000 - 0x1_4000_0000. This is
the exact same memory map for DRAM memory as on your board. I also
modified the value of ram_top to 4GB, as on your board. But I am
unable to hit this on the qemu arm64 platform when I try to boot the
Debian image with 'bootefi bootmgr' command. The only difference that
I see is that on the qemu emulator, the OS is on a virtio disk, as
against mmc in your case. So I think we should try to get to the root
cause of this. I think you mentioned on irc yesterday that you observe
this on two boards, so there is definitely something going on here.
-sughosh
Thanks very much! -E
Hello Eric,
I reproduced the issue you had with the Debian installer on a Pine64
Star64 with 8 GiB.
try_load_from_media: file_path =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,6d00000000000000)/SD(1)/SD(1)
no file name present, try default file
try_load_from_media: final_dp =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,6d00000000000000)/SD(1)/SD(1)/HD(2,0x01,0,0x1da800,0x1000)/\EFI\BOOT\BOOTRISCV64.EFI
efi_load_image_from_file: buffer 0x23feab000, size 0x11d000
efi_load_pe: efi 0x000000023feab000, size 0x11d000
Not a PE-COFF file
Loading Boot0000 'mmc 1' failed
EFI boot manager: Cannot load any image
Boot failed (err=-14)
Card did not respond to voltage select! : -110
** Booting bootflow '[email protected]_2' with efi
efi_install_fdt: fdt copied to 0x000000023ffba000
Booting /\EFI\BOOT\BOOTRISCV64.EFI
efi_load_pe: efi 0x0000000040200000, size 0x11d000
error: no such device: /.disk/info.
So loading to high memory fails though CONFIG_BOUNCE_BUFFER is enabled.
With CONFIG_EFI_LOADER_BOUNCE_BUFFER=y booting the Debian installer
image succeeds.
In efi_disk.c we call disk_blk_read(). But CONFIG_BOUNCE_BUFFER is only
evaluated in blk_read() same for write. This should be changed.
CONFIG_EFI_LOADER_BOUNCE_BUFFER should not depend on an architecture.
@Hal, @Minda
The MMC driver not supporting addresses over 4GiB, is this due to a
hardware deficiency or can that be fixed in the U-Boot driver?
Best regards
Heinrich
