Hi Heinrich and Tom, thanks. I reproduced it in qemu too, there was a mistake in the way I was setting the network device path. I will send a patch.
Best, Adriano El jue, 5 dic 2024 a las 15:06, Heinrich Schuchardt (<[email protected]>) escribió: > On 05.12.24 16:19, Tom Rini wrote: > > On Thu, Dec 05, 2024 at 10:00:11AM +0100, Heinrich Schuchardt wrote: > >> On 05.12.24 02:30, Tom Rini wrote: > >>> On Wed, Dec 04, 2024 at 12:05:23AM -0300, Adriano Cordova wrote: > >>> > >>>> Set the device path of the efi boot device to an HTTP device path > >>>> (as formed by efi_dp_from_http) when the next boot stage is loaded > >>>> using wget (i.e., when wget is used with wget_info.set_bootdev=1). > >>>> > >>>> When loaded from HTTP, the device path should account for it so that > >>>> the next boot stage is aware (e.g. grub only loads its http stack if > >>>> it itself was loaded from http, and it checks this from its device > path). > >>>> > >>>> Signed-off-by: Adriano Cordova <[email protected]> > >>>> Reviewed-by: Heinrich Schuchardt <[email protected]> > >>> > >>> I know this is applied now, but after re-checking some things in one of > >>> my labs, this breaks test_efi_helloworld_builtin on rpi_3 at least (and > >>> possibly others). There is no output from "bootefi hello". > >>> > >> > >> Hello Tom, > >> > >> None of the Raspberry Pi 3 related defconfigs enables bootefi hello: > >> > >> rpi_3_32b_defconfig # CONFIG_CMD_BOOTEFI_HELLO is not set > >> rpi_3_defconfig # CONFIG_CMD_BOOTEFI_HELLO is not set > >> rpi_3_b_plus_defconfig # CONFIG_CMD_BOOTEFI_HELLO is not set > >> rpi_arm64_defconfig # CONFIG_CMD_BOOTEFI_HELLO is not set > >> > >> Which configuration have you been testing? > >> > >> Please, supply the .config and the related test log. > >> > >> I just tested pinea64-lts_defconfig with CONFIG_CMD_BOOTEFI_HELLO=y and > get > >> > >> => bootefi hello > >> Card did not respond to voltage select! : -110 > >> Booting /MemoryMapped(0x0,0xbdfbe9b0,0xbdfc1b60) > >> Hello, world! > >> Running on UEFI 2.10 > >> Firmware vendor: Das U-Boot > >> Firmware revision: 20250100 > >> Have device tree > >> Load options: <none> > >> File path: <none> > >> Boot device: /MemoryMapped(0x0,0xbdfbe9b0,0xbdfc1b60) > >> > >> So there seems to be no generic problem. > > > > For testing as much as possible, I do enable a number of additional > > options (as well as building them with clang). In this case, please try > > also enabling CONFIG_CMD_WGET. I've narrowed my config changes down to > > adding both CONFIG_CMD_BOOTEFI_HELLO=y and CONFIG_CMD_WGET=y to > > rpi_3_defconfig which results in: > > ============================= test session starts > ============================== > > platform linux -- Python 3.11.2, pytest-6.2.5, py-1.11.0, pluggy-0.13.0 > > rootdir: /home/trini/u-boot/u-boot/test/py, configfile: pytest.ini > > plugins: forked-1.6.0, xdist-2.5.0 > > collected 478 items / 424 deselected / 54 selected > > > > test/py/tests/test_efi_fit.py s > [ 1%] > > test/py/tests/test_efi_loader.py .....F > > > > =================================== FAILURES > =================================== > > _________________________ test_efi_helloworld_builtin > __________________________ > > test/py/tests/test_efi_loader.py:208: in test_efi_helloworld_builtin > > assert expected_text in output > > E AssertionError: assert 'Hello, world' in '' > > ----------------------------- Captured stdout call > ----------------------------- > > U-Boot> bootefi hello > > U-Boot> > > =========================== short test summary info > ============================ > > SKIPPED [1] test/py/conftest.py:620: .config feature "fit" not enabled > > FAILED test/py/tests/test_efi_loader.py::test_efi_helloworld_builtin - > Assert... > > !!!!!!!!!!!!!!!!!!!!!!!!!! stopping after 1 failures > !!!!!!!!!!!!!!!!!!!!!!!!!!! > > =========== 1 failed, 5 passed, 1 skipped, 424 deselected in 27.01s > ============ > > > > Hello Adriano, > > The following command sequence reproduces the problem on my Raspberry Pi 3: > > U-Boot> setenv autoload no > U-Boot> dhcp > lan78xx_eth Waiting for PHY auto negotiation to complete...... done > BOOTP broadcast 1 > DHCP client bound to address 192.168.1.83 (109 ms) > U-Boot> setenv autoload yes > U-Boot> tftpboot 192.168.1.2:/arm64/helloworld.efi > lan78xx_eth Waiting for PHY auto negotiation to complete...... done > Using lan78xx_eth device > TFTP from server 192.168.1.2; our IP address is 192.168.103.83 > Filename '/arm64/helloworld.efi'. > Load address: 0x1000000 > Loading: ################################################## 4.4 KiB > 198.2 KiB/s > done > Bytes transferred = 4480 (1180 hex) > U-Boot> bootefi $loadaddr > Card did not respond to voltage select! : -110 > Booting /\arm64\helloworld.efi > Hello, world! > Running on UEFI 2.: > Have device tree > Load options: <none> > U-Boot> wget 192.168.1.2:/hweb/arm64/helloworld.efi > lan78xx_eth Waiting for PHY auto negotiation to complete...... done > HTTP/1.1 200 OK > Packets received 7, Transfer Successful > Bytes transferred = 4480 (1180 hex) > U-Boot> bootefi $loadaddr > Booting /\hweb\arm64\helloworld.efi > Hello, world! > Running on UEFI 2.: > Have device tree > Load options: <none> > U-Boot> bootefi hello > U-Boot> > > I was not able to reproduce the problem with only TFTP or only wget. > > qemu_arm64_defconfig shows the same issue. > > efi_install_multiple_protocol_interfaces() called in efi_run_image() > returns EFI_ALREADY_STARTED. > > With a debug message enabled we get this output: > > Path /MemoryMapped(0x0,0x7f762d10,0x7f765ec0) already installed > > We have to these things to check: > > * Why do we miss to uninstall the memory device-path when executing > 'bootefi $loadaddr'? > * Why do we generate a memory device-path for either TFTP or wget? > > Best regards > > Heinrich >
