RISC-V MC schedule is out
The official schedule RISC-V MC at Plumbers is available now. https://linuxplumbersconf.org/event/11/sessions/114/#20210921 We have many interesting topics that will be discussed including the following draft specifications. [1] RISC-V Platform specification (https://github.com/riscv/riscv-platform-specs) [2] Advanced Interrupt Architecture (AIA) (https://github.com/riscv/riscv-aia) [3] Advanced CLINT (ACLINT) (https://github.com/riscv/riscv-aclint/) [4] ACPI for RISC-V (https://github.com/riscv-non-isa/riscv-acpi) All of these specifications will be moved to a wider public review phase in a few months as well. We look forward to your feedback on these specifications. Hope to have a great session next week. FYI: The registration for plumbers is still open if you have not already done so [1]. [1] https://linuxplumbersconf.org/event/11/page/112-attend -- Regards, Atish
Re: [PATCH] riscv: Fix setting no-map in reserved memory nodes
On Sun, Sep 12, 2021 at 9:05 AM Samuel Holland wrote:
>
> The no-map property is wrongly skipped if a no-map reserved memory
> node follows one without that property. Fix this by not remembering
> the absence of a no-map property across loop iterations.
>
> Fixes: d4ea649f179a ("riscv: Provide a mechanism to fix DT for reserved
> memory")
> Signed-off-by: Samuel Holland
> ---
>
> arch/riscv/lib/fdt_fixup.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> index f636b284497..61cf8935269 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -31,7 +31,6 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> fdt_addr_t addr;
> fdt_size_t size;
> int offset, node, err, rmem_offset;
> - bool nomap = true;
> char basename[32] = {0};
> int bname_len;
> int max_len = sizeof(basename);
> @@ -81,9 +80,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> log_err("failed to add reserved memory: %d\n", err);
> return err;
> }
> - if (!fdt_getprop(src, node, "no-map", NULL))
> - nomap = false;
> - if (nomap) {
> + if (fdt_getprop(src, node, "no-map", NULL)) {
> rmem_offset = fdt_node_offset_by_phandle(dst,
> phandle);
> fdt_setprop_empty(dst, rmem_offset, "no-map");
> }
> --
> 2.31.1
>
Thanks for catching it.
Reviewed-by: Atish Patra
--
Regards,
Atish
Status of the various RISC-V specification and policy
Hi All, Please find the below email from Stephano about the freeze announcement for various RISC-V specifications that will be part of privilege specification v1.12. All the review discussions are happening in the isa-dev mailing list. The review period will be open for 45 days ending Sunday October 31, 2021. I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions are frozen now. *This will help us merge some patches that have been present in the mailing list for a while. Here are the ratification policy and extension life cycle documents present in the public. If you have any questions regarding this, please check with Mark/Stephano (cc'd). Ratification policy: https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit Extension life cycle: https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1 -- Regards, Atish Mail from Stephano: -- Subject: Privileged Specification 1.12 Freeze Milestone: Public Review All, The Privileged Specification version 1.12 has gone to public review. You can view the specification documents by following the links provided here: https://docs.google.com/document/d/1soGI__HytotOkoJtgTYD0nzf82Zhp5nWw1Mcgqvbn8o/edit?usp=sharing Review discussion can be followed on the ISA-DEV mailing list here: https://groups.google.com/a/groups.riscv.org/g/isa-dev The review period will be open for 45 days ending Sunday October 31, 2021. We encourage all conversation to happen on this mailing list. Simply reply to the posts linked above with any questions or comments. If you feel that you have a topic that is best discussed internally with RISC-V members only, please contact me directly. Kind Regards, Stephano -- Stephano Cetola Director of Technical Programs RISC-V International
Re: Status of the various RISC-V specification and policy
On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt wrote: > > On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote: > > the words in this document : > > > > https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230 > > > > make it very clear when changes are allowed or not and likely or not. > > > > if you think the verbiage is somehow ambiguous please help us make it > > better. > > I'm not really worried about changes, I'm worried about a committment to > future compatibility. When we take code into the kernel (and most other > core systems projects) we're taking on the burden of supporting (until > someone can prove there are no more users), which is very difficult to > do when the ISA changes in an incompatible fashion. The whole point of > agreeing on the frozen thing was that it gave us a committment from the > specifcation authors that the future ISA would be compatible with th > frozen extensions. > > We're already in this spot with the V extension and the whole stable > thing, this definitaion of frozen looks very much like what was has led > to the issues there. Saying the spec won't change really isn't > meaningful, it's saying future specs will be compatible that's > important. Nothing in this whole rule touches on compatibility, and I > really don't want to end up in a bigger mess than we're already in. > > (Also: some PGE subcontractor drove a crane into my house, so things are > a bit chaotic on my end. If you have that list of what's officially > frozen, can you send it out? I'll try to take a look ASAP, as then I > can at least focus the discussion on what's relevant right now.) Here is the list of the specs that are frozen. https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone I will let Mark comment on the compatibility thing. > > > > > Mark > > > > sent from a mobile device. please forgive any typos. > > > >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt wrote: > >> > >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote: > >>> Hi All, > >>> Please find the below email from Stephano about the freeze announcement > >>> for > >>> various RISC-V specifications that will be part of privilege specification > >>> v1.12. > >>> All the review discussions are happening in the isa-dev mailing list. The > >>> review period will be open for 45 days ending Sunday October 31, 2021. > >>> > >>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO extensions > >>> are frozen now. *This will help us merge some patches that have been > >>> present in the mailing list for a while. > >>> > >>> Here are the ratification policy and extension life cycle documents > >>> present > >>> in the public. If you have any questions regarding this, please check with > >>> Mark/Stephano (cc'd). > >>> > >>> Ratification policy: > >>> https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit > >>> > >>> Extension life cycle: > >>> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1 > >> > >> I'm still buried after Plumbers, but one of the bits on my TODO list was > >> to look throught the new definitions for frozen and stable. Nothing in > >> this extension life cycle talks about the point at which compatibility > >> will be maintained, which was really the central point behind frozen > >> before. > >> > >> Are there more concrete definitions somewhere? -- Regards, Atish
Re: Status of the various RISC-V specification and policy
On Tue, Sep 28, 2021 at 3:43 PM Palmer Dabbelt wrote: > > On Tue, 28 Sep 2021 13:05:53 PDT (-0700), ati...@atishpatra.org wrote: > > On Tue, Sep 28, 2021 at 11:34 AM Palmer Dabbelt wrote: > >> > >> On Mon, 27 Sep 2021 08:57:15 PDT (-0700), markhimelst...@riscv.org wrote: > >> > the words in this document : > >> > > >> > https://wiki.riscv.org/plugins/servlet/mobile?contentId=13098230#content/view/13098230 > >> > > >> > make it very clear when changes are allowed or not and likely or not. > >> > > >> > if you think the verbiage is somehow ambiguous please help us make it > >> > better. > >> > >> I'm not really worried about changes, I'm worried about a committment to > >> future compatibility. When we take code into the kernel (and most other > >> core systems projects) we're taking on the burden of supporting (until > >> someone can prove there are no more users), which is very difficult to > >> do when the ISA changes in an incompatible fashion. The whole point of > >> agreeing on the frozen thing was that it gave us a committment from the > >> specifcation authors that the future ISA would be compatible with th > >> frozen extensions. > >> > >> We're already in this spot with the V extension and the whole stable > >> thing, this definitaion of frozen looks very much like what was has led > >> to the issues there. Saying the spec won't change really isn't > >> meaningful, it's saying future specs will be compatible that's > >> important. Nothing in this whole rule touches on compatibility, and I > >> really don't want to end up in a bigger mess than we're already in. > >> > >> (Also: some PGE subcontractor drove a crane into my house, so things are > >> a bit chaotic on my end. If you have that list of what's officially > >> frozen, can you send it out? I'll try to take a look ASAP, as then I > >> can at least focus the discussion on what's relevant right now.) > > > > Here is the list of the specs that are frozen. > > https://wiki.riscv.org/display/TECH/ISA+Extensions+On+Deck+for+Freeze+Milestone > > How does that indicate what is frozen? I see "ISA Extensions On Deck > for Freeze Milestone" as the title, which makes it sound like these are > extension that are not yet frozen but will be eventually. Any row with "top sheet" complete and "out for public review" is frozen. The life cycle document[1] that I shared earlier in this thread also says the same i.e. any specification that is out for public review is frozen. Stephano also sent out a public email about all the specifications that are frozen. However, I understand that you need to do a little bit of deduction to understand what is frozen. @Stephano(already cc'd here) Can you add a separate column clearly indicating that "Freeze" status for each of those specifications in the wiki link. [1] https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1 > > Scrolling down to the end of that list, it lists pointer masking. The > best I can find is > https://github.com/riscv/riscv-j-extension/blob/master/pointer-masking-proposal.adoc > , which says "Version: v0.1-draft", which definately doesn't sound > frozen. The README says "Working Draft of the RISC-V J Extension > Specification", which also doesn't sound frozen. > > > I will let Mark comment on the compatibility thing. > > > >> > >> > > >> > Mark > >> > > >> > sent from a mobile device. please forgive any typos. > >> > > >> >> On Sep 27, 2021, at 8:50 AM, Palmer Dabbelt wrote: > >> >> > >> >> On Tue, 21 Sep 2021 17:20:17 PDT (-0700), ati...@atishpatra.org wrote: > >> >>> Hi All, > >> >>> Please find the below email from Stephano about the freeze > >> >>> announcement for > >> >>> various RISC-V specifications that will be part of privilege > >> >>> specification > >> >>> v1.12. > >> >>> All the review discussions are happening in the isa-dev mailing list. > >> >>> The > >> >>> review period will be open for 45 days ending Sunday October 31, 2021. > >> >>> > >> >>> I just want to highlight the fact that the *H*, *V, SvPBMT, CMO > >> >>> extensions > >> >>> are frozen now. *This will help us merge some patches that have been > >> >>> present in the mailing list for a while. > >> >>> > >> >>> Here are the ratification policy and extension life cycle documents > >> >>> present > >> >>> in the public. If you have any questions regarding this, please check > >> >>> with > >> >>> Mark/Stephano (cc'd). > >> >>> > >> >>> Ratification policy: > >> >>> https://docs.google.com/document/d/1-UlaSGqk59_myeuPMrV9gyuaIgnmFzGh5Gfy_tpViwM/edit > >> >>> > >> >>> Extension life cycle: > >> >>> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1 > >> >> > >> >> I'm still buried after Plumbers, but one of the bits on my TODO list > >> >> was to look throught the new definitions for frozen and stable. > >> >> Nothing in this extension life cycle talks about the point at which > >> >> compatibility w
Re: [PATCH] efi_loader: consider no-map property of reserved memory
On Wed, Sep 2, 2020 at 12:10 AM Heinrich Schuchardt wrote:
>
> On 31.08.20 20:08, Atish Patra wrote:
> > On Thu, Aug 27, 2020 at 9:16 AM Heinrich Schuchardt
> > wrote:
> >>
> >> If a reserved memory node in the device tree has the property no-map,
> >> remove it from the UEFI memory map provided by GetMemoryMap().
> >>
> >> Signed-off-by: Heinrich Schuchardt
>
> In the mail-thread starting a
>
> [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property
> https://lists.linaro.org/pipermail/boot-architecture/2020-September/001389.html
>
> the issue has been discussed. The conclusion was that we should not
> change the current behavior.
>
Digging some old threads :)
The merged version of the patch marks any reserved memory as
EFI_BOOT_SERVICES_DATA.
AFAIK, these memory regions will be available after ExitBootservice.
If the operating system chooses to
map these region and access them, it violates the purpose of the
reserved memory region specified by the firmware.
Did I miss something ?
> Best regards
>
> Heinrich
>
> >> ---
> >> cmd/bootefi.c | 34 --
> >> include/efi.h | 3 +++
> >> lib/efi_loader/efi_memory.c | 7 +--
> >> 3 files changed, 36 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >> index 40d5ef2b3a..f173105251 100644
> >> --- a/cmd/bootefi.c
> >> +++ b/cmd/bootefi.c
> >> @@ -135,12 +135,29 @@ done:
> >> return ret;
> >> }
> >>
> >> -static void efi_reserve_memory(u64 addr, u64 size)
> >> +/**
> >> + * efi_reserve_memory() - add reserved memory to memory map
> >> + *
> >> + * @addr: start address of the reserved memory range
> >> + * @size: size of the reserved memory range
> >> + * @nomap: indicates that the memory range shall be hidden from the
> >> memory
> >> + * map
> >> + */
> >> +static void efi_reserve_memory(u64 addr, u64 size, bool nomap)
> >> {
> >> + int type;
> >> + efi_uintn_t ret;
> >> +
> >> /* Convert from sandbox address space. */
> >> addr = (uintptr_t)map_sysmem(addr, 0);
> >> - if (efi_add_memory_map(addr, size,
> >> - EFI_RESERVED_MEMORY_TYPE) != EFI_SUCCESS)
> >> +
> >> + if (nomap)
> >> + type = EFI_NO_MAP_MEMORY;
> >> + else
> >> + type = EFI_RESERVED_MEMORY_TYPE;
> >> +
> >> + ret = efi_add_memory_map(addr, size, type);
> >> + if (ret != EFI_SUCCESS)
> >> log_err("Reserved memory mapping failed addr %llx size
> >> %llx\n",
> >> addr, size);
> >> }
> >> @@ -166,7 +183,7 @@ static void efi_carve_out_dt_rsv(void *fdt)
> >> for (i = 0; i < nr_rsv; i++) {
> >> if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
> >> continue;
> >> - efi_reserve_memory(addr, size);
> >> + efi_reserve_memory(addr, size, false);
> >> }
> >>
> >> /* process reserved-memory */
> >> @@ -186,8 +203,13 @@ static void efi_carve_out_dt_rsv(void *fdt)
> >> * a size instead of a reg property.
> >> */
> >> if (fdt_addr != FDT_ADDR_T_NONE &&
> >> - fdtdec_get_is_enabled(fdt, subnode))
> >> - efi_reserve_memory(fdt_addr, fdt_size);
> >> + fdtdec_get_is_enabled(fdt, subnode)) {
> >> + bool nomap;
> >> +
> >> + nomap = !!fdt_getprop(fdt, subnode,
> >> "no-map",
> >> + NULL);
> >> + efi_reserve_memory(fdt_addr, fdt_size,
> >> nomap);
> >> + }
> >> subnode = fdt_next_subnode(fdt, subnode);
> >> }
> >> }
> >> diff --git a/include/efi.h b/include/efi.h
> >> index f986aad877..50190021ef 100644
> >> --- a/include/efi.h
> >> +++ b/include/efi.h
> >> @@ -181,6 +181,9 @@ enum efi_mem_type {
> >>
> >> EFI_MAX
Re: [PATCH] efi_loader: consider no-map property of reserved memory
On Mon, May 10, 2021 at 4:47 PM Atish Patra wrote:
>
> On Wed, Sep 2, 2020 at 12:10 AM Heinrich Schuchardt
> wrote:
> >
> > On 31.08.20 20:08, Atish Patra wrote:
> > > On Thu, Aug 27, 2020 at 9:16 AM Heinrich Schuchardt
> > > wrote:
> > >>
> > >> If a reserved memory node in the device tree has the property no-map,
> > >> remove it from the UEFI memory map provided by GetMemoryMap().
> > >>
> > >> Signed-off-by: Heinrich Schuchardt
> >
> > In the mail-thread starting a
> >
> > [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property
> > https://lists.linaro.org/pipermail/boot-architecture/2020-September/001389.html
> >
> > the issue has been discussed. The conclusion was that we should not
> > change the current behavior.
> >
>
> Digging some old threads :)
>
> The merged version of the patch marks any reserved memory as
> EFI_BOOT_SERVICES_DATA.
> AFAIK, these memory regions will be available after ExitBootservice.
> If the operating system chooses to
> map these region and access them, it violates the purpose of the
> reserved memory region specified by the firmware.
>
> Did I miss something ?
>
ping ?
> > Best regards
> >
> > Heinrich
> >
> > >> ---
> > >> cmd/bootefi.c | 34 --
> > >> include/efi.h | 3 +++
> > >> lib/efi_loader/efi_memory.c | 7 +--
> > >> 3 files changed, 36 insertions(+), 8 deletions(-)
> > >>
> > >> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > >> index 40d5ef2b3a..f173105251 100644
> > >> --- a/cmd/bootefi.c
> > >> +++ b/cmd/bootefi.c
> > >> @@ -135,12 +135,29 @@ done:
> > >> return ret;
> > >> }
> > >>
> > >> -static void efi_reserve_memory(u64 addr, u64 size)
> > >> +/**
> > >> + * efi_reserve_memory() - add reserved memory to memory map
> > >> + *
> > >> + * @addr: start address of the reserved memory range
> > >> + * @size: size of the reserved memory range
> > >> + * @nomap: indicates that the memory range shall be hidden from the
> > >> memory
> > >> + * map
> > >> + */
> > >> +static void efi_reserve_memory(u64 addr, u64 size, bool nomap)
> > >> {
> > >> + int type;
> > >> + efi_uintn_t ret;
> > >> +
> > >> /* Convert from sandbox address space. */
> > >> addr = (uintptr_t)map_sysmem(addr, 0);
> > >> - if (efi_add_memory_map(addr, size,
> > >> - EFI_RESERVED_MEMORY_TYPE) != EFI_SUCCESS)
> > >> +
> > >> + if (nomap)
> > >> + type = EFI_NO_MAP_MEMORY;
> > >> + else
> > >> + type = EFI_RESERVED_MEMORY_TYPE;
> > >> +
> > >> + ret = efi_add_memory_map(addr, size, type);
> > >> + if (ret != EFI_SUCCESS)
> > >> log_err("Reserved memory mapping failed addr %llx size
> > >> %llx\n",
> > >> addr, size);
> > >> }
> > >> @@ -166,7 +183,7 @@ static void efi_carve_out_dt_rsv(void *fdt)
> > >> for (i = 0; i < nr_rsv; i++) {
> > >> if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
> > >> continue;
> > >> - efi_reserve_memory(addr, size);
> > >> + efi_reserve_memory(addr, size, false);
> > >> }
> > >>
> > >> /* process reserved-memory */
> > >> @@ -186,8 +203,13 @@ static void efi_carve_out_dt_rsv(void *fdt)
> > >> * a size instead of a reg property.
> > >> */
> > >> if (fdt_addr != FDT_ADDR_T_NONE &&
> > >> - fdtdec_get_is_enabled(fdt, subnode))
> > >> - efi_reserve_memory(fdt_addr, fdt_size);
> > >> + fdtdec_get_is_enabled(fdt, subnode)) {
> > >> + bool nomap;
> > >> +
> > >> + nomap = !!fdt_getprop(fdt, subnode,
> > >> "no-map",
> > >> +
Re: [PATCH] riscv: Fix arch_fixup_fdt always failing without /chosen
On Sat, May 8, 2021 at 9:13 AM Sean Anderson wrote:
>
> If /chosen was missing, chosen_offset would never get updated with the new
> /chosen node. This would cause fdt_setprop_u32 to fail. This patch fixes
> this by setting chosen_offset. In addition, log any errors from setting
> boot-hartid as well.
>
> Fixes: 177c53fe6c6 ("riscv: Move all fdt fixups together")
> Signed-off-by: Sean Anderson
> ---
> I have not actually tested this (nor observed the original failure). But this
> seemed buggy from inspection.
>
> arch/riscv/lib/fdt_fixup.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> index 1f3f23621c..f636b28449 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -151,14 +151,17 @@ int arch_fixup_fdt(void *blob)
> }
> chosen_offset = fdt_path_offset(blob, "/chosen");
> if (chosen_offset < 0) {
> - err = fdt_add_subnode(blob, 0, "chosen");
> - if (err < 0) {
> + chosen_offset = fdt_add_subnode(blob, 0, "chosen");
> + if (chosen_offset < 0) {
> log_err("chosen node cannot be added\n");
> - return err;
> + return chosen_offset;
> }
> }
> /* Overwrite the boot-hartid as U-Boot is the last stage BL */
> - fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
> gd->arch.boot_hart);
> + err = fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
> + gd->arch.boot_hart);
> + if (err < 0)
> + return log_msg_ret("could not set boot-hartid", err);
> #endif
>
> /* Copy the reserved-memory node to the DT used by OS */
> --
> 2.31.0
>
Thanks for the fix. Good catch.
With update commit text as suggested by Bin:
Reviewed-by: Atish Patra
--
Regards,
Atish
Re: [PATCH] efi_loader: consider no-map property of reserved memory
On Fri, May 14, 2021 at 12:59 AM Heinrich Schuchardt wrote: > > On 5/13/21 11:53 PM, Mark Kettenis wrote: > >> From: Heinrich Schuchardt > >> Date: Thu, 13 May 2021 21:41:40 +0200 > > > > Hi Heinrich & Atish, > > > >> On 5/11/21 1:47 AM, Atish Patra wrote: > >>> On Wed, Sep 2, 2020 at 12:10 AM Heinrich Schuchardt > >>> wrote: > >>>> > >>>> On 31.08.20 20:08, Atish Patra wrote: > >>>>> On Thu, Aug 27, 2020 at 9:16 AM Heinrich Schuchardt > >>>>> wrote: > >>>>>> > >>>>>> If a reserved memory node in the device tree has the property no-map, > >>>>>> remove it from the UEFI memory map provided by GetMemoryMap(). > >>>>>> > >>>>>> Signed-off-by: Heinrich Schuchardt > >>>> > >>>> In the mail-thread starting a > >>>> > >>>> [PATCH 1/1] EBBR: GetMemoryMap(), handling of no-map DT property > >>>> https://lists.linaro.org/pipermail/boot-architecture/2020-September/001389.html > >>>> > >>>> the issue has been discussed. The conclusion was that we should not > >>>> change the current behavior. > >>>> > >>> > >>> Digging some old threads :) > >>> > >>> The merged version of the patch marks any reserved memory as > >>> EFI_BOOT_SERVICES_DATA. > >>> AFAIK, these memory regions will be available after ExitBootservice. > >>> If the operating system chooses to > >>> map these region and access them, it violates the purpose of the > >>> reserved memory region specified by the firmware. > >>> > >>> Did I miss something ? > >> > >> The no-map property is neither described in the EBBR nor in the > >> Devicetree specification v0.3 but only in Linux' reserved-memory.txt. > > > > It is described (quite explicitly) in the current devicetree > > specification draft. > > > >> In > >> https://lists.linaro.org/pipermail/boot-architecture/2020-September/001418.html > >> Ard requested that no-map memory shall be marked EfiReservedMemory > >> because Linux will not map EfiReservedMemory, see Linux function > >> is_usable_memory(). > >> > >> All reserved memory that is not marked as no-map shall be mapped by > >> Linux. It may for instance serve as DMA pool or as video memory. Or it > >> may even be reusable. See reserved-memory.txt. > >> > >> Only drivers will access their own reserved memory if the region is not > >> marked as reusable. > > > > I suspect Atish is asking because of the issue I opened for opensbi: > > > >https://github.com/riscv/opensbi/issues/210 > > > > On many RISC-V platforms, opensbi runs in "machine mode" (somewhat > > equivalent to EL3 on ARMv8) and allocates some memory for itself. It > > sets up protections for this memory such that "supervisor mode" > > (somewhat equivalent to EL1 on ARMv8) can't access this memory. > > > > Older versions of opensbi marked this memory area as "no-map", > > resulting in that memory area being marked as EfiReservedMemoryType, > > and evrything is fine. > > > > However, according to reserved-memory.txt, "no-map" means the the area > > isn't supposed to be mapped by the OS at all. That is deemed > > undesirable since it prevents the OS from using a large 2MB or 1G page > > table entry to map the memory range that happens to include the memory > > reserved for opensbi. That is sub-optimal as it means the OS has to > > allocated more levels of page tables for this memory block and has to > > use 4K pages which will increase TLB pressure. So newer versions of > > opensbi dropped the "no-map" property resulting in the area being > > marked as EfiBootServicesData. But that is obviously wrong since the > > OS can't actually access that memory range. > > > > Now somewhat by accident the Linux kernel didn't actually attempt to > > use this memory area so the issue wasn't noticed. But we're working > > on OpenBSD/riscv64 and when I added code to use the EFI memory map the > > OpenBSD kernel tried to use that inaccessable memory, which obviously > > didn't end well. > > It is not by accident. The idea of reserved memory is that only a driver > responsible for this reserved memory is allowed to access it. > What is the expected behavi
RISC-V Microconference Accepted into 2021 Linux Plumbers Conference
The CFP for topic proposals for the RISC-V micro conference is open now. Please submit it as soon as possible. Here is the announcement. https://www.linuxplumbersconf.org/blog/2021/index.php/2021/07/26/risc-v-microconference-accepted-into-2021-linux-plumbers-conference/ FYI: The Linux plumbers event will be virtual this year. More details can be found here. https://www.linuxplumbersconf.org/event/11/page/103-lpc-2021-overview -- Regards, Atish
Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
On Wed, 2019-08-21 at 12:07 -0700, David Abdurachmanov wrote:
> Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
> commands in RISC-V targets and broke extlinux support as reported
> by Fu Wei .
>
> The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
> to Kconfig.
>
> Signed-off-by: David Abdurachmanov
> ---
> configs/qemu-riscv64_smode_defconfig | 2 ++
> configs/sifive_fu540_defconfig | 2 ++
> include/configs/sifive-fu540.h | 4
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-
> riscv64_smode_defconfig
> index 74743a5ebe..2e1f7fa91f 100644
> --- a/configs/qemu-riscv64_smode_defconfig
> +++ b/configs/qemu-riscv64_smode_defconfig
> @@ -9,3 +9,5 @@ CONFIG_DISPLAY_CPUINFO=y
> CONFIG_DISPLAY_BOARDINFO=y
> # CONFIG_CMD_MII is not set
> CONFIG_OF_PRIOR_STAGE=y
> +CONFIG_USE_PREBOOT=y
> +CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr}; fdt addr
> ${fdtcontroladdr};"
> diff --git a/configs/sifive_fu540_defconfig
> b/configs/sifive_fu540_defconfig
> index 48865e5f11..a852579309 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -9,3 +9,5 @@ CONFIG_MISC_INIT_R=y
> CONFIG_DISPLAY_CPUINFO=y
> CONFIG_DISPLAY_BOARDINFO=y
> CONFIG_OF_PRIOR_STAGE=y
> +CONFIG_USE_PREBOOT=y
> +CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr}; fdt addr
> ${fdtcontroladdr};"
> diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-
> fu540.h
> index 858b7a7da1..ba4aa0652c 100644
> --- a/include/configs/sifive-fu540.h
> +++ b/include/configs/sifive-fu540.h
> @@ -40,8 +40,4 @@
> "ramdisk_addr_r=0x8830\0" \
> BOOTENV
>
> -#define CONFIG_PREBOOT \
> - "setenv fdt_addr ${fdtcontroladdr};" \
> - "fdt addr ${fdtcontroladdr};"
> -
As per the README, fdt_addr should be flash location. Why it was done
in the first place ?
Additionally, fdtcontroladdr is set what gdt->fdt_blob is set. On
latest U-boot in HiFive Unleashed, it is set to 0xff76e470. Not sure
the reasong. May be after relocation ?
However, 5.3 kernel possibly ovewriting that address resulting in boot
failures. Using fdt_addr_r works fine though.
As per following patch, we should do a tftpboot dtb to fdt_addr_r or
just using fdt_addr_r will also work as fdt_addr_r is set to the
address where OpenSBI keeps the DT.
> #endif /* __CONFIG_H */
--
Regards,
Atish
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V
Hi All, I noticed following issues around U-Boot fdt location in Unleashed and Qemu virt machine. OpenSBI copies the FDT to following addresses for respective platforms Qemu: 0x8220 Unleashed: 0x8800 As CONFIG_PRIOR_STAGE is set for both platforms, fdt is first copied to gd->fdt_blob and then gets relocated to a different address(gd- >new_fdt) in function reloc_fdt. As a result, FDT is present at two locations. 1. 0x8800(Unleashed)/0x8220(Qemu) : OpenSBI copied FDT to this address. 2. gd->new_fdt: U-Boot relocated the fdt to this address. fdtcontroladdr will also point to this address. However, commit ac12c6190927 (riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64M) in U-boot changed Qemu config so that fdt_addr_r points to 0x8800 which is wrong as nobody copies fdt to above address in Qemu. Also, 5.3-rc+ kernels overwrite the address pointed by fdtcontroladdr. As a result, fdtcontroladdr won't work on any platform and fdt_addr_r will work only for Unleashed but not for Qemu. I am not sure what should be the ideal solution to avoid these kind of fdt placement issues in future. Here are the few possible ones. 1. Change the FDT_JUMP_ADDR in OpenSBI to 0x8800(RAM+128MB) for Qemu as well. This won't work as Qemu copies initrd to that address. I guess best next option is to copy to 0x8400(RAM+64MB) and U-boot config for Qemu accordingly. 2. Change fdt_addr_r to 0x8220 in Qemu. Update documentation to use fdt only from fdt_addr_r not fdtcontroladdr. @david: What was the reason behind changing it for Qemu ? 3. Fix gd->new_fdt computation. This may affect every board which is not a very good idea either. 4. Mandate loading fdt only from tftp or sdcard which is the safest option and will avoid these kind of complications. However, I think a default booting method without tftp server should at least work. Let me know if that is not a sane request. In that case, we should update documentation to clearly say that only tftpboot or sdcard loading method works. -- Regards, Atish ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V
On Mon, 2019-09-09 at 13:22 +0300, David Abdurachmanov wrote:
> On Mon, Sep 9, 2019 at 8:05 AM Anup Patel wrote:
> > Hi,
> >
> > I think keeping FDT placement in-sync between U-Boot and OpenSBI
> > across platforms is going to be painful.
> >
> > I suggest that for all platforms U-Boot explicitly load FDT from
> > somewhere
> > so:
> > 1. U-Boot ${fdt_addr_r} default value will be recommended location
> > of FDT
> > 2. U-Boot ${fdtcontroladdr} will always point to copy of FDT passed
> > by OpenSBI
> > 3. To forward FDT passed by OpenSBI to Linux, U-Boot users can
> > always explicitly
> > copy FDT from ${fdtcontroladdr} to ${fdt_addr_r} using U-Boot copy
> > command
> >
> > I also suspect that in-future for certain platforms FDT passed to
> > U-Boot and
> > FDT passed to Linux might be little different due to U-Boot
> > specific changes
> > in DTS.
> >
> > Thoughts ??
>
> Do not forget PXE and EXTLINUX boot options. These options must
> always be able to override DTB from previous stages. See below what
> PXE/EXT use. For Fedora/RISCV we end up in scenario #2 and thus
> fdt_addr needs to be set if DTB is coming from somewhere in the
> firmware.
> This is why we had CONFIG_PREBOOT to set it.
>
> [..]
> * Scenario 1: If fdt_addr_r specified and "fdt" label is defined in
> * pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm,
> * and adjust argc appropriately.
> *
> * Scenario 2: If there is an fdt_addr specified, pass it along to
> * bootm, and adjust argc appropriately.
> *
How about if we do this in PREBOOT ?
1. copy fdt from fdtcontroladdr to fdt_addr_r
2. setenv fdt_addr $fdt_addr_r
In this way, U-Boot will not have any direct dependancies on OpenSBI.
As long as U-Boot is configured with a fdt_addr_r, it should work. It
will be still valid for loading fdt from tftp server to fdt_addr_r as
well.
> * Scenario 3: fdt blob is not available.
> [..]
>
> david
>
> > Regards,
> > Anup
> >
> > > -Original Message-
> > > From: Atish Patra
> > > Sent: Sunday, September 8, 2019 5:40 PM
> > > To: david.abdurachma...@sifive.com; Alistair Francis
> > > ; Anup Patel
> > > Cc: u-boot@lists.denx.de; open...@lists.infradead.org
> > > Subject: FDT placement in OpenSBI + U-Boot + Linux kernel issue
> > > for RISC-V
> > >
> > > Hi All,
> > >
> > > I noticed following issues around U-Boot fdt location in
> > > Unleashed and Qemu
> > > virt machine.
> > >
> > > OpenSBI copies the FDT to following addresses for respective
> > > platforms
> > >
> > > Qemu: 0x8220
> > > Unleashed:0x8800
> > >
> > >
> > > As CONFIG_PRIOR_STAGE is set for both platforms, fdt is first
> > > copied to
> > > gd->fdt_blob and then gets relocated to a different address(gd-
> > > > new_fdt) in function reloc_fdt.
> > >
> > > As a result, FDT is present at two locations.
> > >
> > > 1. 0x8800(Unleashed)/0x8220(Qemu) : OpenSBI copied FDT to
> > > this
> > > address.
> > > 2. gd->new_fdt: U-Boot relocated the fdt to this address.
> > > fdtcontroladdr will also point to this address.
> > >
> > > However, commit ac12c6190927 (riscv: set CONFIG_SYS_BOOTM_LEN to
> > > SZ_64M) in U-boot changed Qemu config so that fdt_addr_r points
> > > to
> > > 0x8800 which is wrong as nobody copies fdt to above address
> > > in Qemu.
> > > Also, 5.3-rc+ kernels overwrite the address pointed by
> > > fdtcontroladdr.
> > >
> > > As a result, fdtcontroladdr won't work on any platform and
> > > fdt_addr_r will
> > > work only for Unleashed but not for Qemu.
> > >
> > > I am not sure what should be the ideal solution to avoid these
> > > kind of fdt
> > > placement issues in future. Here are the few possible ones.
> > >
> > > 1. Change the FDT_JUMP_ADDR in OpenSBI to 0x8800(RAM+128MB)
> > > for
> > > Qemu as well. This won't work as Qemu copies initrd to that
> > > address. I guess
> > > best next option is to copy to 0x8400(RAM+64MB) and U-boot
> > > config for
> > > Qemu accordingly.
> > >
> > > 2. Change fdt_addr_r to 0x8220 in Qemu. Update documentation
> > > to use
> > > fdt only from fdt_addr_r not fdtcontroladdr.
> > >
> > >
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Wed, 2019-11-13 at 11:47 -0800, Atish Patra wrote:
> On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov wrote:
> > On Sat, Nov 9, 2019 at 2:14 AM Atish Patra
> > wrote:
> > > Add compressed Image parsing support so that booti can parse both
> > > flat and compressed Image to boot Linux. Currently, it is
> > > difficult
> > > to calculate a safe address for every board where the compressed
> > > image can be decompressed. It is also not possible to figure out
> > > the
> > > size of the compressed file as well. Thus, user need to set two
> > > additional environment variables kernel_comp_addr_r and filesize
> > > to
> > > make this work.
> > >
> > > Following compression methods are supported for now.
> > > lzma, lzo, bzip2, gzip.
> > >
> > > lz4 support is not added as ARM64 kernel generates a lz4
> > > compressed
> > > image with legacy header which U-Boot doesn't know how to parse
> > > and
> > > decompress.
> > >
> > > Tested on HiFive Unleashed and Qemu for RISC-V.
> > > Tested on Qemu for ARM64.
> > >
> > > Signed-off-by: Atish Patra
> > > ---
> > > I could not test this patch on any ARM64 boards due to lack of
> > > access to any ARM64 board. If anybody can test it on ARM64, that
> > > would be great.
> > > ---
> > > cmd/booti.c| 40 ++-
> > > doc/README.distro | 12 +
> > > doc/board/sifive/fu540.rst | 55
> > > ++
> > > 3 files changed, 106 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/cmd/booti.c b/cmd/booti.c
> > > index c36b0235df8c..cd8670a9a8db 100644
> > > --- a/cmd/booti.c
> > > +++ b/cmd/booti.c
> > > @@ -13,6 +13,7 @@
> > > #include
> > > #include
> > >
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > /*
> > > * Image booting support
> > > */
> > > @@ -23,6 +24,12 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > > flag, int argc,
> > > ulong ld;
> > > ulong relocated_addr;
> > > ulong image_size;
> > > + uint8_t *temp;
> > > + ulong dest;
> > > + ulong dest_end;
> > > + unsigned long comp_len;
> > > + unsigned long decomp_len;
> > > + int ctype;
> > >
> > > ret = do_bootm_states(cmdtp, flag, argc, argv,
> > > BOOTM_STATE_START,
> > > images, 1);
> > > @@ -37,6 +44,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > > flag, int argc,
> > > debug("* kernel: cmdline image address =
> > > 0x%08lx\n", ld);
> > > }
> > >
> > > + temp = map_sysmem(ld, 0);
> > > + ctype = image_decomp_type(temp, 2);
> > > + if (ctype > 0) {
> > > + dest = env_get_ulong("kernel_comp_addr_r", 16,
> > > 0);
> > > + comp_len = env_get_ulong("filesize", 16, 0);
> > > + if (!dest || !comp_len) {
> > > + puts("kernel_comp_addr_r or filesize is
> > > not
> > > provided!\n");
> > > + return -EINVAL;
> > > + }
> > > + if (dest < gd->ram_base || dest > gd->ram_top) {
> > > + puts("kernel_comp_addr_r is outside of
> > > DRAM
> > > range!\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + debug("kernel image compression type %d size =
> > > 0x%08lx address = 0x%08lx\n",
> > > + ctype, comp_len, (ulong)dest);
> > > + decomp_len = comp_len * 10;
> > > + ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
> > > +(void *)dest, (void *)ld,
> > > comp_len,
> > > +decomp_len, &dest_end);
> > > + if (ret)
> > > + return ret;
> > > + /* dest_end contains the uncompressed Image size
> > > */
> > > + memmove((void *) ld, (void *)dest, dest_end);
> > > + }
> > > + unmap_sysmem((void *)ld);
> > > +
&
Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel wrote: > > On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW Technologist) > wrote: > > > > > > > > > -Original Message- > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > > > Sent: Wednesday, February 12, 2020 2:26 AM > > > To: Chang, Abner (HPS SW/FW Technologist) ; > > > Atish Patra ; Ard Biesheuvel > > > > > > Cc: Alexander Graf ; U-Boot Mailing List > > b...@lists.denx.de>; Atish Patra ; > > > l...@nuviainc.com > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup > > > > > > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > > > > > > > >> -Original Message- > > > >> From: Atish Patra [mailto:ati...@atishpatra.org] > > > >> Sent: Friday, February 7, 2020 6:56 AM > > > >> To: Ard Biesheuvel ; Chang, Abner (HPS > > > >> SW/FW > > > >> Technologist) > > > >> Cc: Alexander Graf ; Heinrich Schuchardt > > > >> ; U-Boot Mailing List ; > > > >> Atish Patra ; l...@nuviainc.com > > > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI > > > >> setup > > > >> > > > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > > > >> > > > >> wrote: > > > >>> > > > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra > > > >>> wrote: > > > >>>> > > > >>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf > > > wrote: > > > >>>>> > > > >>>>> > > > >>>>> On 06.02.20 19:28, Atish Patra wrote: > > > >>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > > > >>>>>> wrote: > > > >>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > > > >> wrote: > > > >>>>>>>> RISC-V booting currently is based on a per boot stage lottery > > > >>>>>>>> to determine the active CPU. The Hart State Management (HSM) > > > >>>>>>>> SBI extension replaces this lottery by using a dedicated > > > >>>>>>>> primary > > > >> CPU. > > > >>>>>>>> > > > >>>>>>>> Cf. Hart State Management Extension, Extension ID: 0x48534D > > > >>>>>>>> (HSM) > > > >>>>>>>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a > > > >>>>>>>> doc > > > >>>>>>>> > > > >>>>>>>> In this scenario the id of the active hart has to be passed > > > >>>>>>>> from boot stage to boot stage. Using a UEFI variable would > > > >>>>>>>> provide > > > >> an easy implementation. > > > >>>>>>>> > > > >>>>>>>> This patch provides a weak function that is called at the end > > > >>>>>>>> of the setup of U-Boot's UEFI sub-system. By overriding this > > > >>>>>>>> function architecture specific UEFI variables or configuration > > > >>>>>>>> tables > > > >> can be created. > > > >>>>>>>> > > > >>>>>>>> Signed-off-by: Heinrich Schuchardt > > > >>>>>>>> Reviewed-by: Atish Patra > > > >>>>>>> OK, so I have a couple of questions: > > > >>>>>>> > > > >>>>>>> - does RISC-V use device tree? if so, why are you not passing > > > >>>>>>> the active hart via a property in the /chosen node? > > > >>>>>> Yes. RISC-V uses device tree. Technically, we can pass the active > > > >>>>>> hart by a DT property but that means we have to modify the DT in > > > >>>>>> OpenSBI (RISC-V specific run time service provider). > > > >>>>>> We have been trying to avoid that if possible so that DT is not > > > >>>>>> bounced around. This also limits U-Boot to have its own device > > > >>>>>> tree. > > > >&
Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
On Thu, Feb 13, 2020 at 2:11 PM Ard Biesheuvel wrote: > > On Thu, 13 Feb 2020 at 19:59, Atish Patra wrote: > > > > On Tue, Feb 11, 2020 at 11:28 PM Ard Biesheuvel > > wrote: > > > > > > On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW Technologist) > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > > > > > Sent: Wednesday, February 12, 2020 2:26 AM > > > > > To: Chang, Abner (HPS SW/FW Technologist) ; > > > > > Atish Patra ; Ard Biesheuvel > > > > > > > > > > Cc: Alexander Graf ; U-Boot Mailing List > > > > b...@lists.denx.de>; Atish Patra ; > > > > > l...@nuviainc.com > > > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI > > > > > setup > > > > > > > > > > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > > > > > > > > > > > > > >> -Original Message- > > > > > >> From: Atish Patra [mailto:ati...@atishpatra.org] > > > > > >> Sent: Friday, February 7, 2020 6:56 AM > > > > > >> To: Ard Biesheuvel ; Chang, Abner (HPS > > > > > >> SW/FW > > > > > >> Technologist) > > > > > >> Cc: Alexander Graf ; Heinrich Schuchardt > > > > > >> ; U-Boot Mailing List ; > > > > > >> Atish Patra ; l...@nuviainc.com > > > > > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI > > > > > >> setup > > > > > >> > > > > > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel > > > > > >> > > > > > >> wrote: > > > > > >>> > > > > > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra > > > > > >>> wrote: > > > > > >>>> > > > > > >>>> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf > > > > > wrote: > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> On 06.02.20 19:28, Atish Patra wrote: > > > > > >>>>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel > > > > > >>>>>> wrote: > > > > > >>>>>>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt > > > > > >> wrote: > > > > > >>>>>>>> RISC-V booting currently is based on a per boot stage lottery > > > > > >>>>>>>> to determine the active CPU. The Hart State Management (HSM) > > > > > >>>>>>>> SBI extension replaces this lottery by using a dedicated > > > > > >>>>>>>> primary > > > > > >> CPU. > > > > > >>>>>>>> > > > > > >>>>>>>> Cf. Hart State Management Extension, Extension ID: 0x48534D > > > > > >>>>>>>> (HSM) > > > > > >>>>>>>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a > > > > > >>>>>>>> doc > > > > > >>>>>>>> > > > > > >>>>>>>> In this scenario the id of the active hart has to be passed > > > > > >>>>>>>> from boot stage to boot stage. Using a UEFI variable would > > > > > >>>>>>>> provide > > > > > >> an easy implementation. > > > > > >>>>>>>> > > > > > >>>>>>>> This patch provides a weak function that is called at the end > > > > > >>>>>>>> of the setup of U-Boot's UEFI sub-system. By overriding this > > > > > >>>>>>>> function architecture specific UEFI variables or > > > > > >>>>>>>> configuration > > > > > >>>>>>>> tables > > > > > >> can be created. > > > > > >>>>>>>> > > > > > >>>>>>>> Signed-off-by: Heinrich Schuchardt > > > > > >&g
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Fri, Feb 14, 2020 at 8:43 AM Tom Rini wrote: > > On Thu, Feb 13, 2020 at 11:32:52PM +0200, David Abdurachmanov wrote: > > On Thu, Feb 13, 2020 at 6:17 PM Tom Rini wrote: > > > > > > On Wed, Feb 05, 2020 at 12:01:38AM +, Atish Patra wrote: > > > > On Fri, 2019-11-22 at 18:19 -0800, Atish Patra wrote: > > > > > On Wed, 2019-11-13 at 11:47 -0800, Atish Patra wrote: > > > > > > On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov wrote: > > > > > > > On Sat, Nov 9, 2019 at 2:14 AM Atish Patra > > > > > > > wrote: > > > > > > > > Add compressed Image parsing support so that booti can parse > > > > > > > > both > > > > > > > > flat and compressed Image to boot Linux. Currently, it is > > > > > > > > difficult > > > > > > > > to calculate a safe address for every board where the > > > > > > > > compressed > > > > > > > > image can be decompressed. It is also not possible to figure > > > > > > > > out > > > > > > > > the > > > > > > > > size of the compressed file as well. Thus, user need to set two > > > > > > > > additional environment variables kernel_comp_addr_r and > > > > > > > > filesize > > > > > > > > to > > > > > > > > make this work. > > > > > > > > > > > > > > > > Following compression methods are supported for now. > > > > > > > > lzma, lzo, bzip2, gzip. > > > > > > > > > > > > > > > > lz4 support is not added as ARM64 kernel generates a lz4 > > > > > > > > compressed > > > > > > > > image with legacy header which U-Boot doesn't know how to parse > > > > > > > > and > > > > > > > > decompress. > > > > > > > > > > > > > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > > > > > Tested on Qemu for ARM64. > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > --- > > > > > > > > I could not test this patch on any ARM64 boards due to lack of > > > > > > > > access to any ARM64 board. If anybody can test it on ARM64, > > > > > > > > that > > > > > > > > would be great. > > > > > > > > --- > > > > > > > > cmd/booti.c| 40 ++- > > > > > > > > doc/README.distro | 12 + > > > > > > > > doc/board/sifive/fu540.rst | 55 > > > > > > > > ++ > > > > > > > > 3 files changed, 106 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > diff --git a/cmd/booti.c b/cmd/booti.c > > > > > > > > index c36b0235df8c..cd8670a9a8db 100644 > > > > > > > > --- a/cmd/booti.c > > > > > > > > +++ b/cmd/booti.c > > > > > > > > @@ -13,6 +13,7 @@ > > > > > > > > #include > > > > > > > > #include > > > > > > > > > > > > > > > > +DECLARE_GLOBAL_DATA_PTR; > > > > > > > > /* > > > > > > > > * Image booting support > > > > > > > > */ > > > > > > > > @@ -23,6 +24,12 @@ static int booti_start(cmd_tbl_t *cmdtp, int > > > > > > > > flag, int argc, > > > > > > > > ulong ld; > > > > > > > > ulong relocated_addr; > > > > > > > > ulong image_size; > > > > > > > > + uint8_t *temp; > > > > > > > > + ulong dest; > > > > > > > > + ulong dest_end; > > > > > > > > + unsigned long comp_len; > > > > > > > > + unsigned long decomp_len; > > > > > > > > + int ctype; > > > > > > > > > > > > > > > > ret = do_bootm_states(cmdtp, flag, argc, argv, > > > > > > > &g
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Thu, Feb 20, 2020 at 1:14 PM David Abdurachmanov wrote: > > On Tue, Feb 18, 2020 at 10:38 PM Tom Rini wrote: > > > > On Sun, Feb 16, 2020 at 04:48:22PM -0800, Atish Patra wrote: > > > On Fri, Feb 14, 2020 at 8:43 AM Tom Rini wrote: > > > > > > > > On Thu, Feb 13, 2020 at 11:32:52PM +0200, David Abdurachmanov wrote: > > > > > On Thu, Feb 13, 2020 at 6:17 PM Tom Rini wrote: > > > > > > > > > > > > On Wed, Feb 05, 2020 at 12:01:38AM +, Atish Patra wrote: > > > > > > > On Fri, 2019-11-22 at 18:19 -0800, Atish Patra wrote: > > > > > > > > On Wed, 2019-11-13 at 11:47 -0800, Atish Patra wrote: > > > > > > > > > On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov wrote: > > > > > > > > > > On Sat, Nov 9, 2019 at 2:14 AM Atish Patra > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > Add compressed Image parsing support so that booti can > > > > > > > > > > > parse > > > > > > > > > > > both > > > > > > > > > > > flat and compressed Image to boot Linux. Currently, it is > > > > > > > > > > > difficult > > > > > > > > > > > to calculate a safe address for every board where the > > > > > > > > > > > compressed > > > > > > > > > > > image can be decompressed. It is also not possible to > > > > > > > > > > > figure > > > > > > > > > > > out > > > > > > > > > > > the > > > > > > > > > > > size of the compressed file as well. Thus, user need to > > > > > > > > > > > set two > > > > > > > > > > > additional environment variables kernel_comp_addr_r and > > > > > > > > > > > filesize > > > > > > > > > > > to > > > > > > > > > > > make this work. > > > > > > > > > > > > > > > > > > > > > > Following compression methods are supported for now. > > > > > > > > > > > lzma, lzo, bzip2, gzip. > > > > > > > > > > > > > > > > > > > > > > lz4 support is not added as ARM64 kernel generates a lz4 > > > > > > > > > > > compressed > > > > > > > > > > > image with legacy header which U-Boot doesn't know how to > > > > > > > > > > > parse > > > > > > > > > > > and > > > > > > > > > > > decompress. > > > > > > > > > > > > > > > > > > > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > > > > > > > > Tested on Qemu for ARM64. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > > --- > > > > > > > > > > > I could not test this patch on any ARM64 boards due to > > > > > > > > > > > lack of > > > > > > > > > > > access to any ARM64 board. If anybody can test it on > > > > > > > > > > > ARM64, > > > > > > > > > > > that > > > > > > > > > > > would be great. > > > > > > > > > > > --- > > > > > > > > > > > cmd/booti.c| 40 > > > > > > > > > > > ++- > > > > > > > > > > > doc/README.distro | 12 + > > > > > > > > > > > doc/board/sifive/fu540.rst | 55 > > > > > > > > > > > ++ > > > > > > > > > > > 3 files changed, 106 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > > > > > diff --git a/cmd/booti.c b/cmd/booti.c > > > > > > > > > > > index c36b0235df8c..cd8670a9a8db 100644 > > > > &g
[RFC PATCH 0/1] Add boot hartid to a Device tree
The RISC-V booting protocol requires the hart id to be present in "a0" register. This is not a problem for bootm/booti commands as they directly jump to Linux kernel. However, bootefi jumps to a EFI boot stub code in Linux kernel which acts a loader and jumps to real Linux after terminating the boot services. This boot stub code has to be aware of the boot hart id so that it can set it in "a0" before jumping to Linux kernel. Currently, UEFI protocol doesn't have any mechanism to pass the boot hart id to an EFI executable. We should keep it this way as this is a RISC-V specific requirement rather than a UEFI requirement. Out of the all possible options, device tree seemed to be the best choice to do this job. The detailed discussion can be found in the following thread. https://patchwork.ozlabs.org/patch/1233664/ This patch updates the device tree in arch_fixup_fdt() which is common for all booting commands. As a result, the DT modification doesn't require any efi related arch specific functions and all DT related modifications are contained at one place. However, the hart id node will be available for Linux even if the kernel is booted using bootm command. If that is not acceptable, we can always move the code to an efi specific function. Atish Patra (1): riscv: Add boot hartid to Device tree arch/riscv/lib/bootm.c | 13 + 1 file changed, 13 insertions(+) -- 2.24.0
[RFC PATCH 1/1] riscv: Add boot hartid to Device tree
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.
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");
+ return -1;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ fdt_setprop_u64(blob, chosen_offset, "efi-boot-hartid",
+ gd->arch.boot_hart);
+
return 0;
}
--
2.24.0
Re: [RFC PATCH 0/1] Add boot hartid to a Device tree
On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel wrote: > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt wrote: > > > > On 2/24/20 11:19 PM, Atish Patra wrote: > > > The RISC-V booting protocol requires the hart id to be present in "a0" > > > register. This is not a problem for bootm/booti commands as they directly > > > jump to Linux kernel. However, bootefi jumps to a EFI boot stub code in > > > Linux kernel which acts a loader and jumps to real Linux after terminating > > > the boot services. This boot stub code has to be aware of the boot hart id > > > so that it can set it in "a0" before jumping to Linux kernel. Currently, > > > UEFI protocol doesn't have any mechanism to pass the boot hart id to an > > > EFI executable. We should keep it this way as this is a RISC-V specific > > > requirement rather than a UEFI requirement. Out of the all possible > > > options, > > > device tree seemed to be the best choice to do this job. > > > The detailed discussion can be found in the following thread. > > > > > > https://patchwork.ozlabs.org/patch/1233664/ > > > > The above mentioned patch is obsoleted by the new suggestion. > > Thanks for pointing that out to avoid confusion. > > > > > > This patch updates the device tree in arch_fixup_fdt() which is common for > > > all booting commands. As a result, the DT modification doesn't require any > > > efi related arch specific functions and all DT related modifications are > > > contained at one place. However, the hart id node will be available for > > > Linux even if the kernel is booted using bootm command. > > > > > > If that is not acceptable, we can always move the code to an efi specific > > > function. > > > > Does a related Linux patch already exist? Yes. But in my local tree ;). It will be included in RISC-V EFI stub support series which I am planning to post in a couple of days. > > How about EDK2? > > > > RISC-V is not supported at all yet in EDK2. > The EDK2 patches are out there and reviewed. I guess it will be available in mainline EDK2 pretty soon. Abner agreed that similar patch can be added to EDK2 as well in the previous thread. > > I guess boot loaders like GRUB would not have to care about the extra > > property? > > > > Yes, that is basically the point. -- Regards, Atish
[v1 PATCH 1/1] riscv: Add boot hartid to Device tree
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-boot can not pass the hartid via a0 during via standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
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..dd359a45c2e1 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 accommodate new node");
+ return -1;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
+ gd->arch.boot_hart);
+
return 0;
}
--
2.24.0
[v1 PATCH 0/1] Add boot hartid to a Device tree
The RISC-V booting protocol requires the hart id to be present in "a0" register. This is not a problem for bootm/booti commands as they directly jump to Linux kernel. However, bootefi jumps to a EFI boot stub code in Linux kernel which acts a loader and jumps to real Linux after terminating the boot services. This boot stub code has to be aware of the boot hart id so that it can set it in "a0" before jumping to Linux kernel. Currently, UEFI protocol doesn't have any mechanism to pass the boot hart id to an EFI executable. We should keep it this way as this is a RISC-V specific requirement rather than a UEFI requirement. Out of the all possible options, device tree seemed to be the best choice to do this job. The detailed discussion can be found in the following thread (the patch in discussion is no longer required) https://patchwork.ozlabs.org/patch/1233664/ This patch updates the device tree in arch_fixup_fdt() which is common for all booting commands. As a result, the DT modification doesn't require any efi related arch specific functions and all DT related modifications are contained at one place. However, the hart id node will be available for Linux even if the kernel is booted using bootm command. Changes from previous version: 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". 2. Changed the property type to u32 instead of u64 for RV32 compatibility. Atish Patra (1): riscv: Add boot hartid to Device tree arch/riscv/lib/bootm.c | 13 + 1 file changed, 13 insertions(+) -- 2.24.0
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Thu, Feb 20, 2020 at 2:25 PM Atish Patra wrote: > > On Thu, Feb 20, 2020 at 1:14 PM David Abdurachmanov > wrote: > > > > On Tue, Feb 18, 2020 at 10:38 PM Tom Rini wrote: > > > > > > On Sun, Feb 16, 2020 at 04:48:22PM -0800, Atish Patra wrote: > > > > On Fri, Feb 14, 2020 at 8:43 AM Tom Rini wrote: > > > > > > > > > > On Thu, Feb 13, 2020 at 11:32:52PM +0200, David Abdurachmanov wrote: > > > > > > On Thu, Feb 13, 2020 at 6:17 PM Tom Rini wrote: > > > > > > > > > > > > > > On Wed, Feb 05, 2020 at 12:01:38AM +, Atish Patra wrote: > > > > > > > > On Fri, 2019-11-22 at 18:19 -0800, Atish Patra wrote: > > > > > > > > > On Wed, 2019-11-13 at 11:47 -0800, Atish Patra wrote: > > > > > > > > > > On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov > > > > > > > > > > wrote: > > > > > > > > > > > On Sat, Nov 9, 2019 at 2:14 AM Atish Patra > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > Add compressed Image parsing support so that booti can > > > > > > > > > > > > parse > > > > > > > > > > > > both > > > > > > > > > > > > flat and compressed Image to boot Linux. Currently, it > > > > > > > > > > > > is > > > > > > > > > > > > difficult > > > > > > > > > > > > to calculate a safe address for every board where the > > > > > > > > > > > > compressed > > > > > > > > > > > > image can be decompressed. It is also not possible to > > > > > > > > > > > > figure > > > > > > > > > > > > out > > > > > > > > > > > > the > > > > > > > > > > > > size of the compressed file as well. Thus, user need to > > > > > > > > > > > > set two > > > > > > > > > > > > additional environment variables kernel_comp_addr_r and > > > > > > > > > > > > filesize > > > > > > > > > > > > to > > > > > > > > > > > > make this work. > > > > > > > > > > > > > > > > > > > > > > > > Following compression methods are supported for now. > > > > > > > > > > > > lzma, lzo, bzip2, gzip. > > > > > > > > > > > > > > > > > > > > > > > > lz4 support is not added as ARM64 kernel generates a lz4 > > > > > > > > > > > > compressed > > > > > > > > > > > > image with legacy header which U-Boot doesn't know how > > > > > > > > > > > > to parse > > > > > > > > > > > > and > > > > > > > > > > > > decompress. > > > > > > > > > > > > > > > > > > > > > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > > > > > > > > > Tested on Qemu for ARM64. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > > > --- > > > > > > > > > > > > I could not test this patch on any ARM64 boards due to > > > > > > > > > > > > lack of > > > > > > > > > > > > access to any ARM64 board. If anybody can test it on > > > > > > > > > > > > ARM64, > > > > > > > > > > > > that > > > > > > > > > > > > would be great. > > > > > > > > > > > > --- > > > > > > > > > > > > cmd/booti.c| 40 > > > > > > > > > > > > ++- > > > > > > > > > > > > doc/README.distro | 12 + > > > > > > > > > > > > doc/board/s
Re: [v1 PATCH 1/1] riscv: Add boot hartid to Device tree
On Tue, Mar 3, 2020 at 11:59 PM Rick Chen wrote:
>
> Hi Atish
>
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Atish Patra
> > Sent: Friday, February 28, 2020 5:01 AM
> > To: u-boot@lists.denx.de
> > Cc: Atish Patra; Alexander Graf; Anup Patel; Bin Meng; Joe Hershberger;
> > Loic Pallardy; Lukas Auer; Marek Behún; Marek Vasut; Patrick Delaunay; Peng
> > Fan; Philippe Reynes; Simon Glass; Simon Goldschmidt; Stefano Babic;
> > Thierry Reding; tr...@konsulko.com; Heinrich Schuchardt; Ard Biesheuvel;
> > l...@nuviainc.com; abner.ch...@hpe.com; daniel.schae...@hpe.com
> > Subject: [v1 PATCH 1/1] riscv: Add boot hartid to Device tree
> >
> > Linux booting protocol mandates that register "a0" contains the hartid.
> > However, U-boot can not pass the hartid via a0 during via standard UEFI
> > protocol. DT nodes are commonly used to pass such information to the OS.
> >
> > 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..dd359a45c2e1 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 accommodate new
> > node");
> > + return -1;
> > + }
> > + chosen_offset = fdt_path_offset(blob, "/chosen");
> > + fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
> > + gd->arch.boot_hart);
>
> Is it also OK for RV64 ?
>
Yes. I have tested it. To make it compatible for both 32 bit & 64 bit,
I have chosen a 32bit property
which allows the max hartid to be 2^32-1 which should be sufficient.
> Other than that,
> Reviewed-by: Rick Chen
>
> > +
> > return 0;
> > }
> >
> > --
> > 2.24.0
> >
--
Regards,
Atish
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Mon, Mar 2, 2020 at 10:41 AM Tom Rini wrote: > > On Fri, Feb 28, 2020 at 05:15:53PM -0800, Atish Patra wrote: > > On Thu, Feb 20, 2020 at 2:25 PM Atish Patra wrote: > > > > > > On Thu, Feb 20, 2020 at 1:14 PM David Abdurachmanov > > > wrote: > > > > > > > > On Tue, Feb 18, 2020 at 10:38 PM Tom Rini wrote: > > > > > > > > > > On Sun, Feb 16, 2020 at 04:48:22PM -0800, Atish Patra wrote: > > > > > > On Fri, Feb 14, 2020 at 8:43 AM Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Feb 13, 2020 at 11:32:52PM +0200, David Abdurachmanov > > > > > > > wrote: > > > > > > > > On Thu, Feb 13, 2020 at 6:17 PM Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Feb 05, 2020 at 12:01:38AM +, Atish Patra wrote: > > > > > > > > > > On Fri, 2019-11-22 at 18:19 -0800, Atish Patra wrote: > > > > > > > > > > > On Wed, 2019-11-13 at 11:47 -0800, Atish Patra wrote: > > > > > > > > > > > > On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Sat, Nov 9, 2019 at 2:14 AM Atish Patra > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Add compressed Image parsing support so that booti > > > > > > > > > > > > > > can parse > > > > > > > > > > > > > > both > > > > > > > > > > > > > > flat and compressed Image to boot Linux. Currently, > > > > > > > > > > > > > > it is > > > > > > > > > > > > > > difficult > > > > > > > > > > > > > > to calculate a safe address for every board where > > > > > > > > > > > > > > the > > > > > > > > > > > > > > compressed > > > > > > > > > > > > > > image can be decompressed. It is also not possible > > > > > > > > > > > > > > to figure > > > > > > > > > > > > > > out > > > > > > > > > > > > > > the > > > > > > > > > > > > > > size of the compressed file as well. Thus, user > > > > > > > > > > > > > > need to set two > > > > > > > > > > > > > > additional environment variables kernel_comp_addr_r > > > > > > > > > > > > > > and > > > > > > > > > > > > > > filesize > > > > > > > > > > > > > > to > > > > > > > > > > > > > > make this work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Following compression methods are supported for now. > > > > > > > > > > > > > > lzma, lzo, bzip2, gzip. > > > > > > > > > > > > > > > > > > > > > > > > > > > > lz4 support is not added as ARM64 kernel generates > > > > > > > > > > > > > > a lz4 > > > > > > > > > > > > > > compressed > > > > > > > > > > > > > > image with legacy header which U-Boot doesn't know > > > > > > > > > > > > > > how to parse > > > > > > > > > > > > > > and > > > > > > > > > > > > > > decompress. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > > > > > > > > > > > Tested on Qemu for ARM64. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > > >
[RFT PATCH v5 2/3] image: Add a common compression type detection function.
Currently, there is no method that can detect compression types
given a file. This is very useful where a compressed kernel image
is loaded directly to the memory.
Inspect initial few bytes to figure out compression type of the
image. It will be used in booti method for now but can be reused
any other function in future as well.
Signed-off-by: Atish Patra
Reviewed-by: Tom Rini
---
common/image.c | 23 +++
include/image.h | 21 +
2 files changed, 44 insertions(+)
diff --git a/common/image.c b/common/image.c
index 94873cb6ed50..d8d14e871c64 100644
--- a/common/image.c
+++ b/common/image.c
@@ -202,6 +202,14 @@ struct table_info {
const table_entry_t *table;
};
+static const struct comp_magic_map image_comp[] = {
+ { IH_COMP_BZIP2, "bzip2",{0x42, 0x5a},},
+ { IH_COMP_GZIP, "gzip", {0x1f, 0x8b},},
+ { IH_COMP_LZMA, "lzma", {0x5d, 0x00},},
+ { IH_COMP_LZO,"lzo", {0x89, 0x4c},},
+ { IH_COMP_NONE, "none", {}, },
+};
+
static const struct table_info table_info[IH_COUNT] = {
{ "architecture", IH_ARCH_COUNT, uimage_arch },
{ "compression", IH_COMP_COUNT, uimage_comp },
@@ -407,6 +415,21 @@ static void print_decomp_msg(int comp_type, int type, bool
is_xip)
printf(" Uncompressing %s\n", name);
}
+int image_decomp_type(const unsigned char *buf, ulong len)
+{
+ const struct comp_magic_map *cmagic = image_comp;
+
+ if (len < 2)
+ return -EINVAL;
+
+ for (; cmagic->comp_id > 0; cmagic++) {
+ if (!memcmp(buf, cmagic->magic, 2))
+ break;
+ }
+
+ return cmagic->comp_id;
+}
+
int image_decomp(int comp, ulong load, ulong image_start, int type,
void *load_buf, void *image_buf, ulong image_len,
uint unc_len, ulong *load_end)
diff --git a/include/image.h b/include/image.h
index b316d167d8d7..9bbb1acfb3af 100644
--- a/include/image.h
+++ b/include/image.h
@@ -452,6 +452,15 @@ typedef struct table_entry {
char*lname; /* long (output) name to print for messages */
} table_entry_t;
+/*
+ * Compression type and magic number mapping table.
+ */
+struct comp_magic_map {
+ int comp_id;
+ const char *name;
+ unsigned char magic[2];
+};
+
/*
* get_table_entry_id() scans the translation table trying to find an
* entry that matches the given short name. If a matching entry is
@@ -868,6 +877,18 @@ static inline int image_check_target_arch(const
image_header_t *hdr)
}
#endif /* USE_HOSTCC */
+/**
+ * image_decomp_type() - Find out compression type of an image
+ *
+ * @buf: Address in U-Boot memory where image is loaded.
+ * @len: Length of the compressed image.
+ * @return compression type or IH_COMP_NONE if not compressed.
+ *
+ * Note: Only following compression types are supported now.
+ * lzo, lzma, gzip, bzip2
+ */
+int image_decomp_type(const unsigned char *buf, ulong len);
+
/**
* image_decomp() - decompress an image
*
--
2.24.0
[RFT PATCH v5 3/3] image: Add compressed Image parsing support in booti.
Add compressed Image parsing support so that booti can parse both
flat and compressed Image to boot Linux. Currently, it is difficult
to calculate a safe address for every board where the compressed
image can be decompressed. It is also not possible to figure out the
size of the compressed file as well. Thus, user need to set two
additional environment variables kernel_comp_addr_r and filesize to
make this work.
Following compression methods are supported for now.
lzma, lzo, bzip2, gzip.
lz4 support is not added as ARM64 kernel generates a lz4 compressed
image with legacy header which U-Boot doesn't know how to parse and
decompress.
Tested on HiFive Unleashed and Qemu for RISC-V.
Tested on Qemu for ARM64.
Signed-off-by: Atish Patra
---
I could not test this patch on any ARM64 boards due to lack of
access to any ARM64 board. If anybody can test it on ARM64, that
would be great.
---
cmd/booti.c| 40 ++-
doc/README.distro | 12 +
doc/board/sifive/fu540.rst | 55 ++
3 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/cmd/booti.c b/cmd/booti.c
index de5058236e0a..4fff8cfcf69f 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -14,6 +14,7 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
/*
* Image booting support
*/
@@ -24,6 +25,12 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
ulong ld;
ulong relocated_addr;
ulong image_size;
+ uint8_t *temp;
+ ulong dest;
+ ulong dest_end;
+ unsigned long comp_len;
+ unsigned long decomp_len;
+ int ctype;
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
@@ -38,6 +45,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
debug("* kernel: cmdline image address = 0x%08lx\n", ld);
}
+ temp = map_sysmem(ld, 0);
+ ctype = image_decomp_type(temp, 2);
+ if (ctype > 0) {
+ dest = env_get_ulong("kernel_comp_addr_r", 16, 0);
+ comp_len = env_get_ulong("kernel_comp_size", 16, 0);
+ if (!dest || !comp_len) {
+ puts("kernel_comp_addr_r or kernel_comp_size is not
provided!\n");
+ return -EINVAL;
+ }
+ if (dest < gd->ram_base || dest > gd->ram_top) {
+ puts("kernel_comp_addr_r is outside of DRAM range!\n");
+ return -EINVAL;
+ }
+
+ debug("kernel image compression type %d size = 0x%08lx address
= 0x%08lx\n",
+ ctype, comp_len, (ulong)dest);
+ decomp_len = comp_len * 10;
+ ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
+(void *)dest, (void *)ld, comp_len,
+decomp_len, &dest_end);
+ if (ret)
+ return ret;
+ /* dest_end contains the uncompressed Image size */
+ memmove((void *) ld, (void *)dest, dest_end);
+ }
+ unmap_sysmem((void *)ld);
+
ret = booti_setup(ld, &relocated_addr, &image_size, false);
if (ret != 0)
return 1;
@@ -100,10 +134,14 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
#ifdef CONFIG_SYS_LONGHELP
static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
- "- boot Linux 'Image' stored at 'addr'\n"
+ "- boot Linux flat or compressed 'Image' stored at 'addr'\n"
"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
+ "\tCurrently only booting from gz, bz2, lzma and lz4 compression\n"
+ "\ttypes are supported. In order to boot from any of these compressed\n"
+ "\timages, user have to set kernel_comp_addr_r and kernel_comp_size
enviornment\n"
+ "\tvariables beforehand.\n"
#if defined(CONFIG_OF_LIBFDT)
"\tSince booting a Linux kernel requires a flat device-tree, a\n"
"\tthird argument providing the address of the device-tree blob\n"
diff --git a/doc/README.distro b/doc/README.distro
index ab6e6f4e74be..5076bebd1808 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -246,6 +246,18 @@ kernel_addr_r:
A size of 16MB for the kernel is likely adequate.
+kernel_comp_addr_r:
+ Optional. This is only required if user wants to boot Linux from a compressed
+ Image(.gz, .bz2, .lzma, .lzo) using booti command. It represents the location
+ in RAM
[RFT PATCH v5 1/3] lib: kconfig: Add option to set BZIP2 compression method
There is no way to select BZIP2 compression method. Add it under library/compression config where all other compression related configs are present. Signed-off-by: Atish Patra Reviewed-by: Tom Rini --- lib/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index ab6aff710dd6..ff8e955f899a 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -409,6 +409,11 @@ config GZIP help This enables support for GZIP compression algorithm. +config BZIP2 + bool "Enable bzip2 decompression support" + help + This enables support for BZIP2 compression algorithm. + config ZLIB bool default y -- 2.24.0
[RFT PATCH v5 0/3] Add compressed Image booting support
This patch series extends booti to support compressed images as well. Following compressed images are supported for now. lzma, lzo, bzip2, gz. Other compression methods can easily be supported if required. The above compression methods are common ones that Linux kernel (ARM64/RISC-V) and U-Boot supports. Changes from v4->v5 1. Moved back to explicit kernel_comp_size enviornemnt variable from filesize. 2. Rebased on top latest master. Changes from v3->v4 1. Removed CONFIG_SYS_BOOTM_LEN usage. Atish Patra (3): lib: kconfig: Add option to set BZIP2 compression method image: Add a common compression type detection function. image: Add compressed Image parsing support in booti. cmd/booti.c| 40 ++- common/image.c | 23 doc/README.distro | 12 + doc/board/sifive/fu540.rst | 55 ++ include/image.h| 21 +++ lib/Kconfig| 5 6 files changed, 155 insertions(+), 1 deletion(-) -- 2.24.0
Re: [RFC PATCH 0/1] Add boot hartid to a Device tree
On Wed, Mar 4, 2020 at 7:22 PM Schaefer, Daniel (DualStudy) wrote: > > Hi, > > I have started to implement the corresponding changes in EDK2: > https://github.com/changab/edk2-staging-riscv/compare/5f63e9249751ccb9302514455b9a1a7038f34547...RISC-V-DT-fixup > What happens is: The DTB is embedded in the FW image and passed to sbi_init > in SEC phase. We initialize OpenSBI as early as possible and because it also > wants to modify the device tree, I have to pass it the DTB as next_arg1. > Then it's passed to PEI in the firmware context and further to DXE via a HOB. > In DXE the boot-hartid is inserted and it's installed into the EFI system > config table from where the EFISTUB reads it. > > Unfortunately I don't get any console output after the EFISTUB calls > ExitBootServices, so my patch is still WIP. > Atish, which platform file in OpenSBI did you use to test your changes? > platform/qemu/virt/platform.c or platform/sifive/fu540/platform.c ? Both. I have verified bootefi boot on Qemu and Unleashed. > Maybe the failure is unrelated to the new patches - we've never booted Linux > from EDKII yet. > I have never tried EDKII patches as well. I will give it a try. You can add a quick hack can be added in OpenSBI to add the chosen node easily. By doing that, you ensure that EDK2 is unchanged and try my EFI stub patches. I might have missed something in EFI stub as well :). > > I'm a bit skeptical whether DT is the best way to pass the boothartid to the > kernel. Ard has argued that it's good because it's independent from UEFI, but > the proper kernel doesn't read the hartid from there - it gets it from a0. > Only the EFISTUB reads the hartid from the device tree. Therefore the > solution we need is EFI specific anyways, right? yes. > One of the design goals is that we don't want to force bootloaders, which > load the EFISTUB (e.g. UEFI Shell, grub chainloading, systemd-boot), to > change. > I don't know how systemd-boot works but grub doesn't need to modify DT. The stage loading the grub must have already made that modification. > If we let the firmware embed the hartid in the DT, the user cannot swap out > the DT later for their custom one. They need to use the one given by the > firmware. > Of course we could add commands and config to bootloaders to load and fixup > (embed hartid) the device tree... but, as mentioned earlier, we want to avoid > that. > Additionally from EDKII side we're also planning to run later stages, > including the bootloader, in S-Mode, where they wouldn't even have access to > mhartid and thus couldn't fixup the DT. > > If instead the firmware writes the hartid into the EFI system config table, > the EFISTUB can read it from there, just like it does the device tree > already. Then bootloaders can put a user supplied DT in the config table, > too, like they always have. > > What do you all think - does that make sense? > > - Daniel > On 2/25/20 10:07 AM, Ard Biesheuvel wrote: > > On Tue, 25 Feb 2020 at 09:59, Chang, Abner (HPS SW/FW Technologist) > wrote: > > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, February 25, 2020 4:48 PM > To: Chang, Abner (HPS SW/FW Technologist) > Cc: Atish Patra ; Heinrich Schuchardt > ; Atish Patra ; U-Boot Mailing > List ; Alexander Graf ; Anup Patel > ; Bin Meng ; Joe > Hershberger ; Loic Pallardy > ; Lukas Auer ; > Marek Behún ; Marek Vasut > ; Patrick Delaunay ; > Peng Fan ; Philippe Reynes > ; Simon Glass ; > Simon Goldschmidt ; Stefano Babic > ; Thierry Reding ; Tom Rini > ; l...@nuviainc.com; Schaefer, Daniel (DualStudy) > > Subject: Re: [RFC PATCH 0/1] Add boot hartid to a Device tree > > On Tue, 25 Feb 2020 at 09:28, Chang, Abner (HPS SW/FW Technologist) > wrote: > > -Original Message- > From: Atish Patra [mailto:ati...@atishpatra.org] > > > > On Mon, Feb 24, 2020 at 3:35 PM Ard Biesheuvel > wrote: > > On Tue, 25 Feb 2020 at 00:22, Heinrich Schuchardt > > > wrote: > > On 2/24/20 11:19 PM, Atish Patra wrote: > > The RISC-V booting protocol requires the hart id to be present in > > "a0" > > register. This is not a problem for bootm/booti commands as > they directly jump to Linux kernel. However, bootefi jumps to > a EFI boot stub code in Linux kernel which acts a loader and > jumps to real Linux after terminating the boot services. This > boot stub code has to be aware of the boot hart id so that it > can set it in "a0" before jumping to Linux kernel. Currently, > UEFI protocol doesn't have any mechanism to pass the boot hart > id to an EFI executable. We
Re: [RFT PATCH v5 3/3] image: Add compressed Image parsing support in booti.
On Fri, Mar 6, 2020 at 6:59 AM Tom Rini wrote: > > On Thu, Mar 05, 2020 at 04:24:23PM -0800, Atish Patra wrote: > > Add compressed Image parsing support so that booti can parse both > > flat and compressed Image to boot Linux. Currently, it is difficult > > to calculate a safe address for every board where the compressed > > image can be decompressed. It is also not possible to figure out the > > size of the compressed file as well. Thus, user need to set two > > additional environment variables kernel_comp_addr_r and filesize to > > make this work. > > > > Following compression methods are supported for now. > > lzma, lzo, bzip2, gzip. > > > > lz4 support is not added as ARM64 kernel generates a lz4 compressed > > image with legacy header which U-Boot doesn't know how to parse and > > decompress. > > Is that a "legacy lz4 header" or something else? Thanks! > Yeah. I was talking about legacy lz4 header as per U-Boot documentation. > -- > Tom -- Regards, Atish
[PATCH v2 1/4] riscv: Add boot hartid to Device tree
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-boot can not pass the hartid via a0 during via standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
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
Reviewed-by: Rick Chen
---
arch/riscv/lib/bootm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index fad16901c5f2..f927694ae32f 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,6 +28,28 @@ __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 accommodate new node");
+ return -1;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return -1;
+ }
+ }
+
+ /* Overwrite the boot-hartid as U-Boot is the last state BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
+ gd->arch.boot_hart);
+
return 0;
}
--
2.25.1
[PATCH v2 3/4] riscv: Provide a mechanism for riscv boards to parse reserved memory
In RISC-V, M-mode software can reserve physical memory regions
by setting appropriate physical memory protection (PMP) csr. As the
PMP csr are accessible only in M-mode, S-mode U-Boot can not read
this configuration directly. However, M-mode software can pass this
information via reserved-memory node in device tree so that S-mode
software can access this information.
In U-boot, any board may use the DT in following ways.
1. OF_SEPARTE: It ignores the DT from previous stage and uses the DT
from U-Boot sources.
2. OF_PRIOR_STATE: It reuses the DT from previous stage.
For case 1: U-Boot needs to parse the reserved-memory node from the
DT passed from the previous stage and update the DT in use.
This patch provides a framework to do that from any RISC-V boards.
Signed-off-by: Atish Patra
---
arch/riscv/cpu/start.S| 1 +
arch/riscv/include/asm/global_data.h | 1 +
arch/riscv/include/asm/u-boot-riscv.h | 1 +
arch/riscv/lib/asm-offsets.c | 1 +
arch/riscv/lib/bootm.c| 37 +++
5 files changed, 41 insertions(+)
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 6b3ff99c3882..0282685c2906 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -121,6 +121,7 @@ call_board_init_f_0:
jal board_init_f_init_reserve
+ SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index b74bd7e738bb..51ac8d1c98e2 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -15,6 +15,7 @@
/* Architecture-specific global data */
struct arch_global_data {
long boot_hart; /* boot hart id */
+ phys_addr_t firmware_fdt_addr;
#ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
#endif
diff --git a/arch/riscv/include/asm/u-boot-riscv.h
b/arch/riscv/include/asm/u-boot-riscv.h
index 49febd588102..b7bea0ba184d 100644
--- a/arch/riscv/include/asm/u-boot-riscv.h
+++ b/arch/riscv/include/asm/u-boot-riscv.h
@@ -17,5 +17,6 @@ int cleanup_before_linux(void);
/* board/.../... */
int board_init(void);
void board_quiesce_devices(void);
+int riscv_board_reserved_mem_fixup(void *fdt);
#endif /* _U_BOOT_RISCV_H_ */
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index 4fa4fd371473..7301c1b98e23 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,6 +14,7 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+ DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
#ifndef CONFIG_XIP
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
#endif
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index f927694ae32f..3a4d0bf14c86 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -26,6 +27,42 @@ __weak void board_quiesce_devices(void)
{
}
+int riscv_board_reserved_mem_fixup(void *fdt)
+{
+ uint32_t phandle;
+ struct fdt_memory pmp_mem;
+ int err;
+ void *src_fdt_addr;
+ int offset, node;
+ phys_addr_t addr, size;
+
+ src_fdt_addr = map_sysmem(gd->arch.firmware_fdt_addr, 0);
+ offset = fdt_path_offset(src_fdt_addr, "/reserved-memory");
+ if (offset < 0) {
+ printf("No reserved memory region found in FDT\n");
+ return offset;
+ }
+
+ fdt_for_each_subnode(node, src_fdt_addr, offset) {
+ const char *name = fdt_get_name(src_fdt_addr, node, NULL);
+
+ addr = fdtdec_get_addr_size(src_fdt_addr, node, "reg", &size);
+ if (addr == FDT_ADDR_T_NONE) {
+ debug("failed to read address/size for %s\n", name);
+ continue;
+ }
+ pmp_mem.start = addr;
+ pmp_mem.end = addr + size;
+ err = fdtdec_add_reserved_memory(fdt, name, &pmp_mem, &phandle);
+ if (err < 0) {
+ printf("failed to add reserved memory: %d\n", err);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
int arch_fixup_fdt(void *blob)
{
u32 size;
--
2.25.1
[PATCH v2 0/4] DT related fixes for RISC-V UEFI
This series adds few DT related fixes required for Linux EFI stub to work on RISC-V. Patch 1 adds the boot hartid property under /chosen node. The related discussion can be found here. https://patchwork.ozlabs.org/patch/1233664/ https://lists.denx.de/pipermail/u-boot/2020-March/402085.html Patch 2 fixes a generic issue in bootefi. Patch 3 & 4 provide one of the option to update reserved-memory node for Linux. It depends on Bin's following series in OpenSBI http://lists.infradead.org/pipermail/opensbi/2020-March/001316.html The other options are SBI extension and trap/emulate on PMP csr access. The detaild discussion can be found here. https://github.com/riscv/riscv-sbi-doc/pull/37 Patch 1 & 2 can be applied indepedently from 3 and 4. I want to keep all the patches together to provide a holistic view of changes required for RISC-V UEFI. Changes from v1->v2: 1. Fix the issue if chosen node is not present. Changes from previous version: 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". 2. Changed the property type to u32 instead of u64 for RV32 compatibility. Atish Patra (4): riscv: Add boot hartid to Device tree cmd: bootefi: Parse reserved-memory node from DT riscv: Provide a mechanism for riscv boards to parse reserved memory riscv: Setup reserved-memory node for FU540 arch/riscv/cpu/start.S| 1 + arch/riscv/include/asm/global_data.h | 1 + arch/riscv/include/asm/u-boot-riscv.h | 1 + arch/riscv/lib/asm-offsets.c | 1 + arch/riscv/lib/bootm.c| 59 +++ board/sifive/fu540/fu540.c| 15 +++ cmd/bootefi.c | 42 +++ configs/sifive_fu540_defconfig| 1 + 8 files changed, 112 insertions(+), 9 deletions(-) -- 2.25.1
[PATCH v2 4/4] riscv: Setup reserved-memory node for FU540
FU540 uses OF_SEPARATE instead of OF_PRIOR.
Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
Signed-off-by: Atish Patra
---
board/sifive/fu540/fu540.c | 15 +++
configs/sifive_fu540_defconfig | 1 +
2 files changed, 16 insertions(+)
diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
index 47a20902517c..82b3a9c8e729 100644
--- a/board/sifive/fu540/fu540.c
+++ b/board/sifive/fu540/fu540.c
@@ -141,6 +141,21 @@ int misc_init_r(void)
#endif
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *fdt)
+{
+ int err;
+
+ err = riscv_board_reserved_mem_fixup(fdt);
+ if (err < 0) {
+ printf("failed to fixup DT for reserved memory: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
/* For now nothing to do here. */
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 6d61e6c960ee..8fb3794cd578 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -12,3 +12,4 @@ CONFIG_DISPLAY_BOARDINFO=y
CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
+CONFIG_OF_BOARD_FIXUP=y
--
2.25.1
[PATCH v2 2/4] cmd: bootefi: Parse reserved-memory node from DT
Currently, bootefi only parses memory reservation block to setup
EFI reserved memory mappings. However, it doesn't parse the
reserved-memory[1] device tree node that also can contain the
reserved memory regions.
Add capability to parse reserved-memory node and update the EFI memory
mappings accordingly.
1. /doc/device-tree-bindings/reserved-memory/reserved-memory.txt]
Signed-off-by: Atish Patra
---
cmd/bootefi.c | 42 +-
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 24fc42ae898e..43b36fbacfcd 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -149,6 +149,20 @@ done:
return ret;
}
+static void efi_reserve_memory(uint64_t addr, uint64_t size)
+{
+ uint64_t pages;
+
+ /* Convert from sandbox address space. */
+ addr = (uintptr_t)map_sysmem(addr, 0);
+ pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
+ addr &= ~EFI_PAGE_MASK;
+ if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
+ false) != EFI_SUCCESS)
+ printf("Reserved memory mapping failed addr %llx size %llx\n",
+ (unsigned long long)addr, (unsigned long long)size);
+}
+
/**
* efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
*
@@ -161,7 +175,8 @@ done:
static void efi_carve_out_dt_rsv(void *fdt)
{
int nr_rsv, i;
- uint64_t addr, size, pages;
+ uint64_t addr, size;
+ int nodeoffset, subnode;
nr_rsv = fdt_num_mem_rsv(fdt);
@@ -169,15 +184,24 @@ static void efi_carve_out_dt_rsv(void *fdt)
for (i = 0; i < nr_rsv; i++) {
if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
continue;
+ efi_reserve_memory(addr, size);
+ }
- /* Convert from sandbox address space. */
- addr = (uintptr_t)map_sysmem(addr, 0);
-
- pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
- addr &= ~EFI_PAGE_MASK;
- if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
- false) != EFI_SUCCESS)
- printf("FDT memrsv map %d: Failed to add to map\n", i);
+ /* process reserved-memory */
+ nodeoffset = fdt_subnode_offset(fdt, 0, "reserved-memory");
+ if (nodeoffset >= 0) {
+ subnode = fdt_first_subnode(fdt, nodeoffset);
+ while (subnode >= 0) {
+ /* check if this subnode has a reg property */
+ addr = fdtdec_get_addr_size(fdt, subnode, "reg",
+ (fdt_size_t *)&size);
+ if (addr == FDT_ADDR_T_NONE) {
+ debug("failed to read address/size\n");
+ continue;
+ }
+ efi_reserve_memory(addr, size);
+ subnode = fdt_next_subnode(fdt, subnode);
+ }
}
}
--
2.25.1
Re: [PATCH v2 0/4] DT related fixes for RISC-V UEFI
On Fri, Mar 13, 2020 at 5:11 PM Atish Patra wrote: > > This series adds few DT related fixes required for Linux EFI stub to work > on RISC-V. > > Patch 1 adds the boot hartid property under /chosen node. The related > discussion can be found here. > > https://patchwork.ozlabs.org/patch/1233664/ > https://lists.denx.de/pipermail/u-boot/2020-March/402085.html > > Patch 2 fixes a generic issue in bootefi. > > Patch 3 & 4 provide one of the option to update reserved-memory node for > Linux. > It depends on Bin's following series in OpenSBI > http://lists.infradead.org/pipermail/opensbi/2020-March/001316.html > > The other options are SBI extension and trap/emulate on PMP csr access. > The detaild discussion can be found here. > https://github.com/riscv/riscv-sbi-doc/pull/37 > > Patch 1 & 2 can be applied indepedently from 3 and 4. I want to keep all > the patches together to provide a holistic view of changes required for > RISC-V UEFI. > > Changes from v1->v2: > 1. Fix the issue if chosen node is not present. > > Changes from previous version: > 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". > 2. Changed the property type to u32 instead of u64 for RV32 compatibility. > > Atish Patra (4): > riscv: Add boot hartid to Device tree > cmd: bootefi: Parse reserved-memory node from DT > riscv: Provide a mechanism for riscv boards to parse reserved memory > riscv: Setup reserved-memory node for FU540 > > arch/riscv/cpu/start.S| 1 + > arch/riscv/include/asm/global_data.h | 1 + > arch/riscv/include/asm/u-boot-riscv.h | 1 + > arch/riscv/lib/asm-offsets.c | 1 + > arch/riscv/lib/bootm.c| 59 +++ > board/sifive/fu540/fu540.c| 15 +++ > cmd/bootefi.c | 42 +++ > configs/sifive_fu540_defconfig| 1 + > 8 files changed, 112 insertions(+), 9 deletions(-) > > -- > 2.25.1 > Fixed palmer's email address. Sorry for the spam. -- Regards, Atish
Re: [PATCH v2 1/4] riscv: Add boot hartid to Device tree
On Fri, Mar 13, 2020 at 5:12 PM Atish Patra wrote:
>
> Linux booting protocol mandates that register "a0" contains the hartid.
> However, U-boot can not pass the hartid via a0 during via standard UEFI
> protocol. DT nodes are commonly used to pass such information to the OS.
>
> 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
> Reviewed-by: Rick Chen
> ---
> arch/riscv/lib/bootm.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> index fad16901c5f2..f927694ae32f 100644
> --- a/arch/riscv/lib/bootm.c
> +++ b/arch/riscv/lib/bootm.c
> @@ -28,6 +28,28 @@ __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 accommodate new
> node");
> + return -1;
> + }
> + chosen_offset = fdt_path_offset(blob, "/chosen");
> + if (chosen_offset < 0) {
> + err = fdt_add_subnode(blob, 0, "chosen");
> + if (err < 0) {
> + printf("chosen node can not be added\n");
> + return -1;
> + }
> + }
> +
> + /* Overwrite the boot-hartid as U-Boot is the last state BL */
> + fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
> + gd->arch.boot_hart);
> +
> return 0;
> }
>
> --
> 2.25.1
>
Fixed palmer's email address. Sorry for the spam.
--
Regards,
Atish
Re: [PATCH v2 4/4] riscv: Setup reserved-memory node for FU540
On Fri, Mar 13, 2020 at 5:12 PM Atish Patra wrote:
>
> FU540 uses OF_SEPARATE instead of OF_PRIOR.
>
> Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
>
> Signed-off-by: Atish Patra
> ---
> board/sifive/fu540/fu540.c | 15 +++
> configs/sifive_fu540_defconfig | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> index 47a20902517c..82b3a9c8e729 100644
> --- a/board/sifive/fu540/fu540.c
> +++ b/board/sifive/fu540/fu540.c
> @@ -141,6 +141,21 @@ int misc_init_r(void)
>
> #endif
>
> +#ifdef CONFIG_OF_BOARD_FIXUP
> +int board_fix_fdt(void *fdt)
> +{
> + int err;
> +
> + err = riscv_board_reserved_mem_fixup(fdt);
> + if (err < 0) {
> + printf("failed to fixup DT for reserved memory: %d\n", err);
> + return err;
> + }
> +
> + return 0;
> +}
> +#endif
> +
> int board_init(void)
> {
> /* For now nothing to do here. */
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
> index 6d61e6c960ee..8fb3794cd578 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -12,3 +12,4 @@ CONFIG_DISPLAY_BOARDINFO=y
> CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_DM_MTD=y
> +CONFIG_OF_BOARD_FIXUP=y
> --
> 2.25.1
>
Fixed palmer's email address. Sorry for the spam.
--
Regards,
Atish
Re: [PATCH v2 3/4] riscv: Provide a mechanism for riscv boards to parse reserved memory
On Fri, Mar 13, 2020 at 5:12 PM Atish Patra wrote:
>
> In RISC-V, M-mode software can reserve physical memory regions
> by setting appropriate physical memory protection (PMP) csr. As the
> PMP csr are accessible only in M-mode, S-mode U-Boot can not read
> this configuration directly. However, M-mode software can pass this
> information via reserved-memory node in device tree so that S-mode
> software can access this information.
>
> In U-boot, any board may use the DT in following ways.
> 1. OF_SEPARTE: It ignores the DT from previous stage and uses the DT
> from U-Boot sources.
> 2. OF_PRIOR_STATE: It reuses the DT from previous stage.
> For case 1: U-Boot needs to parse the reserved-memory node from the
> DT passed from the previous stage and update the DT in use.
>
> This patch provides a framework to do that from any RISC-V boards.
>
> Signed-off-by: Atish Patra
> ---
> arch/riscv/cpu/start.S| 1 +
> arch/riscv/include/asm/global_data.h | 1 +
> arch/riscv/include/asm/u-boot-riscv.h | 1 +
> arch/riscv/lib/asm-offsets.c | 1 +
> arch/riscv/lib/bootm.c| 37 +++
> 5 files changed, 41 insertions(+)
>
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 6b3ff99c3882..0282685c2906 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -121,6 +121,7 @@ call_board_init_f_0:
>
> jal board_init_f_init_reserve
>
> + SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> /* save the boot hart id to global_data */
> SREGtp, GD_BOOT_HART(gp)
>
> diff --git a/arch/riscv/include/asm/global_data.h
> b/arch/riscv/include/asm/global_data.h
> index b74bd7e738bb..51ac8d1c98e2 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -15,6 +15,7 @@
> /* Architecture-specific global data */
> struct arch_global_data {
> long boot_hart; /* boot hart id */
> + phys_addr_t firmware_fdt_addr;
> #ifdef CONFIG_SIFIVE_CLINT
> void __iomem *clint;/* clint base address */
> #endif
> diff --git a/arch/riscv/include/asm/u-boot-riscv.h
> b/arch/riscv/include/asm/u-boot-riscv.h
> index 49febd588102..b7bea0ba184d 100644
> --- a/arch/riscv/include/asm/u-boot-riscv.h
> +++ b/arch/riscv/include/asm/u-boot-riscv.h
> @@ -17,5 +17,6 @@ int cleanup_before_linux(void);
> /* board/.../... */
> int board_init(void);
> void board_quiesce_devices(void);
> +int riscv_board_reserved_mem_fixup(void *fdt);
>
> #endif /* _U_BOOT_RISCV_H_ */
> diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
> index 4fa4fd371473..7301c1b98e23 100644
> --- a/arch/riscv/lib/asm-offsets.c
> +++ b/arch/riscv/lib/asm-offsets.c
> @@ -14,6 +14,7 @@
> int main(void)
> {
> DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
> + DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
> #ifndef CONFIG_XIP
> DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
> #endif
> diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> index f927694ae32f..3a4d0bf14c86 100644
> --- a/arch/riscv/lib/bootm.c
> +++ b/arch/riscv/lib/bootm.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -26,6 +27,42 @@ __weak void board_quiesce_devices(void)
> {
> }
>
> +int riscv_board_reserved_mem_fixup(void *fdt)
> +{
> + uint32_t phandle;
> + struct fdt_memory pmp_mem;
> + int err;
> + void *src_fdt_addr;
> + int offset, node;
> + phys_addr_t addr, size;
> +
> + src_fdt_addr = map_sysmem(gd->arch.firmware_fdt_addr, 0);
> + offset = fdt_path_offset(src_fdt_addr, "/reserved-memory");
> + if (offset < 0) {
> + printf("No reserved memory region found in FDT\n");
> + return offset;
> + }
> +
> + fdt_for_each_subnode(node, src_fdt_addr, offset) {
> + const char *name = fdt_get_name(src_fdt_addr, node, NULL);
> +
> + addr = fdtdec_get_addr_size(src_fdt_addr, node, "reg", &size);
> + if (addr == FDT_ADDR_T_NONE) {
> + debug("failed to read address/size for %s\n", name);
> + continue;
> + }
> + pmp_mem.start = addr;
> + pmp_mem.end = addr + size;
> + err = fdtdec_add_reserved_memory(fdt, name, &pmp_mem,
> &phandle);
> + if (err < 0) {
> + printf("failed to add reserved memory: %d\n", err);
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +
> int arch_fixup_fdt(void *blob)
> {
> u32 size;
> --
> 2.25.1
>
Fixed palmer's email address. Sorry for the spam.
--
Regards,
Atish
Re: [PATCH v2 2/4] cmd: bootefi: Parse reserved-memory node from DT
On Fri, Mar 13, 2020 at 5:12 PM Atish Patra wrote:
>
> Currently, bootefi only parses memory reservation block to setup
> EFI reserved memory mappings. However, it doesn't parse the
> reserved-memory[1] device tree node that also can contain the
> reserved memory regions.
>
> Add capability to parse reserved-memory node and update the EFI memory
> mappings accordingly.
>
> 1. source>/doc/device-tree-bindings/reserved-memory/reserved-memory.txt]
>
> Signed-off-by: Atish Patra
> ---
> cmd/bootefi.c | 42 +-
> 1 file changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 24fc42ae898e..43b36fbacfcd 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -149,6 +149,20 @@ done:
> return ret;
> }
>
> +static void efi_reserve_memory(uint64_t addr, uint64_t size)
> +{
> + uint64_t pages;
> +
> + /* Convert from sandbox address space. */
> + addr = (uintptr_t)map_sysmem(addr, 0);
> + pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
> + addr &= ~EFI_PAGE_MASK;
> + if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
> + false) != EFI_SUCCESS)
> + printf("Reserved memory mapping failed addr %llx size %llx\n",
> + (unsigned long long)addr, (unsigned long long)size);
> +}
> +
> /**
> * efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
> *
> @@ -161,7 +175,8 @@ done:
> static void efi_carve_out_dt_rsv(void *fdt)
> {
> int nr_rsv, i;
> - uint64_t addr, size, pages;
> + uint64_t addr, size;
> + int nodeoffset, subnode;
>
> nr_rsv = fdt_num_mem_rsv(fdt);
>
> @@ -169,15 +184,24 @@ static void efi_carve_out_dt_rsv(void *fdt)
> for (i = 0; i < nr_rsv; i++) {
> if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
> continue;
> + efi_reserve_memory(addr, size);
> + }
>
> - /* Convert from sandbox address space. */
> - addr = (uintptr_t)map_sysmem(addr, 0);
> -
> - pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
> - addr &= ~EFI_PAGE_MASK;
> - if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
> - false) != EFI_SUCCESS)
> - printf("FDT memrsv map %d: Failed to add to map\n",
> i);
> + /* process reserved-memory */
> + nodeoffset = fdt_subnode_offset(fdt, 0, "reserved-memory");
> + if (nodeoffset >= 0) {
> + subnode = fdt_first_subnode(fdt, nodeoffset);
> + while (subnode >= 0) {
> + /* check if this subnode has a reg property */
> + addr = fdtdec_get_addr_size(fdt, subnode, "reg",
> + (fdt_size_t *)&size);
> + if (addr == FDT_ADDR_T_NONE) {
> + debug("failed to read address/size\n");
> + continue;
> + }
> + efi_reserve_memory(addr, size);
> + subnode = fdt_next_subnode(fdt, subnode);
> + }
> }
> }
>
> --
> 2.25.1
>
Fixed palmer's email address. Sorry for the spam.
--
Regards,
Atish
Re: [PATCH v2 3/4] riscv: Provide a mechanism for riscv boards to parse reserved memory
On Sat, Mar 14, 2020 at 3:00 AM Bin Meng wrote:
>
> Hi Atish,
>
> On Sat, Mar 14, 2020 at 8:54 AM Atish Patra wrote:
> >
> > On Fri, Mar 13, 2020 at 5:12 PM Atish Patra wrote:
> > >
> > > In RISC-V, M-mode software can reserve physical memory regions
> > > by setting appropriate physical memory protection (PMP) csr. As the
> > > PMP csr are accessible only in M-mode, S-mode U-Boot can not read
> > > this configuration directly. However, M-mode software can pass this
> > > information via reserved-memory node in device tree so that S-mode
> > > software can access this information.
> > >
> > > In U-boot, any board may use the DT in following ways.
>
> nits: U-Boot
>
> > > 1. OF_SEPARTE: It ignores the DT from previous stage and uses the DT
>
> typo: OF_SEPARATE
>
> > > from U-Boot sources.
> > > 2. OF_PRIOR_STATE: It reuses the DT from previous stage.
>
> typo: OF_PRIOR_STAGE
>
> > > For case 1: U-Boot needs to parse the reserved-memory node from the
> > > DT passed from the previous stage and update the DT in use.
> > >
> > > This patch provides a framework to do that from any RISC-V boards.
> > >
> > > Signed-off-by: Atish Patra
> > > ---
> > > arch/riscv/cpu/start.S| 1 +
> > > arch/riscv/include/asm/global_data.h | 1 +
> > > arch/riscv/include/asm/u-boot-riscv.h | 1 +
> > > arch/riscv/lib/asm-offsets.c | 1 +
> > > arch/riscv/lib/bootm.c| 37 +++
> > > 5 files changed, 41 insertions(+)
> > >
> > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > index 6b3ff99c3882..0282685c2906 100644
> > > --- a/arch/riscv/cpu/start.S
> > > +++ b/arch/riscv/cpu/start.S
> > > @@ -121,6 +121,7 @@ call_board_init_f_0:
> > >
> > > jal board_init_f_init_reserve
> > >
> > > + SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> > > /* save the boot hart id to global_data */
> > > SREGtp, GD_BOOT_HART(gp)
> > >
> > > diff --git a/arch/riscv/include/asm/global_data.h
> > > b/arch/riscv/include/asm/global_data.h
> > > index b74bd7e738bb..51ac8d1c98e2 100644
> > > --- a/arch/riscv/include/asm/global_data.h
> > > +++ b/arch/riscv/include/asm/global_data.h
> > > @@ -15,6 +15,7 @@
> > > /* Architecture-specific global data */
> > > struct arch_global_data {
> > > long boot_hart; /* boot hart id */
> > > + phys_addr_t firmware_fdt_addr;
> > > #ifdef CONFIG_SIFIVE_CLINT
> > > void __iomem *clint;/* clint base address */
> > > #endif
> > > diff --git a/arch/riscv/include/asm/u-boot-riscv.h
> > > b/arch/riscv/include/asm/u-boot-riscv.h
> > > index 49febd588102..b7bea0ba184d 100644
> > > --- a/arch/riscv/include/asm/u-boot-riscv.h
> > > +++ b/arch/riscv/include/asm/u-boot-riscv.h
> > > @@ -17,5 +17,6 @@ int cleanup_before_linux(void);
> > > /* board/.../... */
> > > int board_init(void);
> > > void board_quiesce_devices(void);
> > > +int riscv_board_reserved_mem_fixup(void *fdt);
> > >
> > > #endif /* _U_BOOT_RISCV_H_ */
> > > diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
> > > index 4fa4fd371473..7301c1b98e23 100644
> > > --- a/arch/riscv/lib/asm-offsets.c
> > > +++ b/arch/riscv/lib/asm-offsets.c
> > > @@ -14,6 +14,7 @@
> > > int main(void)
> > > {
> > > DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
> > > + DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t,
> > > arch.firmware_fdt_addr));
> > > #ifndef CONFIG_XIP
> > > DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
> > > #endif
> > > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > > index f927694ae32f..3a4d0bf14c86 100644
> > > --- a/arch/riscv/lib/bootm.c
> > > +++ b/arch/riscv/lib/bootm.c
> > > @@ -19,6 +19,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > DECLARE_GLOBAL_DATA_PTR;
> > >
> > > @@ -26,6 +27,42 @@ __weak void board_quiesce_devices(void)
> > > {
> > > }
> > >
> > > +int riscv_board_reserved_mem_fixup(void *fdt)
> > > +{
> > > + uint32_t phandle;
> > > + struct fdt_memory pmp
Re: [PATCH v2 4/4] riscv: Setup reserved-memory node for FU540
On Sat, Mar 14, 2020 at 3:18 AM Bin Meng wrote:
>
> Hi Atish,
>
> On Sat, Mar 14, 2020 at 8:11 AM Atish Patra wrote:
> >
> > FU540 uses OF_SEPARATE instead of OF_PRIOR.
> >
> > Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
> >
> > Signed-off-by: Atish Patra
> > ---
> > board/sifive/fu540/fu540.c | 15 +++
> > configs/sifive_fu540_defconfig | 1 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> > index 47a20902517c..82b3a9c8e729 100644
> > --- a/board/sifive/fu540/fu540.c
> > +++ b/board/sifive/fu540/fu540.c
> > @@ -141,6 +141,21 @@ int misc_init_r(void)
> >
> > #endif
> >
> > +#ifdef CONFIG_OF_BOARD_FIXUP
> > +int board_fix_fdt(void *fdt)
>
> This is used to fix-up the DT that U-Boot uses, not the DT that
> operating system uses.
>
Ahh yes. User can load DT from sdcard or network for OS usage.
We should also update the arch_fixup_fdt as well so that OS sees
the reserved memory nodes.
> As I mentioned in
> https://github.com/riscv/riscv-sbi-doc/pull/37#issuecomment-596184723,
> we need consider U-Boot SPL usage.
>
If U-Boot SPL is built without a DT, OpenSBI should be built with a DT.
Here are the constraints to use reserved-memory:
For any DT based platform:
1. If the stage prior to OpenSBI i.e. FSBL, U-Boot SPL is built
without a DT, OpenSBI
must be built with a DT.
2. If U-boot proper is built with OF_SEPARATE, OF_BOARD_FIXUP should be enabled
as well so that U-Boot can copy the reserved-memory nodes from
previous stage DT and update
the current DT in use.
> > +{
> > + int err;
> > +
> > + err = riscv_board_reserved_mem_fixup(fdt);
> > + if (err < 0) {
> > + printf("failed to fixup DT for reserved memory: %d\n", err);
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +#endif
> > +
> > int board_init(void)
> > {
> > /* For now nothing to do here. */
> > diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
> > index 6d61e6c960ee..8fb3794cd578 100644
> > --- a/configs/sifive_fu540_defconfig
> > +++ b/configs/sifive_fu540_defconfig
> > @@ -12,3 +12,4 @@ CONFIG_DISPLAY_BOARDINFO=y
> > CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
> > CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > CONFIG_DM_MTD=y
> > +CONFIG_OF_BOARD_FIXUP=y
> > --
>
> Regards,
> Bin
--
Regards,
Atish
[PATCH v3 1/5] riscv: Add boot hartid to Device tree
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-boot can not pass the hartid via a0 during via standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
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
Reviewed-by: Rick Chen
---
arch/riscv/lib/bootm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index fad16901c5f2..f927694ae32f 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,6 +28,28 @@ __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 accommodate new node");
+ return -1;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return -1;
+ }
+ }
+
+ /* Overwrite the boot-hartid as U-Boot is the last state BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
+ gd->arch.boot_hart);
+
return 0;
}
--
2.25.1
[PATCH v3 2/5] cmd: bootefi: Parse reserved-memory node from DT
Currently, bootefi only parses memory reservation block to setup
EFI reserved memory mappings. However, it doesn't parse the
reserved-memory[1] device tree node that also can contain the
reserved memory regions.
Add capability to parse reserved-memory node and update the EFI memory
mappings accordingly.
1. /doc/device-tree-bindings/reserved-memory/reserved-memory.txt]
Signed-off-by: Atish Patra
---
cmd/bootefi.c | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 24fc42ae898e..291cb2d69ff6 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -149,6 +149,20 @@ done:
return ret;
}
+static void efi_reserve_memory(uint64_t addr, uint64_t size)
+{
+ uint64_t pages;
+
+ /* Convert from sandbox address space. */
+ addr = (uintptr_t)map_sysmem(addr, 0);
+ pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
+ addr &= ~EFI_PAGE_MASK;
+ if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
+ false) != EFI_SUCCESS)
+ printf("Reserved memory mapping failed addr %llx size %llx\n",
+ (unsigned long long)addr, (unsigned long long)size);
+}
+
/**
* efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
*
@@ -161,7 +175,8 @@ done:
static void efi_carve_out_dt_rsv(void *fdt)
{
int nr_rsv, i;
- uint64_t addr, size, pages;
+ uint64_t addr, size;
+ int nodeoffset, subnode;
nr_rsv = fdt_num_mem_rsv(fdt);
@@ -169,15 +184,26 @@ static void efi_carve_out_dt_rsv(void *fdt)
for (i = 0; i < nr_rsv; i++) {
if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
continue;
+ efi_reserve_memory(addr, size);
+ }
- /* Convert from sandbox address space. */
- addr = (uintptr_t)map_sysmem(addr, 0);
-
- pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
- addr &= ~EFI_PAGE_MASK;
- if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
- false) != EFI_SUCCESS)
- printf("FDT memrsv map %d: Failed to add to map\n", i);
+ /* process reserved-memory */
+ nodeoffset = fdt_subnode_offset(fdt, 0, "reserved-memory");
+ if (nodeoffset < 0)
+ return;
+ subnode = fdt_first_subnode(fdt, nodeoffset);
+ while (subnode >= 0) {
+ /* check if this subnode has a reg property */
+ addr = fdtdec_get_addr_size_auto_noparent(fdt, subnode,
+ "reg", 0,
+ (fdt_size_t *)&size,
+ true);
+ if (addr == FDT_ADDR_T_NONE) {
+ debug("failed to read address/size\n");
+ continue;
+ }
+ efi_reserve_memory(addr, size);
+ subnode = fdt_next_subnode(fdt, subnode);
}
}
--
2.25.1
[PATCH v3 0/5] DT related fixes for RISC-V UEFI
This series adds few DT related fixes required for Linux EFI stub to work on RISC-V. Patch 1 adds the boot hartid property under /chosen node. The related discussion can be found here. https://patchwork.ozlabs.org/patch/1233664/ https://lists.denx.de/pipermail/u-boot/2020-March/402085.html Patch 2 fixes a generic issue in bootefi. Patch 3,4,5 provide one of the option to update reserved-memory node for next stage. It depends on Bin's following series in OpenSBI http://lists.infradead.org/pipermail/opensbi/2020-March/001316.html The other options are SBI extension and trap/emulate on PMP csr access. The detaild discussion can be found here. https://github.com/riscv/riscv-sbi-doc/pull/37 Patch 1 & 2 can be applied independently from 3 and 4. I want to keep all the patches together to provide a holistic view of changes required for RISC-V UEFI. Changes from v2->v3: 1. Update the DT meant for OS if it is different from the one used by U-Boot 2. Use different FDT api to obtain "reg" address & size to honor the cell count. Changes from v1->v2: 1. Fix the issue if chosen node is not present. Changes from previous version: 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". 2. Changed the property type to u32 instead of u64 for RV32 compatibility. Atish Patra (5): riscv: Add boot hartid to Device tree cmd: bootefi: Parse reserved-memory node from DT riscv: Provide a mechanism to fix DT for reserved memory riscv: Setup reserved-memory node for FU540 riscv: Copy the reserved-memory nodes to final DT arch/riscv/cpu/start.S| 1 + arch/riscv/include/asm/global_data.h | 1 + arch/riscv/include/asm/u-boot-riscv.h | 1 + arch/riscv/lib/asm-offsets.c | 1 + arch/riscv/lib/bootm.c| 95 +++ board/sifive/fu540/fu540.c| 15 + cmd/bootefi.c | 44 ++--- configs/sifive_fu540_defconfig| 1 + 8 files changed, 150 insertions(+), 9 deletions(-) -- 2.25.1
[PATCH v3 5/5] riscv: Copy the reserved-memory nodes to final DT
The DT used by U-Boot may be different from the DT being passed to the OS if the DT is loaded from external media such as network or mmc. In that case, the reserved-memory node needs to be copied to the DT passed to the OS. Signed-off-by: Atish Patra --- arch/riscv/lib/bootm.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c index 5e907e96701c..1ca8370849a0 100644 --- a/arch/riscv/lib/bootm.c +++ b/arch/riscv/lib/bootm.c @@ -118,6 +118,11 @@ int arch_fixup_fdt(void *blob) fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart); + /* Copy the reserved-memory node to the DT used by OS */ + err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob); + if (err < 0) + return err; + return 0; } -- 2.25.1
[PATCH v3 3/5] riscv: Provide a mechanism to fix DT for reserved memory
In RISC-V, M-mode software can reserve physical memory regions
by setting appropriate physical memory protection (PMP) csr. As the
PMP csr are accessible only in M-mode, S-mode U-Boot can not read
this configuration directly. However, M-mode software can pass this
information via reserved-memory node in device tree so that S-mode
software can access this information.
This patch provides a framework to copy to the reserved-memory node
from one DT to another. This will be used to update the DT used by
U-Boot and the DT passed to the next stage OS.
Signed-off-by: Atish Patra
---
arch/riscv/cpu/start.S| 1 +
arch/riscv/include/asm/global_data.h | 1 +
arch/riscv/include/asm/u-boot-riscv.h | 1 +
arch/riscv/lib/asm-offsets.c | 1 +
arch/riscv/lib/bootm.c| 68 +++
5 files changed, 72 insertions(+)
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 6b3ff99c3882..0282685c2906 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -121,6 +121,7 @@ call_board_init_f_0:
jal board_init_f_init_reserve
+ SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index b74bd7e738bb..51ac8d1c98e2 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -15,6 +15,7 @@
/* Architecture-specific global data */
struct arch_global_data {
long boot_hart; /* boot hart id */
+ phys_addr_t firmware_fdt_addr;
#ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
#endif
diff --git a/arch/riscv/include/asm/u-boot-riscv.h
b/arch/riscv/include/asm/u-boot-riscv.h
index 49febd588102..b7bea0ba184d 100644
--- a/arch/riscv/include/asm/u-boot-riscv.h
+++ b/arch/riscv/include/asm/u-boot-riscv.h
@@ -17,5 +17,6 @@ int cleanup_before_linux(void);
/* board/.../... */
int board_init(void);
void board_quiesce_devices(void);
+int riscv_board_reserved_mem_fixup(void *fdt);
#endif /* _U_BOOT_RISCV_H_ */
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index 4fa4fd371473..7301c1b98e23 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,6 +14,7 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+ DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
#ifndef CONFIG_XIP
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
#endif
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index f927694ae32f..5e907e96701c 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -26,6 +27,73 @@ __weak void board_quiesce_devices(void)
{
}
+int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
+{
+ uint32_t phandle;
+ struct fdt_memory pmp_mem;
+ fdt_addr_t addr;
+ fdt_size_t size;
+ int offset, node, err, rmem_offset;
+ bool nomap = false;
+ char basename[32] = {0};
+ int bname_len;
+ int max_len = sizeof(basename);
+ const char *name;
+ char *temp;
+
+ offset = fdt_path_offset(src, "/reserved-memory");
+ if (offset < 0) {
+ printf("No reserved memory region found in source FDT\n");
+ return 0;
+ }
+
+ fdt_for_each_subnode(node, src, offset) {
+ name = fdt_get_name(src, node, NULL);
+
+ addr = fdtdec_get_addr_size_auto_noparent(src, node,
+ "reg", 0, &size,
+ true);
+ if (addr == FDT_ADDR_T_NONE) {
+ debug("failed to read address/size for %s\n", name);
+ continue;
+ }
+ strncpy(basename, name, max_len);
+ temp = strchr(basename, '@');
+ if (temp) {
+ bname_len = strnlen(basename, max_len) - strnlen(temp,
+ max_len);
+ *(basename+bname_len) = '\0';
+ }
+ pmp_mem.start = addr;
+ pmp_mem.end = addr + size;
+ err = fdtdec_add_reserved_memory(dst, basename, &pmp_mem,
+&phandle);
+ if (err < 0) {
+ printf("failed to add reserved memory: %d\n", err);
+ return err;
+ }
+ rmem_offset = fdt_node_offset_by_phandle(dst, phandle);
+ nomap = fdt_get_property(src, node, "no-map",
[PATCH v3 4/5] riscv: Setup reserved-memory node for FU540
FU540 uses OF_SEPARATE instead of OF_PRIOR.
Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
Signed-off-by: Atish Patra
---
board/sifive/fu540/fu540.c | 15 +++
configs/sifive_fu540_defconfig | 1 +
2 files changed, 16 insertions(+)
diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
index 47a20902517c..82b3a9c8e729 100644
--- a/board/sifive/fu540/fu540.c
+++ b/board/sifive/fu540/fu540.c
@@ -141,6 +141,21 @@ int misc_init_r(void)
#endif
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *fdt)
+{
+ int err;
+
+ err = riscv_board_reserved_mem_fixup(fdt);
+ if (err < 0) {
+ printf("failed to fixup DT for reserved memory: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
/* For now nothing to do here. */
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 6d61e6c960ee..8fb3794cd578 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -12,3 +12,4 @@ CONFIG_DISPLAY_BOARDINFO=y
CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
+CONFIG_OF_BOARD_FIXUP=y
--
2.25.1
Re: [PATCH v2 2/4] cmd: bootefi: Parse reserved-memory node from DT
On Sat, Mar 14, 2020 at 12:14 AM Heinrich Schuchardt wrote:
>
> On 3/14/20 1:55 AM, Atish Patra wrote:
> > On Fri, Mar 13, 2020 at 5:12 PM Atish Patra wrote:
> >>
> >> Currently, bootefi only parses memory reservation block to setup
> >> EFI reserved memory mappings. However, it doesn't parse the
> >> reserved-memory[1] device tree node that also can contain the
> >> reserved memory regions.
> >>
> >> Add capability to parse reserved-memory node and update the EFI memory
> >> mappings accordingly.
>
> Hello Atish,
>
> thanks for reporting the problem.
>
> I would appreciate a test to verify that the code really works. We
> should add both types of reserved-memory device tree node to the sandbox
> device-tree and parse the output of 'efidebug memmap' and compare it to
> the output of 'fdt print'. Could you, please, provide a first patch for
> sandbox.dts and sandbox64.dts. The next step then would be to build a
> Python test.
>
Sorry I didn't see your reply before sending out a v3. I missed this
email earlier because of a wrong email filter.
I will add the tests and fix the endless loop problem in v4 as you suggested.
> This patch series could be split into two. One for EFI and one for RISC-V.
>
> (see comment below)
>
> >>
> >> 1. >> source>/doc/device-tree-bindings/reserved-memory/reserved-memory.txt]
> >>
> >> Signed-off-by: Atish Patra
> >> ---
> >> cmd/bootefi.c | 42 +-
> >> 1 file changed, 33 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >> index 24fc42ae898e..43b36fbacfcd 100644
> >> --- a/cmd/bootefi.c
> >> +++ b/cmd/bootefi.c
> >> @@ -149,6 +149,20 @@ done:
> >> return ret;
> >> }
> >>
> >> +static void efi_reserve_memory(uint64_t addr, uint64_t size)
> >> +{
> >> + uint64_t pages;
> >> +
> >> + /* Convert from sandbox address space. */
> >> + addr = (uintptr_t)map_sysmem(addr, 0);
> >> + pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
> >> + addr &= ~EFI_PAGE_MASK;
> >> + if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
> >> + false) != EFI_SUCCESS)
> >> + printf("Reserved memory mapping failed addr %llx size
> >> %llx\n",
> >> + (unsigned long long)addr, (unsigned long long)size);
> >> +}
> >> +
> >> /**
> >>* efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
> >>*
> >> @@ -161,7 +175,8 @@ done:
> >> static void efi_carve_out_dt_rsv(void *fdt)
> >> {
> >> int nr_rsv, i;
> >> - uint64_t addr, size, pages;
> >> + uint64_t addr, size;
> >> + int nodeoffset, subnode;
> >>
> >> nr_rsv = fdt_num_mem_rsv(fdt);
> >>
> >> @@ -169,15 +184,24 @@ static void efi_carve_out_dt_rsv(void *fdt)
> >> for (i = 0; i < nr_rsv; i++) {
> >> if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
> >> continue;
> >> + efi_reserve_memory(addr, size);
> >> + }
> >>
> >> - /* Convert from sandbox address space. */
> >> - addr = (uintptr_t)map_sysmem(addr, 0);
> >> -
> >> - pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
> >> - addr &= ~EFI_PAGE_MASK;
> >> - if (efi_add_memory_map(addr, pages,
> >> EFI_RESERVED_MEMORY_TYPE,
> >> - false) != EFI_SUCCESS)
> >> - printf("FDT memrsv map %d: Failed to add to
> >> map\n", i);
> >> + /* process reserved-memory */
> >> + nodeoffset = fdt_subnode_offset(fdt, 0, "reserved-memory");
> >> + if (nodeoffset >= 0) {
> >> + subnode = fdt_first_subnode(fdt, nodeoffset);
> >> + while (subnode >= 0) {
> >> + /* check if this subnode has a reg property */
> >> + addr = fdtdec_get_addr_size(fdt, subnode, "reg",
> >> + (fdt_size_t *)&size);
> >> + if (addr == FDT_AD
Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI
On Mon, Apr 13, 2020 at 3:42 PM Bin Meng wrote:
>
> Hi Atish,
>
> On Tue, Apr 14, 2020 at 6:02 AM Atish Patra wrote:
> >
> > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra wrote:
> > >
> > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel
> > > wrote:
> > > >
> > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt
> > > > wrote:
> > > > >
> > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote:
> > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra
> > > > > > wrote:
> > > > > >>
> > > > > >> This series adds few DT related fixes required for Linux EFI stub
> > > > > >> to work
> > > > > >> on RISC-V.
> > > > > >>
> > > > > >
> > > > > > I'm not sure how this is supposed to work, since DT reserved memory
> > > > > > regions are not used by EFI. If you want to reserve memory on a UEFI
> > > > > > system, you have to reserve it in the UEFI memory map from firmware.
> > > > > > The DT reserved-memory node is taken into account too late, the
> > > > > > /memreserve/ entries are ignored entirely.
> > > > >
> > > > > Hello Ard,
> > > > >
> > > > > thanks for reviewing.
> > > > >
> > > > > What do you mean by "The DT reserved-memory node is taken into account
> > > > > too late"?
> > > > >
> > > > > Cf. commit 7be64b885a36 ("cmd: bootefi: Parse reserved-memory node
> > > > > from DT")
> > > > >
> > > >
> > > > What I mean is that the EFI stub in Linux uses memory allocation
> > > > functions, expecting the firmware to ensure that those allocations do
> > > > not conflict with memory descriptions and reservations in DT. So if
> > > > the firmware wants to express this redundantly, by passing
> > > > reservations in both reserved-memory and in the EFI memory map, that
> > > > is probably fine.
> > > >
> > > > Also, I must sheepishly admit that I only realize now that this patch
> > > > set is against u-boot not Linux :-)
> > > >
> > > :)
> > >
> > > > So if fixed reserved-memory regions are only being used to seed the
> > > > reserved regions in the EFI memory map, you can safely ignore me.
> > >
> > > Yeah. That's the purpose. Having reserved memory nodes in the final DT
> > > used by linux
> > > also ensures that proper Linux adds a reserved memory block or removes
> > > it from memblock
> > > entries depending on "no-map" property.
> > >
> > > > Apologies for the noise.
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
> >
> > Any other comments on the series ? It would be great if this series
> > could be merged before
> > v2020.07 release.
>
> I hope so if no one objects the proposed solution here in U-Boot vs.
> the PMP SBI extension. I need have another look at the latest version
> of patches though.
>
Thanks. As far as I know, there is no opposition to the current
approach adopted in U-Boot.
I am hoping EFI stub series can be merged before 5.8. If this series
can go in v2020.07,
RISC-V will have all required support to boot via EFI from Linux
kernel v5.8 and U-Boot v2020.07.
> Regards,
> Bin
--
Regards,
Atish
[RESEND PATCH v5 2/6] fdtdec: Fix boundary check
In U-Boot, the reserved memory end address is considered as a inclusive
address. This notion is followed while adding a reserved memory node to
the DT.
For example:
end_address = start_address + size - 1
Follow the same notion and fix the end address computation while checking
for existing nodes.
Signed-off-by: Atish Patra
---
lib/fdtdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index eb11fc898e30..07ba9f5c97e9 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1311,7 +1311,8 @@ int fdtdec_add_reserved_memory(void *blob, const char
*basename,
continue;
}
- if (addr == carveout->start && (addr + size) == carveout->end) {
+ if (addr == carveout->start && (addr + size - 1) ==
+ carveout->end) {
if (phandlep)
*phandlep = fdt_get_phandle(blob, node);
return 0;
--
2.25.1
[RESEND PATCH v5 1/6] riscv: Add boot hartid to Device tree
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-boot can not pass the hartid via a0 during via standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
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
Reviewed-by: Rick Chen
Tested-by: Heinrich Schuchardt
---
arch/riscv/lib/bootm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index fad16901c5f2..87cadad5016d 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,6 +28,28 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
+#ifdef CONFIG_EFI_LOADER
+ int err;
+ u32 size;
+ int chosen_offset;
+
+ size = fdt_totalsize(blob);
+ err = fdt_open_into(blob, blob, size + 32);
+ if (err < 0) {
+ printf("Device Tree can't be expanded to accommodate new node");
+ return err;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return err;
+ }
+ }
+ /* Overwrite the boot-hartid as U-Boot is the last stage BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
+#endif
return 0;
}
--
2.25.1
[RESEND PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI
This series adds few DT related fixes required for Linux EFI stub to work on RISC-V. Patch 1 adds the boot hartid property under /chosen node. The related discussion can be found here. https://patchwork.ozlabs.org/patch/1233664/ https://lists.denx.de/pipermail/u-boot/2020-March/402085.html Patch 2 fixes a generic issue in fdtdec related to reserved memory node. Patch 3,4,5 provide one of the option to update reserved-memory node for next stage. It depends on master OpenSBI branch. The other options are SBI extension and trap/emulate on PMP csr access. The detaild discussion can be found here. https://github.com/riscv/riscv-sbi-doc/pull/37 Patch 1 & 2 can be applied independently from 3 and 4. I want to keep all the patches together to provide a holistic view of changes required for RISC-V UEFI. Changes v4->v5: 1. Added comments for new functions. Changes v3->v4: 1. Dropped generic efi fix patch as it is already merged. 2. Moved all the fdt fixups to a common file. 3. Addressed few nit comments. Changes from v2->v3: 1. Update the DT meant for OS if it is different from the one used by U-Boot 2. Use different FDT api to obtain "reg" address & size to honor the cell count. Changes from v1->v2: 1. Fix the issue if chosen node is not present. Changes from previous version: 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". 2. Changed the property type to u32 instead of u64 for RV32 compatibility. Atish Patra (6): riscv: Add boot hartid to Device tree fdtdec: Fix boundary check riscv: Provide a mechanism to fix DT for reserved memory riscv: Setup reserved-memory node for FU540 riscv: Copy the reserved-memory nodes to final DT riscv: Move all fdt fixups together arch/riscv/cpu/start.S| 1 + arch/riscv/include/asm/global_data.h | 1 + arch/riscv/include/asm/u-boot-riscv.h | 2 + arch/riscv/lib/Makefile | 1 + arch/riscv/lib/asm-offsets.c | 1 + arch/riscv/lib/bootm.c| 5 - arch/riscv/lib/fdt_fixup.c| 150 ++ configs/sifive_fu540_defconfig| 1 + lib/fdtdec.c | 3 +- 9 files changed, 159 insertions(+), 6 deletions(-) create mode 100644 arch/riscv/lib/fdt_fixup.c -- 2.25.1
[RESEND PATCH v5 4/6] riscv: Setup reserved-memory node for FU540
FU540 uses OF_SEPARATE instead of OF_PRIOR.
Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
Signed-off-by: Atish Patra
---
arch/riscv/lib/fdt_fixup.c | 15 +++
configs/sifive_fu540_defconfig | 1 +
2 files changed, 16 insertions(+)
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
index 1fce41490973..af12e484db9b 100644
--- a/arch/riscv/lib/fdt_fixup.c
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -100,3 +100,18 @@ int riscv_board_reserved_mem_fixup(void *fdt)
return 0;
}
+
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *fdt)
+{
+ int err;
+
+ err = riscv_board_reserved_mem_fixup(fdt);
+ if (err < 0) {
+ printf("failed to fixup DT for reserved memory: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+#endif
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 6d61e6c960ee..8fb3794cd578 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -12,3 +12,4 @@ CONFIG_DISPLAY_BOARDINFO=y
CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
+CONFIG_OF_BOARD_FIXUP=y
--
2.25.1
[RESEND PATCH v5 5/6] riscv: Copy the reserved-memory nodes to final DT
The DT used by U-Boot may be different from the DT being passed to
the OS if the DT is loaded from external media such as network or
mmc. In that case, the reserved-memory node needs to be copied to
the DT passed to the OS.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/bootm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 87cadad5016d..8ff8db6bf533 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
-#ifdef CONFIG_EFI_LOADER
int err;
+#ifdef CONFIG_EFI_LOADER
u32 size;
int chosen_offset;
@@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
/* Overwrite the boot-hartid as U-Boot is the last stage BL */
fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
return 0;
}
--
2.25.1
[RESEND PATCH v5 3/6] riscv: Provide a mechanism to fix DT for reserved memory
In RISC-V, M-mode software can reserve physical memory regions
by setting appropriate physical memory protection (PMP) csr. As the
PMP csr are accessible only in M-mode, S-mode U-Boot can not read
this configuration directly. However, M-mode software can pass this
information via reserved-memory node in device tree so that S-mode
software can access this information.
This patch provides a framework to copy to the reserved-memory node
from one DT to another. This will be used to update the DT used by
U-Boot and the DT passed to the next stage OS.
Signed-off-by: Atish Patra
---
arch/riscv/cpu/start.S| 1 +
arch/riscv/include/asm/global_data.h | 1 +
arch/riscv/include/asm/u-boot-riscv.h | 2 +
arch/riscv/lib/Makefile | 1 +
arch/riscv/lib/asm-offsets.c | 1 +
arch/riscv/lib/fdt_fixup.c| 102 ++
6 files changed, 108 insertions(+)
create mode 100644 arch/riscv/lib/fdt_fixup.c
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 6b3ff99c3882..0282685c2906 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -121,6 +121,7 @@ call_board_init_f_0:
jal board_init_f_init_reserve
+ SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index b74bd7e738bb..51ac8d1c98e2 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -15,6 +15,7 @@
/* Architecture-specific global data */
struct arch_global_data {
long boot_hart; /* boot hart id */
+ phys_addr_t firmware_fdt_addr;
#ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
#endif
diff --git a/arch/riscv/include/asm/u-boot-riscv.h
b/arch/riscv/include/asm/u-boot-riscv.h
index 49febd588102..543a1688db8f 100644
--- a/arch/riscv/include/asm/u-boot-riscv.h
+++ b/arch/riscv/include/asm/u-boot-riscv.h
@@ -17,5 +17,7 @@ int cleanup_before_linux(void);
/* board/.../... */
int board_init(void);
void board_quiesce_devices(void);
+int riscv_board_reserved_mem_fixup(void *fdt);
+int riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
#endif /* _U_BOOT_RISCV_H_ */
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index adadbf4bcbef..d132b59ce32c 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -24,6 +24,7 @@ obj-y += reset.o
obj-y += setjmp.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SPL_BUILD)+= spl.o
+obj-y += fdt_fixup.o
# For building EFI apps
CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index 4fa4fd371473..7301c1b98e23 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,6 +14,7 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+ DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
#ifndef CONFIG_XIP
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
#endif
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
new file mode 100644
index ..1fce41490973
--- /dev/null
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates
+ *
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * riscv_fdt_copy_resv_mem_node() - Copy reserve memory node entry
+ * @src: Pointer to the source device tree from which reserved memory node
+ * needs to be copied.
+ * @dst: Pointer to the destination device tree to which reserved memory node
+ * needs to be copied.
+ *
+ * Return: 0 on success or if source doesn't have reserved memory node.
+ *Error if copy process failed.
+ */
+int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
+{
+ u32 phandle;
+ struct fdt_memory pmp_mem;
+ fdt_addr_t addr;
+ fdt_size_t size;
+ int offset, node, err, rmem_offset;
+ bool nomap = true;
+ char basename[32] = {0};
+ int bname_len;
+ int max_len = sizeof(basename);
+ const char *name;
+ char *temp;
+
+ offset = fdt_path_offset(src, "/reserved-memory");
+ if (offset < 0) {
+ printf("No reserved memory region found in source FDT\n");
+ return 0;
+ }
+
+ fdt_for_each_subnode(node, src, offset) {
+ name = fdt_get_name(src, node, NULL);
+
+ addr = fdtdec_get_addr_size_auto_noparent(src, node,
+ "reg", 0, &size,
+ false);
+ if (addr == FDT_ADDR_T_NONE) {
+ debug(&q
[RESEND PATCH v5 6/6] riscv: Move all fdt fixups together
Keep all the fdt fixups together for better code management.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/bootm.c | 33 -
arch/riscv/lib/fdt_fixup.c | 33 +
2 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 8ff8db6bf533..0d06095da11a 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -26,39 +26,6 @@ __weak void board_quiesce_devices(void)
{
}
-int arch_fixup_fdt(void *blob)
-{
- int err;
-#ifdef CONFIG_EFI_LOADER
- u32 size;
- int chosen_offset;
-
- size = fdt_totalsize(blob);
- err = fdt_open_into(blob, blob, size + 32);
- if (err < 0) {
- printf("Device Tree can't be expanded to accommodate new node");
- return err;
- }
- chosen_offset = fdt_path_offset(blob, "/chosen");
- if (chosen_offset < 0) {
- err = fdt_add_subnode(blob, 0, "chosen");
- if (err < 0) {
- printf("chosen node can not be added\n");
- return err;
- }
- }
- /* Overwrite the boot-hartid as U-Boot is the last stage BL */
- fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
-#endif
-
- /* Copy the reserved-memory node to the DT used by OS */
- err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
- if (err < 0)
- return err;
-
- return 0;
-}
-
/**
* announce_and_cleanup() - Print message and prepare for kernel boot
*
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
index af12e484db9b..20e0759f135b 100644
--- a/arch/riscv/lib/fdt_fixup.c
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -115,3 +115,36 @@ int board_fix_fdt(void *fdt)
return 0;
}
#endif
+
+int arch_fixup_fdt(void *blob)
+{
+ int err;
+#ifdef CONFIG_EFI_LOADER
+ u32 size;
+ int chosen_offset;
+
+ size = fdt_totalsize(blob);
+ err = fdt_open_into(blob, blob, size + 32);
+ if (err < 0) {
+ printf("Device Tree can't be expanded to accommodate new node");
+ return err;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return err;
+ }
+ }
+ /* Overwrite the boot-hartid as U-Boot is the last stage BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
+#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
--
2.25.1
Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI
On Thu, Apr 16, 2020 at 7:27 PM Bin Meng wrote: > > Hi Atish, > > On Fri, Apr 17, 2020 at 10:14 AM Bin Meng wrote: > > > > Correct Palmer's email address > > > > On Fri, Apr 17, 2020 at 10:12 AM Bin Meng wrote: > > > > > > Hi Rick, > > > > > > On Fri, Apr 17, 2020 at 9:12 AM Rick Chen wrote: > > > > > > > > Hi Bin > > > > > > > > > Hi Rick, > > > > > > > > > > On Fri, Apr 17, 2020 at 8:51 AM Rick Chen > > > > > wrote: > > > > > > > > > > > > 於 2020年4月17日 週五 上午8:39寫道： > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Atish Patra [mailto:ati...@atishpatra.org] > > > > > > > Sent: Wednesday, April 15, 2020 7:18 AM > > > > > > > To: Bin Meng > > > > > > > Cc: Ard Biesheuvel; Heinrich Schuchardt; U-Boot Mailing List; > > > > > > > Anup Patel; Lukas Auer; Alexander Graf; Rick Jian-Zhi Chen(陳建志); > > > > > > > Palmer Dabbelt > > > > > > > Subject: Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved > > > > > > > memory & UEFI > > > > > > > > > > > > > > On Mon, Apr 13, 2020 at 3:42 PM Bin Meng > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Atish, > > > > > > > > > > > > > > > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote: > > > > > > > > > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra > > > > > > > > > > > > > wrote: > > > > > > > > > > > > >> > > > > > > > > > > > > >> This series adds few DT related fixes required for > > > > > > > > > > > > >> Linux > > > > > > > > > > > > >> EFI stub to work on RISC-V. > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure how this is supposed to work, since DT > > > > > > > > > > > > > reserved > > > > > > > > > > > > > memory regions are not used by EFI. If you want to > > > > > > > > > > > > > reserve > > > > > > > > > > > > > memory on a UEFI system, you have to reserve it in > > > > > > > > > > > > > the UEFI memory map from firmware. > > > > > > > > > > > > > The DT reserved-memory node is taken into account too > > > > > > > > > > > > > late, > > > > > > > > > > > > > the /memreserve/ entries are ignored entirely. > > > > > > > > > > > > > > > > > > > > > > > > Hello Ard, > > > > > > > > > > > > > > > > > > > > > > > > thanks for reviewing. > > > > > > > > > > > > > > > > > > > > > > > > What do you mean by "The DT reserved-memory node is > > > > > > > > > > > > taken into > > > > > > > > > > > > account too late"? > > > > > > > > > > > > > > > > > > > > > > > > Cf. commit 7be64b8
[PATCH v6 4/6] riscv: Setup reserved-memory node for FU540
FU540 uses OF_SEPARATE instead of OF_PRIOR_STAGE.
Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/fdt_fixup.c | 15 +++
configs/sifive_fu540_defconfig | 1 +
2 files changed, 16 insertions(+)
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
index 1fce41490973..af12e484db9b 100644
--- a/arch/riscv/lib/fdt_fixup.c
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -100,3 +100,18 @@ int riscv_board_reserved_mem_fixup(void *fdt)
return 0;
}
+
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *fdt)
+{
+ int err;
+
+ err = riscv_board_reserved_mem_fixup(fdt);
+ if (err < 0) {
+ printf("failed to fixup DT for reserved memory: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+#endif
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 6d61e6c960ee..f805aacc7afd 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -9,6 +9,7 @@ CONFIG_FIT=y
CONFIG_MISC_INIT_R=y
CONFIG_DISPLAY_CPUINFO=y
CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_OF_BOARD_FIXUP=y
CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
--
2.25.1
[PATCH v6 1/6] riscv: Add boot hartid to device tree
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-Boot can not pass the hartid via a0 during via standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
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
Reviewed-by: Rick Chen
Reviewed-by: Bin Meng
Tested-by: Heinrich Schuchardt
---
arch/riscv/lib/bootm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index fad16901c5f2..87cadad5016d 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,6 +28,28 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
+#ifdef CONFIG_EFI_LOADER
+ int err;
+ u32 size;
+ int chosen_offset;
+
+ size = fdt_totalsize(blob);
+ err = fdt_open_into(blob, blob, size + 32);
+ if (err < 0) {
+ printf("Device Tree can't be expanded to accommodate new node");
+ return err;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return err;
+ }
+ }
+ /* Overwrite the boot-hartid as U-Boot is the last stage BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
+#endif
return 0;
}
--
2.25.1
[PATCH v6 0/6] RISC-V DT related fixes for reserved memory & UEFI
This series adds few DT related fixes required for Linux EFI stub to work on RISC-V. Patch 1 adds the boot hartid property under /chosen node. The related discussion can be found here. https://patchwork.ozlabs.org/patch/1233664/ https://lists.denx.de/pipermail/u-boot/2020-March/402085.html Patch 2 fixes a generic issue in fdtdec related to reserved memory node. Patch 3,4,5 provide one of the option to update reserved-memory node for next stage. It depends on master OpenSBI branch. The other options are SBI extension and trap/emulate on PMP csr access. The detaild discussion can be found here. https://github.com/riscv/riscv-sbi-doc/pull/37 Patch 1 & 2 can be applied independently from 3 and 4. I want to keep all the patches together to provide a holistic view of changes required for RISC-V UEFI. Changes from v5->v6: 1. Fixed typos in commit message and added reviewed-by tags. Changes from v4->v5: 1. Added comments for new functions. Changes from v3->v4: 1. Dropped generic efi fix patch as it is already merged. 2. Moved all the fdt fixups to a common file. 3. Addressed few nit comments. Changes from v2->v3: 1. Update the DT meant for OS if it is different from the one used by U-Boot 2. Use different FDT api to obtain "reg" address & size to honor the cell count. Changes from v1->v2: 1. Fix the issue if chosen node is not present. Changes from previous version: 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". 2. Changed the property type to u32 instead of u64 for RV32 compatibility. Atish Patra (6): riscv: Add boot hartid to device tree fdtdec: Fix boundary check riscv: Provide a mechanism to fix DT for reserved memory riscv: Setup reserved-memory node for FU540 riscv: Copy the reserved-memory nodes to final DT riscv: Move all fdt fixups together arch/riscv/cpu/start.S| 1 + arch/riscv/include/asm/global_data.h | 1 + arch/riscv/include/asm/u-boot-riscv.h | 2 + arch/riscv/lib/Makefile | 1 + arch/riscv/lib/asm-offsets.c | 1 + arch/riscv/lib/bootm.c| 5 - arch/riscv/lib/fdt_fixup.c| 150 ++ configs/sifive_fu540_defconfig| 1 + lib/fdtdec.c | 3 +- 9 files changed, 159 insertions(+), 6 deletions(-) create mode 100644 arch/riscv/lib/fdt_fixup.c -- 2.25.1
[PATCH v6 2/6] fdtdec: Fix boundary check
In U-Boot, the reserved memory end address is considered as a inclusive
address. This notion is followed while adding a reserved memory node to
the DT.
For example:
end_address = start_address + size - 1
Follow the same notion and fix the end address computation while checking
for existing nodes.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
lib/fdtdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index eb11fc898e30..07ba9f5c97e9 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1311,7 +1311,8 @@ int fdtdec_add_reserved_memory(void *blob, const char
*basename,
continue;
}
- if (addr == carveout->start && (addr + size) == carveout->end) {
+ if (addr == carveout->start && (addr + size - 1) ==
+ carveout->end) {
if (phandlep)
*phandlep = fdt_get_phandle(blob, node);
return 0;
--
2.25.1
[PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved memory
In RISC-V, M-mode software can reserve physical memory regions
by setting appropriate physical memory protection (PMP) csr. As the
PMP csr are accessible only in M-mode, S-mode U-Boot can not read
this configuration directly. However, M-mode software can pass this
information via reserved-memory node in device tree so that S-mode
software can access this information.
This patch provides a framework to copy to the reserved-memory node
from one DT to another. This will be used to update the DT used by
U-Boot and the DT passed to the next stage OS.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/cpu/start.S| 1 +
arch/riscv/include/asm/global_data.h | 1 +
arch/riscv/include/asm/u-boot-riscv.h | 2 +
arch/riscv/lib/Makefile | 1 +
arch/riscv/lib/asm-offsets.c | 1 +
arch/riscv/lib/fdt_fixup.c| 102 ++
6 files changed, 108 insertions(+)
create mode 100644 arch/riscv/lib/fdt_fixup.c
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 6b3ff99c3882..0282685c2906 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -121,6 +121,7 @@ call_board_init_f_0:
jal board_init_f_init_reserve
+ SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index b74bd7e738bb..51ac8d1c98e2 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -15,6 +15,7 @@
/* Architecture-specific global data */
struct arch_global_data {
long boot_hart; /* boot hart id */
+ phys_addr_t firmware_fdt_addr;
#ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
#endif
diff --git a/arch/riscv/include/asm/u-boot-riscv.h
b/arch/riscv/include/asm/u-boot-riscv.h
index 49febd588102..543a1688db8f 100644
--- a/arch/riscv/include/asm/u-boot-riscv.h
+++ b/arch/riscv/include/asm/u-boot-riscv.h
@@ -17,5 +17,7 @@ int cleanup_before_linux(void);
/* board/.../... */
int board_init(void);
void board_quiesce_devices(void);
+int riscv_board_reserved_mem_fixup(void *fdt);
+int riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
#endif /* _U_BOOT_RISCV_H_ */
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index adadbf4bcbef..d132b59ce32c 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -24,6 +24,7 @@ obj-y += reset.o
obj-y += setjmp.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SPL_BUILD)+= spl.o
+obj-y += fdt_fixup.o
# For building EFI apps
CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index 4fa4fd371473..7301c1b98e23 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,6 +14,7 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+ DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
#ifndef CONFIG_XIP
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
#endif
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
new file mode 100644
index ..1fce41490973
--- /dev/null
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates
+ *
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * riscv_fdt_copy_resv_mem_node() - Copy reserve memory node entry
+ * @src: Pointer to the source device tree from which reserved memory node
+ * needs to be copied.
+ * @dst: Pointer to the destination device tree to which reserved memory node
+ * needs to be copied.
+ *
+ * Return: 0 on success or if source doesn't have reserved memory node.
+ *Error if copy process failed.
+ */
+int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
+{
+ u32 phandle;
+ struct fdt_memory pmp_mem;
+ fdt_addr_t addr;
+ fdt_size_t size;
+ int offset, node, err, rmem_offset;
+ bool nomap = true;
+ char basename[32] = {0};
+ int bname_len;
+ int max_len = sizeof(basename);
+ const char *name;
+ char *temp;
+
+ offset = fdt_path_offset(src, "/reserved-memory");
+ if (offset < 0) {
+ printf("No reserved memory region found in source FDT\n");
+ return 0;
+ }
+
+ fdt_for_each_subnode(node, src, offset) {
+ name = fdt_get_name(src, node, NULL);
+
+ addr = fdtdec_get_addr_size_auto_noparent(src, node,
+ "reg", 0, &size,
+ false);
+ if (addr == FDT_ADDR_T_NONE) {
+
[PATCH v6 6/6] riscv: Move all fdt fixups together
Keep all the fdt fixups together for better code management.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/bootm.c | 33 -
arch/riscv/lib/fdt_fixup.c | 33 +
2 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 8ff8db6bf533..0d06095da11a 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -26,39 +26,6 @@ __weak void board_quiesce_devices(void)
{
}
-int arch_fixup_fdt(void *blob)
-{
- int err;
-#ifdef CONFIG_EFI_LOADER
- u32 size;
- int chosen_offset;
-
- size = fdt_totalsize(blob);
- err = fdt_open_into(blob, blob, size + 32);
- if (err < 0) {
- printf("Device Tree can't be expanded to accommodate new node");
- return err;
- }
- chosen_offset = fdt_path_offset(blob, "/chosen");
- if (chosen_offset < 0) {
- err = fdt_add_subnode(blob, 0, "chosen");
- if (err < 0) {
- printf("chosen node can not be added\n");
- return err;
- }
- }
- /* Overwrite the boot-hartid as U-Boot is the last stage BL */
- fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
-#endif
-
- /* Copy the reserved-memory node to the DT used by OS */
- err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
- if (err < 0)
- return err;
-
- return 0;
-}
-
/**
* announce_and_cleanup() - Print message and prepare for kernel boot
*
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
index af12e484db9b..20e0759f135b 100644
--- a/arch/riscv/lib/fdt_fixup.c
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -115,3 +115,36 @@ int board_fix_fdt(void *fdt)
return 0;
}
#endif
+
+int arch_fixup_fdt(void *blob)
+{
+ int err;
+#ifdef CONFIG_EFI_LOADER
+ u32 size;
+ int chosen_offset;
+
+ size = fdt_totalsize(blob);
+ err = fdt_open_into(blob, blob, size + 32);
+ if (err < 0) {
+ printf("Device Tree can't be expanded to accommodate new node");
+ return err;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return err;
+ }
+ }
+ /* Overwrite the boot-hartid as U-Boot is the last stage BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
+#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
--
2.25.1
[PATCH v6 5/6] riscv: Copy the reserved-memory nodes to final DT
The DT used by U-Boot may be different from the DT being passed to
the OS if the DT is loaded from external media such as network or
mmc. In that case, the reserved-memory node needs to be copied to
the DT passed to the OS.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/bootm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 87cadad5016d..8ff8db6bf533 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
-#ifdef CONFIG_EFI_LOADER
int err;
+#ifdef CONFIG_EFI_LOADER
u32 size;
int chosen_offset;
@@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
/* Overwrite the boot-hartid as U-Boot is the last stage BL */
fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
return 0;
}
--
2.25.1
Re: [PATCH v2 4/6] riscv: Add SMP Kconfig option dependency for U-Boot proper
On Thu, Apr 16, 2020 at 8:18 AM Bin Meng wrote: > > U-Boot proper running in S-mode only need SMP support when using > SBI v0.1. With SBI v0.2 HSM extension, it does not need implement > multicore boot in U-Boot proper. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - add "!RISCV_SMODE" to the dependency > > arch/riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 5ef6849..a252cdb 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -193,6 +193,7 @@ config SYS_MALLOC_F_LEN > > config SMP > bool "Symmetric Multi-Processing" > + depends on SBI_V01 || !RISCV_SMODE > help > This enables support for systems with more than one CPU. If > you say N here, U-Boot will run on single and multiprocessor > -- > 2.7.4 > Reviewed-by: Atish Patra -- Regards, Atish
Re: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved memory
On Mon, Apr 20, 2020 at 1:41 AM Rick Chen wrote:
>
> Hi Atish
>
> > From: Atish Patra [mailto:atish.pa...@wdc.com]
> > Sent: Sunday, April 19, 2020 3:32 AM
> > To: u-boot@lists.denx.de
> > Cc: Atish Patra; Bin Meng; Anup Patel; Lukas Auer; Heinrich Schuchardt;
> > ag...@csgraf.de; ard.biesheu...@linaro.org; Marcus Comstedt; Paul Walmsley;
> > Rick Jian-Zhi Chen(陳建志); pal...@dabbelt.com
> > Subject: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved
> > memory
> >
> > In RISC-V, M-mode software can reserve physical memory regions by setting
> > appropriate physical memory protection (PMP) csr. As the PMP csr are
> > accessible only in M-mode, S-mode U-Boot can not read this configuration
> > directly. However, M-mode software can pass this information via
> > reserved-memory node in device tree so that S-mode software can access this
> > information.
> >
> > This patch provides a framework to copy to the reserved-memory node from
> > one DT to another. This will be used to update the DT used by U-Boot and
> > the DT passed to the next stage OS.
> >
> > Signed-off-by: Atish Patra
> > Reviewed-by: Bin Meng
> > ---
> > arch/riscv/cpu/start.S| 1 +
> > arch/riscv/include/asm/global_data.h | 1 +
> > arch/riscv/include/asm/u-boot-riscv.h | 2 +
> > arch/riscv/lib/Makefile | 1 +
> > arch/riscv/lib/asm-offsets.c | 1 +
> > arch/riscv/lib/fdt_fixup.c| 102 ++
> > 6 files changed, 108 insertions(+)
> > create mode 100644 arch/riscv/lib/fdt_fixup.c
> >
>
> I am trying to applied Bin and your patch.
> The sequence of apply is according to submit date.
> This patch seem conflict with [PATCH v2 2/6] riscv: Merge unnecessary
> SMP ifdefs in start.S of Bin
> Can you rebase it and send again ?
>
Ok. I will rebase on top of Bin's series and resend.
> Thanks
> Rick
>
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > 6b3ff99c3882..0282685c2906 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -121,6 +121,7 @@ call_board_init_f_0:
> >
> > jal board_init_f_init_reserve
> >
> > + SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> > /* save the boot hart id to global_data */
> > SREGtp, GD_BOOT_HART(gp)
> >
> > diff --git a/arch/riscv/include/asm/global_data.h
> > b/arch/riscv/include/asm/global_data.h
> > index b74bd7e738bb..51ac8d1c98e2 100644
> > --- a/arch/riscv/include/asm/global_data.h
> > +++ b/arch/riscv/include/asm/global_data.h
> > @@ -15,6 +15,7 @@
> > /* Architecture-specific global data */ struct arch_global_data {
> > long boot_hart; /* boot hart id */
> > + phys_addr_t firmware_fdt_addr;
> > #ifdef CONFIG_SIFIVE_CLINT
> > void __iomem *clint;/* clint base address */
> > #endif
> > diff --git a/arch/riscv/include/asm/u-boot-riscv.h
> > b/arch/riscv/include/asm/u-boot-riscv.h
> > index 49febd588102..543a1688db8f 100644
> > --- a/arch/riscv/include/asm/u-boot-riscv.h
> > +++ b/arch/riscv/include/asm/u-boot-riscv.h
> > @@ -17,5 +17,7 @@ int cleanup_before_linux(void);
> > /* board/.../... */
> > int board_init(void);
> > void board_quiesce_devices(void);
> > +int riscv_board_reserved_mem_fixup(void *fdt); int
> > +riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
> >
> > #endif /* _U_BOOT_RISCV_H_ */
> > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index
> > adadbf4bcbef..d132b59ce32c 100644
> > --- a/arch/riscv/lib/Makefile
> > +++ b/arch/riscv/lib/Makefile
> > @@ -24,6 +24,7 @@ obj-y += reset.o
> > obj-y += setjmp.o
> > obj-$(CONFIG_SMP) += smp.o
> > obj-$(CONFIG_SPL_BUILD)+= spl.o
> > +obj-y += fdt_fixup.o
> >
> > # For building EFI apps
> > CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
> > diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
> > index 4fa4fd371473..7301c1b98e23 100644
> > --- a/arch/riscv/lib/asm-offsets.c
> > +++ b/arch/riscv/lib/asm-offsets.c
> > @@ -14,6 +14,7 @@
> > int main(void)
> > {
> > DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
> > + DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t,
> > arch.firmware_fdt_addr));
> > #ifndef CONFIG_XIP
> > DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
> > #endif diff --git a/arch/riscv/lib/fdt_fixu
[PATCH v7 0/6] RISC-V DT related fixes for reserved memory & UEFI
This series adds few DT related fixes required for Linux EFI stub to work on RISC-V. Patch 1 adds the boot hartid property under /chosen node. The related discussion can be found here. https://patchwork.ozlabs.org/patch/1233664/ https://lists.denx.de/pipermail/u-boot/2020-March/402085.html Patch 2 fixes a generic issue in fdtdec related to reserved memory node. Patch 3,4,5 provide one of the option to update reserved-memory node for next stage. It depends on master OpenSBI branch. The other options are SBI extension and trap/emulate on PMP csr access. The detaild discussion can be found here. https://github.com/riscv/riscv-sbi-doc/pull/37 Patch 1 & 2 can be applied independently from 3 and 4. I want to keep all the patches together to provide a holistic view of changes required for RISC-V UEFI. Changes from v6->v7: 1. Reabsed on top of u-boot-riscv and added Tested-by tags. Changes from v5->v6: 1. Fixed typos in commit message and added reviewed-by tags. Changes from v4->v5: 1. Added comments for new functions. Changes from v3->v4: 1. Dropped generic efi fix patch as it is already merged. 2. Moved all the fdt fixups to a common file. 3. Addressed few nit comments. Changes from v2->v3: 1. Update the DT meant for OS if it is different from the one used by U-Boot 2. Use different FDT api to obtain "reg" address & size to honor the cell count. Changes from v1->v2: 1. Fix the issue if chosen node is not present. Changes from previous version: 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". 2. Changed the property type to u32 instead of u64 for RV32 compatibility. Atish Patra (6): riscv: Add boot hartid to device tree fdtdec: Fix boundary check riscv: Provide a mechanism to fix DT for reserved memory riscv: Setup reserved-memory node for FU540 riscv: Copy the reserved-memory nodes to final DT riscv: Move all fdt fixups together arch/riscv/cpu/start.S| 1 + arch/riscv/include/asm/global_data.h | 1 + arch/riscv/include/asm/u-boot-riscv.h | 2 + arch/riscv/lib/Makefile | 1 + arch/riscv/lib/asm-offsets.c | 1 + arch/riscv/lib/bootm.c| 5 - arch/riscv/lib/fdt_fixup.c| 150 ++ configs/sifive_fu540_defconfig| 1 + lib/fdtdec.c | 3 +- 9 files changed, 159 insertions(+), 6 deletions(-) create mode 100644 arch/riscv/lib/fdt_fixup.c -- 2.25.1
[PATCH v7 5/6] riscv: Copy the reserved-memory nodes to final DT
The DT used by U-Boot may be different from the DT being passed to
the OS if the DT is loaded from external media such as network or
mmc. In that case, the reserved-memory node needs to be copied to
the DT passed to the OS.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
arch/riscv/lib/bootm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 87cadad5016d..8ff8db6bf533 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,8 +28,8 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
-#ifdef CONFIG_EFI_LOADER
int err;
+#ifdef CONFIG_EFI_LOADER
u32 size;
int chosen_offset;
@@ -50,6 +50,12 @@ int arch_fixup_fdt(void *blob)
/* Overwrite the boot-hartid as U-Boot is the last stage BL */
fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
return 0;
}
--
2.25.1
[PATCH v7 1/6] riscv: Add boot hartid to device tree
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-Boot can not pass the hartid via a0 during standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
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
Reviewed-by: Rick Chen
Reviewed-by: Bin Meng
Tested-by: Heinrich Schuchardt
Tested-by: Bin Meng
---
arch/riscv/lib/bootm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index fad16901c5f2..87cadad5016d 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,6 +28,28 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
+#ifdef CONFIG_EFI_LOADER
+ int err;
+ u32 size;
+ int chosen_offset;
+
+ size = fdt_totalsize(blob);
+ err = fdt_open_into(blob, blob, size + 32);
+ if (err < 0) {
+ printf("Device Tree can't be expanded to accommodate new node");
+ return err;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return err;
+ }
+ }
+ /* Overwrite the boot-hartid as U-Boot is the last stage BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
+#endif
return 0;
}
--
2.25.1
[PATCH v7 2/6] fdtdec: Fix boundary check
In U-Boot, the reserved memory end address is considered as a inclusive
address. This notion is followed while adding a reserved memory node to
the DT.
For example:
end_address = start_address + size - 1
Follow the same notion and fix the end address computation while checking
for existing nodes.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
lib/fdtdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 9ecfa2a2d743..460f0d250b4d 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1311,7 +1311,8 @@ int fdtdec_add_reserved_memory(void *blob, const char
*basename,
continue;
}
- if (addr == carveout->start && (addr + size) == carveout->end) {
+ if (addr == carveout->start && (addr + size - 1) ==
+ carveout->end) {
if (phandlep)
*phandlep = fdt_get_phandle(blob, node);
return 0;
--
2.25.1
[PATCH v7 3/6] riscv: Provide a mechanism to fix DT for reserved memory
In RISC-V, M-mode software can reserve physical memory regions
by setting appropriate physical memory protection (PMP) csr. As the
PMP csr are accessible only in M-mode, S-mode U-Boot can not read
this configuration directly. However, M-mode software can pass this
information via reserved-memory node in device tree so that S-mode
software can access this information.
This patch provides a framework to copy to the reserved-memory node
from one DT to another. This will be used to update the DT used by
U-Boot and the DT passed to the next stage OS.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/cpu/start.S| 1 +
arch/riscv/include/asm/global_data.h | 1 +
arch/riscv/include/asm/u-boot-riscv.h | 2 +
arch/riscv/lib/Makefile | 1 +
arch/riscv/lib/asm-offsets.c | 1 +
arch/riscv/lib/fdt_fixup.c| 102 ++
6 files changed, 108 insertions(+)
create mode 100644 arch/riscv/lib/fdt_fixup.c
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 1cedbef6cfaf..f408e41ab9dc 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -121,6 +121,7 @@ call_board_init_f_0:
jal board_init_f_init_reserve
+ SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index e0875ebf8f9d..2eb14815bcf0 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -17,6 +17,7 @@
/* Architecture-specific global data */
struct arch_global_data {
long boot_hart; /* boot hart id */
+ phys_addr_t firmware_fdt_addr;
#ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
#endif
diff --git a/arch/riscv/include/asm/u-boot-riscv.h
b/arch/riscv/include/asm/u-boot-riscv.h
index 49febd588102..543a1688db8f 100644
--- a/arch/riscv/include/asm/u-boot-riscv.h
+++ b/arch/riscv/include/asm/u-boot-riscv.h
@@ -17,5 +17,7 @@ int cleanup_before_linux(void);
/* board/.../... */
int board_init(void);
void board_quiesce_devices(void);
+int riscv_board_reserved_mem_fixup(void *fdt);
+int riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
#endif /* _U_BOOT_RISCV_H_ */
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index bd7b2c4d162b..b5e93244e0ec 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -24,6 +24,7 @@ obj-y += reset.o
obj-y += setjmp.o
obj-$(CONFIG_$(SPL_)SMP) += smp.o
obj-$(CONFIG_SPL_BUILD)+= spl.o
+obj-y += fdt_fixup.o
# For building EFI apps
CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index 4fa4fd371473..7301c1b98e23 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,6 +14,7 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+ DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
#ifndef CONFIG_XIP
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
#endif
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
new file mode 100644
index ..1fce41490973
--- /dev/null
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Western Digital Corporation or its affiliates
+ *
+ */
+
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * riscv_fdt_copy_resv_mem_node() - Copy reserve memory node entry
+ * @src: Pointer to the source device tree from which reserved memory node
+ * needs to be copied.
+ * @dst: Pointer to the destination device tree to which reserved memory node
+ * needs to be copied.
+ *
+ * Return: 0 on success or if source doesn't have reserved memory node.
+ *Error if copy process failed.
+ */
+int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
+{
+ u32 phandle;
+ struct fdt_memory pmp_mem;
+ fdt_addr_t addr;
+ fdt_size_t size;
+ int offset, node, err, rmem_offset;
+ bool nomap = true;
+ char basename[32] = {0};
+ int bname_len;
+ int max_len = sizeof(basename);
+ const char *name;
+ char *temp;
+
+ offset = fdt_path_offset(src, "/reserved-memory");
+ if (offset < 0) {
+ printf("No reserved memory region found in source FDT\n");
+ return 0;
+ }
+
+ fdt_for_each_subnode(node, src, offset) {
+ name = fdt_get_name(src, node, NULL);
+
+ addr = fdtdec_get_addr_size_auto_noparent(src, node,
+ "reg", 0, &size,
+ false);
+ if (addr == FDT_ADDR_T_NONE) {
+
[PATCH v7 4/6] riscv: Setup reserved-memory node for FU540
FU540 uses OF_SEPARATE instead of OF_PRIOR_STAGE.
Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
arch/riscv/lib/fdt_fixup.c | 15 +++
configs/sifive_fu540_defconfig | 1 +
2 files changed, 16 insertions(+)
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
index 1fce41490973..af12e484db9b 100644
--- a/arch/riscv/lib/fdt_fixup.c
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -100,3 +100,18 @@ int riscv_board_reserved_mem_fixup(void *fdt)
return 0;
}
+
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *fdt)
+{
+ int err;
+
+ err = riscv_board_reserved_mem_fixup(fdt);
+ if (err < 0) {
+ printf("failed to fixup DT for reserved memory: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+#endif
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 6d61e6c960ee..f805aacc7afd 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -9,6 +9,7 @@ CONFIG_FIT=y
CONFIG_MISC_INIT_R=y
CONFIG_DISPLAY_CPUINFO=y
CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_OF_BOARD_FIXUP=y
CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
--
2.25.1
[PATCH v7 6/6] riscv: Move all fdt fixups together
Keep all the fdt fixups together for better code management.
Signed-off-by: Atish Patra
Reviewed-by: Bin Meng
---
arch/riscv/lib/bootm.c | 33 -
arch/riscv/lib/fdt_fixup.c | 33 +
2 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index 8ff8db6bf533..0d06095da11a 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -26,39 +26,6 @@ __weak void board_quiesce_devices(void)
{
}
-int arch_fixup_fdt(void *blob)
-{
- int err;
-#ifdef CONFIG_EFI_LOADER
- u32 size;
- int chosen_offset;
-
- size = fdt_totalsize(blob);
- err = fdt_open_into(blob, blob, size + 32);
- if (err < 0) {
- printf("Device Tree can't be expanded to accommodate new node");
- return err;
- }
- chosen_offset = fdt_path_offset(blob, "/chosen");
- if (chosen_offset < 0) {
- err = fdt_add_subnode(blob, 0, "chosen");
- if (err < 0) {
- printf("chosen node can not be added\n");
- return err;
- }
- }
- /* Overwrite the boot-hartid as U-Boot is the last stage BL */
- fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
-#endif
-
- /* Copy the reserved-memory node to the DT used by OS */
- err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
- if (err < 0)
- return err;
-
- return 0;
-}
-
/**
* announce_and_cleanup() - Print message and prepare for kernel boot
*
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
index af12e484db9b..20e0759f135b 100644
--- a/arch/riscv/lib/fdt_fixup.c
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -115,3 +115,36 @@ int board_fix_fdt(void *fdt)
return 0;
}
#endif
+
+int arch_fixup_fdt(void *blob)
+{
+ int err;
+#ifdef CONFIG_EFI_LOADER
+ u32 size;
+ int chosen_offset;
+
+ size = fdt_totalsize(blob);
+ err = fdt_open_into(blob, blob, size + 32);
+ if (err < 0) {
+ printf("Device Tree can't be expanded to accommodate new node");
+ return err;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return err;
+ }
+ }
+ /* Overwrite the boot-hartid as U-Boot is the last stage BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
+#endif
+
+ /* Copy the reserved-memory node to the DT used by OS */
+ err = riscv_fdt_copy_resv_mem_node(gd->fdt_blob, blob);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
--
2.25.1
Re: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved memory
On Tue, Apr 21, 2020 at 1:25 AM Rick Chen wrote:
>
> Hi Atish
>
> > On Mon, Apr 20, 2020 at 1:41 AM Rick Chen wrote:
> > >
> > > Hi Atish
> > >
> > > > From: Atish Patra [mailto:atish.pa...@wdc.com]
> > > > Sent: Sunday, April 19, 2020 3:32 AM
> > > > To: u-boot@lists.denx.de
> > > > Cc: Atish Patra; Bin Meng; Anup Patel; Lukas Auer; Heinrich Schuchardt;
> > > > ag...@csgraf.de; ard.biesheu...@linaro.org; Marcus Comstedt; Paul
> > > > Walmsley; Rick Jian-Zhi Chen(陳建志); pal...@dabbelt.com
> > > > Subject: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for
> > > > reserved memory
> > > >
> > > > In RISC-V, M-mode software can reserve physical memory regions by
> > > > setting appropriate physical memory protection (PMP) csr. As the PMP
> > > > csr are accessible only in M-mode, S-mode U-Boot can not read this
> > > > configuration directly. However, M-mode software can pass this
> > > > information via reserved-memory node in device tree so that S-mode
> > > > software can access this information.
> > > >
> > > > This patch provides a framework to copy to the reserved-memory node
> > > > from one DT to another. This will be used to update the DT used by
> > > > U-Boot and the DT passed to the next stage OS.
> > > >
> > > > Signed-off-by: Atish Patra
> > > > Reviewed-by: Bin Meng
> > > > ---
> > > > arch/riscv/cpu/start.S| 1 +
> > > > arch/riscv/include/asm/global_data.h | 1 +
> > > > arch/riscv/include/asm/u-boot-riscv.h | 2 +
> > > > arch/riscv/lib/Makefile | 1 +
> > > > arch/riscv/lib/asm-offsets.c | 1 +
> > > > arch/riscv/lib/fdt_fixup.c| 102 ++
> > > > 6 files changed, 108 insertions(+)
> > > > create mode 100644 arch/riscv/lib/fdt_fixup.c
> > > >
> > >
> > > I am trying to applied Bin and your patch.
> > > The sequence of apply is according to submit date.
> > > This patch seem conflict with [PATCH v2 2/6] riscv: Merge unnecessary
> > > SMP ifdefs in start.S of Bin
> > > Can you rebase it and send again ?
> > >
> >
> > Ok. I will rebase on top of Bin's series and resend.
> >
>
> Please rebase on u-boot-riscv/master.
> I also applied Sean's patch today.
>
Done. Sent v7.
> Thanks,
> Rick
>
> > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> > > > 6b3ff99c3882..0282685c2906 100644
> > > > --- a/arch/riscv/cpu/start.S
> > > > +++ b/arch/riscv/cpu/start.S
> > > > @@ -121,6 +121,7 @@ call_board_init_f_0:
> > > >
> > > > jal board_init_f_init_reserve
> > > >
> > > > + SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> > > > /* save the boot hart id to global_data */
> > > > SREGtp, GD_BOOT_HART(gp)
> > > >
> > > > diff --git a/arch/riscv/include/asm/global_data.h
> > > > b/arch/riscv/include/asm/global_data.h
> > > > index b74bd7e738bb..51ac8d1c98e2 100644
> > > > --- a/arch/riscv/include/asm/global_data.h
> > > > +++ b/arch/riscv/include/asm/global_data.h
> > > > @@ -15,6 +15,7 @@
> > > > /* Architecture-specific global data */ struct arch_global_data {
> > > > long boot_hart; /* boot hart id */
> > > > + phys_addr_t firmware_fdt_addr;
> > > > #ifdef CONFIG_SIFIVE_CLINT
> > > > void __iomem *clint;/* clint base address */
> > > > #endif
> > > > diff --git a/arch/riscv/include/asm/u-boot-riscv.h
> > > > b/arch/riscv/include/asm/u-boot-riscv.h
> > > > index 49febd588102..543a1688db8f 100644
> > > > --- a/arch/riscv/include/asm/u-boot-riscv.h
> > > > +++ b/arch/riscv/include/asm/u-boot-riscv.h
> > > > @@ -17,5 +17,7 @@ int cleanup_before_linux(void);
> > > > /* board/.../... */
> > > > int board_init(void);
> > > > void board_quiesce_devices(void);
> > > > +int riscv_board_reserved_mem_fixup(void *fdt); int
> > > > +riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
> > > >
> > > > #endif /* _U_BOOT_RISCV_H_ */
> > > > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index
> > > > ada
[PATCH] riscv: Move all SMP related SBI calls to SBI_v01
SMP support for S-mode U-Boot is enabled only if SBI_V01 is enabled.
There is no point in supporting SMP related (IPI and fences) SBI calls
when SBI_V02 is enabled.
Modify all the SMP related SBI calls to be defined only for SBI_V01.
Signed-off-by: Atish Patra
---
arch/riscv/include/asm/sbi.h | 5 ++---
arch/riscv/lib/sbi.c | 37 ++--
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 3595ee8bf7ee..453cb5cec5eb 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -106,8 +106,6 @@ void sbi_console_putchar(int ch);
int sbi_console_getchar(void);
void sbi_clear_ipi(void);
void sbi_shutdown(void);
-#endif
-void sbi_set_timer(uint64_t stime_value);
void sbi_send_ipi(const unsigned long *hart_mask);
void sbi_remote_fence_i(const unsigned long *hart_mask);
void sbi_remote_sfence_vma(const unsigned long *hart_mask,
@@ -117,7 +115,8 @@ void sbi_remote_sfence_vma_asid(const unsigned long
*hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid);
-
+#endif
+void sbi_set_timer(uint64_t stime_value);
int sbi_probe_extension(int ext);
#endif
diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c
index 7bdf071dbbe5..993597e33db1 100644
--- a/arch/riscv/lib/sbi.c
+++ b/arch/riscv/lib/sbi.c
@@ -39,6 +39,23 @@ struct sbiret sbi_ecall(int ext, int fid, unsigned long arg0,
return ret;
}
+/**
+ * sbi_set_timer() - Program the timer for next timer event.
+ * @stime_value: The value after which next timer event should fire.
+ *
+ * Return: None
+ */
+void sbi_set_timer(uint64_t stime_value)
+{
+#if __riscv_xlen == 32
+ sbi_ecall(SBI_EXT_SET_TIMER, SBI_FID_SET_TIMER, stime_value,
+ stime_value >> 32, 0, 0, 0, 0);
+#else
+ sbi_ecall(SBI_EXT_SET_TIMER, SBI_FID_SET_TIMER, stime_value,
+ 0, 0, 0, 0, 0);
+#endif
+}
+
#ifdef CONFIG_SBI_V01
/**
@@ -86,25 +103,6 @@ void sbi_shutdown(void)
sbi_ecall(SBI_EXT_0_1_SHUTDOWN, 0, 0, 0, 0, 0, 0, 0);
}
-#endif /* CONFIG_SBI_V01 */
-
-/**
- * sbi_set_timer() - Program the timer for next timer event.
- * @stime_value: The value after which next timer event should fire.
- *
- * Return: None
- */
-void sbi_set_timer(uint64_t stime_value)
-{
-#if __riscv_xlen == 32
- sbi_ecall(SBI_EXT_SET_TIMER, SBI_FID_SET_TIMER, stime_value,
- stime_value >> 32, 0, 0, 0, 0);
-#else
- sbi_ecall(SBI_EXT_SET_TIMER, SBI_FID_SET_TIMER, stime_value,
- 0, 0, 0, 0, 0);
-#endif
-}
-
/**
* sbi_send_ipi() - Send an IPI to any hart.
* @hart_mask: A cpu mask containing all the target harts.
@@ -185,3 +183,4 @@ int sbi_probe_extension(int extid)
return -ENOTSUPP;
}
+#endif /* CONFIG_SBI_V01 */
--
2.25.1
Re: [U-Boot] [RFC/RFT U-Boot PATCH] image: Add Image.gz parsing support in booti.
On Fri, 2019-11-01 at 09:29 -0400, Tom Rini wrote: > On Thu, Oct 10, 2019 at 02:23:17PM -0700, Atish Patra wrote: > > > Add gz parsing logic so that booti can parse both Image > > and Image.gz to boot Linux. Currently, it is difficult to calculate > > a safe address for every board where the Image.gz can be > > decompressed. > > It is also not possible to figure out the size of the compressed > > file > > as well. Thus, user need to set two additional environment > > variables > > kernel_gz_addr_r and kernel_gz_size to make Image.gz work. > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > Signed-off-by: Atish Patra > > --- > > I could not test this patch on any ARM64 devices due to lack of > > access to any ARM64 board. If anybody can test it on ARM64, that > > would be great. > > Can we do the compression check more generally? I'd like to be able > to > see Image.xz/lz4/etc be able to be handled cleanly. This patch is intended only handle Image.gz which is a compressed version of kernel "Image" file. That's why relevant code is only added to booti command. > When you say the > compressed file, you do mean the Image.gz (for example) itself, > right? Yes. > I would suggest documenting using $filesize after loading the > compressed > image as that should always be set. Thanks! > ok. I will change the kernel_gz_size to filesize. -- Regards, Atish ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC/RFT U-Boot PATCH] image: Add Image.gz parsing support in booti.
On Mon, 2019-11-04 at 17:35 -0500, Tom Rini wrote: > On Mon, Nov 04, 2019 at 10:20:33PM +0000, Atish Patra wrote: > > On Fri, 2019-11-01 at 09:29 -0400, Tom Rini wrote: > > > On Thu, Oct 10, 2019 at 02:23:17PM -0700, Atish Patra wrote: > > > > > > > Add gz parsing logic so that booti can parse both Image > > > > and Image.gz to boot Linux. Currently, it is difficult to > > > > calculate > > > > a safe address for every board where the Image.gz can be > > > > decompressed. > > > > It is also not possible to figure out the size of the > > > > compressed > > > > file > > > > as well. Thus, user need to set two additional environment > > > > variables > > > > kernel_gz_addr_r and kernel_gz_size to make Image.gz work. > > > > > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > > > > > Signed-off-by: Atish Patra > > > > --- > > > > I could not test this patch on any ARM64 devices due to lack of > > > > access to any ARM64 board. If anybody can test it on ARM64, > > > > that > > > > would be great. > > Oh, I missed this part before. You should be able to get fairly far > with qemu :) > I did verify with qemu. I was requesting some tested-by on ARM64 hardware. Sorry for the confusion. I will update the commit text in next version. > > > Can we do the compression check more generally? I'd like to be > > > able > > > to > > > see Image.xz/lz4/etc be able to be handled cleanly. > > > > This patch is intended only handle Image.gz which is a compressed > > version of kernel "Image" file. That's why relevant code is only > > added > > to booti command. > > Right. But the linux kernel will happily spit out a handful of other > compressed Image files on arm64. I see riscv is only .gz today, but > I > want to be able to handle whatever the compression is, so long as we > have it available. > Ahh I misunderstood that part. I could not find any existing code to detect to different compression formats. If I have not missed anything, I can add that code in common/image.c and use that function in booti.c. -- Regards, Atish ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v3 0/3] Add compressed Image booting support
This patch series extends booti to support compressed images as well. Following compressed images are supported for now. lzma, lzo, bzip2, gz. Other compression methods can easily be supported if required. The above compression methods are the common ones that both Linux kernel (ARM64/RISC-V) and U-Boot supports. Atish Patra (3): lib: kconfig: Add option to set BZIP2 compression method image: Add a common compression type detection function. image: Add compressed Image parsing support in booti. cmd/booti.c| 39 ++- common/image.c | 23 doc/README.distro | 12 + doc/board/sifive/fu540.rst | 55 ++ include/image.h| 21 +++ lib/Kconfig| 5 6 files changed, 154 insertions(+), 1 deletion(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v3 2/3] image: Add a common compression type detection function.
Currently, there is no method that can detect compression types
given a file. This is very useful where a compressed kernel image
is loaded directly to the memory.
Inspect initial few bytes to figure out compression type of the
image. It will be used in booti method for now but can be reused
any other function in future as well.
Signed-off-by: Atish Patra
---
common/image.c | 23 +++
include/image.h | 21 +
2 files changed, 44 insertions(+)
diff --git a/common/image.c b/common/image.c
index 179eef0bd2dc..3043f0a1c2fc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -196,6 +196,14 @@ struct table_info {
const table_entry_t *table;
};
+static const struct comp_magic_map image_comp[] = {
+ { IH_COMP_BZIP2, "bzip2",{0x42, 0x5a},},
+ { IH_COMP_GZIP, "gzip", {0x1f, 0x8b},},
+ { IH_COMP_LZMA, "lzma", {0x5d, 0x00},},
+ { IH_COMP_LZO,"lzo", {0x89, 0x4c},},
+ { IH_COMP_NONE, "none", {}, },
+};
+
static const struct table_info table_info[IH_COUNT] = {
{ "architecture", IH_ARCH_COUNT, uimage_arch },
{ "compression", IH_COMP_COUNT, uimage_comp },
@@ -401,6 +409,21 @@ static void print_decomp_msg(int comp_type, int type, bool
is_xip)
printf(" Uncompressing %s\n", name);
}
+int image_decomp_type(const unsigned char *buf, ulong len)
+{
+ const struct comp_magic_map *cmagic = image_comp;
+
+ if (len < 2)
+ return -EINVAL;
+
+ for (; cmagic->comp_id > 0; cmagic++) {
+ if (!memcmp(buf, cmagic->magic, 2))
+ break;
+ }
+
+ return cmagic->comp_id;
+}
+
int image_decomp(int comp, ulong load, ulong image_start, int type,
void *load_buf, void *image_buf, ulong image_len,
uint unc_len, ulong *load_end)
diff --git a/include/image.h b/include/image.h
index c1065c06f9bd..733a6a107da8 100644
--- a/include/image.h
+++ b/include/image.h
@@ -447,6 +447,15 @@ typedef struct table_entry {
char*lname; /* long (output) name to print for messages */
} table_entry_t;
+/*
+ * Compression type and magic number mapping table.
+ */
+struct comp_magic_map {
+ int comp_id;
+ const char *name;
+ unsigned char magic[2];
+};
+
/*
* get_table_entry_id() scans the translation table trying to find an
* entry that matches the given short name. If a matching entry is
@@ -851,6 +860,18 @@ static inline int image_check_target_arch(const
image_header_t *hdr)
}
#endif /* USE_HOSTCC */
+/**
+ * image_decomp_type() - Find out compression type of an image
+ *
+ * @buf: Address in U-Boot memory where image is loaded.
+ * @len: Length of the compressed image.
+ * @return compression type or IH_COMP_NONE if not compressed.
+ *
+ * Note: Only following compression types are supported now.
+ * lzo, lzma, gzip, bzip2
+ */
+int image_decomp_type(const unsigned char *buf, ulong len);
+
/**
* image_decomp() - decompress an image
*
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v3 1/3] lib: kconfig: Add option to set BZIP2 compression method
There is no way to select BZIP2 compression method. Add it under library/compression config where all other compression related configs are present. Signed-off-by: Atish Patra --- lib/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index 3da45a5ec322..b5dcdba23014 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -385,6 +385,11 @@ config GZIP help This enables support for GZIP compression algorithm. +config BZIP2 + bool "Enable bzip2 decompression support" + help + This enables support for BZIP2 compression algorithm. + config ZLIB bool default y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v3 3/3] image: Add compressed Image parsing support in booti.
Add compressed Image parsing support so that booti can parse both
flat and compressed Image to boot Linux. Currently, it is difficult
to calculate a safe address for every board where the compressed
image can be decompressed. It is also not possible to figure out the
size of the compressed file as well. Thus, user need to set two
additional environment variables kernel_comp_addr_r and filesize to
make this work.
Following compression methods are supported for now.
lzma, lzo, bzip2, gzip.
lz4 support is not added as ARM64 kernel generates a lz4 compressed
image with legacy header which U-Boot doesn't know how to parse and
decompress.
Tested on HiFive Unleashed and Qemu for RISC-V.
Tested on Qemu for ARM64.
Signed-off-by: Atish Patra
---
I could not test this patch on any ARM64 boards due to lack of
access to any ARM64 board. If anybody can test it on ARM64, that
would be great.
---
cmd/booti.c| 39 ++-
doc/README.distro | 12 +
doc/board/sifive/fu540.rst | 55 ++
3 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/cmd/booti.c b/cmd/booti.c
index c36b0235df8c..531de507149c 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -13,6 +13,7 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
/*
* Image booting support
*/
@@ -23,6 +24,11 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
ulong ld;
ulong relocated_addr;
ulong image_size;
+ uint8_t *temp;
+ ulong dest;
+ ulong dest_end;
+ unsigned long comp_len;
+ int ctype;
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
@@ -37,6 +43,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
debug("* kernel: cmdline image address = 0x%08lx\n", ld);
}
+ temp = map_sysmem(ld, 0);
+ ctype = image_decomp_type(temp, 2);
+ if (ctype > 0) {
+ dest = env_get_ulong("kernel_comp_addr_r", 16, 0);
+ comp_len = env_get_ulong("filesize", 16, 0);
+ if (!dest || !comp_len) {
+ puts("kernel_comp_addr_r or filesize is not
provided!\n");
+ return -EINVAL;
+ }
+ if (dest < gd->ram_base || dest > gd->ram_top) {
+ puts("kernel_comp_addr_r is outside of DRAM range!\n");
+ return -EINVAL;
+ }
+
+ debug("kernel image compression type %d size = 0x%08lx address
= 0x%08lx\n",
+ ctype, comp_len, (ulong)dest);
+
+ ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
+(void *)dest, (void *)ld, comp_len,
+CONFIG_SYS_BOOTM_LEN, &dest_end);
+ if (ret)
+ return ret;
+ /* dest_end contains the uncompressed Image size */
+ memmove((void *) ld, (void *)dest, dest_end);
+ }
+ unmap_sysmem((void *)ld);
+
ret = booti_setup(ld, &relocated_addr, &image_size, false);
if (ret != 0)
return 1;
@@ -96,10 +129,14 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
#ifdef CONFIG_SYS_LONGHELP
static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
- "- boot Linux 'Image' stored at 'addr'\n"
+ "- boot Linux flat or compressed 'Image' stored at 'addr'\n"
"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
+ "\tCurrently only booting from gz, bz2, lzma and lz4 compression\n"
+ "\ttypes are supported. In order to boot from any of these compressed\n"
+ "\timages, user have to set kernel_comp_addr_r and filesize
enviornment\n"
+ "\tvariables beforehand.\n"
#if defined(CONFIG_OF_LIBFDT)
"\tSince booting a Linux kernel requires a flat device-tree, a\n"
"\tthird argument providing the address of the device-tree blob\n"
diff --git a/doc/README.distro b/doc/README.distro
index ab6e6f4e74be..67b49e1e4b6a 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -246,6 +246,18 @@ kernel_addr_r:
A size of 16MB for the kernel is likely adequate.
+kernel_comp_addr_r:
+ Optional. This is only required if user wants to boot Linux from a compressed
+ Image(.gz, .bz2, .lzma, .lzo) using booti command. It represents the location
+ in RAM where the compressed Image will be decompressed temporarily. Once the
+ decompression is co
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Thu, 2019-11-07 at 19:41 +0800, Rick Chen wrote: > Hi Anup & Lukas > > Anup Patel 於 2019年11月7日 週四 下午6:44寫道： > > On Thu, Nov 7, 2019 at 3:11 PM Auer, Lukas > > wrote: > > > On Thu, 2019-11-07 at 11:48 +0530, Anup Patel wrote: > > > > On Thu, Nov 7, 2019 at 11:40 AM Rick Chen > > > > wrote: > > > > > Hi Anup > > > > > > > > > > > On Thu, Nov 7, 2019 at 10:45 AM Anup Patel < > > > > > > a...@brainfault.org> wrote: > > > > > > > On Thu, Nov 7, 2019 at 7:04 AM Rick Chen < > > > > > > > rickche...@gmail.com> wrote: > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > On Wed, Nov 6, 2019 at 2:51 PM Rick Chen < > > > > > > > > > rickche...@gmail.com> wrote: > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > On Wed, Nov 6, 2019 at 2:18 PM Anup Patel < > > > > > > > > > > > a...@brainfault.org> wrote: > > > > > > > > > > > > On Wed, Nov 6, 2019 at 12:14 PM Rick Chen < > > > > > > > > > > > > rickche...@gmail.com> wrote: > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 7:19 AM Rick Chen < > > > > > > > > > > > > > > rickche...@gmail.com> wrote: > > > > > > > > > > > > > > > Hi Anup > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup > > > > > > > > > > > > > > > > > Patel wrote: > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM > > > > > > > > > > > > > > > > > > Alan Kao > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the critics. Comments > > > > > > > > > > > > > > > > > > > below. > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at > > > > > > > > > > > > > > > > > > > 06:38:00PM +0800, Bin Meng wrote: > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 > > > > > > > > > > > > > > > > > > > > AM Rick Chen < > > > > > > > > > > > > > > > > > > > > rickche...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at > > > > > > > > > > > > > > > > > > > > > > 2:18 PM Andes < > > > > > > > > > > > > > > > > > > > > > > ub...@andestech.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > From: Rick Chen < > > > > > > > > > > > > > > > > > > > > > > > r...@andestech.com> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It will work fine due to > > > > > > > > > > > > > > > > > > > > > > > hart 0 always will be > > > > > > > > > > > > > > > > > > > > > > > main > > > > > > > > > > > > > > > > > > > > > > > hart coincidentally. When > > > > > > > > > > > > > > > > > > > > > > > develop SPL flow, I try > > > > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > force other harts to be > > > > > > > > > > > > > > > > > > > > > > > main hart. And it will go > > > > > > > > > > > > > > > > > > > > > > > wrong in sending IPI > > > > > > > > > > > > > > > > > > > > > > > flow. So fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fix what? Does this commit > > > > > > > > > > > > > > > > > > > > > > contain 2 fixes, or just 1 > > > > > > > > > > > > > > > > > > > > > > fix? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, it include two fixs. But > > > > > > > > > > > > > > > > > > > > > they will cause one negative > > > > > > > > > > > > > > > > > > > > > result > > > > > > > > > > > > > > > > > > > > > that only hart 0 can send ipi > > > > > > > > > > > > > > > > > > > > > to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart > > > > > > > > > > > > > > > > > > > > > > > can be main hart in U- > > > > > > > > > > > > > > > > > > > > > > > Boot SPL > > > > > > > > > > > > > > > > > > > > > > > theoretically, but it > > > > > > > > > > > > > > > > > > > > > > > still fail somewhere. > > > > > > > > > > > > > > > > > > > > > > > After dig in > > > > > > > > > > > > > > > > > > > > > > > and found there is an > > > > > > > > > > > > > > > > > > > > > > > assumption that hart 0 > > > > > > > > > > > > > > > > > > > > > > > shall be > > > > > > > > > > > > > > > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So does this mean there is > > > > > > > > > > > > > > > > > > > > > > a bug in OpenSBI too? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a bug. > > > > > > > > > > > > > > > > > > > > > Maybe it is a compatible > > > >
Re: [U-Boot] [RFC/RFT PATCH v3 3/3] image: Add compressed Image parsing support in booti.
On Wed, 2019-11-06 at 14:15 -0800, Atish Patra wrote:
> Add compressed Image parsing support so that booti can parse both
> flat and compressed Image to boot Linux. Currently, it is difficult
> to calculate a safe address for every board where the compressed
> image can be decompressed. It is also not possible to figure out the
> size of the compressed file as well. Thus, user need to set two
> additional environment variables kernel_comp_addr_r and filesize to
> make this work.
>
> Following compression methods are supported for now.
> lzma, lzo, bzip2, gzip.
>
> lz4 support is not added as ARM64 kernel generates a lz4 compressed
> image with legacy header which U-Boot doesn't know how to parse and
> decompress.
>
> Tested on HiFive Unleashed and Qemu for RISC-V.
> Tested on Qemu for ARM64.
>
> Signed-off-by: Atish Patra
> ---
> I could not test this patch on any ARM64 boards due to lack of
> access to any ARM64 board. If anybody can test it on ARM64, that
> would be great.
> ---
> cmd/booti.c| 39 ++-
> doc/README.distro | 12 +
> doc/board/sifive/fu540.rst | 55
> ++
> 3 files changed, 105 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/booti.c b/cmd/booti.c
> index c36b0235df8c..531de507149c 100644
> --- a/cmd/booti.c
> +++ b/cmd/booti.c
> @@ -13,6 +13,7 @@
> #include
> #include
>
> +DECLARE_GLOBAL_DATA_PTR;
> /*
> * Image booting support
> */
> @@ -23,6 +24,11 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag,
> int argc,
> ulong ld;
> ulong relocated_addr;
> ulong image_size;
> + uint8_t *temp;
> + ulong dest;
> + ulong dest_end;
> + unsigned long comp_len;
> + int ctype;
>
> ret = do_bootm_states(cmdtp, flag, argc, argv,
> BOOTM_STATE_START,
> images, 1);
> @@ -37,6 +43,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag,
> int argc,
> debug("* kernel: cmdline image address = 0x%08lx\n",
> ld);
> }
>
> + temp = map_sysmem(ld, 0);
> + ctype = image_decomp_type(temp, 2);
> + if (ctype > 0) {
> + dest = env_get_ulong("kernel_comp_addr_r", 16, 0);
> + comp_len = env_get_ulong("filesize", 16, 0);
> + if (!dest || !comp_len) {
> + puts("kernel_comp_addr_r or filesize is not
> provided!\n");
> + return -EINVAL;
> + }
> + if (dest < gd->ram_base || dest > gd->ram_top) {
> + puts("kernel_comp_addr_r is outside of DRAM
> range!\n");
> + return -EINVAL;
> + }
> +
> + debug("kernel image compression type %d size = 0x%08lx
> address = 0x%08lx\n",
> + ctype, comp_len, (ulong)dest);
> +
> + ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
> + (void *)dest, (void *)ld, comp_len,
> + CONFIG_SYS_BOOTM_LEN, &dest_end);
There is a chance that CONFIG_SYS_BOOTM_LEN may not be defined or a
fixed size may not be sufficient. I have sent a v4 fixing this.
In stead of using a fixed expected uncompressed file size, we can
calculate uncompressed size as a factor of comp_len. As this is just a
maximum possible size, a higher value won't hurt.
I have modified the patch as below.
diff --git a/cmd/booti.c b/cmd/booti.c
index 531de507149c..cd8670a9a8db 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -28,6 +28,7 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag,
int argc,
ulong dest;
ulong dest_end;
unsigned long comp_len;
+ unsigned long decomp_len;
int ctype;
ret = do_bootm_states(cmdtp, flag, argc, argv,
BOOTM_STATE_START,
@@ -59,10 +60,10 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag,
int argc,
debug("kernel image compression type %d size = 0x%08lx
address = 0x%08lx\n",
ctype, comp_len, (ulong)dest);
-
+ decomp_len = comp_len * 10;
ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
(void *)dest, (void *)ld, comp_len,
-CONFIG_SYS_BOOTM_LEN, &dest_end);
+decomp_len, &dest_end);
> + if (ret)
> + return ret;
> + /* dest_end contains the uncompressed Image size */
> + memmove((void *) ld, (void *)dest, dest_end);
> + }
> + unmap_sysmem((void *)ld);
> +
> ret = booti_setup(ld, &rel
[U-Boot] [RFC/RFT PATCH v4 0/3] Add compressed Image booting support
This patch series extends booti to support compressed images as well. Following compressed images are supported for now. lzma, lzo, bzip2, gz. Other compression methods can easily be supported if required. The above compression methods are common ones that Linux kernel (ARM64/RISC-V) and U-Boot supports. Changes from v3->v4 1. Removed CONFIG_SYS_BOOTM_LEN usage. Atish Patra (3): lib: kconfig: Add option to set BZIP2 compression method image: Add a common compression type detection function. image: Add compressed Image parsing support in booti. cmd/booti.c| 40 ++- common/image.c | 23 doc/README.distro | 12 + doc/board/sifive/fu540.rst | 55 ++ include/image.h| 21 +++ lib/Kconfig| 5 6 files changed, 155 insertions(+), 1 deletion(-) -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
Add compressed Image parsing support so that booti can parse both
flat and compressed Image to boot Linux. Currently, it is difficult
to calculate a safe address for every board where the compressed
image can be decompressed. It is also not possible to figure out the
size of the compressed file as well. Thus, user need to set two
additional environment variables kernel_comp_addr_r and filesize to
make this work.
Following compression methods are supported for now.
lzma, lzo, bzip2, gzip.
lz4 support is not added as ARM64 kernel generates a lz4 compressed
image with legacy header which U-Boot doesn't know how to parse and
decompress.
Tested on HiFive Unleashed and Qemu for RISC-V.
Tested on Qemu for ARM64.
Signed-off-by: Atish Patra
---
I could not test this patch on any ARM64 boards due to lack of
access to any ARM64 board. If anybody can test it on ARM64, that
would be great.
---
cmd/booti.c| 40 ++-
doc/README.distro | 12 +
doc/board/sifive/fu540.rst | 55 ++
3 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/cmd/booti.c b/cmd/booti.c
index c36b0235df8c..cd8670a9a8db 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -13,6 +13,7 @@
#include
#include
+DECLARE_GLOBAL_DATA_PTR;
/*
* Image booting support
*/
@@ -23,6 +24,12 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
ulong ld;
ulong relocated_addr;
ulong image_size;
+ uint8_t *temp;
+ ulong dest;
+ ulong dest_end;
+ unsigned long comp_len;
+ unsigned long decomp_len;
+ int ctype;
ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
images, 1);
@@ -37,6 +44,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
debug("* kernel: cmdline image address = 0x%08lx\n", ld);
}
+ temp = map_sysmem(ld, 0);
+ ctype = image_decomp_type(temp, 2);
+ if (ctype > 0) {
+ dest = env_get_ulong("kernel_comp_addr_r", 16, 0);
+ comp_len = env_get_ulong("filesize", 16, 0);
+ if (!dest || !comp_len) {
+ puts("kernel_comp_addr_r or filesize is not
provided!\n");
+ return -EINVAL;
+ }
+ if (dest < gd->ram_base || dest > gd->ram_top) {
+ puts("kernel_comp_addr_r is outside of DRAM range!\n");
+ return -EINVAL;
+ }
+
+ debug("kernel image compression type %d size = 0x%08lx address
= 0x%08lx\n",
+ ctype, comp_len, (ulong)dest);
+ decomp_len = comp_len * 10;
+ ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
+(void *)dest, (void *)ld, comp_len,
+decomp_len, &dest_end);
+ if (ret)
+ return ret;
+ /* dest_end contains the uncompressed Image size */
+ memmove((void *) ld, (void *)dest, dest_end);
+ }
+ unmap_sysmem((void *)ld);
+
ret = booti_setup(ld, &relocated_addr, &image_size, false);
if (ret != 0)
return 1;
@@ -96,10 +130,14 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
#ifdef CONFIG_SYS_LONGHELP
static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
- "- boot Linux 'Image' stored at 'addr'\n"
+ "- boot Linux flat or compressed 'Image' stored at 'addr'\n"
"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
+ "\tCurrently only booting from gz, bz2, lzma and lz4 compression\n"
+ "\ttypes are supported. In order to boot from any of these compressed\n"
+ "\timages, user have to set kernel_comp_addr_r and filesize
enviornment\n"
+ "\tvariables beforehand.\n"
#if defined(CONFIG_OF_LIBFDT)
"\tSince booting a Linux kernel requires a flat device-tree, a\n"
"\tthird argument providing the address of the device-tree blob\n"
diff --git a/doc/README.distro b/doc/README.distro
index ab6e6f4e74be..67b49e1e4b6a 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -246,6 +246,18 @@ kernel_addr_r:
A size of 16MB for the kernel is likely adequate.
+kernel_comp_addr_r:
+ Optional. This is only required if user wants to boot Linux from a compressed
+ Image(.gz, .bz2, .lzma, .lzo) using booti command. It represents the location
+ in RAM where the compressed Image
[U-Boot] [RFC/RFT PATCH v4 2/3] image: Add a common compression type detection function.
Currently, there is no method that can detect compression types
given a file. This is very useful where a compressed kernel image
is loaded directly to the memory.
Inspect initial few bytes to figure out compression type of the
image. It will be used in booti method for now but can be reused
any other function in future as well.
Signed-off-by: Atish Patra
Reviewed-by: Tom Rini
---
common/image.c | 23 +++
include/image.h | 21 +
2 files changed, 44 insertions(+)
diff --git a/common/image.c b/common/image.c
index 179eef0bd2dc..3043f0a1c2fc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -196,6 +196,14 @@ struct table_info {
const table_entry_t *table;
};
+static const struct comp_magic_map image_comp[] = {
+ { IH_COMP_BZIP2, "bzip2",{0x42, 0x5a},},
+ { IH_COMP_GZIP, "gzip", {0x1f, 0x8b},},
+ { IH_COMP_LZMA, "lzma", {0x5d, 0x00},},
+ { IH_COMP_LZO,"lzo", {0x89, 0x4c},},
+ { IH_COMP_NONE, "none", {}, },
+};
+
static const struct table_info table_info[IH_COUNT] = {
{ "architecture", IH_ARCH_COUNT, uimage_arch },
{ "compression", IH_COMP_COUNT, uimage_comp },
@@ -401,6 +409,21 @@ static void print_decomp_msg(int comp_type, int type, bool
is_xip)
printf(" Uncompressing %s\n", name);
}
+int image_decomp_type(const unsigned char *buf, ulong len)
+{
+ const struct comp_magic_map *cmagic = image_comp;
+
+ if (len < 2)
+ return -EINVAL;
+
+ for (; cmagic->comp_id > 0; cmagic++) {
+ if (!memcmp(buf, cmagic->magic, 2))
+ break;
+ }
+
+ return cmagic->comp_id;
+}
+
int image_decomp(int comp, ulong load, ulong image_start, int type,
void *load_buf, void *image_buf, ulong image_len,
uint unc_len, ulong *load_end)
diff --git a/include/image.h b/include/image.h
index c1065c06f9bd..733a6a107da8 100644
--- a/include/image.h
+++ b/include/image.h
@@ -447,6 +447,15 @@ typedef struct table_entry {
char*lname; /* long (output) name to print for messages */
} table_entry_t;
+/*
+ * Compression type and magic number mapping table.
+ */
+struct comp_magic_map {
+ int comp_id;
+ const char *name;
+ unsigned char magic[2];
+};
+
/*
* get_table_entry_id() scans the translation table trying to find an
* entry that matches the given short name. If a matching entry is
@@ -851,6 +860,18 @@ static inline int image_check_target_arch(const
image_header_t *hdr)
}
#endif /* USE_HOSTCC */
+/**
+ * image_decomp_type() - Find out compression type of an image
+ *
+ * @buf: Address in U-Boot memory where image is loaded.
+ * @len: Length of the compressed image.
+ * @return compression type or IH_COMP_NONE if not compressed.
+ *
+ * Note: Only following compression types are supported now.
+ * lzo, lzma, gzip, bzip2
+ */
+int image_decomp_type(const unsigned char *buf, ulong len);
+
/**
* image_decomp() - decompress an image
*
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC/RFT PATCH v4 1/3] lib: kconfig: Add option to set BZIP2 compression method
There is no way to select BZIP2 compression method. Add it under library/compression config where all other compression related configs are present. Signed-off-by: Atish Patra Reviewed-by: Tom Rini --- lib/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index 3da45a5ec322..b5dcdba23014 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -385,6 +385,11 @@ config GZIP help This enables support for GZIP compression algorithm. +config BZIP2 + bool "Enable bzip2 decompression support" + help + This enables support for BZIP2 compression algorithm. + config ZLIB bool default y -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
On Wed, 2019-11-13 at 15:36 +0200, David Abdurachmanov wrote:
> On Sat, Nov 9, 2019 at 2:14 AM Atish Patra
> wrote:
> > Add compressed Image parsing support so that booti can parse both
> > flat and compressed Image to boot Linux. Currently, it is difficult
> > to calculate a safe address for every board where the compressed
> > image can be decompressed. It is also not possible to figure out
> > the
> > size of the compressed file as well. Thus, user need to set two
> > additional environment variables kernel_comp_addr_r and filesize to
> > make this work.
> >
> > Following compression methods are supported for now.
> > lzma, lzo, bzip2, gzip.
> >
> > lz4 support is not added as ARM64 kernel generates a lz4 compressed
> > image with legacy header which U-Boot doesn't know how to parse and
> > decompress.
> >
> > Tested on HiFive Unleashed and Qemu for RISC-V.
> > Tested on Qemu for ARM64.
> >
> > Signed-off-by: Atish Patra
> > ---
> > I could not test this patch on any ARM64 boards due to lack of
> > access to any ARM64 board. If anybody can test it on ARM64, that
> > would be great.
> > ---
> > cmd/booti.c| 40 ++-
> > doc/README.distro | 12 +
> > doc/board/sifive/fu540.rst | 55
> > ++
> > 3 files changed, 106 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/booti.c b/cmd/booti.c
> > index c36b0235df8c..cd8670a9a8db 100644
> > --- a/cmd/booti.c
> > +++ b/cmd/booti.c
> > @@ -13,6 +13,7 @@
> > #include
> > #include
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > /*
> > * Image booting support
> > */
> > @@ -23,6 +24,12 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > flag, int argc,
> > ulong ld;
> > ulong relocated_addr;
> > ulong image_size;
> > + uint8_t *temp;
> > + ulong dest;
> > + ulong dest_end;
> > + unsigned long comp_len;
> > + unsigned long decomp_len;
> > + int ctype;
> >
> > ret = do_bootm_states(cmdtp, flag, argc, argv,
> > BOOTM_STATE_START,
> > images, 1);
> > @@ -37,6 +44,33 @@ static int booti_start(cmd_tbl_t *cmdtp, int
> > flag, int argc,
> > debug("* kernel: cmdline image address =
> > 0x%08lx\n", ld);
> > }
> >
> > + temp = map_sysmem(ld, 0);
> > + ctype = image_decomp_type(temp, 2);
> > + if (ctype > 0) {
> > + dest = env_get_ulong("kernel_comp_addr_r", 16, 0);
> > + comp_len = env_get_ulong("filesize", 16, 0);
> > + if (!dest || !comp_len) {
> > + puts("kernel_comp_addr_r or filesize is not
> > provided!\n");
> > + return -EINVAL;
> > + }
> > + if (dest < gd->ram_base || dest > gd->ram_top) {
> > + puts("kernel_comp_addr_r is outside of DRAM
> > range!\n");
> > + return -EINVAL;
> > + }
> > +
> > + debug("kernel image compression type %d size =
> > 0x%08lx address = 0x%08lx\n",
> > + ctype, comp_len, (ulong)dest);
> > + decomp_len = comp_len * 10;
> > + ret = image_decomp(ctype, 0, ld, IH_TYPE_KERNEL,
> > +(void *)dest, (void *)ld,
> > comp_len,
> > +decomp_len, &dest_end);
> > + if (ret)
> > + return ret;
> > + /* dest_end contains the uncompressed Image size */
> > + memmove((void *) ld, (void *)dest, dest_end);
> > + }
> > + unmap_sysmem((void *)ld);
> > +
> > ret = booti_setup(ld, &relocated_addr, &image_size, false);
> > if (ret != 0)
> > return 1;
> > @@ -96,10 +130,14 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int
> > argc, char * const argv[])
> > #ifdef CONFIG_SYS_LONGHELP
> > static char booti_help_text[] =
> > "[addr [initrd[:size]] [fdt]]\n"
> > - "- boot Linux 'Image' stored at 'addr'\n"
> > + "- boot Linux flat or compressed 'Image' stored at
> > 'addr'\n"
> > "\tThe argu
Re: [PATCH v3 2/5] cmd: bootefi: Parse reserved-memory node from DT
On Tue, Mar 17, 2020 at 3:02 PM Heinrich Schuchardt wrote:
>
> On 3/17/20 10:19 PM, Atish Patra wrote:
> > Currently, bootefi only parses memory reservation block to setup
> > EFI reserved memory mappings. However, it doesn't parse the
> > reserved-memory[1] device tree node that also can contain the
> > reserved memory regions.
> >
> > Add capability to parse reserved-memory node and update the EFI memory
> > mappings accordingly.
> >
> > 1. > source>/doc/device-tree-bindings/reserved-memory/reserved-memory.txt]
> >
> > Signed-off-by: Atish Patra
> > ---
> > cmd/bootefi.c | 44 +++-
> > 1 file changed, 35 insertions(+), 9 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 24fc42ae898e..291cb2d69ff6 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -149,6 +149,20 @@ done:
> > return ret;
> > }
> >
> > +static void efi_reserve_memory(uint64_t addr, uint64_t size)
> > +{
> > + uint64_t pages;
> > +
> > + /* Convert from sandbox address space. */
> > + addr = (uintptr_t)map_sysmem(addr, 0);
> > + pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
> > + addr &= ~EFI_PAGE_MASK;
> > + if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
> > +false) != EFI_SUCCESS)
> > + printf("Reserved memory mapping failed addr %llx size %llx\n",
> > + (unsigned long long)addr, (unsigned long long)size);
> > +}
> > +
> > /**
> >* efi_carve_out_dt_rsv() - Carve out DT reserved memory ranges
> >*
> > @@ -161,7 +175,8 @@ done:
> > static void efi_carve_out_dt_rsv(void *fdt)
> > {
> > int nr_rsv, i;
> > - uint64_t addr, size, pages;
> > + uint64_t addr, size;
> > + int nodeoffset, subnode;
> >
> > nr_rsv = fdt_num_mem_rsv(fdt);
> >
> > @@ -169,15 +184,26 @@ static void efi_carve_out_dt_rsv(void *fdt)
> > for (i = 0; i < nr_rsv; i++) {
> > if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0)
> > continue;
> > + efi_reserve_memory(addr, size);
> > + }
> >
> > - /* Convert from sandbox address space. */
> > - addr = (uintptr_t)map_sysmem(addr, 0);
> > -
> > - pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
> > - addr &= ~EFI_PAGE_MASK;
> > - if (efi_add_memory_map(addr, pages, EFI_RESERVED_MEMORY_TYPE,
> > -false) != EFI_SUCCESS)
> > - printf("FDT memrsv map %d: Failed to add to map\n",
> > i);
> > + /* process reserved-memory */
> > + nodeoffset = fdt_subnode_offset(fdt, 0, "reserved-memory");
> > + if (nodeoffset < 0)
> > + return;
> > + subnode = fdt_first_subnode(fdt, nodeoffset);
> > + while (subnode >= 0) {
> > + /* check if this subnode has a reg property */
> > + addr = fdtdec_get_addr_size_auto_noparent(fdt, subnode,
> > + "reg", 0,
> > + (fdt_size_t *)&size,
> > + true);
> > + if (addr == FDT_ADDR_T_NONE) {
> > + debug("failed to read address/size\n");
> > + continue;
>
> As you do not update subnode you never leave the loop, cf.
> https://lists.denx.de/pipermail/u-boot/2020-March/402891.html
>
Thanks for the fix. I have verified your sandbox patches as well with
bootefi hello
and efidebug memmap as well.
> Best regards
>
> Heinrich
>
> > + }
> > + efi_reserve_memory(addr, size);
> > + subnode = fdt_next_subnode(fdt, subnode);
> > }
> > }
> >
> >
>
--
Regards,
Atish
Re: [PATCH 1/1] efi_loader: create reservations after ft_board_setup
On Sat, Mar 14, 2020 at 3:12 AM Heinrich Schuchardt wrote:
>
> Some memory reservations are made in ft_board_setup(). Ensure that we
> create reserved memory map entries after ft_board_setup().
>
> The downside of this patch is that if bootefi is called multiple times with
> an devicetree argument superfluous reservations for the old copies of the
> device tree will exist. But that is still better than missing a reservation.
>
> Deleting the superfluous reservations is not possible because reservations
> in the memory map are rounded to page size and may be coallesced.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/bootefi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 485f4b408a..9990959fe7 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -293,9 +293,6 @@ efi_status_t efi_install_fdt(void *fdt)
> return EFI_LOAD_ERROR;
> }
>
> - /* Create memory reservations as indicated by the device tree */
> - efi_carve_out_dt_rsv(fdt);
> -
> /* Prepare device tree for payload */
> ret = copy_fdt(&fdt);
> if (ret) {
> @@ -303,6 +300,9 @@ efi_status_t efi_install_fdt(void *fdt)
> return EFI_OUT_OF_RESOURCES;
> }
>
> + /* Create memory reservations as indicated by the device tree */
> + efi_carve_out_dt_rsv(fdt);
> +
> /* Install device tree as UEFI table */
> ret = efi_install_configuration_table(&efi_guid_fdt, fdt);
> if (ret != EFI_SUCCESS) {
> --
> 2.25.1
>
As per my understanding, copy_fdt tries allocate efi memory below dram
start + 127MB
for device tree. If efi_carve_out_dt_rsv is called after copy_fdt, it
may overwrite
a reserved-memory region. No ?
--
Regards,
Atish
Re: [PATCH v3 1/5] riscv: Add boot hartid to Device tree
On Wed, Mar 18, 2020 at 8:14 PM Bin Meng wrote:
>
> On Thu, Mar 19, 2020 at 11:10 AM Bin Meng wrote:
> >
> > On Wed, Mar 18, 2020 at 5:19 AM Atish Patra wrote:
> > >
> > > Linux booting protocol mandates that register "a0" contains the hartid.
> > > However, U-boot can not pass the hartid via a0 during via standard UEFI
> >
> > nits: U-Boot
> >
> > remove "during" ?
> >
> > > protocol. DT nodes are commonly used to pass such information to the OS.
> > >
> > > 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
> > > Reviewed-by: Rick Chen
> > > ---
> > > arch/riscv/lib/bootm.c | 22 ++
> > > 1 file changed, 22 insertions(+)
> > >
> > > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > > index fad16901c5f2..f927694ae32f 100644
> > > --- a/arch/riscv/lib/bootm.c
> > > +++ b/arch/riscv/lib/bootm.c
> > > @@ -28,6 +28,28 @@ __weak void board_quiesce_devices(void)
> > >
> > > int arch_fixup_fdt(void *blob)
> > > {
>
> One additional note, do have need to guard the "boot-hartid" fix-up with
>
> #ifdef CONFIG_EFI_LOADER
>
> #endif
>
Good point. Thanks I will add it.
> ?
>
> > > + 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 accommodate new
> > > node");
> > > + return -1;
> >
> > return err
> >
Sure.
> > > + }
> > > + chosen_offset = fdt_path_offset(blob, "/chosen");
> > > + if (chosen_offset < 0) {
> > > + err = fdt_add_subnode(blob, 0, "chosen");
> > > + if (err < 0) {
> > > + printf("chosen node can not be added\n");
> > > + return -1;
> >
> > return err
> >
Sure.
> > > + }
> > > + }
> > > +
> > > + /* Overwrite the boot-hartid as U-Boot is the last state BL */
> >
> > typo: stage
> >
> > > + fdt_setprop_u32(blob, chosen_offset, "boot-hartid",
> > > + gd->arch.boot_hart);
> > > +
> > > return 0;
> > > }
> > >
> > > --
>
> Regards,
> Bin
I will address all other typos as well.
--
Regards,
Atish
Re: [PATCH v3 3/5] riscv: Provide a mechanism to fix DT for reserved memory
On Thu, Mar 19, 2020 at 7:31 AM Bin Meng wrote:
>
> On Wed, Mar 18, 2020 at 5:19 AM Atish Patra wrote:
> >
> > In RISC-V, M-mode software can reserve physical memory regions
> > by setting appropriate physical memory protection (PMP) csr. As the
> > PMP csr are accessible only in M-mode, S-mode U-Boot can not read
> > this configuration directly. However, M-mode software can pass this
> > information via reserved-memory node in device tree so that S-mode
> > software can access this information.
> >
> > This patch provides a framework to copy to the reserved-memory node
> > from one DT to another. This will be used to update the DT used by
> > U-Boot and the DT passed to the next stage OS.
> >
> > Signed-off-by: Atish Patra
> > ---
> > arch/riscv/cpu/start.S| 1 +
> > arch/riscv/include/asm/global_data.h | 1 +
> > arch/riscv/include/asm/u-boot-riscv.h | 1 +
> > arch/riscv/lib/asm-offsets.c | 1 +
> > arch/riscv/lib/bootm.c| 68 +++
> > 5 files changed, 72 insertions(+)
> >
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index 6b3ff99c3882..0282685c2906 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -121,6 +121,7 @@ call_board_init_f_0:
> >
> > jal board_init_f_init_reserve
> >
> > + SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> > /* save the boot hart id to global_data */
> > SREGtp, GD_BOOT_HART(gp)
> >
> > diff --git a/arch/riscv/include/asm/global_data.h
> > b/arch/riscv/include/asm/global_data.h
> > index b74bd7e738bb..51ac8d1c98e2 100644
> > --- a/arch/riscv/include/asm/global_data.h
> > +++ b/arch/riscv/include/asm/global_data.h
> > @@ -15,6 +15,7 @@
> > /* Architecture-specific global data */
> > struct arch_global_data {
> > long boot_hart; /* boot hart id */
> > + phys_addr_t firmware_fdt_addr;
> > #ifdef CONFIG_SIFIVE_CLINT
> > void __iomem *clint;/* clint base address */
> > #endif
> > diff --git a/arch/riscv/include/asm/u-boot-riscv.h
> > b/arch/riscv/include/asm/u-boot-riscv.h
> > index 49febd588102..b7bea0ba184d 100644
> > --- a/arch/riscv/include/asm/u-boot-riscv.h
> > +++ b/arch/riscv/include/asm/u-boot-riscv.h
> > @@ -17,5 +17,6 @@ int cleanup_before_linux(void);
> > /* board/.../... */
> > int board_init(void);
> > void board_quiesce_devices(void);
> > +int riscv_board_reserved_mem_fixup(void *fdt);
> >
> > #endif /* _U_BOOT_RISCV_H_ */
> > diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
> > index 4fa4fd371473..7301c1b98e23 100644
> > --- a/arch/riscv/lib/asm-offsets.c
> > +++ b/arch/riscv/lib/asm-offsets.c
> > @@ -14,6 +14,7 @@
> > int main(void)
> > {
> > DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
> > + DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t,
> > arch.firmware_fdt_addr));
> > #ifndef CONFIG_XIP
> > DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
> > #endif
> > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
> > index f927694ae32f..5e907e96701c 100644
> > --- a/arch/riscv/lib/bootm.c
> > +++ b/arch/riscv/lib/bootm.c
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -26,6 +27,73 @@ __weak void board_quiesce_devices(void)
> > {
> > }
> >
> > +int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
>
> We probably need find a better place for this routine, see below
> comments for riscv_board_reserved_mem_fixup().
>
> We need make this routine public in u-boot-riscv.h as well.
>
> > +{
> > + uint32_t phandle;
> > + struct fdt_memory pmp_mem;
> > + fdt_addr_t addr;
> > + fdt_size_t size;
> > + int offset, node, err, rmem_offset;
> > + bool nomap = false;
> > + char basename[32] = {0};
> > + int bname_len;
> > + int max_len = sizeof(basename);
> > + const char *name;
> > + char *temp;
> > +
> > + offset = fdt_path_offset(src, "/reserved-memory");
> > + if (offset < 0) {
> > + printf("No reserved memory region found in source FDT\n");
> > + return 0;
> > + }
> > +
> > + fdt_for_each_subnode(node, src, offset) {
>
Re: [PATCH v3 4/5] riscv: Setup reserved-memory node for FU540
On Thu, Mar 19, 2020 at 7:32 AM Bin Meng wrote:
>
> On Wed, Mar 18, 2020 at 5:19 AM Atish Patra wrote:
> >
> > FU540 uses OF_SEPARATE instead of OF_PRIOR.
> >
> > Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
> >
> > Signed-off-by: Atish Patra
> > ---
> > board/sifive/fu540/fu540.c | 15 +++
> > configs/sifive_fu540_defconfig | 1 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> > index 47a20902517c..82b3a9c8e729 100644
> > --- a/board/sifive/fu540/fu540.c
> > +++ b/board/sifive/fu540/fu540.c
> > @@ -141,6 +141,21 @@ int misc_init_r(void)
> >
> > #endif
> >
> > +#ifdef CONFIG_OF_BOARD_FIXUP
> > +int board_fix_fdt(void *fdt)
>
> This routine should be put in a more generic file, as this could
> potentially apply to all RISC-V platforms that need OF_BOARD_FIXUP
> (e.g.: U-Boot itself is built with OF_SEPARATE).
>
> In case other platform wants to override this, we can define it as a __weak.
>
I am not opposed to that idea but board specific functions should be
defined in board specific file.
If we can violate that rule, I am okay with the proposal.
We can define a __weak board_fix_fdt in arch/riscv/lib/fdt_fixup.c and
guard it under CONFIG_OF_BOARD_FIXUP.
> > +{
> > + int err;
> > +
> > + err = riscv_board_reserved_mem_fixup(fdt);
> > + if (err < 0) {
> > + printf("failed to fixup DT for reserved memory: %d\n", err);
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +#endif
> > +
> > int board_init(void)
> > {
> > /* For now nothing to do here. */
> > diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
> > index 6d61e6c960ee..8fb3794cd578 100644
> > --- a/configs/sifive_fu540_defconfig
> > +++ b/configs/sifive_fu540_defconfig
> > @@ -12,3 +12,4 @@ CONFIG_DISPLAY_BOARDINFO=y
> > CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
> > CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > CONFIG_DM_MTD=y
> > +CONFIG_OF_BOARD_FIXUP=y
>
> This line should be inserted after CONFIG_DISPLAY_BOARDINFO=y
>
> Please ensure defconfig file is updated like this:
>
> $ make sifive_fu540_defconfig
> $ make savedefconfig
> $ cp defconfig configs/sifive_fu540_defconfig
>
Sure. Will do that.
> Regards,
> Bin
--
Regards,
Atish
[PATCH v4 4/6] riscv: Setup reserved-memory node for FU540
FU540 uses OF_SEPARATE instead of OF_PRIOR.
Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
Signed-off-by: Atish Patra
---
arch/riscv/lib/fdt_fixup.c | 15 +++
configs/sifive_fu540_defconfig | 1 +
2 files changed, 16 insertions(+)
diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
index f3d1ec5c5d02..e41f06f5b7f1 100644
--- a/arch/riscv/lib/fdt_fixup.c
+++ b/arch/riscv/lib/fdt_fixup.c
@@ -10,6 +10,21 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_OF_BOARD_FIXUP
+int board_fix_fdt(void *fdt)
+{
+ int err;
+
+ err = riscv_board_reserved_mem_fixup(fdt);
+ if (err < 0) {
+ printf("failed to fixup DT for reserved memory: %d\n", err);
+ return err;
+ }
+
+ return 0;
+}
+#endif
+
int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
{
u32 phandle;
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 6d61e6c960ee..8fb3794cd578 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -12,3 +12,4 @@ CONFIG_DISPLAY_BOARDINFO=y
CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM_MTD=y
+CONFIG_OF_BOARD_FIXUP=y
--
2.25.1
[PATCH v4 0/6] DT related fixes for RISC-V UEFI
This series adds few DT related fixes required for Linux EFI stub to work on RISC-V. Patch 1 adds the boot hartid property under /chosen node. The related discussion can be found here. https://patchwork.ozlabs.org/patch/1233664/ https://lists.denx.de/pipermail/u-boot/2020-March/402085.html Patch 2 fixes a generic issue in fdtdec related to reserved memory node. Patch 3,4,5 provide one of the option to update reserved-memory node for next stage. It depends on Bin's following series in OpenSBI http://lists.infradead.org/pipermail/opensbi/2020-March/001316.html The other options are SBI extension and trap/emulate on PMP csr access. The detaild discussion can be found here. https://github.com/riscv/riscv-sbi-doc/pull/37 Patch 1 & 2 can be applied independently from 3 and 4. I want to keep all the patches together to provide a holistic view of changes required for RISC-V UEFI. Changes v3->v4: 1. Dropped generic efi fix patch as it is already merged. 2. Moved all the fdt fixups to a common file. 3. Addressed few nit comments. Changes from v2->v3: 1. Update the DT meant for OS if it is different from the one used by U-Boot 2. Use different FDT api to obtain "reg" address & size to honor the cell count. Changes from v1->v2: 1. Fix the issue if chosen node is not present. Changes from previous version: 1. Renamed the DT node property to "boot-hartid" from "efi-boot-hartid". 2. Changed the property type to u32 instead of u64 for RV32 compatibility. Atish Patra (6): riscv: Add boot hartid to Device tree fdtdec: Fix boundary check riscv: Provide a mechanism to fix DT for reserved memory riscv: Setup reserved-memory node for FU540 riscv: Copy the reserved-memory nodes to final DT riscv: Move all fdt fixups together arch/riscv/cpu/start.S| 1 + arch/riscv/include/asm/global_data.h | 1 + arch/riscv/include/asm/u-boot-riscv.h | 2 + arch/riscv/lib/Makefile | 1 + arch/riscv/lib/asm-offsets.c | 1 + arch/riscv/lib/bootm.c| 5 - arch/riscv/lib/fdt_fixup.c| 128 ++ configs/sifive_fu540_defconfig| 1 + lib/fdtdec.c | 3 +- 9 files changed, 137 insertions(+), 6 deletions(-) create mode 100644 arch/riscv/lib/fdt_fixup.c -- 2.25.1
[PATCH v4 1/6] riscv: Add boot hartid to Device tree
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-boot can not pass the hartid via a0 during via standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
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
Reviewed-by: Rick Chen
---
arch/riscv/lib/bootm.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index fad16901c5f2..87cadad5016d 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -28,6 +28,28 @@ __weak void board_quiesce_devices(void)
int arch_fixup_fdt(void *blob)
{
+#ifdef CONFIG_EFI_LOADER
+ int err;
+ u32 size;
+ int chosen_offset;
+
+ size = fdt_totalsize(blob);
+ err = fdt_open_into(blob, blob, size + 32);
+ if (err < 0) {
+ printf("Device Tree can't be expanded to accommodate new node");
+ return err;
+ }
+ chosen_offset = fdt_path_offset(blob, "/chosen");
+ if (chosen_offset < 0) {
+ err = fdt_add_subnode(blob, 0, "chosen");
+ if (err < 0) {
+ printf("chosen node can not be added\n");
+ return err;
+ }
+ }
+ /* Overwrite the boot-hartid as U-Boot is the last stage BL */
+ fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart);
+#endif
return 0;
}
--
2.25.1
[PATCH v4 2/6] fdtdec: Fix boundary check
In U-Boot, the reserved memory end address is considered as a inclusive
address. This notion is followed while adding a reserved memory node to
the DT.
For example:
end_address = start_address + size - 1
Follow the same notion and fix the end address computation while checking
for existing nodes.
Signed-off-by: Atish Patra
---
lib/fdtdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index eb11fc898e30..07ba9f5c97e9 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1311,7 +1311,8 @@ int fdtdec_add_reserved_memory(void *blob, const char
*basename,
continue;
}
- if (addr == carveout->start && (addr + size) == carveout->end) {
+ if (addr == carveout->start && (addr + size - 1) ==
+ carveout->end) {
if (phandlep)
*phandlep = fdt_get_phandle(blob, node);
return 0;
--
2.25.1
