Hi Tom, On Sun, Dec 8, 2024, 08:51 Tom Rini <tr...@konsulko.com> wrote: > > On Sun, Dec 08, 2024 at 08:28:42AM -0700, Simon Glass wrote: > > Hi, > > > > On Sun, 1 Dec 2024 at 09:15, Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Matthew, > > > > > > On Sat, 23 Nov 2024 at 12:56, Matthew Garrett <mj...@srcf.ucam.org> wrote: > > > > > > > > We run a mixed environment including traditional embedded Linux and > > > > UEFI. For consistency it's valuable to use U-Boot in both cases, but on > > > > UEFI systems we want to run the full Linux kernel UEFI boot stub. This > > > > patchset adds support for that, along with various other quality-of-life > > > > improvements such as automatically finding partitions based on their > > > > GUID, automatic identification of load addresses where the firmware has > > > > given us constraints, support for EFI variable access in the EFI app, > > > > drivers for EFI network adapters and TPMs, support for embedding DTBs in > > > > the EFI app, and a couple of bug fixes. > > > > > > > > > > > > Janis Danisevskis (1): > > > > Fix efi_bind_block. > > > > > > > > Matthew Garrett (9): > > > > Add EFI handover support to bootm > > > > Add part_find command > > > > Add a command to find a load address > > > > Hook up EFI env variable support in the EFI app > > > > Add EFI network driver > > > > Add UEFI TPM2 driver > > > > Support separate DTB files with the UEFI app > > > > Use the correct ramdisk address > > > > Add command to set an environment variable to an EFI variable > > > > > > > > Makefile | 7 +- > > > > arch/x86/config.mk | 2 +- > > > > arch/x86/lib/bootm.c | 60 ++++++++---- > > > > arch/x86/lib/elf_x86_64_efi.lds | 4 + > > > > boot/bootm.c | 5 + > > > > cmd/Kconfig | 23 ++++- > > > > cmd/Makefile | 3 + > > > > cmd/addr_find.c | 87 +++++++++++++++++ > > > > cmd/efigetenv.c | 133 ++++++++++++++++++++++++++ > > > > cmd/part_find.c | 156 ++++++++++++++++++++++++++++++ > > > > drivers/net/Kconfig | 7 ++ > > > > drivers/net/Makefile | 1 + > > > > drivers/net/efi_net.c | 110 +++++++++++++++++++++ > > > > drivers/tpm/Kconfig | 7 ++ > > > > drivers/tpm/Makefile | 1 + > > > > drivers/tpm/tpm2_efi.c | 97 +++++++++++++++++++ > > > > include/asm-generic/sections.h | 1 + > > > > include/bootm.h | 6 ++ > > > > include/efi.h | 24 +++++ > > > > include/efi_tcg2.h | 1 + > > > > lib/efi/Makefile | 2 +- > > > > lib/efi/efi.c | 1 + > > > > lib/efi/efi_app.c | 41 ++++++++ > > > > lib/efi/efi_app_init.c | 163 ++++++++++++++++++++++++++++++-- > > > > lib/efi/efi_dtb.S | 6 ++ > > > > lib/efi/efi_vars.c | 44 +++++++++ > > > > lib/fdtdec.c | 3 + > > > > 27 files changed, 967 insertions(+), 28 deletions(-) > > > > create mode 100644 cmd/addr_find.c > > > > create mode 100644 cmd/efigetenv.c > > > > create mode 100644 cmd/part_find.c > > > > create mode 100644 drivers/net/efi_net.c > > > > create mode 100644 drivers/tpm/tpm2_efi.c > > > > create mode 100644 lib/efi/efi_dtb.S > > > > create mode 100644 lib/efi/efi_vars.c > > > > > > > > -- > > > > 2.47.0 > > > > > > > > > > Thank you for sending this and for your interesting talk at plumbers. > > > It is a novel approach and potentially provides an alternative to grub > > > and EFI_LOADER, etc. > > > > > > I'd like to try getting this running in CI as we don't have any such > > > tests for the app or payload at present. > > > > I'm planning to pull this in as this seems like an important use case. > > I'm not sure how much time Matthew will have for this, and I want to > > avoid this series going stale. > > > > The comments which are not 'why do you want to do this?' are fairly > > minor, so I'll send a follow-up to resolve them next week. We should > > also think about what code we could move from lib/efi_loader to > > lib/efi so we can share it with the app. > > > > Matthew, thanks again for sending this. if you are planning to do more > > here in the short term, please let me know. > > Please don't grab other peoples patch series and pick them up for your, > well, whatever you want to call "ci/master". You can do what you like > with patches you wrote but taking submissions from others is just going > to confuse the situation as to if you are, or are not, forking the > project at this point.
This is a special situation as I had requested the series based on a talk that I saw. I am interested in building on this work and obviously don't want to do it on an out-of-tree basis. I have to say I felt quite uncomfortable at the response we gave this new contributor. If I had received such a response on my first series to U-Boot I would never have come back. I intend to keep the openness to new ideas in the future. Re the patchwork thing, it was temporary while I was bringing in the series. It should be fixed now. Regards, Simon
