On Mon, 24 Feb 2020 at 23:20, Atish Patra <[email protected]> wrote: > > Linux booting protocol mandates that register "a0" contains the hartid. > However, U-boot can not pass the hartid via a0 during EFI boot without > breaking the UEFI specification. >
It is not about breaking or violating the UEFI specification. It is about the firmware using a conduit that is already being used to describe the hardware to the OS to pass an extra piece of information that the OS needs. > Add a DT node under chosen node to indicate the boot hartid. EFI stub > in Linux kernel will parse this node and pass it to the real kernel > in "a0" before jumping to it. > > Signed-off-by: Atish Patra <[email protected]> > --- > arch/riscv/lib/bootm.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c > index fad16901c5f2..b84cc2db2016 100644 > --- a/arch/riscv/lib/bootm.c > +++ b/arch/riscv/lib/bootm.c > @@ -28,6 +28,19 @@ __weak void board_quiesce_devices(void) > > int arch_fixup_fdt(void *blob) > { > + u32 size; > + int chosen_offset, err; > + > + size = fdt_totalsize(blob); > + err = fdt_open_into(blob, blob, size + 32); > + if (err < 0) { > + printf("Device Tree can't be expanded to accmodate new node"); 'accommodate' > + return -1; > + } > + chosen_offset = fdt_path_offset(blob, "/chosen"); > + fdt_setprop_u64(blob, chosen_offset, "efi-boot-hartid", I assume that boot hartid does not change value when you boot via UEFI, so this should simply be /chosen/boot-hartid > + gd->arch.boot_hart); > + > return 0; > } > > -- > 2.24.0 >
