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

[Heinrich Schuchardt]

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