Re: [PATCH 1/1] riscv: enable CONFIG_DEBUG_UART by default
> From: Heinrich Schuchardt > Sent: Saturday, September 23, 2023 7:35 AM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > > Cc: u-boot@lists.denx.de; Heinrich Schuchardt > > Subject: [PATCH 1/1] riscv: enable CONFIG_DEBUG_UART by default > > Most boards don't enable the pre-console buffer. So we will not see any early > messages. OpenSBI 1.3 provides us with the debug console extension that can > fill this gap. > > For S-Mode U-Boot enable CONFIG_DEBUG_UART by default. > > Signed-off-by: Heinrich Schuchardt > --- > arch/riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Rick Chen
Re: [PATCH 7/7] riscv: Remove common.h usage
> From: Tom Rini > Sent: Friday, October 13, 2023 7:04 AM > To: u-boot@lists.denx.de > Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > > Subject: [PATCH 7/7] riscv: Remove common.h usage > > We can remove common.h from most cases of the code here, and only a few > places need an additional header instead. > > Signed-off-by: Tom Rini > --- > Cc: Rick Chen > Cc: Leo > --- Reviewed-by: Rick Chen
Re: [PATCH 1/1] configs: sifive: enable poweroff command on Unmatched
> From: Heinrich Schuchardt > Sent: Sunday, October 01, 2023 1:41 PM > To: Paul Walmsley ; Green Wan > Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; u-boot@lists.denx.de; Heinrich Schuchardt > > Subject: [PATCH 1/1] configs: sifive: enable poweroff command on Unmatched > > Powering off the SiFive HiFive Unmatched board is supported both via the SBI > and GPIO sysreset drivers. See device-tree entry > > compatible = "gpio-poweroff". > > Enable the poweroff command. > > Signed-off-by: Heinrich Schuchardt > --- > configs/sifive_unmatched_defconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Rick Chen
Re: [PATCH] riscv: Support riscv64 image type
> Hi Rick, > > On Wed, 19 Apr 2023 at 00:56, Rick Chen wrote: > > > > Hi Simon, > > > > > Hi Rick, > > > > > > On Mon, 10 Apr 2023 at 01:26, Rick Chen wrote: > > > > > > > > Allow U-Boot to load 32 or 64 bits RISC-V Kernel Image > > > > distinguishly. It helps to avoid someone maybe make a mistake > > > > to run 32-bit U-Boot to load 64-bit kernel. > > > > > > > > Signed-off-by: Rick Chen > > > > > > > > --- > > > > The patchset is based on Simon's patch: > > > > riscv: Add a 64-bit image type > > > > --- > > > > --- > > > > arch/riscv/include/asm/u-boot.h | 4 > > > > cmd/booti.c | 2 +- > > > > 2 files changed, 5 insertions(+), 1 deletion(-) > > > > > > Reviewed-by: Simon Glass > > > > > > I don't know much about RISC-V, but I assume U-Boot is able to do this > > > successfully? Does it not need to switch modes first? > > > > No, it is not need to switch modes as far as I know. > > Here only provide a check mechanism just like arm to see if loader and > > OS are match > > > > But This patch is for bootm flow. > > Maybe I still need to check if it is necessary to prepare a patch for > > binman flow ? > > /arch/riscv/dts/binman.dtsi > > arch = "riscv"; > > > > maybe provide another binman64.dtsi for arch="riscv64" > > Yes I think that is needed too. Are you going to update this patch, or > send a second one? Hi Simon, OK. HI Leo, I am a little busy on other things.Can you help to update this patch ? Thanks. Rick > > Regards, > Simon
Re: [PATCH v2 1/1] acpi: Add missing RISC-V acpi_table header
> From: Heinrich Schuchardt > Sent: Wednesday, July 26, 2023 2:05 PM > To: Rick Jian-Zhi Chen(陳建志) > Cc: Leo Yu-Chi Liang(梁育齊) ; u-boot@lists.denx.de; > Heinrich Schuchardt > Subject: [PATCH v2 1/1] acpi: Add missing RISC-V acpi_table header > > The pci_mmc.c driver can generate ACPI info and therefore includes > asm/acpi_table.h. This file does not exist for the RISC-V architecture and > thus code compilation fails when using this driver on RISC-V > > Create an empty include file. > > Signed-off-by: Heinrich Schuchardt > --- > v2: > Add include skeleton. > --- > arch/riscv/include/asm/acpi_table.h | 11 +++ > 1 file changed, 11 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH 1/1] riscv: sifive: initialize PCI on Unmatched
> From: Heinrich Schuchardt > Sent: Tuesday, July 25, 2023 6:42 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > > Cc: Paul Walmsley ; Green Wan > ; u-boot@lists.denx.de; Heinrich Schuchardt > > Subject: [PATCH 1/1] riscv: sifive: initialize PCI on Unmatched > > The Unmatched board is typically booted from NVMe which requires PCI. > When dropping to a console PCI is not initialized yet. 'pci enum' has to be > called. > > Change the configuration to call pci_init() in board_init_r(). > > Signed-off-by: Heinrich Schuchardt > --- > configs/sifive_unmatched_defconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Rick Chen
Re: [PATCH 18/18] riscv: qemu: Enable usb keyboard as an input device
> From: U-Boot On Behalf Of Bin Meng > Sent: Sunday, July 23, 2023 12:41 PM > To: Simon Glass ; u-boot@lists.denx.de > Cc: Bin Meng ; Heinrich Schuchardt > Subject: [PATCH 18/18] riscv: qemu: Enable usb keyboard as an input device > > This brings PCI xHCI support to QEMU RISC-V and uses a usb keyboard as one of > the input devices. > > Signed-off-by: Bin Meng > > --- > > board/emulation/qemu-riscv/Kconfig | 5 + > board/emulation/qemu-riscv/qemu-riscv.c | 5 + > doc/board/emulation/qemu-riscv.rst | 5 + > include/configs/qemu-riscv.h| 2 +- > 4 files changed, 16 insertions(+), 1 deletion(-) Reviewed-by: Rick Chen
Re: [PATCH 17/18] riscv: qemu: Remove out-of-date "riscv, kernel-start" handling
> From: U-Boot On Behalf Of Bin Meng
> Sent: Sunday, July 23, 2023 12:41 PM
> To: Simon Glass ; u-boot@lists.denx.de
> Cc: Bin Meng
> Subject: [PATCH 17/18] riscv: qemu: Remove out-of-date "riscv, kernel-start"
> handling
>
> Commit 66ffe57 ("riscv: qemu: detect and boot the kernel passed by QEMU")
> added some logic to handle "riscv,kernel-start" in DT and stored the address
> to an environment variable kernel_start.
>
> However this "riscv,kernel-start" has never been an upstream DT binding.
> The upstream QEMU never generates such a DT either. Presumably U-Boot
> development was based on a downstream QEMU fork.
>
> Now we drop all codes in commit 66ffe57, except that BOARD_LATE_INIT is kept
> for later use.
>
> Signed-off-by: Bin Meng
> ---
>
> board/emulation/qemu-riscv/qemu-riscv.c | 24
> include/configs/qemu-riscv.h| 10 --
> 2 files changed, 34 deletions(-)
Reviewed-by: Rick Chen
Re: [PATCH 15/18] riscv: qemu: Enable PRE_CONSOLE_BUFFER
> From: U-Boot On Behalf Of Bin Meng > Sent: Sunday, July 23, 2023 12:41 PM > To: Simon Glass ; u-boot@lists.denx.de > Cc: Bin Meng > Subject: [PATCH 15/18] riscv: qemu: Enable PRE_CONSOLE_BUFFER > > By default the video console only outputs messages after it's ready. > Messages before that won't show on the video console, but U-Boot has an > option to buffer the console messages before it's ready. > > Enable this support, and carefully select an address for the buffer. > > Signed-off-by: Bin Meng > --- > > board/emulation/qemu-riscv/Kconfig | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH] riscv: Fix alignment of RELA sections in the linker scripts
> From: Bin Meng
> Sent: Wednesday, June 21, 2023 11:07 PM
> To: u-boot@lists.denx.de
> Cc: Andrew Scull ; Leo Yu-Chi Liang(梁育齊)
> ; Rick Jian-Zhi Chen(陳建志) ; Simon
> Glass
> Subject: [PATCH] riscv: Fix alignment of RELA sections in the linker scripts
>
> In current linker script both .efi_runtime_rel and .rela.dyn sections are of
> RELA type whose entry size is either 12 (RV32) or 24 (RV64).
> These two are arranged as an continuous region on purpose so that the
> prelink-riscv executable can fix up the PIE addresses in one loop.
>
> However there is an 'ALIGN(8)' between these 2 sections which might cause a
> gap to be inserted between thesse 2 sections to satify the alignment
> requirement on RV32. This would break the assumption of the prelink process
> and generate an unbootable image.
>
> Fixes: 9a6569a043d3 ("riscv: Update alignment for some sections in linker
> scripts")
> Signed-off-by: Bin Meng
>
> ---
> This fix should go into the v2023.07 release.
>
> arch/riscv/cpu/u-boot.lds | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Reviewed-by: Rick Chen
Hi Leo,
Please help to push this patch ASAP.
Thanks,
Rick
Re: [PATCH v2 1/3] riscv: timer: Update the sifive clint timer driver to support aclint
> From: Bin Meng > Sent: Wednesday, June 21, 2023 11:12 PM > To: u-boot@lists.denx.de > Cc: Anup Patel ; Atish Patra ; > Bin Meng ; Palmer Dabbelt ; Paul > Walmsley ; Rick Jian-Zhi Chen(陳建志) > > Subject: [PATCH v2 1/3] riscv: timer: Update the sifive clint timer driver to > support aclint > > This RISC-V ACLINT specification [1] defines a set of memory mapped devices > which provide inter-processor interrupts (IPI) and timer functionalities for > each HART on a multi-HART RISC-V platform. > > The RISC-V ACLINT specification is defined to be backward compatible with the > SiFive CLINT specification, however the device tree binding is a new one. > This change updates the sifive clint timer driver to support ACLINT mtimer > device, using a per-driver data field to hold the mtimer offset to the base > address encoded in the mtimer node. > > [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - drop ae350.h changes > > drivers/timer/sifive_clint_timer.c | 16 +++- > include/configs/qemu-riscv.h | 2 +- > include/configs/sifive-unleashed.h | 2 +- > include/configs/starfive-visionfive2.h | 1 + > 4 files changed, 14 insertions(+), 7 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM
> From: Yanhong Wang
> Sent: Thursday, June 15, 2023 5:37 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo
> Yu-Chi Liang(梁育齊) ; Joe Hershberger
> ; Ramon Fried
> Cc: Yanhong Wang ; Torsten Duwe ;
> Leyfoon Tan ; samin . guo
> ; Walker Chen ; Hal
> Feng
> Subject: [PATCH v5 10/11] ram: starfive: Read memory size information from
> EEPROM
>
> StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of DDR
> capacity includes 2G/4G/8G, a DT can not support multiple capacities, so the
> capacity size information is recorded to EEPROM, when DDR initialization
> required capacity size information is read from EEPROM.
>
> If there is no information in EEPROM, it is initialized with the default size
> defined in DT.
>
> Signed-off-by: Yanhong Wang
> ---
> arch/riscv/cpu/jh7110/spl.c | 32 -
> drivers/ram/starfive/starfive_ddr.c | 2 --
> 2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c index
> 104f0fe949..72adcefa0e 100644
> --- a/arch/riscv/cpu/jh7110/spl.c
> +++ b/arch/riscv/cpu/jh7110/spl.c
> @@ -3,19 +3,49 @@
> * Copyright (C) 2022 StarFive Technology Co., Ltd.
> * Author: Yanhong Wang
> */
> -
> +#include
> +#include
> #include
> #include
> #include
> +#include
> #include
> +#include
>
> #define CSR_U74_FEATURE_DISABLE0x7c1
> #define L2_LIM_MEM_END 0x81FUL
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static bool check_ddr_size(phys_size_t size) {
> + switch (size) {
> + case SZ_2:
> + case SZ_4:
> + case SZ_8:
> + case SZ_16:
In commit message, it describes that "DDR capacity includes 2G/4G/8G".
Is it mismatch here ?
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> int spl_soc_init(void)
> {
> int ret;
> struct udevice *dev;
> + phys_size_t size;
> +
> + ret = fdtdec_setup_mem_size_base();
> + if (ret)
> + return ret;
It maybe unnecessary to add return above. If it fail to parse memory
node from DT, then there
has no chance to get ddr size from eeprom.
Thanks,
Rick
> +
> + /* Read the definition of the DDR size from eeprom, and if not,
> +* use the definition in DT
> +*/
> + size = (get_ddr_size_from_eeprom() >> 16) & 0xFF;
> + if (check_ddr_size(size))
> + gd->ram_size = size << 30;
>
> /* DDR init */
> ret = uclass_get_device(UCLASS_RAM, 0, ); diff --git
> a/drivers/ram/starfive/starfive_ddr.c b/drivers/ram/starfive/starfive_ddr.c
> index 553f2ce6f4..a0a3d6b33d 100644
> --- a/drivers/ram/starfive/starfive_ddr.c
> +++ b/drivers/ram/starfive/starfive_ddr.c
> @@ -72,8 +72,6 @@ static int starfive_ddr_probe(struct udevice *dev)
> u64 rate;
> int ret;
>
> - /* Read memory base and size from DT */
> - fdtdec_setup_mem_size_base();
> priv->info.base = gd->ram_base;
> priv->info.size = gd->ram_size;
>
> --
> 2.17.1
Re: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for 1.2A and 1.3B
> From: Yanhong Wang > Sent: Thursday, June 15, 2023 5:37 PM > To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo > Yu-Chi Liang(梁育齊) ; Joe Hershberger > ; Ramon Fried > Cc: Yanhong Wang ; Torsten Duwe ; > Leyfoon Tan ; samin . guo > ; Walker Chen ; Hal > Feng > Subject: [PATCH v5 11/11] board: starfive: Dynamic configuration of DT for > 1.2A and 1.3B > > The main difference between StarFive VisionFive 2 1.2A and 1.3B is gmac. > You can read the PCB version of the current board by > get_pcb_revision_from_eeprom(), and then dynamically configure the difference > of gmac in spl_perform_fixups() according to different PCB versions, so that > one DT and one defconfig can support both 1.2A and 1.3B versions, which is > more user-friendly. > > Signed-off-by: Yanhong Wang > --- > board/starfive/visionfive2/spl.c | 157 +++ > 1 file changed, 157 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux
> From: Conor Dooley > Sent: Thursday, June 15, 2023 6:13 PM > To: u-boot@lists.denx.de > Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; Padmarao Begari ; > Conor Dooley > Subject: [PATCH v2 2/3] riscv: dts: sync mpfs-icicle devicetree with linux > > The "notable" disappearances are: > - the pac193x stanza - there's nothing in mainline linux w.r.t. bindings > for this & what is going to appear in mainline linux is going to be > incompatible with what is currently in U-Boot. > - operating points - these operating points should not be set at the > soc.dtsi level as they may not be possible depending on the design > programmed to the FPGA > - clock output names - there are defines for the clock indices, these > should not be needed > - the dt maintainers in linux NAKed using defines for IRQ numbers > - the qspi nand, which is not part of the icicle's default configuration > is removed. > > Reviewed-by: Padmarao Begari > Tested-by: Padmarao Begari > Signed-off-by: Conor Dooley > --- > arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi| 71 +++ > arch/riscv/dts/mpfs-icicle-kit.dts| 190 +--- > arch/riscv/dts/mpfs.dtsi | 442 -- > .../dt-bindings/clock/microchip-mpfs-clock.h | 29 +- > .../microchip-mpfs-plic.h | 196 > .../interrupt-controller/riscv-hart.h | 17 - Reviewed-by: Rick Chen
Re: [PATCH 3/3] riscv: Rename SiFive CLINT to RISC-V ALINT
> From: Bin Meng
> Sent: Monday, June 12, 2023 3:36 PM
> To: u-boot@lists.denx.de
> Cc: Andre Przywara ; Anup Patel
> ; Jonas Schwöbel ; Kautuk
> Consul ; Leo Yu-Chi Liang(梁育齊)
> ; Michael Walle ; Michal Simek
> ; Nikita Shubin ; Rick Jian-Zhi
> Chen(陳建志) ; Sean Anderson ; Sergei
> Antonov ; Simon Glass ; Stefan
> Herbrechtsmeier ; Svyatoslav Ryhel
> ; Tianrui Wei ; William Zhang
> ; Yanhong Wang ;
> Peter Yu-Chien Lin(林宇謙)
> Subject: [PATCH 3/3] riscv: Rename SiFive CLINT to RISC-V ALINT
>
> As the RISC-V ACLINT specification is defined to be backward compatible with
> the SiFive CLINT specification, we rename SiFive CLINT to RISC-V ALINT in the
> source tree to be future-proof.
>
> Signed-off-by: Bin Meng
>
> ---
>
> MAINTAINERS | 2 +-
> arch/riscv/Kconfig| 8
> arch/riscv/cpu/fu540/Kconfig | 2 +-
> arch/riscv/cpu/fu740/Kconfig | 2 +-
> arch/riscv/cpu/generic/Kconfig| 4 ++--
> arch/riscv/cpu/jh7110/Kconfig | 2 +-
> arch/riscv/include/asm/global_data.h | 4 ++--
> arch/riscv/include/asm/syscon.h | 2 +-
> arch/riscv/lib/Makefile | 2 +-
> .../lib/{sifive_clint.c => aclint_ipi.c} | 16 +++
> board/openpiton/riscv64/Kconfig | 2 +-
> board/sipeed/maix/Kconfig | 2 +-
> drivers/timer/Makefile| 2 +-
> ...ive_clint_timer.c => riscv_aclint_timer.c} | 20 +--
> 14 files changed, 35 insertions(+), 35 deletions(-) rename
> arch/riscv/lib/{sifive_clint.c => aclint_ipi.c} (73%) rename
> drivers/timer/{sifive_clint_timer.c => riscv_aclint_timer.c} (75%)
Reviewed-by: Rick Chen
Re: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to support aclint
> > From: Bin Meng > > Sent: Monday, June 12, 2023 3:36 PM > > To: u-boot@lists.denx.de > > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > > > > Subject: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to > > support aclint > > > > This RISC-V ACLINT specification [1] defines a set of memory mapped devices > > which provide inter-processor interrupts (IPI) and timer functionalities > > for each HART on a multi-HART RISC-V platform. > > > > The RISC-V ACLINT specification is defined to be backward compatible with > > the SiFive CLINT specification, however the device tree binding is a new > > one. This change updates the sifive clint ipi driver to support ACLINT mswi > > device, by checking the per-driver data field of the ACLINT mtimer driver > > to determine whether a syscon based approach needs to be taken to get the > > base address of the ACLINT mswi device. > > > > [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc > > > > Signed-off-by: Bin Meng > > LGTM. Sorry, forgot the signed up. Reviewed-by: Rick Chen > > Thanks, > Rick
Re: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to support aclint
> From: Bin Meng > Sent: Monday, June 12, 2023 3:36 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > > Subject: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to > support aclint > > This RISC-V ACLINT specification [1] defines a set of memory mapped devices > which provide inter-processor interrupts (IPI) and timer functionalities for > each HART on a multi-HART RISC-V platform. > > The RISC-V ACLINT specification is defined to be backward compatible with the > SiFive CLINT specification, however the device tree binding is a new one. > This change updates the sifive clint ipi driver to support ACLINT mswi > device, by checking the per-driver data field of the ACLINT mtimer driver to > determine whether a syscon based approach needs to be taken to get the base > address of the ACLINT mswi device. > > [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc > > Signed-off-by: Bin Meng LGTM. Thanks, Rick
Re: [PATCH 1/3] riscv: timer: Update the sifive clint timer driver to support aclint
Hi Bin,
> From: Bin Meng
> Sent: Monday, June 12, 2023 3:36 PM
> To: u-boot@lists.denx.de
> Cc: Anup Patel ; Atish Patra ;
> Bin Meng ; Palmer Dabbelt ; Paul
> Walmsley ; Rick Jian-Zhi Chen(陳建志)
>
> Subject: [PATCH 1/3] riscv: timer: Update the sifive clint timer driver to
> support aclint
>
> This RISC-V ACLINT specification [1] defines a set of memory mapped devices
> which provide inter-processor interrupts (IPI) and timer functionalities for
> each HART on a multi-HART RISC-V platform.
>
> The RISC-V ACLINT specification is defined to be backward compatible with the
> SiFive CLINT specification, however the device tree binding is a new one.
> This change updates the sifive clint timer driver to support ACLINT mtimer
> device, using a per-driver data field to hold the mtimer offset to the base
> address encoded in the mtimer node.
>
> [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/timer/sifive_clint_timer.c | 16 +++-
> include/configs/ae350.h| 2 +-
> include/configs/qemu-riscv.h | 2 +-
> include/configs/sifive-unleashed.h | 2 +-
> include/configs/starfive-visionfive2.h | 1 +
> 5 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/timer/sifive_clint_timer.c
> b/drivers/timer/sifive_clint_timer.c
> index 939b99d937..be45f17ddf 100644
> --- a/drivers/timer/sifive_clint_timer.c
> +++ b/drivers/timer/sifive_clint_timer.c
> @@ -12,12 +12,16 @@
> #include
> #include
>
> +#define CLINT_MTIME_OFFSET 0xbff8
> +#define ACLINT_MTIME_OFFSET0
> +
> /* mtime register */
> -#define MTIME_REG(base)((ulong)(base) + 0xbff8)
> +#define MTIME_REG(base, offset)((ulong)(base) + (offset))
>
> static u64 notrace sifive_clint_get_count(struct udevice *dev) {
> - return readq((void __iomem *)MTIME_REG(dev_get_priv(dev)));
> + return readq((void __iomem *)MTIME_REG(dev_get_priv(dev),
> + dev_get_driver_data(dev)));
> }
>
> #if CONFIG_IS_ENABLED(RISCV_MMODE) && IS_ENABLED(CONFIG_TIMER_EARLY) @@
> -35,7 +39,8 @@ unsigned long notrace timer_early_get_rate(void)
> */
> u64 notrace timer_early_get_count(void) {
> - return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
> + return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE,
> + RISCV_MMODE_TIMEROFF));
> }
> #endif
>
> @@ -53,8 +58,9 @@ static int sifive_clint_probe(struct udevice *dev) }
>
> static const struct udevice_id sifive_clint_ids[] = {
> - { .compatible = "riscv,clint0" },
> - { .compatible = "sifive,clint0" },
> + { .compatible = "riscv,clint0", .data = CLINT_MTIME_OFFSET },
> + { .compatible = "sifive,clint0", .data = CLINT_MTIME_OFFSET },
> + { .compatible = "riscv,aclint-mtimer", .data = ACLINT_MTIME_OFFSET },
> { }
> };
>
> diff --git a/include/configs/ae350.h b/include/configs/ae350.h index
> b566ecf296..02c5c80215 100644
> --- a/include/configs/ae350.h
> +++ b/include/configs/ae350.h
> @@ -8,8 +8,8 @@
> #define __CONFIG_H
>
> #define RISCV_MMODE_TIMERBASE 0xe600
> +#define RISCV_MMODE_TIMEROFF0xbff8
Why add this for ae350 ?
> #define RISCV_MMODE_TIMER_FREQ 6000
> -
> #define RISCV_SMODE_TIMER_FREQ 6000
>
> /*
> diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
> index 20135f569e..f6d326bda0 100644
> --- a/include/configs/qemu-riscv.h
> +++ b/include/configs/qemu-riscv.h
> @@ -11,8 +11,8 @@
> #define CFG_SYS_SDRAM_BASE 0x8000
>
> #define RISCV_MMODE_TIMERBASE 0x200
> +#define RISCV_MMODE_TIMEROFF 0xbff8
> #define RISCV_MMODE_TIMER_FREQ 100
> -
> #define RISCV_SMODE_TIMER_FREQ 100
>
> /* Environment options */
> diff --git a/include/configs/sifive-unleashed.h
> b/include/configs/sifive-unleashed.h
> index de3a0dcdd5..f208f5e20d 100644
> --- a/include/configs/sifive-unleashed.h
> +++ b/include/configs/sifive-unleashed.h
> @@ -14,8 +14,8 @@
> #define CFG_SYS_SDRAM_BASE 0x8000
>
> #define RISCV_MMODE_TIMERBASE 0x200
> +#define RISCV_MMODE_TIMEROFF 0xbff8
> #define RISCV_MMODE_TIMER_FREQ 100
> -
> #define RISCV_SMODE_TIMER_FREQ 100
>
> /* Environment options */
> diff --git a/include/configs/starfive-visionfive2.h
> b/include/configs/starfive-visionfive2.h
> index 93dcc22d36..4ee02b8420 100644
> --- a/include/configs/starfive-visionfive2.h
> +++ b/include/configs/starfive-visionfive2.h
> @@ -9,6 +9,7 @@
> #define _STARFIVE_VISIONFIVE2_H
>
> #define RISCV_MMODE_TIMERBASE 0x200
> +#define RISCV_MMODE_TIMEROFF 0xbff8
> #define RISCV_MMODE_TIMER_FREQ 400
> #define RISCV_SMODE_TIMER_FREQ 400
Re: [PATCH v1 1/3] riscv: dts: drop microchip from dts filenames
> From: Conor Dooley
> Sent: Wednesday, June 07, 2023 6:06 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊)
> ; Padmarao Begari ;
> Conor Dooley
> Subject: [PATCH v1 1/3] riscv: dts: drop microchip from dts filenames
>
> The original names picked for the DT doesn't match Linux's naming scheme and
> it was renamed there a while ago. Rename it in U-Boot to allow easily syncing
> dts between the two projects.
>
> Signed-off-by: Conor Dooley
> ---
> arch/riscv/dts/Makefile | 2 +-
> ...s-icicle-kit-u-boot.dtsi => mpfs-icicle-kit-u-boot.dtsi} | 0
> .../{microchip-mpfs-icicle-kit.dts => mpfs-icicle-kit.dts} | 2 +-
> arch/riscv/dts/{microchip-mpfs.dtsi => mpfs.dtsi} | 0
> configs/microchip_mpfs_icicle_defconfig | 2 +-
> doc/board/microchip/mpfs_icicle.rst | 6 +++---
Reviewed-by: Rick Chen
Re: [RESEND PATCH v1] arch: riscv: jh7110: Correctly zero L2 LIM
> From: Bo Gan > Sent: Monday, June 12, 2023 7:59 AM > To: u-boot@lists.denx.de > Cc: Bo Gan ; samin . guo ; > Yanhong Wang ; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) ; Sean > Anderson ; Lukasz Majewski > Subject: [RESEND PATCH v1] arch: riscv: jh7110: Correctly zero L2 LIM > > Background information: > JH7110 SPL runs in L2 LIM (2M in size mapped at 0x800). It consists of > 16 0x2 sized regions, each one can be used as either L2 cache way or > SRAM (not both). From top to bottom, there're ways 0-15. The way 0 is always > enabled, at most 0x1e can be used. > > In SPL, we don't enable any cache ways, thus all 15 (except way 0) ways can > be used. However, due to HW requirement, we must zero the LIM before use. > This is because ECC is applied to LIM, and if not cleared first, the ECC part > is invalid, which can trigger ECC errors when reading/writing data. > > There are several issues currently. We clear L2 LIM from __bss_end to > 0x81F in `harts_early_init`. This is wrong because: > > a. Each hart (in the middle of a function call) overwriting its own > stack and other harts' stacks. > (data-race and data-corruption) > b. Lottery winner hart can be doing `board_init_f_init_reserve`, > while other harts're in the middle of zeroing L2 LIM. > (data-race) > > To fix this, we split the job, such that there's one and only one owner of > zeroing a specific region (No data-race). A new SPL config option > `SPL_ZERO_MEM_BEFORE_USE` is introduced. Allowing The zeroing to happen in > the same code path. (much easier to reason about). > > Another option `SPL_SYS_MALLOC_CLEAR_ON_INIT` also gets introduced. > It allows us to also zero late malloc (dlmalloc) area, in case it gets > configured to be inside L2 LIM (via `CUSTOM_SYS_SPL_MALLOC_ADDR`) We by > default enable it to be on the safe side. > > `CONFIG_SPL_STACK` is adjusted to reduce the waste of L2 LIM space. > When setting > > CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x810 > CONFIG_SYS_SPL_MALLOC_SIZE=0xe > > A 0.875M late malloc arena is available in L2 LIM. It's sufficient for > loading JH7110 FIT Image (gzip compressed OpenSBI+UBOOT+DTB). > The advantage of this config is allowing OpenSBI/UBOOT to be loaded at any > DDR memory address. By default the malloc arena is configured in DDR memory, > so OpenSBI/UBOOT loading address must not collide with it. > > CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000 (DDR +1GB) > CONFIG_SYS_SPL_MALLOC_SIZE=0x40 > > JH7110 SPL memory map (based on the following defconfig): > > CONFIG_NR_CPUS=8 > CONFIG_STACK_SIZE_SHIFT=14 > CONFIG_SPL_STACK=0x810 > CONFIG_SPL_SYS_MALLOC_F_LEN=0x1 > CONFIG_SPL_BSS_START_ADDR=0x804 > > ++ 0x81e > | Free | > || > ++ 0x810 > | hart 0 stack | <--- cleared by each hart (start.S) > ++ 0x80fc000 > | hart 1 stack |. > ++ 0x80f8000 . > | ..|. > ++ > | hart N-1 stack| <--- cleared by each hart (start.S) > ++ 0x80e > | ..| <--- cleared by lottery winner hart > | malloc_base | board_init_f_init_reserve() > ++ 0x80d > | GD| <--- cleared by lottery winner hart > ++ board_init_f_init_reserve() > || > | hole | > || > ++ > | BSS | <--- cleared by lottery winner hart > +----+ 0x804spl_clear_bss (start.S) > | hole | > ++ > | Image+DTB | <--- Assuming cleared/loaded by ROM > ++ 0x800 > > Signed-off-by: Bo Gan > Cc: samin . guo > Cc: Yanhong Wang > Cc: Rick Chen > Cc: Leo > Cc: Sean Anderson > Cc: Lukasz Majewski > --- > > v1: > - patch is on top of > https://patchwork.ozlabs.org/project/uboot/patch/1684650044-313122-1-git-send-email-ganbo...@gmail.com/ > - Tested on VisionFive 2 board (4G) > --- > Kconfig| 11 +++ > arch/riscv/Kconfig | 7 +++ > arch/riscv/cpu/jh7110/Kconfig | 2 ++ > arch/riscv/cpu/jh7110/spl.c| 25 - > arch/riscv/cpu/start.S | 12 > common/dlmalloc.c | 6 +++--- > common/init/board_init.c | 3 +++ > configs/starfive_visionfive2_defconfig | 3 ++- > 8 files changed, 40 insertions(+), 29 deletions(-) Please separate as several PATCHs, but not mix them as one PATCH Thanks, Rick
Re: [RESEND PATCH v2] riscv: setup per-hart stack earlier
> From: Bo Gan > Sent: Monday, June 12, 2023 7:54 AM > To: u-boot@lists.denx.de > Cc: Bo Gan ; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) ; Sean > Anderson ; Bin Meng ; Lukas Auer > > Subject: [RESEND PATCH v2] riscv: setup per-hart stack earlier > > Harts need to use per-hart stack before any function call, even if that > function is a simple one. When the callee uses stack for register save/ > restore, especially RA, if nested call, concurrent access by multiple harts > on the same stack will cause data-race. > > This patch sets up SP before `board_init_f_alloc_reserve`. A side effect of > this is that the memory layout has changed as the following: > > ++++ <- SPL_STACK/ > | ..|| hart 0 stack |SYS_INIT_SP_ADDR > | malloc_base |++ > ++| hart 1 stack | > | GD|++ If not SMP, N=1 > ++| ..| > | hart 0 stack |++ > ++ ==> | hart N-1 stack| > | hart 1 stack |++ > ++| ..| > | ..|| malloc_base | > ++++ > | hart N-1 stack|| GD| > +++----+ > |||| > > Signed-off-by: Bo Gan > Cc: Rick Chen > Cc: Leo > Cc: Sean Anderson > Cc: Bin Meng > Cc: Lukas Auer > --- > > v2: > - Fixed macro CONFIG_SYS_INIT_SP_ADDR -> SYS_INIT_SP_ADDR > - Tested SPL with VisionFive 2 board > --- > arch/riscv/cpu/start.S | 37 - > 1 file changed, 24 insertions(+), 13 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH v6 0/3] Add StarFive JH7110 PCIe drvier support
Hi Minda > From: Minda Chen > Sent: Thursday, June 01, 2023 9:07 AM > To: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; Simon Glass ; Stefan Roese > ; Andrew Scull ; Pali Rohár > ; Mark Kettenis > Cc: u-boot@lists.denx.de; Mason Huo ; Leyfoon Tan > ; Kevin Xie > Subject: Re: [PATCH v6 0/3] Add StarFive JH7110 PCIe drvier support > > > Hi Rick and Leo > Could you review these series patches? Thanks. > Since patch 1 was acked by Pali， Does it mean patch 1 is accepted？ OK, we will review these series patches ASAP and help to push. Thanks, Rick > > On 2023/5/9 16:26, Minda Chen wrote: > > These PCIe series patches are based on the JH7110 RISC-V SoC and VisionFive > > V2 board. > > > > The PCIe driver depends on gpio, pinctrl, clk and reset driver to do init. > > The PCIe dts configuation includes all these setting. > > > > The PCIe drivers codes has been tested on the VisionFive V2 boards. > > The test devices includes M.2 NVMe SSD and Realtek 8169 Ethernet adapter. > > > > previous patch version > > > > v1: > > https://patchwork.ozlabs.org/project/uboot/cover/20230223105240.15180- > > 1-minda.c...@starfivetech.com/ > > v2: > > https://patchwork.ozlabs.org/project/uboot/cover/20230308054833.95730- > > 1-minda.c...@starfivetech.com/ > > v3: > > https://patchwork.ozlabs.org/project/uboot/cover/20230329100143.10724- > > 1-minda.c...@starfivetech.com/ > > v4: > > https://patchwork.ozlabs.org/project/uboot/cover/20230411010209.76561- > > 1-minda.c...@starfivetech.com/ > > v5: > > https://patchwork.ozlabs.org/project/uboot/cover/20230423105859.125764 > > -1-minda.c...@starfivetech.com/ > > > > changes > > v6 > >patch 2 > > 1. Change one VisionFive2 config file. > >patch 3 > > 1. remove the pcie interrupt-controller. interrupts setting revert to > > origin. > > > > setting. > > v5 > >patch 1 > > 1. split PLDA controller driver codes to pcie_plda_common.c > > 2. correct the codes of record secondary number. > >patch 3 > > 1. change the pcie dtsi config. make them the same with kernel. > > > > v4 > >patch 1 > > 1. Remove the IDS_REVISION_ID macros. > > 2. Replace sec_busno to first_busno in starfive_pcie > > 3. Remove starfive_pcie_off_conf function. > > 4. Replace "imply" to "depends on" in PCIe Kconfig. > > 5 .Check sec_busno in starfive_pcie_addr_valid. > > > > v3 > >patch 1 > > 1. remove the read vendor ID delay > > 2. remove starfive_pcie_hide_rc_bar function. do not hide host > > bridge BAR write. > > 3. Using PCIE_ECAM_OFFSET and PCI_CLASS_BRIDGE_PCI_NORMAL macros. > > 4. Add comments for bus and address limitation reason in function > >starfive_pcie_addr_valid > > 5. Change the multiple line comments in Line 373 > > 6. Using gpio_request_by_name to get PCIe reset gpio,and using > >dm_gpio_set_value set GPIO value. > > patch 2 > > 1. support PCIeboth 12a and 13b vf2 board. > > patch 3 > > 1. reset dts change to reset-gpio. > > > > v2 > >1. remove clock commit. The pcie clocks change has been includeded in > > [1]. > >2. Using GENMASK marco1 in patch1. > >3. remove the syscon dts node in patch3. The syscon dts dts node has been > > included in [1]. > > > > > > Mason Huo (3): > > starfive: pci: Add StarFive JH7110 pcie driver > > configs: starfive-jh7110: Add support for PCIe host driver > > riscv: dts: starfive: Enable PCIe host controller > > > > .../dts/jh7110-starfive-visionfive-2.dtsi | 11 + > > arch/riscv/dts/jh7110.dtsi| 74 > > configs/starfive_visionfive2_defconfig| 10 + > > drivers/pci/Kconfig | 13 + > > drivers/pci/Makefile | 2 + > > drivers/pci/pcie_plda_common.c| 116 +++ > > drivers/pci/pcie_plda_common.h| 118 +++ > > drivers/pci/pcie_starfive_jh7110.c| 317 ++ > > 8 files changed, 661 insertions(+) > > create mode 100644 drivers/pci/pcie_plda_common.c create mode 100644 > > drivers/pci/pcie_plda_common.h create mode 100644 > > drivers/pci/pcie_starfive_jh7110.c > > > > > > base-commit: c9c2c95d4cd27fe0cd41fe13a863899d268f973c
Re: [PATCH] riscv: setup per-hart stack earlier
Hi Bo Gan, > From: Bo Gan > Sent: Tuesday, May 09, 2023 9:46 AM > To: u-boot@lists.denx.de > Cc: Bo Gan ; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) > Subject: [PATCH] riscv: setup per-hart stack earlier > > Harts need to use per-hart stack before any function call, even if that > function is a simple one. When the callee uses stack for register save/ > restore, especially RA, if nested call, concurrent access by multiple harts > on the same stack will cause data-race. > > This patch sets up SP before `board_init_f_alloc_reserve`. A side effect of > this is that the memory layout has changed as the following: > > ++++ <- SPL_STACK/ > | ..|| hart 0 stack |SYS_INIT_SP_ADDR > | malloc_base |++ > ++| hart 1 stack | > | GD|++ If not SMP, N=1 > ++| ..| > | hart 0 stack |++ > ++ ==> | hart N-1 stack| > | hart 1 stack |++ > ++| ..| > | ..|| malloc_base | > ++++ > | hart N-1 stack|| GD| > +++----+ > |||| > > Signed-off-by: Bo Gan > Cc: Rick Chen > Cc: Leo > --- > arch/riscv/cpu/start.S | 37 - > 1 file changed, 24 insertions(+), 13 deletions(-) > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index > dad22bf..90015c2 100644 > --- a/arch/riscv/cpu/start.S > +++ b/arch/riscv/cpu/start.S > @@ -91,16 +91,35 @@ _start: > * Set stackpointer in internal/ex RAM to call board_init_f > */ > call_board_init_f: > - li t0, -16 > #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) > - li t1, CONFIG_SPL_STACK > + li t0, CONFIG_SPL_STACK > #else > - li t1, SYS_INIT_SP_ADDR > + li t0, CONFIG_SYS_INIT_SP_ADDR It builds fail as below: arch/riscv/cpu/start.S:97: Error: illegal operands `li t0,CONFIG_SYS_INIT_SP_ADDR' Thanks, Rick
Re: [PATCH] riscv: Support riscv64 image type
Hi Simon, > Hi Rick, > > On Mon, 10 Apr 2023 at 01:26, Rick Chen wrote: > > > > Allow U-Boot to load 32 or 64 bits RISC-V Kernel Image > > distinguishly. It helps to avoid someone maybe make a mistake > > to run 32-bit U-Boot to load 64-bit kernel. > > > > Signed-off-by: Rick Chen > > > > --- > > The patchset is based on Simon's patch: > > riscv: Add a 64-bit image type > > --- > > --- > > arch/riscv/include/asm/u-boot.h | 4 > > cmd/booti.c | 2 +- > > 2 files changed, 5 insertions(+), 1 deletion(-) > > Reviewed-by: Simon Glass > > I don't know much about RISC-V, but I assume U-Boot is able to do this > successfully? Does it not need to switch modes first? No, it is not need to switch modes as far as I know. Here only provide a check mechanism just like arm to see if loader and OS are match But This patch is for bootm flow. Maybe I still need to check if it is necessary to prepare a patch for binman flow ? /arch/riscv/dts/binman.dtsi arch = "riscv"; maybe provide another binman64.dtsi for arch="riscv64" Thanks, Rick > > Regards, > Simon
Re: [PATCH 7/8] riscv: spl: Remove relocation sections
> From: Bin Meng
> Sent: Thursday, March 30, 2023 12:20 PM
> To: u-boot@lists.denx.de
> Cc: Andrew Scull ; Leo Yu-Chi Liang(梁育齊)
> ; Rick Jian-Zhi Chen(陳建志) ; Simon
> Glass
> Subject: [PATCH 7/8] riscv: spl: Remove relocation sections
>
> U-Boot SPL is not relocable. Drop these relocation sections.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/riscv/cpu/u-boot-spl.lds | 25 -
> 1 file changed, 25 deletions(-)
>
> diff --git a/arch/riscv/cpu/u-boot-spl.lds b/arch/riscv/cpu/u-boot-spl.lds
> index 993536302a..c3b4907905 100644
> --- a/arch/riscv/cpu/u-boot-spl.lds
> +++ b/arch/riscv/cpu/u-boot-spl.lds
> @@ -32,14 +32,6 @@ SECTIONS
> } > .spl_mem
> . = ALIGN(4);
>
> - .got : {
> - __got_start = .;
> - *(.got.plt) *(.got)
> - __got_end = .;
> - } > .spl_mem
> -
> - . = ALIGN(4);
> -
> __u_boot_list : {
> KEEP(*(SORT(__u_boot_list*)));
> } > .spl_mem
> @@ -54,23 +46,6 @@ SECTIONS
>
> . = ALIGN(4);
>
> - /DISCARD/ : { *(.rela.plt*) }
> - .rela.dyn : {
> - __rel_dyn_start = .;
> - *(.rela*)
> - __rel_dyn_end = .;
> - } > .spl_mem
This patch will cause u-boot-spl build fail:
...
LD spl/u-boot-spl
riscv64-linux-ld.bfd: arch/riscv/cpu/start.o: in function `fix_rela_dyn':
/home/u-boot-riscv/arch/riscv/cpu/start.S:299: undefined reference to
`__rel_dyn_start'
riscv64-linux-ld.bfd: arch/riscv/cpu/start.o: in function `.L0 ':
Thanks,
Rick
> -
> - . = ALIGN(4);
> -
> - .dynsym : {
> - __dyn_sym_start = .;
> - *(.dynsym)
> - __dyn_sym_end = .;
> - } > .spl_mem
> -
> - . = ALIGN(4);
> -
> _end = .;
> _image_binary_end = .;
>
> --
> 2.34.1
[PATCH] riscv: Support riscv64 image type
Allow U-Boot to load 32 or 64 bits RISC-V Kernel Image distinguishly. It helps to avoid someone maybe make a mistake to run 32-bit U-Boot to load 64-bit kernel. Signed-off-by: Rick Chen --- The patchset is based on Simon's patch: riscv: Add a 64-bit image type --- --- arch/riscv/include/asm/u-boot.h | 4 cmd/booti.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/u-boot.h b/arch/riscv/include/asm/u-boot.h index d5e1d5f323..e3b4a0357c 100644 --- a/arch/riscv/include/asm/u-boot.h +++ b/arch/riscv/include/asm/u-boot.h @@ -23,6 +23,10 @@ #include /* For image.h:image_check_target_arch() */ +#ifdef CONFIG_ARCH_RV64I +#define IH_ARCH_DEFAULT IH_ARCH_RISCV64 +#else #define IH_ARCH_DEFAULT IH_ARCH_RISCV +#endif #endif /* _U_BOOT_H_ */ diff --git a/cmd/booti.c b/cmd/booti.c index 6ac39193db..dc0b0ae41c 100644 --- a/cmd/booti.c +++ b/cmd/booti.c @@ -119,7 +119,7 @@ int do_booti(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) images.os.os = IH_OS_LINUX; #ifdef CONFIG_RISCV_SMODE - images.os.arch = IH_ARCH_RISCV; + images.os.arch = IH_ARCH_DEFAULT; #elif CONFIG_ARM64 images.os.arch = IH_ARCH_ARM64; #endif -- 2.17.1
Re: [PATCH] riscv: Add a 64-bit image type
> From: Simon Glass > Sent: Monday, April 03, 2023 4:28 AM > To: U-Boot Mailing List > Cc: Sean Anderson ; Bin Meng ; Rick > Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; Simon Glass ; Andre Przywara > ; Marc Kleine-Budde ; SESA644425 > ; Samuel Holland ; Steven > Lawrance > Subject: [PATCH] riscv: Add a 64-bit image type > > At present it is not possible to know whether an image can be booted by a 32- > or 64-bit bootloader. This means that U-Boot may attempt to boot the wrong > image. This may cause a crash which might be hard to debug. > > Add a new property to make this explicit. > > The existing 'RISC-V' is now taken to mean 32-bit. > > Signed-off-by: Simon Glass > --- > > boot/image.c| 3 ++- > include/image.h | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH 5/8] makefile: riscv: Drop useless argument of prelink-riscv
> From: U-Boot On Behalf Of Bin Meng > Sent: Thursday, March 30, 2023 12:20 PM > To: u-boot@lists.denx.de > Cc: Heinrich Schuchardt ; Kever Yang > ; Marek Behún ; Pali Rohár > ; Quentin Schulz ; > Simon Glass > Subject: [PATCH 5/8] makefile: riscv: Drop useless argument of prelink-riscv > > The argv[2] is never used in prelink-riscv. Drop it. > > Signed-off-by: Bin Meng > --- > > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Rick Chen
Re: [PATCH 4/8] tools: prelink-riscv: Unmap the ELF image when done
> From: Bin Meng > Sent: Thursday, March 30, 2023 12:20 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > > Subject: [PATCH 4/8] tools: prelink-riscv: Unmap the ELF image when done > > The codes forget to call munmap() to unmap the ELF image that was mapped by > previous mmap(). > > Signed-off-by: Bin Meng > --- > > tools/prelink-riscv.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH 3/8] tools: prelink-riscv: Cosmetic style fixes
> From: U-Boot On Behalf Of Bin Meng > Sent: Thursday, March 30, 2023 12:20 PM > To: u-boot@lists.denx.de > Subject: [PATCH 3/8] tools: prelink-riscv: Cosmetic style fixes > > Some coding convention fixes. > > Signed-off-by: Bin Meng > --- > > tools/prelink-riscv.inc | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH 2/8] riscv: Optimize loading relocation type
> From: Bin Meng > Sent: Thursday, March 30, 2023 12:20 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Nikita Shubin > ; Rick Jian-Zhi Chen(陳建志) > Subject: [PATCH 2/8] riscv: Optimize loading relocation type > > 't5' already contains relocation type so don't bother reloading it. > > Signed-off-by: Bin Meng > --- > > arch/riscv/cpu/start.S | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Rick Chen
Re: [PATCH 1/8] riscv: Optimize source end address calculation in start.S
> From: Bin Meng > Sent: Thursday, March 30, 2023 12:20 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Nikita Shubin > ; Rick Jian-Zhi Chen(陳建志) > Subject: [PATCH 1/8] riscv: Optimize source end address calculation in start.S > > The __bss_start is the source end address hence load its address directly > into register 't2' for optimization. > > Signed-off-by: Bin Meng > --- > > arch/riscv/cpu/start.S | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH] riscv: Correct a comment in io.h
> From: Bin Meng > Sent: Monday, April 03, 2023 11:38 AM > To: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > > Cc: u-boot@lists.denx.de > Subject: [PATCH] riscv: Correct a comment in io.h > > Replace NDS32 with RISC-V in the comments. > > Signed-off-by: Bin Meng > --- > > arch/riscv/include/asm/io.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h index > 220266e76f..b16e6dfa37 100644 > --- a/arch/riscv/include/asm/io.h > +++ b/arch/riscv/include/asm/io.h > @@ -180,7 +180,7 @@ static inline u64 readq(const volatile void __iomem *addr) > * IO port access primitives > * - > * > - * The NDS32 doesn't have special IO access instructions just like ARM; > + * The RISC-V doesn't have special IO access instructions just like > + ARM; > * all IO is memory mapped. > * Note that these are defined to perform little endian accesses > * only. Their primary purpose is to access PCI and ISA peripherals. Reviewed-by: Rick Chen
Re: Boot from 64-bit memory address?
Hi Philip, > From: U-Boot On Behalf Of Bernard, Philip > Sent: Thursday, February 23, 2023 9:21 AM > To: u-boot@lists.denx.de > Subject: Boot from 64-bit memory address? > > Hi, > > Is it possible to boot from a DRAM memory address beyond the 32-bit boundary? > I'm trying to configure a new RISC-V board which has 2GB of DRAM starting at > offset 0x40__. I started from the settings for an existing RISC-V > board and made I think it is possible to boot from a DRAM memory beyond the 32-bit boundary. But maybe you need to modify some code to achieve that. I have tried to boot an internal AE350-like platform whose DRAM base is at 0x4. adjustments for my HW, but when I try to boot, I run into an "out of memory" error. > > From > https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html#tables > I noticed that U-Boot will only use "conventional" memory which is 4GB and > below, so it seems like this may not be possible? Looking through the repo, I > also noticed that nearly every device is configuring settings like > CONFIG_SYS_LOAD_ADDR with a 32-bit value, so I haven't found any examples to > emulate for my use case. CONFIG_SYS_LOAD_ADDR is not important. Maybe you shall notice CONFIG_SYS_TEXT_BASE and CONFIG_SPL_OPENSBI_LOAD_ADDR which will be parsed from binman.dtsi You can change them like this: load = /bits/64 ; load = /bits/64 ; > > I'm hoping someone knows the mistake I'm making or can confirm that this > isn't possible. Appreciate the help. > > Best, > Phil > > > Below is the output from U-Boot: > > U-Boot SPL 2022.07 (Feb 23 2023 - 00:50:44 +) Trying to boot from RAM > > OpenSBI v1.1 >_ _ > / __ \ / | _ \_ _| > | | | |_ __ ___ _ __ | (___ | |_) || | > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | __| | |_) | __/ | | |) | > | ||_) || |_ > \/| .__/ \___|_| |_|_/|/_| > | | > |_| > > Platform Name : test,test > Platform Features : medeleg > Platform HART Count : 1 > Platform IPI Device : aclint-mswi > Platform Timer Device : aclint-mtimer @ 100Hz > Platform Console Device : uart8250 > Platform HSM Device : --- > Platform Reboot Device: --- > Platform Shutdown Device : --- > Firmware Base : 0x8000 > Firmware Size : 276 KB > Runtime SBI Version : 1.0 > > Domain0 Name : root > Domain0 Boot HART : 0 > Domain0 HARTs : 0* > Domain0 Region00 : 0x0200-0x0200 (I) > Domain0 Region01 : 0x8000-0x8007 () > Domain0 Region02 : 0x-0x (R,W,X) > Domain0 Next Address : 0x00400120 > Domain0 Next Arg1 : 0x004001267830 > Domain0 Next Mode : S-mode > Domain0 SysReset : yes > > Boot HART ID : 0 > Boot HART Domain : root > Boot HART Priv Version: v1.10 > Boot HART Base ISA: rv64imafdcb > Boot HART ISA Extensions : time > Boot HART PMP Count : 8 > Boot HART PMP Granularity : 4 > Boot HART PMP Address Bits: 54 > Boot HART MHPM Count : 0 > Boot HART MIDELEG : 0x0222 > Boot HART MEDELEG : 0xb109 > > > U-Boot 2022.07 (Feb 23 2023 - 00:50:44 +) > > CPU: rv64imafdc > Model: test,test > DRAM: 2 GiB > Core: 11 devices, 8 uclasses, devicetree: separate > ERROR: Out of memory > Loading Environment from nowhere... OK > In:serial@13140 > Out: serial@13140 > Err: serial@13140 > Model: test,test > Net: No ethernet found. > Hit any key to stop autoboot: 0 > Moving Image from 0x400600 to 0x400020, end=4000b01c8c ## Flattened > Device Tree blob at ff76a1d0 >Booting using the fdt blob at 0xff76a1d0 > ERROR: Failed to allocate 0x100 bytes below 0x1. Can you dig in where to print this ERROR ? Thanks, Rick > ramdisk - allocation error
[PATCH v2] riscv: binman: Add help message for missing blobs
Add the 'missing-msg' for more detailed output
on missing system firmware.
Signed-off-by: Rick Chen
Reviewed-by: Leo Yu-Chi Liang
---
Changes in v2
- Add more descriptions about fw_dynamic.bin
---
arch/riscv/dts/binman.dtsi | 1 +
tools/binman/missing-blob-help | 6 ++
2 files changed, 7 insertions(+)
diff --git a/arch/riscv/dts/binman.dtsi b/arch/riscv/dts/binman.dtsi
index b8fc8f7f35..156cb00971 100644
--- a/arch/riscv/dts/binman.dtsi
+++ b/arch/riscv/dts/binman.dtsi
@@ -45,6 +45,7 @@
opensbi_blob: opensbi {
filename = "fw_dynamic.bin";
+ missing-msg = "opensbi";
};
};
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index c61ca02a35..4448ac9311 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -37,3 +37,9 @@ https://github.com/siemens/k3-rti-wdt.
tee-os:
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) with TEE=/path/to/tee.bin
+
+opensbi:
+See the documentation for your board. The OpenSBI git repo is at
+https://github.com/riscv/opensbi.git
+You may need to build fw_dynamic.bin first and re-build u-boot with
+OPENSBI=/path/to/fw_dynamic.bin
--
2.17.1
Re: [PATCH] riscv: binman: Add help message for missing blobs
Hi Leo
> On Thu, Feb 16, 2023 at 09:19:45AM +0800, Rick Chen wrote:
> > Add the 'missing-msg' for more detailed output
> > on missing system firmware.
> >
> > Signed-off-by: Rick Chen
> > ---
> > arch/riscv/dts/binman.dtsi | 1 +
> > tools/binman/missing-blob-help | 4
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/arch/riscv/dts/binman.dtsi b/arch/riscv/dts/binman.dtsi
> > index b8fc8f7f35..156cb00971 100644
> > --- a/arch/riscv/dts/binman.dtsi
> > +++ b/arch/riscv/dts/binman.dtsi
> > @@ -45,6 +45,7 @@
> >
> > opensbi_blob: opensbi {
> > filename = "fw_dynamic.bin";
> > + missing-msg = "opensbi";
> > };
> > };
> >
> > diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
> > index c61ca02a35..654ad642a3 100644
> > --- a/tools/binman/missing-blob-help
> > +++ b/tools/binman/missing-blob-help
> > @@ -37,3 +37,7 @@ https://github.com/siemens/k3-rti-wdt.
> > tee-os:
> > See the documentation for your board. You may need to build Open Portable
> > Trusted Execution Environment (OP-TEE) with TEE=/path/to/tee.bin
> > +
> > +opensbi:
> > +See the documentation for your board. The OpenSBI git repo is at
> > +https://github.com/riscv/opensbi.git
> Hi Rick,
>
> Could we add something like
> "build fw_dynamic.bin first and re-build u-boot with
> OPENSBI=/path/to/fw_dynamic.bin"
OK.
Thanks,
Rick
>
> Other than that,
> Reviewed-by: Leo Yu-Chi Liang
>
> > --
> > 2.17.1
> >
Re: [RFC PATCH v3] doc: arch: Add document for RISC-V architecture
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Tuesday, February 14, 2023 6:19 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; s...@chromium.org; xypron.g...@gmx.de; Peter Yu-Chien > Lin(林宇謙) ; Samuel Holland > Subject: [RFC PATCH v3] doc: arch: Add document for RISC-V architecture > > This patch adds a brief introduction to the RISC-V architecture and the > typical boot process used on a variety of RISC-V platforms. > > Signed-off-by: Yu Chien Peter Lin > Reviewed-by: Samuel Holland > Reviewed-by: Simon Glass > --- > Changes v1 -> v2 > - Use 'boot phases' rather than 'boot stages' > - Pick up Samuel and Simon's RB tags > Changes v2 -> v3 > - Follow the suggestion by Heinrich [1] > - Add the document as an entry of Andes maintainer in MAINTAINERS > - Add some pointers to OpenSBI document > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20230212070053.14800-1-peter...@andestech.com/ > --- > MAINTAINERS| 1 + > doc/arch/index.rst | 1 + > doc/arch/riscv.rst | 74 ++ > 3 files changed, 76 insertions(+) > create mode 100644 doc/arch/riscv.rst Reviewed-by: Rick Chen
[PATCH] riscv: binman: Add help message for missing blobs
Add the 'missing-msg' for more detailed output
on missing system firmware.
Signed-off-by: Rick Chen
---
arch/riscv/dts/binman.dtsi | 1 +
tools/binman/missing-blob-help | 4
2 files changed, 5 insertions(+)
diff --git a/arch/riscv/dts/binman.dtsi b/arch/riscv/dts/binman.dtsi
index b8fc8f7f35..156cb00971 100644
--- a/arch/riscv/dts/binman.dtsi
+++ b/arch/riscv/dts/binman.dtsi
@@ -45,6 +45,7 @@
opensbi_blob: opensbi {
filename = "fw_dynamic.bin";
+ missing-msg = "opensbi";
};
};
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index c61ca02a35..654ad642a3 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -37,3 +37,7 @@ https://github.com/siemens/k3-rti-wdt.
tee-os:
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) with TEE=/path/to/tee.bin
+
+opensbi:
+See the documentation for your board. The OpenSBI git repo is at
+https://github.com/riscv/opensbi.git
--
2.17.1
Re: [PATCH 2/2] riscv: ae350: Adjust the memory layout of ae350
> From: Leo Yu-Chi Liang(梁育齊) > Sent: Thursday, February 09, 2023 4:34 PM > To: u-boot@lists.denx.de > Cc: Rick Jian-Zhi Chen(陳建志) ; Peter Yu-Chien Lin(林宇謙) > ; Leo Yu-Chi Liang(梁育齊) > Subject: [PATCH 2/2] riscv: ae350: Adjust the memory layout of ae350 > > Signed-off-by: Leo Yu-Chi Liang > --- > configs/ae350_rv32_spl_defconfig | 6 +++--- > configs/ae350_rv32_spl_xip_defconfig | 6 +++--- > configs/ae350_rv64_spl_defconfig | 6 +++--- > configs/ae350_rv64_spl_xip_defconfig | 6 +++--- > 4 files changed, 12 insertions(+), 12 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH 1/2] riscv: Rename Andes cpu and board names
> From: Leo Yu-Chi Liang(梁育齊) > Sent: Thursday, February 09, 2023 4:34 PM > To: u-boot@lists.denx.de > Cc: Rick Jian-Zhi Chen(陳建志) ; Peter Yu-Chien Lin(林宇謙) > ; Leo Yu-Chi Liang(梁育齊) > Subject: [PATCH 1/2] riscv: Rename Andes cpu and board names > > The current ae350-related defconfigs could also support newer Andes CPU IP, > so modify the names of CPU from ax25 to andesv5, and board name from > ax25-ae350 to ae350. > > Signed-off-by: Leo Yu-Chi Liang Reviewed-by: Rick Chen
Re: [PATCH v3 3/3] net: ftmac100: add mii read and write callbacks
> From: U-Boot On Behalf Of Sergei Antonov > Sent: Saturday, February 04, 2023 3:09 AM > To: u-boot@lists.denx.de; rfried@gmail.com; joe.hershber...@ni.com > Cc: Sergei Antonov > Subject: [PATCH v3 3/3] net: ftmac100: add mii read and write callbacks > > Register mii_bus with read and write callbacks to allow the 'mii' > command to work. Use a timeout of 10 ms to wait for the R/W operations to > complete. > > Signed-off-by: Sergei Antonov > --- Reviewed-by: Rick Chen Tested-by: Rick Chen I have verified this patch on AE350 platform and it work well with dhcp command as below: U-Boot 2023.04-rc1-00032-gf9f161b600-dirty (Feb 09 2023 - 10:55:03 +0800) DRAM: 1 GiB Core: 16 devices, 12 uclasses, devicetree: board Flash: 64 MiB MMC: Loading Environment from SPIFlash... SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB OK In:serial@f030 Out: serial@f030 Err: serial@f030 Net: no alias for ethernet0 eth0: mac@e010 Hit any key to stop autoboot: 0 RISC-V # RISC-V # dhcp 0x0600 10.0.12.60:Image-518 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.0.12.91 (280 ms) Using mac@e010 device TFTP from server 10.0.12.60; our IP address is 10.0.12.91 Filename 'Image-518'. Load address: 0x600 Loading: # # # # # # # # # # # # # # ### 300.8 KiB/s done Bytes transferred = 14098060 (d71e8c hex) RISC-V # mii device MII devices: 'eth0' Current device: 'eth0' RISC-V # mii info PHY 0x00: OUI = 0x606E, Model = 0x0B, Rev = 0x01, 100baseT, FDX RISC-V #
Re: [PATCH v3 2/3] net: ftmac100: simplify priv->iobase casting
> From: U-Boot On Behalf Of Sergei Antonov > Sent: Saturday, February 04, 2023 3:09 AM > To: u-boot@lists.denx.de; rfried@gmail.com; joe.hershber...@ni.com > Cc: Sergei Antonov > Subject: [PATCH v3 2/3] net: ftmac100: simplify priv->iobase casting > > Replace 'phys_addr_t iobase' with 'struct ftmac100 *ftmac100' in struct > ftmac100_data. It allows to remove casting in a number of places. > > Since priv->iobase is phys_addr_t, use phys_to_virt() to make a pointer from > it. > > Signed-off-by: Sergei Antonov Reviewed-by: Rick Chen
Re: [PATCH v3 1/3] net: ftmac100: change driver name from nds32_mac to ftmac100
> From: U-Boot On Behalf Of Sergei Antonov > Sent: Saturday, February 04, 2023 3:09 AM > To: u-boot@lists.denx.de; rfried@gmail.com; joe.hershber...@ni.com > Cc: Sergei Antonov > Subject: [PATCH v3 1/3] net: ftmac100: change driver name from nds32_mac to > ftmac100 > > So it will be named similarly to the related ftgmac100 driver. > The old name 'nds32_mac' is not referred to anywhere in U-Boot. > > Signed-off-by: Sergei Antonov > Reviewed-by: Ramon Fried Reviewed-by: Rick Chen
Re: Docs for RISC-V
Hi Zong, > From: Leo Yu-Chi Liang(梁育齊) > Sent: Monday, February 06, 2023 3:58 PM > To: Simon Glass > Cc: U-Boot Mailing List ; Rick Jian-Zhi Chen(陳建志) > ; zong...@sifive.com; vincent.c...@sifive.com > Subject: Re: Docs for RISC-V > > Hi Simon, > > On Thu, Feb 02, 2023 at 10:25:36AM -0700, Simon Glass wrote: > > Hi, > > > > On Thu, 2 Feb 2023 at 10:18, Simon Glass wrote: > > > > > > Hi Rick & Leo, > > > > > > I see docs for one board at [1] but I'm not sure what to do with > > > unleashed. > > > > > > It seems to need a 'genimage' tool, going on what I see in CI. Would you please take a look at this item ? Thanks, Rick > > > > > It does seem like that accroding to "sifive_unleashed_sdcard test.py". > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/568342) > > > > Could you adjust it to use binman to output an image suitable for > > > writing to an SD card in a single 'dd' step, as Rockchip does? > > > > > I think I will both take a look at it and forward this message to guys at > sifive. > > > > Also, how about adding a RISC-V section here? > > > > > > https://u-boot.readthedocs.io/en/latest/arch/index.html > > > > > Sounds great! > I will reference what other architectures have and create a RISC-V section. > > > > > Also I notice that this is incorrect: > > > > https://u-boot.readthedocs.io/en/latest/board/sifive/unleashed.html?hi > > ghlight=fw_dynamic.bin > > > > since 'make PLATFORM=generic' gives errors. I think it needs > > CROSS_COMPILE > > > > There is already an 'export CROSS_COMPILE' in the previous "building" section > before 'make PLATFROM=generic', so I guess that is why CROSS_COMPILE is > omitted in make command. > > > One other thing...binman output is this: > > > > binman: Filename 'fw_dynamic.bin' not found in input path (...) > > > > You should add something to tools/binman/missing-blob-help so that it > > tells the user where to find the blob. > > > > Same as the above, I will forward this to guys at sifive to see what they > would like to do. > > > Thanks for all the catches! > Best regards, > Leo > > > Thanks again, > > Simon > > > > > Thanks, > > > Simon > > > > > > [1] > > > https://u-boot.readthedocs.io/en/latest/board/sifive/unmatched.html
Re: [PATCH v2 09/10] configs: ae350: Display CPU and board info for AE350 platforms
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Monday, February 06, 2023 4:11 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; prabhakar.cse...@gmail.com; Peter Yu-Chien Lin(林宇謙) > > Subject: [PATCH v2 09/10] configs: ae350: Display CPU and board info for > AE350 platforms > > Display information about CPU and board during start up. > > Signed-off-by: Yu Chien Peter Lin > Reviewed-by: Leo Yu-Chi Liang > --- > configs/ae350_rv32_defconfig | 2 ++ > configs/ae350_rv32_spl_defconfig | 2 ++ > configs/ae350_rv32_spl_xip_defconfig | 2 ++ > configs/ae350_rv32_xip_defconfig | 2 ++ > configs/ae350_rv64_defconfig | 2 ++ > configs/ae350_rv64_spl_defconfig | 2 ++ > configs/ae350_rv64_spl_xip_defconfig | 2 ++ > configs/ae350_rv64_xip_defconfig | 2 ++ > 8 files changed, 16 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v2 07/10] configs: ae350: Enable v5l2 cache for AE350 platforms in SPL
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Monday, February 06, 2023 4:11 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; prabhakar.cse...@gmail.com; Peter Yu-Chien Lin(林宇謙) > > Subject: [PATCH v2 07/10] configs: ae350: Enable v5l2 cache for AE350 > platforms in SPL > > To reduce the code size, CONFIG_V5L2_CACHE was disabled since commit: > ca06444aac2c643db3a3f2eb37afc60fae15177e > > Turing on does not significantly increase the size of u-boot-spl.bin, so we > enable it by default to improve performance. > > Signed-off-by: Yu Chien Peter Lin > Reviewed-by: Leo Yu-Chi Liang > --- > arch/riscv/cpu/ax25/Kconfig | 1 + > configs/ae350_rv32_spl_defconfig | 2 ++ > configs/ae350_rv32_spl_xip_defconfig | 2 ++ > configs/ae350_rv64_spl_defconfig | 2 ++ > configs/ae350_rv64_spl_xip_defconfig | 2 ++ > 5 files changed, 9 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v2 06/10] riscv: ax25: cache.c: Cleanups to L1/L2 cache function used in SPL
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Monday, February 06, 2023 4:11 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; prabhakar.cse...@gmail.com; Peter Yu-Chien Lin(林宇謙) > > Subject: [PATCH v2 06/10] riscv: ax25: cache.c: Cleanups to L1/L2 cache > function used in SPL > > This patch refines L1 cache enable/disable and v5l2-cache enable functions. > > Signed-off-by: Yu Chien Peter Lin > Reviewed-by: Leo Yu-Chi Liang > --- > arch/riscv/cpu/ax25/cache.c | 98 + > 1 file changed, 68 insertions(+), 30 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH v2 05/10] riscv: ae350: dts: Update L2 cache compatible string
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Monday, February 06, 2023 4:11 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; prabhakar.cse...@gmail.com; Peter Yu-Chien Lin(林宇謙) > > Subject: [PATCH v2 05/10] riscv: ae350: dts: Update L2 cache compatible string > > Update the compatible string of L2 cache. > > Signed-off-by: Yu Chien Peter Lin > Reviewed-by: Leo Yu-Chi Liang > --- > arch/riscv/dts/ae350_32.dts | 2 +- > arch/riscv/dts/ae350_64.dts | 2 +- > drivers/cache/cache-v5l2.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH v2 04/10] riscv: cpu: ax25: Simplify cache enabling logic in harts_early_init()
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Monday, February 06, 2023 4:11 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; prabhakar.cse...@gmail.com; Peter Yu-Chien Lin(林宇謙) > > Subject: [PATCH v2 04/10] riscv: cpu: ax25: Simplify cache enabling logic in > harts_early_init() > > As the OpenSBI v1.2 does not enable the cache [0], we enable the i/d-cache in > harts_early_init() and do not disable in cleanup_before_linux(). This patch > also simplifies the logic and moves the CSR encoding to > include/asm/arch-andes/csr.h. > > [0] > https://github.com/riscv-software-src/opensbi/commit/bd7ef4139829da5c30fa980f7498d385124408fa > > Signed-off-by: Yu Chien Peter Lin > Reviewed-by: Leo Yu-Chi Liang > --- > arch/riscv/cpu/ax25/cpu.c | 49 ++--- > arch/riscv/include/asm/arch-andes/csr.h | 29 +++ > 2 files changed, 41 insertions(+), 37 deletions(-) create mode 100644 > arch/riscv/include/asm/arch-andes/csr.h Reviewed-by: Rick Chen
Re: [PATCH v2 03/10] driver: cache: cache-v5l2: Update memory-mapped scheme to support Gen2 platform
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Monday, February 06, 2023 4:11 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; prabhakar.cse...@gmail.com; Peter Yu-Chien Lin(林宇謙) > > Subject: [PATCH v2 03/10] driver: cache: cache-v5l2: Update memory-mapped > scheme to support Gen2 platform > > The L2C configuration register has MAP field to indicate its version is v0 > (Gen1) or v1 (Gen2) L2-cache. This patch makes the driver compatible with > both memory-mapped scheme. > > Signed-off-by: Yu Chien Peter Lin > Reviewed-by: Leo Yu-Chi Liang > --- > drivers/cache/cache-v5l2.c | 32 > 1 file changed, 24 insertions(+), 8 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH 08/11] configs: ae350: Enable v5l2 cache for AE350 platforms
Hi Peter, > From: Peter Yu-Chien Lin(林宇謙) > Sent: Thursday, January 19, 2023 3:06 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; Peter Yu-Chien Lin(林宇謙) > Subject: [PATCH 08/11] configs: ae350: Enable v5l2 cache for AE350 platforms > > Enable cache-v5l2 driver for each AE350 defconfig. Please refer to commit ca06444aac2c643db3a3f2eb37afc60fae15177e and describe why it shall be enabled currently. And it can be enabled by imply in Kconfig. Thanks, Rick > > Signed-off-by: Yu Chien Peter Lin > --- > configs/ae350_rv32_defconfig | 1 + > configs/ae350_rv32_spl_defconfig | 3 +++ > configs/ae350_rv32_spl_xip_defconfig | 3 +++ > configs/ae350_rv32_xip_defconfig | 1 + > configs/ae350_rv64_defconfig | 1 + > configs/ae350_rv64_spl_defconfig | 3 +++ > configs/ae350_rv64_spl_xip_defconfig | 3 +++ > configs/ae350_rv64_xip_defconfig | 1 + > 8 files changed, 16 insertions(+) > > diff --git a/configs/ae350_rv32_defconfig b/configs/ae350_rv32_defconfig > index e5c8358e54..5bcc7b9526 100644 > --- a/configs/ae350_rv32_defconfig > +++ b/configs/ae350_rv32_defconfig > @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_BOOTP_SEND_HOSTNAME=y > CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_V5L2_CACHE=y > CONFIG_MMC=y > CONFIG_FTSDC010=y > CONFIG_FTSDC010_SDIO=y > diff --git a/configs/ae350_rv32_spl_defconfig > b/configs/ae350_rv32_spl_defconfig > index a66db65621..688c2c15cd 100644 > --- a/configs/ae350_rv32_spl_defconfig > +++ b/configs/ae350_rv32_spl_defconfig > @@ -22,6 +22,8 @@ CONFIG_BOOTDELAY=3 > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_MAX_SIZE=0x10 > CONFIG_SPL_BSS_START_ADDR=0x400 > +CONFIG_SPL_BOARD_INIT=y > +CONFIG_SPL_CACHE=y > CONFIG_SYS_PBSIZE=1050 > CONFIG_SYS_BOOTM_LEN=0x400 > CONFIG_CMD_IMLS=y > @@ -34,6 +36,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_BOOTP_SEND_HOSTNAME=y CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_V5L2_CACHE=y > CONFIG_MMC=y > CONFIG_FTSDC010=y > CONFIG_FTSDC010_SDIO=y > diff --git a/configs/ae350_rv32_spl_xip_defconfig > b/configs/ae350_rv32_spl_xip_defconfig > index 606962c0a7..07bef47e42 100644 > --- a/configs/ae350_rv32_spl_xip_defconfig > +++ b/configs/ae350_rv32_spl_xip_defconfig > @@ -23,6 +23,8 @@ CONFIG_BOOTDELAY=3 > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_MAX_SIZE=0x10 > CONFIG_SPL_BSS_START_ADDR=0x400 > +CONFIG_SPL_BOARD_INIT=y > +CONFIG_SPL_CACHE=y > CONFIG_SYS_PBSIZE=1050 > CONFIG_SYS_BOOTM_LEN=0x400 > CONFIG_CMD_IMLS=y > @@ -35,6 +37,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_BOOTP_SEND_HOSTNAME=y CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_V5L2_CACHE=y > CONFIG_MMC=y > CONFIG_FTSDC010=y > CONFIG_FTSDC010_SDIO=y > diff --git a/configs/ae350_rv32_xip_defconfig > b/configs/ae350_rv32_xip_defconfig > index 069a9d3982..235a496c58 100644 > --- a/configs/ae350_rv32_xip_defconfig > +++ b/configs/ae350_rv32_xip_defconfig > @@ -29,6 +29,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_BOOTP_SEND_HOSTNAME=y > CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_V5L2_CACHE=y > CONFIG_MMC=y > CONFIG_FTSDC010=y > CONFIG_FTSDC010_SDIO=y > diff --git a/configs/ae350_rv64_defconfig b/configs/ae350_rv64_defconfig > index c373b99b95..af23f27ade 100644 > --- a/configs/ae350_rv64_defconfig > +++ b/configs/ae350_rv64_defconfig > @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_BOOTP_SEND_HOSTNAME=y > CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_V5L2_CACHE=y > CONFIG_MMC=y > CONFIG_FTSDC010=y > CONFIG_FTSDC010_SDIO=y > diff --git a/configs/ae350_rv64_spl_defconfig > b/configs/ae350_rv64_spl_defconfig > index f235db7990..295b56835f 100644 > --- a/configs/ae350_rv64_spl_defconfig > +++ b/configs/ae350_rv64_spl_defconfig > @@ -22,6 +22,8 @@ CONFIG_BOOTDELAY=3 > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_MAX_SIZE=0x10 > CONFIG_SPL_BSS_START_ADDR=0x400 > +CONFIG_SPL_BOARD_INIT=y > +CONFIG_SPL_CACHE=y > CONFIG_SYS_PBSIZE=1050 > CONFIG_SYS_BOOTM_LEN=0x400 > CONFIG_CMD_IMLS=y > @@ -34,6 +36,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_BOOTP_SEND_HOSTNAME=y CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_V5L2_CACHE=y > CONFIG_MMC=y > CONFIG_FTSDC010=y > CONFIG_FTSDC010_SDIO=y > diff --git a/configs/ae350_rv64_spl_xip_defconfig > b/configs/ae350_rv64_spl_xip_defconfig > index 4cbfd52fb1..497e6c0155 100644 > --- a/configs/ae350_rv64_spl_xip_defconfig > +++ b/configs/ae350_rv64_spl_xip_defconfig > @@ -23,6 +23,8 @@ CONFIG_BOOTDELAY=3 > CONFIG_BOARD_EARLY_INIT_F=y > CONFIG_SPL_MAX_SIZE=0x10 > CONFIG_SPL_BSS_START_ADDR=0x400 > +CONFIG_SPL_BOARD_INIT=y > +CONFIG_SPL_CACHE=y > CONFIG_SYS_PBSIZE=1050 > CONFIG_SYS_BOOTM_LEN=0x400 > CONFIG_CMD_IMLS=y > @@ -35,6 +37,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y > CONFIG_BOOTP_SEND_HOSTNAME=y CONFIG_NET_RANDOM_ETHADDR=y >
Re: [PATCH 03/11] board: AndesTech: ax25-ae350.c: Enable v5l2-cache in spl_board_init()
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Thursday, January 19, 2023 3:06 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; Peter Yu-Chien Lin(林宇謙) > Subject: [PATCH 03/11] board: AndesTech: ax25-ae350.c: Enable v5l2-cache in > spl_board_init() > > The L2-cache is not enabled currently, the enbale_caches() will call the > v5l2_enable() callback to enable it in SPL. > > Signed-off-by: Yu Chien Peter Lin > --- > board/AndesTech/ax25-ae350/ax25-ae350.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH 02/11] riscv: Remove redundant Kconfig "RISCV_NDS_CACHE"
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Thursday, January 19, 2023 3:06 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; Peter Yu-Chien Lin(林宇謙) > Subject: [PATCH 02/11] riscv: Remove redundant Kconfig "RISCV_NDS_CACHE" > > From: Leo Yu-Chi Liang > > There is no need for RISCV_NDS_CACHE config to control cache switches. > > Signed-off-by: Leo Yu-Chi Liang > Reviewed-by: Yu Chien Peter Lin > --- > arch/riscv/cpu/ax25/Kconfig | 10 - > arch/riscv/cpu/ax25/cache.c | 84 + > drivers/cache/Kconfig | 1 - > 3 files changed, 2 insertions(+), 93 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH 01/11] riscv: global_data.h: Correct the comment for PLICSW
> From: Peter Yu-Chien Lin(林宇謙)
> Sent: Thursday, January 19, 2023 3:06 PM
> To: u-boot@lists.denx.de
> Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志)
> ; Peter Yu-Chien Lin(林宇謙)
> Subject: [PATCH 01/11] riscv: global_data.h: Correct the comment for PLICSW
>
> PLIC is used for external interrupt, while PLICSW is an Andes-specific design
> for software interrupt.
>
> Signed-off-by: Yu Chien Peter Lin
> ---
> arch/riscv/include/asm/global_data.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
It seems not relative to cache.
Other than that,
Reviewed-by: Rick Chen
>
> diff --git a/arch/riscv/include/asm/global_data.h
> b/arch/riscv/include/asm/global_data.h
> index 6fdc86dd8b..31ba72693d 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -22,7 +22,7 @@ struct arch_global_data {
> void __iomem *clint;/* clint base address */
> #endif
> #ifdef CONFIG_ANDES_PLICSW
> - void __iomem *plicsw; /* plic base address */
> + void __iomem *plicsw; /* andes plicsw base address */
> #endif
> #if CONFIG_IS_ENABLED(SMP)
> struct ipi_data ipi[CONFIG_NR_CPUS];
> --
> 2.34.1
Re: [PATCH v3] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
> On Wed, Jan 4, 2023 at 10:08 AM Rick Chen wrote:
> >
> > Original openSBI (without FW_PIC) will relocate itself
>
> nits: OpenSBI
>
> > from 0x100 to 0x0. After openSBI added FW_PIC codes,
>
> ditto
OK, will fix it.
>
> > it will not relocate any more and always run at 0x100.
> > Hence, it may overlap with Kernel memory region. So it is
>
> with the Linux kernel?
>
> > necessary to change openSBI address from 0x100 to 0x0.
>
> ditto
OK, will fix it.
>
> >
> > More details can refer to commit cb052d771200
> > ("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
> >
> > Signed-off-by: Rick Chen
> > Reviewed-by: Samuel Holland
> > ---
> > Changes in v3
> > - fix typos
> > ---
> > board/AndesTech/ax25-ae350/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/AndesTech/ax25-ae350/Kconfig
> > b/board/AndesTech/ax25-ae350/Kconfig
> > index 36b67f0b52..4bb33b0793 100644
> > --- a/board/AndesTech/ax25-ae350/Kconfig
> > +++ b/board/AndesTech/ax25-ae350/Kconfig
> > @@ -25,7 +25,7 @@ config SPL_TEXT_BASE
> > default 0x80
> >
> > config SPL_OPENSBI_LOAD_ADDR
> > - default 0x0100
> > + default 0x
> >
> > config SYS_FDT_BASE
> > hex
> > --
> > 2.17.1
> >
>
> Otherwise,
> Reviewed-by: Bin Meng
Thanks for reviewing.
B.R,
Rick
[PATCH v4] riscv: ae350: support OpenSBI 1.0+ which enable FW_PIC
Original OpenSBI (without FW_PIC) will relocate itself
from 0x100 to 0x0. After OpenSBI added FW_PIC codes,
it will not relocate any more and always run at 0x100.
Hence, it may overlap with Kernel memory region. So it is
necessary to change OpenSBI address from 0x100 to 0x0.
More details can refer to commit cb052d771200
("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
Signed-off-by: Rick Chen
Reviewed-by: Samuel Holland
Reviewed-by: Bin Meng
---
Changes in v4
- fix openSBI typo
---
board/AndesTech/ax25-ae350/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/Kconfig
b/board/AndesTech/ax25-ae350/Kconfig
index 36b67f0b52..4bb33b0793 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ax25-ae350/Kconfig
@@ -25,7 +25,7 @@ config SPL_TEXT_BASE
default 0x80
config SPL_OPENSBI_LOAD_ADDR
- default 0x0100
+ default 0x
config SYS_FDT_BASE
hex
--
2.17.1
[PATCH v3] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
Original openSBI (without FW_PIC) will relocate itself
from 0x100 to 0x0. After openSBI added FW_PIC codes,
it will not relocate any more and always run at 0x100.
Hence, it may overlap with Kernel memory region. So it is
necessary to change openSBI address from 0x100 to 0x0.
More details can refer to commit cb052d771200
("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
Signed-off-by: Rick Chen
Reviewed-by: Samuel Holland
---
Changes in v3
- fix typos
---
board/AndesTech/ax25-ae350/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/Kconfig
b/board/AndesTech/ax25-ae350/Kconfig
index 36b67f0b52..4bb33b0793 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ax25-ae350/Kconfig
@@ -25,7 +25,7 @@ config SPL_TEXT_BASE
default 0x80
config SPL_OPENSBI_LOAD_ADDR
- default 0x0100
+ default 0x
config SYS_FDT_BASE
hex
--
2.17.1
[PATCH v3 2/2] riscv: memcpy: check src and dst before copy
Add src and dst address checking, if they are the same address, just return and don't copy data anymore. Signed-off-by: Rick Chen --- Changes in v3 - new patch: separate from [1/2] --- arch/riscv/lib/memcpy.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S index 00672c19ad..9884077c93 100644 --- a/arch/riscv/lib/memcpy.S +++ b/arch/riscv/lib/memcpy.S @@ -9,6 +9,7 @@ /* void *memcpy(void *, const void *, size_t) */ ENTRY(__memcpy) WEAK(memcpy) + beq a0, a1, .copy_end /* Save for return value */ mv t6, a0 @@ -121,6 +122,7 @@ WEAK(memcpy) 2: mv a0, t6 +.copy_end: ret .Lmisaligned_word_copy: -- 2.17.1
[PATCH v3 1/2] riscv: ax25: bypass malloc when spl fit boots from ram
When fit image boots from ram, the payload will
be prepared in the address of SPL_LOAD_FIT_ADDRESS.
In spl fit generic flow, it will malloc another
memory address and copy whole fit image to this
malloc address. But it is un-necessary for booting
from RAM.
This patch improves this flow by declare the
board_spl_fit_buffer_addr() to replace the original one.
The larger image size (eq: Kernel Image 10~20MB), it
can save more booting time.
Signed-off-by: Rick Chen
---
Changes in v3
- fix aligment
- refine board_spl_fit_buffer_addr
---
arch/riscv/cpu/ax25/Makefile | 1 +
arch/riscv/cpu/ax25/spl.c| 27 +++
2 files changed, 28 insertions(+)
create mode 100644 arch/riscv/cpu/ax25/spl.c
diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
index 318baccb09..35a1a2fb83 100644
--- a/arch/riscv/cpu/ax25/Makefile
+++ b/arch/riscv/cpu/ax25/Makefile
@@ -5,3 +5,4 @@
obj-y := cpu.o
obj-y += cache.o
+obj-y += spl.o
diff --git a/arch/riscv/cpu/ax25/spl.c b/arch/riscv/cpu/ax25/spl.c
new file mode 100644
index 00..413849043b
--- /dev/null
+++ b/arch/riscv/cpu/ax25/spl.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if CONFIG_IS_ENABLED(RAM_SUPPORT)
+struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
+{
+ return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
+}
+
+void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
+{
+ return spl_get_load_buffer(0, sectors * bl_len);
+}
+#endif
--
2.17.1
Re: [PATCH v2] riscv: ax25: bypass malloc when spl fit boots from ram
> Hi Rick,
>
> On 1/3/23 02:20, Rick Chen wrote:
> > When fit image boots from ram, the payload will
> > be prepared in the address of SPL_LOAD_FIT_ADDRESS.
> > In spl fit generic flow, it will malloc another
> > memory address and copy whole fit image to this
> > malloc address. But it is un-necessary for booting
> > from RAM.
> >
> > This patch improves this flow by declare the
> > board_spl_fit_buffer_addr() to replace the original one.
> > The larger image size (eq: Kernel Image 10~20MB), it
> > can save more booting time.
> >
> > Also enhance memcpy function by checking source and
> > destination address. If they are the same address,
> > just return and don't copy data anymore.
>
> Starting a paragraph with "also" is a good indication that this should
> be split into two separate patches.
OK, I will separate it to another patch.
>
> > Signed-off-by: Rick Chen
> > ---
> > Changes in v2
> > - Move spl.c to board level instead of arch level
> > ---
> > arch/riscv/cpu/ax25/Makefile | 1 +
> > arch/riscv/cpu/ax25/spl.c| 31 +++
> > arch/riscv/lib/memcpy.S | 2 ++
> > 3 files changed, 34 insertions(+)
> > create mode 100644 arch/riscv/cpu/ax25/spl.c
> >
> > diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
> > index 318baccb09..f1c21eadd4 100644
> > --- a/arch/riscv/cpu/ax25/Makefile
> > +++ b/arch/riscv/cpu/ax25/Makefile
> > @@ -5,3 +5,4 @@
> >
> > obj-y:= cpu.o
> > obj-y+= cache.o
> > +obj-y += spl.o
>
> nit: alignment
OK, I will fix it.
>
> > diff --git a/arch/riscv/cpu/ax25/spl.c b/arch/riscv/cpu/ax25/spl.c
> > new file mode 100644
> > index 00..6bf357d26d
> > --- /dev/null
> > +++ b/arch/riscv/cpu/ax25/spl.c
> > @@ -0,0 +1,31 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2023 Andes Technology Corporation
> > + * Rick Chen, Andes Technology Corporation
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#if CONFIG_IS_ENABLED(RAM_SUPPORT)
> > +struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
> > +{
> > + return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
> > +}
> > +
> > +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
> > +{
> > + void *buf;
> > +
> > + buf = spl_get_load_buffer(0, sectors * bl_len);
> > +
> > + return buf;
>
> nit: this could all be one line
OK, I will refine it.
B,R,
Rick
>
> Regards,
> Samuel
>
> > +}
> > +#endif
> > diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S
> > index 00672c19ad..9884077c93 100644
> > --- a/arch/riscv/lib/memcpy.S
> > +++ b/arch/riscv/lib/memcpy.S
> > @@ -9,6 +9,7 @@
> > /* void *memcpy(void *, const void *, size_t) */
> > ENTRY(__memcpy)
> > WEAK(memcpy)
> > + beq a0, a1, .copy_end
> > /* Save for return value */
> > mv t6, a0
> >
> > @@ -121,6 +122,7 @@ WEAK(memcpy)
> > 2:
> >
> > mv a0, t6
> > +.copy_end:
> > ret
> >
> > .Lmisaligned_word_copy:
>
Re: [PATCH v2] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
Hi Samuel
> On 1/3/23 02:18, Rick Chen wrote:
> > Original openSBI (without FW_PIC) will relocate itselt
>
> typo: itself
OK, I will fix it.
>
> > from 0x100 to 0x0. After openSBI added FW_PIC codes,
> > it will not relocate any more and alaways run at 0x100.
>
> typo: always
OK, I will fix it.
>
> > Hence, it may overlap with Kernel memory region. So it is
> > necessary to change openSBI address from 0x100 to 0x0.
> >
> > More details can refer to commit cb052d771200
> > ("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
> >
> > Signed-off-by: Rick Chen
>
> Reviewed-by: Samuel Holland
Thank you for reviewing.
Best Regards,
Rick
>
> > ---
> >
> > Changes in v2
> > - fix typo
> > - describe why is this change a must have
> >
> > ---
> >
> > board/AndesTech/ax25-ae350/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/AndesTech/ax25-ae350/Kconfig
> > b/board/AndesTech/ax25-ae350/Kconfig
> > index 36b67f0b52..4bb33b0793 100644
> > --- a/board/AndesTech/ax25-ae350/Kconfig
> > +++ b/board/AndesTech/ax25-ae350/Kconfig
> > @@ -25,7 +25,7 @@ config SPL_TEXT_BASE
> > default 0x80
> >
> > config SPL_OPENSBI_LOAD_ADDR
> > - default 0x0100
> > + default 0x
> >
> > config SYS_FDT_BASE
> > hex
> > --
> > 2.17.1
> >
>
[PATCH v2] riscv: ax25: bypass malloc when spl fit boots from ram
When fit image boots from ram, the payload will
be prepared in the address of SPL_LOAD_FIT_ADDRESS.
In spl fit generic flow, it will malloc another
memory address and copy whole fit image to this
malloc address. But it is un-necessary for booting
from RAM.
This patch improves this flow by declare the
board_spl_fit_buffer_addr() to replace the original one.
The larger image size (eq: Kernel Image 10~20MB), it
can save more booting time.
Also enhance memcpy function by checking source and
destination address. If they are the same address,
just return and don't copy data anymore.
Signed-off-by: Rick Chen
---
Changes in v2
- Move spl.c to board level instead of arch level
---
arch/riscv/cpu/ax25/Makefile | 1 +
arch/riscv/cpu/ax25/spl.c| 31 +++
arch/riscv/lib/memcpy.S | 2 ++
3 files changed, 34 insertions(+)
create mode 100644 arch/riscv/cpu/ax25/spl.c
diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/ax25/Makefile
index 318baccb09..f1c21eadd4 100644
--- a/arch/riscv/cpu/ax25/Makefile
+++ b/arch/riscv/cpu/ax25/Makefile
@@ -5,3 +5,4 @@
obj-y := cpu.o
obj-y += cache.o
+obj-y += spl.o
diff --git a/arch/riscv/cpu/ax25/spl.c b/arch/riscv/cpu/ax25/spl.c
new file mode 100644
index 00..6bf357d26d
--- /dev/null
+++ b/arch/riscv/cpu/ax25/spl.c
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if CONFIG_IS_ENABLED(RAM_SUPPORT)
+struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
+{
+ return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
+}
+
+void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
+{
+ void *buf;
+
+ buf = spl_get_load_buffer(0, sectors * bl_len);
+
+ return buf;
+}
+#endif
diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S
index 00672c19ad..9884077c93 100644
--- a/arch/riscv/lib/memcpy.S
+++ b/arch/riscv/lib/memcpy.S
@@ -9,6 +9,7 @@
/* void *memcpy(void *, const void *, size_t) */
ENTRY(__memcpy)
WEAK(memcpy)
+ beq a0, a1, .copy_end
/* Save for return value */
mv t6, a0
@@ -121,6 +122,7 @@ WEAK(memcpy)
2:
mv a0, t6
+.copy_end:
ret
.Lmisaligned_word_copy:
--
2.17.1
[PATCH v2] riscv: ae350: support openSBI 1.0+ which enable FW_PIC
Original openSBI (without FW_PIC) will relocate itselt
from 0x100 to 0x0. After openSBI added FW_PIC codes,
it will not relocate any more and alaways run at 0x100.
Hence, it may overlap with Kernel memory region. So it is
necessary to change openSBI address from 0x100 to 0x0.
More details can refer to commit cb052d771200
("riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+")
Signed-off-by: Rick Chen
---
Changes in v2
- fix typo
- describe why is this change a must have
---
board/AndesTech/ax25-ae350/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/Kconfig
b/board/AndesTech/ax25-ae350/Kconfig
index 36b67f0b52..4bb33b0793 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ax25-ae350/Kconfig
@@ -25,7 +25,7 @@ config SPL_TEXT_BASE
default 0x80
config SPL_OPENSBI_LOAD_ADDR
- default 0x0100
+ default 0x
config SYS_FDT_BASE
hex
--
2.17.1
[PATCH v2] riscv: ae350: Enable CCTL_SUEN
CCTL operations are available to Supervisor/User-mode software under the control of the mcache_ctl.CCTL_SUEN control bit. Enable it to support Supervisor(and User) CCTL operations. Signed-off-by: Rick Chen --- Changes in v2 - fix typo - correct aligment --- arch/riscv/cpu/ax25/cpu.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/ax25/cpu.c index c4c2de2ef0..a46674f7c2 100644 --- a/arch/riscv/cpu/ax25/cpu.c +++ b/arch/riscv/cpu/ax25/cpu.c @@ -12,18 +12,20 @@ #include #define CSR_MCACHE_CTL 0x7ca -#define CSR_MMISC_CTL 0x7d0 -#define CSR_MARCHID0xf12 +#define CSR_MMISC_CTL 0x7d0 +#define CSR_MARCHID0xf12 #define V5_MCACHE_CTL_IC_EN_OFFSET 0 #define V5_MCACHE_CTL_DC_EN_OFFSET 1 -#define V5_MCACHE_CTL_DC_COHEN_OFFSET 19 +#define V5_MCACHE_CTL_CCTL_SUEN_OFFSET 8 +#define V5_MCACHE_CTL_DC_COHEN_OFFSET 19 #define V5_MCACHE_CTL_DC_COHSTA_OFFSET 20 -#define V5_MCACHE_CTL_IC_ENBIT(V5_MCACHE_CTL_IC_EN_OFFSET) -#define V5_MCACHE_CTL_DC_EN BIT(V5_MCACHE_CTL_DC_EN_OFFSET) -#define V5_MCACHE_CTL_DC_COHEN_EN BIT(V5_MCACHE_CTL_DC_COHEN_OFFSET) -#define V5_MCACHE_CTL_DC_COHSTA_EN BIT(V5_MCACHE_CTL_DC_COHSTA_OFFSET) +#define V5_MCACHE_CTL_IC_EN BIT(V5_MCACHE_CTL_IC_EN_OFFSET) +#define V5_MCACHE_CTL_DC_EN BIT(V5_MCACHE_CTL_DC_EN_OFFSET) +#define V5_MCACHE_CTL_CCTL_SUEN BIT(V5_MCACHE_CTL_CCTL_SUEN_OFFSET) +#define V5_MCACHE_CTL_DC_COHEN_EN BIT(V5_MCACHE_CTL_DC_COHEN_OFFSET) +#define V5_MCACHE_CTL_DC_COHSTA_EN BIT(V5_MCACHE_CTL_DC_COHSTA_OFFSET) /* @@ -55,6 +57,8 @@ void harts_early_init(void) mcache_ctl_val |= V5_MCACHE_CTL_IC_EN; if (!(mcache_ctl_val & V5_MCACHE_CTL_DC_EN)) mcache_ctl_val |= V5_MCACHE_CTL_DC_EN; + if (!(mcache_ctl_val & V5_MCACHE_CTL_CCTL_SUEN)) + mcache_ctl_val |= V5_MCACHE_CTL_CCTL_SUEN; csr_write(CSR_MCACHE_CTL, mcache_ctl_val); /* -- 2.17.1
Re: [PATCH] riscv: bypass malloc when spl fit boots from ram
> On 12/27/22 21:22, Rick Chen wrote:
> > Hi Samuel,
> >
> > Samuel Holland 於 2022年12月28日 週三 上午10:47寫道：
> >>
> >> On 12/22/22 01:21, Rick Chen wrote:
> >>> When fit image boots from ram, the payload will
> >>> be prepared in the address of SPL_LOAD_FIT_ADDRESS.
> >>> In spl fit generic flow, it will malloc another
> >>> memory address and copy whole fit image to this
> >>> malloc address. But it is un-necessary for booting
> >>> from RAM.
> >>
> >> This should mostly be solved by using `mkimage -E` or binman's
> >> `fit,external-offset`. Then only the FIT structure, without any data,
> >> will be copied.
> >>
> >>> This patch improves this flow by declare the
> >>> board_spl_fit_buffer_addr() to replace the original one.
> >>> The larger image size (eq: Kernel Image 10~20MB), it
> >>> can save more booting time.
> >>>
> >>> Also enhance memcpy function by checking source and
> >>> destination address. If they are the same address,
> >>> just return and don't copy data anymore.
> >>>
> >>> Signed-off-by: Rick Chen
> >>> ---
> >>> arch/riscv/lib/memcpy.S | 2 ++
> >>> arch/riscv/lib/spl.c| 16
> >>> 2 files changed, 18 insertions(+)
> >>>
> >>> diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S
> >>> index 00672c19ad..9884077c93 100644
> >>> --- a/arch/riscv/lib/memcpy.S
> >>> +++ b/arch/riscv/lib/memcpy.S
> >>> @@ -9,6 +9,7 @@
> >>> /* void *memcpy(void *, const void *, size_t) */
> >>> ENTRY(__memcpy)
> >>> WEAK(memcpy)
> >>> + beq a0, a1, .copy_end
> >>
> >> I see one call to memcpy() in common/spl/spl_ram.c. I think it would
> >> make more sense to do the check there instead of adding a branch to
> >> every memcpy() call.
> >
> > There is not only one memcpy being called in spl_ram.c during spl
> > booting progress, but also in spl_fit.c .
>
> Either your FIT uses external data, and the one in spl_ram.c is trivial,
> or it uses internal data, and the one in spl_fit.c is unavoidable.
> Either way, there is only one place where this change makes a difference.
>
> > Otherwise I prefer not to modify it in generic flow level but arch
> > level, because the src and dest checking
> > may not be necessary for other booting devices.
>
> I see arch/arm/lib/memcpy.S has similar logic, so other code may be
> depending on this optimization, and there is precedent for this change.
>
> >>
> >>> /* Save for return value */
> >>> mv t6, a0
> >>>
> >>> @@ -121,6 +122,7 @@ WEAK(memcpy)
> >>> 2:
> >>>
> >>> mv a0, t6
> >>> +.copy_end:
> >>> ret
> >>>
> >>> .Lmisaligned_word_copy:
> >>> diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c
> >>> index f4d3b67e5d..18f86ee207 100644
> >>> --- a/arch/riscv/lib/spl.c
> >>> +++ b/arch/riscv/lib/spl.c
> >>> @@ -61,3 +61,19 @@ void __noreturn jump_to_image_no_args(struct
> >>> spl_image_info *spl_image)
> >>> #endif
> >>> image_entry(gd->arch.boot_hart, fdt_blob);
> >>> }
> >>> +
> >>> +#ifdef CONFIG_SPL_RAM_SUPPORT
> >>> +struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
> >>> +{
> >>> + return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
> >>> +}
> >>> +
> >>> +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
> >>> +{
> >>> + void *buf;
> >>> +
> >>> + buf = spl_get_load_buffer(0, sectors * bl_len);
> >>> +
> >>> + return buf;
> >>> +}
> >>> +#endif
> >>
> >> You cannot provide strong definitions of these functions at an
> >> architecture level, as this prevents any board from overriding them.
> >
> > Originally I wanted to put it in arch/riscv/cpu/ax25/spl.c .
> > However It is a fundamental improvement for spl_ram flow, but not
> > likely a private change.
> > That's why I put it here, so that all boards of RISC-V can be benefited.
>
> This change isn't in any way specific to RISC-V. If you want to make
> this generic, it would belong in spl_ram.c. But I still think it is
> inappropriate to provide a strong definition of board_* functions
> outside board code.
OK, I will move it to arch/riscv/cpu/ax25/spl.c.
>
> Regards,
> Samuel
>
Re: [PATCH] riscv: bypass malloc when spl fit boots from ram
Hi Samuel,
Samuel Holland 於 2022年12月28日 週三 上午10:47寫道：
>
> On 12/22/22 01:21, Rick Chen wrote:
> > When fit image boots from ram, the payload will
> > be prepared in the address of SPL_LOAD_FIT_ADDRESS.
> > In spl fit generic flow, it will malloc another
> > memory address and copy whole fit image to this
> > malloc address. But it is un-necessary for booting
> > from RAM.
>
> This should mostly be solved by using `mkimage -E` or binman's
> `fit,external-offset`. Then only the FIT structure, without any data,
> will be copied.
>
> > This patch improves this flow by declare the
> > board_spl_fit_buffer_addr() to replace the original one.
> > The larger image size (eq: Kernel Image 10~20MB), it
> > can save more booting time.
> >
> > Also enhance memcpy function by checking source and
> > destination address. If they are the same address,
> > just return and don't copy data anymore.
> >
> > Signed-off-by: Rick Chen
> > ---
> > arch/riscv/lib/memcpy.S | 2 ++
> > arch/riscv/lib/spl.c| 16
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S
> > index 00672c19ad..9884077c93 100644
> > --- a/arch/riscv/lib/memcpy.S
> > +++ b/arch/riscv/lib/memcpy.S
> > @@ -9,6 +9,7 @@
> > /* void *memcpy(void *, const void *, size_t) */
> > ENTRY(__memcpy)
> > WEAK(memcpy)
> > + beq a0, a1, .copy_end
>
> I see one call to memcpy() in common/spl/spl_ram.c. I think it would
> make more sense to do the check there instead of adding a branch to
> every memcpy() call.
There is not only one memcpy being called in spl_ram.c during spl
booting progress, but also in spl_fit.c .
Otherwise I prefer not to modify it in generic flow level but arch
level, because the src and dest checking
may not be necessary for other booting devices.
>
> > /* Save for return value */
> > mv t6, a0
> >
> > @@ -121,6 +122,7 @@ WEAK(memcpy)
> > 2:
> >
> > mv a0, t6
> > +.copy_end:
> > ret
> >
> > .Lmisaligned_word_copy:
> > diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c
> > index f4d3b67e5d..18f86ee207 100644
> > --- a/arch/riscv/lib/spl.c
> > +++ b/arch/riscv/lib/spl.c
> > @@ -61,3 +61,19 @@ void __noreturn jump_to_image_no_args(struct
> > spl_image_info *spl_image)
> > #endif
> > image_entry(gd->arch.boot_hart, fdt_blob);
> > }
> > +
> > +#ifdef CONFIG_SPL_RAM_SUPPORT
> > +struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
> > +{
> > + return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
> > +}
> > +
> > +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
> > +{
> > + void *buf;
> > +
> > + buf = spl_get_load_buffer(0, sectors * bl_len);
> > +
> > + return buf;
> > +}
> > +#endif
>
> You cannot provide strong definitions of these functions at an
> architecture level, as this prevents any board from overriding them.
Originally I wanted to put it in arch/riscv/cpu/ax25/spl.c .
However It is a fundamental improvement for spl_ram flow, but not
likely a private change.
That's why I put it here, so that all boards of RISC-V can be benefited.
Thanks,
Rick
>
> Regards,
> Samuel
>
Re: [PATCH] riscv: ae350: Support openSBI 1.0+ which enable FW_PIC
> On Thu, Dec 22, 2022 at 4:07 PM Rick Chen wrote: > > > > > On Thu, Dec 22, 2022 at 1:23 PM Rick Chen wrote: > > > > > > > > Hi Bin, > > > > > > > > > On Wed, Dec 21, 2022 at 10:29 AM Rick Chen wrote: > > > > > > > > > > > > Change openSBI load address from 0x100 to 0x0 and it > > > > > > > > > > nits: OpenSBI > > > > > > > > OK, will fix it. > > > > > > > > > > > > > > > will start to run at 0x0 directly without relocation. > > > > > > > > > > > > Signed-off-by: Rick Chen > > > > > > --- > > > > > > board/AndesTech/ax25-ae350/Kconfig | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/board/AndesTech/ax25-ae350/Kconfig > > > > > > b/board/AndesTech/ax25-ae350/Kconfig > > > > > > index 36b67f0b52..4bb33b0793 100644 > > > > > > --- a/board/AndesTech/ax25-ae350/Kconfig > > > > > > +++ b/board/AndesTech/ax25-ae350/Kconfig > > > > > > @@ -25,7 +25,7 @@ config SPL_TEXT_BASE > > > > > > default 0x80 > > > > > > > > > > > > config SPL_OPENSBI_LOAD_ADDR > > > > > > - default 0x0100 > > > > > > + default 0x > > > > > > > > > > > > config SYS_FDT_BASE > > > > > > hex > > > > > > -- > > > > > > > > > > Can you describe why is this change a must have, like why 0x0100 > > > > > does not work? > > > > > > > > When I prepare this patch, I have tried two OpenSBI address, 0x100 > > > > and 0x0. > > > > And both boot successfully. I think maybe the Kernel Image is smaller > > > > one that it just don't overlap > > > > the memory region ! > > > > > > But why 0x0100 does not work? > > > > 0x100 is not a preferable runtime address for OpenSBI. > > > > Why? It once worked so something has changed to break and it remains > unexplained yet. OK. I will add more description about why 0x100 does not work. Thanks, Rick > > Regards, > Biun
Re: [PATCH] riscv: ae350: Support openSBI 1.0+ which enable FW_PIC
> On Thu, Dec 22, 2022 at 1:23 PM Rick Chen wrote: > > > > Hi Bin, > > > > > On Wed, Dec 21, 2022 at 10:29 AM Rick Chen wrote: > > > > > > > > Change openSBI load address from 0x100 to 0x0 and it > > > > > > nits: OpenSBI > > > > OK, will fix it. > > > > > > > > > will start to run at 0x0 directly without relocation. > > > > > > > > Signed-off-by: Rick Chen > > > > --- > > > > board/AndesTech/ax25-ae350/Kconfig | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/board/AndesTech/ax25-ae350/Kconfig > > > > b/board/AndesTech/ax25-ae350/Kconfig > > > > index 36b67f0b52..4bb33b0793 100644 > > > > --- a/board/AndesTech/ax25-ae350/Kconfig > > > > +++ b/board/AndesTech/ax25-ae350/Kconfig > > > > @@ -25,7 +25,7 @@ config SPL_TEXT_BASE > > > > default 0x80 > > > > > > > > config SPL_OPENSBI_LOAD_ADDR > > > > - default 0x0100 > > > > + default 0x > > > > > > > > config SYS_FDT_BASE > > > > hex > > > > -- > > > > > > Can you describe why is this change a must have, like why 0x0100 > > > does not work? > > > > When I prepare this patch, I have tried two OpenSBI address, 0x100 and > > 0x0. > > And both boot successfully. I think maybe the Kernel Image is smaller > > one that it just don't overlap > > the memory region ! > > But why 0x0100 does not work? 0x100 is not a preferable runtime address for OpenSBI. > > Regards, > Bin
[PATCH] riscv: bypass malloc when spl fit boots from ram
When fit image boots from ram, the payload will
be prepared in the address of SPL_LOAD_FIT_ADDRESS.
In spl fit generic flow, it will malloc another
memory address and copy whole fit image to this
malloc address. But it is un-necessary for booting
from RAM.
This patch improves this flow by declare the
board_spl_fit_buffer_addr() to replace the original one.
The larger image size (eq: Kernel Image 10~20MB), it
can save more booting time.
Also enhance memcpy function by checking source and
destination address. If they are the same address,
just return and don't copy data anymore.
Signed-off-by: Rick Chen
---
arch/riscv/lib/memcpy.S | 2 ++
arch/riscv/lib/spl.c| 16
2 files changed, 18 insertions(+)
diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S
index 00672c19ad..9884077c93 100644
--- a/arch/riscv/lib/memcpy.S
+++ b/arch/riscv/lib/memcpy.S
@@ -9,6 +9,7 @@
/* void *memcpy(void *, const void *, size_t) */
ENTRY(__memcpy)
WEAK(memcpy)
+ beq a0, a1, .copy_end
/* Save for return value */
mv t6, a0
@@ -121,6 +122,7 @@ WEAK(memcpy)
2:
mv a0, t6
+.copy_end:
ret
.Lmisaligned_word_copy:
diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c
index f4d3b67e5d..18f86ee207 100644
--- a/arch/riscv/lib/spl.c
+++ b/arch/riscv/lib/spl.c
@@ -61,3 +61,19 @@ void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
#endif
image_entry(gd->arch.boot_hart, fdt_blob);
}
+
+#ifdef CONFIG_SPL_RAM_SUPPORT
+struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
+{
+ return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset);
+}
+
+void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
+{
+ void *buf;
+
+ buf = spl_get_load_buffer(0, sectors * bl_len);
+
+ return buf;
+}
+#endif
--
2.17.1
Re: [PATCH v1 01/17] riscv: cpu: jh7110: Add support for jh7110 SoC
> From: Yanhong Wang > Sent: Monday, December 12, 2022 10:50 AM > To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) ; Leo > Yu-Chi Liang(梁育齊) ; Lukasz Majewski ; > Sean Anderson > Cc: Lee Kuan Lim ; Jianlong Huang > ; Emil Renner Berthing ; > Yanhong Wang > Subject: [PATCH v1 01/17] riscv: cpu: jh7110: Add support for jh7110 SoC > > Add StarFive JH7110 SoC to support RISC-V arch. > > Signed-off-by: Yanhong Wang > --- > arch/riscv/cpu/jh7110/Makefile| 10 > arch/riscv/cpu/jh7110/cpu.c | 23 > arch/riscv/cpu/jh7110/dram.c | 38 + > arch/riscv/cpu/jh7110/spl.c | 56 +++ > .../include/asm/arch-jh7110/jh7110-regs.h | 20 +++ > arch/riscv/include/asm/arch-jh7110/spl.h | 13 +++++ > 6 files changed, 160 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH] riscv: ae350: Support openSBI 1.0+ which enable FW_PIC
Hi Bin, > On Wed, Dec 21, 2022 at 10:29 AM Rick Chen wrote: > > > > Change openSBI load address from 0x100 to 0x0 and it > > nits: OpenSBI OK, will fix it. > > > will start to run at 0x0 directly without relocation. > > > > Signed-off-by: Rick Chen > > --- > > board/AndesTech/ax25-ae350/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/board/AndesTech/ax25-ae350/Kconfig > > b/board/AndesTech/ax25-ae350/Kconfig > > index 36b67f0b52..4bb33b0793 100644 > > --- a/board/AndesTech/ax25-ae350/Kconfig > > +++ b/board/AndesTech/ax25-ae350/Kconfig > > @@ -25,7 +25,7 @@ config SPL_TEXT_BASE > > default 0x80 > > > > config SPL_OPENSBI_LOAD_ADDR > > - default 0x0100 > > + default 0x > > > > config SYS_FDT_BASE > > hex > > -- > > Can you describe why is this change a must have, like why 0x0100 > does not work? When I prepare this patch, I have tried two OpenSBI address, 0x100 and 0x0. And both boot successfully. I think maybe the Kernel Image is smaller one that it just don't overlap the memory region ! Thanks, Rick > > Is the reason the same as commit cb052d771200b15717eeb68f185cf7caa2dcfea0 > "riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+" > > Regards, > Bin
Re: [PATCH] riscv: ae350: Enable CCTL_SUEN
Hi Bin > On Wed, Dec 21, 2022 at 11:00 AM Rick Chen wrote: > > > > CCTL operations are available to Supervisor/User-mode > > software under the control of the mcache_ctl.CCTL_SUEN > > control bit. Enable it to support Superviosr(and User) > > typo: Supervisor OK, will fix it. > > > CCTL operations. > > > > Signed-off-by: Rick Chen > > --- > > arch/riscv/cpu/ax25/cpu.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/ax25/cpu.c > > index c4c2de2ef0..fc3239e1ac 100644 > > --- a/arch/riscv/cpu/ax25/cpu.c > > +++ b/arch/riscv/cpu/ax25/cpu.c > > @@ -17,11 +17,13 @@ > > > > #define V5_MCACHE_CTL_IC_EN_OFFSET 0 > > #define V5_MCACHE_CTL_DC_EN_OFFSET 1 > > +#define V5_MCACHE_CTL_CCTL_SUEN_OFFSET 8 > > nits: alignment seems wrong OK, will fix it. > > > #define V5_MCACHE_CTL_DC_COHEN_OFFSET 19 > > #define V5_MCACHE_CTL_DC_COHSTA_OFFSET 20 > > > > #define V5_MCACHE_CTL_IC_ENBIT(V5_MCACHE_CTL_IC_EN_OFFSET) > > #define V5_MCACHE_CTL_DC_EN > > BIT(V5_MCACHE_CTL_DC_EN_OFFSET) > > +#define V5_MCACHE_CTL_CCTL_SUENBIT(V5_MCACHE_CTL_CCTL_SUEN_OFFSET) > > nits: alignment seems wrong OK, will fix it. Thanks for review. Rick > > > #define V5_MCACHE_CTL_DC_COHEN_EN BIT(V5_MCACHE_CTL_DC_COHEN_OFFSET) > > #define V5_MCACHE_CTL_DC_COHSTA_EN BIT(V5_MCACHE_CTL_DC_COHSTA_OFFSET) > > > > @@ -55,6 +57,8 @@ void harts_early_init(void) > > mcache_ctl_val |= V5_MCACHE_CTL_IC_EN; > > if (!(mcache_ctl_val & V5_MCACHE_CTL_DC_EN)) > > mcache_ctl_val |= V5_MCACHE_CTL_DC_EN; > > + if (!(mcache_ctl_val & V5_MCACHE_CTL_CCTL_SUEN)) > > + mcache_ctl_val |= V5_MCACHE_CTL_CCTL_SUEN; > > csr_write(CSR_MCACHE_CTL, mcache_ctl_val); > > > > /* > > -- > > Regards, > Bin
[PATCH] riscv: ae350: Enable CCTL_SUEN
CCTL operations are available to Supervisor/User-mode software under the control of the mcache_ctl.CCTL_SUEN control bit. Enable it to support Superviosr(and User) CCTL operations. Signed-off-by: Rick Chen --- arch/riscv/cpu/ax25/cpu.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/ax25/cpu.c index c4c2de2ef0..fc3239e1ac 100644 --- a/arch/riscv/cpu/ax25/cpu.c +++ b/arch/riscv/cpu/ax25/cpu.c @@ -17,11 +17,13 @@ #define V5_MCACHE_CTL_IC_EN_OFFSET 0 #define V5_MCACHE_CTL_DC_EN_OFFSET 1 +#define V5_MCACHE_CTL_CCTL_SUEN_OFFSET 8 #define V5_MCACHE_CTL_DC_COHEN_OFFSET 19 #define V5_MCACHE_CTL_DC_COHSTA_OFFSET 20 #define V5_MCACHE_CTL_IC_ENBIT(V5_MCACHE_CTL_IC_EN_OFFSET) #define V5_MCACHE_CTL_DC_EN BIT(V5_MCACHE_CTL_DC_EN_OFFSET) +#define V5_MCACHE_CTL_CCTL_SUENBIT(V5_MCACHE_CTL_CCTL_SUEN_OFFSET) #define V5_MCACHE_CTL_DC_COHEN_EN BIT(V5_MCACHE_CTL_DC_COHEN_OFFSET) #define V5_MCACHE_CTL_DC_COHSTA_EN BIT(V5_MCACHE_CTL_DC_COHSTA_OFFSET) @@ -55,6 +57,8 @@ void harts_early_init(void) mcache_ctl_val |= V5_MCACHE_CTL_IC_EN; if (!(mcache_ctl_val & V5_MCACHE_CTL_DC_EN)) mcache_ctl_val |= V5_MCACHE_CTL_DC_EN; + if (!(mcache_ctl_val & V5_MCACHE_CTL_CCTL_SUEN)) + mcache_ctl_val |= V5_MCACHE_CTL_CCTL_SUEN; csr_write(CSR_MCACHE_CTL, mcache_ctl_val); /* -- 2.17.1
[PATCH] riscv: ae350: Support openSBI 1.0+ which enable FW_PIC
Change openSBI load address from 0x100 to 0x0 and it will start to run at 0x0 directly without relocation. Signed-off-by: Rick Chen --- board/AndesTech/ax25-ae350/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/AndesTech/ax25-ae350/Kconfig b/board/AndesTech/ax25-ae350/Kconfig index 36b67f0b52..4bb33b0793 100644 --- a/board/AndesTech/ax25-ae350/Kconfig +++ b/board/AndesTech/ax25-ae350/Kconfig @@ -25,7 +25,7 @@ config SPL_TEXT_BASE default 0x80 config SPL_OPENSBI_LOAD_ADDR - default 0x0100 + default 0x config SYS_FDT_BASE hex -- 2.17.1
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
> On 12/13/22 11:24, Tom Rini wrote: > > On Tue, Dec 13, 2022 at 08:42:47AM +0800, Rick Chen wrote: > >> Hi Sean, > >> > >>> On 12/12/22 10:03, Tom Rini wrote: > >>>> On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote: > >>>>> Hi Tom > >>>>> > >>>>>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote: > >>>>>>> On 12/7/22 01:23, Rick Chen wrote: > >>>>>>>> In RISC-V, it only provide normal mode booting currently. > >>>>>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT > >>>>>>>> to achieve this feature which will be call Fast-Boot mode. By > >>>>>>> > >>>>>>> Can you name this something different. We already have something > >>>>>>> called > >>>>>>> fastboot in-tree (the Android-derived protocol) and there's a > >>>>>>> Microsoft > >>>>>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't > >>>>>>> very specific either, since we (almost always) boot an OS. Maybe > >>>>>>> "Eagle > >>>>>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS. > >>>>>>> > >>>>>>> (Is this substantially different from falcon mode anyway?) > >>>>>> > >>>>>> I was kind of wondering if this is different, really, from Falcon Mode. > >>>>>> Falcon Mode didn't initially have to factor in other-firmware as that's > >>>>>> not a hard requirement on arm32 like it is on arm64 or risc-v. But my > >>>>>> first read of this was that it seems like the RISC-V specific side of > >>>>>> doing Falcon Mode and dealing with the prior stage needs correctly. > >>>>>> > >>>>> > >>>>> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y). > >>>>> When I try to enable SPL_OS_BOOT, it will encounter that > >>>>> SYS_SPL_ARGS_ADDR and > >>>>>jump_to_image_linux() shall be defined but they are un-necessary for > >>>>> RISC-V. > >>>>> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code > >>>>> flow in board_init_r() of common/spl/spl.c. > >>>>> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this > >>>>> RISC-V fast boot implementation. > >>>> > >>>> Those sound like fairly minor challenges for the same fundamental > >>>> concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to > >>>> pass along". We might need to do a little code re-factoring here. But > >>>> maybe also a little bit of explaining why we wouldn't be booting to the > >>>> OS directly but instead passing back to openSBI to do this? That's not > >>>> normally how RISC-V boots the OS, right? Or am I miss-understanding > >>>> something here? > >>>> > >>> > >>> The usual process is > >>> > >>> ROM -> SPL -> SBI -> U-Boot -> Linux > >> > >> In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as > >> M-mode to deal with SBI calls at run-time. > >> So the fast boot idea, I just want to bypass U-Boot and jump to Linux > >> directly and Linux still needs OpenSBI. > >> Hence SPL_OPENSBI can't be disabled here. > > > > So is the flow here: > > a) ROM -> SPL -> SBI -> SPL -> Linux > > or > > b) ROM -> SPL -> SBI -> Linux > > The latter. The regular boot is > > (M) Boot ROM loads SPL and executes it > (M) SPL loads SBI and U-Boot proper and executes SBI > (M) SBI performs initialization and executes U-Boot > (S) U-Boot loads Linux and executes it > (S) Linux boots > > And this would change that to > > (M) Boot ROM loads SPL and executes it > (M) SPL loads SBI and Linux and executes SBI > (M) SBI performs initialization and executes Linux > (S) Linux boots > > So the idea here is to load Linux in SPL instead of U-Boot. But I think this > is > the only way to go for platforms which use OpenSBI. Regular falcon mode would > require a Linux which runs in M-mode. So I don't think we need a separate > config. Hi Sean, Thanks for your explanation. It is very clear. Hi Tom, Sean, Do you have any further suggestions that I can improve or refine this patch ? Thanks, Rick > > --Sean > > > It's not clear to me, and I think that'll help figure out what's best > > here. Since I kinda think we're looking at a more generic issue that we > > see with newer architectures and maybe we already had to solve this (but > > didn't name things well enough) for aarch64. > > > > >
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
Hi Tom, > On Wed, Dec 14, 2022 at 08:49:03AM +0800, Rick Chen wrote: > > Hi Tom, > > > > > On Tue, Dec 13, 2022 at 10:06:50AM +0800, Rick Chen wrote: > > > > > On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote: > > > > > > > On 12/7/22 01:23, Rick Chen wrote: > > > > > > > > In RISC-V, it only provide normal mode booting currently. > > > > > > > > To speed up the booting process, here provide > > > > > > > > SPL_OPENSBI_OS_BOOT > > > > > > > > to achieve this feature which will be call Fast-Boot mode. By > > > > > > > > > > > > > > Can you name this something different. We already have something > > > > > > > called > > > > > > > fastboot in-tree (the Android-derived protocol) and there's a > > > > > > > Microsoft > > > > > > > technology called fastboot (some kind of hibernation). "OS Boot" > > > > > > > isn't > > > > > > > very specific either, since we (almost always) boot an OS. Maybe > > > > > > > "Eagle > > > > > > > mode" by analogy to Falcon mode, which lets SPL directly boot an > > > > > > > OS. > > > > > > > > > > > > I think fast boot is a behavior which shall be interpreted widely > > > > > > but > > > > > > not proprietary. > > > > > > Or maybe I can rename it as RISC-V Fast Boot to distinguish them. > > > > > > > > > > > > > > > > > > > > (Is this substantially different from falcon mode anyway?) > > > > > > > > > > > > Please see the explanations to Tom. > > > > > > > > > > > > > > > > > > > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead > > > > > > > > of default u-boot.itb after compiling. It initializes memory > > > > > > > > with > > > > > > > > the U-Boot SPL at the first stage, just like what a regular > > > > > > > > booting > > > > > > > > process (i.e. Normal Boot) does in the beginning. Instead of > > > > > > > > jumping > > > > > > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, > > > > > > > > the > > > > > > > > Fast Boot process jumps directly to Linux Kernel to gain shorter > > > > > > > > booting time. > > > > > > > > > > > > > > > > Signed-off-by: Rick Chen > > > > > > > > --- > > > > > > > > common/spl/Kconfig | 14 ++ > > > > > > > > common/spl/spl_fit.c | 3 ++- > > > > > > > > common/spl/spl_opensbi.c | 25 - > > > > > > > > 3 files changed, 28 insertions(+), 14 deletions(-) > > > > > > > > > > > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > > > > > > index 05181bdba3..8805aba1b7 100644 > > > > > > > > --- a/common/spl/Kconfig > > > > > > > > +++ b/common/spl/Kconfig > > > > > > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS > > > > > > > > Options passed to fw_dynamic, for example > > > > > > > > SBI_SCRATCH_NO_BOOT_PRINTS or > > > > > > > > SBI_SCRATCH_DEBUG_PRINTS. > > > > > > > > > > > > > > > > +config SPL_OPENSBI_OS_BOOT > > > > > > > > > > > > > > Please use the same name for the config as for the description. > > > > > > > > > > > > > > > + bool "openSBI Fast Boot" > > > > > > > > + depends on SPL_OPENSBI > > > > > > > > + help > > > > > > > > + Enable this openSBI can jump to Linux Kernel directly. > > > > > > > > > > > > > > Can you put some of the explanation from the commit message here? > > > > > > > > > > > > OK, I will move some messages here from commit messages. > > > > > > > &g
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
Hi Tom, > On Tue, Dec 13, 2022 at 10:06:50AM +0800, Rick Chen wrote: > > > On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote: > > > > > On 12/7/22 01:23, Rick Chen wrote: > > > > > > In RISC-V, it only provide normal mode booting currently. > > > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT > > > > > > to achieve this feature which will be call Fast-Boot mode. By > > > > > > > > > > Can you name this something different. We already have something > > > > > called > > > > > fastboot in-tree (the Android-derived protocol) and there's a > > > > > Microsoft > > > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't > > > > > very specific either, since we (almost always) boot an OS. Maybe > > > > > "Eagle > > > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS. > > > > > > > > I think fast boot is a behavior which shall be interpreted widely but > > > > not proprietary. > > > > Or maybe I can rename it as RISC-V Fast Boot to distinguish them. > > > > > > > > > > > > > > (Is this substantially different from falcon mode anyway?) > > > > > > > > Please see the explanations to Tom. > > > > > > > > > > > > > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead > > > > > > of default u-boot.itb after compiling. It initializes memory with > > > > > > the U-Boot SPL at the first stage, just like what a regular booting > > > > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping > > > > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the > > > > > > Fast Boot process jumps directly to Linux Kernel to gain shorter > > > > > > booting time. > > > > > > > > > > > > Signed-off-by: Rick Chen > > > > > > --- > > > > > > common/spl/Kconfig | 14 ++ > > > > > > common/spl/spl_fit.c | 3 ++- > > > > > > common/spl/spl_opensbi.c | 25 - > > > > > > 3 files changed, 28 insertions(+), 14 deletions(-) > > > > > > > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > > > > index 05181bdba3..8805aba1b7 100644 > > > > > > --- a/common/spl/Kconfig > > > > > > +++ b/common/spl/Kconfig > > > > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS > > > > > > Options passed to fw_dynamic, for example > > > > > > SBI_SCRATCH_NO_BOOT_PRINTS or > > > > > > SBI_SCRATCH_DEBUG_PRINTS. > > > > > > > > > > > > +config SPL_OPENSBI_OS_BOOT > > > > > > > > > > Please use the same name for the config as for the description. > > > > > > > > > > > + bool "openSBI Fast Boot" > > > > > > + depends on SPL_OPENSBI > > > > > > + help > > > > > > + Enable this openSBI can jump to Linux Kernel directly. > > > > > > > > > > Can you put some of the explanation from the commit message here? > > > > > > > > OK, I will move some messages here from commit messages. > > > > > > > > > > > > > > > + > > > > > > +config SPL_OPENSBI_FIT_NAME > > > > > > + string "SPL openSBI fit image name" > > > > > > + depends on SPL_OPENSBI > > > > > > + default "linux.itb" if SPL_OPENSBI_OS_BOOT > > > > > > + default "u-boot.itb" > > > > > > + help > > > > > > + This will help to generate different fit name accordingly. > > > > > > > > > > Why not SPL_FS_LOAD_PAYLOAD_NAME? > > > > > > > > > > It looks like the code changes below do not use these configs. Can you > > > > > move them to the next patch so it is clearer that they are for binman? > > > > > > > > I have saw this config, but it does't support SPL_RAM but only for > > > > filesystem > > > > That is why I don't leverage it. > > > &
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
> On Mon, Dec 12, 2022 at 03:49:10PM +0800, Rick Chen wrote: > > > On 12/7/22 01:23, Rick Chen wrote: > > > > In RISC-V, it only provide normal mode booting currently. > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT > > > > to achieve this feature which will be call Fast-Boot mode. By > > > > > > Can you name this something different. We already have something called > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS. > > > > I think fast boot is a behavior which shall be interpreted widely but > > not proprietary. > > Or maybe I can rename it as RISC-V Fast Boot to distinguish them. > > > > > > > > (Is this substantially different from falcon mode anyway?) > > > > Please see the explanations to Tom. > > > > > > > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead > > > > of default u-boot.itb after compiling. It initializes memory with > > > > the U-Boot SPL at the first stage, just like what a regular booting > > > > process (i.e. Normal Boot) does in the beginning. Instead of jumping > > > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the > > > > Fast Boot process jumps directly to Linux Kernel to gain shorter > > > > booting time. > > > > > > > > Signed-off-by: Rick Chen > > > > --- > > > > common/spl/Kconfig | 14 ++ > > > > common/spl/spl_fit.c | 3 ++- > > > > common/spl/spl_opensbi.c | 25 - > > > > 3 files changed, 28 insertions(+), 14 deletions(-) > > > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > > index 05181bdba3..8805aba1b7 100644 > > > > --- a/common/spl/Kconfig > > > > +++ b/common/spl/Kconfig > > > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS > > > > Options passed to fw_dynamic, for example > > > > SBI_SCRATCH_NO_BOOT_PRINTS or > > > > SBI_SCRATCH_DEBUG_PRINTS. > > > > > > > > +config SPL_OPENSBI_OS_BOOT > > > > > > Please use the same name for the config as for the description. > > > > > > > + bool "openSBI Fast Boot" > > > > + depends on SPL_OPENSBI > > > > + help > > > > + Enable this openSBI can jump to Linux Kernel directly. > > > > > > Can you put some of the explanation from the commit message here? > > > > OK, I will move some messages here from commit messages. > > > > > > > > > + > > > > +config SPL_OPENSBI_FIT_NAME > > > > + string "SPL openSBI fit image name" > > > > + depends on SPL_OPENSBI > > > > + default "linux.itb" if SPL_OPENSBI_OS_BOOT > > > > + default "u-boot.itb" > > > > + help > > > > + This will help to generate different fit name accordingly. > > > > > > Why not SPL_FS_LOAD_PAYLOAD_NAME? > > > > > > It looks like the code changes below do not use these configs. Can you > > > move them to the next patch so it is clearer that they are for binman? > > > > I have saw this config, but it does't support SPL_RAM but only for > > filesystem > > That is why I don't leverage it. > > > > I can prepare a patch as below if no other concerns: > > > > config SPL_FS_LOAD_PAYLOAD_NAME > > string "File to load for U-Boot from the filesystem" > > depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM > > default "tispl.bin" if SYS_K3_SPL_ATF > > default "u-boot.itb" if SPL_LOAD_FIT > > default "linux.itb" if SPL_OPENSBI_OS_BOOT > > default "u-boot.img" > > help > > Filename to read to load U-Boot when reading from filesystem. > > But in the case you have it's for the output name, and not at all about > what's being loaded from a filesystem yes? This shouldn't be a "SPL_.." For SPL_RAM purpose, it is just an output name to distinguish normal boot (u-boot.itb) and fast boot (linux.itb) indeed. But for SPL_OPENSBI_OS_BOOT && SPL_MMC && SPL_FAT this combination, it can help to load linux.itb automatically from SD card. > option, but should be under arch/riscv/Kconfig somewhere, since it's > changing the general riscv binman.dtsi file. And on a related note, I will fall back on the earlier changes and move SPL_OPENSBI_OS_BOOT and SPL_OPENSBI_FIT_NAME to arch/riscv/Kconfig. > please make sure that 'make htmldocs' is happy with your documentation > changes as I think I see some spacing problems in 4/4. Sorry about the spacing problems. I will check it. Thanks, Rick > > -- > Tom
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
Hi Tom > On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote: > > Hi Tom > > > > > On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote: > > > > On 12/7/22 01:23, Rick Chen wrote: > > > > > In RISC-V, it only provide normal mode booting currently. > > > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT > > > > > to achieve this feature which will be call Fast-Boot mode. By > > > > > > > > Can you name this something different. We already have something called > > > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft > > > > technology called fastboot (some kind of hibernation). "OS Boot" isn't > > > > very specific either, since we (almost always) boot an OS. Maybe "Eagle > > > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS. > > > > > > > > (Is this substantially different from falcon mode anyway?) > > > > > > I was kind of wondering if this is different, really, from Falcon Mode. > > > Falcon Mode didn't initially have to factor in other-firmware as that's > > > not a hard requirement on arm32 like it is on arm64 or risc-v. But my > > > first read of this was that it seems like the RISC-V specific side of > > > doing Falcon Mode and dealing with the prior stage needs correctly. > > > > > > > Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y). > > When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR > > and > > jump_to_image_linux() shall be defined but they are un-necessary for > > RISC-V. > > Because the flow of OpenSBI and SPL_OS_BOOT are totally different code > > flow in board_init_r() of common/spl/spl.c. > > That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this > > RISC-V fast boot implementation. > > Those sound like fairly minor challenges for the same fundamental > concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to > pass along". We might need to do a little code re-factoring here. But > maybe also a little bit of explaining why we wouldn't be booting to the > OS directly but instead passing back to openSBI to do this? That's not > normally how RISC-V boots the OS, right? Or am I miss-understanding > something here? Because RISC-V Linux runs in S-Mode, it needs OpenSBI which runs in M-mode to handle SBI calls. So it can not boot Linux (OS) directly from U-Boot SPL but passing back to openSBI to do this. Rick > > -- > Tom
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
Hi Sean, > On 12/12/22 10:03, Tom Rini wrote: > > On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote: > >> Hi Tom > >> > >>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote: > >>>> On 12/7/22 01:23, Rick Chen wrote: > >>>>> In RISC-V, it only provide normal mode booting currently. > >>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT > >>>>> to achieve this feature which will be call Fast-Boot mode. By > >>>> > >>>> Can you name this something different. We already have something called > >>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft > >>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't > >>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle > >>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS. > >>>> > >>>> (Is this substantially different from falcon mode anyway?) > >>> > >>> I was kind of wondering if this is different, really, from Falcon Mode. > >>> Falcon Mode didn't initially have to factor in other-firmware as that's > >>> not a hard requirement on arm32 like it is on arm64 or risc-v. But my > >>> first read of this was that it seems like the RISC-V specific side of > >>> doing Falcon Mode and dealing with the prior stage needs correctly. > >>> > >> > >> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y). > >> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR > >> and > >> jump_to_image_linux() shall be defined but they are un-necessary for > >> RISC-V. > >> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code > >> flow in board_init_r() of common/spl/spl.c. > >> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this > >> RISC-V fast boot implementation. > > > > Those sound like fairly minor challenges for the same fundamental > > concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to > > pass along". We might need to do a little code re-factoring here. But > > maybe also a little bit of explaining why we wouldn't be booting to the > > OS directly but instead passing back to openSBI to do this? That's not > > normally how RISC-V boots the OS, right? Or am I miss-understanding > > something here? > > > > The usual process is > > ROM -> SPL -> SBI -> U-Boot -> Linux In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as M-mode to deal with SBI calls at run-time. So the fast boot idea, I just want to bypass U-Boot and jump to Linux directly and Linux still needs OpenSBI. Hence SPL_OPENSBI can't be disabled here. Rick > > Where SPL loads SBI and U-Boot and tells SBI "please run U-Boot after you are > done booting". But the idea here is to load Linux instead of U-Boot. I think > this is pretty similar to Falcon mode. Actually, when CONFIG_SPL_OPENSBI is > enabled, I think it's reasonable for falcon mode to do exactly that. People > who want the SPL -> Linux path can disable SPL_OPENSBI. > > --Sean
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
> On 12/7/22 01:23, Rick Chen wrote: > > In RISC-V, it only provide normal mode booting currently. > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT > > to achieve this feature which will be call Fast-Boot mode. By > > Can you name this something different. We already have something called > fastboot in-tree (the Android-derived protocol) and there's a Microsoft > technology called fastboot (some kind of hibernation). "OS Boot" isn't > very specific either, since we (almost always) boot an OS. Maybe "Eagle > mode" by analogy to Falcon mode, which lets SPL directly boot an OS. I think fast boot is a behavior which shall be interpreted widely but not proprietary. Or maybe I can rename it as RISC-V Fast Boot to distinguish them. > > (Is this substantially different from falcon mode anyway?) Please see the explanations to Tom. > > > enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead > > of default u-boot.itb after compiling. It initializes memory with > > the U-Boot SPL at the first stage, just like what a regular booting > > process (i.e. Normal Boot) does in the beginning. Instead of jumping > > to the U-Boot proper from OpenSBI before booting Linux Kernel, the > > Fast Boot process jumps directly to Linux Kernel to gain shorter > > booting time. > > > > Signed-off-by: Rick Chen > > --- > > common/spl/Kconfig | 14 ++ > > common/spl/spl_fit.c | 3 ++- > > common/spl/spl_opensbi.c | 25 - > > 3 files changed, 28 insertions(+), 14 deletions(-) > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > index 05181bdba3..8805aba1b7 100644 > > --- a/common/spl/Kconfig > > +++ b/common/spl/Kconfig > > @@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS > > Options passed to fw_dynamic, for example > > SBI_SCRATCH_NO_BOOT_PRINTS or > > SBI_SCRATCH_DEBUG_PRINTS. > > > > +config SPL_OPENSBI_OS_BOOT > > Please use the same name for the config as for the description. > > > + bool "openSBI Fast Boot" > > + depends on SPL_OPENSBI > > + help > > + Enable this openSBI can jump to Linux Kernel directly. > > Can you put some of the explanation from the commit message here? OK, I will move some messages here from commit messages. > > > + > > +config SPL_OPENSBI_FIT_NAME > > + string "SPL openSBI fit image name" > > + depends on SPL_OPENSBI > > + default "linux.itb" if SPL_OPENSBI_OS_BOOT > > + default "u-boot.itb" > > + help > > + This will help to generate different fit name accordingly. > > Why not SPL_FS_LOAD_PAYLOAD_NAME? > > It looks like the code changes below do not use these configs. Can you > move them to the next patch so it is clearer that they are for binman? I have saw this config, but it does't support SPL_RAM but only for filesystem That is why I don't leverage it. I can prepare a patch as below if no other concerns: config SPL_FS_LOAD_PAYLOAD_NAME string "File to load for U-Boot from the filesystem" depends on SPL_FS_EXT4 || SPL_FS_FAT || SPL_FS_SQUASHFS || SPL_RAM default "tispl.bin" if SYS_K3_SPL_ATF default "u-boot.itb" if SPL_LOAD_FIT default "linux.itb" if SPL_OPENSBI_OS_BOOT default "u-boot.img" help Filename to read to load U-Boot when reading from filesystem. Thanks, Rick > > --Sean > > > config SPL_TARGET > > string "Addtional build targets for 'make'" > > default "spl/u-boot-spl.srec" if RCAR_GEN2 > > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c > > index c1ed31e367..c5b1dfb3ba 100644 > > --- a/common/spl/spl_fit.c > > +++ b/common/spl/spl_fit.c > > @@ -363,7 +363,8 @@ static bool os_takes_devicetree(uint8_t os) > > case IH_OS_U_BOOT: > > return true; > > case IH_OS_LINUX: > > - return IS_ENABLED(CONFIG_SPL_OS_BOOT); > > + return IS_ENABLED(CONFIG_SPL_OS_BOOT) || > > + IS_ENABLED(CONFIG_SPL_OPENSBI_OS_BOOT); > > default: > > return false; > > } > > diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c > > index b0f40076c3..83869c6b18 100644 > > --- a/common/spl/spl_opensbi.c > > +++ b/common/spl/spl_opensbi.c > > @@ -20,7 +20,7 @@ DECLARE_GLOBAL_DATA_PTR; > > > > struct fw_dynamic_info opensbi_info; > > > > -static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node) > > +static int
Re: [PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
Hi Tom > On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote: > > On 12/7/22 01:23, Rick Chen wrote: > > > In RISC-V, it only provide normal mode booting currently. > > > To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT > > > to achieve this feature which will be call Fast-Boot mode. By > > > > Can you name this something different. We already have something called > > fastboot in-tree (the Android-derived protocol) and there's a Microsoft > > technology called fastboot (some kind of hibernation). "OS Boot" isn't > > very specific either, since we (almost always) boot an OS. Maybe "Eagle > > mode" by analogy to Falcon mode, which lets SPL directly boot an OS. > > > > (Is this substantially different from falcon mode anyway?) > > I was kind of wondering if this is different, really, from Falcon Mode. > Falcon Mode didn't initially have to factor in other-firmware as that's > not a hard requirement on arm32 like it is on arm64 or risc-v. But my > first read of this was that it seems like the RISC-V specific side of > doing Falcon Mode and dealing with the prior stage needs correctly. > Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y). When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and jump_to_image_linux() shall be defined but they are un-necessary for RISC-V. Because the flow of OpenSBI and SPL_OS_BOOT are totally different code flow in board_init_r() of common/spl/spl.c. That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this RISC-V fast boot implementation. Thanks, Rick > -- > Tom
[PATCH 4/4] doc: ae350: Add Fast Boot description
Descript how to boot Kernel with Fast Boot and record booting messages here. Signed-off-by: Rick Chen --- doc/board/AndesTech/ax25-ae350.rst | 140 + 1 file changed, 140 insertions(+) diff --git a/doc/board/AndesTech/ax25-ae350.rst b/doc/board/AndesTech/ax25-ae350.rst index b46f427f4b..01b7159117 100644 --- a/doc/board/AndesTech/ax25-ae350.rst +++ b/doc/board/AndesTech/ax25-ae350.rst @@ -522,3 +522,143 @@ Messages of U-Boot SPL boots Kernel on AE350 board nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering... ~ # + + +Fast-Boot on AE350 +-- +In hope of reducing the boot time, Andes U-Boot is implemented with a feature similar to +U-Boot FALCON mode. The boot flow using this feature, called Fast Boot, initializes memory +with the U-Boot SPL at the first stage, just like what a regular booting process +(i.e. Normal Boot) does in the beginning. Instead of jumping to the U-Boot proper (normal mode) +from OpenSBI before booting kernel, the Fast Boot process jumps directly to kernel to enabl +shorter boot time. + + +Fast-Boot flow +-- +U-Boot SPL --> openSBI --> Linux Kernel + +How to run Fast-Boot on AE350 +--- +1. Copy Kernel Image (arch/riscv/boot/Image) into U-Boot root directory. +2. make ae350_rv[32|64]_spl_fastboot_defconfig and build. +3. linux.itb will be generated here. + + +Messages of Fast-Boot Kernel on AE350 board +--- +U-Boot SPL 2023.01-rc1-00100-gf854773d8a-dirty (Dec 05 2022 - 13:54:20 +0800) +Trying to boot from RAM +[0.00] OF: fdt: Ignoring memory range 0x0 - 0x180 +[0.00] Linux version 5.4.192-18651-gf2d0487a5fb8-dirty (rick@atcsqa06) (gcc version 10.3.0 (2022-05-13_nds64le-linux-glibc-v5d-_experimental)) #2 SMP PREEMPT Thu Oct 13 10:39:07 CST 2022 +[0.00] earlycon: sbi0 at I/O port 0x0 (options '') +[0.00] printk: bootconsole [sbi0] enabled +[0.00] initrd not found or empty - disabling initrd +[0.00] Zone ranges: +[0.00] DMA32[mem 0x0180-0x3fff] +[0.00] Normal empty +[0.00] Movable zone start for each node +[0.00] Early memory node ranges +[0.00] node 0: [mem 0x0180-0x3fff] +[0.00] Initmem setup node 0 [mem 0x0180-0x3fff] +[0.00] SBI specification v0.3 detected +[0.00] SBI implementation ID=0x1 Version=0x1 +[0.00] SBI v0.2 TIME extension detected +[0.00] SBI v0.2 IPI extension detected +[0.00] SBI v0.2 RFENCE extension detected +[0.00] SBI SRST extension detected +[0.00] SBI v0.2 HSM extension detected +[0.00] percpu: Embedded 16 pages/cpu s28120 r8192 d29224 u65536 +[0.00] Built 1 zonelists, mobility grouping on. Total pages: 252500 +[0.00] Kernel command line: console=ttyS0,38400n8 debug loglevel=7 earlycon=sbi +[0.00] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[0.00] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear) +[0.00] Sorting __ex_table... +[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off +[0.00] Memory: 994544K/1024000K available (4565K kernel code, 290K rwdata, 1655K rodata, 7083K init, 189K bss, 29456K reserved, 0K cma-reserved) +[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 +[0.00] rcu: Preemptible hierarchical RCU implementation. +[0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. +[0.00] Tasks RCU enabled. +[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. +[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 +[0.00] NR_IRQS: 72, nr_irqs: 72, preallocated irqs: 0 +[0.00] plic: mapped 71 interrupts with 1 handlers for 2 contexts. +[0.00] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0] +[0.00] clocksource: riscv_clocksource: mask: 0x max_cycles: 0x1bacf917bf, max_idle_ns: 881590412290 ns +[0.91] sched_clock: 64 bits at 60MHz, resolution 16ns, wraps every 4398046511098ns +[0.025459] Console: colour dummy device 40x30 +[0.039116] Calibrating delay loop (skipped), value calculated using timer frequency.. 120.00 BogoMIPS (lpj=60) +[0.070377] pid_max: default: 32768 minimum: 301 +[0.086700] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[0.109186] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) +[0.160697] rcu: Hierarchical SRCU implementation. +[0.181706] smp: Bringing up secondary CPUs ... +[0.195674] smp: Brought up 1 node, 1 CPU +[0.213734] devtmpfs: initialized +[0.247406] random: get_random_u32 called from bucket_table_alloc.isra.0+0x7
[PATCH 3/4] riscv: ae350: Support Fast Boot
Add defconfig for Fast Boot
Signed-off-by: Rick Chen
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 7 ++-
configs/ae350_rv32_spl_fastboot_defconfig | 53 +++
configs/ae350_rv64_spl_fastboot_defconfig | 53 +++
3 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 configs/ae350_rv32_spl_fastboot_defconfig
create mode 100644 configs/ae350_rv64_spl_fastboot_defconfig
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 63a966e092..b5b2b93f76 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -134,7 +134,10 @@ void board_boot_order(u32 *spl_boot_list)
#ifdef CONFIG_SPL_LOAD_FIT
int board_fit_config_name_match(const char *name)
{
- /* boot using first FIT config */
- return 0;
+#if IS_ENABLED(CONFIG_SPL_OPENSBI_OS_BOOT)
+ return strcmp("linux", name);
+#endif
+
+ return -EINVAL;
}
#endif
diff --git a/configs/ae350_rv32_spl_fastboot_defconfig
b/configs/ae350_rv32_spl_fastboot_defconfig
new file mode 100644
index 00..fe9959b75e
--- /dev/null
+++ b/configs/ae350_rv32_spl_fastboot_defconfig
@@ -0,0 +1,53 @@
+CONFIG_RISCV=y
+CONFIG_TEXT_BASE=0x0180
+CONFIG_SYS_MALLOC_LEN=0x8
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SECT_SIZE=0x1000
+CONFIG_DEFAULT_DEVICE_TREE="ae350_32"
+CONFIG_SYS_PROMPT="RISC-V # "
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x200
+CONFIG_SPL=y
+CONFIG_SPL_OPENSBI_OS_BOOT=y
+CONFIG_SYS_LOAD_ADDR=0x10
+CONFIG_TARGET_AX25_AE350=y
+CONFIG_RISCV_SMODE=y
+# CONFIG_AVAILABLE_HARTS is not set
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xf00
+CONFIG_SYS_MONITOR_LEN=786432
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x1000
+CONFIG_SYS_MONITOR_BASE=0x8800
+CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_MAX_SIZE=0x10
+CONFIG_SPL_BSS_START_ADDR=0x40
+CONFIG_SYS_PBSIZE=1050
+CONFIG_SYS_BOOTM_LEN=0x400
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF_TEST=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_BOOTP_PREFER_SERVERIP=y
+CONFIG_CMD_CACHE=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_BOOTP_SEND_HOSTNAME=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_MMC=y
+CONFIG_FTSDC010=y
+CONFIG_FTSDC010_SDIO=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_SYS_FLASH_CFI_WIDTH_16BIT=y
+CONFIG_SYS_CFI_FLASH_STATUS_POLL=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_FTMAC100=y
+CONFIG_BAUDRATE=38400
+CONFIG_SYS_NS16550=y
+CONFIG_SPI=y
+CONFIG_ATCSPI200_SPI=y
+# CONFIG_BINMAN_FDT is not set
diff --git a/configs/ae350_rv64_spl_fastboot_defconfig
b/configs/ae350_rv64_spl_fastboot_defconfig
new file mode 100644
index 00..118d13bcda
--- /dev/null
+++ b/configs/ae350_rv64_spl_fastboot_defconfig
@@ -0,0 +1,53 @@
+CONFIG_RISCV=y
+CONFIG_TEXT_BASE=0x0180
+CONFIG_SYS_MALLOC_LEN=0x8
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SECT_SIZE=0x1000
+CONFIG_DEFAULT_DEVICE_TREE="ae350_64"
+CONFIG_SYS_PROMPT="RISC-V # "
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x200
+CONFIG_SPL=y
+CONFIG_SPL_OPENSBI_OS_BOOT=y
+CONFIG_SYS_LOAD_ADDR=0x10
+CONFIG_TARGET_AX25_AE350=y
+CONFIG_ARCH_RV64I=y
+CONFIG_RISCV_SMODE=y
+# CONFIG_AVAILABLE_HARTS is not set
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xe70
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x1000
+CONFIG_SYS_MONITOR_BASE=0x8800
+CONFIG_BOOTDELAY=3
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_MAX_SIZE=0x10
+CONFIG_SPL_BSS_START_ADDR=0x40
+CONFIG_SYS_PBSIZE=1050
+CONFIG_SYS_BOOTM_LEN=0x400
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF_TEST=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_BOOTP_PREFER_SERVERIP=y
+CONFIG_CMD_CACHE=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_BOOTP_SEND_HOSTNAME=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_MMC=y
+CONFIG_FTSDC010=y
+CONFIG_FTSDC010_SDIO=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_SYS_FLASH_CFI_WIDTH_16BIT=y
+CONFIG_SYS_CFI_FLASH_STATUS_POLL=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_FTMAC100=y
+CONFIG_BAUDRATE=38400
+CONFIG_SYS_NS16550=y
+CONFIG_SPI=y
+CONFIG_ATCSPI200_SPI=y
+# CONFIG_BINMAN_FDT is not set
--
2.17.1
[PATCH 2/4] riscv: dts: Support Fast-Boot
By enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
of default u-boot.itb after compiling. And Lnux Kernel Image will be
appended in linux.itb. Then it can jump to Linux Kernel from openSBI
directly.
Signed-off-by: Rick Chen
---
arch/riscv/dts/binman.dtsi | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/dts/binman.dtsi b/arch/riscv/dts/binman.dtsi
index b8fc8f7f35..ca72719d19 100644
--- a/arch/riscv/dts/binman.dtsi
+++ b/arch/riscv/dts/binman.dtsi
@@ -13,14 +13,27 @@
{
itb {
- filename = "u-boot.itb";
+ filename = CONFIG_SPL_OPENSBI_FIT_NAME;
fit {
- description = "Configuration to load OpenSBI before
U-Boot";
+ description = "Configuration to load OpenSBI before OS";
#address-cells = <1>;
fit,fdt-list = "of-list";
images {
+#ifdef CONFIG_SPL_OPENSBI_OS_BOOT
+ linux {
+ description = "Linux";
+ type = "standalone";
+ os = "Linux";
+ arch = "riscv";
+ compression = "none";
+ load = ;
+ linux_blob: blob-ext {
+ filename = "Image";
+ };
+ };
+#else
uboot {
description = "U-Boot";
type = "standalone";
@@ -33,6 +46,7 @@
filename = "u-boot-nodtb.bin";
};
};
+#endif
opensbi {
description = "OpenSBI fw_dynamic
Firmware";
@@ -72,6 +86,12 @@
fdt = "fdt-SEQ";
#endif
};
+
+ conf-2 {
+ description = "linux";
+ firmware = "opensbi";
+ loadables = "linux";
+ };
};
};
};
--
2.17.1
[PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT
In RISC-V, it only provide normal mode booting currently.
To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
to achieve this feature which will be call Fast-Boot mode. By
enabling SPL_OPENSBI_OS_BOOT, it will generate linux.itb instead
of default u-boot.itb after compiling. It initializes memory with
the U-Boot SPL at the first stage, just like what a regular booting
process (i.e. Normal Boot) does in the beginning. Instead of jumping
to the U-Boot proper from OpenSBI before booting Linux Kernel, the
Fast Boot process jumps directly to Linux Kernel to gain shorter
booting time.
Signed-off-by: Rick Chen
---
common/spl/Kconfig | 14 ++
common/spl/spl_fit.c | 3 ++-
common/spl/spl_opensbi.c | 25 -
3 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 05181bdba3..8805aba1b7 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1509,6 +1509,20 @@ config SPL_OPENSBI_SCRATCH_OPTIONS
Options passed to fw_dynamic, for example SBI_SCRATCH_NO_BOOT_PRINTS
or
SBI_SCRATCH_DEBUG_PRINTS.
+config SPL_OPENSBI_OS_BOOT
+ bool "openSBI Fast Boot"
+ depends on SPL_OPENSBI
+ help
+ Enable this openSBI can jump to Linux Kernel directly.
+
+config SPL_OPENSBI_FIT_NAME
+ string "SPL openSBI fit image name"
+ depends on SPL_OPENSBI
+ default "linux.itb" if SPL_OPENSBI_OS_BOOT
+ default "u-boot.itb"
+ help
+ This will help to generate different fit name accordingly.
+
config SPL_TARGET
string "Addtional build targets for 'make'"
default "spl/u-boot-spl.srec" if RCAR_GEN2
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index c1ed31e367..c5b1dfb3ba 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -363,7 +363,8 @@ static bool os_takes_devicetree(uint8_t os)
case IH_OS_U_BOOT:
return true;
case IH_OS_LINUX:
- return IS_ENABLED(CONFIG_SPL_OS_BOOT);
+ return IS_ENABLED(CONFIG_SPL_OS_BOOT) ||
+ IS_ENABLED(CONFIG_SPL_OPENSBI_OS_BOOT);
default:
return false;
}
diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
index b0f40076c3..83869c6b18 100644
--- a/common/spl/spl_opensbi.c
+++ b/common/spl/spl_opensbi.c
@@ -20,7 +20,7 @@ DECLARE_GLOBAL_DATA_PTR;
struct fw_dynamic_info opensbi_info;
-static int spl_opensbi_find_uboot_node(void *blob, int *uboot_node)
+static int spl_opensbi_find_os_node(void *blob, int *os_node)
{
int fit_images_node, node;
const char *fit_os;
@@ -34,10 +34,9 @@ static int spl_opensbi_find_uboot_node(void *blob, int
*uboot_node)
if (!fit_os)
continue;
- if (genimg_get_os_id(fit_os) == IH_OS_U_BOOT) {
- *uboot_node = node;
- return 0;
- }
+ *os_node = node;
+
+ return 0;
}
return -ENODEV;
@@ -45,8 +44,8 @@ static int spl_opensbi_find_uboot_node(void *blob, int
*uboot_node)
void spl_invoke_opensbi(struct spl_image_info *spl_image)
{
- int ret, uboot_node;
- ulong uboot_entry;
+ int ret, os_node;
+ ulong os_entry;
void (*opensbi_entry)(ulong hartid, ulong dtb, ulong info);
if (!spl_image->fdt_addr) {
@@ -54,22 +53,22 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
hang();
}
- /* Find U-Boot image in /fit-images */
- ret = spl_opensbi_find_uboot_node(spl_image->fdt_addr, _node);
+ /* Find U-Boot or Linux image in /fit-images */
+ ret = spl_opensbi_find_os_node(spl_image->fdt_addr, _node);
if (ret) {
pr_err("Can't find U-Boot node, %d\n", ret);
hang();
}
- /* Get U-Boot entry point */
- ret = fit_image_get_entry(spl_image->fdt_addr, uboot_node,
_entry);
+ /* Get os entry point */
+ ret = fit_image_get_entry(spl_image->fdt_addr, os_node, _entry);
if (ret)
- ret = fit_image_get_load(spl_image->fdt_addr, uboot_node,
_entry);
+ ret = fit_image_get_load(spl_image->fdt_addr, os_node,
_entry);
/* Prepare opensbi_info object */
opensbi_info.magic = FW_DYNAMIC_INFO_MAGIC_VALUE;
opensbi_info.version = FW_DYNAMIC_INFO_VERSION;
- opensbi_info.next_addr = uboot_entry;
+ opensbi_info.next_addr = os_entry;
opensbi_info.next_mode = FW_DYNAMIC_INFO_NEXT_MODE_S;
opensbi_info.options = CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS;
opensbi_info.boot_hart = gd->arch.boot_hart;
--
2.17.1
Re: [PATCH] riscv: use imply instead of select for SPL_SEPARATE_BSS
> From: Zong Li > Sent: Tuesday, November 29, 2022 10:02 AM > To: Sean Anderson > Cc: s...@chromium.org; michal.si...@amd.com; sean.ander...@seco.com; Leo > Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; u-boot@lists.denx.de > Subject: Re: [PATCH] riscv: use imply instead of select for SPL_SEPARATE_BSS > > On Mon, Nov 21, 2022 at 8:17 PM Zong Li wrote: > > > > On Mon, Nov 21, 2022 at 12:00 PM Sean Anderson wrote: > > > > > > On 11/16/22 02:08, Zong Li wrote: > > > > Use imply instead of select, then it can still be disabled by > > > > board-specific defconfig, or be set to n manually. > > > > > > > > Signed-off-by: Zong Li > > > > --- > > > > arch/Kconfig | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/arch/Kconfig b/arch/Kconfig index > > > > ae39716697..102956d24c 100644 > > > > --- a/arch/Kconfig > > > > +++ b/arch/Kconfig > > > > @@ -111,7 +111,7 @@ config RISCV > > > > select SUPPORT_OF_CONTROL > > > > select OF_CONTROL > > > > select DM > > > > - select SPL_SEPARATE_BSS if SPL > > > > + imply SPL_SEPARATE_BSS if SPL > > > > imply DM_SERIAL > > > > imply DM_ETH > > > > imply DM_EVENT > > > > > > Do you have an example of a board which does this? > > > > > > > Hi Sean, > > We'd like to disable 'SPL_SEPARATE_BSS' on our internal platforms that > > don't exist in the mainline. It seems to me that using 'imply' might > > be not only working on the mainline's board, but also making it > > flexible to disable 'SPL_SEPARATE_BSS' by board-specific configuration > > or disable it manually for debug purposes. Hope the idea is good to > > you all. Thanks > > > > Hi all, > Thanks for your reviewing, could I know whether this patch makes sense to you? It's reasonable for me. Thanks, Rick > > > > --Sean
Re: [PATCH] riscv: use imply instead of select for SPL_SEPARATE_BSS
> From: Zong Li > Sent: Wednesday, November 16, 2022 3:09 PM > To: s...@chromium.org; michal.si...@amd.com; sean.ander...@seco.com; Leo > Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; u-boot@lists.denx.de > Cc: Zong Li > Subject: [PATCH] riscv: use imply instead of select for SPL_SEPARATE_BSS > > Use imply instead of select, then it can still be disabled by board-specific > defconfig, or be set to n manually. > > Signed-off-by: Zong Li > --- > arch/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Rick Chen
Re: [PATCH 1/1] riscv: clarify meaning of CONFIG_SBI_V02
> From: Heinrich Schuchardt > Sent: Tuesday, November 08, 2022 11:14 PM > To: Bin Meng > Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; Conor Dooley ; > u-boot@lists.denx.de > Subject: Re: [PATCH 1/1] riscv: clarify meaning of CONFIG_SBI_V02 > > On 11/8/22 16:05, Bin Meng wrote: > > Hi Heinrich, > > > > On Tue, Nov 8, 2022 at 10:53 PM Heinrich Schuchardt > > wrote: > >> > >> Describe that CONFIG_SBI_V02=y does not mean SBI specification v0.2 > >> but v0.2 or later. > >> > >> Signed-off-by: Heinrich Schuchardt > >> > >> --- > >> arch/riscv/Kconfig | 14 +++--- > >> 1 file changed, 7 insertions(+), 7 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH 1/1] riscv: clarify meaning of CONFIG_SBI_V02
Hi Heinrich > From: Heinrich Schuchardt > Sent: Tuesday, November 08, 2022 11:14 PM > To: Bin Meng > Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; Conor Dooley ; > u-boot@lists.denx.de > Subject: Re: [PATCH 1/1] riscv: clarify meaning of CONFIG_SBI_V02 > > On 11/8/22 16:05, Bin Meng wrote: > > Hi Heinrich, > > > > On Tue, Nov 8, 2022 at 10:53 PM Heinrich Schuchardt > > wrote: > >> > >> Describe that CONFIG_SBI_V02=y does not mean SBI specification v0.2 > >> but v0.2 or later. > >> > >> Signed-off-by: Heinrich Schuchardt > >> > >> --- > >> arch/riscv/Kconfig | 14 +++--- > >> 1 file changed, 7 insertions(+), 7 deletions(-) > >> > >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > >> 4d64e9be3f..ebc4bef220 100644 > >> --- a/arch/riscv/Kconfig > >> +++ b/arch/riscv/Kconfig > >> @@ -257,16 +257,16 @@ config SBI_V01 > >>deprecated in future once legacy M-mode software are no longer > >> in use. > >> > >> config SBI_V02 > >> - bool "SBI v0.2 support" > >> + bool "SBI v0.2 or later support" > >> depends on SBI > >> help > >> - This config allows kernel to use SBI v0.2 APIs. SBI v0.2 is more > >> - scalable and extendable to handle future needs for RISC-V > >> supervisor > >> - interfaces. For example, with SBI v0.2 HSM extension, only a > >> single > >> - hart need to boot and enter operating system. The booting hart > >> can > >> - bring up secondary harts one by one afterwards. > >> + The SBI specification introduced the concept of extensions in > >> version > >> + v0.2. With this configuration option U-Boot can detect and use > >> SBI > >> + extensions. With the HSM extension introduced in SBI 0.2, only a > >> + single hart needs to boot and enter the operating system. The > >> booting > >> + hart can bring up secondary harts one by one afterwards. > >> > >> - Choose this option if OpenSBI v0.7 or above release is used > >> together > >> + Choose this option if OpenSBI release v0.7 or above is used > >> + together > >>with U-Boot. > >> > >> endchoice > > > > I remember this option was borrowed from the Linux kernel. Do you plan > > to send patch to Linux kernel too? > > Linux uses a single configuration symbol > CONFIG_RISCV_SBI_V01 "SBI v0.1 support" > > So there is no need for a change there. > > SBI v0.1 is really obsolete. Can we drop support for it in U-Boot? I am fine to remove it. Thanks, Rick
Re: [PATCH v2] riscv: Fix detecting FPU support in standard extension
> From: U-Boot On Behalf Of Yu Chien Peter Lin > Sent: Saturday, November 05, 2022 2:02 PM > To: u-boot@lists.denx.de > Cc: sam...@sholland.org; Peter Yu-Chien Lin(林宇謙) > Subject: [PATCH v2] riscv: Fix detecting FPU support in standard extension > > We should check the string until it hits underscore, in case it searches for > the letters in the custom extension. For example, "rv64imac_xandes" will be > treated as D extension support since there is a "d" in "andes", resulting > illegal instruction caused by initializing FCSR. > > Signed-off-by: Yu Chien Peter Lin > --- > arch/riscv/cpu/cpu.c | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH] riscv: Rename Andes PLIC to PLICSW
> From: Peter Yu-Chien Lin(林宇謙)
> Sent: Tuesday, October 25, 2022 11:04 PM
> To: u-boot@lists.denx.de
> Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志)
> ; Peter Yu-Chien Lin(林宇謙)
> Subject: [PATCH] riscv: Rename Andes PLIC to PLICSW
>
> As PLICSW is used to trigger the software interrupt, we should rename Andes
> PLIC configuration and file name to reflect the usage. This patch also
> updates PLMT and PLICSW compatible strings to be consistent with OpenSBI fdt
> driver.
>
> Signed-off-by: Yu Chien Peter Lin
> ---
> arch/riscv/Kconfig| 6 ++---
> arch/riscv/cpu/ax25/Kconfig | 2 +-
> arch/riscv/dts/ae350-u-boot.dtsi | 2 +-
> arch/riscv/dts/ae350_32.dts | 6 ++---
> arch/riscv/dts/ae350_64.dts | 6 ++---
> arch/riscv/include/asm/global_data.h | 4 +--
> arch/riscv/include/asm/syscon.h | 2 +-
> arch/riscv/lib/Makefile | 2 +-
> .../lib/{andes_plic.c => andes_plicsw.c} | 26 +--
> 9 files changed, 28 insertions(+), 28 deletions(-) rename
> arch/riscv/lib/{andes_plic.c => andes_plicsw.c} (76%)
Reviewed-by: Rick Chen
Re: [PATCH v3 4/4] riscv: Update Microchip MPFS Icicle Kit support
> From: Padmarao Begari > Sent: Thursday, October 27, 2022 2:02 PM > To: u-boot@lists.denx.de; ja...@amarulasolutions.com; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) ; > bmeng...@gmail.com > Cc: cyril.j...@microchip.com; conor.doo...@microchip.com; > valentina.fernandezala...@microchip.com; nagasuresh.re...@microchip.com; > Padmarao Begari > Subject: [PATCH v3 4/4] riscv: Update Microchip MPFS Icicle Kit support > > This patch updates Microchip MPFS Icicle Kit support. For now, add Microchip > QSPI driver and a small 4MB reservation is made at the end of 32-bit DDR to > provide some memory for the HSS to use. > > Signed-off-by: Padmarao Begari > Reviewed-by: Conor Dooley > --- > board/microchip/mpfs_icicle/Kconfig | 7 +++ > configs/microchip_mpfs_icicle_defconfig | 1 + > 2 files changed, 8 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v3 2/4] riscv: dts: Add QSPI NAND device node
> From: Padmarao Begari > Sent: Thursday, October 27, 2022 2:02 PM > To: u-boot@lists.denx.de; ja...@amarulasolutions.com; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) ; > bmeng...@gmail.com > Cc: cyril.j...@microchip.com; conor.doo...@microchip.com; > valentina.fernandezala...@microchip.com; nagasuresh.re...@microchip.com; > Padmarao Begari > Subject: [PATCH v3 2/4] riscv: dts: Add QSPI NAND device node > > Add QSPI NAND device node to the Microchip PolarFire SoC Icicle kit device > tree. > > The Winbond NAND flash memory can be connected to the Icicle Kit by using the > Mikroe Flash 5 click board and the Pi 3 Click shield. > > Signed-off-by: Padmarao Begari > Reviewed-by: Conor Dooley > --- > arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 16 ++++ > 1 file changed, 16 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v3 1/4] riscv: dts: Update memory configuration
> From: Padmarao Begari > Sent: Thursday, October 27, 2022 2:02 PM > To: u-boot@lists.denx.de; ja...@amarulasolutions.com; Rick Jian-Zhi Chen(陳建志) > ; Leo Yu-Chi Liang(梁育齊) ; > bmeng...@gmail.com > Cc: cyril.j...@microchip.com; conor.doo...@microchip.com; > valentina.fernandezala...@microchip.com; nagasuresh.re...@microchip.com; > Padmarao Begari > Subject: [PATCH v3 1/4] riscv: dts: Update memory configuration > > In the v2022.10 Icicle reference design, the seg registers have been changed, > resulting in a required change to the memory map. > A small 4MB reservation is made at the end of 32-bit DDR to provide some > memory for the HSS to use, so that it can cache its payload between reboots > of a specific context. > > Co-developed-by: Conor Dooley > Signed-off-by: Conor Dooley > Signed-off-by: Padmarao Begari > Reviewed-by: Conor Dooley > --- > arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 75 +--- > 1 file changed, 17 insertions(+), 58 deletions(-) Reviewed-by: Rick Chen
[PATCH v2] riscv: ae350: Check firmware_fdt_addr header
Check firmware_fdt_addr header to see if it
is a valid fdt blob.
Signed-off-by: Rick Chen
Reviewed-by: Leo Yu-Chi Liang
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 36f0dd4b0f..08d0c6b264 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -60,7 +60,7 @@ void *board_fdt_blob_setup(int *err)
*err = 0;
if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
- if (gd->arch.firmware_fdt_addr)
+ if (fdt_magic((void *)gd->arch.firmware_fdt_addr) == FDT_MAGIC)
return (void *)(ulong)gd->arch.firmware_fdt_addr;
}
--
2.18.0
Re: [PATCH] riscv: andes_plic.c: use modified IPI scheme
> From: Peter Yu-Chien Lin(林宇謙) > Sent: Friday, October 14, 2022 3:00 PM > To: u-boot@lists.denx.de > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > ; Peter Yu-Chien Lin(林宇謙) > Subject: [PATCH] riscv: andes_plic.c: use modified IPI scheme > > The IPI scheme in OpenSBI has been updated to support 8-core AE350 platform, > the plicsw configuration needs to be modified accordingly. > > Signed-off-by: Yu Chien Peter Lin > --- > arch/riscv/lib/andes_plic.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH] riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+
> From: Bin Meng
> Sent: Monday, October 17, 2022 12:42 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊)
> ; u-boot@lists.denx.de
> Cc: fal...@tinylab.org; Yangjie Zhang
> Subject: [PATCH] riscv: qemu: spl: Fix booting Linux kernel with OpenSBI 1.0+
>
> Since OpenSBI commit bf3ef53bb7f5 ("firmware: Enable FW_PIC by default"),
> OpenSBI runs directly at the load address without any code movement.
> This causes the SPL version of QEMU 'virt' U-Boot does not boot Linux kernel
> anymore. In that case, OpenSBI is loaded and runs at 0x8100, and it
> creates a 512KiB PMP window from that address. When booting the Linux kernel,
> moving kernel to its linking address 0x8020 overlaps the PMP window, and
> a PMP access failure is raised.
>
> Update SPL_OPENSBI_LOAD_ADDR to load OpenSBI to a safe address.
>
> Reported-by: Yangjie Zhang
> Signed-off-by: Bin Meng
> Tested-by: Yangjie Zhang
>
> ---
>
> board/emulation/qemu-riscv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rick Chen
[PATCH] riscv: ae350: Check firmware_fdt_addr header
Check firmware_fdt_addr header to see if it is a valid
fdt blob.
Signed-off-by: Rick Chen
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 36f0dd4..f348066 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -60,7 +60,7 @@ void *board_fdt_blob_setup(int *err)
*err = 0;
if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
- if (gd->arch.firmware_fdt_addr)
+ if (fdt_magic(gd->arch.firmware_fdt_addr) == FDT_MAGIC)
return (void *)(ulong)gd->arch.firmware_fdt_addr;
}
--
2.7.4
Re: [PATCH 1/1] riscv: support building double-float modules
HI Heinrich > >> From: Heinrich Schuchardt > >> Sent: Saturday, October 08, 2022 5:18 PM > >> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > >> > >> Cc: Tom Rini ; u-boot@lists.denx.de; Heinrich > >> Schuchardt > >> Subject: [PATCH 1/1] riscv: support building double-float modules > >> > >> The riscv32 toolchain for GCC-12 provided by kernel.org contains libgcc.a > >> compiled for double-float. To link to it we have to adjust how we build > >> U-Boot. > >> > >> As U-Boot actually does not use floating point at all this should not make > >> a significant difference for the produced binaries. > >> > >> Signed-off-by: Heinrich Schuchardt > >> --- > >> arch/riscv/Kconfig | 14 ++ arch/riscv/Makefile | 17 > >> ++--- > >> 2 files changed, 28 insertions(+), 3 deletions(-) > >> > >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > >> 32a90b83b5..8add95c8ef 100644 > >> --- a/arch/riscv/Kconfig > >> +++ b/arch/riscv/Kconfig > >> @@ -152,6 +152,20 @@ config RISCV_ISA_C > >>when building U-Boot, which results in compressed instructions > >> in the > >>U-Boot binary. > >> > >> +config RISCV_ISA_F > >> + bool "Standard extension for Single-Precision Floating Point" > >> + default y > > > > > > Shall this default y need to depend on RV32 ? > > All RV64 boards that we currently support have the F and D extension and > these extensions are in RV64GC. There is no need to disable the F option > on RV64. > > If you wanted to catch if anybody is using floating point calculation in > U-Boot, we could let it depend on RV32 until we hit another libgcc pitfall. OK, let's keep no change here. Thanks for your explanation. Thanks, Rick > > Best regards > > Heinrich > > > > > Reviewed-by: Rick Chen > > > >> + help > >> + Adds "F" to the ISA string passed to the compiler. > >> + > >> +config RISCV_ISA_D > >> + bool "Standard extension forr Double-Precision Floating Point" > >> + depends on RISCV_ISA_F > >> + default y > >> + help > >> + Adds "D" to the ISA string passed to the compiler and changes the > >> + riscv32 ABI from ilp32 to ipl32d. > >> + > >> config RISCV_ISA_A > >> def_bool y > >> > >> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index > >> 53d1194ffb..d1b6e86dd8 100644 > >> --- a/arch/riscv/Makefile > >> +++ b/arch/riscv/Makefile > >> @@ -5,15 +5,24 @@ > >> > >> ifeq ($(CONFIG_ARCH_RV64I),y) > >> ARCH_BASE = rv64im > >> - ABI = lp64 > >> + ABI_BASE = lp64 > >> endif > >> ifeq ($(CONFIG_ARCH_RV32I),y) > >> ARCH_BASE = rv32im > >> - ABI = ilp32 > >> + ABI_BASE = ilp32 > >> endif > >> ifeq ($(CONFIG_RISCV_ISA_A),y) > >> ARCH_A = a > >> endif > >> +ifeq ($(CONFIG_RISCV_ISA_F),y) > >> + ARCH_F = f > >> +endif > >> +ifeq ($(CONFIG_RISCV_ISA_D),y) > >> + ARCH_D = d > >> +ifeq ($(CONFIG_ARCH_RV32I),y) > >> + ABI_D = d > >> +endif > >> +endif > >> ifeq ($(CONFIG_RISCV_ISA_C),y) > >> ARCH_C = c > >> endif > >> @@ -24,7 +33,9 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) > >> CMODEL = medany > >> endif > >> > >> -RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_C) > >> + > >> +RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_D)$(ARCH_C) > >> +ABI = $(ABI_BASE)$(ABI_D) > >> > >> # Newer binutils versions default to ISA spec version 20191213 which > >> moves some # instructions from the I extension to the Zicsr and Zifencei > >> extensions. > >> --
