Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4592006ybv; Tue, 25 Feb 2020 23:29:27 -0800 (PST) X-Google-Smtp-Source: APXvYqxSUcpzZwdKCaKykfeikHCVwCVuWyCR3gb1J4MaJLU5zm0+sMwdcMZR5lddlltwsBqzrNaq X-Received: by 2002:a9d:5e18:: with SMTP id d24mr2020881oti.155.1582702166894; Tue, 25 Feb 2020 23:29:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582702166; cv=none; d=google.com; s=arc-20160816; b=X/aoAZ9o4qFJyIYUX7hAZ9J3poWbreYqFIOvrScHEIca7mtLXCPVq9CRFTBIC7JZyS 5p9vIc0WPPKSysKqqfw5mMZ/5KdsmAyelpG2wUUz48BtlD79hsaVDSLFGuoxKvT3sROg NfzTI+qHFcPU6oqfBToUwqYjPG57fzc7WgPn9Sz3IS17/cOkz0JSz8V9z681HgKay2UM /cqANkngnnZVAsr1epnz2zONMHQLD5ngb5xYO6OKPV1bSNkrHw6FYsiL8eD3yrsbzV4M CHM7HYNLrsw5fL/Ul731iPGNYRA5Ql0W3U7+QnfkL4nLp7mG7LILSKsVJhOq7nt/VjdT jtuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6hOqhJin6slJRTo9o/UwU4wdwwg6HMJyJHFCg7NR7vE=; b=nblY3Q9RtLflUycO3YE03zzECIyWYlhzZZD6RjcvKynhSmvKJHsE2+1TUjoqQefns/ cCjcMMg6H5Ss9xt9C1leUwiK6fkKGP2Obu9XI7LyCrqI2y331E0/LA2KnMZBtZV/LzV6 xX8xwp4BFRWRZbJ4XQCj6+YswAqnFWJvX0xXNhzE8WJ+QV52p0/DVNZXoAMCndm1F6zl rhTDQVyLEIkOgt1wK2RzBMyPzNdKTNJ3HGPVk7Ntpdw6j3r1ebL7QiAdVBVwWURlpRB6 dO2biQVFcjnE/ANOZM3LAQWphL2MoX5SqkPr5r33HefgvtBsFxoRiXRjqkuEZs+XliJF SA2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tyKKpFPJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m12si670761oim.195.2020.02.25.23.29.14; Tue, 25 Feb 2020 23:29:26 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tyKKpFPJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727309AbgBZH2n (ORCPT + 99 others); Wed, 26 Feb 2020 02:28:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:54814 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727303AbgBZH2n (ORCPT ); Wed, 26 Feb 2020 02:28:43 -0500 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9FEB824673 for ; Wed, 26 Feb 2020 07:28:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582702122; bh=Jpmvaue+x7NvgWHz2Bnrr5J65mlxuyxU4weChioHbN4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tyKKpFPJuV40kHYnBsG1WZ9ovDUbWRrfCTcxsc3sq3zMEIOuuH6oqGAcbMasK3/a4 3dWgFPPyz9W1/RFn8pWncabUiqo5JP03yAFjMx29LcSYSA43eWH/5qodBSdMQkcGAK TemdHhbI9L9gVzLNp7Ckqm+t8PREINhSPg4hxjxw= Received: by mail-wm1-f47.google.com with SMTP id t14so1805459wmi.5 for ; Tue, 25 Feb 2020 23:28:41 -0800 (PST) X-Gm-Message-State: APjAAAXLr5kAotK1Wc/T3cJL4l7ZIULMwjWt55YVtpZcROx3G/LO9Wc6 6ohltgrBLqy8nUeh+Cqeuv1usrFrxJ0ihUHql2RX9A== X-Received: by 2002:a7b:c4cc:: with SMTP id g12mr4048163wmk.68.1582702119856; Tue, 25 Feb 2020 23:28:39 -0800 (PST) MIME-Version: 1.0 References: <20200226011037.7179-1-atish.patra@wdc.com> <20200226011037.7179-6-atish.patra@wdc.com> In-Reply-To: <20200226011037.7179-6-atish.patra@wdc.com> From: Ard Biesheuvel Date: Wed, 26 Feb 2020 08:28:28 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 5/5] RISC-V: Add EFI stub support. To: Atish Patra Cc: Linux Kernel Mailing List , Albert Ou , Alexios Zavras , Allison Randal , Andrew Morton , Anup Patel , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Greentime Hu , Greg Kroah-Hartman , Ingo Molnar , Kate Stewart , Kees Cook , Linus Walleij , linux-efi , linux-riscv@lists.infradead.org, Mao Han , Mauro Carvalho Chehab , Michal Simek , Mike Rapoport , Palmer Dabbelt , Paolo Bonzini , Paul Walmsley , Russell King , Thomas Gleixner , Will Deacon , Alexander Graf , "leif@nuviainc.com" , "Chang, Abner (HPS SW/FW Technologist)" , "Schaefer, Daniel (DualStudy)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 26 Feb 2020 at 02:10, Atish Patra wrote: > > Add a RISC-V architecture specific stub code that actually copies the > actual kernel image to a valid address and jump to it after boot services > are terminated. Enable UEFI related kernel configs as well for RISC-V. > > Signed-off-by: Atish Patra > --- > arch/riscv/Kconfig | 20 ++++ > arch/riscv/Makefile | 1 + > arch/riscv/configs/defconfig | 1 + > drivers/firmware/efi/libstub/Makefile | 8 ++ > drivers/firmware/efi/libstub/riscv-stub.c | 135 ++++++++++++++++++++++ > 5 files changed, 165 insertions(+) > create mode 100644 drivers/firmware/efi/libstub/riscv-stub.c > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 42c122170cfd..68b1d565e51d 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -372,10 +372,30 @@ config CMDLINE_FORCE > > endchoice > > +config EFI_STUB > + bool > + > +config EFI > + bool "UEFI runtime support" > + depends on OF > + select LIBFDT > + select UCS2_STRING > + select EFI_PARAMS_FROM_FDT > + select EFI_STUB > + select EFI_GENERIC_ARCH_STUB > + default y > + help > + This option provides support for runtime services provided > + by UEFI firmware (such as non-volatile variables, realtime > + clock, and platform reset). A UEFI stub is also provided to > + allow the kernel to be booted as an EFI application. This > + is only useful on systems that have UEFI firmware. > + > endmenu > > menu "Power management options" > > source "kernel/power/Kconfig" > +source "drivers/firmware/Kconfig" > > endmenu > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > index b9009a2fbaf5..0afaa89ba9ad 100644 > --- a/arch/riscv/Makefile > +++ b/arch/riscv/Makefile > @@ -78,6 +78,7 @@ head-y := arch/riscv/kernel/head.o > core-y += arch/riscv/ > > libs-y += arch/riscv/lib/ > +core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a > > PHONY += vdso_install > vdso_install: > diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig > index e2ff95cb3390..0a5d3578f51e 100644 > --- a/arch/riscv/configs/defconfig > +++ b/arch/riscv/configs/defconfig > @@ -125,3 +125,4 @@ CONFIG_DEBUG_BLOCK_EXT_DEVT=y > # CONFIG_FTRACE is not set > # CONFIG_RUNTIME_TESTING_MENU is not set > CONFIG_MEMTEST=y > +CONFIG_EFI=y > diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile > index 2c5b76787126..38facb61745b 100644 > --- a/drivers/firmware/efi/libstub/Makefile > +++ b/drivers/firmware/efi/libstub/Makefile > @@ -21,6 +21,8 @@ cflags-$(CONFIG_ARM64) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ > cflags-$(CONFIG_ARM) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ > -fno-builtin -fpic \ > $(call cc-option,-mno-single-pic-base) > +cflags-$(CONFIG_RISCV) := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \ > + -fpic > > cflags-$(CONFIG_EFI_GENERIC_ARCH_STUB) += -I$(srctree)/scripts/dtc/libfdt > > @@ -55,6 +57,7 @@ lib-$(CONFIG_EFI_GENERIC_ARCH_STUB) += efi-stub.o fdt.o string.o \ > lib-$(CONFIG_ARM) += arm32-stub.o > lib-$(CONFIG_ARM64) += arm64-stub.o > lib-$(CONFIG_X86) += x86-stub.o > +lib-$(CONFIG_RISCV) += riscv-stub.o > CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET) > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET) > > @@ -79,6 +82,11 @@ STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \ > --prefix-symbols=__efistub_ > STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS > > +STUBCOPY_FLAGS-$(CONFIG_RISCV) += --prefix-alloc-sections=.init \ > + --prefix-symbols=__efistub_ > +STUBCOPY_RELOC-$(CONFIG_RISCV) := R_RISCV_HI20 > + > + > $(obj)/%.stub.o: $(obj)/%.o FORCE > $(call if_changed,stubcopy) > > diff --git a/drivers/firmware/efi/libstub/riscv-stub.c b/drivers/firmware/efi/libstub/riscv-stub.c > new file mode 100644 > index 000000000000..3935b29ea93a > --- /dev/null > +++ b/drivers/firmware/efi/libstub/riscv-stub.c > @@ -0,0 +1,135 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2013, 2014 Linaro Ltd; > + * Copyright (C) 2020 Western Digital Corporation or its affiliates. > + * > + * This file implements the EFI boot stub for the RISC-V kernel. > + * Adapted from ARM64 version at drivers/firmware/efi/libstub/arm64-stub.c. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include "efistub.h" > +/* > + * RISCV requires the kernel image to placed TEXT_OFFSET bytes beyond a 2 MB > + * aligned base for 64 bit and 4MB for 32 bit. > + */ > +#if IS_ENABLED(CONFIG_64BIT) You can use #ifdef here > +#define MIN_KIMG_ALIGN SZ_2M > +#else > +#define MIN_KIMG_ALIGN SZ_4M > +#endif > +/* > + * TEXT_OFFSET ensures that we don't overwrite the firmware that probably sits > + * at the beginning of the DRAM. > + */ Ugh. Really? On an EFI system, that memory should be reserved in some way, we shouldn't be able to stomp on it like that. > +#define TEXT_OFFSET MIN_KIMG_ALIGN > + > +typedef __attribute__((noreturn)) void (*jump_kernel_func)(unsigned int, > + unsigned long); > + > +efi_status_t check_platform_features(void) > +{ > + return EFI_SUCCESS; > +} > + > +u64 get_boot_hartid_from_fdt(unsigned long fdt) static > +{ > + int chosen_node, len; > + const fdt64_t *prop; > + uint64_t hartid = U64_MAX; > + > + chosen_node = fdt_path_offset((void *)fdt, "/chosen"); > + if (chosen_node < 0) > + return hartid; Just return U64_MAX here > + prop = fdt_getprop((void *)fdt, chosen_node, "efi-boot-hartid", &len); Please call this 'boot-hartid' not 'efi-boot-hartid' as the hartid value is independent of whether you boot via EFI or not. > + if (!prop || len != sizeof(u64)) > + return hartid; > + Return U64_MAX > + hartid = fdt64_to_cpu(*prop); > + and just return the swabbed value, so you can get rid of the local var. > + return hartid; > +} > + > +/* > + * Jump to real kernel here with following constraints. > + * 1. MMU should be disabled. > + * 2. a0 should contain hartid > + * 3. a1 should DT address > + */ > +void __noreturn efi_enter_kernel(unsigned long entrypoint, unsigned long fdt) This prototype has changed, and now includes the size of the fdt in param 3. > +{ > + unsigned long kernel_entry = entrypoint + _start_kernel - _start; stext_offset ? It has a terrible name though, and I'll probably propose to change it at some point, for all arches. But you can still use it here. > + jump_kernel_func jump_kernel = (void (*)(unsigned int, unsigned long))kernel_entry; > + u64 hartid = get_boot_hartid_from_fdt(fdt); > + > + if (hartid == U64_MAX) > + /* We can not use panic or BUG at this point */ > + __asm__ __volatile__ ("ebreak"); > + /* Disable MMU */ > + csr_write(CSR_SATP, 0); > + jump_kernel(hartid, fdt); > +} > + > +efi_status_t handle_kernel_image(unsigned long *image_addr, > + unsigned long *image_size, > + unsigned long *reserve_addr, > + unsigned long *reserve_size, > + unsigned long dram_base, > + efi_loaded_image_t *image) > +{ > + efi_status_t status; > + unsigned long kernel_size, kernel_memsize = 0; > + unsigned long preferred_offset; > + > + /* > + * The preferred offset of the kernel Image is TEXT_OFFSET bytes beyond > + * a KIMG_ALIGN aligned base. > + */ > + preferred_offset = round_up(dram_base, MIN_KIMG_ALIGN) + TEXT_OFFSET; > + > + kernel_size = _edata - _start; > + kernel_memsize = kernel_size + (_end - _edata); > + > + /* > + * Try a straight allocation at the preferred offset. > + * This will work around the issue where, if dram_base == 0x0, > + * efi_low_alloc() refuses to allocate at 0x0 (to prevent the > + * address of the allocation to be mistaken for a FAIL return > + * value or a NULL pointer). It will also ensure that, on > + * platforms where the [dram_base, dram_base + TEXT_OFFSET) > + * interval is partially occupied by the firmware (like on APM > + * Mustang), we can still place the kernel at the address > + * 'dram_base + TEXT_OFFSET'. Better drop this entire last sentence (unless it is relevant, but then rework it to drop the APM Mustang reference) > + */ > + if (*image_addr == preferred_offset) > + return EFI_SUCCESS; > + > + *image_addr = *reserve_addr = preferred_offset; > + *reserve_size = round_up(kernel_memsize, EFI_ALLOC_ALIGN); > + > + status = efi_bs_call(allocate_pages, EFI_ALLOCATE_ADDRESS, > + EFI_LOADER_DATA, > + *reserve_size / EFI_PAGE_SIZE, > + (efi_physical_addr_t *)reserve_addr); > + > + if (status != EFI_SUCCESS) { > + *reserve_size = kernel_memsize + TEXT_OFFSET; > + status = efi_low_alloc(*reserve_size, MIN_KIMG_ALIGN, > + reserve_addr); > + > + if (status != EFI_SUCCESS) { > + pr_efi_err("Failed to relocate kernel\n"); > + *reserve_size = 0; > + return status; > + } > + *image_addr = *reserve_addr + TEXT_OFFSET; > + } > + memcpy((void *)*image_addr, image->image_base, kernel_size); > + > + return EFI_SUCCESS; > +} > -- > 2.24.0 >