On Tue, 21 Apr 2020 at 22:59, Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: > > On Tue, 21 Apr 2020 00:24:04 PDT (-0700), ardb@xxxxxxxxxx wrote: > > On Tue, 21 Apr 2020 at 05:34, Atish Patra <atish.patra@xxxxxxx> wrote: > >> > >> This series adds UEFI support for RISC-V. Currently, only boot time > >> services have been added. Runtime services will be added in a separate > >> series. This series depends on some core EFI patches > >> present in current in efi-next and following other patches. > >> > >> U-Boot: Adds the boot hartid under chosen node. > >> https://lists.denx.de/pipermail/u-boot/2020-April/405726.html > >> > >> Linux kernel: 5.7-rc1 > >> > >> OpenSBI: master > >> > >> Patch 1 just moves arm-stub code to a generic code so that it can be used > >> across different architecture. > >> > >> Patch 3 adds fixmap bindings so that CONFIG_EFI can be compiled and we do not > >> have create separate config to enable boot time services. > >> As runtime services are not enabled at this time, full generic early ioremap > >> support is also not added in this series. > >> > >> Patch 4 and 5 adds the PE/COFF header and EFI stub code support for RISC-V > >> respectively. > >> > >> The patches can also be found in following git repo. > >> > >> https://github.com/atishp04/linux/tree/wip_uefi_riscv_v4 > >> > >> The patches have been verified on Qemu using bootefi command in U-Boot. > >> > >> Changes from v3->v4: > >> 1. Rebased on top of efi-next. > >> 2. Dropped patch 1 & 2 from this series as it is already queued in efi-next. > >> Changes from v2->v3: > >> 3. Improved handle_kernel_image() for RISC-V. > >> > > > > Thanks Atish. This looks nice and simple now. > > > > I will need an ack from the RISC-V maintainers on these, and it is up > > to them to consider whether the changes to core kconfigs and makefiles > > are likely to cause trouble or not. If so, I am happy to work out a > > way to merge this via a shared stable branch. > > Sorry it took me a while to get around to these, but they're essentially good > with me. There's some comments about needing ISA_C/c.li, but that's pretty > trivial. In terms of mechanics: I don't really ever understand how to do these > multi-tree merges. In an ideal world I'd like to have the arch/riscv/ stuff > stay in riscv/for-next, both because I don't want to deal with merge conflicts > and because that's where the RISC-V autobuilders look. > > The best I can come up with is to split #3 up such that drivers/firmware/efi/ > is its own patch and then send that up along with the PE header definitions > into an RC. It'd be unused code at that point, but at least it'd break the > dependency between the trees and it'll be getting tested in riscv/for-next so > it won't rot. We can ARMSTUB->GENERIC_STUB by just having the RISC-V support > select woth ARMSTUB and GENERIC_STUB, with a cleanup going in after everything > is merged. > > That said, I'm happy if there's a better way to do this... > I'll reshuffle the code a bit, and send out an updated series. If we are all happy with that, I will stick the first 2 patches on a shared tag that you can pull into your branch, and you can apply the remaining 4 patches on top of that. Are you ok with a tag based on v5.7-rc2?
