[BUG regression in HEAD] efi: memory: use the lmb API's for allocating and freeing memory
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".
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.
Best regards,
-E Shattow
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.
1) running the 'bdinfo' command
2) do you get any errors when running the 'bootefi bootmgr' command other than what you mention above
3) What exactly do you mean by "global EFI boot is successful"
-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.
Best regards,
-E Shattow
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.
-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
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
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.
Thanks very much! -E
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
On Thu, 21 Nov 2024 at 13:34, Sughosh Ganu sughosh.ganu@linaro.org wrote:
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.
Heinrich figured out that this is an issue with the mmc driver on these platforms. So it looks like the mmc driver is unable to load any data to addresses above 4GB. E Shattow confirmed this by trying to load an image from the mmc to an address above 4GB with the 'load mmc' command, which failed. Loading the same to an address below 4GB works. I am unaware of the mmc controller IP, so why is the mmc driver not able to access memory addresses above 4GB would have to be investigated. Thanks.
-sughosh
-sughosh
Thanks very much! -E
On 21.11.24 09:04, Sughosh Ganu wrote:
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
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 'mmc@16020000.bootdev.part_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
Following up on this with some positive results:
On Thu, Nov 21, 2024 at 4:22 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 21.11.24 09:04, Sughosh Ganu wrote:
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
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 'mmc@16020000.bootdev.part_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
A combination of these two series remedy this issue:
"configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER" "bouncebuf: Allow allocation from U-Boot heap"
Tested on 4GB Milk-V Mars CM Lite, 8GB Milk-V Mars CM Lite WiFi, 4GB Pine64 Star64.
Sughosh can you please add to your series my Tested-by: E Shattow lucent@gmail.com
Google inexplicably failed to deliver your patch series message(s) to my e-mail account, it is not in spam folder or anything it just never made it through even though I am CC and a list subscriber. If the messages do later appear on my e-mail account I will reply there. Tom mentioned some quirk of non-subscribers getting flagged with Google mail accounts but this is weird that I don't get any message when I am on the CC directly - could be a question for Linaro if they're getting bounces from Google mail or what...
-E
Replying my own message postscript
On Wed, Nov 27, 2024 at 4:47 AM E Shattow lucent@gmail.com wrote:
Following up on this with some positive results:
On Thu, Nov 21, 2024 at 4:22 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 21.11.24 09:04, Sughosh Ganu wrote:
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.
> > 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 '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
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 'mmc@16020000.bootdev.part_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
A combination of these two series remedy this issue:
"configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER" "bouncebuf: Allow allocation from U-Boot heap"
Tested on 4GB Milk-V Mars CM Lite, 8GB Milk-V Mars CM Lite WiFi, 4GB Pine64 Star64.
Sughosh can you please add to your series my Tested-by: E Shattow lucent@gmail.com
...
-E
Postscript I'm getting failure when 'load mmc' a large file, but success 'load mmc' a small file. Same applies for 'bootefi bootmgr' whatever file access it is making.
Okay admittedly I am frustrated and confused what is our testing methodology here? I don't actually know what is broken (something unspecified in an mmc driver) and what we are fixing (preventing the new behavior which does not agree with the old driver - how?).
The problem appears to be a broken mmc implementation and we are not fixing that by these buffering tricks.
-E
On Wed, 27 Nov 2024 at 19:41, E Shattow lucent@gmail.com wrote:
Replying my own message postscript
On Wed, Nov 27, 2024 at 4:47 AM E Shattow lucent@gmail.com wrote:
Following up on this with some positive results:
On Thu, Nov 21, 2024 at 4:22 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 21.11.24 09:04, Sughosh Ganu wrote:
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. > >> >> 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 '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
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 'mmc@16020000.bootdev.part_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
A combination of these two series remedy this issue:
"configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER" "bouncebuf: Allow allocation from U-Boot heap"
Tested on 4GB Milk-V Mars CM Lite, 8GB Milk-V Mars CM Lite WiFi, 4GB Pine64 Star64.
Sughosh can you please add to your series my Tested-by: E Shattow lucent@gmail.com
...
-E
Postscript I'm getting failure when 'load mmc' a large file, but success 'load mmc' a small file. Same applies for 'bootefi bootmgr' whatever file access it is making.
Okay admittedly I am frustrated and confused what is our testing methodology here? I don't actually know what is broken (something unspecified in an mmc driver) and what we are fixing (preventing the new behavior which does not agree with the old driver - how?).
The problem appears to be a broken mmc implementation and we are not fixing that by these buffering tricks.
As discussed offline, this is because you are trying to load a very big file, and your platform only has 8MB of heap region. And I don't think that loading multiple MB's of data from mmc is an unusual scenario. I am thinking now that the original change which I had shared with you would be the most appropriate solution for this.
-sughosh
-E
On 27.11.24 16:21, Sughosh Ganu wrote:
On Wed, 27 Nov 2024 at 19:41, E Shattow lucent@gmail.com wrote:
Replying my own message postscript
On Wed, Nov 27, 2024 at 4:47 AM E Shattow lucent@gmail.com wrote:
Following up on this with some positive results:
On Thu, Nov 21, 2024 at 4:22 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 21.11.24 09:04, Sughosh Ganu wrote:
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. >> >>> >>> 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 '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
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 'mmc@16020000.bootdev.part_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
A combination of these two series remedy this issue:
"configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER" "bouncebuf: Allow allocation from U-Boot heap"
Tested on 4GB Milk-V Mars CM Lite, 8GB Milk-V Mars CM Lite WiFi, 4GB Pine64 Star64.
Sughosh can you please add to your series my Tested-by: E Shattow lucent@gmail.com
...
-E
Postscript I'm getting failure when 'load mmc' a large file, but success 'load mmc' a small file. Same applies for 'bootefi bootmgr' whatever file access it is making.
Okay admittedly I am frustrated and confused what is our testing methodology here? I don't actually know what is broken (something unspecified in an mmc driver) and what we are fixing (preventing the new behavior which does not agree with the old driver - how?).
The problem appears to be a broken mmc implementation and we are not fixing that by these buffering tricks.
As discussed offline, this is because you are trying to load a very big file, and your platform only has 8MB of heap region. And I don't think that loading multiple MB's of data from mmc is an unusual scenario. I am thinking now that the original change which I had shared with you would be the most appropriate solution for this.
I have not seen a distro kernel with less than 8 MiB recently.
Shouldn't the driver work in chunks?
Best regards
Heinrich
On Wed, 27 Nov 2024 at 21:29, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 27.11.24 16:21, Sughosh Ganu wrote:
On Wed, 27 Nov 2024 at 19:41, E Shattow lucent@gmail.com wrote:
Replying my own message postscript
On Wed, Nov 27, 2024 at 4:47 AM E Shattow lucent@gmail.com wrote:
Following up on this with some positive results:
On Thu, Nov 21, 2024 at 4:22 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 21.11.24 09:04, Sughosh Ganu wrote:
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. >>> >>>> >>>> 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 '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
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 'mmc@16020000.bootdev.part_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
A combination of these two series remedy this issue:
"configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER" "bouncebuf: Allow allocation from U-Boot heap"
Tested on 4GB Milk-V Mars CM Lite, 8GB Milk-V Mars CM Lite WiFi, 4GB Pine64 Star64.
Sughosh can you please add to your series my Tested-by: E Shattow lucent@gmail.com
...
-E
Postscript I'm getting failure when 'load mmc' a large file, but success 'load mmc' a small file. Same applies for 'bootefi bootmgr' whatever file access it is making.
Okay admittedly I am frustrated and confused what is our testing methodology here? I don't actually know what is broken (something unspecified in an mmc driver) and what we are fixing (preventing the new behavior which does not agree with the old driver - how?).
The problem appears to be a broken mmc implementation and we are not fixing that by these buffering tricks.
As discussed offline, this is because you are trying to load a very big file, and your platform only has 8MB of heap region. And I don't think that loading multiple MB's of data from mmc is an unusual scenario. I am thinking now that the original change which I had shared with you would be the most appropriate solution for this.
I have not seen a distro kernel with less than 8 MiB recently.
Shouldn't the driver work in chunks?
At least the designware mmc driver does not seem to be working in that fashion. The bounce-buffer logic does not consider breaking down the transfer size in smaller chunks -- I think that is expected from the drivers. But currently, the driver seems to be sending the transaction size as is to the bounce_buffer_start() function. Should be fairly straightforward to ascertain this though, just putting a debug print in the bounce buffer function.
-sughosh
Best regards
Heinrich
From: Sughosh Ganu sughosh.ganu@linaro.org Date: Thu, 28 Nov 2024 15:51:06 +0530
On Wed, 27 Nov 2024 at 21:29, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 27.11.24 16:21, Sughosh Ganu wrote:
On Wed, 27 Nov 2024 at 19:41, E Shattow lucent@gmail.com wrote:
Replying my own message postscript
On Wed, Nov 27, 2024 at 4:47 AM E Shattow lucent@gmail.com wrote:
Following up on this with some positive results:
On Thu, Nov 21, 2024 at 4:22 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 21.11.24 09:04, Sughosh Ganu wrote: > 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. >>>> >>>>> >>>>> 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 '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
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 'mmc@16020000.bootdev.part_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
A combination of these two series remedy this issue:
"configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER" "bouncebuf: Allow allocation from U-Boot heap"
Tested on 4GB Milk-V Mars CM Lite, 8GB Milk-V Mars CM Lite WiFi, 4GB Pine64 Star64.
Sughosh can you please add to your series my Tested-by: E Shattow lucent@gmail.com
...
-E
Postscript I'm getting failure when 'load mmc' a large file, but success 'load mmc' a small file. Same applies for 'bootefi bootmgr' whatever file access it is making.
Okay admittedly I am frustrated and confused what is our testing methodology here? I don't actually know what is broken (something unspecified in an mmc driver) and what we are fixing (preventing the new behavior which does not agree with the old driver - how?).
The problem appears to be a broken mmc implementation and we are not fixing that by these buffering tricks.
As discussed offline, this is because you are trying to load a very big file, and your platform only has 8MB of heap region. And I don't think that loading multiple MB's of data from mmc is an unusual scenario. I am thinking now that the original change which I had shared with you would be the most appropriate solution for this.
I have not seen a distro kernel with less than 8 MiB recently.
Shouldn't the driver work in chunks?
At least the designware mmc driver does not seem to be working in that fashion. The bounce-buffer logic does not consider breaking down the transfer size in smaller chunks -- I think that is expected from the drivers. But currently, the driver seems to be sending the transaction size as is to the bounce_buffer_start() function. Should be fairly straightforward to ascertain this though, just putting a debug print in the bounce buffer function.
I have been following this discussion from a distance, but I think you're on the wrong path here with relying on bounce buffers too much. A few observations about the generic bounce buffer implementation in U-Boot:
* Only a small number of drivers actually implement bounce buffer support. While there is support for bounce buffers in the blk layer, this may not be sufficient, and it doesn't help non-blk drivers.
* Bounce buffer support in U-Boot is primarily there to make sure DMA buffers are cache-aligned. That typically is only important for smallish buffers that are allocated on the stack as large memory allocations tend to be properly aligned already.
* Bounce buffers make things slower as they introduce additional memory allocations.
The way U-Boot handles DMA address constraints is by allocating only from the address range that allows DMA by implementing board_get_usable_ram_top(). This works well because boards that have DMA address contraints typically have plenty of RAM that has no DMA restrictions. The typical case is hardware that uses 32-bit DMA descriptors which means memory with addresses above 4G isn't DMA addressable. But those boards have at least 2G of memory below that limit and nobody is going to load a kernel or initrd that comes close to that.
The exception here is EFI. EFI apps (such as bootloaders or kernels with an EFI stub) are typically unaware of any DMA constraints and may allocate memory at an arbitrary address. This is why we have CONFIG_EFI_LOADER_BOUNCE_BUFFER. This implements bounce buffers in the EFI layer and bounces before buffers are handed over to the drivers. So this will work even if the individual drivers don't implement bounce buffers themselves.
Based on these observations:
* Boards that have DMA constraints should implement board_get_usable_ram_top() and should set CONFIG_EFI_LOADER_BOUNCE_BUFFER=y.
* The lmb memory allocations should by default return memory below that limit.
Cheers,
Mark
On Thu, 28 Nov 2024 at 16:44, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Sughosh Ganu sughosh.ganu@linaro.org Date: Thu, 28 Nov 2024 15:51:06 +0530
On Wed, 27 Nov 2024 at 21:29, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 27.11.24 16:21, Sughosh Ganu wrote:
On Wed, 27 Nov 2024 at 19:41, E Shattow lucent@gmail.com wrote:
Replying my own message postscript
On Wed, Nov 27, 2024 at 4:47 AM E Shattow lucent@gmail.com wrote:
Following up on this with some positive results:
On Thu, Nov 21, 2024 at 4:22 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote: > > On 21.11.24 09:04, Sughosh Ganu wrote: >> 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. >>>>> >>>>>> >>>>>> 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 '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 > > 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 'mmc@16020000.bootdev.part_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 > >
A combination of these two series remedy this issue:
"configs: JH7110: enable EFI_LOADER_BOUNCE_BUFFER" "bouncebuf: Allow allocation from U-Boot heap"
Tested on 4GB Milk-V Mars CM Lite, 8GB Milk-V Mars CM Lite WiFi, 4GB Pine64 Star64.
Sughosh can you please add to your series my Tested-by: E Shattow lucent@gmail.com
...
-E
Postscript I'm getting failure when 'load mmc' a large file, but success 'load mmc' a small file. Same applies for 'bootefi bootmgr' whatever file access it is making.
Okay admittedly I am frustrated and confused what is our testing methodology here? I don't actually know what is broken (something unspecified in an mmc driver) and what we are fixing (preventing the new behavior which does not agree with the old driver - how?).
The problem appears to be a broken mmc implementation and we are not fixing that by these buffering tricks.
As discussed offline, this is because you are trying to load a very big file, and your platform only has 8MB of heap region. And I don't think that loading multiple MB's of data from mmc is an unusual scenario. I am thinking now that the original change which I had shared with you would be the most appropriate solution for this.
I have not seen a distro kernel with less than 8 MiB recently.
Shouldn't the driver work in chunks?
At least the designware mmc driver does not seem to be working in that fashion. The bounce-buffer logic does not consider breaking down the transfer size in smaller chunks -- I think that is expected from the drivers. But currently, the driver seems to be sending the transaction size as is to the bounce_buffer_start() function. Should be fairly straightforward to ascertain this though, just putting a debug print in the bounce buffer function.
I have been following this discussion from a distance, but I think you're on the wrong path here with relying on bounce buffers too much. A few observations about the generic bounce buffer implementation in U-Boot:
Only a small number of drivers actually implement bounce buffer support. While there is support for bounce buffers in the blk layer, this may not be sufficient, and it doesn't help non-blk drivers.
Bounce buffer support in U-Boot is primarily there to make sure DMA buffers are cache-aligned. That typically is only important for smallish buffers that are allocated on the stack as large memory allocations tend to be properly aligned already.
Bounce buffers make things slower as they introduce additional memory allocations.
The way U-Boot handles DMA address constraints is by allocating only from the address range that allows DMA by implementing board_get_usable_ram_top(). This works well because boards that have DMA address contraints typically have plenty of RAM that has no DMA restrictions. The typical case is hardware that uses 32-bit DMA descriptors which means memory with addresses above 4G isn't DMA addressable. But those boards have at least 2G of memory below that limit and nobody is going to load a kernel or initrd that comes close to that.
The exception here is EFI. EFI apps (such as bootloaders or kernels with an EFI stub) are typically unaware of any DMA constraints and may allocate memory at an arbitrary address. This is why we have CONFIG_EFI_LOADER_BOUNCE_BUFFER. This implements bounce buffers in the EFI layer and bounces before buffers are handed over to the drivers. So this will work even if the individual drivers don't implement bounce buffers themselves.
Based on these observations:
- Boards that have DMA constraints should implement board_get_usable_ram_top() and should set CONFIG_EFI_LOADER_BOUNCE_BUFFER=y.
Heinrich has enabled the above config symbol in the affected platform's defconfig. But this does not seem to help, and E Shattow has been observing the issues even after this change.
- The lmb memory allocations should by default return memory below that limit.
Yes, I am planning to send a patch which handles this scenario. The current LMB code handles the scenario where DRAM banks which fall above ram_top get reserved, but this scenario of ram_top in the middle of a given bank needs to be handled.
-sughosh
Cheers,
Mark
participants (4)
-
E Shattow -
Heinrich Schuchardt -
Mark Kettenis -
Sughosh Ganu