Pull request for efi-2023-04-rc3-2

Ilias Apalodimas ilias.apalodimas at linaro.org
Fri Feb 24 15:52:06 CET 2023


Hi all,

Just to put some context

On Fri, 24 Feb 2023 at 16:44, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 2/24/23 15:42, Tom Rini wrote:
> > On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote:
> >> The following changes since commit 8c39999acb726ef083d3d5de12f20318ee0e5070:
> >>
> >>    Merge branch 'master' of
> >> https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29
> >> -0500)
> >>
> >> are available in the Git repository at:
> >>
> >>    https://source.denx.de/u-boot/custodians/u-boot-efi.git
> >> tags/efi-2023-04-rc3-2
> >>
> >> for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8:
> >>
> >>    cmd: bootefi: allocate device-tree copy from high memory (2023-02-24
> >> 07:44:35 +0100)
> >>
> >> Gitlab CI showed no issues:
> >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340
> >>
> >> ----------------------------------------------------------------
> >> Pull request for efi-2023-04-rc3-2
> >>
> >> Documentation:
> >>      Fix links to fwu_updates.rst
> >
> > This is a fix.
> >
> >>
> >> UEFI:
> >>      Allocate device-tree copy from high memory in bootefi command
> >
> > This I think counts as a fix, but I'm a little confused about allocate
> > in this context. Can you point me at the patch please?

https://source.denx.de/u-boot/custodians/u-boot-efi/-/commit/0bb5d6b1e4105ec4215239958830a396658bfed8

The TL;DR is that we were placing the DT on 127mb.  This might
overwrite previously loaded binaries. The efi-stub of the linux kernel
doesn't use the DTB in place.  Instead, it copies it and adds some
nodes for the efi-stub -> kernel proper handover (e.g a kaslr-seed).
So we as far as linux is concerned we are free to place the DT
wherever we want.

Unless people from risc-v want this in *now*, we are better of landing
this in -next.

> >
> >>      Correct attributes checks in SetVariable()

This can wait.  This fixes one minor issue on the SystemReady Security
extensions test suite. This is a test suite (mostly running as EFI
apps) from Arm to check conformance for UEFI Secure Boot and Measured
boot.

> >
> > This is a fix..
> >
> >> Other:
> >>      Allow SPL to load main U-Boot via partition type GUID
> >
> > This is new functionality, and I didn't quite see that everyone agreed
> > this was a good idea? Not for master at this point in the cycle.
>
> Would you take it for next?

Regards
/Ilias

>
> Best regards
>
> Heinrich
>
> >
> >>      Test case for crc8 function
> >
> > This I suppose can count as a fix.
> >
>


More information about the U-Boot mailing list