
On Wed, 20 Nov 2024 at 13:49, E Shattow lucent@gmail.com wrote:
Hi all, (on-list)
On Tue, Nov 19, 2024 at 9:14 PM Sughosh Ganu sughosh.ganu@linaro.org wrote:
On Wed, 20 Nov 2024 at 10:09, E Shattow lucent@gmail.com wrote:
On Tue, Nov 19, 2024 at 6:42 PM Sughosh Ganu sughosh.ganu@linaro.org wrote:
On Wed, 20 Nov 2024 at 04:48, E Shattow lucent@gmail.com 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.
- 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
- 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
- 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 'mmc@16010000.bootdev.part_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