Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32
On Mon, Jan 3, 2022 at 1:13 PM Leo Liang wrote: > > On Thu, Dec 30, 2021 at 01:55:15AM +0800, Xiang W wrote: > > 在 2021-12-29星期三的 17:23 +0800，Leo Liang写道： > > > Hi Xiang, > > > On Wed, Dec 22, 2021 at 07:32:53AM +0800, Xiang W wrote: > > > > Various specifications of riscv allow the number of hart to be > > > > greater than 32. The limit of 32 is determined by > > > > gd->arch.available_harts. We can eliminate this limitation through > > > > bitmaps. Currently, the number of hart is limited to 4095, and 4095 > > > > is the limit of the RISC-V Advanced Core Local Interruptor > > > > Specification. > > > > > > > > Test on sifive unmatched. > > > > > > > > Signed-off-by: Xiang W > > > > --- > > > > Changes since v1: > > > > > > > > * When NR_CPUS is very large, the value of GD_AVAILABLE_HARTS will > > > > overflow the immediate range of ld/lw. This patch fixes this > > > > problem > > > > > > > > arch/riscv/Kconfig | 4 ++-- > > > > arch/riscv/cpu/start.S | 21 - > > > > arch/riscv/include/asm/global_data.h | 4 +++- > > > > arch/riscv/lib/smp.c | 2 +- > > > > 4 files changed, 22 insertions(+), 9 deletions(-) > > > > > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > > > > index 76850ec9be..92f3b78f29 100644 > > > > --- a/arch/riscv/cpu/start.S > > > > +++ b/arch/riscv/cpu/start.S > > > > @@ -166,11 +166,22 @@ wait_for_gd_init: > > > > mv gp, s0 > > > > > > > > /* register available harts in the available_harts mask */ > > > > - li t1, 1 > > > > - sll t1, t1, tp > > > > - LREGt2, GD_AVAILABLE_HARTS(gp) > > > > - or t2, t2, t1 > > > > - SREGt2, GD_AVAILABLE_HARTS(gp) > > > > + li t1, GD_AVAILABLE_HARTS > > > > + add t1, t1, gp > > > > + LREGt1, 0(t1) > > > > +#if defined(CONFIG_ARCH_RV64I) > > > > + srlit2, tp, 6 > > > > + sllit2, t2, 3 > > > > +#elif defined(CONFIG_ARCH_RV32I) > > > > + srlit2, tp, 5 > > > > + sllit2, t2, 2 > > > > +#endif > > > > + add t1, t1, t2 > > > > + LREGt2, 0(t1) > > > > + li t3, 1 > > > > + sll t3, t3, tp > > > This seems incorrect. > > > Shouldn't we have "$tp % sizeof(ulong)" instead of "$tp / > > > sizeof(ulong)" ? > > > > Do you meening: "$tp % sizeof(ulong)" instead of "$tp" ? > > > > There is such a description in the riscv specification： > > > > SLL, SRL, and SRA perform logical left, logical right, and arithmetic > > right shifts on the value in register rs1 by the shift amount held in > > the lower 5 bits of register rs2. > > > > SLL, SRL, and SRA perform logical left, logical right, and arithmetic > > right shifts on the value in register rs1 by the shift amount held in > > register rs2. In RV64I, only the low 6 bits of rs2 are considered for > > the shift amount. > > > > So we don’t need to perform the remainder operation. > > Got it! Thanks for the explanation. > > LGTM, > Reviewed-by: Leo Yu-Chi Liang I noticed that this has never landed in U-Boot. Was this forgotten or dropped for some reason (couldn't find anything)? The current limit on the Linux kernel side is 512. The default on 64-bit (riscv64) is 64. david > > Best regards, > Leo > > > > regards， > > Xiang W > > > > + or t2, t2, t3 > > > > + SREGt2, 0(t1) > > > > > > > > amoswap.w.rl zero, zero, 0(t0) > > > Best regards, > > > Leo > > > >
Re: [PATCH v2 14/17] riscv: dts: jh7110: Add initial StarFive JH7110 device tree
On Wed, Jan 18, 2023 at 10:19 AM Yanhong Wang
wrote:
>
> Add initial device tree for the JH7110 RISC-V SoC.
>
> Signed-off-by: Yanhong Wang
> ---
> arch/riscv/dts/jh7110.dtsi | 497 +
> 1 file changed, 497 insertions(+)
> create mode 100644 arch/riscv/dts/jh7110.dtsi
>
> diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
> new file mode 100644
> index 00..49d34b85af
> --- /dev/null
> +++ b/arch/riscv/dts/jh7110.dtsi
> @@ -0,0 +1,497 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright (C) 2022 StarFive Technology Co., Ltd.
> + * Copyright (C) 2022 Emil Renner Berthing
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "starfive,jh7110";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + S76_0: cpu@0 {
> + compatible = "sifive,u74-mc", "riscv";
> + reg = <0>;
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <8192>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <40>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <16384>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <40>;
> + mmu-type = "riscv,sv39";
> + next-level-cache = <>;
> + riscv,isa = "rv64imacu";
> + tlb-split;
> + status = "disabled";
> +
> + cpu0_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> + };
> +
> + U74_1: cpu@1 {
> + compatible = "sifive,u74-mc", "riscv";
> + reg = <1>;
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <40>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <40>;
> + mmu-type = "riscv,sv39";
> + next-level-cache = <>;
> + riscv,isa = "rv64imafdcbsu";
> + tlb-split;
> +
> + cpu1_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> + };
> +
> + U74_2: cpu@2 {
> + compatible = "sifive,u74-mc", "riscv";
> + reg = <2>;
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <40>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <40>;
> + mmu-type = "riscv,sv39";
> + next-level-cache = <>;
> + riscv,isa = "rv64imafdcbsu";
> + tlb-split;
> +
> + cpu2_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> + };
> +
> + U74_3: cpu@3 {
> + compatible = "sifive,u74-mc", "riscv";
> + reg = <3>;
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <32768>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <40>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <32768>;
> +
Re: [PATCH v2 1/2] riscv: Support booting SiFive Unmatched from SPI.
On Wed, Nov 24, 2021 at 10:11 PM Thomas Skibo wrote:
>
> On 11/23/21 8:39 PM, Sean Anderson wrote:
> > On 11/23/21 11:27 PM, Thomas Skibo wrote:
> >> +
> >> +
> >> +Booting from SPI
> >> +
> >> +
> >> +Use Building steps from "Booting from uSD using U-Boot SPL" section.
> >> +
> >> +Partition the SPI in Linux via mtdblock.
> >> +
> >> +.. code-block:: none
> >> +
> >> +sgdisk --clear -a 1 \
> >> +--new=1:40:2087 --change-name=1:spl
> >> --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
> >> +--new=2:2088:10279 --change-name=2:uboot
> >> --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
> >> +--new=3:10280:10535 --change-name=3:env
> >> --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
> >
> > nit: Please use hexcodes as printed with sgdisk -L. And also document
> > what the type is. Documentation is for us humans after all :)
> >
> > --Sean
> >
>
> The first two partitions' typecodes are unique to the SiFive chip so
> they don't have a short hexcode. The third partition, storage for the
That's correct. The 1st two are SiFive boards specific. From util-linux:
/* HiFive bootloaders */
DEF_GUID("5B193300-FC78-40CD-8002-E86C45580B47", N_("HiFive FSBL")),
DEF_GUID("2E54B353-1271-4842-806F-E436D6AF6985", N_("HiFive BBL")),
> environment, is hexcode 8300 which is a Linux filesystem. I wonder if
> there is better partition type for the environment.
Shouldn't this be?
"u-boot-env" = PARTITION_U_BOOT_ENVIRONMENT
(3DE21764-95BD-54BD-A5C3-4ABE786F38A8)
Taken from doc/README.gpt
See:
https://github.com/u-boot/u-boot/commit/c0364ce1c6957c5295e933b95802e6966e00b08f
david
>
> I can change the typecode for the third partition and add a note about
> what the other partitions are.
>
> -Thomas
>
Re: [PATCH v2 1/2] board: sifive: unmatched: use zero copy for initrd
On Tue, Nov 9, 2021 at 7:11 PM Tom Rini wrote:
>
> On Tue, Nov 09, 2021 at 05:27:52PM +0100, Heinrich Schuchardt wrote:
> > On 11/9/21 17:07, Tom Rini wrote:
> > > On Tue, Nov 09, 2021 at 04:50:27PM +0100, Heinrich Schuchardt wrote:
> > > > On 11/9/21 16:46, Tom Rini wrote:
> > > > > On Tue, Nov 09, 2021 at 03:46:00PM +0100, Heinrich Schuchardt wrote:
> > > > >
> > > > > > Booting Ubuntu Impish showed the following output:
> > > > > >
> > > > > > relocaddr = 0xfff6
> > > > > >
> > > > > > Loading Ramdisk to fa118000, end f19d ...
> > > > > >
> > > > > > The initrd is overwriting the U-Boot binary. Booting fails.
> > > > > >
> > > > > > There is no need to copy the initrd from $ramdisk_addr_r.
> > > > > > Set init_high = ~0UL to use zero copy. Do the same for the device
> > > > > > tree.
> > > > > >
> > > > > > Same for the devicetree.
> > > > > >
> > > > > > Signed-off-by: Heinrich Schuchardt
> > > > > >
> > > > > > ---
> > > > > > v2:
> > > > > > Don't copy fdt either.
> > > > > > ---
> > > > > >include/configs/sifive-unmatched.h | 2 ++
> > > > > >1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/include/configs/sifive-unmatched.h
> > > > > > b/include/configs/sifive-unmatched.h
> > > > > > index f68d7d7676..69a4eb2f2a 100644
> > > > > > --- a/include/configs/sifive-unmatched.h
> > > > > > +++ b/include/configs/sifive-unmatched.h
> > > > > > @@ -59,6 +59,8 @@
> > > > > > "name=system,size=-,bootable,type=${type_guid_gpt_system};"
> > > > > >#define CONFIG_EXTRA_ENV_SETTINGS \
> > > > > > + "fdt_high=0x\0" \
> > > > > > + "initrd_high=0x\0" \
> > > > > > "kernel_addr_r=0x8400\0" \
> > > > > > "fdt_addr_r=0x8800\0" \
> > > > > > "scriptaddr=0x8810\0" \
> > > > >
> > > > > I know I'm doing this out of order, but I'm going to repeat myself
> > > > > here
> > > > > too. You cannot disable device tree relocation. I cannot count the
> > > > > number of hours that have been wasted because of this mis-feature due
> > > > > to
> > > > > misalignment of the device tree or overwriting of the device tree and
> > > > > then U-Boot not fixing it because it was told not to, and then people
> > > > > and projects wasting countless hours over it. It's why checkpatch.pl
> > > > > throws out an ERROR on this now. I didn't yell even more loudly
> > > > > previously at riscv because as it was missing the arch_lmb portion to
> > > > > avoid overwriting U-Boot at run-time, it still was a problem. But
> > > > > that's been fixed. So, no. NAK.
> > > >
> > > > Why should the devicetree relocated?
> > > > This should never have been enabled on RISC-V.
> > >
> > > To repeat myself, because RISC-V has been broken until very recently and
> > > lacked the parts of lmb to avoid overwriting U-Boot while running, is
> > > why any platforms have been allowed in with fdt/initrd_high set to
> > > disable relocation. As that problem has now been fixed, fdt relocation
> > > must be re-enabled on the currently wrong platforms, and will not be
> > > allowed on new platforms.
> > >
> > > There are specific deployment cases where the developer can choose to
> > > disable relocation because they know that there will never be a way for
> > > things to be done in an overlapping manner because the system is locked
> > > down. That is very rarely the case for mainline and absolutely not the
> > > case for a general purpose board like the unmatched.
> >
> > __lmb_alloc_base() seems not be integrated with the UEFI sub-system. So UEFI
> > might hand out memory marked as reserved in the LMB sub-system.
Heinrich, do you plan to work on this?
It would be great if we could finally solve this situation with the
2022.01 release.
Right now Unmatched is probably the only board that doesn't turn off
the relocation, and thus some people hit the issues.
Looking at the git history, the LMB issue is fixed in v2022.01-rc1
only right now. Minus UEFI part, which is/will be important for
distributions.
david
> >
> > I guess this is still a topic to be addressed.
>
> If UEFI can still end up getting U-Boot overwritten, yes, that needs to
> be addressed. Only slightly surprised one of the capture-the-flag or
> similar events hasn't come to us yet with some CVEs related to that,
> too.
>
> --
> Tom
Re: HiFive Unmatched: U-Boot stuck when loading Ramdisk
On Fri, Oct 15, 2021 at 7:16 PM Tom Rini wrote:
>
> On Fri, Oct 15, 2021 at 06:29:09PM +0300, David Abdurachmanov wrote:
> > On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel
> > wrote:
> > >
> > > Hello,
> > >
> > > I hope this is the right way to report u-boot issues. I tried to reach
> > > out to the RISC-V subsystem maintainer beforehand but didn't receive a
> > > response, hence sending this to the ML.
> > >
> > > We are currently working on Alpine Linux support for the Hifive
> > > Unmatched and at least two of our developers have access to a board
> > > presently. While working on Alpine support, we noticed that U-Boot with
> > > sifive_unmatched_defconfig gets stuck while loading the Alpine
> > > initramfs. The last message received on the SiFive UART is:
> > >
> > > Loading Ramdisk to ffa72000, end fc19 ...
> > >
> > > Afterwards, U-Boot is stuck. We ran into this problem on two different
> > > boards independently. Both with u-boot-2021.10 as well as u-boot master
> > > (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set
> > > initrd_high manually (i.e. change the address region the Ramdisk is
> > > loaded to) everything works as expected. For example, `setenv
> > > initrd_high 0x8500`. Maybe the default address region used for the
> > > Ramdisk overlaps with the U-Boot stack/text region or something?
> > >
> > > I am not familiar with U-Boot internals, but briefly looking at the code
> > > and how the default Ramdisk address region is calculated, it seems to me
> > > that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration
> > > for the Unmatched and Unleashed doesn't. If I set it manually everything
> > > works as expected. For example:
> > >
> > > diff --git a/include/configs/sifive-unmatched.h
> > > b/include/configs/sifive-unmatched.h
> > > index d63a5f62fb..e1d3cb4ec4 100644
> > > --- a/include/configs/sifive-unmatched.h
> > > +++ b/include/configs/sifive-unmatched.h
> > > @@ -25,6 +25,7 @@
> > >
> > > #endif
> > >
> > > +#define CONFIG_SYS_BOOTMAPSZ (256 << 20)
> > > #define CONFIG_SYS_SDRAM_BASE 0x8000
> > > #define CONFIG_SYS_INIT_SP_ADDR
> > > (CONFIG_SYS_SDRAM_BASE + SZ_2M)
> > >
> > > This causes the Ramdisk to be loaded to 8f9f7000, end 8b3d by
> > > default which, looking at the Unmatched memory map, seems to be a more
> > > sensible address region for the Ramdisk:
> > >
> > > Moving Image from 0x8400 to 0x8020, end=811a9000
> > > ## Flattened Device Tree blob at 8800
> > >Booting using the fdt blob at 0x8800
> > >Loading Ramdisk to 8f9f7000, end 8b3d ... OK
> > >Loading Device Tree to 8f9f1000, end 8f9f660b
> > > ... OK
> > >
> > > If there is a better place to report this issue let me know. If you need
> > > more information to reproduce/debug this issue I would be very happy to
> > > help.
> >
> > Could you try these two changes together (see below)?
> >
> > diff --git a/include/configs/sifive-unmatched.h
> > b/include/configs/sifive-unmatched.h
> > index 7157295..7254e06 100644
> > --- a/include/configs/sifive-unmatched.h
> > +++ b/include/configs/sifive-unmatched.h
> > @@ -67,7 +67,7 @@
> > "scriptaddr=0x8810\0" \
> > "pxefile_addr_r=0x8820\0" \
> > "ramdisk_addr_r=0x8830\0" \
> > - "kernel_comp_addr_r=0x9000\0" \
> > + "kernel_comp_addr_r=0x9030\0" \
> > "kernel_comp_size=0x400\0" \
> > "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
> > "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
> >
> > diff --git a/include/configs/sifive-unmatched.h
> > b/include/configs/sifive-unmatched.h
> > index 7254e06..3b72304 100644
> > --- a/include/configs/sifive-unmatched.h
> > +++ b/include/configs/sifive-unmatched.h
> > @@ -62,6 +62,8 @@
> > "name=system,size=-,bootable,type=${type_guid_gpt_system};"
> > #define CONFIG_EXTRA_ENV_SETTINGS \
> > + "fdt_high=0x\0" \
> > + "initrd_high=0x\0" \
> > "kernel_addr_r=0x8400\0" \
> > "fdt_addr_r=0x8
Re: HiFive Unmatched: U-Boot stuck when loading Ramdisk
On Fri, Oct 15, 2021 at 6:02 PM Sören Tempel wrote:
>
> Hello,
>
> I hope this is the right way to report u-boot issues. I tried to reach
> out to the RISC-V subsystem maintainer beforehand but didn't receive a
> response, hence sending this to the ML.
>
> We are currently working on Alpine Linux support for the Hifive
> Unmatched and at least two of our developers have access to a board
> presently. While working on Alpine support, we noticed that U-Boot with
> sifive_unmatched_defconfig gets stuck while loading the Alpine
> initramfs. The last message received on the SiFive UART is:
>
> Loading Ramdisk to ffa72000, end fc19 ...
>
> Afterwards, U-Boot is stuck. We ran into this problem on two different
> boards independently. Both with u-boot-2021.10 as well as u-boot master
> (78e786decb6c8783568044c98891e64289cbf59c). I noticed that if I set
> initrd_high manually (i.e. change the address region the Ramdisk is
> loaded to) everything works as expected. For example, `setenv
> initrd_high 0x8500`. Maybe the default address region used for the
> Ramdisk overlaps with the U-Boot stack/text region or something?
>
> I am not familiar with U-Boot internals, but briefly looking at the code
> and how the default Ramdisk address region is calculated, it seems to me
> that many boards set CONFIG_SYS_BOOTMAPSZ but the board configuration
> for the Unmatched and Unleashed doesn't. If I set it manually everything
> works as expected. For example:
>
> diff --git a/include/configs/sifive-unmatched.h
> b/include/configs/sifive-unmatched.h
> index d63a5f62fb..e1d3cb4ec4 100644
> --- a/include/configs/sifive-unmatched.h
> +++ b/include/configs/sifive-unmatched.h
> @@ -25,6 +25,7 @@
>
> #endif
>
> +#define CONFIG_SYS_BOOTMAPSZ (256 << 20)
> #define CONFIG_SYS_SDRAM_BASE 0x8000
> #define CONFIG_SYS_INIT_SP_ADDR
> (CONFIG_SYS_SDRAM_BASE + SZ_2M)
>
> This causes the Ramdisk to be loaded to 8f9f7000, end 8b3d by
> default which, looking at the Unmatched memory map, seems to be a more
> sensible address region for the Ramdisk:
>
> Moving Image from 0x8400 to 0x8020, end=811a9000
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8f9f7000, end 8b3d ... OK
>Loading Device Tree to 8f9f1000, end 8f9f660b ...
> OK
>
> If there is a better place to report this issue let me know. If you need
> more information to reproduce/debug this issue I would be very happy to
> help.
Could you try these two changes together (see below)?
diff --git a/include/configs/sifive-unmatched.h
b/include/configs/sifive-unmatched.h
index 7157295..7254e06 100644
--- a/include/configs/sifive-unmatched.h
+++ b/include/configs/sifive-unmatched.h
@@ -67,7 +67,7 @@
"scriptaddr=0x8810\0" \
"pxefile_addr_r=0x8820\0" \
"ramdisk_addr_r=0x8830\0" \
- "kernel_comp_addr_r=0x9000\0" \
+ "kernel_comp_addr_r=0x9030\0" \
"kernel_comp_size=0x400\0" \
"type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
"type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
diff --git a/include/configs/sifive-unmatched.h
b/include/configs/sifive-unmatched.h
index 7254e06..3b72304 100644
--- a/include/configs/sifive-unmatched.h
+++ b/include/configs/sifive-unmatched.h
@@ -62,6 +62,8 @@
"name=system,size=-,bootable,type=${type_guid_gpt_system};"
#define CONFIG_EXTRA_ENV_SETTINGS \
+ "fdt_high=0x\0" \
+ "initrd_high=0x\0" \
"kernel_addr_r=0x8400\0" \
"fdt_addr_r=0x8800\0" \
"scriptaddr=0x8810\0" \
>
> Greetings,
> Sören
Re: [PATCH] config/sifive_unmatched: add preboot commands
On Sun, Aug 15, 2021 at 6:27 PM Alexander von Gluck IV wrote: > > * Opens up u-boot to properly search through USB media > for a valid boot media > * The MMC on the unmatched is slow, so a model of running > the OS from USB or NVMe is a compelling one. (putting just > u-boot on the sd card) > --- > configs/sifive_unmatched_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/sifive_unmatched_defconfig > b/configs/sifive_unmatched_defconfig > index 38b7acd536..0e02d46f72 100644 > --- a/configs/sifive_unmatched_defconfig > +++ b/configs/sifive_unmatched_defconfig > @@ -11,6 +11,7 @@ CONFIG_TARGET_SIFIVE_UNMATCHED=y > CONFIG_ARCH_RV64I=y > CONFIG_RISCV_SMODE=y > # CONFIG_SPL_USE_ARCH_MEMMOVE is not set > +CONFIG_PREBOOT="pci enum; usb start;" I don't think you need it. Looking at the include/config_distro_bootcmd.h and in particular at CONFIG_CMD_USB I don't see BOOTENV_RUN_PCI_ENUM listed. It is listed for NVMe, VirtIO, DHCP stuff. In other words the current code in bootcmd does not expect USB to be connected via PCIe. Thus I suggest adding BOOTENV_RUN_PCI_ENUM (one line) to CONFIG_CMD_USB config as in other boot options. That seems to be the correct approach. david > CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_SPL_LOAD_FIT_ADDRESS=0x8400 > -- > 2.32.0 >
Re: [RFC 1/1] board: sifive: unmatched: use zero copy for initrd
On Tue, Jul 20, 2021 at 1:06 AM Tom Rini wrote: > > On Mon, Jul 19, 2021 at 11:52:09PM +0200, Heinrich Schuchardt wrote: > > > > > > On 19.07.21 23:38, Heinrich Schuchardt wrote: > > > Booting Ubuntu Impish showed the following output: > > > > > > relocaddr = 0xfff6 > > > > > > Loading Ramdisk to fa118000, end f19d ... > > > > > > The initrd is overwriting the U-Boot binary. Booting fails. > > > > > > There is no need to copy the initrd from $ramdisk_addr_r. > > > Set init_high = ~0UL to use zero copy. > > > > > > Signed-off-by: Heinrich Schuchardt > > > --- > > > Generally copying to another memory location than $ramdisk_addr_r provides > > > no benefit whatsoever. > > > > > > But we still should find out why the initrd relocation fails so badly. > > > --- > > > include/configs/sifive-unmatched.h | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/include/configs/sifive-unmatched.h > > > b/include/configs/sifive-unmatched.h > > > index d63a5f62fb..8dcfffedbe 100644 > > > --- a/include/configs/sifive-unmatched.h > > > +++ b/include/configs/sifive-unmatched.h > > > @@ -67,6 +67,7 @@ > > > "scriptaddr=0x8810\0" \ > > > "pxefile_addr_r=0x8820\0" \ > > > "ramdisk_addr_r=0x8830\0" \ > > > + "initrd_high=0x\0" \ > > > "kernel_comp_addr_r=0x9000\0" \ > > > > Tom remarked that kernel_comp_addr_r is poorly chosen as it will overlap > > with initrd if initrd exceeds 125 MiB. Current RISC-V Linux thinks > > initrd should fit into the first 128 MiB of RAM but that is an > > unnecessary restriction in Linux. While I don't expect this to be a major issue we should definitely fix it. When I originally picked the value I wasn't thinking about it and initrd images were small. david > > I'll repeat what I said on IRC as well. I lament that there does not > seem to be as detailed "booting" requirements in Linux for RISC-V as > there is for arm/aarch64 because we REALLY need something like: > https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/ti_armv7_common.h#L32 > but for one or more RISC-V platforms (and well, MIPS and everyone else > using device trees) that can be referenced when bringing up a new board > to get good and always safe addresses to use. > > And I'll even say now that the ti_armv7_common.h example could be > improved upon because I'm not super thrilled with the DTBO storage spot, > but I don't have a better answer off the top of my head. > > -- > Tom
Re: [PATCH] board: sifive: drop stuff related to unmatched revision 1
On Wed, Jul 14, 2021 at 2:22 PM Bin Meng wrote:
>
> Hi Zong,
>
> On Fri, Jul 9, 2021 at 4:06 PM Zong Li wrote:
> >
> > This patch reverts the following commits:
> > - 4b4159d0f3 ("riscv: dts: add dts for unmatched rev1")
> > - ffe9a394df ("board: sifive: support spl multi-dtb on unmatched board")
> >
> > We won't plan to support unmatched that the revision below 3 in u-boot,
> > so they can be dropped because they might be useless.
> >
> > Signed-off-by: Zong Li
> > Suggested-by: David Abdurachmanov
> > ---
> > arch/riscv/dts/Makefile |2 +-
> > .../fu740-hifive-unmatched-a00-ddr-rev1.dtsi | 1489 -
> > .../dts/hifive-unmatched-a00-rev1-u-boot.dtsi |7 -
> > arch/riscv/dts/hifive-unmatched-a00-rev1.dts |4 -
> > board/sifive/unmatched/spl.c | 28 +-
> > configs/sifive_unmatched_defconfig|4 -
> > 6 files changed, 3 insertions(+), 1531 deletions(-)
> > delete mode 100644 arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi
> > delete mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1-u-boot.dtsi
> > delete mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1.dts
>
> How do we tell boards at our hands whether it is rev1 board?
The boards from Crowd Supply and Mourser are 3B0 boards. That's at the
end of the assembly number (sticker on the board next to DIP and RTC
battery).
I2C EEPROM driver will print information (incl. PCB revision, e.g. 3).
You cannot buy any older revision. There are some 3A0 (you might have
one if you received it as an early access software ecosystem partner).
There are only minor changes between these boards and do not affect,
e.g. device tree. Boath boards will report PCB revision at 3.
>
> Are all patches in SiFive SDK upstreamed in current u-boot/master?
Not yet.
E.g. "[PATCH 0/2] board: sifive: unmatched: reset multiple devices in
SPL" I believe is not merged yet.
There might be some other things (I would need to check), e.g. LED
colors for bootstage indicator.
Cheers,
david
>
> Regards,
> Bin
Re: [PATCH v2 8/8] drivers: net: macb: add fu740 support
On Tue, Mar 16, 2021 at 6:35 PM Green Wan wrote:
>
> From: David Abdurachmanov
>
> Add fu740 support to macb ethernet driver
>
> Signed-off-by: David Abdurachmanov
> Signed-off-by: Green Wan
> Reviewed-by: Ramon Fried
> ---
> drivers/net/macb.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 57ea45e..df65d82 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -592,7 +592,11 @@ static int macb_sifive_clk_init(struct udevice *dev,
> ulong rate)
> * and output clock on GMII output signal GTX_CLK
> * 1 = MII mode. Use MII input signal TX_CLK in TX logic
> */
> - writel(rate != 12500, gemgxl_regs);
> + if (device_is_compatible(dev, "sifive,fu540-c000-gem"))
> + writel(rate != 12500, gemgxl_regs);
Could you add a comment here why we need this? (i.e. about the HW quirk)
Note that 125.125 is actually outside of specification for VSC8541XMV-02.
> + else if (device_is_compatible(dev, "sifive,fu740-c000-gem"))
> + writel(rate != 125125000, gemgxl_regs);
> +
> return 0;
> }
>
> @@ -1507,6 +1511,8 @@ static const struct udevice_id macb_eth_ids[] = {
> { .compatible = "cdns,zynq-gem" },
> { .compatible = "sifive,fu540-c000-gem",
> .data = (ulong)_config },
> + { .compatible = "sifive,fu740-c000-gem",
> + .data = (ulong)_config },
> { .compatible = "microchip,mpfs-mss-gem",
> .data = (ulong)_config },
> { }
> --
> 2.7.4
>
Re: [PATCH 7/7] drivers: net: macb: add fu740 support
On Thu, Mar 11, 2021 at 4:45 PM Bin Meng wrote: > > On Thu, Mar 11, 2021 at 10:42 PM Green Wan wrote: > > > > > > > > Bin Meng 於 2021年3月11日 週四，下午10:22寫道： > >> > >> On Thu, Mar 11, 2021 at 9:50 PM Green Wan wrote: > >> > > >> > Add fu740 support to macb ethernet driver > >> > > >> > Signed-off-by: Green Wan > >> > --- > >> > drivers/net/macb.c | 8 +++- > >> > 1 file changed, 7 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c > >> > index 57ea45e..df65d82 100644 > >> > --- a/drivers/net/macb.c > >> > +++ b/drivers/net/macb.c > >> > @@ -592,7 +592,11 @@ static int macb_sifive_clk_init(struct udevice > >> > *dev, ulong rate) > >> > * and output clock on GMII output signal GTX_CLK > >> > * 1 = MII mode. Use MII input signal TX_CLK in TX logic > >> > */ > >> > - writel(rate != 12500, gemgxl_regs); > >> > + if (device_is_compatible(dev, "sifive,fu540-c000-gem")) > >> > + writel(rate != 12500, gemgxl_regs); > >> > + else if (device_is_compatible(dev, "sifive,fu740-c000-gem")) > >> > + writel(rate != 125125000, gemgxl_regs); > >> > >> 125125000 seems to be an odd value for 1000 Mbps ethernet. Can you > >> please explain this a little bit? > > > > > > It's simply due to the limitation in the PLL cannot generate 125 000 000 Hz > > clock precisely. The closet one is 125 125 000 HZ. > > So FU540 can but FU740 cannot? I would consider this as a hardware > regression ... Note that 125.125MHz is out of spec, but that's the closest we can get and 1Gbps works fine based on the tests I did. This is hardware quirk, and probably a comment explaining this should be provided here. david > > Regards, > Bin
Re: [PATCH 1/4] travis: Remove qemu-riscv64 testing
On Fri, Mar 27, 2020 at 7:31 AM Bin Meng wrote: > > On Fri, Mar 27, 2020 at 1:20 PM David Abdurachmanov > wrote: > > > > On Thu, Mar 26, 2020 at 6:06 PM Bin Meng wrote: > > > > > > As of today there is no pre-built UEFI GRUB image for RISC-V 32/64 > > > available on the internet, and with travis-ci we don't build GRUB > > > images like we do for azure and gitlab. > > > > There are RPM packages for GRUB in OpenSUSE and Fedora. > > > > https://build.opensuse.org/package/binaries/openSUSE:Factory:RISCV/grub2/standard > > http://fedora.riscv.rocks/koji/buildinfo?buildID=133151 > > > > I've looked at this alternatives before, it turns out there are only > riscv64 images. Do you know any riscv32 prebuilt images? I am not aware of any distribution supporting RV32 (or plans to do it). Furthermore RV32 Linux ABI is not frozen yet. OE definitely has RV32 Linux support, but it doesn't incl. RV32 GRUB2 for booting. Simply put, I don't think there are RV32 GRUB2 binaries somewhere online. > > > I have not tried them on QEMU or Unleashed yet. > > > > We should be able to boot with GRUB2 and EFI stubs to the kernel soonish. > > Regards, > Bin
Re: [PATCH 1/4] travis: Remove qemu-riscv64 testing
On Thu, Mar 26, 2020 at 6:06 PM Bin Meng wrote: > > As of today there is no pre-built UEFI GRUB image for RISC-V 32/64 > available on the internet, and with travis-ci we don't build GRUB > images like we do for azure and gitlab. There are RPM packages for GRUB in OpenSUSE and Fedora. https://build.opensuse.org/package/binaries/openSUSE:Factory:RISCV/grub2/standard http://fedora.riscv.rocks/koji/buildinfo?buildID=133151 I have not tried them on QEMU or Unleashed yet. We should be able to boot with GRUB2 and EFI stubs to the kernel soonish. > > Remove qemu-riscv64 testing temporarily. > > Signed-off-by: Bin Meng > --- > > .travis.yml | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/.travis.yml b/.travis.yml > index c59bd77..55b94cf 100644 > --- a/.travis.yml > +++ b/.travis.yml > @@ -481,13 +481,6 @@ matrix: >QEMU_TARGET="ppc-softmmu" >BUILDMAN="^qemu-ppce500$" >TOOLCHAIN="powerpc" > -- name: "test/py qemu-riscv64" > - env: > -- TEST_PY_BD="qemu-riscv64" > - TEST_PY_TEST_SPEC="not sleep" > - QEMU_TARGET="riscv64-softmmu" > - BUILDMAN="^qemu-riscv64$" > - TOOLCHAIN="riscv" > - name: "test/py qemu-x86" >env: > - TEST_PY_BD="qemu-x86" > -- > 2.7.4 >
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
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 > > > > > > > > > > --- a/cmd/booti.c > > > > > > > > > > +++ b/cmd/booti.c > > > > > > > > > > @@ -13,6 +13,7 @@ > > > > > > > > > > #include > > > > > > > > > > #include > > > > > > > > > > > > > > > > > > > > +DECLARE_GLOBAL_DATA_PTR; > > > > > > > > > > /* > > > > > > > > > > * Image booting support > > > > > > > &
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
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,
> > > > > > 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("f
Re: [PATCH] distro_bootcmd: Add support for loading user environment
On Fri, Jan 31, 2020 at 3:42 PM Jon Hunter wrote: > > > On 31/01/2020 14:05, Tom Rini wrote: > > On Fri, Jan 31, 2020 at 01:24:21PM +, Jon Hunter wrote: > >> > >> On 31/01/2020 12:42, Soeren Moch wrote: > >>> On 31.01.20 11:59, Jon Hunter wrote: > U-Boot supports loading a user environment from a file in the > file-system. Therefore to make it easier for users to override the > default environment, add support to the 'distro_bootcmd' to look for > and load a user environment in a file called 'uEnv.txt' in the same > locations where an extlinux.conf or boot script might be found. > >>> > >>> We already have boot script support, which can easily be used to modify > >>> the environment. Do we really need to bloat the distro_boot machinery > >>> further with environment import, that is quite limited in contrast to > >>> boot scripts? > >> > >> If you are booting with an extlinux.conf file, as we do by default, then > >> if this file is found, this is always booted from before you have the > >> opportunity to run the boot.scr script. > >> > >> Furthermore if you did switch the order to boot from a boot.scr script > >> before the extlinux.conf, but you just wanted to do some simple > >> modifications of the environment before booting (ie. so the boot.scr > >> does not actually boot the system), then as the code is today you get a > >> 'echo SCRIPT FAILED: continuing...' message. > >> > >> Yes this could be changed, but just seems cleaner and simpler to add > >> support to make changes to the environment before the extlinux.conf is > >> loaded. > >> > >> Yes this does add more to the environment, but it is hardly significant > >> bloat, but if that is a concern then we could always disable this by > >> default and allow users to enable it. > > > > This is something I think we had talked about and rejected doing > > initially. Can you please expand on the use-case here, and why it's > > perhaps not better handled via PREBOOT on some platforms? Thanks! > > We have one specific use-case in a downstream version of u-boot where we > store some parameters in the u-boot environment for tweaking the DT > firmware on boot [0]. Now there are cases where we do not wish to modify > DT at all and so want to clear these variables and I would like a way to > automate the re-configuration of the u-boot environment without the user > having to manually set these just by the presence of a uEnv.txt file on > the disk. > > Admittedly, this particular use-case/scenario is not directly applicable > to the mainline u-boot branch as there is no support for these > environment variables for Tegra (yet). However, it seemed that this > change would have some value in upstream u-boot as well to allow the > user to change any default environment variables without having to > re-compile and hence, I decided submit this change here. >From Fedora/RISCV maintainer this sounds quite interesting. While working on boot flow I do re-building U-Boot multiple times tweaking the default environment (e.g. using preboot), but that's so annoying. uEnv.txt would be a lot easier and probably easier to explain to users who want to make quick modifications (as quick as modifying extlinux.conf). Also every time I re-build U-Boot I have to rebuild OpenSBI (which has U-Boot as a payload right now). > > For example, if we wanted to tweak any of the default environment > variables that are currently in 'include/configs/tegra210-common.h' we > could. Now you may say if we are not tweaking these very often, then why > not recompile, and we could, but given that we have the ability to load > environment parameters from a file on disk, it seems as shame that in > the current boot flow there is no way to make use of this extremely > useful feature. > > Cheers! > Jon > > [0] > https://nv-tegra.nvidia.com/gitweb/?p=3rdparty/u-boot.git;a=blob;f=include/configs/tegra210-common.h;h=81a3a2a447efacf34227847997fcc50639f54999;hb=refs/heads/l4t/l4t-r32.3.1-v2016.07#l59 > > -- > nvpublic
Re: [PATCH] riscv: sifive: fu540: Enable saving environment in MMC
On Thu, Jan 16, 2020 at 9:21 AM Bin Meng wrote: > > At present U-Boot environment is not saved so it's a little bit > inconvenient if booting kernel via network as each time we need > input the network environment variables from U-Boot shell. > > We already have the MMC support and let's enable saveenv with that. Does this also mean we can use fw_setenv and fw_printenv from the Linux user-space? How does one need to format partitions / prepare uSD card for this? Currently I have 4 GPT partitions: - /boot (ext4) - FSBL (raw) - OpenSBI + U-Boot (raw) - rootfs (ext4) david > > Signed-off-by: Bin Meng > --- > > configs/sifive_fu540_defconfig | 2 ++ > include/configs/sifive-fu540.h | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig > index 7d38ec9..6f9e619 100644 > --- a/configs/sifive_fu540_defconfig > +++ b/configs/sifive_fu540_defconfig > @@ -1,5 +1,6 @@ > CONFIG_RISCV=y > CONFIG_ENV_SIZE=0x2 > +CONFIG_ENV_OFFSET=0x100 > CONFIG_NR_DRAM_BANKS=1 > CONFIG_TARGET_SIFIVE_FU540=y > CONFIG_ARCH_RV64I=y > @@ -11,5 +12,6 @@ CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00" > CONFIG_DISPLAY_CPUINFO=y > CONFIG_DISPLAY_BOARDINFO=y > CONFIG_OF_SEPARATE=y > +CONFIG_ENV_IS_IN_MMC=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_DM_MTD=y > diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h > index 2756ed5..fb829be 100644 > --- a/include/configs/sifive-fu540.h > +++ b/include/configs/sifive-fu540.h > @@ -24,6 +24,8 @@ > > /* Environment options */ > > +#define CONFIG_SYS_MMC_ENV_DEV 0 > + > #define BOOT_TARGET_DEVICES(func) \ > func(MMC, mmc, 0) \ > func(DHCP, dhcp, na) > -- > 2.7.4 >
Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
On Thu, Dec 19, 2019 at 12:18 AM Vagrant Cascadian wrote:
>
> On 2019-12-18, David Abdurachmanov wrote:
> > On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian
> > wrote:
> >>
> >> On 2019-09-25, Vagrant Cascadian wrote:
> >> > On 2019-08-21, 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.
> >> >
> >> > Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
> >> >
> >> > Please CC me on future updates to the patch series.
> >> >
> >> > Tested-by: Vagrant Cascadian
> >>
> >> This patch, or something like it, is still needed with u-boot
> >> v2020.01-rc5 for extlinux support to load the device-tree from the boot
> >> firmware.
> >>
> >> Is there a new approach in the works, or any chance to see something
> >> like this get merged soon?
> >
> > I do carry several experiment patches in Fedora/RISCV, which I didn't
> > yet sent for a review.
> > Basically that allows me to boot a single Fedora/RISCV disk image on
> > QEMU virt machine
> > and SiFive Unleashed.
> >
> > See:
> > http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/uboot-tools.spec#L36
> >
> > Note some of the patches were merged in rc5.
>
> Thanks! I'll give your patches some testing when I get a chance.
>
>
> Some potentially quite naive questions:
>
> > You would want the following two patches:
> > http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv64-set-fdt_addr.patch
>
> Why does it need fdt_addr=0x8800 need to be set (and to the same
> value as fdt_addr_r)? According to README fdt_addr is for the flash
> media, which I don't think is used in the qemu case, at least. Is
> fdt_addr being (ab)used for some other purpose? I guess the README also
> gives free reign to use the variables for other purposes... but it would
> be good to know why that is needed vs. just using fdt_addr_r as
> documented.
The comments in uboot-tools.spec explain it.
This is only needed if you use EXTLINUX to boot your image. IIRC
EXTLINUX will assume DTB blob is available at fdt_addr or you can load
one via fdt/fdtdir label in extlinux.conf (never tried).
If you are booting in some other way you probably don't care about it.
>
>
> > http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv-bootargs-preboot.patch
>
> CONFIG_PREBOOT="cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x1;"
This used to solve memory corruption for DTB in v5.3 kernel IIRC. That
was fixed in v5.4 kernel thus should be removed (I will test later).
>
> What does cp.l do?
>
> Do you need to force setting the console in CONFIG_BOOTARGS? It seemed
> to autodetect the console on the installations I have running, possibly
> getting the chosen console from device-tree?
It doesn't detect it for me. Well it does on QEMU, but not on SiFive
Unleashed. Both use different console (ttyS0 vs ttySIF0). I think the
kernel doesn't look into chosen console expect powerpc IIRC.
I can retest since this was added:
https://github.com/torvalds/linux/commit/2993c9b04e616df0848b655d7202a707a70fc876
I am updating kernel in Fedora/RISCV to 5.5-rc2 now thus I can
re-check various patches again.
david
>
>
> live well,
> vagrant
Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian wrote: > > On 2019-09-25, Vagrant Cascadian wrote: > > On 2019-08-21, 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. > > > > Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks! > > > > Please CC me on future updates to the patch series. > > > > Tested-by: Vagrant Cascadian > > This patch, or something like it, is still needed with u-boot > v2020.01-rc5 for extlinux support to load the device-tree from the boot > firmware. > > Is there a new approach in the works, or any chance to see something > like this get merged soon? I do carry several experiment patches in Fedora/RISCV, which I didn't yet sent for a review. Basically that allows me to boot a single Fedora/RISCV disk image on QEMU virt machine and SiFive Unleashed. See: http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/uboot-tools.spec#L36 Note some of the patches were merged in rc5. You would want the following two patches: http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv64-set-fdt_addr.patch http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv-bootargs-preboot.patch If you could review them I could send them out. david
Re: [U-Boot] [RFC/RFT PATCH v4 3/3] image: Add compressed Image parsing support in booti.
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, _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, _addr, _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
Re: [U-Boot] [PATCH] include/env.h: Ensure ulong is defined
On Wed, Nov 6, 2019 at 4:30 PM Alistair Francis wrote: > > To fix these failures when building with musl: >include/env.h:166:1: error: unknown type name 'ulong'; did you mean 'long'? > ensure that ulong is defined. I think, this was fixed before 2019.10 release by this patchset: https://patchwork.ozlabs.org/cover/1152432/ > > Signed-off-by: Alistair Francis > --- > include/env.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/env.h b/include/env.h > index b72239f6a5..5ca49a3456 100644 > --- a/include/env.h > +++ b/include/env.h > @@ -13,6 +13,8 @@ > #include > #include > > +typedef unsigned long ulong; > + > struct environment_s; > > /* Value for environment validity */ > -- > 2.23.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ 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 Fri, Oct 11, 2019 at 12:23 AM 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
Tested-by: David Abdurachmanov
I also incl. it in Fedora/RISCV releases.
> ---
> 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.
> ---
> cmd/booti.c| 39 ++-
> doc/README.distro | 11
> doc/board/sifive/fu540.rst | 55 ++
> 3 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/booti.c b/cmd/booti.c
> index c36b0235df8c..6c37f84833d0 100644
> --- a/cmd/booti.c
> +++ b/cmd/booti.c
> @@ -13,6 +13,9 @@
> #include
> #include
>
> +DECLARE_GLOBAL_DATA_PTR;
> +#define GZ_HEADER_0 0x1f
> +#define GZ_HEADER_1 0x8b
> /*
> * Image booting support
> */
> @@ -23,6 +26,10 @@ 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 gz_len;
>
> ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
> images, 1);
> @@ -37,6 +44,34 @@ 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);
> +
> + if (*(temp) == GZ_HEADER_0 && *(temp+1) == GZ_HEADER_1) {
> + dest = env_get_ulong("kernel_gz_addr_r", 16, 0);
> + gz_len = env_get_ulong("kernel_gz_size", 16, 0);
> + if (!dest || !gz_len) {
> + puts("kernel_gz_addr_r or kernel_gz_size is not
> provided for Image.gz!\n");
> + return -EINVAL;
> + }
> + if (dest < gd->ram_base || dest > gd->ram_top) {
> + puts("kernel_gz_addr_r size is outside of dram
> range!\n");
> + return -EINVAL;
> + }
> +
> + debug("Image.gz of size = 0x%08lx will be decompressed at
> 0x%08lx\n",
> + gz_len, (ulong)dest);
> +
> + ret = image_decomp(IH_COMP_GZIP, 0, ld, IH_TYPE_KERNEL,
> +(void *)dest, (void *)ld, gz_len,
> +CONFIG_SYS_BOOTM_LEN, _end);
> + if (ret)
> + return ret;
> + /* dest_end contains the uncompressed Image size */
> + memmove((void *) ld, (void *)dest, dest_end);
> + unmap_sysmem((void *)dest);
> + }
> + unmap_sysmem((void *)ld);
> +
> ret = booti_setup(ld, _addr, _size, false);
> if (ret != 0)
> return 1;
> @@ -96,10 +131,12 @@ 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 'Image' or Image.gz 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"
> + "\tIn order to boot from Image.gz, user have to set
> kernel_gz_addr_r\n"
> + "\tand kernel_gz_size enviornment variables 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..dbf6eef07e35 100644
> --- a/doc/README.distro
> +++ b/doc/README.distro
> @@ -246,6 +246,17 @@ kernel_addr_r:
>
>A size of 16MB for the kernel is likely adequate.
>
> +kernel_gz_addr_r:
> + Optiona
Re: [U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V
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.
*
* 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.
> >
> > @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
> ___
> opensbi mailing list
> open...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/opensbi
___
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 Sun, Sep 8, 2019 at 3:10 PM Atish Patra wrote: > > 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 ? Not enough space for the kernel. Thus it was moved from 16M to 64M (which was a common thing for some ARM boards, e.g. 96Boards). I that point I didn't know about QEMU limitation and initrd placement (IIUC only if you use -initrd). > > 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. I don't think we should require this. FDT should be part of the firmware (FSBL, U-Boot SPI, OpenSBI, U-Boot, etc.). There should be a way to override the default one from the firmware (e.g. via tfptboot, PXE or EXTLINUX configs), but that's optional as majority people will not do that. david > > > -- > Regards, > Atish > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
On Mon, Aug 26, 2019 at 5:43 AM Bin Meng wrote:
>
> Hi David,
>
> On Thu, Aug 22, 2019 at 3:07 AM David Abdurachmanov
> wrote:
> >
> > Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
> > commands in RISC-V targets and broke extlinux support as reported
> > by Fu Wei .
>
> I think you need add a "Reported-By" tag instead of writing this in
> the commit message.
Yes. I rushed to send the patch. There should also be Tested-By from him.
>
> And a "Fixes: commit-id ("commit title") format as well.
Okay. Basically same as for kernel patches.
>
> Please describe the commit title using something like:
>
> riscv: fix extlinux (define preboot)
>
> as it impacts more than one target.
I can only test two targets.
That's also the main (only?) used targets by Fedora/RISCV users.
I don't want to modify targets that I (or users) can test.
>
> >
> > The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
> > to Kconfig.
> >
> > Signed-off-by: David Abdurachmanov
> > ---
> > configs/qemu-riscv64_smode_defconfig | 2 ++
>
> What about other QEMU RISC-V targets?
That's the only two targets which I can test.
Also the only two targets that had this enabled.
>
> > 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};"
>
> Please insert the config option to the correct place, eg: you can run
> it like this:
>
> $ make savedefconfig
> $ cp defconfig configs/qemu-riscv64_smode_defconfig
Will do.
>
> > 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};"
> > -
> > #endif /* __CONFIG_H */
> > --
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10-rc2 released
On Wed, Aug 21, 2019 at 1:24 AM Peter Robinson wrote: > > Hi Simon, > > > It's the day after the scheduled release day, and here is v2019.10-rc2. > > It took me a while to confirm that the riscv PR was causing the issue I > > saw, and I got extra paranoid about testing all of the other PRs to be > > sure it really was that and not some other race condition. At this > > point, it's time to aim to stabilize everything. That said, I think > > there's at least one or two trees that haven't sent their big PR yet and > > I'd like to see that come in as soon as possible. > > > > In terms of a changelog, > > git log --merges v2019.10-rc1..v2019.10-rc2 > > continues to look pretty good but the content there varies based on what > > was given to me in the PR. So please, the more details in the request > > the better! > > > > I'm still planning on doing -rc3 on the 26th of August with -rc4 on > > September 9th and -rc5 on September 23rd with the release scheduled on > > October 7th. Thanks all! > > I'm seeing the following build failure with gcc 9, possibly due to > tightened cflags in Fedora, although from a quick look I don't see > why, since the split out of environment functions into the separate > header. Any thoughts on what might be missing? I hit the same issue on RISC-V. Looks like env.h incl. linux/types.h (the internal one in U-Boot provides ulong). Then IIUC all U-Boot incl. are added via -idirafter flag thus we probably incl. /usr/include/linux/types.h from the system which doesn't have these typedefs. I haven't verified it via a local build thus it's just a guess. > > Peter > > BUILDSTDERR: gcc -O2 -g -pipe -Wall -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions > -fstack-protector-strong -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection > -Wp,-MD,scripts/dtc/.checks.o.d -Iscripts/dtc -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu11 > -I../scriptsIn file included from ../tools/env/../../env/flags.c:7, > BUILDSTDERR: from ../tools/env/env_flags.c:1: > BUILDSTDERR: ../include/env.h:158:1: error: unknown type name 'ulong'; > did you mean 'long'? > BUILDSTDERR: 158 | ulong env_get_ulong(const char *name, int base, > ulong default_val); > BUILDSTDERR: | ^ > BUILDSTDERR: | long > BUILDSTDERR: ../include/env.h:158:49: error: unknown type name > 'ulong'; did you mean 'long'? > BUILDSTDERR: 158 | ulong env_get_ulong(const char *name, int base, > ulong default_val); > BUILDSTDERR: | ^ > BUILDSTDERR: | long > BUILDSTDERR: ../include/env.h:167:40: error: unknown type name > 'ulong'; did you mean 'long'? > BUILDSTDERR: 167 | int env_set_ulong(const char *varname, ulong value); > BUILDSTDERR: |^ > BUILDSTDERR: |long > BUILDSTDERR: ../include/env.h:179:1: error: unknown type name 'ulong'; > did you mean 'long'? > BUILDSTDERR: 179 | ulong env_get_hex(const char *varname, ulong > default_val); > BUILDSTDERR: | ^ > BUILDSTDERR: | long > BUILDSTDERR: ../include/env.h:179:40: error: unknown type name > 'ulong'; did you mean 'long'? > BUILDSTDERR: 179 | ulong env_get_hex(const char *varname, ulong > default_val); > BUILDSTDERR: |^ > BUILDSTDERR: |long > BUILDSTDERR: ../include/env.h:188:38: error: unknown type name > 'ulong'; did you mean 'long'? > BUILDSTDERR: 188 | int env_set_hex(const char *varname, ulong value); > BUILDSTDERR: | ^ > BUILDSTDERR: | long > BUILDSTDERR: ../include/env.h: In function 'env_set_addr': > BUILDSTDERR: ../include/env.h:199:31: error: 'ulong' undeclared (first > use in this function) > BUILDSTDERR: 199 | return env_set_hex(varname, (ulong)addr); > BUILDSTDERR: | ^ > BUILDSTDERR: ../include/env.h:199:31: note: each undeclared identifier > is reported only once for each function it appears in > BUILDSTDERR: ../include/env.h:199:37: error: expected ')' before 'addr' > BUILDSTDERR: 199 | return env_set_hex(varname, (ulong)addr); > BUILDSTDERR: | ^~~~ > BUILDSTDERR: | ) > BUILDSTDERR: ../include/env.h: At top level: > BUILDSTDERR: ../include/env.h:223:44: error: unknown type name 'uint8_t' > BUILDSTDERR: 223 | int eth_env_get_enetaddr(const char *name, > uint8_t *enetaddr); > BUILDSTDERR: |^~~ > BUILDSTDERR: ../include/env.h:232:50: error: unknown
[U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
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};"
-
#endif /* __CONFIG_H */
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 3/4] riscv: sifive: fu540: Sync-up config header with RISC-V QEMU support
On Mon, Jul 22, 2019 at 10:48 AM Anup Patel wrote: > > We typically use same set of distro images (yocto, debian, fedora, etc.) > on both QEMU RISC-V virt machine and SiFive Unleashed board. > > With growing kernel and ramdisk images, we need to re-adjust default > U-Boot environment variables. The config header for QEMU RISC-V virt > machine has been already updated to handle bigger kernel and ramdisk > images hence this patch updates SiFive FU540 config header accordingly. > > Signed-off-by: Anup Patel > --- Reviewed-by: David Abdurachmanov Tested-by: David Abdurachmanov ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH] distro_bootcmd: refactor virtio to support PCI block devices
Starting libvirt v5.3.0 with QEMU 4.0.0 use of PCI is automatic
and thus storage is connected via PCI, which is not visible to
U-Boot out-of-the-box.
Refactor to do "pci enum" followed by "virtio scan" to see PCI
connected storage, and allow bootloader to load kernel and
initramfs images.
Tested with Fedora/RISCV using releases: libvirt 5.4.0 & 5.5.0,
QEMU 4.0.0 and U-Boot 2019.07 RC4.
Signed-off-by: David Abdurachmanov
---
include/config_distro_bootcmd.h | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 26e61ef196..3570a32dff 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -254,11 +254,11 @@
#endif
#if defined(CONFIG_DM_PCI)
-#define BOOTENV_RUN_NET_PCI_ENUM "run boot_net_pci_enum; "
+#define BOOTENV_RUN_PCI_ENUM "run boot_pci_enum; "
#define BOOTENV_SHARED_PCI \
- "boot_net_pci_enum=pci enum\0"
+ "boot_pci_enum=pci enum\0"
#else
-#define BOOTENV_RUN_NET_PCI_ENUM
+#define BOOTENV_RUN_PCI_ENUM
#define BOOTENV_SHARED_PCI
#endif
@@ -281,10 +281,24 @@
#endif
#ifdef CONFIG_CMD_VIRTIO
-#define BOOTENV_SHARED_VIRTIO BOOTENV_SHARED_BLKDEV(virtio)
+#define BOOTENV_RUN_VIRTIO_INIT "run virtio_init; "
+#define BOOTENV_SET_VIRTIO_NEED_INIT "virtio_need_init=; "
+#define BOOTENV_SHARED_VIRTIO \
+ "virtio_init=" \
+ "if ${virtio_need_init}; then " \
+ "virtio_need_init=false; " \
+ "virtio scan; " \
+ "fi\0" \
+ \
+ "virtio_boot=" \
+ BOOTENV_RUN_PCI_ENUM \
+ BOOTENV_RUN_VIRTIO_INIT \
+ BOOTENV_SHARED_BLKDEV_BODY(virtio)
#define BOOTENV_DEV_VIRTIO BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_VIRTIOBOOTENV_DEV_NAME_BLKDEV
#else
+#define BOOTENV_RUN_VIRTIO_INIT
+#define BOOTENV_SET_VIRTIO_NEED_INIT
#define BOOTENV_SHARED_VIRTIO
#define BOOTENV_DEV_VIRTIO \
BOOT_TARGET_DEVICES_references_VIRTIO_without_CONFIG_CMD_VIRTIO
@@ -350,7 +364,7 @@
#define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
"bootcmd_dhcp=" \
BOOTENV_RUN_NET_USB_START \
- BOOTENV_RUN_NET_PCI_ENUM \
+ BOOTENV_RUN_PCI_ENUM \
"if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
"source ${scriptaddr}; " \
"fi;" \
@@ -369,7 +383,7 @@
#define BOOTENV_DEV_PXE(devtypeu, devtypel, instance) \
"bootcmd_pxe=" \
BOOTENV_RUN_NET_USB_START \
- BOOTENV_RUN_NET_PCI_ENUM \
+ BOOTENV_RUN_PCI_ENUM \
"dhcp; " \
"if pxe get; then " \
"pxe boot; " \
@@ -465,6 +479,7 @@
"distro_bootcmd=" BOOTENV_SET_SCSI_NEED_INIT \
BOOTENV_SET_NVME_NEED_INIT\
BOOTENV_SET_IDE_NEED_INIT \
+ BOOTENV_SET_VIRTIO_NEED_INIT \
"for target in ${boot_targets}; do " \
"run bootcmd_${target}; " \
"done\0"
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] distro_bootcmd: refactor virtio to support PCI block devices
libvirt v5.3.0 with QEMU 4.0.0 use PCI automatically and thus storage
is connected via PCI, which is not visible to U-Boot automatically.
Refactor to do "pci enum" followed by "virtio scan" to see PCI
connected storage.
Tested with Fedora/RISCV using the latest releases: libvirt 5.4.0,
QEMU 4.0.0 and U-Boot 2019.07 RC4.
Signed-off-by: David Abdurachmanov
---
include/config_distro_bootcmd.h | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 26e61ef196..3570a32dff 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -254,11 +254,11 @@
#endif
#if defined(CONFIG_DM_PCI)
-#define BOOTENV_RUN_NET_PCI_ENUM "run boot_net_pci_enum; "
+#define BOOTENV_RUN_PCI_ENUM "run boot_pci_enum; "
#define BOOTENV_SHARED_PCI \
- "boot_net_pci_enum=pci enum\0"
+ "boot_pci_enum=pci enum\0"
#else
-#define BOOTENV_RUN_NET_PCI_ENUM
+#define BOOTENV_RUN_PCI_ENUM
#define BOOTENV_SHARED_PCI
#endif
@@ -281,10 +281,24 @@
#endif
#ifdef CONFIG_CMD_VIRTIO
-#define BOOTENV_SHARED_VIRTIO BOOTENV_SHARED_BLKDEV(virtio)
+#define BOOTENV_RUN_VIRTIO_INIT "run virtio_init; "
+#define BOOTENV_SET_VIRTIO_NEED_INIT "virtio_need_init=; "
+#define BOOTENV_SHARED_VIRTIO \
+ "virtio_init=" \
+ "if ${virtio_need_init}; then " \
+ "virtio_need_init=false; " \
+ "virtio scan; " \
+ "fi\0" \
+ \
+ "virtio_boot=" \
+ BOOTENV_RUN_PCI_ENUM \
+ BOOTENV_RUN_VIRTIO_INIT \
+ BOOTENV_SHARED_BLKDEV_BODY(virtio)
#define BOOTENV_DEV_VIRTIO BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_VIRTIOBOOTENV_DEV_NAME_BLKDEV
#else
+#define BOOTENV_RUN_VIRTIO_INIT
+#define BOOTENV_SET_VIRTIO_NEED_INIT
#define BOOTENV_SHARED_VIRTIO
#define BOOTENV_DEV_VIRTIO \
BOOT_TARGET_DEVICES_references_VIRTIO_without_CONFIG_CMD_VIRTIO
@@ -350,7 +364,7 @@
#define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
"bootcmd_dhcp=" \
BOOTENV_RUN_NET_USB_START \
- BOOTENV_RUN_NET_PCI_ENUM \
+ BOOTENV_RUN_PCI_ENUM \
"if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
"source ${scriptaddr}; " \
"fi;" \
@@ -369,7 +383,7 @@
#define BOOTENV_DEV_PXE(devtypeu, devtypel, instance) \
"bootcmd_pxe=" \
BOOTENV_RUN_NET_USB_START \
- BOOTENV_RUN_NET_PCI_ENUM \
+ BOOTENV_RUN_PCI_ENUM \
"dhcp; " \
"if pxe get; then " \
"pxe boot; " \
@@ -465,6 +479,7 @@
"distro_bootcmd=" BOOTENV_SET_SCSI_NEED_INIT \
BOOTENV_SET_NVME_NEED_INIT\
BOOTENV_SET_IDE_NEED_INIT \
+ BOOTENV_SET_VIRTIO_NEED_INIT \
"for target in ${boot_targets}; do " \
"run bootcmd_${target}; " \
"done\0"
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] qemu-riscv: enable VIRTIO_PCI
libvirt v.5.3.0 with QEMU 4.0.0 or above uses PCI automatically and thus devices (network, storage, etc) are connected via PCI. Signed-off-by: David Abdurachmanov --- board/emulation/qemu-riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 7f9a74dd48..6cc7c31dc6 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -24,6 +24,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply VIRTIO_MMIO imply VIRTIO_NET imply VIRTIO_BLK + imply VIRTIO_PCI imply CMD_PING imply CMD_FS_GENERIC imply DOS_PARTITION -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Enable booting from VirtIO PCI connected storage
Fedora/RISCV uses OpenSBI + U-Boot setup which loads extlinux configuration file from boot media and then continues booting Linux kernel. pcie-root-port was finally enabled for RISC-V in QEMU 4.0.0. PCI is now default instead of MMIO starting libvirt v5.3.0 with QEMU 4.0.0 or newer. Simply put this means that devices are connected over VirtIO PCI (incl. storage, i.e. boot media). Andrea Bolognani (Red Hat, Virtualization) noticed that Fedora/RISCV doesn't boot using libvirt. This is due to U-Boot not detecting boot media. These two small patches address the issue (tested by me and Andrea). Cc: Bin Meng Cc: Andrea Bolognani Cc: Richard W.M. Jones Cc: Palmer Dabbelt David Abdurachmanov (2): qemu-riscv: enable VIRTIO_PCI distro_bootcmd: refactor virtio to support PCI block devices board/emulation/qemu-riscv/Kconfig | 1 + include/config_distro_bootcmd.h| 27 +-- 2 files changed, 22 insertions(+), 6 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RISC-V: Crashes with OpenSBI+U-Boot on the qemu "virt" machine
On Sat, May 4, 2019 at 7:20 PM Anup Patel wrote: > > On Sat, May 4, 2019 at 8:38 PM Karsten Merker wrote: > > > > On Sat, May 04, 2019 at 09:24:15AM +0530, Anup Patel wrote: > > > > [U-Boot+OpenSBI crash with more than 2GB RAM in qemu-system-riscv64] > > > I tried again with image header changes applied to u-boot and > > > Linux kernel but still not able to reproduce the issues. > > > > > > Either you might have more local changes or debian toolchain > > > is causing issue for u-boot. > > > > Hello, > > > > I hadn't made any local changes besides the ones described in my > > original email, i.e. the application of the booti patches. To > > check for a toolchain-related problem I have rebuilt everything > > with both the gcc8-based and the gcc7-based buildroot toolchains, > > but the problem remained in all cases, regardless of whether I > > used the branch with the booti patch or the plain v2019.07-rc1 > > tag, so the problem is definitely not specific to the Debian > > toolchain. As a new qemu release has happend just a few days > > ago, I have now tried to upgrade qemu from the previous release > > version 3.1.0 to the freshly released version 4.0.0, and indeed > > with qemu 4.0.0 both the 2GB problem and the hang of init in SMP > > configurations with OpenSBI+U-Boot are gone. Which qemu version > > had you been using in your tests? > > I am using QEMU 4.0.0-rc2. > If you want to use SMP with U-Boot you need to use QEMU 4.0.0 + Kernel 5.1 + U-Boot v2019.07-rc1. At least that's what I recall. david ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64M
On Thu, Apr 11, 2019 at 2:40 PM Auer, Lukas wrote: > > + Bin > [Please use get_maintainer or patman to include all maintainers on CC] Thanks. Hm.. get_maintainer and patman are not mentioned on wiki page: "Patches and Feature Requests". It only mentions to CC people from: http://www.denx.de/wiki/U-Boot/Custodians > > On Tue, 2019-04-09 at 12:42 +0200, David Abdurachmanov wrote: > > After updating Fedora/RISCV kernel to 5.1-rc3+ the size increased above > > the current threshold. Looking into HiKey, Dragonboards, etc. seems that > > SZ_64M is a popular option. > > > > This sucessfully boots Fedora/RISCV with 5.1-rc3+ kernel on QEMU 4.0 > > (master) > > with OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup. > > > > Signed-off-by: David Abdurachmanov > > --- > > include/configs/qemu-riscv.h | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h > > index 2588c5a0b2..22a5cd7365 100644 > > --- a/include/configs/qemu-riscv.h > > +++ b/include/configs/qemu-riscv.h > > @@ -15,7 +15,7 @@ > > > > #define CONFIG_SYS_MALLOC_LENSZ_8M > > > > -#define CONFIG_SYS_BOOTM_LEN SZ_16M > > +#define CONFIG_SYS_BOOTM_LEN SZ_64M > > > > #define CONFIG_STANDALONE_LOAD_ADDR 0x8020 > > > > @@ -41,11 +41,11 @@ > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > "fdt_high=0x\0" \ > > "initrd_high=0x\0" \ > > - "kernel_addr_r=0x8100\0" \ > > - "fdt_addr_r=0x8200\0" \ > > - "scriptaddr=0x8210\0" \ > > - "pxefile_addr_r=0x8220\0" \ > > - "ramdisk_addr_r=0x8230\0" \ > > + "kernel_addr_r=0x8400\0" \ > > Why are you also moving kernel_addr_r? I think there two 16MB windows here for kernel: - 0x8000 - 0x8100 (kernel_addr_r), and kernel is loaded at 0x8020 - 0x8100 (kernel_addr_r) - 0x8200 (fdt_addr_r) From U-Boot documentation: [..] 236 kernel_addr_r: 237 238 Mandatory. The location in RAM where the kernel will be loaded to when 239 processing the kernel option in the extlinux.conf. [..] Thus I moved it to ensure that both windows are 64MB. > > Thanks, > Lukas > > > + "fdt_addr_r=0x8800\0" \ > > + "scriptaddr=0x8810\0" \ > > + "pxefile_addr_r=0x8820\0" \ > > + "ramdisk_addr_r=0x8830\0" \ > > BOOTENV > > > > #endif /* __CONFIG_H */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] riscv: qemu-riscv.h: define CONFIG_PREBOOT (enables extlinux)
On Thu, Apr 11, 2019 at 2:41 PM Auer, Lukas
wrote:
>
> + Bin
>
> On Tue, 2019-04-09 at 12:42 +0200, David Abdurachmanov wrote:
> > - Set fdt_addr variable, which is needed for extlinux to find FDT.
> > Otherwise booting kernel using extlinux results in missing FDT.
> >
> > - Also run fdt addr with FDT address so that fdt commands would
> > work out of the box in U-Boot prompt.
>
> While often useful to have, the fdt command is not used during a normal
> boot. I think we should avoid calling commands, which are not normally
> needed. Can you remove this from your patch?
I borrowed idea from other boards, and I find it useful to have fdt working
out-of-the-box without trying to figure the correct variable which holds
address of FDT.
I can remove it from the patch, but I will probably keep adding it as Fedora
specific patch then.
>
> Thanks,
> Lukas
>
> >
> > This is successfully used by Fedora/RISCV with 5.1-rc3+ kernel using
> > OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup.
> >
> > Signed-off-by: David Abdurachmanov
> > ---
> > include/configs/qemu-riscv.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
> > index 22a5cd7365..b7110edebc 100644
> > --- a/include/configs/qemu-riscv.h
> > +++ b/include/configs/qemu-riscv.h
> > @@ -48,4 +48,8 @@
> > "ramdisk_addr_r=0x8830\0" \
> > BOOTENV
> >
> > +#define CONFIG_PREBOOT \
> > + "setenv fdt_addr ${fdtcontroladdr};" \
> > + "fdt addr ${fdtcontroladdr};"
> > +
> > #endif /* __CONFIG_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64M
After updating Fedora/RISCV kernel to 5.1-rc3+ the size increased above the current threshold. Looking into HiKey, Dragonboards, etc. seems that SZ_64M is a popular option. This sucessfully boots Fedora/RISCV with 5.1-rc3+ kernel on QEMU 4.0 (master) with OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup. Signed-off-by: David Abdurachmanov --- include/configs/qemu-riscv.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h index 2588c5a0b2..22a5cd7365 100644 --- a/include/configs/qemu-riscv.h +++ b/include/configs/qemu-riscv.h @@ -15,7 +15,7 @@ #define CONFIG_SYS_MALLOC_LEN SZ_8M -#define CONFIG_SYS_BOOTM_LEN SZ_16M +#define CONFIG_SYS_BOOTM_LEN SZ_64M #define CONFIG_STANDALONE_LOAD_ADDR0x8020 @@ -41,11 +41,11 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "fdt_high=0x\0" \ "initrd_high=0x\0" \ - "kernel_addr_r=0x8100\0" \ - "fdt_addr_r=0x8200\0" \ - "scriptaddr=0x8210\0" \ - "pxefile_addr_r=0x8220\0" \ - "ramdisk_addr_r=0x8230\0" \ + "kernel_addr_r=0x8400\0" \ + "fdt_addr_r=0x8800\0" \ + "scriptaddr=0x8810\0" \ + "pxefile_addr_r=0x8820\0" \ + "ramdisk_addr_r=0x8830\0" \ BOOTENV #endif /* __CONFIG_H */ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] riscv: qemu-riscv.h: define CONFIG_PREBOOT (enables extlinux)
- Set fdt_addr variable, which is needed for extlinux to find FDT.
Otherwise booting kernel using extlinux results in missing FDT.
- Also run fdt addr with FDT address so that fdt commands would
work out of the box in U-Boot prompt.
This is successfully used by Fedora/RISCV with 5.1-rc3+ kernel using
OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup.
Signed-off-by: David Abdurachmanov
---
include/configs/qemu-riscv.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
index 22a5cd7365..b7110edebc 100644
--- a/include/configs/qemu-riscv.h
+++ b/include/configs/qemu-riscv.h
@@ -48,4 +48,8 @@
"ramdisk_addr_r=0x8830\0" \
BOOTENV
+#define CONFIG_PREBOOT \
+ "setenv fdt_addr ${fdtcontroladdr};" \
+ "fdt addr ${fdtcontroladdr};"
+
#endif /* __CONFIG_H */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] riscv: set preboot and increase kernel size
The following two changes are used by Fedora/RISCV with 5.1-rc3+ kernel using OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup. Signed-off-by: David Abdurachmanov Cc: r...@andestech.com Cc: atish.pa...@wdc.com Cc: anup.pa...@wdc.com Cc: lukas.a...@aisec.fraunhofer.de David Abdurachmanov (2): riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64M riscv: qemu-riscv.h: define CONFIG_PREBOOT (enables extlinux) include/configs/qemu-riscv.h | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
