Re: [PATCH 1/1] cmd: exception: unaligned data access on RISC-V

[Rick Chen]

Hi Heinrich

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, August 04, 2020 7:10 PM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] cmd: exception: unaligned data access on RISC-V
>
> The command 'exception' can be used to test the handling of exceptions.
>
> Currently the exception command only allows to create an illegal instruction 
> exception on RISC-V.
>
> Provide a sub-command 'exception unaligned' to cause a misaligned load 
> address exception.
>
> Adjust the online help for 'exception undefined'.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/riscv/exception.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/riscv/exception.c b/cmd/riscv/exception.c index 
> 3c8dbbec0e..53159531d9 100644
> --- a/cmd/riscv/exception.c
> +++ b/cmd/riscv/exception.c
> @@ -8,6 +8,17 @@
>  #include 
>  #include 
>
> +static int do_unaligned(struct cmd_tbl *cmdtp, int flag, int argc,
> +   char *const argv[])
> +{
> +   asm volatile (
> +   "auipc a1, 0\n"
> +   "ori   a1, a1, 3\n"
> +   "lwa2, (0)(a1)\n"
> +   );
> +   return CMD_RET_FAILURE;

I suggest that we can modify it as below to print the unaligned
address and data for more debug information.

int ret = 0;
int addr = 0;

asm volatile (
"auipc a1, 0\n"
"ori   %0, a1, 3\n"
"lw%1, (0)(a1)\n"
: "=r" (addr), "=r" (ret)
:
: "memory"
);
printf("unaligned addr 0x%x , ret 0x%x\n",addr,ret);

return CMD_RET_SUCCESS;

So if run in S-Mode, it will work as below:

RISC-V # exception unaligned
unaligned addr 0x3ff92fd7 , ret 0x35e59300
RISC-V #


(gdb) x/4x 0x3ff92fd0
0x3ff92fd0: 0x7ac362ef  0x0597  0x0035e593  0xc5174190
(gdb)


If run in M-Mode, it will work as below:

RISC-V # exception unaligned
Unhandled exception: Load address misaligned
EPC: 3ff92fdc RA: 3ff93032 TVAL: 3ff92fd7
EPC: 9fdc RA: a032 reloc adjusted

### ERROR ### Please RESET the board ###

Thanks,
Rick

> +}
> +
>  static int do_undefined(struct cmd_tbl *cmdtp, int flag, int argc,
> char *const argv[])
>  {
> @@ -16,6 +27,8 @@ static int do_undefined(struct cmd_tbl *cmdtp, int flag, 
> int argc,  }
>
>  static struct cmd_tbl cmd_sub[] = {
> +   U_BOOT_CMD_MKENT(unaligned, CONFIG_SYS_MAXARGS, 1, do_unaligned,
> +"", ""),
> U_BOOT_CMD_MKENT(undefined, CONFIG_SYS_MAXARGS, 1, do_undefined,
>  "", ""),
>  };
> @@ -23,7 +36,8 @@ static struct cmd_tbl cmd_sub[] = {  static char 
> exception_help_text[] =
> "\n"
> "  The following exceptions are available:\n"
> -   "  undefined  - undefined instruction\n"
> +   "  undefined - illegal instruction\n"
> +   "  unaligned - load address misaligned\n"
> ;
>
>  #include 
> --
> 2.27.0

Re: [PATCH 1/1] riscv: remove redundant logical constraint.

[Rick Chen]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, August 04, 2020 5:34 AM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: Anatolij Gustschin; Bin Meng; Sean Anderson; Simon Glass; Lukas Auer; 
> u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] riscv: remove redundant logical constraint.
>
> After
>
> if (ret) return ret;
>
> we know that ret is zero. Don't check it again.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/lib/andes_plic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rick Chen 

Re: [PATCH 1/1] riscv: sifive: fu540: redundant initialization

[Rick Chen]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, August 04, 2020 5:10 AM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: Pragnesh Patel; Bin Meng; u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] riscv: sifive: fu540: redundant initialization
>
> We should not initialize a variable if the value is overwritten before being 
> read.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/cpu/fu540/cache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rick Chen 

Re: [PATCH 1/1] riscv: fix building with CONFIG_SPL_SMP=n

[Rick Chen]

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, August 04, 2020 5:26 AM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: Simon Glass; Anup Patel; Lukas Auer; Bin Meng; Daniel Schwierzeck; 
> u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] riscv: fix building with CONFIG_SPL_SMP=n
>
> Building with CONFIG_SPL_SMP=n results in:
>
> arch/riscv/lib/spl.c: In function ‘jump_to_image_no_args’:
> arch/riscv/lib/spl.c:33:6:
> error: unused variable ‘ret’ [-Werror=unused-variable]
>33 |  int ret;
>   |  ^~~
>
> Define the variable ret as __maybe_unused.
>
> Fixes: 191636e44898 ("riscv: Introduce SPL_SMP Kconfig option for U-Boot
> SPL")
> Fixes: 8c59f2023cc8 ("riscv: add SPL support")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/lib/spl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Rick Chen 

> diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c index 
> c47dcd46ce..ef00ec2bcc 100644
> --- a/arch/riscv/lib/spl.c
> +++ b/arch/riscv/lib/spl.c
> @@ -30,7 +30,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info 
> *spl_image)  {
> typedef void __noreturn (*image_entry_riscv_t)(ulong hart, void *dtb);
> void *fdt_blob;
> -   int ret;
> +   __maybe_unused int ret;
>
>  #if CONFIG_IS_ENABLED(LOAD_FIT) || CONFIG_IS_ENABLED(LOAD_FIT_FULL)
> fdt_blob = spl_image->fdt_addr;
> --
> 2.27.0

Re: [PATCH 2/6] riscv: sifive/fu540: spl: Drop our own version of board_init_f()

[Rick Chen]

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Monday, August 03, 2020 2:09 PM
> To: Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; U-Boot Mailing List
> Cc: Bin Meng
> Subject: [PATCH 2/6] riscv: sifive/fu540: spl: Drop our own version of 
> board_init_f()
>
> From: Bin Meng 
>
> Use the generic board_init_f() provided by the RISC-V library codes.
>
> Signed-off-by: Bin Meng 
> ---

Reviewed-by: Rick Chen 

>
>  board/sifive/fu540/spl.c | 19 +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/board/sifive/fu540/spl.c b/board/sifive/fu540/spl.c index 
> 55325cf..31d315d 100644
> --- a/board/sifive/fu540/spl.c
> +++ b/board/sifive/fu540/spl.c
> @@ -17,7 +17,7 @@
>
>  #define GEM_PHY_RESET  SIFIVE_GENERIC_GPIO_NR(0, 12)
>
> -int init_clk_and_ddr(void)
> +int spl_board_init_f(void)
>  {
> int ret;
>
> @@ -55,20 +55,3 @@ int init_clk_and_ddr(void)
>
> return 0;
>  }
> -
> -void board_init_f(ulong dummy)
> -{
> -   int ret;
> -
> -   ret = spl_early_init();
> -   if (ret)
> -   panic("spl_early_init() failed: %d\n", ret);
> -
> -   arch_cpu_init_dm();
> -
> -   preloader_console_init();
> -
> -   ret = init_clk_and_ddr();
> -   if (ret)
> -   panic("init_clk_and_ddr() failed: %d\n", ret);
> -}
> --
> 2.7.4

Re: [PATCH 1/6] riscv: Call spl_board_init_f() in the generic SPL board_init_f()

[Rick Chen]

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Monday, August 03, 2020 2:09 PM
> To: Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; U-Boot Mailing List
> Cc: Bin Meng
> Subject: [PATCH 1/6] riscv: Call spl_board_init_f() in the generic SPL 
> board_init_f()
>
> From: Bin Meng 
>
> The generic SPL version of board_init_f() should give a call to board 
> specific codes to initialize board in the SPL phase.
>
> Signed-off-by: Bin Meng 
> ---

Reviewed-by: Rick Chen 

>
>  arch/riscv/include/asm/spl.h | 7 +++
>  arch/riscv/lib/spl.c | 9 +
>  2 files changed, 16 insertions(+)
>
> diff --git a/arch/riscv/include/asm/spl.h b/arch/riscv/include/asm/spl.h 
> index 45c03fb..1487f2d 100644
> --- a/arch/riscv/include/asm/spl.h
> +++ b/arch/riscv/include/asm/spl.h
> @@ -28,4 +28,11 @@ enum {
> BOOT_DEVICE_NONE
>  };
>
> +/**
> + * spl_board_init_f() - initialize board in the SPL phase
> + *
> + * @return 0 if succeeded, -ve on error  */ int spl_board_init_f(void);
> +
>  #endif
> diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c index 
> c47dcd4..e24ec5a 100644
> --- a/arch/riscv/lib/spl.c
> +++ b/arch/riscv/lib/spl.c
> @@ -13,6 +13,11 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +__weak int spl_board_init_f(void)
> +{
> +   return 0;
> +}
> +
>  __weak void board_init_f(ulong dummy)
>  {
> int ret;
> @@ -24,6 +29,10 @@ __weak void board_init_f(ulong dummy)
> arch_cpu_init_dm();
>
> preloader_console_init();
> +
> +   ret = spl_board_init_f();
> +   if (ret)
> +   panic("spl_board_init_f() failed: %d\n", ret);
>  }
>
>  void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
> --
> 2.7.4
>

Re: [PATCH v2 1/1] riscv: additional crash information

[Rick Chen]

   regs->t0, regs->t1, regs->t2);
> +   printf("S0:  " REG_FMT " S1:  " REG_FMT " A0:  " REG_FMT "\n",
> +  regs->s0, regs->s1, regs->a0);
> +   printf("A1:  " REG_FMT " A2:  " REG_FMT " A3:  " REG_FMT "\n",
> +  regs->a1, regs->a2, regs->a3);
> +   printf("A4:  " REG_FMT " A5:  " REG_FMT " A6:  " REG_FMT "\n",
> +  regs->a4, regs->a5, regs->a6);
> +   printf("A7:  " REG_FMT " S2:  " REG_FMT " S3:  " REG_FMT "\n",
> +  regs->a7, regs->s2, regs->s3);
> +   printf("S4:  " REG_FMT " S5:  " REG_FMT " S6:  " REG_FMT "\n",
> +  regs->s4, regs->s5, regs->s6);
> +   printf("S7:  " REG_FMT " S8:  " REG_FMT " S9:  " REG_FMT "\n",
> +  regs->s7, regs->s8, regs->s9);
> +   printf("S10: " REG_FMT " S11: " REG_FMT " T3:  " REG_FMT "\n",
> +  regs->s10, regs->s11, regs->t3);
> +   printf("T4:  " REG_FMT " T5:  " REG_FMT " T6:  " REG_FMT "\n\n",
> +  regs->t4, regs->t5, regs->t6);
>  #endif
>  }
>
> @@ -69,8 +76,14 @@ static void _exit_trap(ulong code, ulong epc, ulong tval, 
> struct pt_regs *regs)
> else
> printf("Unhandled exception code: %ld\n", code);
>
> -   printf("EPC: " REG_FMT " TVAL: " REG_FMT "\n", epc, tval);
> +   printf("EPC: " REG_FMT " RA: " REG_FMT " TVAL: " REG_FMT "\n",
> +  epc, regs->ra, tval);
> +   if (gd->flags & GD_FLG_RELOC)
> +   printf("EPC: " REG_FMT " RA: " REG_FMT " reloc adjusted\n\n",
> +  epc - gd->reloc_off, regs->ra - gd->reloc_off);
> +
> show_regs(regs);
> +   show_efi_loaded_images(epc);
> hang();
>  }
>
> --

Reviewed-by: Rick Chen 

Re: [PATCH v5 0/5] add DM based reset driver for SiFive SoC's

[Rick Chen]

 於 2020年8月3日 週一 上午11:05寫道：
>
>
>
> -Original Message-
> From: Sagar Kadam [mailto:sagar.ka...@sifive.com]
> Sent: Friday, July 31, 2020 9:15 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); Paul Walmsley ( Sifive); pal...@dabbelt.com; 
> anup.pa...@wdc.com; atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel; 
> bin.m...@windriver.com; ja...@amarulasolutions.com; s...@chromium.org; 
> twoer...@gmail.com; mbrug...@suse.com; eugeniy.palt...@synopsys.com; 
> sean...@gmail.com; patr...@blueri.se; nsaenzjulie...@suse.de; 
> weijie@mediatek.com; feste...@gmail.com
> Subject: RE: [PATCH v5 0/5] add DM based reset driver for SiFive SoC's
>
> Hi Rick,
>
> > -Original Message-
> > From: Sagar Kadam 
> > Sent: Wednesday, July 29, 2020 3:06 PM
> > To: u-boot@lists.denx.de
> > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > ; pal...@dabbelt.com; anup.pa...@wdc.com;
> > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > ; bin.m...@windriver.com;
> > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > mbrug...@suse.com; eugeniy.palt...@synopsys.com; sean...@gmail.com;
> > patr...@blueri.se; nsaenzjulie...@suse.de; weijie@mediatek.com;
> > feste...@gmail.com; Sagar Kadam 
> > Subject: [PATCH v5 0/5] add DM based reset driver for SiFive SoC's
> >
> > The FU540-C000 support in U-Boot is missing DM based reset driver, and
> > is handling reset's to sub-system within the prci driver itself.
> > The series here adds a generic DM reset driver for SiFive SoC's so as
> > to leverage the U-Boot's reset framework and binds the reset driver with 
> > prci driver.
> > The PRCI driver takes care of triggering the consumers reset signals
> > appropriately.
> >
> > Patch 1: Add necessary dt indexes for device reset register.
> > Patch 2: Update macro's to use common dt indexes from binding header.
> > Patch 3: Add reset producer and consumer entries within the device tree.
> > Patch 4: Add reset dm driver and bind it within prci module.
> > Patch 5: Add Kconfig, Makefile entries and enable the driver
> >
> > This series is re-based on u-boot-riscv top commit 3b191c56c841
> > ("Merge branch '2020-07-28-Kconfig-migrations'")
> >
> > History:
> > ==
> > V5:
> > -Rebased the series on u-boot-riscv/master.
> >
>
> A gentle reminder to pull in this series.

Applied to u-boot-riscv/master!

Thanks,
Rick

Re: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's

[Rick Chen]

Hi Sagar

> From: Sagar Kadam [mailto:sagar.ka...@sifive.com]
> Sent: Tuesday, July 28, 2020 11:19 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); Paul Walmsley ( Sifive); pal...@dabbelt.com; 
> anup.pa...@wdc.com; atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel; 
> bin.m...@windriver.com; ja...@amarulasolutions.com; s...@chromium.org; 
> twoer...@gmail.com; patr...@blueri.se; mbrug...@suse.com; 
> eugeniy.palt...@synopsys.com; weijie@mediatek.com; 
> nsaenzjulie...@suse.de; feste...@gmail.com; sean...@gmail.com
> Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
>
> Hello Rick,
>
> > -Original Message-
> > From: Sagar Kadam
> > Sent: Monday, July 27, 2020 8:56 PM
> > To: u-boot@lists.denx.de
> > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > ; pal...@dabbelt.com; anup.pa...@wdc.com;
> > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > ; bin.m...@windriver.com;
> > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > weijie@mediatek.com; nsaenzjulie...@suse.de; feste...@gmail.com;
> > sean...@gmail.com
> > Subject: RE: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> >
> > Hi Rick,
> > > -Original Message-
> > > From: Sagar Kadam 
> > > Sent: Friday, July 24, 2020 2:17 PM
> > > To: u-boot@lists.denx.de
> > > Cc: r...@andestech.com; Paul Walmsley ( Sifive)
> > > ; pal...@dabbelt.com;
> > anup.pa...@wdc.com;
> > > atish.pa...@wdc.com; lu...@denx.de; Pragnesh Patel
> > > ; bin.m...@windriver.com;
> > > ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com;
> > > patr...@blueri.se; mbrug...@suse.com; eugeniy.palt...@synopsys.com;
> > > weijie@mediatek.com; nsaenzjulie...@suse.de;
> > feste...@gmail.com;
> > > sean...@gmail.com; Sagar Kadam 
> > > Subject: [PATCH v4 0/5] add DM based reset driver for SiFive SoC's
> > >
> > > The FU540-C000 support in U-Boot is missing DM based reset driver,
> > > and is handling reset's to sub-system within the prci driver itself.
> > > The series here adds a generic DM reset driver for SiFive SoC's so
> > > as to leverage the U-Boot's reset framework and binds the reset
> > > driver with prci driver.
> > > The PRCI driver takes care of triggering the consumers reset signals
> > > appropriately.
> > >
> > > Patch 1: Add necessary dt indexes for device reset register.
> > > Patch 2: Update macro's to use common dt indexes from binding header.
> > > Patch 3: Add reset producer and consumer entries within the device tree.
> > > Patch 4: Add reset dm driver and bind it within prci module.
> > > Patch 5: Add Kconfig, Makefile entries and enable the driver
> > >
> > > This series is re-based on mainline U-Boot commit 5d3a21df6694
> > > ("Merge
> > tag
> > > 'dm-pull-20jul20' of git://git.denx.de/u-boot-dm") and depends on
> > > [1]
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=190862
> > >
> >
> > I have rebased this series on u-boot/master.
> > Can you please pull it and let me know if any issues are there.
> >
> It seems that u-boot/master is moved ahead and the commit on which this 
> series was based is reverted "Revert "Merge tag 'dm-pull-20jul20' of 
> git://git.denx.de/u-boot-dm""
> and will again conflict considering other patch's that are merged in 
> u-boot/master.
> I can rebase it again, but would like to know what you would prefer me to 
> rebase on u-boot/master or  u-boot-riscv/master?

Yes, it conflict again.
Applying: configs: reset: fu540: enable dm reset framework for SiFive
error: patch failed: configs/sifive_fu540_defconfig:21
error: configs/sifive_fu540_defconfig: patch does not apply
Patch failed at 0001 configs: reset: fu540: enable dm reset framework for SiFive

You can rebase on u-boot-riscv/master.

Thanks,
Rick

>
> Thanks & BR,
> Sagar
>
> > Thanks & BR,
> > Sagar
> >
> > > History:
> > > ==
> > > V4:
> > > -Rebased the series to u-boot/master.
> > >
> > > V3:
> > > -Add reset indexes in separate dt binding header instead of
> > > updating the clock dt binding header which is synced from Linux
> > >
> > > V2:
> > > -Removed extra character in commit log of 2nd patch
> > >
> > > V1:
> > > -Base version.
> > >
> > > Sagar Shrikant Kadam (5):
> > >   dt-bindings: prci: add indexes for reset signals available in prci
> > >   fu540: prci: use common reset indexes defined in binding header
> > >   fu540: dtsi: add reset producer and consumer entries
> > >   sifive: reset: add DM based reset driver for SiFive SoC's
> > >   configs: reset: fu540: enable dm reset framework for SiFive
> > >
> > >  arch/riscv/dts/fu540-c000-u-boot.dtsi |  12 +++
> > >  arch/riscv/include/asm/arch-fu540/reset.h |  13 +++
> > >  configs/sifive_fu540_defconfig|   2 +
> > >  drivers/clk/sifive/fu540-prci.c   |  90 ++--
> > >  drivers/reset/Kconfig |   9 ++
> > >  drivers/re

Re: [PATCH 1/6] riscv: Rework riscv timer driver to only support S-mode

[Rick Chen]

Hi Sean

> The riscv-timer driver currently serves as a shim for several riscv timer
> drivers. This is not too desirable because it bypasses the usual timer
> selection via the driver model. There is no easy way to specify an
> alternate timing driver, or have the tick rate depend on the cpu's
> configured frequency. The timer drivers also do not have device structs,
> and so have to rely on storing parameters in gd_t. Lastly, there is no
> initialization call, so driver init is done in the same function which
> reads the time. This can result in confusing error messages. To a user, it
> looks like the driver failed when trying to read the time, whereas it may
> have failed while initializing.
>
> This patch removes the shim functionality from the riscv-timer driver, and
> has it instead implement the former rdtime.c timer driver. This is because
> existing u-boot users who pass in a device tree (e.g. qemu) do not create a
> timer device for S-mode u-boot. The existing behavior of creating the
> riscv-timer device in the riscv cpu driver must be kept. The actual reading
> of the CSRs has been redone in the style of Linux's get_cycles64.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  arch/riscv/lib/Makefile |  1 -
>  arch/riscv/lib/rdtime.c | 38 
>  drivers/timer/Kconfig   |  6 +++---
>  drivers/timer/riscv_timer.c | 39 +++--
>  4 files changed, 23 insertions(+), 61 deletions(-)
>  delete mode 100644 arch/riscv/lib/rdtime.c
>
> diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> index 6c503ff2b2..10ac5b06d3 100644
> --- a/arch/riscv/lib/Makefile
> +++ b/arch/riscv/lib/Makefile
> @@ -15,7 +15,6 @@ obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
>  obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
>  obj-$(CONFIG_ANDES_PLMT) += andes_plmt.o
>  else
> -obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
>  obj-$(CONFIG_SBI) += sbi.o
>  obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
>  endif
> diff --git a/arch/riscv/lib/rdtime.c b/arch/riscv/lib/rdtime.c
> deleted file mode 100644
> index e128d7fce6..00
> --- a/arch/riscv/lib/rdtime.c
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2018, Anup Patel 
> - * Copyright (C) 2018, Bin Meng 
> - *
> - * The riscv_get_time() API implementation that is using the
> - * standard rdtime instruction.
> - */
> -
> -#include 
> -
> -/* Implement the API required by RISC-V timer driver */
> -int riscv_get_time(u64 *time)
> -{
> -#ifdef CONFIG_64BIT
> -   u64 n;
> -
> -   __asm__ __volatile__ (
> -   "rdtime %0"
> -   : "=r" (n));
> -
> -   *time = n;
> -#else
> -   u32 lo, hi, tmp;
> -
> -   __asm__ __volatile__ (
> -   "1:\n"
> -   "rdtimeh %0\n"
> -   "rdtime %1\n"
> -   "rdtimeh %2\n"
> -   "bne %0, %2, 1b"
> -   : "=&r" (hi), "=&r" (lo), "=&r" (tmp));
> -
> -   *time = ((u64)hi << 32) | lo;
> -#endif
> -
> -   return 0;
> -}

config RISCV_RDTIME in arch/riscv/Kconfig shall be removed meanwhile.

Thanks,
Rick

> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
> index 637024445c..b85fa33e47 100644
> --- a/drivers/timer/Kconfig
> +++ b/drivers/timer/Kconfig
> @@ -144,10 +144,10 @@ config OMAP_TIMER
>
>  config RISCV_TIMER
> bool "RISC-V timer support"
> -   depends on TIMER && RISCV
> +   depends on TIMER && RISCV_SMODE
> help
> - Select this to enable support for the timer as defined
> - by the RISC-V privileged architecture spec.
> + Select this to enable support for a generic RISC-V S-Mode timer
> + driver.
>
>  config ROCKCHIP_TIMER
> bool "Rockchip timer support"
> diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
> index 9f9f070e0b..449fcfcfd5 100644
> --- a/drivers/timer/riscv_timer.c
> +++ b/drivers/timer/riscv_timer.c
> @@ -1,36 +1,37 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> + * Copyright (C) 2020, Sean Anderson 
>   * Copyright (C) 2018, Bin Meng 
> + * Copyright (C) 2018, Anup Patel 
> + * Copyright (C) 2012 Regents of the University of California
>   *
> - * RISC-V privileged architecture defined generic timer driver
> + * RISC-V architecturally-defined generic timer driver
>   *
> - * This driver relies on RISC-V platform codes to provide the essential API
> - * riscv_get_time() which is supposed to return the timer counter as defined
> - * by the RISC-V privileged architecture spec.
> - *
> - * This driver can be used in both M-mode and S-mode U-Boot.
> + * This driver provides generic timer support for S-mode U-Boot.
>   */
>
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
> -
> -/**
> - * riscv_get_time() - get the timer counter
> - *
> - * Platform codes should provide this API in order to make this driver 
> function.
> - *
> - * @time:  the 64-bit timer count  as defined by the RISC-V privileged

Re: [PATCH 1/1] mtd: cfi_flash: read device tree correctly

[Rick Chen]

Hi Heinrich

> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heinrich 
> Schuchardt
> Sent: Tuesday, July 21, 2020 10:51 AM
> To: Stefan Roese
> Cc: Simon Glass; u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] mtd: cfi_flash: read device tree correctly
>
> dev_read_size_cells() and dev_read_addr_cells() do not walk up the device 
> tree to find the number of cells. On error they return 1 and 2 respectively. 
> On qemu_arm64_defconfig this leads to the incorrect detection of address of 
> the second flash bank as 0x400 instead of 0x400.
>
> When running
>
> qemu-system-aarch64 -machine virt -bios u-boot.bin \
> -cpu cortex-a53 -nographic \
> -drive if=pflash,format=raw,index=1,file=envstore.img
>
> the command 'saveenv' fails with
>
> Saving Environment to Flash... Error: start and/or end address not on
> sector boundary
> Error: start and/or end address not on sector boundary
> Failed (1)
>
> due to this incorrect address.
>
> Use function fdtdec_get_addr_size_auto_noparent() to read the array of flash 
> banks from the device tree.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/mtd/cfi_flash.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index 
> b7289ba539..dfa104bcf0 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -2469,28 +2469,24 @@ unsigned long flash_init(void)  static int 
> cfi_flash_probe(struct udevice *dev)  {
> const fdt32_t *cell;
> -   int addrc, sizec;
> -   int len, idx;
> -
> -   addrc = dev_read_addr_cells(dev);
> -   sizec = dev_read_size_cells(dev);
> +   int len;
>
> /* decode regs; there may be multiple reg tuples. */
> cell = dev_read_prop(dev, "reg", &len);
> if (!cell)
> return -ENOENT;
> -   idx = 0;
> -   len /= sizeof(fdt32_t);
> -   while (idx < len) {
> +
> +   for (cfi_flash_num_flash_banks = 0; ; ++cfi_flash_num_flash_banks) {
> phys_addr_t addr;
>
> -   addr = dev_translate_address(dev, cell + idx);
> +   addr = fdtdec_get_addr_size_auto_noparent(
> +   gd->fdt_blob, dev_of_offset(dev), "reg",
> +   cfi_flash_num_flash_banks, NULL, false);
> +   if (addr == FDT_ADDR_T_NONE)
> +   break;
>
> flash_info[cfi_flash_num_flash_banks].dev = dev;
> flash_info[cfi_flash_num_flash_banks].base = addr;
> -   cfi_flash_num_flash_banks++;
> -
> -   idx += addrc + sizec;
> }
> gd->bd->bi_flashstart = flash_info[0].base;
>
> --
> 2.27.0
>

This patch remind me that I have encounter flash bank detection
problem on AE350 platform a period time ago.
And have commit a patch to work around this problem as below:

commit cca8b1e5b20cdab7299a5ee7139e70783f73ccdf

riscv: dts: Add #address-cells and #size-cells in nor node

Those are required for cfi-flash driver to get correct address information.
Also modify size description correctly.

With this patch, there is unnecessary to re-declaration address-cells
and size-cells in nor node indeed.

Tested-by: Rick Chen 

Thanks,
Rick

Re: [PATCH v4] riscv: Make SiFive HiFive Unleashed board boot again

[Rick Chen]

Hi Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Friday, July 24, 2020 11:26 AM
> To: Leo Yu-Chi Liang(梁育齊); Rick Jian-Zhi Chen(陳建志)
> Cc: U-Boot Mailing List
> Subject: Re: [PATCH v4] riscv: Make SiFive HiFive Unleashed board boot again
>
> Hi Rick,
>
> On Tue, Jul 21, 2020 at 4:30 PM Leo Liang  wrote:
> >
> > On Sun, Jul 19, 2020 at 11:17:07PM -0700, Bin Meng wrote:
> > > From: Bin Meng 
> > >
> > > Commit 40686c394e53 ("riscv: Clean up IPI initialization code")
> > > caused U-Boot failed to boot on SiFive HiFive Unleashed board.
> > >
> > > The codes inside arch_cpu_init_dm() may call U-Boot timer APIs
> > > before the call to riscv_init_ipi(). At that time the timer register
> > > base (e.g.: the SiFive CLINT device in this case) is unknown yet.
> > >
> > > It might be the name riscv_init_ipi() that misleads people to only
> > > consider it is related to IPI, but in fact the timer capability is
> > > provided by the same SiFive CLINT device that provides the IPI.
> > > Timer capability is needed for both UP and SMP.
> > >
> > > Considering that the original refactor does have benefits, that it
> > > makes the IPI code more similar to U-Boot initialization idioms.
> > > It also removes some quite ugly macros. Let's do the minimal revert
> > > instead of a complete revert, plus a fixes to arch_cpu_init_dm() to
> > > consider the SPL case.
> > >
> > > Fixes: 40686c394e53 ("riscv: Clean up IPI initialization code")
> > > Signed-off-by: Bin Meng 
> > > Reviewed-by: Sean Anderson 
> > > ---
> > >
> > > Changes in v4:
> > > - Include Sean's "Reviewed-by" tag
> > >
> > > Changes in v3:
> > > - Simply call riscv_init_ipi() in clint timer functions to avoid
> > >   some duplications
> > >
> > > Changes in v2:
> > > - Do the minimal partial revert instead of a complete revert, enough
> > >   to make HiFive Unleashed board boot again.
> > >
> > >  arch/riscv/cpu/cpu.c  |  2 +-
> > >  arch/riscv/lib/sifive_clint.c | 16 
> > >  common/spl/spl_opensbi.c  |  5 -
> > >  3 files changed, 13 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c index
> > > bbd6c15..bfa2d4a 100644
> > > --- a/arch/riscv/cpu/cpu.c
> > > +++ b/arch/riscv/cpu/cpu.c
> > > @@ -107,7 +107,7 @@ int arch_cpu_init_dm(void)  #endif
> > >   }
> > >
> > > -#ifdef CONFIG_SMP
> > > +#if CONFIG_IS_ENABLED(SMP)
> > >   ret = riscv_init_ipi();
> > >   if (ret)
> > >   return ret;
> > > diff --git a/arch/riscv/lib/sifive_clint.c
> > > b/arch/riscv/lib/sifive_clint.c index 78fc6c8..b9a2c64 100644
> > > --- a/arch/riscv/lib/sifive_clint.c
> > > +++ b/arch/riscv/lib/sifive_clint.c
> > > @@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
> > >
> > >  int riscv_get_time(u64 *time)
> > >  {
> > > + /* ensure timer register base has a sane value */
> > > + riscv_init_ipi();
> > > +
> > >   *time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
> > >
> > >   return 0;
> > > @@ -33,6 +36,9 @@ int riscv_get_time(u64 *time)
> > >
> > >  int riscv_set_timecmp(int hart, u64 cmp)  {
> > > + /* ensure timer register base has a sane value */
> > > + riscv_init_ipi();
> > > +
> > >   writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint,
> > > hart));
> > >
> > >   return 0;
> > > @@ -40,11 +46,13 @@ int riscv_set_timecmp(int hart, u64 cmp)
> > >
> > >  int riscv_init_ipi(void)
> > >  {
> > > - long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
> > > + if (!gd->arch.clint) {
> > > + long *ret =
> > > + syscon_get_first_range(RISCV_SYSCON_CLINT);
> > >
> > > - if (IS_ERR(ret))
> > > - return PTR_ERR(ret);
> > > - gd->arch.clint = ret;
> > > + if (IS_ERR(ret))
> > > + return PTR_ERR(ret);
> > > + gd->arch.clint = ret;
> > > + }
> > >
> > >   return 0;
> > >  }
> > > diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
> > > index 3440bc0..14f335f 100644
> > > --- a/common/spl/spl_opensbi.c
> > > +++ b/common/spl/spl_opensbi.c
> > > @@ -79,11 +79,6 @@ void spl_invoke_opensbi(struct spl_image_info 
> > > *spl_image)
> > >   invalidate_icache_all();
> > >
> > >  #ifdef CONFIG_SPL_SMP
> > > - /* Initialize the IPI before we use it */
> > > - ret = riscv_init_ipi();
> > > - if (ret)
> > > - hang();
> > > -
> > >   /*
> > >* Start OpenSBI on all secondary harts and wait for acknowledgment.
> > >*
> > > --
> > > 2.7.4
> > >
> >
> > Tested-by: Leo Liang 
>
> Could we get this applied soon, since it's broken in u-boot/master?

OK. I am preparing to send a PR later today.

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH v3 5/5] configs: reset: fu540: enable dm reset framework for SiFive SoC

[Rick Chen]

Hi Sagar

> From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> Sent: Friday, July 10, 2020 4:38 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); paul.walms...@sifive.com; pal...@dabbelt.com; 
> anup.pa...@wdc.com; atish.pa...@wdc.com; lu...@denx.de; 
> pragnesh.pa...@sifive.com; bin.m...@windriver.com; 
> ja...@amarulasolutions.com; s...@chromium.org; twoer...@gmail.com; 
> abrod...@synopsys.com; eugeniy.palt...@synopsys.com; patr...@blueri.se; 
> weijie@mediatek.com; feste...@gmail.com; Sagar Shrikant Kadam
> Subject: [PATCH v3 5/5] configs: reset: fu540: enable dm reset framework for 
> SiFive SoC
>
> Add necessary defconfig and Kconfig entries to enable SiFive SoC's reset 
> driver so as to utilise U-Boot's reset framework.
>
> Signed-off-by: Sagar Shrikant Kadam 
> Reviewed-by: Pragnesh Patel 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
> ---
>  configs/sifive_fu540_defconfig | 2 ++
>  drivers/reset/Kconfig  | 9 +
>  drivers/reset/Makefile | 1 +
>  3 files changed, 12 insertions(+)
>
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig 
> index 32347c2..12f2469 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -20,3 +20,5 @@ CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SPL_CLK=y
>  CONFIG_DM_MTD=y
> +CONFIG_SPL_DM_RESET=y
> +CONFIG_DM_RESET=y
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index 
> 88d3be1..627f8e8 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -148,4 +148,13 @@ config RESET_IMX7
> help
>   Support for reset controller on i.MX7/8 SoCs.
>
> +config RESET_SIFIVE
> +   bool "Reset Driver for SiFive SoC's"
> +   depends on DM_RESET && CLK_SIFIVE_FU540_PRCI && TARGET_SIFIVE_FU540
> +   default y
> +   help
> + PRCI module within SiFive SoC's provides mechanism to reset
> + different hw blocks like DDR, gemgxl. With this driver we leverage
> + U-Boot's reset framework to reset these hardware blocks.
> +
>  endmenu
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index 
> 0a044d5..e3c27c4 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_RESET_MTMIPS) += reset-mtmips.o
>  obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
>  obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o
>  obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
> +obj-$(CONFIG_RESET_SIFIVE) += reset-sifive.o

This patch conflicts with u-boot/master, please rebase.

Applying: dt-bindings: prci: add indexes for reset signals available in prci
Applying: fu540: prci: use common reset indexes defined in binding header
Applying: fu540: dtsi: add reset producer and consumer entries
Applying: sifive: reset: add DM based reset driver for SiFive SoC's
Applying: configs: reset: fu540: enable dm reset framework for SiFive SoC
error: patch failed: drivers/reset/Kconfig:148
error: drivers/reset/Kconfig: patch does not apply
error: patch failed: drivers/reset/Makefile:23
error: drivers/reset/Makefile: patch does not apply
Patch failed at 0005 configs: reset: fu540: enable dm reset framework
for SiFive SoC

Thanks,
Rick

Re: [PATCH v5 0/6] riscv: sifive/fu540: SPI boot

[Rick Chen]

Hi Jagan

> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: Tuesday, July 21, 2020 2:26 PM
> To: Rick Jian-Zhi Chen(陳建志); Atish Patra; Palmer Dabbelt; Bin Meng; Paul 
> Walmsley; Anup Patel; Sagar Kadam
> Cc: U-Boot-Denx; linux-amarula
> Subject: Re: [PATCH v5 0/6] riscv: sifive/fu540: SPI boot
>
> Hi Rick,
>
> On Wed, Jul 15, 2020 at 3:39 PM Jagan Teki  wrote:
> >
> > Updated series with boot device detection directly on spl_boot_device
> > function instead of having separate board driver.
> >
> > Changes for v5:
> > - rebase on master
> > Changes for v4:
> > - fix typo and unneeded configs.
> > Changes for v3:
> > - fixed env definitions build
> > - added boot device detection in board Changes for v2:
> > - fu540 board driver
> > - runtime bootmode detection
> > - rebase on Pragnesh v11 series
> >
> > Any inputs?
> > Jagan.
> >
> > Jagan Teki (6):
> >   sifive: fu540: Add runtime boot mode detection
> >   sifive: fu540: Add Booting from SPI
> >   env: Enable SPI flash env for SiFive FU540
> >   sifive: fu540: Mark the default env as SPI flash
> >   sifive: fu540: Add boot flash script offset, size
> >   sifive: fu540: Enable SF distro bootcmd
> >
> >  arch/riscv/cpu/fu540/Kconfig  | 13 ++
> >  .../dts/hifive-unleashed-a00-u-boot.dtsi  | 12 ++
> >  board/sifive/fu540/Kconfig|  1 +
> >  board/sifive/fu540/fu540.c| 25 ---
> >  configs/sifive_fu540_defconfig|  4 ++
> >  doc/board/sifive/fu540.rst| 41 +++
> >  include/configs/sifive-fu540.h|  7 +++-
> >  7 files changed, 96 insertions(+), 7 deletions(-)
> >
> > --
> > 2.25.1
> >
>
> Any chance to pick this?

Applied to u-boot-riscv/master !

Thanks,
Rick

>
> Jagan.

Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver

[Rick Chen]

Hi Pragnesh

> Hi Rick,
>
> Any comments on this patch ?

Applied to u-boot-riscv/master !

Thanks,
Rick

> >From: U-Boot  On Behalf Of Pragnesh Patel
> >Sent: 24 June 2020 13:14
> >To: Bin Meng ; Rick Chen 
> >Cc: U-Boot Mailing List ; Atish Patra
> >; palmerdabb...@google.com; Paul Walmsley ( Sifive)
> >; Anup Patel ; Sagar
> >Kadam ; Palmer Dabbelt ;
> >Jagan Teki ; rick ; Alan
> >Kao 
> >Subject: RE: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
> >
> >Hi Rick,
> >
> >>-Original Message-
> >>From: Bin Meng 
> >>Sent: 24 June 2020 13:04
> >>To: Rick Chen 
> >>Cc: Pragnesh Patel ; U-Boot Mailing List  >>b...@lists.denx.de>; Atish Patra ;
> >>palmerdabb...@google.com; Paul Walmsley ( Sifive)
> >>; Anup Patel ; Sagar
> >>Kadam ; Palmer Dabbelt
> >;
> >>Jagan Teki ; rick ;
> >>Alan Kao 
> >>Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
> >>
> >>[External Email] Do not click links or attachments unless you recognize
> >>the sender and know the content is safe
> >>
> >>Hi Rick,
> >>
> >>On Wed, Jun 24, 2020 at 2:26 PM Rick Chen  wrote:
> >>>
> >>> Hi Bin
> >>>
> >>> > Hi Rick,
> >>> >
> >>> > On Wed, Jun 24, 2020 at 1:24 PM Pragnesh Patel
> >>> >  wrote:
> >>> > >
> >>> > > Hi Rick,
> >>> > >
> >>> > > >-Original Message-
> >>> > > >From: Rick Chen 
> >>> > > >Sent: 24 June 2020 10:44
> >>> > > >To: Pragnesh Patel 
> >>> > > >Cc: U-Boot Mailing List ; Atish Patra
> >>> > > >; palmerdabb...@google.com; Bin Meng
> >>> > > >; Paul Walmsley ( Sifive)
> >>> > > >; Anup Patel ;
> >>> > > >Sagar Kadam ; Palmer Dabbelt
> >>> > > >; Jagan Teki ;
> >>> > > >rick ; Alan Kao 
> >>> > > >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM
> >>> > > >driver
> >>> > > >
> >>> > > >[External Email] Do not click links or attachments unless you
> >>> > > >recognize the sender and know the content is safe
> >>> > > >
> >>> > > >Hi Pragnesh
> >>> > > >
> >>> > > >> Hi Rick,
> >>> > > >>
> >>> > > >> >-Original Message-
> >>> > > >> >From: Rick Chen 
> >>> > > >> >Sent: 24 June 2020 06:30
> >>> > > >> >To: Pragnesh Patel 
> >>> > > >> >Cc: U-Boot Mailing List ; Atish Patra
> >>> > > >> >; palmerdabb...@google.com; Bin Meng
> >>> > > >> >; Paul Walmsley ( Sifive)
> >>> > > >> >; Anup Patel
> >;
> >>> > > >> >Sagar Kadam ; Palmer Dabbelt
> >>> > > >;
> >>> > > >> >Jagan Teki ; rick
> >>> > > >> >; Alan Kao 
> >>> > > >> >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive
> >>> > > >> >PWM driver
> >>> > > >> >
> >>> > > >> >[External Email] Do not click links or attachments unless you
> >>> > > >> >recognize the sender and know the content is safe
> >>> > > >> >
> >>> > > >> >Hi Pragnesh
> >>> > > >> >
> >>> > > >> >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> >>> > > >> >> Sent: Friday, May 29, 2020 2:45 PM
> >>> > > >> >> To: u-boot@lists.denx.de
> >>> > > >> >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com;
> >>> > > >> >bmeng...@gmail.com; paul.walms...@sifive.com;
> >>> > > >> >anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick Jian-Zhi
> >>> > > >> >Chen(陳建志); Pragnesh Patel; Palmer Dabbelt
> >>> > > >> >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive
> >>> > > >> >> PWM driver
> >>> > > >> >>
> >>> > > >> >> This pat

Re: [PATCH v3] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

[Rick Chen]

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Monday, July 20, 2020 11:52 AM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Tom Rini; Bin Meng
> Subject: [PATCH v3] azure: gitlab: travis: Update OpenSBI used for RISC-V 
> testing
>
> From: Bin Meng 
>
> Change to use OpenSBI release v0.8 generic platform images for QEMU RISC-V CI 
> testing for azure, gitlab and travis-ci.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v3:
> - rebase on u-boot/master again
>
> Changes in v2:
> - rebase on u-boot/master
>
>  .azure-pipelines.yml | 8 
>  .gitlab-ci.yml   | 8 
>  .travis.yml  | 8 
>  3 files changed, 12 insertions(+), 12 deletions(-)
>

Applied to u-boot-riscv/master!

Thanks,
Rick

Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Mon, Jul 20, 2020 at 11:16 AM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Monday, July 20, 2020 10:41 AM
> > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > Cc: Tom Rini; Bin Meng
> > > Subject: Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for 
> > > RISC-V testing
> > >
> > > Hi Rick,
> > >
> > > On Thu, Jul 16, 2020 at 5:15 PM Bin Meng  wrote:
> > > >
> > > > From: Bin Meng 
> > > >
> > > > Change to use OpenSBI release v0.8 generic platform images for QEMU
> > > > RISC-V CI testing for azure, gitlab and travis-ci.
> > > >
> > > > Signed-off-by: Bin Meng 
> > > > Reviewed-by: Tom Rini 
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - rebase on u-boot/master
> > > >
> > > >  .azure-pipelines.yml | 8 
> > > >  .gitlab-ci.yml   | 8 
> > > >  .travis.yml  | 8 
> > > >  3 files changed, 12 insertions(+), 12 deletions(-)
> > > >
> > >
> > > Ping?
> >
> > It still conflict with u-boot/master.
> >
> > Applying: azure: gitlab: travis: Update OpenSBI used for RISC-V testing
> > error: patch failed: .azure-pipelines.yml:299
> > error: .azure-pipelines.yml: patch does not apply
> > error: patch failed: .gitlab-ci.yml:25
> > error: .gitlab-ci.yml: patch does not apply
> >
>
> I suspect this is because u-boot-riscv/master is a little bit old. Can
> you rebase u-boot-riscv/master on top of u-boot/master and retry?

Yes, I have rebased to the latest u-boot/master. But the conflicts still occur

Thanks,
Rick.

>
> Regards,
> Bin

Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

[Rick Chen]

Hi Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Monday, July 20, 2020 10:41 AM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Tom Rini; Bin Meng
> Subject: Re: [PATCH v2] azure: gitlab: travis: Update OpenSBI used for RISC-V 
> testing
>
> Hi Rick,
>
> On Thu, Jul 16, 2020 at 5:15 PM Bin Meng  wrote:
> >
> > From: Bin Meng 
> >
> > Change to use OpenSBI release v0.8 generic platform images for QEMU
> > RISC-V CI testing for azure, gitlab and travis-ci.
> >
> > Signed-off-by: Bin Meng 
> > Reviewed-by: Tom Rini 
> > ---
> >
> > Changes in v2:
> > - rebase on u-boot/master
> >
> >  .azure-pipelines.yml | 8 
> >  .gitlab-ci.yml   | 8 
> >  .travis.yml  | 8 
> >  3 files changed, 12 insertions(+), 12 deletions(-)
> >
>
> Ping?

It still conflict with u-boot/master.

Applying: azure: gitlab: travis: Update OpenSBI used for RISC-V testing
error: patch failed: .azure-pipelines.yml:299
error: .azure-pipelines.yml: patch does not apply
error: patch failed: .gitlab-ci.yml:25
error: .gitlab-ci.yml: patch does not apply

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH 1/5] sysreset: syscon: Don't assume default value for offset and mask property

[Rick Chen]

Hi Tom

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Friday, July 17, 2020 2:54 PM
> To: Pragnesh Patel
> Cc: Bin Meng; Rick Jian-Zhi Chen(陳建志); Simon Glass; U-Boot Mailing List; 
> Sagar Kadam
> Subject: Re: [PATCH 1/5] sysreset: syscon: Don't assume default value for 
> offset and mask property
>
> Hi Rick,
>
> On Fri, Jun 26, 2020 at 1:53 PM Pragnesh Patel  
> wrote:
> >
> > >-Original Message-
> > >From: Bin Meng 
> > >Sent: 23 June 2020 11:00
> > >To: Rick Chen ; Simon Glass ;
> > >Pragnesh Patel ; Sagar Kadam
> > >; U-Boot Mailing List 
> > >Cc: Bin Meng 
> > >Subject: [PATCH 1/5] sysreset: syscon: Don't assume default value for
> > >offset and mask property
> > >
> > >[External Email] Do not click links or attachments unless you
> > >recognize the sender and know the content is safe
> > >
> > >From: Bin Meng 
> > >
> > >Per the DT binding,  is a required property. Let's abort the
> > >probe if it is missing. For the  property, current codes assume
> > >a default value of zero, which is not correct either.
> > >
> > >Signed-off-by: Bin Meng 
> > >---
> > >
> > > drivers/sysreset/sysreset_syscon.c | 14 --
> > > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > Reviewed-by: Pragnesh Patel 
>
> Would you please take the remaining 3 patches soon?
> http://patchwork.ozlabs.org/project/uboot/list/?series=185161

May I ask for your opinions about these three SYSRESET patchs. If they
are OK to be pick up in my next PR, though they have been rejected in
previous riscv PR ?
https://www.mail-archive.com/u-boot@lists.denx.de/msg375465.html

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH] azure: gitlab: travis: Update OpenSBI used for RISC-V testing

[Rick Chen]

Hi Bin

> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tom Rini
> Sent: Tuesday, July 07, 2020 10:13 PM
> To: Bin Meng
> Cc: U-Boot Mailing List; Bin Meng
> Subject: Re: [PATCH] azure: gitlab: travis: Update OpenSBI used for RISC-V 
> testing
>
> On Sat, Jun 27, 2020 at 05:21:04AM -0700, Bin Meng wrote:
>
> > From: Bin Meng 
> >
> > Change to use OpenSBI release v0.8 generic platform images for QEMU
> > RISC-V CI testing for azure, gitlab and travis-ci.
> >
> > Signed-off-by: Bin Meng 
>
> Reviewed-by: Tom Rini 
>

I am trying to apply this patch, but it fail

Applying: azure: gitlab: travis: Update OpenSBI used for RISC-V testing
error: patch failed: .azure-pipelines.yml:283
error: .azure-pipelines.yml: patch does not apply
error: patch failed: .gitlab-ci.yml:25
error: .gitlab-ci.yml: patch does not apply
Patch failed at 0001 azure: gitlab: travis: Update OpenSBI used for
RISC-V testing

Can you rebase again ?

Thanks,
Rick

Re: [PATCH 1/2] Revert "riscv: Allow use of reset drivers"

[Rick Chen]

Hi Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, July 16, 2020 9:36 AM
> To: Sean Anderson
> Cc: Rick Jian-Zhi Chen(陳建志); Tom Rini; U-Boot Mailing List; Bin Meng
> Subject: Re: [PATCH 1/2] Revert "riscv: Allow use of reset drivers"
>
> Hi Rick,
>
> On Wed, Jul 8, 2020 at 3:04 PM Sean Anderson  wrote:
> >
> > On 7/8/20 2:44 AM, Bin Meng wrote:
> > > From: Bin Meng 
> > >
> > > This reverts commit 958a3f464c7f8ef7e10db9feb663e9e80445ce2f.
> > >
> > > A more appropriate change below is already in mainline.
> > > Commit fd31e4fd184f ("riscv: Do not build reset.c if SYSRESET is
> > > on")
> > >
> > > Revert this patch, so that U-Boot can be built successfully for
> > > SiFive Fu540 board.
> > >
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  arch/riscv/lib/reset.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/arch/riscv/lib/reset.c b/arch/riscv/lib/reset.c index
> > > 6008bbe..8779c61 100644
> > > --- a/arch/riscv/lib/reset.c
> > > +++ b/arch/riscv/lib/reset.c
> > > @@ -7,7 +7,6 @@
> > >  #include 
> > >  #include 
> > >
> > > -#ifndef CONFIG_SYSRESET
> > >  int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> > > argv[])  {
> > >   printf("resetting ...\n");
> > > @@ -17,4 +16,3 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int
> > > argc, char *const argv[])
> > >
> > >   return 0;
> > >  }
> > > -#endif
> > >
> >
> > Reviewed-by: Sean Anderson 
>
> Could we get this series applied soon? thanks!
>

OK.

But [PATCH 2/2] Revert "Revert "riscv: sifive: fu540: Add gpio-restart
support"" seem conflict with Pragnesh's [PATCH 2/2] riscv: sifive:
fu540: Enable SiFive PWM driver.

Would you please rebase with u-boot-riscv/master and send again ?

Thanks,
Rick

> Regards,
> Bin

Re: [PATCH v4 2/6] sifive: fu540: Add Booting from SPI

[Rick Chen]

Hi Jagan

> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: Thursday, July 02, 2020 4:03 PM
> To: Rick Jian-Zhi Chen(陳建志); Atish Patra; Palmer Dabbelt; Bin Meng; Paul 
> Walmsley; Anup Patel; Sagar Kadam
> Cc: u-boot@lists.denx.de; linux-amar...@amarulasolutions.com; Jagan Teki; Bin 
> Meng
> Subject: [PATCH v4 2/6] sifive: fu540: Add Booting from SPI
>
> Add booting from SPI for SiFive Unleashed board.
>
> Signed-off-by: Jagan Teki 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
> ---
> Changes for v4:
> - drop BOARD configs
>

Can you rebase and send the whole patches of v4 again ?
When I tried to pick up others from v3, there have some conflicts.

Thanks,
Rick

>  .../dts/hifive-unleashed-a00-u-boot.dtsi  | 12 ++
>  configs/sifive_fu540_defconfig|  4 ++
>  doc/board/sifive/fu540.rst| 41 +++
>  3 files changed, 57 insertions(+)
>
> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> index 303806454b..4b2b242deb 100644
> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> @@ -12,6 +12,10 @@
> spi2 = &qspi2;
> };
>
> +   config {
> +   u-boot,spl-payload-offset = <0x105000>; /* loader2 @1044KB */
> +   };
> +
> hfclk {
> u-boot,dm-spl;
> };
> @@ -22,6 +26,14 @@
>
>  };
>
> +&qspi0 {
> +   u-boot,dm-spl;
> +
> +   flash@0 {
> +   u-boot,dm-spl;
> +   };
> +};
> +
>  &qspi2 {
> mmc@0 {
> u-boot,dm-spl;
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig 
> index 8d412f8d6a..551d4b04a5 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -2,9 +2,11 @@ CONFIG_RISCV=y
>  CONFIG_SPL_GPIO_SUPPORT=y
>  CONFIG_SYS_MALLOC_F_LEN=0x3000
>  CONFIG_ENV_SIZE=0x2
> +CONFIG_SPL_DM_SPI=y
>  CONFIG_SPL_MMC_SUPPORT=y
>  CONFIG_NR_DRAM_BANKS=1
>  CONFIG_SPL=y
> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI_SUPPORT=y
>  CONFIG_TARGET_SIFIVE_FU540=y
>  CONFIG_ARCH_RV64I=y
> @@ -15,9 +17,11 @@ CONFIG_MISC_INIT_R=y
>  CONFIG_DISPLAY_CPUINFO=y
>  CONFIG_DISPLAY_BOARDINFO=y
>  CONFIG_SPL_SEPARATE_BSS=y
> +CONFIG_SPL_SPI_LOAD=y
>  CONFIG_SPL_YMODEM_SUPPORT=y
>  CONFIG_OF_BOARD_FIXUP=y
>  CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_SPL_CLK=y
>  CONFIG_DM_MTD=y
> diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst index 
> 739eefa669..1ce9ab14f5 100644
> --- a/doc/board/sifive/fu540.rst
> +++ b/doc/board/sifive/fu540.rst
> @@ -533,3 +533,44 @@ Sample boot log from HiFive Unleashed board
> type:   0fc63daf-8483-4772-8e79-3d69d8477de4
> type:   linux
> guid:   9faa81b6-39b1-4418-af5e-89c48f29c20d
> +
> +Booting from SPI
> +
> +
> +Use Building steps from "Booting from MMC using U-Boot SPL" section.
> +
> +Partition the SPI in Linux via mtdblock. (Require to boot the board in
> +SD boot mode by enabling MTD block in Linux)
> +
> +Use prebuilt image from here [1], which support to partition the SPI flash.
> +
> +.. code-block:: none
> +
> +  # sgdisk --clear \
> +  > --set-alignment=2 \
> +  > --new=1:40:2087 --change-name=1:loader1
> + --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \  >
> + --new=2:2088:10279 --change-name=2:loader2
> + --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \  >
> + --new=3:10536:65494 --change-name=3:rootfs
> + --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \  > /dev/mtdblock0
> +
> +Program the SPI (Require to boot the board in SD boot mode)
> +
> +Execute below steps on U-Boot proper,
> +
> +.. code-block:: none
> +
> +  tftpboot $kernel_addr_r u-boot-spl.bin  sf erase 0x5000 $filesize  sf
> + write $kernel_addr_r 0x5000 $filesize
> +
> +  tftpboot $kernel_addr_r u-boot.itb
> +  sf erase 0x105000 $filesize
> +  sf write $kernel_addr_r 0x105000 $filesize
> +
> +Power off the board
> +
> +Change DIP switches MSEL[3:0] are set to 0110
> +
> +Power up the board.
> +
> +[1] https://github.com/amarula/bsp-sifive
> --
> 2.25.1
>

Re: [U-Boot] Pull request: u-boot-riscv/master

[Rick Chen]

> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Thursday, July 02, 2020 9:53 PM
> To: Open Source Project uboot
> Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志)
> Subject: Re: [U-Boot] Pull request: u-boot-riscv/master
>
> On Thu, Jul 02, 2020 at 10:51:48AM +0800, ub...@andestech.com wrote:
>
> > Hi Tom,
> >
> > Please pull some riscv updates:
> >
> > - sbi: Add newline to error message
> > - fu540: dts: Correct reg size of otp and dmc nodes
> > - Enhance reserved memory fixup about PMP information passed from
> > OpenSbi
> > - sifive: fu540: Add gpio-restart support
> > - qemu: Add syscon reboot and poweroff support
> > - qemu-riscv: Update QEMU run command
> > - Assorted fixes related to reserved memory
> > - fu540: enable all cache ways from U-Boot proper
> > - use log functions in fdt_fixup
>
> This changes a few MIPS and ARM platforms.  We're a few days away from 
> release, so I don't feel comfortable taking this right now as I assume it 
> hasn't been tested on the other platforms as well.  Sorry.

Hi Tom,

Thanks for your suggestions.


Hi Bin,

Can you separate this series about sysreset into two series ?
[PATCH 1/5] sysreset: syscon: Don't assume default value for offset
and mask property
[PATCH 2/5] sysreset: syscon: Support value property
[PATCH 3/5] riscv: Do not build reset.c if SYSRESET is on
[PATCH 4/5] riscv: qemu: Add syscon reboot and poweroff support
[PATCH 5/5] riscv: sifive: fu540: Add gpio-restart support

It looks like that patch 3/5, 4/5, 5/5 doesn't depend on patch 1/5 and 2/5.

Thanks,
Rick

>
> --

Re: [PATCH 1/1] riscv: use log functions in fdt_fixup

[Rick Chen]

Hi Heinrich

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Friday, June 26, 2020 12:35 PM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: Bin Meng; Atish Patra; Simon Glass; u-boot@lists.denx.de; Heinrich 
> Schuchardt
> Subject: [PATCH 1/1] riscv: use log functions in fdt_fixup
>
> Replace printf() and debug() by log_err() and log_debug().
>
> "No reserved memory region found in source FDT\n" is not an error but a debug 
> information.
>
> %s/can not/cannot/ - use the more common spelling.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/lib/fdt_fixup.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>

Reviewed-by: Rick Chen 

This patch conflicts with Atish's [PATCH v3 0/2] Assorted fixes
related to reserved memory
Can you rebase it and send again ?

Thanks,
Rick

> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c index 
> 6db48ad04a..c1dc247cf7 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -37,7 +37,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
>
> offset = fdt_path_offset(src, "/reserved-memory");
> if (offset < 0) {
> -   printf("No reserved memory region found in source FDT\n");
> +   log_debug("No reserved memory region found in source FDT\n");
> return 0;
> }
>
> @@ -48,7 +48,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
>   "reg", 0, &size,
>   false);
> if (addr == FDT_ADDR_T_NONE) {
> -   debug("failed to read address/size for %s\n", name);
> +   log_debug("failed to read address/size for %s\n", 
> name);
> continue;
> }
> strncpy(basename, name, max_len);
> @@ -63,7 +63,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> err = fdtdec_add_reserved_memory(dst, basename, &pmp_mem,
>  &phandle);
> if (err < 0) {
> -   printf("failed to add reserved memory: %d\n", err);
> +   log_err("failed to add reserved memory: %d\n", err);
> return err;
> }
> if (!fdt_getprop(src, node, "no-map", NULL)) @@ -109,7 +109,7 
> @@ int board_fix_fdt(void *fdt)
>
> err = riscv_board_reserved_mem_fixup(fdt);
> if (err < 0) {
> -   printf("failed to fixup DT for reserved memory: %d\n", err);
> +   log_err("failed to fixup DT for reserved memory: %d\n", err);
> return err;
> }
>
> @@ -127,14 +127,14 @@ int arch_fixup_fdt(void *blob)
> size = fdt_totalsize(blob);
> err  = fdt_open_into(blob, blob, size + 32);
> if (err < 0) {
> -   printf("Device Tree can't be expanded to accommodate new 
> node");
> +   log_err("Device Tree can't be expanded to accommodate new 
> node");
> return err;
> }
> chosen_offset = fdt_path_offset(blob, "/chosen");
> if (chosen_offset < 0) {
> err = fdt_add_subnode(blob, 0, "chosen");
> if (err < 0) {
> -   printf("chosen node can not be added\n");
> +   log_err("chosen node cannot be added\n");
> return err;
> }
> }
> --
> 2.27.0

Re: [PATCH v4 3/3] riscv: Enable CONFIG_OF_BOARD_FIXUP by default for OF_SEPARATE

[Rick Chen]

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Friday, June 26, 2020 9:16 AM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Atish Patra; Bin Meng
> Subject: [PATCH v4 3/3] riscv: Enable CONFIG_OF_BOARD_FIXUP by default for 
> OF_SEPARATE
>
> From: Bin Meng 
>
> Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the reserved 
> memory node for PMP protected memory regions. All RISC-V boards need to copy 
> the reserved memory node from the device tree provided by the firmware to the 
> device tree used by U-Boot.
>
> Turn on CONFIG_OF_BOARD_FIXUP by default for OF_SEPARATE.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Atish Patra 
> ---
>
> Changes in v4:
> - /s/needs/need in the commit message
>
> Changes in v3:
> - change to "default y if OF_SEPARATE"
>
>  arch/riscv/Kconfig | 3 +++
>  configs/sifive_fu540_defconfig | 1 -
>  2 files changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Rick Chen 

>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index d9854f5..ff8a9f8 
> 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -273,4 +273,7 @@ config STACK_SIZE_SHIFT
> int
> default 14
>
> +config OF_BOARD_FIXUP
> +   default y if OF_SEPARATE
> +
>  endmenu
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig 
> index 8d412f8..32347c2 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -16,7 +16,6 @@ CONFIG_DISPLAY_CPUINFO=y  CONFIG_DISPLAY_BOARDINFO=y  
> CONFIG_SPL_SEPARATE_BSS=y  CONFIG_SPL_YMODEM_SUPPORT=y 
> -CONFIG_OF_BOARD_FIXUP=y  CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SPL_CLK=y
> --
> 2.7.4

Re: [PATCH v4 2/3] riscv: Expand the DT size before copy reserved memory node

[Rick Chen]

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Friday, June 26, 2020 9:16 AM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Atish Patra; Bin Meng
> Subject: [PATCH v4 2/3] riscv: Expand the DT size before copy reserved memory 
> node
>
> From: Bin Meng 
>
> The FDT blob might not have sufficient space to hold a copy of reserved 
> memory node. Expand it before the copy.
>
> Reported-by: Rick Chen 
> Signed-off-by: Bin Meng 
> Reviewed-by: Atish Patra 
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Extend the FDT size by 1024 bytes
>
>  arch/riscv/lib/fdt_fixup.c | 12 ++++
>  1 file changed, 12 insertions(+)
>

Reviewed-by: Rick Chen 

> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c index 
> 5f523f0..160ccca 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -41,6 +41,18 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void 
> *dst)
> return 0;
> }
>
> +   /*
> +* Extend the FDT by the following estimated size:
> +*
> +* Each PMP memory region entry occupies 64 bytes.
> +* With 16 PMP memory regions we need 64 * 16 = 1024 bytes.
> +*/
> +   err = fdt_open_into(dst, dst, fdt_totalsize(dst) + 1024);
> +   if (err < 0) {
> +   printf("Device Tree can't be expanded to accommodate new 
> node");
> +   return err;
> +   }
> +
> fdt_for_each_subnode(node, src, offset) {
> name = fdt_get_name(src, node, NULL);
>
> --
> 2.7.4

Re: [PATCH v3 2/6] sifive: fu540: Add Booting from SPI

[Rick Chen]

Hi Jagan

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Monday, June 22, 2020 9:53 PM
> To: Jagan Teki
> Cc: Rick Jian-Zhi Chen(陳建志); Atish Patra; Palmer Dabbelt; Paul Walmsley; Anup 
> Patel; Sagar Kadam; U-Boot Mailing List; linux-amarula
> Subject: Re: [PATCH v3 2/6] sifive: fu540: Add Booting from SPI
>
> On Fri, Jun 5, 2020 at 4:40 AM Jagan Teki  wrote:
> >
> > Add booting from SPI for SiFive Unleashed board.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> > Changes for v3:
> > - updated based on master
> >
> >  arch/riscv/cpu/fu540/Kconfig  |  2 +
> >  .../dts/hifive-unleashed-a00-u-boot.dtsi  | 12 ++
> >  configs/sifive_fu540_defconfig|  4 ++
> >  doc/board/sifive/fu540.rst| 41 +++
> >  4 files changed, 59 insertions(+)
> >
> > diff --git a/arch/riscv/cpu/fu540/Kconfig
> > b/arch/riscv/cpu/fu540/Kconfig index e9302e87c0..7a813a9ac8 100644
> > --- a/arch/riscv/cpu/fu540/Kconfig
> > +++ b/arch/riscv/cpu/fu540/Kconfig
> > @@ -5,6 +5,8 @@
> >  config SIFIVE_FU540
> > bool
> > select ARCH_EARLY_INIT_R
> > +   imply BOARD
> > +   imply BOARD_FU540
>
> These 2 are not needed in v3.

How is your opinion here ?

>
> > imply CPU
> > imply CPU_RISCV
> > imply RISCV_TIMER
> > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > index 303806454b..4b2b242deb 100644
> > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > @@ -12,6 +12,10 @@
> > spi2 = &qspi2;
> > };
> >
> > +   config {
> > +   u-boot,spl-payload-offset = <0x105000>; /* loader2 @1044KB 
> > */
> > +   };
> > +
> > hfclk {
> > u-boot,dm-spl;
> > };
> > @@ -22,6 +26,14 @@
> >
> >  };
> >
> > +&qspi0 {
> > +   u-boot,dm-spl;
> > +
> > +   flash@0 {
> > +   u-boot,dm-spl;
> > +   };
> > +};
> > +
> >  &qspi2 {
> > mmc@0 {
> > u-boot,dm-spl;
>
> Other than above,
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Wed, Jun 24, 2020 at 1:24 PM Pragnesh Patel
>  wrote:
> >
> > Hi Rick,
> >
> > >-----Original Message-
> > >From: Rick Chen 
> > >Sent: 24 June 2020 10:44
> > >To: Pragnesh Patel 
> > >Cc: U-Boot Mailing List ; Atish Patra
> > >; palmerdabb...@google.com; Bin Meng
> > >; Paul Walmsley ( Sifive)
> > >; Anup Patel ; Sagar
> > >Kadam ; Palmer Dabbelt ;
> > >Jagan Teki ; rick ; Alan
> > >Kao 
> > >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
> > >
> > >[External Email] Do not click links or attachments unless you recognize the
> > >sender and know the content is safe
> > >
> > >Hi Pragnesh
> > >
> > >> Hi Rick,
> > >>
> > >> >-Original Message-
> > >> >From: Rick Chen 
> > >> >Sent: 24 June 2020 06:30
> > >> >To: Pragnesh Patel 
> > >> >Cc: U-Boot Mailing List ; Atish Patra
> > >> >; palmerdabb...@google.com; Bin Meng
> > >> >; Paul Walmsley ( Sifive)
> > >> >; Anup Patel ; Sagar
> > >> >Kadam ; Palmer Dabbelt
> > >;
> > >> >Jagan Teki ; rick ;
> > >> >Alan Kao 
> > >> >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM
> > >> >driver
> > >> >
> > >> >[External Email] Do not click links or attachments unless you
> > >> >recognize the sender and know the content is safe
> > >> >
> > >> >Hi Pragnesh
> > >> >
> > >> >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> > >> >> Sent: Friday, May 29, 2020 2:45 PM
> > >> >> To: u-boot@lists.denx.de
> > >> >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com;
> > >> >bmeng...@gmail.com; paul.walms...@sifive.com; anup.pa...@wdc.com;
> > >> >sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); Pragnesh Patel;
> > >> >Palmer Dabbelt
> > >> >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
> > >> >>
> > >> >> This patch enables SiFive PWM driver for the SiFive Unleashed board.
> > >> >>
> > >> >> Signed-off-by: Pragnesh Patel 
> > >> >> ---
> > >> >>  board/sifive/fu540/Kconfig | 2 ++
> > >> >>  1 file changed, 2 insertions(+)
> > >> >>
> > >> >> diff --git a/board/sifive/fu540/Kconfig
> > >> >> b/board/sifive/fu540/Kconfig index
> > >> >86193d7668..683668d059 100644
> > >> >> --- a/board/sifive/fu540/Kconfig
> > >> >> +++ b/board/sifive/fu540/Kconfig
> > >> >> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > >> >> imply SMP
> > >> >> imply MISC
> > >> >> imply SIFIVE_OTP
> > >> >> +   imply DM_PWM
> > >> >> +   imply PWM_SIFIVE
> > >> >>
> > >> >
> > >> >This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive.
> > >> >It is weird to introduce here and not appropriate to depend on another
> > >patch.
> > >>
> > >> Do you want me to send this 2 patches separately independent of each
> > >other ?
> > >
> > >How about merged [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
> > >into [PATCH v2 0/2] Add support for PWM SiFive ?
> >
> > I am okay with it, you can go ahead and merge this patch into PWM series of 
> > Yash.
> >
>
> They are separate patches and should keep separate. I am not sure
> what's the issue we want to resolve?

Nothing about resolve.
Logically if they can be put together, it will be more reasonable.

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver

[Rick Chen]

Hi Pragnesh

> Hi Rick,
>
> >-Original Message-----
> >From: Rick Chen 
> >Sent: 24 June 2020 06:30
> >To: Pragnesh Patel 
> >Cc: U-Boot Mailing List ; Atish Patra
> >; palmerdabb...@google.com; Bin Meng
> >; Paul Walmsley ( Sifive)
> >; Anup Patel ; Sagar
> >Kadam ; Palmer Dabbelt ;
> >Jagan Teki ; rick ; Alan
> >Kao 
> >Subject: Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
> >
> >[External Email] Do not click links or attachments unless you recognize the
> >sender and know the content is safe
> >
> >Hi Pragnesh
> >
> >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> >> Sent: Friday, May 29, 2020 2:45 PM
> >> To: u-boot@lists.denx.de
> >> Cc: atish.pa...@wdc.com; palmerdabb...@google.com;
> >bmeng...@gmail.com; paul.walms...@sifive.com; anup.pa...@wdc.com;
> >sagar.ka...@sifive.com; Rick Jian-Zhi Chen(陳建志); Pragnesh Patel; Palmer
> >Dabbelt
> >> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
> >>
> >> This patch enables SiFive PWM driver for the SiFive Unleashed board.
> >>
> >> Signed-off-by: Pragnesh Patel 
> >> ---
> >>  board/sifive/fu540/Kconfig | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index
> >86193d7668..683668d059 100644
> >> --- a/board/sifive/fu540/Kconfig
> >> +++ b/board/sifive/fu540/Kconfig
> >> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> >> imply SMP
> >> imply MISC
> >> imply SIFIVE_OTP
> >> +   imply DM_PWM
> >> +   imply PWM_SIFIVE
> >>
> >
> >This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive.
> >It is weird to introduce here and not appropriate to depend on another patch.
>
> Do you want me to send this 2 patches separately independent of each other ?

How about merged [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
into [PATCH v2 0/2] Add support for PWM SiFive ?

Thanks,
Rick

>
> >
> >Thanks,
> >Rick
> >
> >>  endif
> >> --
> >> 2.17.1

Re: [U-Boot] Pull request: u-boot-riscv/master

[Rick Chen]

Hi Tom

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, June 24, 2020 10:58 AM
> To: Open Source Project uboot
> Cc: Tom Rini; U-Boot Mailing List; Rick Jian-Zhi Chen(陳建志)
> Subject: Re: [U-Boot] Pull request: u-boot-riscv/master
>
> Hi Rick,
>
> On Wed, Jun 24, 2020 at 10:41 AM  wrote:
> >
> > Hi Tom,
> >
> > Please pull some riscv updates:
> >
> > - fu540: dts: Correct reg size of otp and dmc nodes
> > - sbi: Add newline to error message
> > - sifive/fu540: Enable SPI-NOR support
> >
> > Thanks
> > Rick
> >
> > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/701223929
> >
> >
> > The following changes since commit 4ff63383e3497389e66cf70943a83bdb1810462a:
> >
> >   Merge tag 'u-boot-imx-20200623' of 
> > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-23 08:20:55 
> > -0400)
> >
> > are available in the Git repository at:
> >
> >   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> >
> > for you to fetch changes up to 2148d9c76ef5efbf5b98ca3d3fcbaad465115e70:
> >
> >   riscv: fu540: dts: Correct reg size of otp and dmc nodes (2020-06-24 
> > 09:59:30 +0800)
> >
> > 
> > Bin Meng (2):
> >   riscv: fu540: dts: Remove the unnecessary space in the cpu2_intc node
> >   riscv: fu540: dts: Correct reg size of otp and dmc nodes
> >
> > Jagan Teki (6):
> >   sifive: fu540: Add runtime boot mode detection
> >   sifive: fu540: Add Booting from SPI
> >   env: Enable SPI flash env for SiFive FU540
> >   sifive: fu540: Mark the default env as SPI flash
> >   sifive: fu540: Add boot flash script offset, size
> >   sifive: fu540: Enable SF distro bootcmd
>
> You missed my review comments for Jagan's series.
> https://lists.denx.de/pipermail/u-boot/2020-June/417066.html
>
> Please hold on.

Please drop this PR.

Thanks,
Rick

>
> >
> > Sean Anderson (1):
> >   riscv: sbi: Add newline to error message
> >
>
> Regards,
> Bin
> CONFIDENTIALITY NOTICE:
>
> This e-mail (and its attachments) may contain confidential and legally 
> privileged information or information protected from disclosure. If you are 
> not the intended recipient, you are hereby notified that any disclosure, 
> copying, distribution, or use of the information contained herein is strictly 
> prohibited. In this case, please immediately notify the sender by return 
> e-mail, delete the message (and any accompanying documents) and destroy all 
> printed hard copies. Thank you for your cooperation.
>
> Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Wed, Jun 24, 2020 at 9:36 AM Rick Chen  wrote:
> >
> > Hi Sagar
> >
> > >
> > > Hello Rick,
> > >
> > > > -Original Message-
> > > > From: Rick Chen 
> > > > Sent: Monday, June 22, 2020 7:24 AM
> > > > To: Sagar Kadam 
> > > > Cc: U-Boot Mailing List ; Lukasz Majewski
> > > > ; Bin Meng ; Jagan Teki
> > > > ; Pragnesh Patel
> > > > ; Anup Patel ; Simon
> > > > Glass ; Sean Anderson ; rick
> > > > ; Alan Kao ;
> > > > ycli...@andestech.com
> > > > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock 
> > > > handlers
> > > >
> > > > [External Email] Do not click links or attachments unless you recognize 
> > > > the
> > > > sender and know the content is safe
> > > >
> > > > Hi Sagar,
> > > >
> > > > > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> > > > > Sent: Sunday, June 21, 2020 9:10 PM
> > > > > To: u-boot@lists.denx.de
> > > > > Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; bmeng...@gmail.com;
> > > > > ja...@amarulasolutions.com; pragnesh.pa...@sifive.com;
> > > > > anup.pa...@wdc.com; s...@chromium.org; sean...@gmail.com; Sagar
> > > > > Shrikant Kadam
> > > > > Subject: [PATCH v4 1/4] fu540: prci: add request and free clock
> > > > > handlers
> > > > >
> > > > > Add clk_request handler to check if a valid clock is requested.
> > > > > Here clk_free handler is added for debug purpose which will display
> > > > details of clock passed to clk_free.
> > > > >
> > > > > Signed-off-by: Sagar Shrikant Kadam 
> > > > > Reviewed-by: Pragnesh Patel 
> > > > > ---
> > > >
> > > > This v4 series still have some conflicts with master.
> > > > Please check about it.
> > > >
> > > > Applying: fu540: prci: add request and free clock handlers
> > > > Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases
> > > > Applying: riscv: cpu: fixes to display proper CPU features
> > > > error: patch failed: drivers/cpu/riscv_cpu.c:38
> > > > error: drivers/cpu/riscv_cpu.c: patch does not apply Patch failed at 
> > > > 0003
> > > > riscv: cpu: fixes to display proper CPU features
> > > >
> > >
> > > Thanks for trying this out
> > > This series is dependent on following two patches [1]
> > > and [2] below which are part of "Add Sipeed Maix support." series
> > > [1] https://patchwork.ozlabs.org/patch/1295345
> > > [2] https://patchwork.ozlabs.org/patch/1295346
> > > and I also mentioned in cover-letter. Sorry If I missed to add some
> > > additional information there.
> > >
> > > The dependent are added like
> > > -u-boot master [commit 2b8692bac1e8].
> > > -Patches [1] + [2].
> > > -This series.
> >
> > According to this dependency I will apply yours in -next behind of Sean's
>
> I just sent comments to this series, please hold on.

OK.

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers

[Rick Chen]

Hi Sagar

>
> Hello Rick,
>
> > -Original Message-
> > From: Rick Chen 
> > Sent: Monday, June 22, 2020 7:24 AM
> > To: Sagar Kadam 
> > Cc: U-Boot Mailing List ; Lukasz Majewski
> > ; Bin Meng ; Jagan Teki
> > ; Pragnesh Patel
> > ; Anup Patel ; Simon
> > Glass ; Sean Anderson ; rick
> > ; Alan Kao ;
> > ycli...@andestech.com
> > Subject: Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
> >
> > [External Email] Do not click links or attachments unless you recognize the
> > sender and know the content is safe
> >
> > Hi Sagar,
> >
> > > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> > > Sent: Sunday, June 21, 2020 9:10 PM
> > > To: u-boot@lists.denx.de
> > > Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; bmeng...@gmail.com;
> > > ja...@amarulasolutions.com; pragnesh.pa...@sifive.com;
> > > anup.pa...@wdc.com; s...@chromium.org; sean...@gmail.com; Sagar
> > > Shrikant Kadam
> > > Subject: [PATCH v4 1/4] fu540: prci: add request and free clock
> > > handlers
> > >
> > > Add clk_request handler to check if a valid clock is requested.
> > > Here clk_free handler is added for debug purpose which will display
> > details of clock passed to clk_free.
> > >
> > > Signed-off-by: Sagar Shrikant Kadam 
> > > Reviewed-by: Pragnesh Patel 
> > > ---
> >
> > This v4 series still have some conflicts with master.
> > Please check about it.
> >
> > Applying: fu540: prci: add request and free clock handlers
> > Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases
> > Applying: riscv: cpu: fixes to display proper CPU features
> > error: patch failed: drivers/cpu/riscv_cpu.c:38
> > error: drivers/cpu/riscv_cpu.c: patch does not apply Patch failed at 0003
> > riscv: cpu: fixes to display proper CPU features
> >
>
> Thanks for trying this out
> This series is dependent on following two patches [1]
> and [2] below which are part of "Add Sipeed Maix support." series
> [1] https://patchwork.ozlabs.org/patch/1295345
> [2] https://patchwork.ozlabs.org/patch/1295346
> and I also mentioned in cover-letter. Sorry If I missed to add some
> additional information there.
>
> The dependent are added like
> -u-boot master [commit 2b8692bac1e8].
> -Patches [1] + [2].
> -This series.

According to this dependency I will apply yours in -next behind of Sean's

Thanks,
Rick

>
> I guess the PR for the series was sent earlier followed with some discussion
> https://www.mail-archive.com/u-boot@lists.denx.de/msg370739.html
> and I think this series was deferred in that PR.
> Please let me know if you have some suggestions here?
>
> Thanks & BR,
> Sagar Kadam
>
> > Thanks,
> > Rick
> >
> > >  drivers/clk/sifive/fu540-prci.c | 21 +
> > >  1 file changed, 21 insertions(+)
> > >
> > > diff --git a/drivers/clk/sifive/fu540-prci.c
> > > b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..9a9ff6b 100644
> > > --- a/drivers/clk/sifive/fu540-prci.c
> > > +++ b/drivers/clk/sifive/fu540-prci.c
> > > @@ -686,6 +686,25 @@ static ulong sifive_fu540_prci_set_rate(struct clk
> > *clk, ulong rate)
> > > return rate;
> > >  }
> > >
> > > +static int sifive_fu540_prci_clk_request(struct clk *clk) {
> > > +   debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > > + clk->id);
> > > +
> > > +   if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> > > +   return -EINVAL;
> > > +
> > > +   return 0;
> > > +}
> > > +
> > > +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> > > +   debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> > > + clk->id);
> > > +
> > > +   return 0;
> > > +}
> > > +
> > >  static int sifive_fu540_prci_enable(struct clk *clk)  {
> > > struct __prci_clock *pc;
> > > @@ -755,6 +774,8 @@ static struct clk_ops sifive_fu540_prci_ops = {
> > > .get_rate = sifive_fu540_prci_get_rate,
> > > .enable = sifive_fu540_prci_enable,
> > > .disable = sifive_fu540_prci_disable,
> > > +   .request  = sifive_fu540_prci_clk_request,
> > > +   .rfree= sifive_fu540_prci_clk_free,
> > >  };
> > >
> > >  static const struct udevice_id sifive_fu540_prci_ids[] = {
> > > --
> > > 2.7.4
> > >

Re: [U-Boot] Pull request: u-boot-riscv/master

[Rick Chen]

Hi Sean

Tom Rini  於 2020年6月23日 週二 上午8:45寫道：
>
> On Mon, Jun 22, 2020 at 02:03:52PM +0800, Rick Chen wrote:
> > Hi Tom
> >
> > > From: Tom Rini [mailto:tr...@konsulko.com]
> > > Sent: Monday, May 25, 2020 11:40 PM
> > > To: Open Source Project uboot
> > > Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志)
> > > Subject: Re: [U-Boot] Pull request: u-boot-riscv/master
> > >
> > > On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > Please pull some riscv updates:
> > > >
> > > > - Add Sipeed Maix support.
> > > > - sifive: fix palmer's email address.
> > > > - Move all SMP related SBI calls to SBI_v01.
> > > >
> > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926
> > > >
> > > > Thanks
> > > > Rick
> > > >
> > > >
> > > > The following changes since commit 
> > > > 9c5fef577494769e3ff07952a85f9b7125ef765b:
> > > >
> > > >   Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> > > >
> > > > for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607:
> > > >
> > > >   riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800)
> > > >
> > >
> > > There's too many generic changes in this PR for this late in the cycle, 
> > > for things I gather related to the Maix platform.  All of the clk and DM 
> > > changes impact virtually all platforms.  Please re-do this PR to drop the 
> > > Maix platform support for now, and resubmit that for -next, which I will 
> > > be opening shortly.  Everything else however is good for master.
> >
> > May I ask for your suggestions about this patch series about "riscv:
> > Add Sipeed Maix support " ?
> > Shall I send a PR include this patch series in early release cycle or
> > shall I suggest Sean to re-edit this patch series for less generic
> > changes which may bring virtual impacts?
>
> So I looked over the generic changes again.  There's no other way to
> support the platform without those type of changes, yes?  If so, yes,
> lets put it in to -next.

Please rebase -next for upstream
There are some conflicts needed to be fixed.

Applying: clk: Always use the supplied struct clk
Applying: clk: Check that ops of composite clock components exist before calling
Applying: clk: Unconditionally recursively en-/dis-able clocks
Applying: clk: Fix clk_get_by_* handling of index
Applying: clk: Add K210 pll support
Applying: clk: Add a bypass clock for K210
Applying: clk: Add K210 clock support
Applying: dm: Add support for simple-pm-bus
Applying: dm: Fix error handling for dev_read_addr_ptr
Applying: reset: Add generic reset driver
error: patch failed: configs/sandbox_defconfig:196
error: configs/sandbox_defconfig: patch does not apply
Patch failed at 0010 reset: Add generic reset driver

Thanks,
Rick

>
> --
> Tom

Re: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver

[Rick Chen]

Hi Pragnesh

> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Friday, May 29, 2020 2:45 PM
> To: u-boot@lists.denx.de
> Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; 
> paul.walms...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick 
> Jian-Zhi Chen(陳建志); Pragnesh Patel; Palmer Dabbelt
> Subject: [PATCH 2/2] riscv: sifive: fu540: Enable SiFive PWM driver
>
> This patch enables SiFive PWM driver for the SiFive Unleashed board.
>
> Signed-off-by: Pragnesh Patel 
> ---
>  board/sifive/fu540/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index 
> 86193d7668..683668d059 100644
> --- a/board/sifive/fu540/Kconfig
> +++ b/board/sifive/fu540/Kconfig
> @@ -65,5 +65,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply SMP
> imply MISC
> imply SIFIVE_OTP
> +   imply DM_PWM
> +   imply PWM_SIFIVE
>

This patch shall follow [PATCH v2 0/2] Add support for PWM SiFive.
It is weird to introduce here and not appropriate to depend on another patch.

Thanks,
Rick

>  endif
> --
> 2.17.1

Re: [U-Boot] Pull request: u-boot-riscv/master

[Rick Chen]

Hi Tom,

> On Mon, Jun 22, 2020 at 02:03:52PM +0800, Rick Chen wrote:
> > Hi Tom
> >
> > > From: Tom Rini [mailto:tr...@konsulko.com]
> > > Sent: Monday, May 25, 2020 11:40 PM
> > > To: Open Source Project uboot
> > > Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志)
> > > Subject: Re: [U-Boot] Pull request: u-boot-riscv/master
> > >
> > > On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > Please pull some riscv updates:
> > > >
> > > > - Add Sipeed Maix support.
> > > > - sifive: fix palmer's email address.
> > > > - Move all SMP related SBI calls to SBI_v01.
> > > >
> > > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926
> > > >
> > > > Thanks
> > > > Rick
> > > >
> > > >
> > > > The following changes since commit 
> > > > 9c5fef577494769e3ff07952a85f9b7125ef765b:
> > > >
> > > >   Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> > > >
> > > > for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607:
> > > >
> > > >   riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800)
> > > >
> > >
> > > There's too many generic changes in this PR for this late in the cycle, 
> > > for things I gather related to the Maix platform.  All of the clk and DM 
> > > changes impact virtually all platforms.  Please re-do this PR to drop the 
> > > Maix platform support for now, and resubmit that for -next, which I will 
> > > be opening shortly.  Everything else however is good for master.
> >
> > May I ask for your suggestions about this patch series about "riscv:
> > Add Sipeed Maix support " ?
> > Shall I send a PR include this patch series in early release cycle or
> > shall I suggest Sean to re-edit this patch series for less generic
> > changes which may bring virtual impacts?
>
> So I looked over the generic changes again.  There's no other way to
> support the platform without those type of changes, yes?

Yes. Discusstion between Sean and Lukasz about clk as below:
https://patchwork.ozlabs.org/project/uboot/patch/da401261-b73f-afae-0702-ada1e7dd8...@gmail.com/#2346363

If so, yes,
> lets put it in to -next.

Thanks for your reply.

Rick

>
> --
> Tom

Re: [U-Boot] Pull request: u-boot-riscv/master

[Rick Chen]

Hi Tom

> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Monday, May 25, 2020 11:40 PM
> To: Open Source Project uboot
> Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志)
> Subject: Re: [U-Boot] Pull request: u-boot-riscv/master
>
> On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote:
>
> > Hi Tom,
> >
> > Please pull some riscv updates:
> >
> > - Add Sipeed Maix support.
> > - sifive: fix palmer's email address.
> > - Move all SMP related SBI calls to SBI_v01.
> >
> > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926
> >
> > Thanks
> > Rick
> >
> >
> > The following changes since commit 9c5fef577494769e3ff07952a85f9b7125ef765b:
> >
> >   Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400)
> >
> > are available in the Git repository at:
> >
> >   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> >
> > for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607:
> >
> >   riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800)
> >
>
> There's too many generic changes in this PR for this late in the cycle, for 
> things I gather related to the Maix platform.  All of the clk and DM changes 
> impact virtually all platforms.  Please re-do this PR to drop the Maix 
> platform support for now, and resubmit that for -next, which I will be 
> opening shortly.  Everything else however is good for master.

May I ask for your suggestions about this patch series about "riscv:
Add Sipeed Maix support " ?
Shall I send a PR include this patch series in early release cycle or
shall I suggest Sean to re-edit this patch series for less generic
changes which may bring virtual impacts?

Thanks,
Rick

> Sorry.


>
> --
> Tom

Re: [PATCH v4 1/4] fu540: prci: add request and free clock handlers

[Rick Chen]

Hi Sagar,

> From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> Sent: Sunday, June 21, 2020 9:10 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); lu...@denx.de; bmeng...@gmail.com; 
> ja...@amarulasolutions.com; pragnesh.pa...@sifive.com; anup.pa...@wdc.com; 
> s...@chromium.org; sean...@gmail.com; Sagar Shrikant Kadam
> Subject: [PATCH v4 1/4] fu540: prci: add request and free clock handlers
>
> Add clk_request handler to check if a valid clock is requested.
> Here clk_free handler is added for debug purpose which will display details 
> of clock passed to clk_free.
>
> Signed-off-by: Sagar Shrikant Kadam 
> Reviewed-by: Pragnesh Patel 
> ---

This v4 series still have some conflicts with master.
Please check about it.

Applying: fu540: prci: add request and free clock handlers
Applying: riscv: dts: hifive-unleashed-a00: add cpu aliases
Applying: riscv: cpu: fixes to display proper CPU features
error: patch failed: drivers/cpu/riscv_cpu.c:38
error: drivers/cpu/riscv_cpu.c: patch does not apply
Patch failed at 0003 riscv: cpu: fixes to display proper CPU features

Thanks,
Rick

>  drivers/clk/sifive/fu540-prci.c | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/drivers/clk/sifive/fu540-prci.c 
> b/drivers/clk/sifive/fu540-prci.c index fe6e0d4..9a9ff6b 100644
> --- a/drivers/clk/sifive/fu540-prci.c
> +++ b/drivers/clk/sifive/fu540-prci.c
> @@ -686,6 +686,25 @@ static ulong sifive_fu540_prci_set_rate(struct clk *clk, 
> ulong rate)
> return rate;
>  }
>
> +static int sifive_fu540_prci_clk_request(struct clk *clk) {
> +   debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> + clk->id);
> +
> +   if (clk->id >= ARRAY_SIZE(__prci_init_clocks))
> +   return -EINVAL;
> +
> +   return 0;
> +}
> +
> +static int sifive_fu540_prci_clk_free(struct clk *clk) {
> +   debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
> + clk->id);
> +
> +   return 0;
> +}
> +
>  static int sifive_fu540_prci_enable(struct clk *clk)  {
> struct __prci_clock *pc;
> @@ -755,6 +774,8 @@ static struct clk_ops sifive_fu540_prci_ops = {
> .get_rate = sifive_fu540_prci_get_rate,
> .enable = sifive_fu540_prci_enable,
> .disable = sifive_fu540_prci_disable,
> +   .request  = sifive_fu540_prci_clk_request,
> +   .rfree= sifive_fu540_prci_clk_free,
>  };
>
>  static const struct udevice_id sifive_fu540_prci_ids[] = {
> --
> 2.7.4
>

Re: [PATCH v3 0/4] update clock handler and proper cpu features

[Rick Chen]

Hi Sagar

> From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> Sent: Thursday, June 04, 2020 6:45 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志); lu...@denx.de
> Cc: bmeng...@gmail.com; ja...@amarulasolutions.com; 
> pragnesh.pa...@sifive.com; anup.pa...@wdc.com; s...@chromium.org; 
> sean...@gmail.com; Sagar Shrikant Kadam
> Subject: [PATCH v3 0/4] update clock handler and proper cpu features
>
> U-Boot cmd "cpu detail" shows inconsistent CPU features and is missing 
> clk_request and free handlers.
> The current "cpu detail" sometimes shows "Microcode" as a feature, which is 
> not the case with FU540-C000 on HiFive Unleashed board.
>
> Patch 1: add clk request handler to check if valid clock id is requested.
> Patch 2: add cpu node aliases.
> Patch 3: Correctly parse and update mmu-type.
>
> RISC-V core's on FU540-C000 SoC have separate instruction and data (split)
> L1 cache.
> Patch 4:Use i-cache-size dt property as one of identifier to indicate a
> split cache is available.
>
> I have picked few dependent patches from Sean's and Pragnesh's latest series 
> from here [1]...[5].
>
> These have applied on mainline U-Boot commit 0d8f35b58cc8 ("Merge 
> https://gitlab.denx.de/u-boot/custodians/u-boot-spi";)
>
> Patch history:
> =
> V3:
> 1. Included the cosmetic change as suggested
>s/L1 feature/L1 cache feature/
> 2. Added Reviewed-By tags
>
> V2:
> 1. Incorporate review comments from Bin and Sean Anderson.
>and dropped 2nd patch as similar work was already done in [1] and [2]
> 2  Add cpu node aliases to display cpu node's in sequence.
> 3. Add fix to show mmu as available cpu feature.
> 4. Check and append L1 cache feature.
>
> V1: Base version
> Thanks to Vincent Chen  for testing the V1
> version of this series.
>
> [1] https://patchwork.ozlabs.org/patch/1295345
> [2] https://patchwork.ozlabs.org/patch/1295346
> [3] https://patchwork.ozlabs.org/patch/1300369
> [4] https://patchwork.ozlabs.org/patch/1300370
> [5] https://patchwork.ozlabs.org/patch/1300373
>
> All these together is available here:
> https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v3
>
> Sagar Shrikant Kadam (4):
>   fu540: prci: add request and free clock handlers
>   riscv: dts: hifive-unleashed-a00: add cpu aliases
>   riscv: cpu: fixes to display proper CPU features
>   riscv: cpu: check and append L1 cache to cpu features
>
>  arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi |  5 +
>  drivers/clk/sifive/fu540-prci.c | 21 +
>  drivers/cpu/riscv_cpu.c | 10 +-
>  3 files changed, 35 insertions(+), 1 deletion(-)


I am trying to apply to u-boot/master, but it fail as below:
Applying: fu540: prci: add request and free clock handlers
error: patch failed: drivers/clk/sifive/fu540-prci.c:581
error: drivers/clk/sifive/fu540-prci.c: patch does not apply
Patch failed at 0001 fu540: prci: add request and free clock handlers

Please rebase master, I will sync to master later.

Thanks,
Rick

>
> --
> 2.7.4
>

Re: [PATCH v13 00/19] RISC-V SiFive FU540 support SPL

[Rick Chen]

Hi Jagan

> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: Wednesday, June 03, 2020 2:57 AM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: U-Boot-Denx; Atish Patra; Palmer Dabbelt; Bin Meng; Paul Walmsley; Anup 
> Patel; Sagar Kadam; Pragnesh Patel
> Subject: Re: [PATCH v13 00/19] RISC-V SiFive FU540 support SPL
>
> Hi Rick,
>
> On Fri, May 29, 2020 at 11:34 AM Pragnesh Patel  
> wrote:
> >
> > This series add support for SPL to FU540. U-Boot SPL can boot from
> > L2 LIM (0x0800_) and jump to OpenSBI(FW_DYNAMIC firmware) and
> > U-Boot proper from MMC devices.
> >
> > This series is also available here [1] for testing [1]
> > https://github.com/pragnesh26992/u-boot/tree/spl
> >
> > How to test this patch:
> > 1) Go to OpenSBI-dir : make PLATFORM=generic FW_DYNAMIC=y
> > 2) export OPENSBI= > opensbi/build/platform/generic/firmware/fw_dynamic.bin>
> > 3) Change to u-boot-dir
> > 4) make sifive_fu540_defconfig
> > 5) make all
> > 6) Format the SD card (make sure the disk has GPT, otherwise use gdisk
> > to switch)
> >
> > # sudo sgdisk --clear \
> > > --set-alignment=2 \
> > > --new=1:34:2081 --change-name=1:loader1 
> > --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
> > > --new=2:2082:10273 --change-name=2:loader2 
> > --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
> > > --new=3:10274: --change-name=3:rootfs 
> > --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
> > > /dev/sda
> >
> > 7) sudo dd if=spl/u-boot-spl.bin of=/dev/sda seek=34
> > 8) sudo dd if=u-boot.itb of=/dev/sda seek=2082
> >
> > Changes in v13:
> > - Add a new patch to set the ethernet clock rate
> >   (riscv: sifive: dts: fu540: set ethernet clock rate)
> >
> > Changes in v12:
> > - Rebase on mainline U-Boot
> >   Added necessary include files which are not part of common header now
> >   Remove unnecessary include files
> >
> >   drivers/misc/sifive-otp.c
> > +#include 
> > +#include 
> >
> >   board/sifive/fu540/fu540.c
> > -#include 
> > +#include 
> >
> >   board/sifive/fu540/spl.c
> > +#include 
> > +#include 
> > +#include 
> >
> >   drivers/ram/sifive/fu540_ddr.c
> > +#include 
> >
> >   arch/riscv/cpu/fu540/cpu.c
> > -#include 
> > +#include 
> >
> >   arch/riscv/cpu/fu540/spl.c
> > -#include 
> > +#include 
> >
> >   board/sifive/fu540/spl.c
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> >
> > - Update commit description for Release ethernet clock reset
> > - Update OpenSBI building section in "doc/board/sifive/fu540.rst"
> >
> > Changes in v11:
> > - Remove TPL related code and OF_PLATDATA from FU540
> >   DDR driver (drivers/ram/sifive/fu540_ddr.c)
> > - Update FU540 doc (doc/board/sifive/fu540.rst)
> >   Remove unnecessary print
> >
> > Changes in v10:
> > - Update commit description for ethernet clock reset
> >   (https://patchwork.ozlabs.org/patch/1289003)
> > - Update commit description for ddr clock initialization
> >   (https://patchwork.ozlabs.org/patch/1289000)
> >
> > Changes in v9:
> > - Remove cache related patches from this series
> >   sifive: dts: fu540: Enable L2 Cache in U-Boot
> >   (https://patchwork.ozlabs.org/patch/1286705)
> >   riscv: sifive: fu540: enable all cache ways from U-Boot proper
> >   (https://patchwork.ozlabs.org/patch/1286706)
> > - Rename SiFive DDR driver from sdram_fu540.c to fu540_ddr.c
> >   and also do some typo correction in driver
> > - Remove CONFIG_SPL_BUILD for __prci_ddr_release_reset()
> > - Release ethernet clock reset instead of ethernet clock
> >   initialization
> >   (https://patchwork.ozlabs.org/patch/1286697)
> > - Squash fu540 cpu patches
> >   (https://patchwork.ozlabs.org/patch/1286699)
> >   (https://patchwork.ozlabs.org/patch/1286700)
> > - Use spl_boot_device() instead of board_boot_order()
> >
> > Changes in v8:
> > - Remove SPL_CRC7_SUPPORT Kconfig option and compile
> >   crc7.o when CONFIG_MMC_SPI selected
> > - Add "TODO" in drivers/ram/sifive/sdram_fu540.c
> > - Remove unnecessary TODO from drivers/clk/sifive/fu540-prci.c
> > - Make fu540-hifive-unleashed-a00-sdram-ddr4.dtsi file dual-licensed
> > - Add 2 new patches
> >   sifive: fu540: Add sample SD gpt partition layout
> >   (https://patchwork.ozlabs.org/patch/1092)
> >   sifive: fu540: Add U-Boot proper sector start
> >   (https://patchwork.ozlabs.org/patch/1093)
> > - Remove patch
> >   riscv: Enable cpu clock if it is present
> >   (https://patchwork.ozlabs.org/patch/1281573)
> > - Update doc/board/sifive/fu540.rst for PLATFORM=generic
> >
> > Changes in v7:
> > - Standardize SD gpt partition layout
> > - Add delay for SiFive OTP driver
> > - Use DM way for corepll and ddrpll
> > - Add new cpu fu540 (arch/riscv/cpu/fu540)
> > - Update document for FU540 (doc/board/sifive/fu540.rst)
> >
> > Changes in v6:
> > - Typo Correction
> > - Make fu540-c000-u-boot.dtsi and hifive-unleashed-a00-u-boot.dtsi
> >   D

Re: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version

[Rick Chen]

Hi Bin

Bin Meng  於 2020年6月2日 週二 下午5:39寫道：
>
> Hi Rick,
>
> On Tue, Jun 2, 2020 at 5:13 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > Bin Meng  於 2020年6月1日 週一 下午5:06寫道：
> > >
> > > Hi Rick,
> > >
> > > On Mon, Jun 1, 2020 at 4:14 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > Sent: Wednesday, May 27, 2020 5:05 PM
> > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > > Cc: Atish Patra; Bin Meng
> > > > > Subject: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version
> > > > >
> > > > > From: Bin Meng 
> > > > >
> > > > > U-Boot defaults to use SBI v0.2. Howerver there is a global variable 
> > > > > sbi_spec_version that stills refers to v0.1. Since it is not used 
> > > > > anywhere, let's remove it.
> > > > >
> > > > > Signed-off-by: Bin Meng 
> > > > > ---
> > > > >
> > > > >  arch/riscv/include/asm/sbi.h | 2 --
> > > > >  arch/riscv/lib/sbi.c | 3 ---
> > > > >  2 files changed, 5 deletions(-)
> > > > >
> > > > > diff --git a/arch/riscv/include/asm/sbi.h 
> > > > > b/arch/riscv/include/asm/sbi.h index 453cb5c..08e1ac0 100644
> > > > > --- a/arch/riscv/include/asm/sbi.h
> > > > > +++ b/arch/riscv/include/asm/sbi.h
> > > > > @@ -77,7 +77,6 @@ enum sbi_ext_rfence_fid {
> > > > >  #define SBI_FID_REMOTE_SFENCE_VMA_ASID 
> > > > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID
> > > > >  #endif
> > > > >
> > > > > -#define SBI_SPEC_VERSION_DEFAULT   0x1
> > > > >  #define SBI_SPEC_VERSION_MAJOR_SHIFT   24
> > > > >  #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
> > > > >  #define SBI_SPEC_VERSION_MINOR_MASK0xff
> > > > > @@ -90,7 +89,6 @@ enum sbi_ext_rfence_fid {
> > > > >  #define SBI_ERR_DENIED -4
> > > > >  #define SBI_ERR_INVALID_ADDRESS-5
> > > > >
> > > > > -extern unsigned long sbi_spec_version;
> > > > >  struct sbiret {
> > > > > long error;
> > > > > long value;
> > > > > diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index 
> > > > > 993597e..f298846 100644
> > > > > --- a/arch/riscv/lib/sbi.c
> > > > > +++ b/arch/riscv/lib/sbi.c
> > > > > @@ -11,9 +11,6 @@
> > > > >  #include 
> > > > >  #include 
> > > > >
> > > > > -/* default SBI version is 0.1 */
> > > > > -unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;
> > > >
> > > > Why not keep this variable and get version of openSbi automatically,
> > > > then register v01 or v02 callback function just like sbi_init() of
> > > > Atish' patch.
> > >
> > > I feel this is not needed anyway, because we are using Kconfig option
> > > to pass the same information.
> >
> > U-Boot proper has been configured as SBI_V02 by default currently.
> > About backward compatible issue, it is not so friendly for users.
> > They shall select SBI_VERSION configurations correctly in U-Boot
> > proper and re-compile between different versions of openSbi.
> > If U-Boot proper can probe openSbi and switch V01 or V02 mode
> > automatically, users can run smoothly without awareness of SBI
> > versions.
> >
>
> OpenSBI v0.7 is not backward compatible with previous version
> regarding the multicore boot. Dynamically detecting SBI and the SBI
> implementation version will make U-Boot codes very complicated. In
> addition to SBI v0.1 vs. v0.2, we need detect whether SBI HSM
> extension is available and if that's not available, U-Boot has to do
> the lottery multi-core boot in every stage (SPL and proper). RISC-V is
> a new architecture and without a lot of legacy burden to carry on, I
> hope we can do the clean room implementation from the beginning.
>

OK.
Thanks for explanation.

Reviewed-by: Rick Chen 

> Regards,
> Bin

Re: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of CONFIG_SBI_V01

[Rick Chen]

Hi Atish

Atish Patra  於 2020年6月3日 週三 上午2:32寫道：
>
> On Mon, Jun 1, 2020 at 2:09 AM Bin Meng  wrote:
> >
> > Hi Rick,
> >
> > On Mon, Jun 1, 2020 at 5:08 PM Rick Chen  wrote:
> > >
> > > Hi Bin
> > >
> > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > Sent: Wednesday, May 27, 2020 5:05 PM
> > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > > Cc: Atish Patra; Bin Meng
> > > > > Subject: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of 
> > > > > CONFIG_SBI_V01
> > > > >
> > > > > From: Bin Meng 
> > > > >
> > > > > sbi_probe_extension() is an API defined in SBI v0.2, not v0.1.
> > > > >
> > > > > Fixes 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to 
> > > > > SBI_v01")
> > > > > Signed-off-by: Bin Meng 
> > > > > ---
> > > >
> > > > Reviewed-by: Rick Chen 
> > > >
> > >
> > > BTW, it seem look like sbi_remote_fence_i, sbi_remote_sfence_vma and
> > > sbi_remote_sfence_vma_asid
> > > are all can be used no mater in SBI_V01 or SBI_V02. Because you have
> > > distinguished them in sbi.h
> >
> > No these calls are different and not compatible between SBI_V01 and SBI_V02.
> >
>
> In addition to that, U-Boot proper enables SMP only for SBI_V01
> because U-Boot doesn't need
> boot all the cores if the supervisor OS & SBI provider supports SBI
> v0.2 with HSM.
>
> Starting with OpenSBI v0.7 & Linux kernel 5.7 supports both. Thus,
> there is no advantage in adding
> redundant code in a generic path that is never going to be used.
>
> Any SBI provider that only supports SBI v0.1, the user can fall back
> to SBI_V01 config.

Thanks for your explanation.

Regards,
Rick

> > See commit 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to 
> > SBI_v01")
> >
> > Regards,
> > Bin
>
>
>
> --
> Regards,
> Atish

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Atish

Atish Patra  於 2020年6月3日 週三 上午2:22寫道：
>
> On Mon, Jun 1, 2020 at 11:51 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > Bin Meng  於 2020年6月2日 週二 下午2:33寫道：
> > >
> > > Hi Rick,
> > >
> > > On Tue, Jun 2, 2020 at 2:16 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > Bin Meng  於 2020年6月2日 週二 下午2:13寫道：
> > > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Tue, Jun 2, 2020 at 2:04 PM Rick Chen  wrote:
> > > > > >
> > > > > > Hi Bin
> > > > > >
> > > > > > > Hi Rick,
> > > > > > >
> > > > > > > On Mon, Jun 1, 2020 at 3:36 PM Rick Chen  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Bin
> > > > > > > >
> > > > > > > > > Hi Rick,
> > > > > > > > >
> > > > > > > > > On Thu, May 28, 2020 at 4:17 PM Rick Chen 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Bin
> > > > > > > > > >
> > > > > > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > > > > > > > Sent: Wednesday, May 20, 2020 3:40 PM
> > > > > > > > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > > > > > > > > Cc: Bin Meng
> > > > > > > > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP 
> > > > > > > > > > > by default
> > > > > > > > > > >
> > > > > > > > > > > From: Bin Meng 
> > > > > > > > > > >
> > > > > > > > > > > Starting from OpenSBI v0.7, the SBI firmware 
> > > > > > > > > > > inserts/fixes up the reserved memory node for PMP 
> > > > > > > > > > > protected memory regions. All RISC-V boards needs to copy 
> > > > > > > > > > > the reserved memory node from the device tree provided by 
> > > > > > > > > > > the firmware to the device tree used by U-Boot.
> > > > > > > > > > >
> > > > > > > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Bin Meng 
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > >  arch/riscv/Kconfig | 3 +++
> > > > > > > > > > >  configs/sifive_fu540_defconfig | 1 -
> > > > > > > > > > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig 
> > > > > > > > > > > index fb5fe5a..5176b35 100644
> > > > > > > > > > > --- a/arch/riscv/Kconfig
> > > > > > > > > > > +++ b/arch/riscv/Kconfig
> > > > > > > > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> > > > > > > > > > > int
> > > > > > > > > > > default 14
> > > > > > > > > > >
> > > > > > > > > > > +config OF_BOARD_FIXUP
> > > > > > > > > > > +   default y
> > > > > > > > > >
> > > > > > > > > > I think it shall invoke by individual board, just like the 
> > > > > > > > > > description
> > > > > > > > > > of riscv_fdt_copy_resv_mem_node function.
> > > > > > > > >
> > > > > > > > > I believe we should turn on this feature by default for every 
> > > > > > > > > RISC-V
> > > > > > > > > board, because SBI firmware used memory must be marked as 
> > > > > > > > > reserved
> > > > > > > > > otherwise OS might use it and get crashed. For boards which 
> > > > > > > > > don't want
> > > > > > > > > to enable this, they can unset the option in their board 
> > > > > > > > > defconfig
> > > > > > > > > files. This is to reduce some maintenance effort.
> > > > > > > >
> > > > > > > > But not all RISC-V boards need this configuration.
> > > > > > > > If we enable it by default, non spl configuration will run this 
> > > > > > > > fdt
> > > > > > > > fix flow, but it is unnecessary.
> > > > > > > >
> > > > > > >
> > > > > > > Non SPL configuration also needs this, because U-Boot has to 
> > > > > > > patch the
> > > > > > > final DTB that is passed to the kernel. It's a RISC-V architecture
> > > > > > > thing.
> > > > > >
> > > > > > But non SPL configuration will not run openSbi, why it will need 
> > > > > > this flow ?
> > > > > >
> > > > >
> > > > > Which configuration is this?
> > > >
> > > > e.q: ae350_rv[32|64]_defconfig
> > > >
> > >
> > > It looks these 2 configs are for U-Boot M-mode. How are they supposed
> > > to work, if they do not work with OpenSBI?
> >
> > They work with BBL(riscv-pk).
> >
> > Thanks,
> > Rick
> >
> > >
> > > Regards,
> > > Bin
>
> How about enabling only if OF_SEPARATE is enabled ?
> We don't need a board fixup for prior stage case.
>

It is a good suggestion.

Thanks,
Rick

>
> --
> Regards,
> Atish

Re: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version

[Rick Chen]

Hi Bin

Bin Meng  於 2020年6月1日 週一 下午5:06寫道：
>
> Hi Rick,
>
> On Mon, Jun 1, 2020 at 4:14 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Wednesday, May 27, 2020 5:05 PM
> > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > Cc: Atish Patra; Bin Meng
> > > Subject: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version
> > >
> > > From: Bin Meng 
> > >
> > > U-Boot defaults to use SBI v0.2. Howerver there is a global variable 
> > > sbi_spec_version that stills refers to v0.1. Since it is not used 
> > > anywhere, let's remove it.
> > >
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  arch/riscv/include/asm/sbi.h | 2 --
> > >  arch/riscv/lib/sbi.c | 3 ---
> > >  2 files changed, 5 deletions(-)
> > >
> > > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h 
> > > index 453cb5c..08e1ac0 100644
> > > --- a/arch/riscv/include/asm/sbi.h
> > > +++ b/arch/riscv/include/asm/sbi.h
> > > @@ -77,7 +77,6 @@ enum sbi_ext_rfence_fid {
> > >  #define SBI_FID_REMOTE_SFENCE_VMA_ASID 
> > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID
> > >  #endif
> > >
> > > -#define SBI_SPEC_VERSION_DEFAULT   0x1
> > >  #define SBI_SPEC_VERSION_MAJOR_SHIFT   24
> > >  #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
> > >  #define SBI_SPEC_VERSION_MINOR_MASK0xff
> > > @@ -90,7 +89,6 @@ enum sbi_ext_rfence_fid {
> > >  #define SBI_ERR_DENIED -4
> > >  #define SBI_ERR_INVALID_ADDRESS-5
> > >
> > > -extern unsigned long sbi_spec_version;
> > >  struct sbiret {
> > > long error;
> > > long value;
> > > diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index 
> > > 993597e..f298846 100644
> > > --- a/arch/riscv/lib/sbi.c
> > > +++ b/arch/riscv/lib/sbi.c
> > > @@ -11,9 +11,6 @@
> > >  #include 
> > >  #include 
> > >
> > > -/* default SBI version is 0.1 */
> > > -unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;
> >
> > Why not keep this variable and get version of openSbi automatically,
> > then register v01 or v02 callback function just like sbi_init() of
> > Atish' patch.
>
> I feel this is not needed anyway, because we are using Kconfig option
> to pass the same information.

U-Boot proper has been configured as SBI_V02 by default currently.
About backward compatible issue, it is not so friendly for users.
They shall select SBI_VERSION configurations correctly in U-Boot
proper and re-compile between different versions of openSbi.
If U-Boot proper can probe openSbi and switch V01 or V02 mode
automatically, users can run smoothly without awareness of SBI
versions.

Thanks,
Rick



>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Bin

Bin Meng  於 2020年6月2日 週二 下午2:33寫道：
>
> Hi Rick,
>
> On Tue, Jun 2, 2020 at 2:16 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > Bin Meng  於 2020年6月2日 週二 下午2:13寫道：
> > >
> > > Hi Rick,
> > >
> > > On Tue, Jun 2, 2020 at 2:04 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Mon, Jun 1, 2020 at 3:36 PM Rick Chen  wrote:
> > > > > >
> > > > > > Hi Bin
> > > > > >
> > > > > > > Hi Rick,
> > > > > > >
> > > > > > > On Thu, May 28, 2020 at 4:17 PM Rick Chen  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Bin
> > > > > > > >
> > > > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > > > > > Sent: Wednesday, May 20, 2020 3:40 PM
> > > > > > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > > > > > > Cc: Bin Meng
> > > > > > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by 
> > > > > > > > > default
> > > > > > > > >
> > > > > > > > > From: Bin Meng 
> > > > > > > > >
> > > > > > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up 
> > > > > > > > > the reserved memory node for PMP protected memory regions. 
> > > > > > > > > All RISC-V boards needs to copy the reserved memory node from 
> > > > > > > > > the device tree provided by the firmware to the device tree 
> > > > > > > > > used by U-Boot.
> > > > > > > > >
> > > > > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Bin Meng 
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > >  arch/riscv/Kconfig | 3 +++
> > > > > > > > >  configs/sifive_fu540_defconfig | 1 -
> > > > > > > > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> > > > > > > > > fb5fe5a..5176b35 100644
> > > > > > > > > --- a/arch/riscv/Kconfig
> > > > > > > > > +++ b/arch/riscv/Kconfig
> > > > > > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> > > > > > > > > int
> > > > > > > > > default 14
> > > > > > > > >
> > > > > > > > > +config OF_BOARD_FIXUP
> > > > > > > > > +   default y
> > > > > > > >
> > > > > > > > I think it shall invoke by individual board, just like the 
> > > > > > > > description
> > > > > > > > of riscv_fdt_copy_resv_mem_node function.
> > > > > > >
> > > > > > > I believe we should turn on this feature by default for every 
> > > > > > > RISC-V
> > > > > > > board, because SBI firmware used memory must be marked as reserved
> > > > > > > otherwise OS might use it and get crashed. For boards which don't 
> > > > > > > want
> > > > > > > to enable this, they can unset the option in their board defconfig
> > > > > > > files. This is to reduce some maintenance effort.
> > > > > >
> > > > > > But not all RISC-V boards need this configuration.
> > > > > > If we enable it by default, non spl configuration will run this fdt
> > > > > > fix flow, but it is unnecessary.
> > > > > >
> > > > >
> > > > > Non SPL configuration also needs this, because U-Boot has to patch the
> > > > > final DTB that is passed to the kernel. It's a RISC-V architecture
> > > > > thing.
> > > >
> > > > But non SPL configuration will not run openSbi, why it will need this 
> > > > flow ?
> > > >
> > >
> > > Which configuration is this?
> >
> > e.q: ae350_rv[32|64]_defconfig
> >
>
> It looks these 2 configs are for U-Boot M-mode. How are they supposed
> to work, if they do not work with OpenSBI?

They work with BBL(riscv-pk).

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Bin

Bin Meng  於 2020年6月2日 週二 下午2:13寫道：
>
> Hi Rick,
>
> On Tue, Jun 2, 2020 at 2:04 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > Hi Rick,
> > >
> > > On Mon, Jun 1, 2020 at 3:36 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > > Hi Rick,
> > > > >
> > > > > On Thu, May 28, 2020 at 4:17 PM Rick Chen  
> > > > > wrote:
> > > > > >
> > > > > > Hi Bin
> > > > > >
> > > > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > > > Sent: Wednesday, May 20, 2020 3:40 PM
> > > > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > > > > Cc: Bin Meng
> > > > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by 
> > > > > > > default
> > > > > > >
> > > > > > > From: Bin Meng 
> > > > > > >
> > > > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the 
> > > > > > > reserved memory node for PMP protected memory regions. All RISC-V 
> > > > > > > boards needs to copy the reserved memory node from the device 
> > > > > > > tree provided by the firmware to the device tree used by U-Boot.
> > > > > > >
> > > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default.
> > > > > > >
> > > > > > > Signed-off-by: Bin Meng 
> > > > > > > ---
> > > > > > >
> > > > > > >  arch/riscv/Kconfig | 3 +++
> > > > > > >  configs/sifive_fu540_defconfig | 1 -
> > > > > > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> > > > > > > fb5fe5a..5176b35 100644
> > > > > > > --- a/arch/riscv/Kconfig
> > > > > > > +++ b/arch/riscv/Kconfig
> > > > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> > > > > > > int
> > > > > > > default 14
> > > > > > >
> > > > > > > +config OF_BOARD_FIXUP
> > > > > > > +   default y
> > > > > >
> > > > > > I think it shall invoke by individual board, just like the 
> > > > > > description
> > > > > > of riscv_fdt_copy_resv_mem_node function.
> > > > >
> > > > > I believe we should turn on this feature by default for every RISC-V
> > > > > board, because SBI firmware used memory must be marked as reserved
> > > > > otherwise OS might use it and get crashed. For boards which don't want
> > > > > to enable this, they can unset the option in their board defconfig
> > > > > files. This is to reduce some maintenance effort.
> > > >
> > > > But not all RISC-V boards need this configuration.
> > > > If we enable it by default, non spl configuration will run this fdt
> > > > fix flow, but it is unnecessary.
> > > >
> > >
> > > Non SPL configuration also needs this, because U-Boot has to patch the
> > > final DTB that is passed to the kernel. It's a RISC-V architecture
> > > thing.
> >
> > But non SPL configuration will not run openSbi, why it will need this flow ?
> >
>
> Which configuration is this?

e.q: ae350_rv[32|64]_defconfig

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Mon, Jun 1, 2020 at 3:36 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > Hi Rick,
> > >
> > > On Thu, May 28, 2020 at 4:17 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > Sent: Wednesday, May 20, 2020 3:40 PM
> > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > > Cc: Bin Meng
> > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
> > > > >
> > > > > From: Bin Meng 
> > > > >
> > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the 
> > > > > reserved memory node for PMP protected memory regions. All RISC-V 
> > > > > boards needs to copy the reserved memory node from the device tree 
> > > > > provided by the firmware to the device tree used by U-Boot.
> > > > >
> > > > > Turn on CONFIG_OF_BOARD_FIXUP by default.
> > > > >
> > > > > Signed-off-by: Bin Meng 
> > > > > ---
> > > > >
> > > > >  arch/riscv/Kconfig | 3 +++
> > > > >  configs/sifive_fu540_defconfig | 1 -
> > > > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> > > > > fb5fe5a..5176b35 100644
> > > > > --- a/arch/riscv/Kconfig
> > > > > +++ b/arch/riscv/Kconfig
> > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> > > > > int
> > > > > default 14
> > > > >
> > > > > +config OF_BOARD_FIXUP
> > > > > +   default y
> > > >
> > > > I think it shall invoke by individual board, just like the description
> > > > of riscv_fdt_copy_resv_mem_node function.
> > >
> > > I believe we should turn on this feature by default for every RISC-V
> > > board, because SBI firmware used memory must be marked as reserved
> > > otherwise OS might use it and get crashed. For boards which don't want
> > > to enable this, they can unset the option in their board defconfig
> > > files. This is to reduce some maintenance effort.
> >
> > But not all RISC-V boards need this configuration.
> > If we enable it by default, non spl configuration will run this fdt
> > fix flow, but it is unnecessary.
> >
>
> Non SPL configuration also needs this, because U-Boot has to patch the
> final DTB that is passed to the kernel. It's a RISC-V architecture
> thing.

But non SPL configuration will not run openSbi, why it will need this flow ?

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Mon, Jun 1, 2020 at 3:40 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > Hi Rick,
> > >
> > > On Thu, May 28, 2020 at 4:24 PM Bin Meng  wrote:
> > > >
> > > > Hi Rick,
> > > >
> > > > On Thu, May 28, 2020 at 4:17 PM Rick Chen  wrote:
> > > > >
> > > > > Hi Bin
> > > > >
> > > > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > > > Sent: Wednesday, May 20, 2020 3:40 PM
> > > > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > > > Cc: Bin Meng
> > > > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
> > > > > >
> > > > > > From: Bin Meng 
> > > > > >
> > > > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the 
> > > > > > reserved memory node for PMP protected memory regions. All RISC-V 
> > > > > > boards needs to copy the reserved memory node from the device tree 
> > > > > > provided by the firmware to the device tree used by U-Boot.
> > > > > >
> > > > > > Turn on CONFIG_OF_BOARD_FIXUP by default.
> > > > > >
> > > > > > Signed-off-by: Bin Meng 
> > > > > > ---
> > > > > >
> > > > > >  arch/riscv/Kconfig | 3 +++
> > > > > >  configs/sifive_fu540_defconfig | 1 -
> > > > > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> > > > > > fb5fe5a..5176b35 100644
> > > > > > --- a/arch/riscv/Kconfig
> > > > > > +++ b/arch/riscv/Kconfig
> > > > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> > > > > > int
> > > > > > default 14
> > > > > >
> > > > > > +config OF_BOARD_FIXUP
> > > > > > +   default y
> > > > >
> > > > > I think it shall invoke by individual board, just like the description
> > > > > of riscv_fdt_copy_resv_mem_node function.
> > > >
> > > > I believe we should turn on this feature by default for every RISC-V
> > > > board, because SBI firmware used memory must be marked as reserved
> > > > otherwise OS might use it and get crashed. For boards which don't want
> > > > to enable this, they can unset the option in their board defconfig
> > > > files. This is to reduce some maintenance effort.
> > > >
> > > > >
> > > > > In [PATCH 1/2] if source and destination are the same place, it 
> > > > > represent that
> > > > > OF_BOARD_FIXUP is unnecessary.
> > > > >
> > > > > BTW when I try OF_SEPARATE and OF_BOARD_FIXUP both are enabled, it hit
> > > > > the problem as below:
> > > > >
> > > > > U-Boot SPL 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 
> > > > > +0800)
> > > > > Trying to boot from RAM
> > > > >
> > > > >
> > > > > U-Boot 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800)
> > > > >
> > > > > DRAM:  1 GiB
> > > > > failed to add reserved memory: -3
> > > >
> > > > -3 means FDT_ERR_NOSPACE.
> > > >
> > > > The FDT does not have enough space to add reserved memory node. Could
> > > > you please check your FDT blob?
> > > >
> > > > > failed to fixup DT for reserved memory: -3
> > > > > initcall sequence 01253c20 failed at call 0120b8e0 
> > > > > (err=-3)
> > > > > ### ERROR ### Please RESET the board ###
> > > > >
> > > > > I will dig in and figure out what is going on here ?
> > > > > Maybe there exist a potential issue somehow!
> > >
> > > Could you please try this patch?
> > > http://patchwork.ozlabs.org/project/uboot/patch/1590655604-13704-2-git-send-email-bmeng...@gmail.com/
> >
> > I try this patch, it still fail.
> > But after increase 32 more larger, it can pass.
> >
>
> What number did you enlarge this fdt size to?

It looks like depend on individual boards. We can not  guarantee other
boards adopt this size at rum time.
That is why I suggest it shall be enabled individually.

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of CONFIG_SBI_V01

[Rick Chen]

Hi Bin

> > From: Bin Meng [mailto:bmeng...@gmail.com]
> > Sent: Wednesday, May 27, 2020 5:05 PM
> > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > Cc: Atish Patra; Bin Meng
> > Subject: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of 
> > CONFIG_SBI_V01
> >
> > From: Bin Meng 
> >
> > sbi_probe_extension() is an API defined in SBI v0.2, not v0.1.
> >
> > Fixes 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
> > Signed-off-by: Bin Meng 
> > ---
>
> Reviewed-by: Rick Chen 
>

BTW, it seem look like sbi_remote_fence_i, sbi_remote_sfence_vma and
sbi_remote_sfence_vma_asid
are all can be used no mater in SBI_V01 or SBI_V02. Because you have
distinguished them in sbi.h

Thanks,
Rick

> >
> >  arch/riscv/lib/sbi.c | 37 +++--
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index 
> > f298846..8fbc238 100644
> > --- a/arch/riscv/lib/sbi.c
> > +++ b/arch/riscv/lib/sbi.c
> > @@ -53,6 +53,25 @@ void sbi_set_timer(uint64_t stime_value)  #endif  }
> >
> > +/**
> > + * sbi_probe_extension() - Check if an SBI extension ID is supported or 
> > not.
> > + * @extid: The extension ID to be probed.
> > + *
> > + * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> > + */
> > +int sbi_probe_extension(int extid)
> > +{
> > +   struct sbiret ret;
> > +
> > +   ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> > +   0, 0, 0, 0, 0);
> > +   if (!ret.error)
> > +   if (ret.value)
> > +   return ret.value;
> > +
> > +   return -ENOTSUPP;
> > +}
> > +
> >  #ifdef CONFIG_SBI_V01
> >
> >  /**
> > @@ -162,22 +181,4 @@ void sbi_remote_sfence_vma_asid(const unsigned long 
> > *hart_mask,
> >   (unsigned long)hart_mask, start, size, asid, 0, 0);  }
> >
> > -/**
> > - * sbi_probe_extension() - Check if an SBI extension ID is supported or 
> > not.
> > - * @extid: The extension ID to be probed.
> > - *
> > - * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> > - */
> > -int sbi_probe_extension(int extid)
> > -{
> > -   struct sbiret ret;
> > -
> > -   ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> > -   0, 0, 0, 0, 0);
> > -   if (!ret.error)
> > -   if (ret.value)
> > -   return ret.value;
> > -
> > -   return -ENOTSUPP;
> > -}
> >  #endif /* CONFIG_SBI_V01 */
> > --
> > 2.7.4
> >

Re: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version

[Rick Chen]

Hi Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, May 27, 2020 5:05 PM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Atish Patra; Bin Meng
> Subject: [PATCH 1/2] riscv: sbi: Remove sbi_spec_version
>
> From: Bin Meng 
>
> U-Boot defaults to use SBI v0.2. Howerver there is a global variable 
> sbi_spec_version that stills refers to v0.1. Since it is not used anywhere, 
> let's remove it.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/include/asm/sbi.h | 2 --
>  arch/riscv/lib/sbi.c | 3 ---
>  2 files changed, 5 deletions(-)
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h 
> index 453cb5c..08e1ac0 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -77,7 +77,6 @@ enum sbi_ext_rfence_fid {
>  #define SBI_FID_REMOTE_SFENCE_VMA_ASID SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID
>  #endif
>
> -#define SBI_SPEC_VERSION_DEFAULT   0x1
>  #define SBI_SPEC_VERSION_MAJOR_SHIFT   24
>  #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
>  #define SBI_SPEC_VERSION_MINOR_MASK0xff
> @@ -90,7 +89,6 @@ enum sbi_ext_rfence_fid {
>  #define SBI_ERR_DENIED -4
>  #define SBI_ERR_INVALID_ADDRESS-5
>
> -extern unsigned long sbi_spec_version;
>  struct sbiret {
> long error;
> long value;
> diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index 
> 993597e..f298846 100644
> --- a/arch/riscv/lib/sbi.c
> +++ b/arch/riscv/lib/sbi.c
> @@ -11,9 +11,6 @@
>  #include 
>  #include 
>
> -/* default SBI version is 0.1 */
> -unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;

Why not keep this variable and get version of openSbi automatically,
then register v01 or v02 callback function just like sbi_init() of
Atish' patch.

Thanks,
Rick

> -
>  struct sbiret sbi_ecall(int ext, int fid, unsigned long arg0,
> unsigned long arg1, unsigned long arg2,
> unsigned long arg3, unsigned long arg4,
> --
> 2.7.4
>

Re: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of CONFIG_SBI_V01

[Rick Chen]

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, May 27, 2020 5:05 PM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Atish Patra; Bin Meng
> Subject: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of 
> CONFIG_SBI_V01
>
> From: Bin Meng 
>
> sbi_probe_extension() is an API defined in SBI v0.2, not v0.1.
>
> Fixes 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
> Signed-off-by: Bin Meng 
> ---

Reviewed-by: Rick Chen 

>
>  arch/riscv/lib/sbi.c | 37 +++--
>  1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c index 
> f298846..8fbc238 100644
> --- a/arch/riscv/lib/sbi.c
> +++ b/arch/riscv/lib/sbi.c
> @@ -53,6 +53,25 @@ void sbi_set_timer(uint64_t stime_value)  #endif  }
>
> +/**
> + * sbi_probe_extension() - Check if an SBI extension ID is supported or not.
> + * @extid: The extension ID to be probed.
> + *
> + * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> + */
> +int sbi_probe_extension(int extid)
> +{
> +   struct sbiret ret;
> +
> +   ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> +   0, 0, 0, 0, 0);
> +   if (!ret.error)
> +   if (ret.value)
> +   return ret.value;
> +
> +   return -ENOTSUPP;
> +}
> +
>  #ifdef CONFIG_SBI_V01
>
>  /**
> @@ -162,22 +181,4 @@ void sbi_remote_sfence_vma_asid(const unsigned long 
> *hart_mask,
>   (unsigned long)hart_mask, start, size, asid, 0, 0);  }
>
> -/**
> - * sbi_probe_extension() - Check if an SBI extension ID is supported or not.
> - * @extid: The extension ID to be probed.
> - *
> - * Return: Extension specific nonzero value f yes, -ENOTSUPP otherwise.
> - */
> -int sbi_probe_extension(int extid)
> -{
> -   struct sbiret ret;
> -
> -   ret = sbi_ecall(SBI_EXT_BASE, SBI_EXT_BASE_PROBE_EXT, extid,
> -   0, 0, 0, 0, 0);
> -   if (!ret.error)
> -   if (ret.value)
> -   return ret.value;
> -
> -   return -ENOTSUPP;
> -}
>  #endif /* CONFIG_SBI_V01 */
> --
> 2.7.4
>

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Thu, May 28, 2020 at 4:24 PM Bin Meng  wrote:
> >
> > Hi Rick,
> >
> > On Thu, May 28, 2020 at 4:17 PM Rick Chen  wrote:
> > >
> > > Hi Bin
> > >
> > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > Sent: Wednesday, May 20, 2020 3:40 PM
> > > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > > Cc: Bin Meng
> > > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
> > > >
> > > > From: Bin Meng 
> > > >
> > > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the 
> > > > reserved memory node for PMP protected memory regions. All RISC-V 
> > > > boards needs to copy the reserved memory node from the device tree 
> > > > provided by the firmware to the device tree used by U-Boot.
> > > >
> > > > Turn on CONFIG_OF_BOARD_FIXUP by default.
> > > >
> > > > Signed-off-by: Bin Meng 
> > > > ---
> > > >
> > > >  arch/riscv/Kconfig | 3 +++
> > > >  configs/sifive_fu540_defconfig | 1 -
> > > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> > > > fb5fe5a..5176b35 100644
> > > > --- a/arch/riscv/Kconfig
> > > > +++ b/arch/riscv/Kconfig
> > > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> > > > int
> > > > default 14
> > > >
> > > > +config OF_BOARD_FIXUP
> > > > +   default y
> > >
> > > I think it shall invoke by individual board, just like the description
> > > of riscv_fdt_copy_resv_mem_node function.
> >
> > I believe we should turn on this feature by default for every RISC-V
> > board, because SBI firmware used memory must be marked as reserved
> > otherwise OS might use it and get crashed. For boards which don't want
> > to enable this, they can unset the option in their board defconfig
> > files. This is to reduce some maintenance effort.
> >
> > >
> > > In [PATCH 1/2] if source and destination are the same place, it represent 
> > > that
> > > OF_BOARD_FIXUP is unnecessary.
> > >
> > > BTW when I try OF_SEPARATE and OF_BOARD_FIXUP both are enabled, it hit
> > > the problem as below:
> > >
> > > U-Boot SPL 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800)
> > > Trying to boot from RAM
> > >
> > >
> > > U-Boot 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800)
> > >
> > > DRAM:  1 GiB
> > > failed to add reserved memory: -3
> >
> > -3 means FDT_ERR_NOSPACE.
> >
> > The FDT does not have enough space to add reserved memory node. Could
> > you please check your FDT blob?
> >
> > > failed to fixup DT for reserved memory: -3
> > > initcall sequence 01253c20 failed at call 0120b8e0 
> > > (err=-3)
> > > ### ERROR ### Please RESET the board ###
> > >
> > > I will dig in and figure out what is going on here ?
> > > Maybe there exist a potential issue somehow!
>
> Could you please try this patch?
> http://patchwork.ozlabs.org/project/uboot/patch/1590655604-13704-2-git-send-email-bmeng...@gmail.com/

I try this patch, it still fail.
But after increase 32 more larger, it can pass.

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Thu, May 28, 2020 at 4:17 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > Sent: Wednesday, May 20, 2020 3:40 PM
> > > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> > > Cc: Bin Meng
> > > Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
> > >
> > > From: Bin Meng 
> > >
> > > Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the 
> > > reserved memory node for PMP protected memory regions. All RISC-V boards 
> > > needs to copy the reserved memory node from the device tree provided by 
> > > the firmware to the device tree used by U-Boot.
> > >
> > > Turn on CONFIG_OF_BOARD_FIXUP by default.
> > >
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  arch/riscv/Kconfig | 3 +++
> > >  configs/sifive_fu540_defconfig | 1 -
> > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> > > fb5fe5a..5176b35 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> > > int
> > > default 14
> > >
> > > +config OF_BOARD_FIXUP
> > > +   default y
> >
> > I think it shall invoke by individual board, just like the description
> > of riscv_fdt_copy_resv_mem_node function.
>
> I believe we should turn on this feature by default for every RISC-V
> board, because SBI firmware used memory must be marked as reserved
> otherwise OS might use it and get crashed. For boards which don't want
> to enable this, they can unset the option in their board defconfig
> files. This is to reduce some maintenance effort.

But not all RISC-V boards need this configuration.
If we enable it by default, non spl configuration will run this fdt
fix flow, but it is unnecessary.

Thanks,
Rick

>
> >
> > In [PATCH 1/2] if source and destination are the same place, it represent 
> > that
> > OF_BOARD_FIXUP is unnecessary.
> >
> > BTW when I try OF_SEPARATE and OF_BOARD_FIXUP both are enabled, it hit
> > the problem as below:
> >
> > U-Boot SPL 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800)
> > Trying to boot from RAM
> >
> >
> > U-Boot 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800)
> >
> > DRAM:  1 GiB
> > failed to add reserved memory: -3
>
> -3 means FDT_ERR_NOSPACE.
>
> The FDT does not have enough space to add reserved memory node. Could
> you please check your FDT blob?
>
> > failed to fixup DT for reserved memory: -3
> > initcall sequence 01253c20 failed at call 0120b8e0 (err=-3)
> > ### ERROR ### Please RESET the board ###
> >
> > I will dig in and figure out what is going on here ?
> > Maybe there exist a potential issue somehow!
> >
>
> Regards,
> Bin

Re: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default

[Rick Chen]

Hi Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, May 20, 2020 3:40 PM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Bin Meng
> Subject: [PATCH 2/2] riscv: Enable CONFIG_OF_BOARD_FIXUP by default
>
> From: Bin Meng 
>
> Starting from OpenSBI v0.7, the SBI firmware inserts/fixes up the reserved 
> memory node for PMP protected memory regions. All RISC-V boards needs to copy 
> the reserved memory node from the device tree provided by the firmware to the 
> device tree used by U-Boot.
>
> Turn on CONFIG_OF_BOARD_FIXUP by default.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/Kconfig | 3 +++
>  configs/sifive_fu540_defconfig | 1 -
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index fb5fe5a..5176b35 
> 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -272,4 +272,7 @@ config STACK_SIZE_SHIFT
> int
> default 14
>
> +config OF_BOARD_FIXUP
> +   default y

I think it shall invoke by individual board, just like the description
of riscv_fdt_copy_resv_mem_node function.

In [PATCH 1/2] if source and destination are the same place, it represent that
OF_BOARD_FIXUP is unnecessary.

BTW when I try OF_SEPARATE and OF_BOARD_FIXUP both are enabled, it hit
the problem as below:

U-Boot SPL 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800)
Trying to boot from RAM


U-Boot 2020.07-rc3-16981-g4332225-dirty (May 28 2020 - 14:48:18 +0800)

DRAM:  1 GiB
failed to add reserved memory: -3
failed to fixup DT for reserved memory: -3
initcall sequence 01253c20 failed at call 0120b8e0 (err=-3)
### ERROR ### Please RESET the board ###

I will dig in and figure out what is going on here ?
Maybe there exist a potential issue somehow!

Thanks,
Rick

> +
>  endmenu
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig 
> index f805aac..6d61e6c 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -9,7 +9,6 @@ CONFIG_FIT=y
>  CONFIG_MISC_INIT_R=y
>  CONFIG_DISPLAY_CPUINFO=y
>  CONFIG_DISPLAY_BOARDINFO=y
> -CONFIG_OF_BOARD_FIXUP=y
>  CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_DM_MTD=y
> --
> 2.7.4

Re: [PATCH 1/2] riscv: Avoid the reserved memory fixup if src and dst point to the same place

[Rick Chen]

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Wednesday, May 20, 2020 3:40 PM
> To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Cc: Bin Meng
> Subject: [PATCH 1/2] riscv: Avoid the reserved memory fixup if src and dst 
> point to the same place
>
> From: Bin Meng 
>
> The copy of reserved memory node from source dtb to destination dtb can be 
> avoided if they point to the same place. This is useful when OF_PRIOR_STAGE 
> is used.
>
> Signed-off-by: Bin Meng 
> ---

Reviewed-by: Rick Chen 

>
>  arch/riscv/lib/fdt_fixup.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c index 
> 6db48ad..5f523f0 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -82,10 +82,9 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void 
> *dst)
>   * @fdt: Pointer to the device tree in which reserved memory node needs to be
>   *  added.
>   *
> - * In RISC-V, any board compiled with OF_SEPARATE needs to copy the reserved
> - * memory node from the device tree provided by the firmware to the device 
> tree
> - * used by U-Boot. This is a common function that individual board fixup
> - * functions can invoke.
> + * In RISC-V, any board needs to copy the reserved memory node from the
> + device
> + * tree provided by the firmware to the device tree used by U-Boot.
> + This is a
> + * common function that individual board fixup functions can invoke.
>   *
>   * Return: 0 on success or error otherwise.
>   */
> @@ -95,6 +94,11 @@ int riscv_board_reserved_mem_fixup(void *fdt)
> void *src_fdt_addr;
>
> src_fdt_addr = map_sysmem(gd->arch.firmware_fdt_addr, 0);
> +
> +   /* avoid the copy if we are using the same device tree */
> +   if (src_fdt_addr == fdt)
> +   return 0;
> +
> err = riscv_fdt_copy_resv_mem_node(src_fdt_addr, fdt);
> if (err < 0)
> return err;
> --
> 2.7.4

Re: [U-Boot] Pull request: u-boot-riscv/master

[Rick Chen]

Hi Tom

> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Monday, May 25, 2020 11:40 PM
> To: Open Source Project uboot
> Cc: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志)
> Subject: Re: [U-Boot] Pull request: u-boot-riscv/master
>
> On Mon, May 25, 2020 at 04:01:08PM +0800, ub...@andestech.com wrote:
>
> > Hi Tom,
> >
> > Please pull some riscv updates:
> >
> > - Add Sipeed Maix support.
> > - sifive: fix palmer's email address.
> > - Move all SMP related SBI calls to SBI_v01.
> >
> > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/690778926
> >
> > Thanks
> > Rick
> >
> >
> > The following changes since commit 9c5fef577494769e3ff07952a85f9b7125ef765b:
> >
> >   Merge git://git.denx.de/u-boot-usb (2020-05-22 22:58:50 -0400)
> >
> > are available in the Git repository at:
> >
> >   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> >
> > for you to fetch changes up to 421c4eb2dcf39f65c31c1804369267ed8a7b5607:
> >
> >   riscv: Add Sipeed Maix support (2020-05-25 10:01:21 +0800)
> >
>
> There's too many generic changes in this PR for this late in the cycle, for 
> things I gather related to the Maix platform.  All of the clk and DM changes 
> impact virtually all platforms.  Please re-do this PR to drop the Maix 
> platform support for now, and resubmit that for -next, which I will be 
> opening shortly.  Everything else however is good for master.

Thanks for your explanations.
Actually I have the same concern with you before sending this PR.

I have tried to ask Sean don't mix all codes together in one patchset.
He shall separate and send them individually, If they are not highly dependent.

Following are my suggestions from those patch-work:

Re: [PATCH v2 01/11] clk: Always use the supplied struct clk
https://patchwork.ozlabs.org/project/uboot/patch/da401261-b73f-afae-0702-ada1e7dd8...@gmail.com/

Re: [PATCH v4 07/17] spi: dw: Add mem_ops
https://patchwork.ozlabs.org/project/uboot/patch/20200211060425.1619471-8-sean...@gmail.com/

Re: [PATCH v5 33/33] riscv: Add Sipeed Maix support
http://u-boot.10912.n7.nabble.com/PATCH-v5-00-33-riscv-Add-Sipeed-Maix-support-tt401784.html#a402055

Re: [PATCH v6 04/19] clk: Add functions to register CCF clock structs
https://patchwork.ozlabs.org/project/uboot/patch/20200305181308.944595-5-sean...@gmail.com/

I will drop the Maix platform support in next PR and re-send again.

Thanks,
Rick


> Sorry.
>
> --
> Tom

Re: [PATCH v12 21/21] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

>
> The Sipeed Maix series is a collection of boards built around the RISC-V
> Kendryte K210 processor. This processor contains several peripherals to
> accelerate neural network processing and other "ai" tasks. This includes a
> "KPU" neural network processor, an audio processor supporting beamforming
> reception, and a digital video port supporting capture and output at VGA
> resolution. Other peripherals include 8M of sram (accessible with and
> without caching); remappable pins, including 40 GPIOs; AES, FFT, and SHA256
> accelerators; a DMA controller; and I2C, I2S, and SPI controllers. Maix
> peripherals vary, but include spi flash; on-board usb-serial bridges; ports
> for cameras, displays, and sd cards; and ESP32 chips. Currently, only the
> Sipeed Maix Bit V2.0 (bitm) is supported, but the boards are fairly
> similar.
>
> Documentation for Maix boards is located at
> .  Documentation for the Kendryte K210 is
> located at . However, hardware details are
> rather lacking, so most technical reference has been taken from the
> standalone sdk located at
> .
>
> Signed-off-by: Sean Anderson 
> ---

This v12 series still have warnings and one error when compile

drivers/clk/kendryte/bypass.c:11: warning: "LOG_CATEGORY" redefined
   11 | #define LOG_CATEGORY UCLASS_CLK
  |
In file included from include/linux/compat.h:4,
 from include/linux/err.h:5,
 from include/clk.h:12,
 from include/kendryte/bypass.h:8,
 from drivers/clk/kendryte/bypass.c:6:
include/log.h:105: note: this is the location of the previous definition

drivers/reset/reset-syscon.c: In function 'syscon_reset_request':
drivers/reset/reset-syscon.c:25:6: warning: implicit declaration of function 'BI
   25 |  if (BIT(rst->id) & priv->mask)

Meanwhile v11 still fail in CI verification.
https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/689149050

If the difference between v11 and v12 is only removing the Sanity
check, then the v12 shall have the same result in CI verification.
Please check about that

Thanks,
Rick


>
> Changes in v9:
> - Update MAINTAINERS to reflect defconfig name change
>
> Changes in v8:
> - Remove unnecessary fdt fixup for sipeed maix
>
> Changes in v7:
> - Split docs off into their own patch
> - Enable ram clocks by name
>
> Changes in v6:
> - Remove trailing whitespace from documentation
> - Remove configuration for spi/pinmux/gpio features
> - Flesh out documentation some more
>
> Changes in v5:
> - Configure relocation location with CONFIG_SYS_SDRAM_*
> - Enable ram clocks
> - Add pinmux/gpio/led support
> - Remove (broken) MMC support
> - Store the environment in flash
> - Add partitions
> - Add bootcmd
> - Add docs for pinctrl and booting
>
> Changes in v4:
> - Rework documentation to be organized by board mfg not cpu mfg
> - Update docs to reflect working SPI support
> - Add proper spi support
> - Don't define unneecessary macros in config.h
> - Lower the default stack so it isn't clobbered on relocation
> - Update MAINTAINERS
> - Update copyright
>
> Changes in v3:
> - Reorder to be last in the patch series
> - Add documentation for the board
> - Generate defconfig with "make savedefconfig"
> - Update Kconfig to imply most features we need
> - Update MAINTAINERS
>
> Changes in v2:
> - Select CONFIG_SYS_RISCV_NOCOUNTER
> - Imply CONFIG_CLK_K210
> - Remove spurious references to CONFIG_ARCH_K210
> - Remove many configs from defconfig where the defaults were fine
> - Add a few "not set" lines to suppress unneeded defaults
> - Reduce pre-reloc malloc space, now that clocks initialization happens
>   later
>
>  arch/riscv/Kconfig |  4 +++
>  board/sipeed/maix/Kconfig  | 47 ++
>  board/sipeed/maix/MAINTAINERS  | 11 +++
>  board/sipeed/maix/Makefile |  5 
>  board/sipeed/maix/maix.c   | 41 ++
>  configs/sipeed_maix_bitm_defconfig |  8 +
>  include/configs/sipeed-maix.h  | 24 +++
>  7 files changed, 140 insertions(+)
>  create mode 100644 board/sipeed/maix/Kconfig
>  create mode 100644 board/sipeed/maix/MAINTAINERS
>  create mode 100644 board/sipeed/maix/Makefile
>  create mode 100644 board/sipeed/maix/maix.c
>  create mode 100644 configs/sipeed_maix_bitm_defconfig
>  create mode 100644 include/configs/sipeed-maix.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index a611f890a1..82d58ea370 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT
>  config TARGET_SIFIVE_FU540
> bool "Support SiFive FU540 Board"
>
> +config TARGET_SIPEED_MAIX
> +   bool "Support Sipeed Maix Board"
> +
>  endchoice
>
>  config SYS_ICACHE_OFF
> @@ -53,6 +56,7 @@ source "board/AndesTech/ax25-ae350/Kconfig"
>  source "board/emulation/qemu-riscv/Kconfig"

Re: [PATCH v11 14/21] riscv: Clean up IPI initialization code

[Rick Chen]

Hi Sean

> The previous IPI code initialized the device whenever the first call was
> made to a riscv_*_ipi function. This made it difficult to determine when
> the IPI device was initialized. This patch introduces a new function
> riscv_init_ipi. It is called once during arch_cpu_init_dm. In SPL, it is
> called in spl_invoke_opensbi. Before this point, no riscv_*_ipi functions
> should be called.
>
> Signed-off-by: Sean Anderson 
> Reviewed-by: Rick Chen 
> ---
>
> Changes in v11:
> - Initialize IPI when used by SPL
> Changes in v9:
> - Fix type of ret variable in riscv_ipi_init
> Changes in v7:
> - Split IPI clearing off into its own patch
>
> Changes in v6:
> - Fix some formatting
> - Clear IPIs before enabling interrupts instead of using a ipi_ready flag
> - Only print messages on error in smp code
>
> Changes in v5:
> - New
>
>  arch/riscv/cpu/cpu.c  |  6 
>  arch/riscv/include/asm/smp.h  | 43 +++
>  arch/riscv/lib/andes_plic.c   | 34 -
>  arch/riscv/lib/sbi_ipi.c  |  5 
>  arch/riscv/lib/sifive_clint.c | 33 +++--
>  arch/riscv/lib/smp.c  | 56 ---
>  common/spl/spl_opensbi.c  |  5 
>  7 files changed, 95 insertions(+), 87 deletions(-)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index 5804aa8e73..d75a3f045a 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -98,6 +98,12 @@ int arch_cpu_init_dm(void)
> csr_write(CSR_SATP, 0);
> }
>
> +#ifdef CONFIG_SMP
> +   ret = riscv_init_ipi();
> +   if (ret)
> +   return ret;
> +#endif
> +
> return 0;
>  }
>
> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> index 74de92ed13..1b428856b2 100644
> --- a/arch/riscv/include/asm/smp.h
> +++ b/arch/riscv/include/asm/smp.h
> @@ -51,4 +51,47 @@ void handle_ipi(ulong hart);
>   */
>  int smp_call_function(ulong addr, ulong arg0, ulong arg1, int wait);
>
> +/**
> + * riscv_init_ipi() - Initialize inter-process interrupt (IPI) driver
> + *
> + * Platform code must provide this function. This function is called once 
> after
> + * the cpu driver is initialized. No other riscv_*_ipi() calls will be made
> + * before this function is called.
> + *
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_init_ipi(void);
> +
> +/**
> + * riscv_send_ipi() - Send inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of receiving hart
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_send_ipi(int hart);
> +
> +/**
> + * riscv_clear_ipi() - Clear inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of hart to be cleared
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_clear_ipi(int hart);
> +
> +/**
> + * riscv_get_ipi() - Get status of inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of hart to be checked
> + * @pending: Pointer to variable with result of the check,
> + *   1 if IPI is pending, 0 otherwise
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_get_ipi(int hart, int *pending);
> +
>  #endif
> diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
> index 20529ab3eb..5cf29df670 100644
> --- a/arch/riscv/lib/andes_plic.c
> +++ b/arch/riscv/lib/andes_plic.c
> @@ -30,20 +30,6 @@
>  #define SEND_IPI_TO_HART(hart)  (0x80 >> (hart))
>
>  DECLARE_GLOBAL_DATA_PTR;
> -static int init_plic(void);
> -
> -#define PLIC_BASE_GET(void)\
> -   do {\
> -   long *ret;  \
> -   \
> -   if (!gd->arch.plic) {   \
> -   ret = syscon_get_first_range(RISCV_SYSCON_PLIC); \
> -   if (IS_ERR(ret))\
> -   return PTR_ERR(ret);\
> -   gd->arch.plic = ret;\
> -   init_plic();\
> -   }   \
> -   } while (0)
>
>  static int enable_ipi(int hart)
>  {
> @@ -93,13 +79,21 @@ static int init_plic(void)
> retu

Re: [PATCH v11 00/18] RISC-V SiFive FU540 support SPL

[Rick Chen]

Hi Bin

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Tuesday, May 19, 2020 4:44 PM
> To: Pragnesh Patel; Rick Jian-Zhi Chen(陳建志)
> Subject: Re: [PATCH v11 00/18] RISC-V SiFive FU540 support SPL
>
> Hi Rick,
>
> On Tue, May 19, 2020 at 3:04 PM Pragnesh Patel  
> wrote:
> >
> > This series add support for SPL to FU540. U-Boot SPL can boot from
> > L2 LIM (0x0800_) and jump to OpenSBI(FW_DYNAMIC firmware) and
> > U-Boot proper from MMC devices.
> >
> > This series depends on:
> > [1] https://patchwork.ozlabs.org/patch/1281853
> > [2] https://patchwork.ozlabs.org/patch/1281852
> >
> > All these together is available for testing here [3] [3]
> > https://github.com/pragnesh26992/u-boot/tree/spl
> >
> > How to test this patch:
> > 1) Go to OpenSBI-dir : make PLATFORM=generic FW_DYNAMIC=y
> > 2) export
> > OPENSBI= > n>
> > 3) Change to u-boot-dir
> > 4) make sifive_fu540_defconfig
> > 5) make all
> > 6) Format the SD card (make sure the disk has GPT, otherwise use gdisk
> > to switch)
> >
> > # sudo sgdisk --clear \
> > > --set-alignment=2 \
> > > --new=1:34:2081 --change-name=1:loader1 
> > --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
> > > --new=2:2082:10273 --change-name=2:loader2 
> > --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
> > > --new=3:10274: --change-name=3:rootfs 
> > --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
> > > /dev/sda
> >
> > 7) sudo dd if=spl/u-boot-spl.bin of=/dev/sda seek=34
> > 8) sudo dd if=u-boot.itb of=/dev/sda seek=2082
> >
> > Changes in v11:
> > - Remove TPL related code and OF_PLATDATA from FU540
> >   DDR driver (drivers/ram/sifive/fu540_ddr.c)
> > - Update FU540 doc (doc/board/sifive/fu540.rst)
> >   Remove unnecessary print
>
> Could we get this v11 applied as soon as possible for v2020.07?

No problem, if everything is OK, I will applied ASAP.
But Jagan seem have some responses, please check about it.

>
> > This series depends on:
> > [1] https://patchwork.ozlabs.org/patch/1281853
> > [2] https://patchwork.ozlabs.org/patch/1281852
>
> Looks this series "riscv: Add Sipeed Maix support" was not applied neither ?

Yes, the reason is that the CI verification of v10 of this series
"riscv: Add Sipeed Maix support" still fail.
Please check the discussion of [v10,20/21] doc: riscv: Add
documentation for Sipeed Maix Bit

https://patchwork.ozlabs.org/project/uboot/patch/20200503024637.327733-21-sean...@gmail.com/

That is why I still not pull it yet.

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH v10 20/21] doc: riscv: Add documentation for Sipeed Maix Bit

[Rick Chen]

Hi Sean

> On 5/5/20 1:02 PM, Sean Anderson wrote:
> > On 5/5/20 5:01 AM, Rick Chen wrote:
> >> Hi Sean
> >>
> >>> This patch adds documentation for the Sipeed Maix bit, and more generally
> >>> for the Kendryte K210 processor.
> >>>
> >>> Signed-off-by: Sean Anderson 
> >>> ---
> >>>
> >>> Changes in v9:
> >>> - Mark dts code block as "none" explicitly
> >>> Changes in v7:
> >>> - Split off into its own patch
> >>> - Fix size of clint
> >>>
> >>>  doc/board/index.rst|   1 +
> >>>  doc/board/sipeed/index.rst |   9 ++
> >>>  doc/board/sipeed/maix.rst  | 298 +
> >>>  3 files changed, 308 insertions(+)
> >>>  create mode 100644 doc/board/sipeed/index.rst
> >>>  create mode 100644 doc/board/sipeed/maix.rst
> >>>
> >>
> >> The CI verification of v10 still fail, please check:
> >> https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/683207657
> >>
> >> Thanks,
> >> Rick
> >
> > Hm, that's strange. I didn't see any of these errors when I ran CI.
> > Perhaps it is an interaction with one of the other patches merged. Is
> > it possible to get the u-boot.map file? The EPC address is present, but
> > without the map we can't tell what function caused the error.
> >
> > --Sean
> >
>
> Ok, so I did some testing, and I was unable to recreate the successful
> test case on my system. For example, I tried to build commit 8d5d3bc,
> which built successfully on travis [1], locally. I got the same output
> as the failing build on travis locally (which is attached as build.log).
> Perhaps it is related to the warning
>
> qemu-system-riscv64: warning: No -bios option specified. Not loading a 
> firmware.
>
> which is present in the failed tests? I would like to bisect this to
> locate the problem, but that won't be possible until I can get a clean
> build to start from.
>
> [1] https://travis-ci.org/github/Forty-Bot/u-boot/jobs/682461390

I just remove your v10 patchs and run again today, it will pass (Build #53)
https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/683645440

Please check about 52 and 53.

Thanks,
Rick

>
> --Sean

Re: [PATCH v10 20/21] doc: riscv: Add documentation for Sipeed Maix Bit

[Rick Chen]

Hi Sean

> This patch adds documentation for the Sipeed Maix bit, and more generally
> for the Kendryte K210 processor.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v9:
> - Mark dts code block as "none" explicitly
> Changes in v7:
> - Split off into its own patch
> - Fix size of clint
>
>  doc/board/index.rst|   1 +
>  doc/board/sipeed/index.rst |   9 ++
>  doc/board/sipeed/maix.rst  | 298 +
>  3 files changed, 308 insertions(+)
>  create mode 100644 doc/board/sipeed/index.rst
>  create mode 100644 doc/board/sipeed/maix.rst
>

The CI verification of v10 still fail, please check:
https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/683207657

Thanks,
Rick

> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 51a2ae6f28..dcc47c5a21 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -16,6 +16,7 @@ Board-specific doc
> renesas/index
> rockchip/index
> sifive/index
> +   sipeed/index
> st/index
> toradex/index
> xilinx/index
> diff --git a/doc/board/sipeed/index.rst b/doc/board/sipeed/index.rst
> new file mode 100644
> index 00..3518e2d8f4
> --- /dev/null
> +++ b/doc/board/sipeed/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Sipeed
> +==
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   maix
> diff --git a/doc/board/sipeed/maix.rst b/doc/board/sipeed/maix.rst
> new file mode 100644
> index 00..06e0008b9f
> --- /dev/null
> +++ b/doc/board/sipeed/maix.rst
> @@ -0,0 +1,298 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +.. Copyright (C) 2020 Sean Anderson 
> +
> +Maix Bit
> +
> +
> +Several of the Sipeed Maix series of boards cotain the Kendryte K210 
> processor,
> +a 64-bit RISC-V CPU. This processor contains several peripherals to 
> accelerate
> +neural network processing and other "ai" tasks. This includes a "KPU" neural
> +network processor, an audio processor supporting beamforming reception, and a
> +digital video port supporting capture and output at VGA resolution. Other
> +peripherals include 8M of SRAM (accessible with and without caching); 
> remappable
> +pins, including 40 GPIOs; AES, FFT, and SHA256 accelerators; a DMA 
> controller;
> +and I2C, I2S, and SPI controllers. Maix peripherals vary, but include spi 
> flash;
> +on-board usb-serial bridges; ports for cameras, displays, and sd cards; and
> +ESP32 chips. Currently, only the Sipeed Maix Bit V2.0 (bitm) is supported, 
> but
> +the boards are fairly similar.
> +
> +Documentation for Maix boards is available from
> +`Sipeed's website `_.
> +Documentation for the Kendryte K210 is available from
> +`Kendryte's website `_. However, hardware
> +details are rather lacking, so most technical reference has been taken from 
> the
> +`standalone sdk `_.
> +
> +Build and boot steps
> +
> +
> +To build u-boot, run
> +
> +.. code-block:: none
> +
> +make sipeed_maix_bitm_defconfig
> +make CROSS_COMPILE=
> +
> +To flash u-boot to a maix bit, run
> +
> +.. code-block:: none
> +
> +kflash -tp /dev/ -B bit_mic u-boot-dtb.bin
> +
> +Boot output should look like the following:
> +
> +.. code-block:: none
> +
> +U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500)
> +
> +DRAM:  8 MiB
> +In:serial@3800
> +Out:   serial@3800
> +Err:   serial@3800
> +=>
> +
> +Loading Images
> +^^
> +
> +To load a kernel, transfer it over serial.
> +
> +.. code-block:: none
> +
> +=> loady 8000 150
> +## Switch baudrate to 150 bps and press ENTER ...
> +
> +*** baud: 150
> +
> +*** baud: 150 ***
> +## Ready for binary (ymodem) download to 0x8000 at 150 bps...
> +C
> +*** file: loader.bin
> +$ sz -vv loader.bin
> +Sending: loader.bin
> +Bytes Sent:2478208   BPS:72937
> +Sending:
> +Ymodem sectors/kbytes sent:   0/ 0k
> +Transfer complete
> +
> +*** exit status: 0 ***
> +## Total Size  = 0x0025d052 = 2478162 Bytes
> +## Switch baudrate to 115200 bps and press ESC ...
> +
> +*** baud: 115200
> +
> +*** baud: 115200 ***
> +=>
> +
> +Running Programs
> +
> +
> +Binaries
> +
> +
> +To run a bare binary, use the ``go`` command:
> +
> +.. code-block:: none
> +
> +=> loady
> +## Ready for binary (ymodem) download to 0x8000 at 115200 bps...
> +C
> +*** file: ./examples/standalone/hello_world.bin
> +$ sz -vv ./examples/standalone/hello_world.bin
> +Sending: hello_world.bin
> +Bytes Sent:   4864   BPS:649
> +Sending:
> +Ymodem sectors/kbytes sent:   0/ 0k
> +Transfer complete
> +
> +*** exit status: 0 ***
> +(CAN) packets, 5 retries
> +## Total Size  = 0x12f8 = 4856 Bytes
> +=> go 8000
> +## Starting applic

Re: [PATCH v10 14/21] riscv: Clean up IPI initialization code

[Rick Chen]

Hi Sean

> The previous IPI code initialized the device whenever the first call was
> made to a riscv_*_ipi function. This made it difficult to determine when
> the IPI device was initialized. This patch introduces a new function
> riscv_init_ipi. It is called once during arch_cpu_init_dm. Before this
> point, no riscv_*_ipi functions should be called.
>
> Signed-off-by: Sean Anderson 
> Reviewed-by: Rick Chen 
> ---
>
> Changes in v9:
> - Fix type of ret variable in riscv_ipi_init
> Changes in v7:
> - Split IPI clearing off into its own patch
>
> Changes in v6:
> - Fix some formatting
> - Clear IPIs before enabling interrupts instead of using a ipi_ready flag
> - Only print messages on error in smp code
>
> Changes in v5:
> - New
>
>  arch/riscv/cpu/cpu.c  |  6 
>  arch/riscv/include/asm/smp.h  | 43 +++
>  arch/riscv/lib/andes_plic.c   | 34 -
>  arch/riscv/lib/sbi_ipi.c  |  5 
>  arch/riscv/lib/sifive_clint.c | 33 +++--
>  arch/riscv/lib/smp.c  | 56 ---
>  6 files changed, 90 insertions(+), 87 deletions(-)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index e457f6acbf..f851374255 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -96,6 +96,12 @@ int arch_cpu_init_dm(void)
> csr_write(CSR_SATP, 0);
> }
>
> +#ifdef CONFIG_SMP
> +   ret = riscv_init_ipi();
> +   if (ret)
> +   return ret;
> +#endif
> +
> return 0;
>  }
>
> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> index 74de92ed13..1b428856b2 100644
> --- a/arch/riscv/include/asm/smp.h
> +++ b/arch/riscv/include/asm/smp.h
> @@ -51,4 +51,47 @@ void handle_ipi(ulong hart);
>   */
>  int smp_call_function(ulong addr, ulong arg0, ulong arg1, int wait);
>
> +/**
> + * riscv_init_ipi() - Initialize inter-process interrupt (IPI) driver
> + *
> + * Platform code must provide this function. This function is called once 
> after
> + * the cpu driver is initialized. No other riscv_*_ipi() calls will be made
> + * before this function is called.
> + *
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_init_ipi(void);
> +
> +/**
> + * riscv_send_ipi() - Send inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of receiving hart
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_send_ipi(int hart);
> +
> +/**
> + * riscv_clear_ipi() - Clear inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of hart to be cleared
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_clear_ipi(int hart);
> +
> +/**
> + * riscv_get_ipi() - Get status of inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of hart to be checked
> + * @pending: Pointer to variable with result of the check,
> + *   1 if IPI is pending, 0 otherwise
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_get_ipi(int hart, int *pending);
> +
>  #endif
> diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
> index 20529ab3eb..5cf29df670 100644
> --- a/arch/riscv/lib/andes_plic.c
> +++ b/arch/riscv/lib/andes_plic.c
> @@ -30,20 +30,6 @@
>  #define SEND_IPI_TO_HART(hart)  (0x80 >> (hart))
>
>  DECLARE_GLOBAL_DATA_PTR;
> -static int init_plic(void);
> -
> -#define PLIC_BASE_GET(void)\
> -   do {\
> -   long *ret;  \
> -   \
> -   if (!gd->arch.plic) {   \
> -   ret = syscon_get_first_range(RISCV_SYSCON_PLIC); \
> -   if (IS_ERR(ret))\
> -   return PTR_ERR(ret);\
> -   gd->arch.plic = ret;\
> -   init_plic();\
> -   }   \
> -   } while (0)
>
>  static int enable_ipi(int hart)
>  {
> @@ -93,13 +79,21 @@ static int init_plic(void)
> return -ENODEV;
>  }
>
> +int riscv_init_ipi(void)
> +{
> +   long *ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
> +
> +   if (IS_ERR(ret))
&g

Re: [PATCH 12/36] bdinfo: riscv: Use the generic bd command

[Rick Chen]

> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Glass
> Sent: Tuesday, May 05, 2020 7:17 AM
> To: U-Boot Mailing List
> Cc: Tom Rini; Simon Glass; Bin Meng; Heiko Schocher
> Subject: [PATCH 12/36] bdinfo: riscv: Use the generic bd command
>
> This arch has none of its own info to show. Move it over to use the generic 
> do_bdinfo().
>
> Signed-off-by: Simon Glass 
> ---
>

Reviewed-by: Rick Chen 

>  cmd/bdinfo.c | 15 +--
>  1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c index 6a2bbfb348..0e96dd619c 100644
> --- a/cmd/bdinfo.c
> +++ b/cmd/bdinfo.c
> @@ -341,20 +341,7 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>
>  #elif defined(CONFIG_RISCV)
>
> -int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) -{
> -   bd_t *bd = gd->bd;
> -
> -   print_bi_boot_params(bd);
> -   print_bi_dram(bd);
> -   print_num("relocaddr", gd->relocaddr);
> -   print_num("reloc off", gd->reloc_off);
> -   print_eth_ip_addr();
> -   print_baudrate();
> -   print_cpu_word_size();
> -
> -   return 0;
> -}
> +#define USE_GENERIC
>
>  #elif defined(CONFIG_ARC)
>
> --
> 2.26.2.526.g744177e7f7-goog

Re: [PATCH 11/36] bdinfo: nds32: Use the generic bd command

[Rick Chen]

> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Glass
> Sent: Tuesday, May 05, 2020 7:17 AM
> To: U-Boot Mailing List
> Cc: Tom Rini; Simon Glass; Bin Meng; Heiko Schocher; Macpaul Lin
> Subject: [PATCH 11/36] bdinfo: nds32: Use the generic bd command
>
> This arch has none of its own info to show. Move it over to use the generic 
> do_bdinfo().
>
> Signed-off-by: Simon Glass 
> ---
>

Reviewed-by: Rick Chen 

>  cmd/bdinfo.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c index dce24b43fa..6a2bbfb348 100644
> --- a/cmd/bdinfo.c
> +++ b/cmd/bdinfo.c
> @@ -337,19 +337,7 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>
>  #elif defined(CONFIG_NDS32)
>
> -int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) -{
> -   bd_t *bd = gd->bd;
> -
> -   print_num("arch_number",bd->bi_arch_number);
> -   print_bi_boot_params(bd);
> -   print_bi_dram(bd);
> -   print_eth_ip_addr();
> -   print_baudrate();
> -   print_cpu_word_size();
> -
> -   return 0;
> -}
> +#define USE_GENERIC
>
>  #elif defined(CONFIG_RISCV)
>
> --
> 2.26.2.526.g744177e7f7-goog

Re: [PATCH 02/36] bdinfo: riscv: Use generic bd_info

[Rick Chen]

> From: Simon Glass [mailto:s...@chromium.org]
> Sent: Tuesday, May 05, 2020 7:17 AM
> To: U-Boot Mailing List
> Cc: Tom Rini; Simon Glass; Joe Hershberger; Rick Jian-Zhi Chen(陳建志)
> Subject: [PATCH 02/36] bdinfo: riscv: Use generic bd_info
>
> At present riscv still uses its own private bd_info struct. Move it over to 
> use the generic one like other archs.
>
> Signed-off-by: Simon Glass 
> ---
>

Reviewed-by: Rick Chen 

>  arch/riscv/include/asm/u-boot.h | 19 ++-
>  1 file changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/arch/riscv/include/asm/u-boot.h 
> b/arch/riscv/include/asm/u-boot.h index 5ba8e77812..d5e1d5f323 100644
> --- a/arch/riscv/include/asm/u-boot.h
> +++ b/arch/riscv/include/asm/u-boot.h
> @@ -18,25 +18,10 @@
>  #ifndef _U_BOOT_H_
>  #define _U_BOOT_H_ 1
>
> +/* Use the generic board which requires a unified bd_info */ #include
> +
>  #include 
>
> -
> -typedef struct bd_info {
> -   unsigned long   bi_boot_params; /* where this board expects params */
> -   unsigned long   bi_memstart;/* start of DRAM memory */
> -   unsigned long   bi_memsize; /* size  of DRAM memory in bytes */
> -   unsigned long   bi_flashstart;  /* start of FLASH memory */
> -   unsigned long   bi_flashsize;   /* size  of FLASH memory */
> -   unsigned long   bi_flashoffset; /* reserved area for startup monitor 
> */
> -   unsigned char   bi_enetaddr[6];
> -
> -   struct  /* RAM configuration */
> -   {
> -   unsigned long start;
> -   unsigned long size;
> -   } bi_dram[CONFIG_NR_DRAM_BANKS];
> -} bd_t;
> -
>  /* For image.h:image_check_target_arch() */  #define IH_ARCH_DEFAULT 
> IH_ARCH_RISCV
>
> --

Re: [PATCH 01/36] bdinfo: nds32: Use generic bd_info

[Rick Chen]

> From: Simon Glass [mailto:s...@chromium.org]
> Sent: Tuesday, May 05, 2020 7:17 AM
> To: U-Boot Mailing List
> Cc: Tom Rini; Simon Glass; Joe Hershberger; Macpaul Lin; Rick Jian-Zhi 
> Chen(陳建志)
> Subject: [PATCH 01/36] bdinfo: nds32: Use generic bd_info
>
> At present nds32 still uses its own private bd_info struct. Move it over to 
> use the generic one like other archs.
>
> Signed-off-by: Simon Glass 
> ---
>

Reviewed-by: Rick Chen 

>  arch/nds32/include/asm/u-boot.h | 20 ++--
>  1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/arch/nds32/include/asm/u-boot.h 
> b/arch/nds32/include/asm/u-boot.h index 8c949e7fb7..7b6e905f2a 100644
> --- a/arch/nds32/include/asm/u-boot.h
> +++ b/arch/nds32/include/asm/u-boot.h
> @@ -19,26 +19,10 @@
>  #ifndef _U_BOOT_H_
>  #define _U_BOOT_H_ 1
>
> +/* Use the generic board which requires a unified bd_info */ #include
> +
>  #include 
>
> -
> -typedef struct bd_info {
> -   unsigned long   bi_arch_number; /* unique id for this board */
> -   unsigned long   bi_boot_params; /* where this board expects params */
> -   unsigned long   bi_memstart;/* start of DRAM memory */
> -   unsigned long   bi_memsize; /* size  of DRAM memory in bytes */
> -   unsigned long   bi_flashstart;  /* start of FLASH memory */
> -   unsigned long   bi_flashsize;   /* size  of FLASH memory */
> -   unsigned long   bi_flashoffset; /* reserved area for startup monitor 
> */
> -   unsigned char   bi_enetaddr[6];
> -
> -   struct  /* RAM configuration */
> -   {
> -   unsigned long start;
> -   unsigned long size;
> -   } bi_dram[CONFIG_NR_DRAM_BANKS];
> -} bd_t;
> -
>  /* For image.h:image_check_target_arch() */  #define IH_ARCH_DEFAULT 
> IH_ARCH_NDS32
>
> --
> 2.26.2.526.g744177e7f7-goog

Re: [PATCH v4 5/5] sifive: fu540: Enable spi-nor flash support

[Rick Chen]

> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: Friday, April 24, 2020 1:01 AM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); Bin Meng; Bhargav Shah; Sagar Shrikant Kadam; 
> linux-amar...@amarulasolutions.com; Jagan Teki
> Subject: [PATCH v4 5/5] sifive: fu540: Enable spi-nor flash support
>
> HiFive Unleashed A00 support is25wp256 spi-nor flash, So enable the same and 
> add test result log for future reference.
>
> Tested on SiFive FU540 board.
>
> Signed-off-by: Jagan Teki 
> Reviewed-by: Bin Meng 

Acked-by: Rick Chen 

> ---
> Changes for v4:
> - none
>
>  arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 1 +
>  board/sifive/fu540/Kconfig  | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> index 8a784b5661..2aebfab646 100644
> --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> @@ -5,6 +5,7 @@
>
>  / {
> aliases {
> +   spi0 = &qspi0;
> spi2 = &qspi2;
> };
>  };
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index 
> 5ca21474de..75661f35f8 100644
> --- a/board/sifive/fu540/Kconfig
> +++ b/board/sifive/fu540/Kconfig
> @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply CMD_FS_GENERIC
> imply CMD_NET
> imply CMD_PING
> +   imply CMD_SF
> imply CLK_SIFIVE
> imply CLK_SIFIVE_FU540_PRCI
> imply DOS_PARTITION
> @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply SIFIVE_SERIAL
> imply SPI
> imply SPI_SIFIVE
> +   imply SPI_FLASH
> +   imply SPI_FLASH_ISSI
> imply MMC
> imply MMC_SPI
> imply MMC_BROKEN_CD
> --
> 2.17.1
>

Re: [PATCH v4 4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi

[Rick Chen]

> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: Friday, April 24, 2020 1:01 AM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志); Bin Meng; Bhargav Shah; Sagar Shrikant Kadam; 
> linux-amar...@amarulasolutions.com; Jagan Teki
> Subject: [PATCH v4 4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi
>
> Add U-Boot specific dts file for hifive-unleashed-a00, this would help to add 
> u-boot specific properties and other node changes without touching the base 
> dts(i) files which are easy to sync from Linux.
>
> Added spi2 alias for qspi2 as an initial u-boot specific property change.
>
> spi probing in current dm model is very much rely on aliases numbering. Even 
> though the qspi2 can't come under any associated spi nor flash it would 
> require to specify the same to make proper binding happen for other spi 
> slaves.
>
> Signed-off-by: Jagan Teki 
> Reviewed-by: Bin Meng 

Acked-by: Rick Chen 

> ---
> Changes for v4:
> - update licence
>
>  arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>  create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>
> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> new file mode 100644
> index 00..8a784b5661
> --- /dev/null
> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (C) 2019 Jagan Teki   */
> +
> +/ {
> +   aliases {
> +   spi2 = &qspi2;
> +   };
> +};
> --
> 2.17.1
>

Re: [PATCH v4 0/5] riscv: sifive/fu540: Enable SPI-NOR support

[Rick Chen]

Hi Jagan

> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> Sent: Saturday, April 25, 2020 7:09 PM
> To: Sagar Kadam; Rick Jian-Zhi Chen(陳建志)
> Cc: u-boot@lists.denx.de; Bin Meng; Bhargav Shah; 
> linux-amar...@amarulasolutions.com
> Subject: Re: [PATCH v4 0/5] riscv: sifive/fu540: Enable SPI-NOR support
>
> On Fri, Apr 24, 2020 at 11:48 PM Sagar Kadam  wrote:
> >
> > Hello Jagan,
> >
> > > -Original Message-
> > > From: Jagan Teki 
> > > Sent: Thursday, April 23, 2020 10:31 PM
> > > To: u-boot@lists.denx.de
> > > Cc: Rick Chen ; Bin Meng ;
> > > Bhargav Shah ; Sagar Kadam
> > > ; linux-amar...@amarulasolutions.com; Jagan
> > > Teki 
> > > Subject: [PATCH v4 0/5] riscv: sifive/fu540: Enable SPI-NOR support
> > >
> > > [External Email] Do not click links or attachments unless you
> > > recognize the sender and know the content is safe
> > >
> > > This is series v4 for SPI-NOR support on SiFive FU540 platform with
> > > HiFive Unleashed board.
> > >
> > > Here is the previous version changes[1].
> > >
> > > All patches on top of u-boot-spi/master.
> > >
> >
> > Thanks for posting v4 for spi-nor support.
> > Tested the series above u-boot-spi/master on HiFive Unleashed and was
> > able to verify it for both spi-nor and mmc Additionally just confirmed the 
> > opcodes nor is configured with post spi_nor_scan:
> > ==
> > [QUAD mode in dt with spi-tx-bus-width: <4>]
> >  pp opcode  = 0x34 [QUAD MODE]
> >  read opcode  = 0x6c  [QUAD MODE]
> >  erase opcode = 0x21
> >
> > SPI-NOR:
> > 1. erase entire flash: Pass
> > 2. write entire flash: Pass
> > 3. read entire flash: Pass
> > 4. cmp 32MiB read back data: Pass
> > 5. MMC: Booted Linux and dtb from mmc (so as to confirm data integrity
> > from mmc)
> > =
> > [SPI MODE in dt with spi-tx-bus-width: <1>  ]
> > pp opcode = 0x12 [SPI MODE]
> > read opcode  = 0xc   [SPI MODE]
> > erase opcode = 0x21
> >
> > SPI-NOR:
> > 1. erase entire flash: Pass
> > 2. write entire flash: Pass
> > 3. read entire flash: Pass
> > 4. cmp 32MiB read back data: Pass
> > 5. MMC: Booted Linux and dtb from mmc (so as to confirm data integrity
> > from mmc)
> >
> > Tested-by: Sagar Kadam 
>
> Thanks for detailed testing of Sagar, I will include these use cases on git 
> log,so-that we can find proper info in future.
>
> Rick,
>
> I would like to pick this via u-boot-spi, let me know if you have any 
> concerns, thanks!
>

I am OK with it.
You can pull it via u-boot-spi.

Thanks,
Rick

> Jagan.

Re: [PATCH v8 00/21] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

> On Wed, Apr 22, 2020 at 10:03:41PM -0400, Sean Anderson wrote:
> > On 4/22/20 9:51 PM, Rick Chen wrote:
> > > Hi Sean
> > >
> > >> Hi Sean
> > >>
> > >>> This patch series adds support for Sipeed Maix boards and the Kendryte
> > >>> K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other
> > >>> models are similar.
> > >>>
> > >>> Known Bugs/Limitations:
> > >>> - Accessing the AI ram hangs, limiting available ram to 6M
> > >>> - Trying to boot an image with bootm fails with
> > >>>   ERROR: Failed to allocate 0x7d60 bytes below 0x8000.
> > >>>
> > >>> To flash u-boot to a maix bit, run
> > >>> kflash -tp /dev/ -B bit_mic u-boot-dtb.bin
> > >>>
> > >>> Boot output should look like the following:
> > >>>
> > >>> U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 
> > >>> -0500)
> > >>>
> > >>> DRAM:  8 MiB
> > >>> In:serial@3800
> > >>> Out:   serial@3800
> > >>> Err:   serial@3800
> > >>> =>
> > >>>
> > >>> Changes for v8:
> > >>> - Removed dependency on the patch "clk: Add functions to register CCF 
> > >>> clock
> > >>>   structs". Hopefully this will make reviewing easier.
> > >>
> > >> I have applied this patch series to u-boot-riscv/master except [PATCH
> > >> v8 14/21] riscv: Clean up IPI initialization code.
> > >> Because it will cause some warnings as below:
> > >>
> > >> arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi':
> > >> arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes
> > >> integer from pointer without a cast [-Wint-conversion]
> > >>   int ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
> > >> ^~
> > >> arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of
> > >> 'IS_ERR' makes pointer from integer without a cast [-Wint-conversion]
> > >>   if (IS_ERR(ret))
> > >>  ^~~
> > >> In file included from arch/riscv/lib/andes_plic.c:20:0:
> > >> include/linux/err.h:34:20: note: expected 'const void *' but argument
> > >> is of type 'int'
> > >>  static inline long IS_ERR(const void *ptr)
> > >> ^~
> > >> arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of
> > >> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion]
> > >>return PTR_ERR(ret);
> > >>   ^~~
> > >> In file included from arch/riscv/lib/andes_plic.c:20:0:
> > >> include/linux/err.h:29:20: note: expected 'const void *' but argument
> > >> is of type 'int'
> > >>  static inline long PTR_ERR(const void *ptr)
> > >> ^~~
> > >> arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer
> > >> from integer without a cast [-Wint-conversion]
> > >>   gd->arch.plic = ret;
> > >>
> > >
> > > after running CI yesterday, it failed in many cases:
> > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678023975
> > >
> > > and I trace at least two cases belong to your patch
> > > 49.59
> > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024035
> > >
> > > arning, treated as error:
> > > /home/travis/build/rickchen36/u-boot-riscv/doc/board/sipeed/maix.rst:173:Error
> > > in "code-block" directive:
> > > 1 argument(s) required, 0 supplied.
> > > .. code-block::
> > > &sysclk {
> > > assigned-clocks = <&sysclk K210_CLK_PLL0>;
> > > assigned-clock-rates = <8>;
> > > };
> > > doc/Makefile:69: recipe for target 'htmldocs' failed
> > > make[1]: *** [htmldocs] Error 1
> >
> > I used to have
> >
> > .. code-block:: dts
> >
> > but it warned that "dts" was not a valid language, so I dropped it.
> >
> > > 49.66
> > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024042
> > >
> > > ./tools/patman/patman --test && ./tools/bui

Re: [PATCH v8 00/21] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

>
> Hi Sean
>
> > On 4/22/20 9:51 PM, Rick Chen wrote:
> > > Hi Sean
> > >
> > >> Hi Sean
> > >>
> > >>> This patch series adds support for Sipeed Maix boards and the Kendryte
> > >>> K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other
> > >>> models are similar.
> > >>>
> > >>> Known Bugs/Limitations:
> > >>> - Accessing the AI ram hangs, limiting available ram to 6M
> > >>> - Trying to boot an image with bootm fails with
> > >>>   ERROR: Failed to allocate 0x7d60 bytes below 0x8000.
> > >>>
> > >>> To flash u-boot to a maix bit, run
> > >>> kflash -tp /dev/ -B bit_mic u-boot-dtb.bin
> > >>>
> > >>> Boot output should look like the following:
> > >>>
> > >>> U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 
> > >>> -0500)
> > >>>
> > >>> DRAM:  8 MiB
> > >>> In:serial@3800
> > >>> Out:   serial@3800
> > >>> Err:   serial@3800
> > >>> =>
> > >>>
> > >>> Changes for v8:
> > >>> - Removed dependency on the patch "clk: Add functions to register CCF 
> > >>> clock
> > >>>   structs". Hopefully this will make reviewing easier.
> > >>
> > >> I have applied this patch series to u-boot-riscv/master except [PATCH
> > >> v8 14/21] riscv: Clean up IPI initialization code.
> > >> Because it will cause some warnings as below:
> > >>
> > >> arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi':
> > >> arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes
> > >> integer from pointer without a cast [-Wint-conversion]
> > >>   int ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
> > >> ^~
> > >> arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of
> > >> 'IS_ERR' makes pointer from integer without a cast [-Wint-conversion]
> > >>   if (IS_ERR(ret))
> > >>  ^~~
> > >> In file included from arch/riscv/lib/andes_plic.c:20:0:
> > >> include/linux/err.h:34:20: note: expected 'const void *' but argument
> > >> is of type 'int'
> > >>  static inline long IS_ERR(const void *ptr)
> > >> ^~
> > >> arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of
> > >> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion]
> > >>return PTR_ERR(ret);
> > >>   ^~~
> > >> In file included from arch/riscv/lib/andes_plic.c:20:0:
> > >> include/linux/err.h:29:20: note: expected 'const void *' but argument
> > >> is of type 'int'
> > >>  static inline long PTR_ERR(const void *ptr)
> > >> ^~~
> > >> arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer
> > >> from integer without a cast [-Wint-conversion]
> > >>   gd->arch.plic = ret;
> > >>
> > >
> > > after running CI yesterday, it failed in many cases:
> > > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678023975
> > >
> > > and I trace at least two cases belong to your patch
> > > 49.59
> > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024035
> > >
> > > arning, treated as error:
> > > /home/travis/build/rickchen36/u-boot-riscv/doc/board/sipeed/maix.rst:173:Error
> > > in "code-block" directive:
> > > 1 argument(s) required, 0 supplied.
> > > .. code-block::
> > > &sysclk {
> > > assigned-clocks = <&sysclk K210_CLK_PLL0>;
> > > assigned-clock-rates = <8>;
> > > };
> > > doc/Makefile:69: recipe for target 'htmldocs' failed
> > > make[1]: *** [htmldocs] Error 1
> >
> > I used to have
> >
> > .. code-block:: dts
> >
> > but it warned that "dts" was not a valid language, so I dropped it.
> >
> > > 49.66
> > > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024042
> > >
> > > ./tools/patman/patman --test && ./tools/buildman/buildman -t &&
> > > ./tool

Re: [PATCH v8 00/21] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

> On 4/22/20 9:51 PM, Rick Chen wrote:
> > Hi Sean
> >
> >> Hi Sean
> >>
> >>> This patch series adds support for Sipeed Maix boards and the Kendryte
> >>> K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other
> >>> models are similar.
> >>>
> >>> Known Bugs/Limitations:
> >>> - Accessing the AI ram hangs, limiting available ram to 6M
> >>> - Trying to boot an image with bootm fails with
> >>>   ERROR: Failed to allocate 0x7d60 bytes below 0x8000.
> >>>
> >>> To flash u-boot to a maix bit, run
> >>> kflash -tp /dev/ -B bit_mic u-boot-dtb.bin
> >>>
> >>> Boot output should look like the following:
> >>>
> >>> U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500)
> >>>
> >>> DRAM:  8 MiB
> >>> In:serial@3800
> >>> Out:   serial@3800
> >>> Err:   serial@3800
> >>> =>
> >>>
> >>> Changes for v8:
> >>> - Removed dependency on the patch "clk: Add functions to register CCF 
> >>> clock
> >>>   structs". Hopefully this will make reviewing easier.
> >>
> >> I have applied this patch series to u-boot-riscv/master except [PATCH
> >> v8 14/21] riscv: Clean up IPI initialization code.
> >> Because it will cause some warnings as below:
> >>
> >> arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi':
> >> arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes
> >> integer from pointer without a cast [-Wint-conversion]
> >>   int ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
> >> ^~
> >> arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of
> >> 'IS_ERR' makes pointer from integer without a cast [-Wint-conversion]
> >>   if (IS_ERR(ret))
> >>  ^~~
> >> In file included from arch/riscv/lib/andes_plic.c:20:0:
> >> include/linux/err.h:34:20: note: expected 'const void *' but argument
> >> is of type 'int'
> >>  static inline long IS_ERR(const void *ptr)
> >> ^~
> >> arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of
> >> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion]
> >>return PTR_ERR(ret);
> >>   ^~~
> >> In file included from arch/riscv/lib/andes_plic.c:20:0:
> >> include/linux/err.h:29:20: note: expected 'const void *' but argument
> >> is of type 'int'
> >>  static inline long PTR_ERR(const void *ptr)
> >> ^~~
> >> arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer
> >> from integer without a cast [-Wint-conversion]
> >>   gd->arch.plic = ret;
> >>
> >
> > after running CI yesterday, it failed in many cases:
> > https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678023975
> >
> > and I trace at least two cases belong to your patch
> > 49.59
> > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024035
> >
> > arning, treated as error:
> > /home/travis/build/rickchen36/u-boot-riscv/doc/board/sipeed/maix.rst:173:Error
> > in "code-block" directive:
> > 1 argument(s) required, 0 supplied.
> > .. code-block::
> > &sysclk {
> > assigned-clocks = <&sysclk K210_CLK_PLL0>;
> > assigned-clock-rates = <8>;
> > };
> > doc/Makefile:69: recipe for target 'htmldocs' failed
> > make[1]: *** [htmldocs] Error 1
>
> I used to have
>
> .. code-block:: dts
>
> but it warned that "dts" was not a valid language, so I dropped it.
>
> > 49.66
> > https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024042
> >
> > ./tools/patman/patman --test && ./tools/buildman/buildman -t &&
> > ./tools/dtoc/dtoc -t && make testconfig; fi; fi
> > cp: cannot create regular file
> > '/home/travis/build/rickchen36/sandbox/': Not a directory
> > cp: cannot create regular file
> > '/home/travis/build/rickchen36/sandbox/': Not a directory
> > WARNING: no status info for 'sipeed_maix_bitm'
> > WARNING: no maintainers for 'sipeed_maix_bitm'
>
> I'm not sure what the issue here is. Which specific files are lacking a
> MAINTAINERS entry?
>
> >
> > So I will drop your patchs and run CI again today.
> > And hope you can fix them in next version and pass CI verification.
>
>
>
> >
> > Thanks,
> > Rick
> >
>
> These "errors" seem rather minor. I will fix the PLIC ones in the next
> revision, but I don't think the sort found in this email are
> particularly erroneous.


Can you run and pass Travis CI after you fix your patchs
It help us to maintain the quality about patch works.

Thanks,
Rick

>
> --Sean
>

Re: [PATCH v8 00/21] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

> Hi Sean
>
> > This patch series adds support for Sipeed Maix boards and the Kendryte
> > K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other
> > models are similar.
> >
> > Known Bugs/Limitations:
> > - Accessing the AI ram hangs, limiting available ram to 6M
> > - Trying to boot an image with bootm fails with
> >   ERROR: Failed to allocate 0x7d60 bytes below 0x8000.
> >
> > To flash u-boot to a maix bit, run
> > kflash -tp /dev/ -B bit_mic u-boot-dtb.bin
> >
> > Boot output should look like the following:
> >
> > U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500)
> >
> > DRAM:  8 MiB
> > In:serial@3800
> > Out:   serial@3800
> > Err:   serial@3800
> > =>
> >
> > Changes for v8:
> > - Removed dependency on the patch "clk: Add functions to register CCF clock
> >   structs". Hopefully this will make reviewing easier.
>
> I have applied this patch series to u-boot-riscv/master except [PATCH
> v8 14/21] riscv: Clean up IPI initialization code.
> Because it will cause some warnings as below:
>
> arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi':
> arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes
> integer from pointer without a cast [-Wint-conversion]
>   int ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
> ^~
> arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of
> 'IS_ERR' makes pointer from integer without a cast [-Wint-conversion]
>   if (IS_ERR(ret))
>  ^~~
> In file included from arch/riscv/lib/andes_plic.c:20:0:
> include/linux/err.h:34:20: note: expected 'const void *' but argument
> is of type 'int'
>  static inline long IS_ERR(const void *ptr)
> ^~
> arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of
> 'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion]
>return PTR_ERR(ret);
>   ^~~
> In file included from arch/riscv/lib/andes_plic.c:20:0:
> include/linux/err.h:29:20: note: expected 'const void *' but argument
> is of type 'int'
>  static inline long PTR_ERR(const void *ptr)
> ^~~
> arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer
> from integer without a cast [-Wint-conversion]
>   gd->arch.plic = ret;
>

after running CI yesterday, it failed in many cases:
https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/678023975

and I trace at least two cases belong to your patch
49.59
https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024035

arning, treated as error:
/home/travis/build/rickchen36/u-boot-riscv/doc/board/sipeed/maix.rst:173:Error
in "code-block" directive:
1 argument(s) required, 0 supplied.
.. code-block::
&sysclk {
assigned-clocks = <&sysclk K210_CLK_PLL0>;
assigned-clock-rates = <8>;
};
doc/Makefile:69: recipe for target 'htmldocs' failed
make[1]: *** [htmldocs] Error 1

49.66
https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/678024042

./tools/patman/patman --test && ./tools/buildman/buildman -t &&
./tools/dtoc/dtoc -t && make testconfig; fi; fi
cp: cannot create regular file
'/home/travis/build/rickchen36/sandbox/': Not a directory
cp: cannot create regular file
'/home/travis/build/rickchen36/sandbox/': Not a directory
WARNING: no status info for 'sipeed_maix_bitm'
WARNING: no maintainers for 'sipeed_maix_bitm'

So I will drop your patchs and run CI again today.
And hope you can fix them in next version and pass CI verification.

Thanks,
Rick

Re: [PATCH v8 00/21] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

> This patch series adds support for Sipeed Maix boards and the Kendryte
> K210 CPU. Currently, only the Maix Bit V2.0 is supported, however other
> models are similar.
>
> Known Bugs/Limitations:
> - Accessing the AI ram hangs, limiting available ram to 6M
> - Trying to boot an image with bootm fails with
>   ERROR: Failed to allocate 0x7d60 bytes below 0x8000.
>
> To flash u-boot to a maix bit, run
> kflash -tp /dev/ -B bit_mic u-boot-dtb.bin
>
> Boot output should look like the following:
>
> U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500)
>
> DRAM:  8 MiB
> In:serial@3800
> Out:   serial@3800
> Err:   serial@3800
> =>
>
> Changes for v8:
> - Removed dependency on the patch "clk: Add functions to register CCF clock
>   structs". Hopefully this will make reviewing easier.

I have applied this patch series to u-boot-riscv/master except [PATCH
v8 14/21] riscv: Clean up IPI initialization code.
Because it will cause some warnings as below:

arch/riscv/lib/andes_plic.c: In function 'riscv_init_ipi':
arch/riscv/lib/andes_plic.c:84:12: warning: initialization makes
integer from pointer without a cast [-Wint-conversion]
  int ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
^~
arch/riscv/lib/andes_plic.c:86:13: warning: passing argument 1 of
'IS_ERR' makes pointer from integer without a cast [-Wint-conversion]
  if (IS_ERR(ret))
 ^~~
In file included from arch/riscv/lib/andes_plic.c:20:0:
include/linux/err.h:34:20: note: expected 'const void *' but argument
is of type 'int'
 static inline long IS_ERR(const void *ptr)
^~
arch/riscv/lib/andes_plic.c:87:18: warning: passing argument 1 of
'PTR_ERR' makes pointer from integer without a cast [-Wint-conversion]
   return PTR_ERR(ret);
  ^~~
In file included from arch/riscv/lib/andes_plic.c:20:0:
include/linux/err.h:29:20: note: expected 'const void *' but argument
is of type 'int'
 static inline long PTR_ERR(const void *ptr)
^~~
arch/riscv/lib/andes_plic.c:88:16: warning: assignment makes pointer
from integer without a cast [-Wint-conversion]
  gd->arch.plic = ret;

Thanks,
Rick


>
> Changes for v7:
> - Split documentation from other board support
> - Split IPI clear from other IPI cleanup
> - Rebased onto a clean upstream. Hopefully this fixes any patching
>   problems.
>
> Changes for v6:
> - Remove spi, pinmux, gpio, led, and wdt support --- to be added in separate
>   patches
> - Rebase onto master
> - Clear IPIs before enabling them
> - Reorganize code so checkpatch errors less
>
> Changes for v5:
> - Rebase onto master
> - Add pinconf support
> - Add gpio support
> - Store environment in spi flash
> - Group patches by prefix
> - Add additional documentation
> - Add SMP support
> - Add WDT support
>
> Changes for v4:
> - Linted several patches
> - Updated the copyright year for several files
> - Added tests for syscon-reset, simple-pm-bus, and the pll calc_rate function
> - Added/updated documentation
> - Fixed SPI for the nor flash
> - Fixed PLLs not enabling/setting rate properly
> - RISCV_PRIV_1_9_1 now (un)defines all diferring CSRs, and also disables VM
> - More devicetree changes
>
> Changes for v3:
> - Remove patch to set RV64I as default
> - Remove patch for a separate sysctl driver
> - Split off cpu frequency patch into its own series
> - Reorder support/devicetree patches to come last
> - Add patch for reset driver
> - Add simple-pm-bus for busses with their own clocks
> - Add additional documentation
> - Reword mcounteren patch to refer to the RISC-V priv spec 1.9.1
> - Many devicetree changes
> - Switch to "make savedefconfig" to generate the config
>
> Changes for v2:
> - Many bugfixes for the device tree
> - Modify the config to build without errors
> - Add support for keeping internal PLL frequencies in-range
> - Fix several rebase-induced artifacts
>
> Sean Anderson (21):
>   clk: Always use the supplied struct clk
>   clk: Check that ops of composite clock components exist before calling
>   clk: Unconditionally recursively en-/dis-able clocks
>   clk: Fix clk_get_by_* handling of index
>   clk: Add K210 pll support
>   clk: Add a bypass clock for K210
>   clk: Add K210 clock support
>   dm: Add support for simple-pm-bus
>   dm: Fix error handling for dev_read_addr_ptr
>   reset: Add generic reset driver
>   lib: Always set errno in hcreate_r
>   riscv: Add headers for asm/global_data.h
>   riscv: Clear pending interrupts before enabling IPIs
>   riscv: Clean up IPI initialization code
>   riscv: Add option to support RISC-V privileged spec 1.9
>   riscv: Allow use of reset drivers
>   riscv: Try to get cpu frequency from a "clocks" node if it exists
>   riscv: Enable cpu clock if it is present
>   riscv: Add device tree for K210 and Sipeed Maix BitM
>   doc: riscv: Add documentation for Sipeed Maix Bit
>   riscv: Add Sipeed Maix support
>
>  MAINTAINERS

Re: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved memory

[Rick Chen]

Hi Atish

> On Mon, Apr 20, 2020 at 1:41 AM Rick Chen  wrote:
> >
> > Hi Atish
> >
> > > From: Atish Patra [mailto:atish.pa...@wdc.com]
> > > Sent: Sunday, April 19, 2020 3:32 AM
> > > To: u-boot@lists.denx.de
> > > Cc: Atish Patra; Bin Meng; Anup Patel; Lukas Auer; Heinrich Schuchardt; 
> > > ag...@csgraf.de; ard.biesheu...@linaro.org; Marcus Comstedt; Paul 
> > > Walmsley; Rick Jian-Zhi Chen(陳建志); pal...@dabbelt.com
> > > Subject: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved 
> > > memory
> > >
> > > In RISC-V, M-mode software can reserve physical memory regions by setting 
> > > appropriate physical memory protection (PMP) csr. As the PMP csr are 
> > > accessible only in M-mode, S-mode U-Boot can not read this configuration 
> > > directly. However, M-mode software can pass this information via 
> > > reserved-memory node in device tree so that S-mode software can access 
> > > this information.
> > >
> > > This patch provides a framework to copy to the reserved-memory node from 
> > > one DT to another. This will be used to update the DT used by U-Boot and 
> > > the DT passed to the next stage OS.
> > >
> > > Signed-off-by: Atish Patra 
> > > Reviewed-by: Bin Meng 
> > > ---
> > >  arch/riscv/cpu/start.S|   1 +
> > >  arch/riscv/include/asm/global_data.h  |   1 +
> > >  arch/riscv/include/asm/u-boot-riscv.h |   2 +
> > >  arch/riscv/lib/Makefile   |   1 +
> > >  arch/riscv/lib/asm-offsets.c  |   1 +
> > >  arch/riscv/lib/fdt_fixup.c| 102 ++
> > >  6 files changed, 108 insertions(+)
> > >  create mode 100644 arch/riscv/lib/fdt_fixup.c
> > >
> >
> > I am trying to applied Bin and your patch.
> > The sequence of apply is according to submit date.
> > This patch seem conflict with [PATCH v2 2/6] riscv: Merge unnecessary
> > SMP ifdefs in start.S of Bin
> > Can you rebase it and send again ?
> >
>
> Ok. I will rebase on top of Bin's series and resend.
>

Please rebase on u-boot-riscv/master.
I also applied Sean's patch today.

Thanks,
Rick

> > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index 
> > > 6b3ff99c3882..0282685c2906 100644
> > > --- a/arch/riscv/cpu/start.S
> > > +++ b/arch/riscv/cpu/start.S
> > > @@ -121,6 +121,7 @@ call_board_init_f_0:
> > >
> > > jal board_init_f_init_reserve
> > >
> > > +   SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> > > /* save the boot hart id to global_data */
> > > SREGtp, GD_BOOT_HART(gp)
> > >
> > > diff --git a/arch/riscv/include/asm/global_data.h 
> > > b/arch/riscv/include/asm/global_data.h
> > > index b74bd7e738bb..51ac8d1c98e2 100644
> > > --- a/arch/riscv/include/asm/global_data.h
> > > +++ b/arch/riscv/include/asm/global_data.h
> > > @@ -15,6 +15,7 @@
> > >  /* Architecture-specific global data */  struct arch_global_data {
> > > long boot_hart; /* boot hart id */
> > > +   phys_addr_t firmware_fdt_addr;
> > >  #ifdef CONFIG_SIFIVE_CLINT
> > > void __iomem *clint;/* clint base address */
> > >  #endif
> > > diff --git a/arch/riscv/include/asm/u-boot-riscv.h 
> > > b/arch/riscv/include/asm/u-boot-riscv.h
> > > index 49febd588102..543a1688db8f 100644
> > > --- a/arch/riscv/include/asm/u-boot-riscv.h
> > > +++ b/arch/riscv/include/asm/u-boot-riscv.h
> > > @@ -17,5 +17,7 @@ int cleanup_before_linux(void);
> > >  /* board/.../... */
> > >  int board_init(void);
> > >  void board_quiesce_devices(void);
> > > +int riscv_board_reserved_mem_fixup(void *fdt); int
> > > +riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
> > >
> > >  #endif /* _U_BOOT_RISCV_H_ */
> > > diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 
> > > adadbf4bcbef..d132b59ce32c 100644
> > > --- a/arch/riscv/lib/Makefile
> > > +++ b/arch/riscv/lib/Makefile
> > > @@ -24,6 +24,7 @@ obj-y += reset.o
> > >  obj-y   += setjmp.o
> > >  obj-$(CONFIG_SMP) += smp.o
> > >  obj-$(CONFIG_SPL_BUILD)+= spl.o
> > > +obj-y   += fdt_fixup.o
> > >
> > >  # For building EFI apps
> > >  CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
> > > diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-of

Re: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved memory

[Rick Chen]

Hi Atish

> From: Atish Patra [mailto:atish.pa...@wdc.com]
> Sent: Sunday, April 19, 2020 3:32 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra; Bin Meng; Anup Patel; Lukas Auer; Heinrich Schuchardt; 
> ag...@csgraf.de; ard.biesheu...@linaro.org; Marcus Comstedt; Paul Walmsley; 
> Rick Jian-Zhi Chen(陳建志); pal...@dabbelt.com
> Subject: [PATCH v6 3/6] riscv: Provide a mechanism to fix DT for reserved 
> memory
>
> In RISC-V, M-mode software can reserve physical memory regions by setting 
> appropriate physical memory protection (PMP) csr. As the PMP csr are 
> accessible only in M-mode, S-mode U-Boot can not read this configuration 
> directly. However, M-mode software can pass this information via 
> reserved-memory node in device tree so that S-mode software can access this 
> information.
>
> This patch provides a framework to copy to the reserved-memory node from one 
> DT to another. This will be used to update the DT used by U-Boot and the DT 
> passed to the next stage OS.
>
> Signed-off-by: Atish Patra 
> Reviewed-by: Bin Meng 
> ---
>  arch/riscv/cpu/start.S|   1 +
>  arch/riscv/include/asm/global_data.h  |   1 +
>  arch/riscv/include/asm/u-boot-riscv.h |   2 +
>  arch/riscv/lib/Makefile   |   1 +
>  arch/riscv/lib/asm-offsets.c  |   1 +
>  arch/riscv/lib/fdt_fixup.c| 102 ++
>  6 files changed, 108 insertions(+)
>  create mode 100644 arch/riscv/lib/fdt_fixup.c
>

I am trying to applied Bin and your patch.
The sequence of apply is according to submit date.
This patch seem conflict with [PATCH v2 2/6] riscv: Merge unnecessary
SMP ifdefs in start.S of Bin
Can you rebase it and send again ?

Thanks
Rick

> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index 
> 6b3ff99c3882..0282685c2906 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -121,6 +121,7 @@ call_board_init_f_0:
>
> jal board_init_f_init_reserve
>
> +   SREGs1, GD_FIRMWARE_FDT_ADDR(gp)
> /* save the boot hart id to global_data */
> SREGtp, GD_BOOT_HART(gp)
>
> diff --git a/arch/riscv/include/asm/global_data.h 
> b/arch/riscv/include/asm/global_data.h
> index b74bd7e738bb..51ac8d1c98e2 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -15,6 +15,7 @@
>  /* Architecture-specific global data */  struct arch_global_data {
> long boot_hart; /* boot hart id */
> +   phys_addr_t firmware_fdt_addr;
>  #ifdef CONFIG_SIFIVE_CLINT
> void __iomem *clint;/* clint base address */
>  #endif
> diff --git a/arch/riscv/include/asm/u-boot-riscv.h 
> b/arch/riscv/include/asm/u-boot-riscv.h
> index 49febd588102..543a1688db8f 100644
> --- a/arch/riscv/include/asm/u-boot-riscv.h
> +++ b/arch/riscv/include/asm/u-boot-riscv.h
> @@ -17,5 +17,7 @@ int cleanup_before_linux(void);
>  /* board/.../... */
>  int board_init(void);
>  void board_quiesce_devices(void);
> +int riscv_board_reserved_mem_fixup(void *fdt); int
> +riscv_fdt_copy_resv_mem_node(const void *src_fdt, void *dest_fdt);
>
>  #endif /* _U_BOOT_RISCV_H_ */
> diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 
> adadbf4bcbef..d132b59ce32c 100644
> --- a/arch/riscv/lib/Makefile
> +++ b/arch/riscv/lib/Makefile
> @@ -24,6 +24,7 @@ obj-y += reset.o
>  obj-y   += setjmp.o
>  obj-$(CONFIG_SMP) += smp.o
>  obj-$(CONFIG_SPL_BUILD)+= spl.o
> +obj-y   += fdt_fixup.o
>
>  # For building EFI apps
>  CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
> diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c 
> index 4fa4fd371473..7301c1b98e23 100644
> --- a/arch/riscv/lib/asm-offsets.c
> +++ b/arch/riscv/lib/asm-offsets.c
> @@ -14,6 +14,7 @@
>  int main(void)
>  {
> DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
> +   DEFINE(GD_FIRMWARE_FDT_ADDR, offsetof(gd_t, arch.firmware_fdt_addr));
>  #ifndef CONFIG_XIP
> DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));  
> #endif diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c 
> new file mode 100644 index ..1fce41490973
> --- /dev/null
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -0,0 +1,102 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020 Western Digital Corporation or its affiliates
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/**
> + * riscv_fdt_copy_resv_mem_node() - Copy reserve memory node entry
> + * @src: Pointer to the source device tree from which reserved memory node
> + *  needs to be copied.
> + * @dst: Pointer to the destination device tree to which reserved memory node
> + *  needs to be copied.
> + *
> + * Return: 0 on success or if source doesn't have reserved memory node.
> + *Error if copy process failed.
> + */
> +int riscv_fdt_copy_resv_mem_node(const void *src, void *dst) {
> +   u32 phandle;
> +   struct fdt_memory pmp_mem;
> +   

Re: [PATCH v2] riscv: ax25: cache: Remove SPL_RISCV_MMODE config check

[Rick Chen]

> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Saturday, April 18, 2020 10:44 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志)
> Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; Paul 
> Walmsley; Simon Glass; Trevor Woerner
> Subject: RE: [PATCH v2] riscv: ax25: cache: Remove SPL_RISCV_MMODE config 
> check
>
> Any comments on this patch ?

Thanks for reviewing.
I will pull it later.

Thanks,
Rick

>
> >-Original Message-
> >From: Pragnesh Patel 
> >Sent: 14 March 2020 19:13
> >To: u-boot@lists.denx.de
> >Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com;
> >Paul Walmsley ; r...@andestech.com; Pragnesh
> >Patel ; Simon Glass ;
> >Trevor Woerner 
> >Subject: [PATCH v2] riscv: ax25: cache: Remove SPL_RISCV_MMODE config
> >check
> >
> >CONFIG_IS_ENABLED(FOO) will check FOO config option for U-Boot, SPL and
> >TPL, so remove unnecessary CONFIG_IS_ENABLED()
> >
> >Signed-off-by: Pragnesh Patel 
> >Reviewed-by: Bin Meng 
> >---
> > arch/riscv/cpu/ax25/cache.c | 16 
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> >diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
> >index 9f424198b4..9df629d23c 100644
> >--- a/arch/riscv/cpu/ax25/cache.c
> >+++ b/arch/riscv/cpu/ax25/cache.c
> >@@ -12,7 +12,7 @@
> > #include 
> >
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> > /* mcctlcommand */
> > #define CCTL_REG_MCCTLCOMMAND_NUM 0x7cc
> >
> >@@ -47,7 +47,7 @@ void flush_dcache_all(void)  {  #if
> >!CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >   csr_write(CCTL_REG_MCCTLCOMMAND_NUM,
> >CCTL_L1D_WBINVAL_ALL);  #endif  #endif @@ -68,7 +68,7 @@ void
> >icache_enable(void)  {  #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >   asm volatile (
> >   "csrr t1, mcache_ctl\n\t"
> >   "ori t0, t1, 0x1\n\t"
> >@@ -83,7 +83,7 @@ void icache_disable(void)  {  #if
> >!CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >   asm volatile (
> >   "fence.i\n\t"
> >   "csrr t1, mcache_ctl\n\t"
> >@@ -99,7 +99,7 @@ void dcache_enable(void)  {  #if
> >!CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >   asm volatile (
> >   "csrr t1, mcache_ctl\n\t"
> >   "ori t0, t1, 0x2\n\t"
> >@@ -117,7 +117,7 @@ void dcache_disable(void)  {  #if
> >!CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >   csr_write(CCTL_REG_MCCTLCOMMAND_NUM,
> >CCTL_L1D_WBINVAL_ALL);
> >   asm volatile (
> >   "csrr t1, mcache_ctl\n\t"
> >@@ -137,7 +137,7 @@ int icache_status(void)
> >   int ret = 0;
> >
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >   asm volatile (
> >   "csrr t1, mcache_ctl\n\t"
> >   "andi   %0, t1, 0x01\n\t"
> >@@ -156,7 +156,7 @@ int dcache_status(void)
> >   int ret = 0;
> >
> > #ifdef CONFIG_RISCV_NDS_CACHE
> >-#if CONFIG_IS_ENABLED(RISCV_MMODE) ||
> >CONFIG_IS_ENABLED(SPL_RISCV_MMODE)
> >+#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >   asm volatile (
> >   "csrr t1, mcache_ctl\n\t"
> >   "andi   %0, t1, 0x02\n\t"
> >--
> >2.17.1

Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI

[Rick Chen]

Hi Bin

> Hi Rick,
>
> On Fri, Apr 17, 2020 at 8:51 AM Rick Chen  wrote:
> >
> >  於 2020年4月17日 週五 上午8:39寫道：
> > >
> > >
> > >
> > > -Original Message-
> > > From: Atish Patra [mailto:ati...@atishpatra.org]
> > > Sent: Wednesday, April 15, 2020 7:18 AM
> > > To: Bin Meng
> > > Cc: Ard Biesheuvel; Heinrich Schuchardt; U-Boot Mailing List; Anup Patel; 
> > > Lukas Auer; Alexander Graf; Rick Jian-Zhi Chen(陳建志); Palmer Dabbelt
> > > Subject: Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & 
> > > UEFI
> > >
> > > On Mon, Apr 13, 2020 at 3:42 PM Bin Meng  wrote:
> > > >
> > > > Hi Atish,
> > > >
> > > > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra  
> > > > wrote:
> > > > >
> > > > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote:
> > > > > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra 
> > > > > > > > >  wrote:
> > > > > > > > >>
> > > > > > > > >> This series adds few DT related fixes required for Linux
> > > > > > > > >> EFI stub to work on RISC-V.
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > > I'm not sure how this is supposed to work, since DT reserved
> > > > > > > > > memory regions are not used by EFI. If you want to reserve
> > > > > > > > > memory on a UEFI system, you have to reserve it in the UEFI 
> > > > > > > > > memory map from firmware.
> > > > > > > > > The DT reserved-memory node is taken into account too late,
> > > > > > > > > the /memreserve/ entries are ignored entirely.
> > > > > > > >
> > > > > > > > Hello Ard,
> > > > > > > >
> > > > > > > > thanks for reviewing.
> > > > > > > >
> > > > > > > > What do you mean by "The DT reserved-memory node is taken into
> > > > > > > > account too late"?
> > > > > > > >
> > > > > > > > Cf. commit 7be64b885a36 ("cmd: bootefi: Parse reserved-memory
> > > > > > > > node from DT")
> > > > > > > >
> > > > > > >
> > > > > > > What I mean is that the EFI stub in Linux uses memory allocation
> > > > > > > functions, expecting the firmware to ensure that those
> > > > > > > allocations do not conflict with memory descriptions and
> > > > > > > reservations in DT. So if the firmware wants to express this
> > > > > > > redundantly, by passing reservations in both reserved-memory and
> > > > > > > in the EFI memory map, that is probably fine.
> > > > > > >
> > > > > > > Also, I must sheepishly admit that I only realize now that this
> > > > > > > patch set is against u-boot not Linux :-)
> > > > > > >
> > > > > > :)
> > > > > >
> > > > > > > So if fixed reserved-memory regions are only being used to seed
> > > > > > > the reserved regions in the EFI memory map, you can safely ignore 
> > > > > > > me.
> > > > > >
> > > > > > Yeah. That's the purpose. Having reserved memory nodes in the
> > > > > > final DT used by linux also ensures that proper Linux adds a
> > > > > > reserved memory block or removes it from memblock entries
> > > > > > depending on "no-map" property.
> > > > > >
> > > > > > > Apologies for the noise.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Atish
> > > > >
> > > > > Any other comments on the series ? It would be great if this series
> > > > > could be merged before
> > > > > v2020.07 release.
> > > >
> > > > I hope so if no one objects the proposed solution here in U-Boot vs.
> > > > the PMP SBI extension. I need have another look at the latest version
> > > > of patches though.
> > > >
> > >
> > > Thanks. As far as I know, there is no opposition to the current approach 
> > > adopted in U-Boot.
> > > I am hoping EFI stub series can be merged before 5.8. If this series can 
> > > go in v2020.07, RISC-V will have all required support to boot via EFI 
> > > from Linux kernel v5.8 and U-Boot v2020.07.
> >
> > OK!
> > I will pull and send a PR ASAP.
>
> I will need have a look and test today. Please wait for some time.
>

OK
No problem :)

Thanks,
Rick

> Regards,
> Bin

Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI

[Rick Chen]

 於 2020年4月17日 週五 上午8:39寫道：
>
>
>
> -Original Message-
> From: Atish Patra [mailto:ati...@atishpatra.org]
> Sent: Wednesday, April 15, 2020 7:18 AM
> To: Bin Meng
> Cc: Ard Biesheuvel; Heinrich Schuchardt; U-Boot Mailing List; Anup Patel; 
> Lukas Auer; Alexander Graf; Rick Jian-Zhi Chen(陳建志); Palmer Dabbelt
> Subject: Re: [PATCH v5 0/6] RISC-V DT related fixes for reserved memory & UEFI
>
> On Mon, Apr 13, 2020 at 3:42 PM Bin Meng  wrote:
> >
> > Hi Atish,
> >
> > On Tue, Apr 14, 2020 at 6:02 AM Atish Patra  wrote:
> > >
> > > On Tue, Apr 7, 2020 at 10:35 AM Atish Patra  wrote:
> > > >
> > > > On Mon, Apr 6, 2020 at 11:51 PM Ard Biesheuvel
> > > >  wrote:
> > > > >
> > > > > On Tue, 7 Apr 2020 at 08:46, Heinrich Schuchardt  
> > > > > wrote:
> > > > > >
> > > > > > On 4/6/20 11:01 PM, Ard Biesheuvel wrote:
> > > > > > > On Mon, 6 Apr 2020 at 22:45, Atish Patra  
> > > > > > > wrote:
> > > > > > >>
> > > > > > >> This series adds few DT related fixes required for Linux
> > > > > > >> EFI stub to work on RISC-V.
> > > > > > >>
> > > > > > >
> > > > > > > I'm not sure how this is supposed to work, since DT reserved
> > > > > > > memory regions are not used by EFI. If you want to reserve
> > > > > > > memory on a UEFI system, you have to reserve it in the UEFI 
> > > > > > > memory map from firmware.
> > > > > > > The DT reserved-memory node is taken into account too late,
> > > > > > > the /memreserve/ entries are ignored entirely.
> > > > > >
> > > > > > Hello Ard,
> > > > > >
> > > > > > thanks for reviewing.
> > > > > >
> > > > > > What do you mean by "The DT reserved-memory node is taken into
> > > > > > account too late"?
> > > > > >
> > > > > > Cf. commit 7be64b885a36 ("cmd: bootefi: Parse reserved-memory
> > > > > > node from DT")
> > > > > >
> > > > >
> > > > > What I mean is that the EFI stub in Linux uses memory allocation
> > > > > functions, expecting the firmware to ensure that those
> > > > > allocations do not conflict with memory descriptions and
> > > > > reservations in DT. So if the firmware wants to express this
> > > > > redundantly, by passing reservations in both reserved-memory and
> > > > > in the EFI memory map, that is probably fine.
> > > > >
> > > > > Also, I must sheepishly admit that I only realize now that this
> > > > > patch set is against u-boot not Linux :-)
> > > > >
> > > > :)
> > > >
> > > > > So if fixed reserved-memory regions are only being used to seed
> > > > > the reserved regions in the EFI memory map, you can safely ignore me.
> > > >
> > > > Yeah. That's the purpose. Having reserved memory nodes in the
> > > > final DT used by linux also ensures that proper Linux adds a
> > > > reserved memory block or removes it from memblock entries
> > > > depending on "no-map" property.
> > > >
> > > > > Apologies for the noise.
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Atish
> > >
> > > Any other comments on the series ? It would be great if this series
> > > could be merged before
> > > v2020.07 release.
> >
> > I hope so if no one objects the proposed solution here in U-Boot vs.
> > the PMP SBI extension. I need have another look at the latest version
> > of patches though.
> >
>
> Thanks. As far as I know, there is no opposition to the current approach 
> adopted in U-Boot.
> I am hoping EFI stub series can be merged before 5.8. If this series can go 
> in v2020.07, RISC-V will have all required support to boot via EFI from Linux 
> kernel v5.8 and U-Boot v2020.07.

OK!
I will pull and send a PR ASAP.

Thanks,
Rick

Re: [PATCH 4/7] riscv: Add SMP Kconfig option dependency for U-Boot proper

[Rick Chen]

Hi Sean

> From: Sean Anderson [mailto:sean...@gmail.com]
> Sent: Wednesday, April 08, 2020 10:21 PM
> To: Bin Meng; Rick Jian-Zhi Chen(陳建志); Lukas Auer; Anup Patel; Atish Patra; 
> Pragnesh Patel; U-Boot Mailing List
> Subject: Re: [PATCH 4/7] riscv: Add SMP Kconfig option dependency for U-Boot 
> proper
>
> On 4/8/20 9:41 AM, Bin Meng wrote:
> > U-Boot proper running in S-mode only need SMP support when using SBI
> > v0.1. With SBI v0.2 HSM extension, it does not need implement
> > multicore boot in U-Boot proper.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/riscv/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index
> > 10478ae..502143f 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -193,6 +193,7 @@ config SYS_MALLOC_F_LEN
> >
> >  config SMP
> >   bool "Symmetric Multi-Processing"
> > + depends on SBI_V01
>
> So should this be
>
> "depends on SBI_V01 or RISCV_PRIV_1_9"
>
> when the priv spec 1.9 patch gets merged?
>

Your series: [v7,22/22] riscv: Add Sipeed Maix support

There are some patchs still need to be fixed:

[v7,22/22] riscv: Add Sipeed Maix support
https://patchwork.ozlabs.org/patch/1258463/

[v7,15/22] riscv: Clean up IPI initialization code
https://patchwork.ozlabs.org/patch/1258461/

And there are two patchs about clk still get no positive response from
clk maintainer

[v7,05/22] clk: Add functions to register CCF clock structs
https://patchwork.ozlabs.org/patch/1258446/

[v7,04/22] clk: Fix clk_get_by_* handling of index
https://patchwork.ozlabs.org/patch/1258442/


Thanks
Rick

> >   help
> > This enables support for systems with more than one CPU. If
> > you say N here, U-Boot will run on single and multiprocessor
> >
>
> --Sean
>

Re: [PATCH v7 15/22] riscv: Clean up IPI initialization code

[Rick Chen]

Hi Sean

> > The previous IPI code initialized the device whenever the first call was
> > made to a riscv_*_ipi function. This made it difficult to determine when
> > the IPI device was initialized. This patch introduces a new function
> > riscv_init_ipi. It is called once during arch_cpu_init_dm. Before this
> > point, no riscv_*_ipi functions should be called.
> >
> > Signed-off-by: Sean Anderson 
>
> Reviewed-by: Rick Chen 

conflict with u-boot/master, please rebase

Thanks
Rick

Applying: riscv: Clean up IPI initialization code
error: patch failed: arch/riscv/lib/sbi_ipi.c:7
error: arch/riscv/lib/sbi_ipi.c: patch does not apply
Patch failed at 0001 riscv: Clean up IPI initialization code
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [PATCH v7 22/22] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

> The Sipeed Maix series is a collection of boards built around the RISC-V
> Kendryte K210 processor. This processor contains several peripherals to
> accelerate neural network processing and other "ai" tasks. This includes a
> "KPU" neural network processor, an audio processor supporting beamforming
> reception, and a digital video port supporting capture and output at VGA
> resolution. Other peripherals include 8M of sram (accessible with and
> without caching); remappable pins, including 40 GPIOs; AES, FFT, and SHA256
> accelerators; a DMA controller; and I2C, I2S, and SPI controllers. Maix
> peripherals vary, but include spi flash; on-board usb-serial bridges; ports
> for cameras, displays, and sd cards; and ESP32 chips. Currently, only the
> Sipeed Maix Bit V2.0 (bitm) is supported, but the boards are fairly
> similar.
>
> Documentation for Maix boards is located at
> .  Documentation for the Kendryte K210 is
> located at . However, hardware details are
> rather lacking, so most technical reference has been taken from the
> standalone sdk located at
> .
>
> Signed-off-by: Sean Anderson 
> board f

Please remove "board f"

>
> ---
>
> Changes in v7:
> - Split docs off into their own patch
> - Enable ram clocks by name
>
> Changes in v6:
> - Remove trailing whitespace from documentation
> - Remove configuration for spi/pinmux/gpio features
> - Flesh out documentation some more
>
> Changes in v5:
> - Configure relocation location with CONFIG_SYS_SDRAM_*
> - Enable ram clocks
> - Add pinmux/gpio/led support
> - Remove (broken) MMC support
> - Store the environment in flash
> - Add partitions
> - Add bootcmd
> - Add docs for pinctrl and booting
>
> Changes in v4:
> - Rework documentation to be organized by board mfg not cpu mfg
> - Update docs to reflect working SPI support
> - Add proper spi support
> - Don't define unneecessary macros in config.h
> - Lower the default stack so it isn't clobbered on relocation
> - Update MAINTAINERS
> - Update copyright
>
> Changes in v3:
> - Reorder to be last in the patch series
> - Add documentation for the board
> - Generate defconfig with "make savedefconfig"
> - Update Kconfig to imply most features we need
> - Update MAINTAINERS
>
> Changes in v2:
> - Select CONFIG_SYS_RISCV_NOCOUNTER
> - Imply CONFIG_CLK_K210
> - Remove spurious references to CONFIG_ARCH_K210
> - Remove many configs from defconfig where the defaults were fine
> - Add a few "not set" lines to suppress unneeded defaults
> - Reduce pre-reloc malloc space, now that clocks initialization happens
>   later
>
>  arch/riscv/Kconfig |  4 +++
>  board/sipeed/maix/Kconfig  | 48 ++
>  board/sipeed/maix/MAINTAINERS  | 11 ++
>  board/sipeed/maix/Makefile |  5 +++
>  board/sipeed/maix/maix.c   | 54 ++
>  configs/sipeed_maix_bitm_defconfig |  8 +
>  include/configs/sipeed-maix.h  | 24 +
>  7 files changed, 154 insertions(+)
>  create mode 100644 board/sipeed/maix/Kconfig
>  create mode 100644 board/sipeed/maix/MAINTAINERS
>  create mode 100644 board/sipeed/maix/Makefile
>  create mode 100644 board/sipeed/maix/maix.c
>  create mode 100644 configs/sipeed_maix_bitm_defconfig
>  create mode 100644 include/configs/sipeed-maix.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index b7a5757584..d016dd75d7 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT
>  config TARGET_SIFIVE_FU540
> bool "Support SiFive FU540 Board"
>
> +config TARGET_SIPEED_MAIX
> +   bool "Support Sipeed Maix Board"
> +
>  endchoice
>
>  config SYS_ICACHE_OFF
> @@ -53,6 +56,7 @@ source "board/AndesTech/ax25-ae350/Kconfig"
>  source "board/emulation/qemu-riscv/Kconfig"
>  source "board/microchip/mpfs_icicle/Kconfig"
>  source "board/sifive/fu540/Kconfig"
> +source "board/sipeed/maix/Kconfig"
>
>  # platform-specific options below
>  source "arch/riscv/cpu/ax25/Kconfig"
> diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
> new file mode 100644
> index 00..8292089fc9
> --- /dev/null
> +++ b/board/sipeed/maix/Kconfig
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (C) 2019-20 Sean Anderson 
> +
> +if TARGET_SIPEED_MAIX
> +
> +config SYS_BOARD
> +   default "maix"
> +
> +config SYS_VENDOR
> +   default "sipeed"
> +
> +config SYS_CPU
> +   default "generic"
> +
> +config SYS_CONFIG_NAME
> +   default "sipeed-maix"
> +
> +config SYS_TEXT_BASE
> +   default 0x8000
> +
> +config DEFAULT_DEVICE_TREE
> +   default "k210-maix-bit"
> +
> +config NR_CPUS
> +   default 2
> +
> +config NR_DRAM_BANKS
> +   default 3
> +
> +config BOARD_SPECIFIC_OPTIONS
> +   def_bool y
> +   select GENERIC_RISCV
> +   select RISCV_PRIV_1_9
> +   imply SMP
> +

Re: [PATCH v7 05/22] clk: Add functions to register CCF clock structs

[Rick Chen]

Hi Peng and Lukasz

> This patch adds alternate versions of the clk_*_register functions for use
> with statically-allocated struct clks. This allows drivers to define clocks
> at compile-time and register them at run-time without malloc-ing. This
> increases the size of the binary, but should not affect ram usage (since
> the clocks now no longer live on the heap).
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v5:
> - New
>
>  drivers/clk/clk-composite.c  | 103 +++
>  drivers/clk/clk-divider.c|  56 +--
>  drivers/clk/clk-gate.c   |  38 -
>  include/linux/clk-provider.h |   9 +++
>  4 files changed, 112 insertions(+), 94 deletions(-)
>

Do you have any comments about this patch ?

Thanks
Rick

> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index 819bfca2fc..b328c4e5a5 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -95,6 +95,51 @@ static int clk_composite_disable(struct clk *clk)
> return 0;
>  }
>
> +struct clk *clk_register_composite_struct(const char *name,
> + const char * const *parent_names,
> + int num_parents,
> + struct clk_composite *composite)
> +{
> +   int ret;
> +   struct clk *clk;
> +
> +   if (!num_parents || (num_parents != 1 && !composite->mux))
> +   return ERR_PTR(-EINVAL);
> +
> +   if (composite->mux && composite->mux_ops)
> +   composite->mux->data = (ulong)composite;
> +
> +   if (composite->rate && composite->rate_ops) {
> +   if (!composite->rate_ops->get_rate)
> +   return ERR_PTR(-EINVAL);
> +
> +   composite->rate->data = (ulong)composite;
> +   }
> +
> +   if (composite->gate && composite->gate_ops) {
> +   if (!composite->gate_ops->enable ||
> +   !composite->gate_ops->disable)
> +   return ERR_PTR(-EINVAL);
> +
> +   composite->gate->data = (ulong)composite;
> +   }
> +
> +   clk = &composite->clk;
> +   ret = clk_register(clk, UBOOT_DM_CLK_COMPOSITE, name,
> +  parent_names[clk_composite_get_parent(clk)]);
> +   if (ret)
> +   clk = ERR_PTR(ret);
> +
> +   if (composite->mux)
> +   composite->mux->dev = clk->dev;
> +   if (composite->rate)
> +   composite->rate->dev = clk->dev;
> +   if (composite->gate)
> +   composite->gate->dev = clk->dev;
> +
> +   return clk;
> +}
> +
>  struct clk *clk_register_composite(struct device *dev, const char *name,
>const char * const *parent_names,
>int num_parents, struct clk *mux,
> @@ -107,62 +152,24 @@ struct clk *clk_register_composite(struct device *dev, 
> const char *name,
>  {
> struct clk *clk;
> struct clk_composite *composite;
> -   int ret;
> -
> -   if (!num_parents || (num_parents != 1 && !mux))
> -   return ERR_PTR(-EINVAL);
>
> composite = kzalloc(sizeof(*composite), GFP_KERNEL);
> if (!composite)
> return ERR_PTR(-ENOMEM);
>
> -   if (mux && mux_ops) {
> -   composite->mux = mux;
> -   composite->mux_ops = mux_ops;
> -   mux->data = (ulong)composite;
> -   }
> +   composite->mux = mux;
> +   composite->mux_ops = mux_ops;
>
> -   if (rate && rate_ops) {
> -   if (!rate_ops->get_rate) {
> -   clk = ERR_PTR(-EINVAL);
> -   goto err;
> -   }
> +   composite->rate = rate;
> +   composite->rate_ops = rate_ops;
>
> -   composite->rate = rate;
> -   composite->rate_ops = rate_ops;
> -   rate->data = (ulong)composite;
> -   }
> +   composite->gate = gate;
> +   composite->gate_ops = gate_ops;
>
> -   if (gate && gate_ops) {
> -   if (!gate_ops->enable || !gate_ops->disable) {
> -   clk = ERR_PTR(-EINVAL);
> -   goto err;
> -   }
> -
> -   composite->gate = gate;
> -   composite->gate_ops = gate_ops;
> -   gate->data = (ulong)composite;
> -   }
> -
> -   clk = &composite->clk;
> -   ret = clk_register(clk, UBOOT_DM_CLK_COMPOSITE, name,
> -  parent_names[clk_composite_get_parent(clk)]);
> -   if (ret) {
> -   clk = ERR_PTR(ret);
> -   goto err;
> -   }
> -
> -   if (composite->mux)
> -   composite->mux->dev = clk->dev;
> -   if (composite->rate)
> -   composite->rate->dev = clk->dev;
> -   if (composite->gate)
> -   composite->gate->dev = clk->dev;
> -
> -   return clk;
> -
> 

Re: [PATCH v7 04/22] clk: Fix clk_get_by_* handling of index

[Rick Chen]

Hi Jagan

> clk_get_by_index_nodev only ever fetched clock 1, due to passing a boolean
> predicate instead of the index. Other clk_get_by_* functions got the clock
> correctly, but passed a predicate instead of the index to clk_get_by_tail.
> This could lead to confusing error messages.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v7:
> - New
>
>  drivers/clk/clk-uclass.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index aa8dd9d027..c082fe95ff 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c

Do you have any suggestions about this patch ?

Thanks
Rick

> @@ -121,7 +121,7 @@ static int clk_get_by_indexed_prop(struct udevice *dev, 
> const char *prop_name,
>
>
> return clk_get_by_index_tail(ret, dev_ofnode(dev), &args, "clocks",
> -index > 0, clk);
> +index, clk);
>  }
>
>  int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
> @@ -133,7 +133,7 @@ int clk_get_by_index(struct udevice *dev, int index, 
> struct clk *clk)
>  index, &args);
>
> return clk_get_by_index_tail(ret, dev_ofnode(dev), &args, "clocks",
> -index > 0, clk);
> +index, clk);
>  }
>
>  int clk_get_by_index_nodev(ofnode node, int index, struct clk *clk)
> @@ -142,10 +142,10 @@ int clk_get_by_index_nodev(ofnode node, int index, 
> struct clk *clk)
> int ret;
>
> ret = ofnode_parse_phandle_with_args(node, "clocks", "#clock-cells", 
> 0,
> -index > 0, &args);
> +index, &args);
>
> return clk_get_by_index_tail(ret, node, &args, "clocks",
> -index > 0, clk);
> +index, clk);
>  }
>
>  int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk)
> --
> 2.25.1
>

Re: [PATCH 1/3] riscv: Start using ldflags-y for 32/64bit LDFLAGS

[Rick Chen]

> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Friday, March 27, 2020 9:52 PM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志)
> Subject: [PATCH 1/3] riscv: Start using ldflags-y for 32/64bit LDFLAGS
>
> To prepare to update our Kbuild logic, start switching some of our cases of 
> adding different bit/endian linker flags via ldflags-y
>
> Cc: Rick Chen 
> Signed-off-by: Tom Rini 
> ---
>  arch/riscv/config.mk | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)

Reviewed-by: Rick Chen 
.

Re: [PATCH v7 14/22] riscv: Clear pending interrupts before enabling IPIs

[Rick Chen]

> On some platforms (k210), the previous stage bootloader may have not
> cleared pending IPIs before transferring control to U-Boot. This can cause
> race conditions, as multiple harts all attempt to initialize the IPI
> controller at once. This patch clears IPIs before enabling them, ensuring
> that only one hart modifies shared memory at once.
>
> Signed-off-by: Sean Anderson 
> ---

Reviewed-by: Rick Chen 

Re: [PATCH v7 15/22] riscv: Clean up IPI initialization code

[Rick Chen]

> The previous IPI code initialized the device whenever the first call was
> made to a riscv_*_ipi function. This made it difficult to determine when
> the IPI device was initialized. This patch introduces a new function
> riscv_init_ipi. It is called once during arch_cpu_init_dm. Before this
> point, no riscv_*_ipi functions should be called.
>
> Signed-off-by: Sean Anderson 

Reviewed-by: Rick Chen 

Re: [PATCH v5 12/14] riscv: sifive: fu540: enable all cache ways from u-boot proper

[Rick Chen]

Hi Pragnesh

> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Tuesday, March 17, 2020 5:52 PM
> To: Bin Meng; Anup Patel
> Cc: U-Boot Mailing List; Atish Patra; Palmer Dabbelt; Paul Walmsley; Jagan 
> Teki; Troy Benjegerdes; Anup Patel; Sagar Kadam; Rick Jian-Zhi Chen(陳建志); 
> Palmer Dabbelt
> Subject: RE: [PATCH v5 12/14] riscv: sifive: fu540: enable all cache ways 
> from u-boot proper
>
>
> Hi,
>
> >-Original Message-
> >From: Bin Meng 
> >Sent: 13 March 2020 19:19
> >To: Anup Patel 
> >Cc: Pragnesh Patel ; U-Boot Mailing List  >b...@lists.denx.de>; Atish Patra ; Palmer Dabbelt
> >; Paul Walmsley ;
> >Jagan Teki ; Troy Benjegerdes
> >; Anup Patel ; Sagar
> >Kadam ; Rick Chen ; Palmer
> >Dabbelt 
> >Subject: Re: [PATCH v5 12/14] riscv: sifive: fu540: enable all cache
> >ways from u-boot proper
> >
> >Hi Anup,
> >
> >On Fri, Mar 13, 2020 at 6:49 PM Anup Patel  wrote:
> >>
> >> On Fri, Mar 13, 2020 at 3:52 PM Bin Meng  wrote:
> >> >
> >> > Hi Anup,
> >> >
> >> > On Fri, Mar 13, 2020 at 6:02 PM Anup Patel  wrote:
> >> > >
> >> > > On Fri, Mar 13, 2020 at 2:31 PM Bin Meng 
> >wrote:
> >> > > >
> >> > > > On Wed, Mar 11, 2020 at 3:04 PM Pragnesh Patel
> >> > > >  wrote:
> >> > > > >
> >> > > > > Enable all cache ways from u-boot proper.
> >> > > >
> >> > > > U-Boot
> >> > > >
> >> > > > >
> >> > > > > Signed-off-by: Pragnesh Patel 
> >> > > > > ---
> >> > > > >  board/sifive/fu540/Makefile |  1 +
> >> > > > > board/sifive/fu540/cache.c  | 20 
> >> > > > > board/sifive/fu540/cache.h  | 13 +
> >> > > > > board/sifive/fu540/fu540.c  |  6 --
> >> > > > >  4 files changed, 38 insertions(+), 2 deletions(-)  create
> >> > > > > mode 100644 board/sifive/fu540/cache.c  create mode 100644
> >> > > > > board/sifive/fu540/cache.h
> >> > > > >
> >> > > > > diff --git a/board/sifive/fu540/Makefile
> >> > > > > b/board/sifive/fu540/Makefile index b05e2f5807..3b867bbd89
> >> > > > > 100644
> >> > > > > --- a/board/sifive/fu540/Makefile
> >> > > > > +++ b/board/sifive/fu540/Makefile
> >> > > > > @@ -3,6 +3,7 @@
> >> > > > >  # Copyright (c) 2019 Western Digital Corporation or its 
> >> > > > > affiliates.
> >> > > > >
> >> > > > >  obj-y  += fu540.o
> >> > > > > +obj-y  += cache.o
> >> > > > >
> >> > > > >  ifdef CONFIG_SPL_BUILD
> >> > > > >  obj-y += spl.o
> >> > > > > diff --git a/board/sifive/fu540/cache.c
> >> > > > > b/board/sifive/fu540/cache.c new file mode 100644 index
> >> > > > > 00..a0bcd2ba48
> >> > > > > --- /dev/null
> >> > > > > +++ b/board/sifive/fu540/cache.c
> >> > > >
> >> > > > This should be put into arch/riscv/cpu/fu540/cache.c
> >> > > >
> >> > > > > @@ -0,0 +1,20 @@
> >> > > > > +// SPDX-License-Identifier: GPL-2.0+
> >> > > > > +/*
> >> > > > > + * Copyright (c) 2019 SiFive, Inc  */ #include 
> >> > > > > +
> >> > > > > +/* Register offsets */
> >> > > > > +#define CACHE_ENABLE   0x008
> >> > > > > +
> >> > > > > +/* Enable ways; allow cache to use these ways */ void
> >> > > > > +cache_enable_ways(u64 base_addr, u8 value) {
> >> > > > > +   volatile u32 *enable = (volatile u32 *)(base_addr +
> >> > > > > + CACHE_ENABLE);
> >> > > > > +   /* memory barrier */
> >> > > > > +   mb();
> >> > > > > +   (*enable) = value;
> >> > > > > +   /* memory barrier */
> >> > > > > +   mb();
> >> > > > > +}
> >> > > > > diff --git a/board/sifive/fu540/cache.h
> >> > > > > b/board/sifive/fu540/cache.h new file

Re: [PATCHv2 2/8] Kconfig: Remove redundant variable sets

[Rick Chen]

> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Thursday, March 12, 2020 6:11 AM
> To: u-boot@lists.denx.de
> Cc: Michal Simek; Rick Jian-Zhi Chen(陳建志); Philippe Reynes; Eric Jarrige
> Subject: [PATCHv2 2/8] Kconfig: Remove redundant variable sets
>
> In a few places we have Kconfig entries that set SPL_LDSCRIPT to what is the 
> default value anyways.  Drop these.
>
> Cc: Michal Simek 
> Cc: Rick Chen 
> Cc: Philippe Reynes 
> Cc: Eric Jarrige 
> Signed-off-by: Tom Rini 
> ---
>  arch/microblaze/Kconfig  | 3 ---
>  arch/riscv/Kconfig   | 3 ---
>  board/armadeus/apf27/Kconfig | 3 ---
>  3 files changed, 9 deletions(-)
>
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index 
> 5ce8261451d3..2bd260e5d76e 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -30,7 +30,4 @@ config STACK_SIZE
>
>  source "board/xilinx/microblaze-generic/Kconfig"
>
> -config SPL_LDSCRIPT
> -   default "arch/microblaze/cpu/u-boot-spl.lds"
> -
>  endmenu
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> 3338b788f84a..f49618d24d26 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -229,7 +229,4 @@ config STACK_SIZE_SHIFT
>     int
> default 14
>
> -config SPL_LDSCRIPT
> -   default "arch/riscv/cpu/u-boot-spl.lds"
> -

Reviewed-by: Rick Chen 

Re: [PATCH v6 03/19] clk: Unconditionally recursively en-/dis-able clocks

[Rick Chen]

Hi Sean


> On 3/10/20 2:51 AM, Rick Chen wrote:
> > Hi Sean
> >
> >>> For clocks not in the CCF, their parents will not have UCLASS_CLK, so we
> >>> just enable them as normal. The enable count is local to the struct clk,
> >>> but this will never result in the actual en-/dis-able op being called
> >>> (unless the same struct clk is enabled twice).
> >>>
> >>> For clocks in the CCF, we always traverse up the tree when enabling.
> >>> Previously, CCF clocks without id set would be skipped, stopping the
> >>> traversal too early.
> >>>
> >>> Signed-off-by: Sean Anderson 
> >>> Acked-by: Lukasz Majewski 
> >>> ---
> >>>
> >>> Changes in v5:
> >>> - Clear enable_count on request
> >>>
> >>> Changes in v4:
> >>> - Lint
> >>>
> >>> Changes in v3:
> >>> - New
> >>>
> >>>  drivers/clk/clk-uclass.c | 60 ++--
> >>>  1 file changed, 27 insertions(+), 33 deletions(-)
> >>>
> >>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> >>> index d497737298..3b711395b8 100644
> >>> --- a/drivers/clk/clk-uclass.c
> >>> +++ b/drivers/clk/clk-uclass.c
> >>> @@ -410,6 +410,7 @@ int clk_request(struct udevice *dev, struct clk *clk)
> >>> ops = clk_dev_ops(dev);
> >>>
> >>> clk->dev = dev;
> >>> +   clk->enable_count = 0;
> >>
> >> Lukasz has taged Acked-by in v3.
> >> Re: [PATCH v3 03/12] clk: Unconditionally recursively en-/dis-able clocks
> >>
> >> This patch shall be fixed and freeze.
> >> But you add a new modification (Clear enable_count on request)in v5 and v6.
> >> Although it seem to look fine and nothing big deal.
> >> I just highlight it here, and if Lukasz have no other comment further.
> >> I will pull it via riscv tree later.
> >>
> >
> > I have told you in v5, that this patch have conflict with
> > u-boot/master please rebase it.
> > But it still conflict in v6.
> >
> > https://patchwork.ozlabs.org/patch/1246836/
> >
> > Applying: clk: Always use the supplied struct clk
> > Applying: clk: Check that ops of composite clock components exist before 
> > calling
> > Applying: clk: Unconditionally recursively en-/dis-able clocks
> > error: patch failed: drivers/clk/clk-uclass.c:522
> > error: drivers/clk/clk-uclass.c: patch does not apply
> > Patch failed at 0003 clk: Unconditionally recursively en-/dis-able clocks
> > The copy of the patch that failed is found in: .git/rebase-apply/patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
> >
> >
>
> This was just rebased against u-boot/master. Should I be rebasing
> against a different branch? The commit I am working off is

It is just fine to sync with u-boot/master.
Before I send a PR, I shall sync to u-boot/master too.

Thanks,
Rick

>
> $ git show upstream/master
> commit 1efb9796f80e1394f080be1b4f3173ff108ad1f2 (upstream/master, 
> upstream/WIP/03Mar2020, upstream/HEAD)
> Merge: 8aad16916d 9aa886cc0b
> Author: Tom Rini 
> Date:   Tue Mar 3 21:48:49 2020 -0500
>
> Merge tag 'dm-pull-3mar20' of git://git.denx.de/u-boot-dm
>
> Fixes for power domain on device removal
>
> >> Thanks,
> >> Rick
> >>
> >>
> >>
> >>>
> >>> if (!ops->request)
> >>> return 0;
> >>> @@ -522,7 +523,6 @@ int clk_set_parent(struct clk *clk, struct clk 
> >>> *parent)
> >>>  int clk_enable(struct clk *clk)
> >>>  {
> >>> const struct clk_ops *ops;
> >>> -   struct clk *clkp = NULL;
> >>> int ret;
> >>>
> >>> debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
> >>> @@ -531,32 +531,29 @@ int clk_enable(struct clk *clk)
> >>> ops = clk_dev_ops(clk->dev);
> >>>
> >>> if (CONFIG_IS_ENABLED(CLK_CCF)) {
> >>> -   /* Take id 0 as a non-valid clk, such as dummy */
> >>> -   if (clk->id && !clk_get_by_id(clk->id, &c

Re: [PATCH v6 19/19] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

> On 3/10/20 5:04 AM, Rick Chen wrote:
> > Hi Sean
> >
> >> The Sipeed Maix series is a collection of boards built around the RISC-V
> >> Kendryte K210 processor. This processor contains several peripherals to
> >> accelerate neural network processing and other "ai" tasks. This includes a
> >> "KPU" neural network processor, an audio processor supporting beamforming
> >> reception, and a digital video port supporting capture and output at VGA
> >> resolution. Other peripherals include 8M of sram (accessible with and
> >> without caching); remappable pins, including 40 GPIOs; AES, FFT, and SHA256
> >> accelerators; a DMA controller; and I2C, I2S, and SPI controllers. Maix
> >> peripherals vary, but include spi flash; on-board usb-serial bridges; ports
> >> for cameras, displays, and sd cards; and ESP32 chips. Currently, only the
> >> Sipeed Maix Bit V2.0 (bitm) is supported, but the boards are fairly
> >> similar.
> >>
> >> Documentation for Maix boards is located at
> >> <http://dl.sipeed.com/MAIX/HDK/>.  Documentation for the Kendryte K210 is
> >> located at <https://kendryte.com/downloads/>. However, hardware details are
> >> rather lacking, so most technical reference has been taken from the
> >> standalone sdk located at
> >> <https://github.com/kendryte/kendryte-standalone-sdk>.
> >>
> >> Signed-off-by: Sean Anderson 
> >> ---
> >
> > This patch applying fail
> >
> > Applying: riscv: Add Sipeed Maix support
> > error: patch failed: doc/board/index.rst:16
> > error: doc/board/index.rst: patch does not apply
> > Patch failed at 0001 riscv: Add Sipeed Maix support
> > The copy of the patch that failed is found in: .git/rebase-apply/patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
> >
> > I have replied to you the same result in v5
> > [v5,33/33] riscv: Add Sipeed Maix support
> > https://patchwork.ozlabs.org/patch/1246869/#2376311
>
> As above, I just rebased against u-boot/master. I'm not sure what's
> causing the problem here.
>
> >
> > By the way,
> > you can not mix them (arch, board, configs, doc)together in a patch.
> > arch/riscv/Kconfig
> > board/sipeed/maix/ ...
> > configs/sipeed_maix_bitm_defconfig
> > doc/board/index.rst
>
> Is there a preferred order for adding these? I will split them for v7.

Maybe you can group them as two patchs

patch 19/20
 arch/riscv/Kconfig
 board/sipeed/maix/Kconfig
 board/sipeed/maix/MAINTAINERS
 board/sipeed/maix/Makefile
 board/sipeed/maix/maix.c
 configs/sipeed_maix_bitm_defconfig
 include/configs/sipeed-maix.h

patch 19/20
 doc/board/index.rst
 doc/board/sipeed/index.rst
 doc/board/sipeed/maix.rst

Thanks,
Rick


>
> > Thanks,
> > Rick
>

Re: [PATCH v6 18/19] riscv: Add device tree for K210 and Sipeed Maix BitM

[Rick Chen]

Hi Sean

> On 3/10/20 5:08 AM, Rick Chen wrote:
> > Hi Sean
> >
> >> Where possible, I have tried to find compatible drivers based on the layout
> >> of registers. However, many devices remain untested. All untested devices
> >> have been left disabled, but some tentative properties (such as compatible
> >> strings, and clocks, interrupts, and resets properties) have been added.
> >>
> >> Signed-off-by: Sean Anderson 
> >> ---
> >>
> >> Changes in v6:
> >> - Remove spi, gpio, pinmux, wdt, and led bindings
> >> - Use consistent capitalization for hex digits
> >>
> >> Changes in v5:
> >> - Add more compatible strings
> >> - Add cache line size
> >> - Document CPUs as rocket cores
> >> - Flesh out the gpio devices
> >> - Add ports for audio and video devices
> >> - Add fpioa pinctrl support
> >> - Configure pins for MMC on SPI1
> >> - Enable MMC
> >> - Fix a couple uart properties (Thanks laanwj)
> >> - Reorder ram now that relocation is handled with CONFIG_SYS defines
> >> - Enable WDT
> >> - Add pinctrl properties
> >> - Add gpio support
> >> - Add led support
> >> - Add assorted AV bindings
> >> - Add compatible strings for ram
> >> - Use GPIO-based CS for MMC
> >> - Limit SPI flash to 50 MHz
> >>
> >> Changes in v4:
> >> - Set regs sizes to full address range
> >> - Remove clock-frequency property from cpus
> >> - Add spi-max-frequency to spi devices from documentation
> >> - Add more compatible strings for each device
> >> - Add AI ram as a separate memory bank. Its clock is disabled on boot, and
> >>   it cannot be accessed
> >> - Reorder memory banks so u-boot relocates higher, leaving more room to
> >>   load boot images
> >> - Add designware ssi CTRL0 field shifts to spi devices
> >> - Don't enable the MMC slot
> >> - Update copyright
> >> - Lint
> >>
> >> Changes in v3:
> >> - Move this patch to the end of the series
> >> - Add a max frequency for spi3
> >> - Remov unused compatible strings from spi-flash@0
> >> - Add s and u to isa string
> >> - Fix mmu-type
> >> - Remove cache-line size since it is unused (in u-boot) and undocumented
> >>   (upstream)
> >> - Add timer interrupts to clint0
> >> - Round up various registers
> >> - Add riscv,max-priority to plic
> >> - Add apb* busses, since they have clocks which need to be enabled to
> >>   access their devices
> >> - Change uart compatible strings to "snps,dw-apb-uart", since that appears
> >>   to match their registers
> >> - Add compatible string for wdt*
> >> - Add system reset device under sysctl
> >> - Add reset device under sysctl
> >>
> >> Changes in v2:
> >> - Model changed to "Sipeed Maix Bit" to match file name
> >> - Value of stdout-path fixed
> >> - SD card slot compatible changed to "mmc-spi-slot"
> >> - "jedec,spi-nor" added to spi flash compatible list
> >> - Aliases for spi busses added
> >> - timebase-frequency divided by 50 to match timer speed
> >> - cpu-frequency renamed to clock-frequency
> >> - CPUX_intc restyled to cpuX_intc
> >> - "kendryte,k210-soc" added to soc compatible list for future-proofing
> >> - PLIC handle renamed to plic0 from pic0
> >> - K210_RST_SOC removed from sysrst, due to not being located in the reset
> >>   register
> >> - K210_RST_* numbers changed to match their bit offset within the reset
> >>   register
> >> - gpio_controller restyled to gpio-controller
> >> - Added a second clock to the dma binding to match what the driver expects
> >> - Changed "snps,designware-spi" compatible string to "snps,dw-apb-ssi" to
> >>   match the correct driver
> >> - Added a name to the spi clocks
> >> - Added reg-io-width property to spi bindings
> >> - Assigned a default parent to K210_CLK_SPI3
> >> - Removed assigned clocks for ACLK and PLLs
> >> - Removed u-boot,dm-pre-reloc bindings
> >>
> >>  arch/riscv/dts/Makefile |   1 +
> >>  arch/riscv/dts/k210-maix-bit.dts|  47 ++
> >>  arch/riscv/dts/k210.dtsi| 599 
> >>  include/dt-bindings/reset/k210-sysctl.h |  38 ++
> >
> > It is not proper to mix them in one patch.
>
> The bindings and the device trees?

Sorry, there are three k210-sysctl.h and I confuse them.

+#include 
+#include 
+#include 

I thought it shall be put in [PATCH v6 07/19] clk: Add K210 clock support.

Please drop this suggestion.

Thanks,
Rick


>
> >
> > Thanks,
> > Rick
> >
>
> --Sean

Re: [PATCH v6 13/19] riscv: Fix race conditions when initializing IPI

[Rick Chen]

Hi Sean

> On 3/10/20 4:20 AM, Rick Chen wrote:
> > Hi Sean
> >
> >> The IPI code could have race conditions in several places.
> >> * Several harts could race on the value of gd->arch->clint/plic
> >> * Non-boot harts could race with the main hart on the DM subsystem In
> >>   addition, if an IPI was pending when U-Boot started, it would cause the
> >>   IPI handler to jump to address 0.
> >>
> >> To address these problems, a new function riscv_init_ipi is introduced. It
> >> is called once during arch_cpu_init_dm. Before this point, no riscv_*_ipi
> >> functions may be called. Access is synchronized by gd->arch->ipi_ready.
> >>
> >> Signed-off-by: Sean Anderson 
> >> ---
> >>
> >
> >> Can you try to clear mip/sip in startup flow before secondary_hart_loop:
> >> Maybe it can help to overcome the problem of calling riscv_clear_ipi()
> >> before riscv_init_ipi() that you added.
> >
> > How is the verified result about trying to clear mip/sip in startup flow ?
> > I have asked you twice in v5, but you still have no response about it.
> >
> > [PATCH v5 27/33] riscv: Fix race conditions when initializing IPI
> > https://patchwork.ozlabs.org/patch/1246864/#2377119
> >
> > Thanks
> > Rick
>
> I managed to get it working, and this patch incorporates that change.
> However, I forgot to update the commit message. The original issue I had
> was related to an accidental change to my config, and not to the
> clearing of MIP.

So it is not a race condition issue, right ?

Maybe you shall split this into two patchs as below

patch 1
riscv: Clear pending ipi in start code
Describe that it can how and what it help to fix the problem you
encounter more detail
e.g.
(Perhaps the prior stage sends an IPI but does not clear it) ...

patch 2
riscv: refine ipi initialize code flow
Describe that your motivation and intention more detail
e.g.
I think the macro approach is a bit confusing,
since it's unclear at first glance what function
will be initializing the clint/plic.
Given U-Boot's otherwise completely SMP-unsafe design,
I think it's better to be explicit and conservative in these areas.

It can help us to roll back and debug in the future.

Thanks,
Rick

>
> --Sean

Re: [PATCH v6 18/19] riscv: Add device tree for K210 and Sipeed Maix BitM

[Rick Chen]

Hi Sean

> Where possible, I have tried to find compatible drivers based on the layout
> of registers. However, many devices remain untested. All untested devices
> have been left disabled, but some tentative properties (such as compatible
> strings, and clocks, interrupts, and resets properties) have been added.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v6:
> - Remove spi, gpio, pinmux, wdt, and led bindings
> - Use consistent capitalization for hex digits
>
> Changes in v5:
> - Add more compatible strings
> - Add cache line size
> - Document CPUs as rocket cores
> - Flesh out the gpio devices
> - Add ports for audio and video devices
> - Add fpioa pinctrl support
> - Configure pins for MMC on SPI1
> - Enable MMC
> - Fix a couple uart properties (Thanks laanwj)
> - Reorder ram now that relocation is handled with CONFIG_SYS defines
> - Enable WDT
> - Add pinctrl properties
> - Add gpio support
> - Add led support
> - Add assorted AV bindings
> - Add compatible strings for ram
> - Use GPIO-based CS for MMC
> - Limit SPI flash to 50 MHz
>
> Changes in v4:
> - Set regs sizes to full address range
> - Remove clock-frequency property from cpus
> - Add spi-max-frequency to spi devices from documentation
> - Add more compatible strings for each device
> - Add AI ram as a separate memory bank. Its clock is disabled on boot, and
>   it cannot be accessed
> - Reorder memory banks so u-boot relocates higher, leaving more room to
>   load boot images
> - Add designware ssi CTRL0 field shifts to spi devices
> - Don't enable the MMC slot
> - Update copyright
> - Lint
>
> Changes in v3:
> - Move this patch to the end of the series
> - Add a max frequency for spi3
> - Remov unused compatible strings from spi-flash@0
> - Add s and u to isa string
> - Fix mmu-type
> - Remove cache-line size since it is unused (in u-boot) and undocumented
>   (upstream)
> - Add timer interrupts to clint0
> - Round up various registers
> - Add riscv,max-priority to plic
> - Add apb* busses, since they have clocks which need to be enabled to
>   access their devices
> - Change uart compatible strings to "snps,dw-apb-uart", since that appears
>   to match their registers
> - Add compatible string for wdt*
> - Add system reset device under sysctl
> - Add reset device under sysctl
>
> Changes in v2:
> - Model changed to "Sipeed Maix Bit" to match file name
> - Value of stdout-path fixed
> - SD card slot compatible changed to "mmc-spi-slot"
> - "jedec,spi-nor" added to spi flash compatible list
> - Aliases for spi busses added
> - timebase-frequency divided by 50 to match timer speed
> - cpu-frequency renamed to clock-frequency
> - CPUX_intc restyled to cpuX_intc
> - "kendryte,k210-soc" added to soc compatible list for future-proofing
> - PLIC handle renamed to plic0 from pic0
> - K210_RST_SOC removed from sysrst, due to not being located in the reset
>   register
> - K210_RST_* numbers changed to match their bit offset within the reset
>   register
> - gpio_controller restyled to gpio-controller
> - Added a second clock to the dma binding to match what the driver expects
> - Changed "snps,designware-spi" compatible string to "snps,dw-apb-ssi" to
>   match the correct driver
> - Added a name to the spi clocks
> - Added reg-io-width property to spi bindings
> - Assigned a default parent to K210_CLK_SPI3
> - Removed assigned clocks for ACLK and PLLs
> - Removed u-boot,dm-pre-reloc bindings
>
>  arch/riscv/dts/Makefile |   1 +
>  arch/riscv/dts/k210-maix-bit.dts|  47 ++
>  arch/riscv/dts/k210.dtsi| 599 
>  include/dt-bindings/reset/k210-sysctl.h |  38 ++

It is not proper to mix them in one patch.

Thanks,
Rick

>  4 files changed, 685 insertions(+)
>  create mode 100644 arch/riscv/dts/k210-maix-bit.dts
>  create mode 100644 arch/riscv/dts/k210.dtsi
>  create mode 100644 include/dt-bindings/reset/k210-sysctl.h
>
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index 4f30e6936f..3a6f96c67d 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -2,6 +2,7 @@
>
>  dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
>  dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
> +dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
>
>  targets += $(dtb-y)
>
> diff --git a/arch/riscv/dts/k210-maix-bit.dts 
> b/arch/riscv/dts/k210-maix-bit.dts
> new file mode 100644
> index 00..5b32c5fd5f
> --- /dev/null
> +++ b/arch/riscv/dts/k210-maix-bit.dts
> @@ -0,0 +1,47 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019-20 Sean Anderson 
> + */
> +
> +/dts-v1/;
> +
> +#include "k210.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "Sipeed Maix Bit 2.0";
> +   compatible = "sipeed,maix-bitm", "sipeed,maix-bit", "kendryte,k210";
> +
> +   chosen {
> +   stdout-path = "serial0:115200";
> +   };
> +
> +   sound {
> +   compatible = "simple-audio-card";
> +   

Re: [PATCH v6 19/19] riscv: Add Sipeed Maix support

[Rick Chen]

Hi Sean

> The Sipeed Maix series is a collection of boards built around the RISC-V
> Kendryte K210 processor. This processor contains several peripherals to
> accelerate neural network processing and other "ai" tasks. This includes a
> "KPU" neural network processor, an audio processor supporting beamforming
> reception, and a digital video port supporting capture and output at VGA
> resolution. Other peripherals include 8M of sram (accessible with and
> without caching); remappable pins, including 40 GPIOs; AES, FFT, and SHA256
> accelerators; a DMA controller; and I2C, I2S, and SPI controllers. Maix
> peripherals vary, but include spi flash; on-board usb-serial bridges; ports
> for cameras, displays, and sd cards; and ESP32 chips. Currently, only the
> Sipeed Maix Bit V2.0 (bitm) is supported, but the boards are fairly
> similar.
>
> Documentation for Maix boards is located at
> .  Documentation for the Kendryte K210 is
> located at . However, hardware details are
> rather lacking, so most technical reference has been taken from the
> standalone sdk located at
> .
>
> Signed-off-by: Sean Anderson 
> ---

This patch applying fail

Applying: riscv: Add Sipeed Maix support
error: patch failed: doc/board/index.rst:16
error: doc/board/index.rst: patch does not apply
Patch failed at 0001 riscv: Add Sipeed Maix support
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

I have replied to you the same result in v5
[v5,33/33] riscv: Add Sipeed Maix support
https://patchwork.ozlabs.org/patch/1246869/#2376311

By the way,
you can not mix them (arch, board, configs, doc)together in a patch.
arch/riscv/Kconfig
board/sipeed/maix/ ...
configs/sipeed_maix_bitm_defconfig
doc/board/index.rst

Thanks,
Rick

>
> Changes in v6:
> - Remove trailing whitespace from documentation
> - Remove configuration for spi/pinmux/gpio features
> - Flesh out documentation some more
>
> Changes in v5:
> - Configure relocation location with CONFIG_SYS_SDRAM_*
> - Enable ram clocks
> - Add pinmux/gpio/led support
> - Remove (broken) MMC support
> - Store the environment in flash
> - Add partitions
> - Add bootcmd
> - Add docs for pinctrl and booting
>
> Changes in v4:
> - Rework documentation to be organized by board mfg not cpu mfg
> - Update docs to reflect working SPI support
> - Add proper spi support
> - Don't define unneecessary macros in config.h
> - Lower the default stack so it isn't clobbered on relocation
> - Update MAINTAINERS
> - Update copyright
>
> Changes in v3:
> - Reorder to be last in the patch series
> - Add documentation for the board
> - Generate defconfig with "make savedefconfig"
> - Update Kconfig to imply most features we need
> - Update MAINTAINERS
>
> Changes in v2:
> - Select CONFIG_SYS_RISCV_NOCOUNTER
> - Imply CONFIG_CLK_K210
> - Remove spurious references to CONFIG_ARCH_K210
> - Remove many configs from defconfig where the defaults were fine
> - Add a few "not set" lines to suppress unneeded defaults
> - Reduce pre-reloc malloc space, now that clocks initialization happens
>   later
>
>  arch/riscv/Kconfig |   4 +
>  board/sipeed/maix/Kconfig  |  48 +
>  board/sipeed/maix/MAINTAINERS  |  11 ++
>  board/sipeed/maix/Makefile |   5 +
>  board/sipeed/maix/maix.c   |  54 ++
>  configs/sipeed_maix_bitm_defconfig |   8 +
>  doc/board/index.rst|   1 +
>  doc/board/sipeed/index.rst |   9 +
>  doc/board/sipeed/maix.rst  | 298 +
>  include/configs/sipeed-maix.h  |  24 +++
>  10 files changed, 462 insertions(+)
>  create mode 100644 board/sipeed/maix/Kconfig
>  create mode 100644 board/sipeed/maix/MAINTAINERS
>  create mode 100644 board/sipeed/maix/Makefile
>  create mode 100644 board/sipeed/maix/maix.c
>  create mode 100644 configs/sipeed_maix_bitm_defconfig
>  create mode 100644 doc/board/sipeed/index.rst
>  create mode 100644 doc/board/sipeed/maix.rst
>  create mode 100644 include/configs/sipeed-maix.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index b7a5757584..d016dd75d7 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT
>  config TARGET_SIFIVE_FU540
> bool "Support SiFive FU540 Board"
>
> +config TARGET_SIPEED_MAIX
> +   bool "Support Sipeed Maix Board"
> +
>  endchoice
>
>  config SYS_ICACHE_OFF
> @@ -53,6 +56,7 @@ source "board/AndesTech/ax25-ae350/Kconfig"
>  source "board/emulation/qemu-riscv/Kconfig"
>  source "board/microchip/mpfs_icicle/Kconfig"
>  source "board/sifive/fu540/Kconfig"
> +source "board/sipeed/maix/Kconfig"
>
>  # platform-specific options below
>  source "arch/riscv/cpu/a

Re: [PATCH v6 13/19] riscv: Fix race conditions when initializing IPI

[Rick Chen]

Hi Sean

> The IPI code could have race conditions in several places.
> * Several harts could race on the value of gd->arch->clint/plic
> * Non-boot harts could race with the main hart on the DM subsystem In
>   addition, if an IPI was pending when U-Boot started, it would cause the
>   IPI handler to jump to address 0.
>
> To address these problems, a new function riscv_init_ipi is introduced. It
> is called once during arch_cpu_init_dm. Before this point, no riscv_*_ipi
> functions may be called. Access is synchronized by gd->arch->ipi_ready.
>
> Signed-off-by: Sean Anderson 
> ---
>

> Can you try to clear mip/sip in startup flow before secondary_hart_loop:
> Maybe it can help to overcome the problem of calling riscv_clear_ipi()
> before riscv_init_ipi() that you added.

How is the verified result about trying to clear mip/sip in startup flow ?
I have asked you twice in v5, but you still have no response about it.

[PATCH v5 27/33] riscv: Fix race conditions when initializing IPI
https://patchwork.ozlabs.org/patch/1246864/#2377119

Thanks
Rick



> Changes in v6:
> - Fix some formatting
> - Clear IPIs before enabling interrupts instead of using a ipi_ready flag
> - Only print messages on error in smp code
>
> Changes in v5:
> - New
>
>  arch/riscv/cpu/cpu.c  |  6 
>  arch/riscv/cpu/start.S|  2 ++
>  arch/riscv/include/asm/smp.h  | 43 +++
>  arch/riscv/lib/andes_plic.c   | 34 -
>  arch/riscv/lib/sbi_ipi.c  |  5 
>  arch/riscv/lib/sifive_clint.c | 33 +++--
>  arch/riscv/lib/smp.c  | 56 ---
>  7 files changed, 92 insertions(+), 87 deletions(-)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index e457f6acbf..f851374255 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -96,6 +96,12 @@ int arch_cpu_init_dm(void)
> csr_write(CSR_SATP, 0);
> }
>
> +#ifdef CONFIG_SMP
> +   ret = riscv_init_ipi();
> +   if (ret)
> +   return ret;
> +#endif
> +
> return 0;
>  }
>
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 6b3ff99c38..e8740c8568 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -67,6 +67,8 @@ _start:
>  #else
> li  t0, SIE_SSIE
>  #endif
> +   /* Clear any pending IPIs */
> +   csrcMODE_PREFIX(ip), t0
> csrsMODE_PREFIX(ie), t0
>  #endif
>
> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> index 74de92ed13..1b428856b2 100644
> --- a/arch/riscv/include/asm/smp.h
> +++ b/arch/riscv/include/asm/smp.h
> @@ -51,4 +51,47 @@ void handle_ipi(ulong hart);
>   */
>  int smp_call_function(ulong addr, ulong arg0, ulong arg1, int wait);
>
> +/**
> + * riscv_init_ipi() - Initialize inter-process interrupt (IPI) driver
> + *
> + * Platform code must provide this function. This function is called once 
> after
> + * the cpu driver is initialized. No other riscv_*_ipi() calls will be made
> + * before this function is called.
> + *
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_init_ipi(void);
> +
> +/**
> + * riscv_send_ipi() - Send inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of receiving hart
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_send_ipi(int hart);
> +
> +/**
> + * riscv_clear_ipi() - Clear inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of hart to be cleared
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_clear_ipi(int hart);
> +
> +/**
> + * riscv_get_ipi() - Get status of inter-processor interrupt (IPI)
> + *
> + * Platform code must provide this function.
> + *
> + * @hart: Hart ID of hart to be checked
> + * @pending: Pointer to variable with result of the check,
> + *   1 if IPI is pending, 0 otherwise
> + * @return 0 if OK, -ve on error
> + */
> +int riscv_get_ipi(int hart, int *pending);
> +
>  #endif
> diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
> index 20529ab3eb..8484f76386 100644
> --- a/arch/riscv/lib/andes_plic.c
> +++ b/arch/riscv/lib/andes_plic.c
> @@ -30,20 +30,6 @@
>  #define SEND_IPI_TO_HART(hart)  (0x80 >> (hart))
>
>  DECLARE_GLOBAL_DATA_PTR;
> -static int init_plic(void);
> -
> -#define PLIC_BASE_GET(void)\
> -   do {\
> -   long *ret;  \
> -   \
> -   if (!gd->arch.plic) {   \
> -   ret = syscon_get_first_range(RISCV_SYSCON_PLIC); \
> -   if (IS_ERR(ret))\
> -   return PTR_ERR(ret);\
> -

Re: [PATCH v6 04/19] clk: Add functions to register CCF clock structs

[Rick Chen]

Hi Sean

> This patch adds alternate versions of the clk_*_register functions for use
> with statically-allocated struct clks. This allows drivers to define clocks
> at compile-time and register them at run-time without malloc-ing. This
> increases the size of the binary, but should not affect ram usage (since
> the clocks now no longer live on the heap).
>
> Signed-off-by: Sean Anderson 
> ---
>

This is a new patch since v5 and still lack of tag of MAINTAINERs.
I will prefer to exclude it in the later pull request of riscv tree.

Thanks,
Rick

> Changes in v5:
> - New
>
>  drivers/clk/clk-composite.c  | 103 +++
>  drivers/clk/clk-divider.c|  56 +--
>  drivers/clk/clk-gate.c   |  38 -
>  include/linux/clk-provider.h |   9 +++
>  4 files changed, 112 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index 819bfca2fc..b328c4e5a5 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -95,6 +95,51 @@ static int clk_composite_disable(struct clk *clk)
> return 0;
>  }
>
> +struct clk *clk_register_composite_struct(const char *name,
> + const char * const *parent_names,
> + int num_parents,
> + struct clk_composite *composite)
> +{
> +   int ret;
> +   struct clk *clk;
> +
> +   if (!num_parents || (num_parents != 1 && !composite->mux))
> +   return ERR_PTR(-EINVAL);
> +
> +   if (composite->mux && composite->mux_ops)
> +   composite->mux->data = (ulong)composite;
> +
> +   if (composite->rate && composite->rate_ops) {
> +   if (!composite->rate_ops->get_rate)
> +   return ERR_PTR(-EINVAL);
> +
> +   composite->rate->data = (ulong)composite;
> +   }
> +
> +   if (composite->gate && composite->gate_ops) {
> +   if (!composite->gate_ops->enable ||
> +   !composite->gate_ops->disable)
> +   return ERR_PTR(-EINVAL);
> +
> +   composite->gate->data = (ulong)composite;
> +   }
> +
> +   clk = &composite->clk;
> +   ret = clk_register(clk, UBOOT_DM_CLK_COMPOSITE, name,
> +  parent_names[clk_composite_get_parent(clk)]);
> +   if (ret)
> +   clk = ERR_PTR(ret);
> +
> +   if (composite->mux)
> +   composite->mux->dev = clk->dev;
> +   if (composite->rate)
> +   composite->rate->dev = clk->dev;
> +   if (composite->gate)
> +   composite->gate->dev = clk->dev;
> +
> +   return clk;
> +}
> +
>  struct clk *clk_register_composite(struct device *dev, const char *name,
>const char * const *parent_names,
>int num_parents, struct clk *mux,
> @@ -107,62 +152,24 @@ struct clk *clk_register_composite(struct device *dev, 
> const char *name,
>  {
> struct clk *clk;
> struct clk_composite *composite;
> -   int ret;
> -
> -   if (!num_parents || (num_parents != 1 && !mux))
> -   return ERR_PTR(-EINVAL);
>
> composite = kzalloc(sizeof(*composite), GFP_KERNEL);
> if (!composite)
> return ERR_PTR(-ENOMEM);
>
> -   if (mux && mux_ops) {
> -   composite->mux = mux;
> -   composite->mux_ops = mux_ops;
> -   mux->data = (ulong)composite;
> -   }
> +   composite->mux = mux;
> +   composite->mux_ops = mux_ops;
>
> -   if (rate && rate_ops) {
> -   if (!rate_ops->get_rate) {
> -   clk = ERR_PTR(-EINVAL);
> -   goto err;
> -   }
> +   composite->rate = rate;
> +   composite->rate_ops = rate_ops;
>
> -   composite->rate = rate;
> -   composite->rate_ops = rate_ops;
> -   rate->data = (ulong)composite;
> -   }
> +   composite->gate = gate;
> +   composite->gate_ops = gate_ops;
>
> -   if (gate && gate_ops) {
> -   if (!gate_ops->enable || !gate_ops->disable) {
> -   clk = ERR_PTR(-EINVAL);
> -   goto err;
> -   }
> -
> -   composite->gate = gate;
> -   composite->gate_ops = gate_ops;
> -   gate->data = (ulong)composite;
> -   }
> -
> -   clk = &composite->clk;
> -   ret = clk_register(clk, UBOOT_DM_CLK_COMPOSITE, name,
> -  parent_names[clk_composite_get_parent(clk)]);
> -   if (ret) {
> -   clk = ERR_PTR(ret);
> -   goto err;
> -   }
> -
> -   if (composite->mux)
> -   composite->mux->dev = clk->dev;
> -   if (composite->rate)
> -   composite->rate->dev = clk->dev;
> -   if (composite->gate)
>

Re: [PATCH v6 03/19] clk: Unconditionally recursively en-/dis-able clocks

[Rick Chen]

Hi Sean

> > For clocks not in the CCF, their parents will not have UCLASS_CLK, so we
> > just enable them as normal. The enable count is local to the struct clk,
> > but this will never result in the actual en-/dis-able op being called
> > (unless the same struct clk is enabled twice).
> >
> > For clocks in the CCF, we always traverse up the tree when enabling.
> > Previously, CCF clocks without id set would be skipped, stopping the
> > traversal too early.
> >
> > Signed-off-by: Sean Anderson 
> > Acked-by: Lukasz Majewski 
> > ---
> >
> > Changes in v5:
> > - Clear enable_count on request
> >
> > Changes in v4:
> > - Lint
> >
> > Changes in v3:
> > - New
> >
> >  drivers/clk/clk-uclass.c | 60 ++--
> >  1 file changed, 27 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > index d497737298..3b711395b8 100644
> > --- a/drivers/clk/clk-uclass.c
> > +++ b/drivers/clk/clk-uclass.c
> > @@ -410,6 +410,7 @@ int clk_request(struct udevice *dev, struct clk *clk)
> > ops = clk_dev_ops(dev);
> >
> > clk->dev = dev;
> > +   clk->enable_count = 0;
>
> Lukasz has taged Acked-by in v3.
> Re: [PATCH v3 03/12] clk: Unconditionally recursively en-/dis-able clocks
>
> This patch shall be fixed and freeze.
> But you add a new modification (Clear enable_count on request)in v5 and v6.
> Although it seem to look fine and nothing big deal.
> I just highlight it here, and if Lukasz have no other comment further.
> I will pull it via riscv tree later.
>

I have told you in v5, that this patch have conflict with
u-boot/master please rebase it.
But it still conflict in v6.

https://patchwork.ozlabs.org/patch/1246836/

Applying: clk: Always use the supplied struct clk
Applying: clk: Check that ops of composite clock components exist before calling
Applying: clk: Unconditionally recursively en-/dis-able clocks
error: patch failed: drivers/clk/clk-uclass.c:522
error: drivers/clk/clk-uclass.c: patch does not apply
Patch failed at 0003 clk: Unconditionally recursively en-/dis-able clocks
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


> Thanks,
> Rick
>
>
>
> >
> > if (!ops->request)
> > return 0;
> > @@ -522,7 +523,6 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
> >  int clk_enable(struct clk *clk)
> >  {
> > const struct clk_ops *ops;
> > -   struct clk *clkp = NULL;
> > int ret;
> >
> > debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
> > @@ -531,32 +531,29 @@ int clk_enable(struct clk *clk)
> > ops = clk_dev_ops(clk->dev);
> >
> > if (CONFIG_IS_ENABLED(CLK_CCF)) {
> > -   /* Take id 0 as a non-valid clk, such as dummy */
> > -   if (clk->id && !clk_get_by_id(clk->id, &clkp)) {
> > -   if (clkp->enable_count) {
> > -   clkp->enable_count++;
> > -   return 0;
> > -   }
> > -   if (clkp->dev->parent &&
> > -   device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
> > -   ret = 
> > clk_enable(dev_get_clk_ptr(clkp->dev->parent));
> > -   if (ret) {
> > -   printf("Enable %s failed\n",
> > -  clkp->dev->parent->name);
> > -   return ret;
> > -   }
> > +   if (clk->enable_count) {
> > +   clk->enable_count++;
> > +   return 0;
> > +   }
> > +   if (clk->dev->parent &&
> > +   device_get_uclass_id(clk->dev->parent) == UCLASS_CLK) {
> > +   ret = clk_enable(dev_get_clk_ptr(clk->dev->parent));
> > +   if (ret) {
> > +   printf("Enable %s failed\n",
> > +  clk->dev->parent->name);
> > +   return ret;
> > }
> > }
> >
> > if (ops->enable) {
> > ret = ops->enable(clk);
> > if (ret) {
> > -   printf("Enable %s failed\n", 
> > clk->dev->name);
> > +   printf("Enable %s failed (error %d)\n",
> > +  clk->dev->name, ret);
> > return ret;
> > }
> > }
> > -   if (clkp)
> > -   clkp->enable_count++;
> > +   clk->enable_count++;
> > } else {
> > 

Re: [PATCH 1/2] riscv: Fix sbi_remote_sfence_vma{,_asid}

[Rick Chen]

Hi Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Tuesday, March 10, 2020 9:54 AM
> To: Lukas Auer; Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
> Subject: Re: [PATCH 1/2] riscv: Fix sbi_remote_sfence_vma{,_asid}
>
> Hi Rick,
>
> On Fri, Mar 6, 2020 at 4:44 PM Bin Meng  wrote:
> >
> > Currently sbi_remote_sfence_vma{,_asid} does not pass their arguments
> > to SBI at all, which is semantically incorrect.
> >
> > This keeps in sync with Linux kernel commit:
> >   a21344dfc6ad: fix sbi_remote_sfence_vma{,_asid}
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/riscv/include/asm/sbi.h | 19 ---
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> >
>
> Ping?
>
> I think these 2 patches in this series should be in v2020.04

OK, no problem.
I will review and pull it later.

Thanks,
Rick

>
> Regards,
> Bin

Re: [PATCH v6 03/19] clk: Unconditionally recursively en-/dis-able clocks

[Rick Chen]

Hi Sean

> For clocks not in the CCF, their parents will not have UCLASS_CLK, so we
> just enable them as normal. The enable count is local to the struct clk,
> but this will never result in the actual en-/dis-able op being called
> (unless the same struct clk is enabled twice).
>
> For clocks in the CCF, we always traverse up the tree when enabling.
> Previously, CCF clocks without id set would be skipped, stopping the
> traversal too early.
>
> Signed-off-by: Sean Anderson 
> Acked-by: Lukasz Majewski 
> ---
>
> Changes in v5:
> - Clear enable_count on request
>
> Changes in v4:
> - Lint
>
> Changes in v3:
> - New
>
>  drivers/clk/clk-uclass.c | 60 ++--
>  1 file changed, 27 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index d497737298..3b711395b8 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -410,6 +410,7 @@ int clk_request(struct udevice *dev, struct clk *clk)
> ops = clk_dev_ops(dev);
>
> clk->dev = dev;
> +   clk->enable_count = 0;

Lukasz has taged Acked-by in v3.
Re: [PATCH v3 03/12] clk: Unconditionally recursively en-/dis-able clocks

This patch shall be fixed and freeze.
But you add a new modification (Clear enable_count on request)in v5 and v6.
Although it seem to look fine and nothing big deal.
I just highlight it here, and if Lukasz have no other comment further.
I will pull it via riscv tree later.

Thanks,
Rick



>
> if (!ops->request)
> return 0;
> @@ -522,7 +523,6 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>  int clk_enable(struct clk *clk)
>  {
> const struct clk_ops *ops;
> -   struct clk *clkp = NULL;
> int ret;
>
> debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
> @@ -531,32 +531,29 @@ int clk_enable(struct clk *clk)
> ops = clk_dev_ops(clk->dev);
>
> if (CONFIG_IS_ENABLED(CLK_CCF)) {
> -   /* Take id 0 as a non-valid clk, such as dummy */
> -   if (clk->id && !clk_get_by_id(clk->id, &clkp)) {
> -   if (clkp->enable_count) {
> -   clkp->enable_count++;
> -   return 0;
> -   }
> -   if (clkp->dev->parent &&
> -   device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
> -   ret = 
> clk_enable(dev_get_clk_ptr(clkp->dev->parent));
> -   if (ret) {
> -   printf("Enable %s failed\n",
> -  clkp->dev->parent->name);
> -   return ret;
> -   }
> +   if (clk->enable_count) {
> +   clk->enable_count++;
> +   return 0;
> +   }
> +   if (clk->dev->parent &&
> +   device_get_uclass_id(clk->dev->parent) == UCLASS_CLK) {
> +   ret = clk_enable(dev_get_clk_ptr(clk->dev->parent));
> +   if (ret) {
> +   printf("Enable %s failed\n",
> +  clk->dev->parent->name);
> +   return ret;
> }
> }
>
> if (ops->enable) {
> ret = ops->enable(clk);
> if (ret) {
> -   printf("Enable %s failed\n", clk->dev->name);
> +   printf("Enable %s failed (error %d)\n",
> +  clk->dev->name, ret);
> return ret;
> }
> }
> -   if (clkp)
> -   clkp->enable_count++;
> +   clk->enable_count++;
> } else {
> if (!ops->enable)
> return -ENOSYS;
> @@ -582,7 +579,6 @@ int clk_enable_bulk(struct clk_bulk *bulk)
>  int clk_disable(struct clk *clk)
>  {
> const struct clk_ops *ops;
> -   struct clk *clkp = NULL;
> int ret;
>
> debug("%s(clk=%p)\n", __func__, clk);
> @@ -591,29 +587,27 @@ int clk_disable(struct clk *clk)
> ops = clk_dev_ops(clk->dev);
>
> if (CONFIG_IS_ENABLED(CLK_CCF)) {
> -   if (clk->id && !clk_get_by_id(clk->id, &clkp)) {
> -   if (clkp->enable_count == 0) {
> -   printf("clk %s already disabled\n",
> -  clkp->dev->name);
> -   return 0;
> -   }
> -
> -   if (--clkp->enable_count > 0)
> -   return 0;
> +   if (clk->enable_count == 0) {
> +   printf("clk %s already disabled\n",
> +  

Re: [PATCH v5 27/33] riscv: Fix race conditions when initializing IPI

[Rick Chen]

Hi Sean

> Hi Sean
>
> > On Mon, 2020-03-02 at 10:43 -0500, Sean Anderson wrote:
> >
> > > On 3/2/20 4:08 AM, Rick Chen wrote:
> > > > Hi Sean
> > > >
> > > > > The IPI code could have race conditions in several places.
> > > > > * Several harts could race on the value of gd->arch->clint/plic
> > > > > * Non-boot harts could race with the main hart on the DM subsystem In
> > > > >   addition, if an IPI was pending when U-Boot started, it would cause 
> > > > > the
> > > > >   IPI handler to jump to address 0.
> > > > >
> > > > > To address these problems, a new function riscv_init_ipi is 
> > > > > introduced. It
> > > > > is called once during arch_cpu_init_dm. Before this point, no 
> > > > > riscv_*_ipi
> > > > > functions may be called. Access is synchronized by 
> > > > > gd->arch->ipi_ready.
> > > > >
> > > > > Signed-off-by: Sean Anderson 
> > > > > ---
> > > > >
> > > > > Changes in v5:
> > > > > - New
> > > > >
> > > > >  arch/riscv/cpu/cpu.c |  9 
> > > > >  arch/riscv/include/asm/global_data.h |  1 +
> > > > >  arch/riscv/include/asm/smp.h | 43 ++
> > > > >  arch/riscv/lib/andes_plic.c  | 34 +-
> > > > >  arch/riscv/lib/sbi_ipi.c |  5 ++
> > > > >  arch/riscv/lib/sifive_clint.c| 33 +-
> > > > >  arch/riscv/lib/smp.c | 68 
> > > > > 
> > > > >  7 files changed, 101 insertions(+), 92 deletions(-)
> > > > >
> > > > > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > > > > index e457f6acbf..a971ec8694 100644
> > > > > --- a/arch/riscv/cpu/cpu.c
> > > > > +++ b/arch/riscv/cpu/cpu.c
> > > > > @@ -96,6 +96,15 @@ int arch_cpu_init_dm(void)
> > > > > csr_write(CSR_SATP, 0);
> > > > > }
> > > > >
> > > > > +#ifdef CONFIG_SMP
> > > > > +   ret = riscv_init_ipi();
> > > > > +   if (ret)
> > > > > +   return ret;
> > > > > +
> > > > > +   /* Atomically set a flag enabling IPI handling */
> > > > > +   WRITE_ONCE(gd->arch.ipi_ready, 1);
> > > >
> > > > I think it shall not have race condition here.
> > > > Can you explain more detail why there will occur race condition ?
> > > >
> > > > Hi Lukas
> > > >
> > > > Do you have any comments ?
> > > >
> > > > Thanks
> > > > Rick
> > >
> > > On the K210, there may already be an IPI pending when U-Boot starts.
> > > (Perhaps the prior stage sends an IPI but does not clear it). As soon as
> > > interrupts are enabled, the hart then tries to call riscv_clear_ipi().
> > > Because the clint/plic has not yet been enabled, the clear_ipi function
> > > will try and bind/probe the device. This can have really nasty effects, 
> > > since
> > > the boot hart is *also* trying to bind/probe devices.
> > >
> > > In addition, a hart could end up trying to probe the clint/plic because
> > > it could receive the IPI before (from its perspective) gd->arch.clint
> > > (or plic) gets initialized.
> > >
> >
> > We did not have a problem with pending IPIs on other platforms. It
> > should suffice to clear SSIP / MSIP before enabling the interrupts.
> >
>
> Can you try to clear mip/sip in startup flow before secondary_hart_loop:
> Maybe it can help to overcome the problem of calling riscv_clear_ipi()
> before riscv_init_ipi() that you added.

How about the verified result ?
Is this can help to fix your problem without any modification (the
original flow)
Avoid unexpected condition can increase the robustness indeed.
But clarify the root cause more precisely is still necessary here.

Thanks,
Rick

>
> Thanks,
> Rick
>
> > > Aside from the above, I think the macro approach is a bit confusing,
> > > since it's unclear at first glance what function will be initializing
> > > the clint/plic. Given U-Boot's otherwise completely SMP-unsafe design, I
> > > think it's better to be explicit and conservative in these areas.
> > >
> >
> > I agree, the patch makes this more clear and helps make the code more
> > robust.
> >
> > Thanks,
> > Lukas