Re: Pull request efi-next-20250104

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4211 bytes --]

On Mon, Mar 31, 2025 at 11:28:34PM +0200, Heiko Stübner wrote:
> Hi,
> 
> Am Samstag, 4. Januar 2025, 04:19:40 MESZ schrieb Heinrich Schuchardt:
> > Dear Tom,
> > 
> > The following changes since commit ec9263b4f15c4cf82eb6a211c67baa6385065b8e:
> > 
> >    Fix neighbor discovery ethernet address saving (2025-01-01 14:40:04
> > -0600)
> > 
> > are available in the Git repository at:
> > 
> >    https://source.denx.de/u-boot/custodians/u-boot-efi.git
> > tags/efi-next-20250104
> > 
> > for you to fetch changes up to ce190e1b33b8c0e1228f4123759dfa1981c202de:
> > 
> >    efi: Correct ECPT table GUID (2025-01-04 02:17:06 +0100)
> > 
> > Gitlab CI reported no issues:
> > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/24075
> > 
> > ----------------------------------------------------------------
> > Pull request efi-next-20250104
> > 
> > Documentation:
> > 
> > * doc: develop: Fix typos and wording in binman/binman.rst
> > * doc: develop: Fix typos and wording in gdb.rst
> > * doc: sandbox: Fix the "sb" command name
> > * doc/develop/distro.rst: Better document upstream definition of
> > extlinux.conf
> > 
> > UEFI:
> > 
> > With this pull request the UEFI sub-system detects all boot devices even
> > if they have not been probed before. If this adds to much boot delay
> > individual bootmeths and bootdevs can be disabled via the customizing.
> > 
> > * efi_loader: avoid writing message in Exit() boot service
> > * efi_loader: run bootdev_hunt() to find ESP
> > * efi_loader: update EFI specification version
> > * cmd: efidebug: update output of memory attributes
> > * efi_loader: Don't warn if the TCG2 FinalEvents table is not installed
> > * cmd: bootmenu: add parameter -e for UEFI boot options
> > * efi_loader: Update startimage_exit self-test to check error
> > * efi: Correct ECPT table GUID
> > 
> > Others:
> > 
> > Building the API demo application for riscv64 is supported.
> > 
> > * API: unify platform_sys_info() implementations
> > * examples: implement _start and syscall for RISC-V
> > * examples: use architecture specific memset() on RISC-V
> > * examples: use QEMU compatible LOAD_ADDR on RISC-V
> > * test: fix test_extension.py
> > * configs: sandbox_deconfig: remove CONFIG_AMIGA_PARTITION
> > * CI: xilinx_versal_virt: disable USB_DWC3
> > * net: eth_bootdev_hunt() should not run DHCP
> > 
> > ----------------------------------------------------------------
> > Adriano Cordova (1):
> >        efi_loader: Expose efi_reinstall_protocol_interface in efi_loader.h
> > 
> > Aleksandar Gerasimovski (1):
> >        efi_loader: fix pe reloc pointer overrun
> > 
> > Heinrich Schuchardt (13):
> >        API: unify platform_sys_info() implementations
> >        examples: implement _start and syscall for RISC-V
> >        examples: use architecture specific memset() on RISC-V
> >        examples: use QEMU compatible LOAD_ADDR on RISC-V
> >        efi_loader: avoid writing message in Exit() boot service
> >        test: fix test_extension.py
> >        configs: sandbox_deconfig: remove CONFIG_AMIGA_PARTITION
> >        CI: xilinx_versal_virt: disable USB_DWC3
> 
> 
> >        net: eth_bootdev_hunt() should not run DHCP
> 
> this change seems to break the "normal" pxe boot from distroboot on
> (at least one, but probably all) Rockchip board(s).
> 
> Up to u-boot 2025.01 distro-boot on Rockchip boards just worked
> normally, the network came up, dhcp ran (and provided the tftp-server
> address in my setup) and then "pxe" could retrieve the pxelinux.cfg/foo...
> file.
> 
> Trying the same setup on 2025.04-rc5 does not work anymore, because
> that dhcp is never run, before pxe tries to get its file.
> 
> Of course running the dhcp manually before handing over to distro-boot
> works, but that needs human interaction. Similarly reverting that patch
> also makes things works again ;-) .
> 
> 
> So while EFI might be faster now, pxe from distroboot is broken and I'm
> wondering, who is supposed to do the dhcp call now?

Well, it's not an intentional regression. I guess we need a revert for
today and a plan for tomorrow.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]