On Mon, 24 Feb 2020 at 23:20, Atish Patra 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
> ---
> 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
>
