[PATCH v7 08/14] efi_loader: net: set EFI bootdevice device path to HTTP when loaded from wget

[Adriano Córdova]

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 (<xypron.glpk at gmx.de>)
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 <adrianox at gmail.com>
> >>>> Reviewed-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> >>>
> >>> 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
>