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