Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR

2022-01-24 Thread Rick Chen
> From: Anup Patel 
> Sent: Saturday, January 15, 2022 12:20 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Bin Meng 
> 
> Cc: Atish Patra ; Alistair Francis 
> ; Anup Patel ; U-Boot Mailing 
> List ; Anup Patel 
> Subject: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR
>
> Currently, if MTD NOR is enabled then U-Boot tries to issue flash commands 
> even when CFI flash DT node is not present. This causes access fault on 
> RISC-V emulators or ISS which do not emulate CFI flash. To handle this issue, 
> we implement is_flash_available() for qemu-riscv board which will return 1 
> only if CFI flash DT node is present.
>
> Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> Signed-off-by: Anup Patel 
> ---
>  board/emulation/qemu-riscv/qemu-riscv.c | 17 +++++
>  1 file changed, 17 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH 2/3] riscv: qemu: Enable HTIF console support

2022-01-24 Thread Rick Chen
> From: Anup Patel 
> Sent: Saturday, January 15, 2022 12:20 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Bin Meng 
> 
> Cc: Atish Patra ; Alistair Francis 
> ; Anup Patel ; U-Boot Mailing 
> List ; Anup Patel ; Philipp 
> Tomsich 
> Subject: [PATCH 2/3] riscv: qemu: Enable HTIF console support
>
> Enable support for HTIF console so that we can use QEMU RISC-V U-Boot on 
> RISC-V emulators and ISS having it.
>
> Signed-off-by: Anup Patel 
> Reviewed-by: Philipp Tomsich 
> ---
>  board/emulation/qemu-riscv/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rick Chen 


Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver

2022-01-24 Thread Rick Chen
> From: Anup Patel 
> Sent: Saturday, January 15, 2022 12:20 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Bin Meng 
> 
> Cc: Atish Patra ; Alistair Francis 
> ; Anup Patel ; U-Boot Mailing 
> List ; Anup Patel ; Philipp 
> Tomsich 
> Subject: [PATCH 1/3] serial: Add RISC-V HTIF console driver
>
> Quite a few RISC-V emulators and ISS (including Spike) have host transfer 
> interface (HTIF) based console. This patch adds HTIF based console driver for 
> RISC-V platforms which depends totally on DT node for HTIF register base 
> address.
>
> Signed-off-by: Anup Patel 
> Reviewed-by: Philipp Tomsich 
> ---
>  drivers/serial/Kconfig   |   8 ++
>  drivers/serial/Makefile  |   1 +
>  drivers/serial/serial_htif.c | 178 +++
>  3 files changed, 187 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH 1/1] board: ae350: Support autoboot from RAM

2021-11-03 Thread Rick Chen
> From: Leo Yu-Chi Liang(梁育齊) 
> Sent: Thursday, November 04, 2021 9:53 AM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Subject: [PATCH 1/1] board: ae350: Support autoboot from RAM
>
> Add boot command "bootcmd_ram" to support autoboot from RAM.
>
> This feature could be useful at the very initial state of chip design when 
> there is only a minimal set of peripheral. (e.g. without mmc and mac ..etc)
>
> The kernel image is default to be loaded at 0x200 via debug port, and the 
> following script serves as an example:
>
> spl()
> {
> cmd="riscv64-linux-gdb -q \
> -ex \"target remote $host:$port\" \
> -ex \"load\" \
> -ex \"thread apply all set \\\$pc=&_start\" \
> -ex \"thread apply all set \\\$a0=\\\$mhartid\" \
> -ex \"thread apply all set \\\$a1=\" \
> -ex \"restore u-boot.itb binary 0x20\" \
> -ex \"restore Image binary 0x200\" \
> -ex \"c\" \
> spl/u-boot-spl
> "
>
> echo $cmd
> eval $cmd
> }
>
> The address where the kernel is loaded can be altered by changing the value 
> of KERNEL_IMAGE_ADDR.
>
> Signed-off-by: Leo Yu-Chi Liang 
> ---
>  include/configs/ax25-ae350.h | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)

Reviewed-by: Rick Chen 


Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE

2021-11-03 Thread Rick Chen
> Hi Rick,
>
> On Mon, Oct 25, 2021 at 10:24 AM Rick Chen  wrote:
> >
> > Hi, Bin
> >
> > > Hi Rick,
> > >
> > > On Mon, Oct 25, 2021 at 9:49 AM Rick Chen  wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > > From: Bin Meng 
> > > > > Sent: Tuesday, October 19, 2021 4:55 PM
> > > > > To: Alexandre Ghiti 
> > > > > Cc: Heinrich Schuchardt ; Tom Rini 
> > > > > ; Leo Yu-Chi Liang(梁育齊) ; 
> > > > > Rick Jian-Zhi Chen(陳建志) ; Pragnesh Patel 
> > > > > ; Dimitri John Ledkov 
> > > > > ; Zong Li ; Green 
> > > > > Wan ; U-Boot Mailing List 
> > > > > Subject: Re: [PATCH 1/1] board: sifive: unmatched: enlarge 
> > > > > CONFIG_SYS_SPL_MALLOC_SIZE
> > > > >
> > > > > On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti 
> > > > >  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Fri, Oct 1, 2021 at 5:35 PM Bin Meng  wrote:
> > > > > > >
> > > > > > > Hi Heinrich,
> > > > > > >
> > > > > > > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Avoid an error like
> > > > > > > >
> > > > > > > > Could not get FIT buffer of 1725952 bytes
> > > > > > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > > > > > > No device tree specified in SPL image
> > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > >
> > > > > > > > Signed-off-by: Heinrich Schuchardt
> > > > > > > > 
> > > > > > > > ---
> > > > > > > >  include/configs/sifive-unmatched.h | 2 +-
> > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/include/configs/sifive-unmatched.h
> > > > > > > > b/include/configs/sifive-unmatched.h
> > > > > > > > index f8ad2cce1f..8d3deabdd3 100644
> > > > > > > > --- a/include/configs/sifive-unmatched.h
> > > > > > > > +++ b/include/configs/sifive-unmatched.h
> > > > > > > > @@ -18,7 +18,7 @@
> > > > > > > >  #define CONFIG_SPL_BSS_MAX_SIZE0x0010
> > > > > > > >  #define CONFIG_SYS_SPL_MALLOC_START
> > > > > > > > (CONFIG_SPL_BSS_START_ADDR + \
> > > > > > > >      
> > > > > > > > CONFIG_SPL_BSS_MAX_SIZE)
> > > > > > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
> > > > > > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0020
> > > > > > > >
> > > > > > > >  #define CONFIG_SPL_STACK   (0x0800 + 0x001D - \
> > > > > > > >  GENERATED_GBL_DATA_SIZE)
> > > > > > >
> > > > > > > What caused this?
> > > > > > >
> > > > > > > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN
> > > > > > > was increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the 
> > > > > > > error
> > > > > > > messages point to
> > > > > > >
> > > > > > > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html
> > > > > > >
> > > > > >
> > > > > > I fell into the same issue this morning and increasing
> > > > > > CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it 
> > > > > > even
> > > > > > more than Heinrich.
> > > > >
> > > > > Is this default build that caused Unmatched boot failure?
> > > > >
> > > > > @Rick Chen  can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was 
> > > > > needed on AE350?
> > > >
> > > > It is needed for limited memory cases on AE350 platforms.
> > >
> > > But the error message indicates that CONFIG_SYS_SPL_MALLOC_SIZE should
> > > be increased, which is what this patch doing.
> > >
> > > Why is CONFIG_SYS_SPL_MALLOC_SIZE not working on AE350?
> >
> > I review why I increase SPL_SYS_MALLOC_F_LEN and recall that it will
> > report memory size problem in spl_get_fit_load_buffer() of spl_fit.c.
> > But Increase CONFIG_SYS_SPL_MALLOC_SIZE is helpful for boards with
> > CONFIG_SYS_SPL_MALLOC_SIZE definition,
> > On Ae350 it is not define SYS_SPL_MALLOC_SIZE, so I increase
> > SPL_SYS_MALLOC_F_LEN instead.
> >
>
> Thanks. So this suggests we should fix the message in
> spl_get_fit_load_buffer() to provide different hints for different
> configurations?

Yes, maybe we can add #if CONFIG_VAL(SYS_MALLOC_F_LEN) to distinguish
CONFIG_SYS_SPL_MALLOC_SIZE and get better hints here.

Thanks,
Rick

>
> Regards,
> Bin


Re: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED

2021-10-31 Thread Rick Chen
> From: Leo Yu-Chi Liang(梁育齊) 
> Sent: Wednesday, October 27, 2021 4:59 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Cc: u-boot@lists.denx.de
> Subject: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED
>
> According to ./include/linux/kconfig.h,
> CONFIG_IS_ENABLED(OF_BOARD) expands to 0 when CONFIG_SPL_BUILD is defined 
> because there is no CONFIG_SPL_OF_BOARD.
>
> Use #if defined instead.
>
> Signed-off-by: Leo Yu-Chi Liang 
> ---
>  board/AndesTech/ax25-ae350/ax25-ae350.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 07/10] Convert CONFIG_OF_EMBED to Kconfig

2021-10-31 Thread Rick Chen
> From: U-Boot  On Behalf Of Tom Rini
> Sent: Sunday, October 31, 2021 11:04 AM
> To: u-boot@lists.denx.de
> Subject: [PATCH 07/10] Convert CONFIG_OF_EMBED to Kconfig
>
> This converts the following to Kconfig:
>CONFIG_OF_EMBED
>
> Signed-off-by: Tom Rini 
> ---
>  README| 7 ---
>  configs/adp-ae3xx_defconfig   | 1 +
>  configs/adp-ag101p_defconfig  | 1 +
>  include/configs/adp-ae3xx.h   | 1 -
>  include/configs/adp-ag101p.h  | 1 -
>  include/configs/cgtqmx8.h | 2 --
>  include/configs/imx8qm_mek.h  | 2 --
>  include/configs/imx8qxp_mek.h | 2 --
>  8 files changed, 2 insertions(+), 15 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 2/2] cmd: sbi: show SBI implementation version

2021-10-27 Thread Rick Chen
> From: Heinrich Schuchardt 
> Sent: Monday, October 25, 2021 9:10 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt 
> 
> Subject: [PATCH 2/2] cmd: sbi: show SBI implementation version
>
> Let the sbi command show the SBI implementation version
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/riscv/sbi.c | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 1/2] riscv: function to retrieve SBI implementation version

2021-10-27 Thread Rick Chen
> From: Heinrich Schuchardt 
> Sent: Monday, October 25, 2021 9:10 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt 
> 
> Subject: [PATCH 1/2] riscv: function to retrieve SBI implementation version
>
> Provide function sbi_get_impl_version() to retrieve the SBI implementation 
> version.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/include/asm/sbi.h |  1 +
>  arch/riscv/lib/sbi.c | 19 +++
>  2 files changed, 20 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE

2021-10-24 Thread Rick Chen
Hi, Bin

> Hi Rick,
>
> On Mon, Oct 25, 2021 at 9:49 AM Rick Chen  wrote:
> >
> > Hi Bin,
> >
> > > From: Bin Meng 
> > > Sent: Tuesday, October 19, 2021 4:55 PM
> > > To: Alexandre Ghiti 
> > > Cc: Heinrich Schuchardt ; Tom Rini 
> > > ; Leo Yu-Chi Liang(梁育齊) ; Rick 
> > > Jian-Zhi Chen(陳建志) ; Pragnesh Patel 
> > > ; Dimitri John Ledkov 
> > > ; Zong Li ; Green Wan 
> > > ; U-Boot Mailing List 
> > > Subject: Re: [PATCH 1/1] board: sifive: unmatched: enlarge 
> > > CONFIG_SYS_SPL_MALLOC_SIZE
> > >
> > > On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti 
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Fri, Oct 1, 2021 at 5:35 PM Bin Meng  wrote:
> > > > >
> > > > > Hi Heinrich,
> > > > >
> > > > > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt
> > > > >  wrote:
> > > > > >
> > > > > > Avoid an error like
> > > > > >
> > > > > > Could not get FIT buffer of 1725952 bytes
> > > > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > > > > No device tree specified in SPL image
> > > > > > ### ERROR ### Please RESET the board ###
> > > > > >
> > > > > > Signed-off-by: Heinrich Schuchardt
> > > > > > 
> > > > > > ---
> > > > > >  include/configs/sifive-unmatched.h | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/include/configs/sifive-unmatched.h
> > > > > > b/include/configs/sifive-unmatched.h
> > > > > > index f8ad2cce1f..8d3deabdd3 100644
> > > > > > --- a/include/configs/sifive-unmatched.h
> > > > > > +++ b/include/configs/sifive-unmatched.h
> > > > > > @@ -18,7 +18,7 @@
> > > > > >  #define CONFIG_SPL_BSS_MAX_SIZE0x0010
> > > > > >  #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR 
> > > > > > + \
> > > > > >  CONFIG_SPL_BSS_MAX_SIZE)
> > > > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
> > > > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00200000
> > > > > >
> > > > > >  #define CONFIG_SPL_STACK   (0x0800 + 0x001D - \
> > > > > >  GENERATED_GBL_DATA_SIZE)
> > > > >
> > > > > What caused this?
> > > > >
> > > > > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN
> > > > > was increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error
> > > > > messages point to
> > > > >
> > > > > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html
> > > > >
> > > >
> > > > I fell into the same issue this morning and increasing
> > > > CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it even
> > > > more than Heinrich.
> > >
> > > Is this default build that caused Unmatched boot failure?
> > >
> > > @Rick Chen  can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was needed 
> > > on AE350?
> >
> > It is needed for limited memory cases on AE350 platforms.
>
> But the error message indicates that CONFIG_SYS_SPL_MALLOC_SIZE should
> be increased, which is what this patch doing.
>
> Why is CONFIG_SYS_SPL_MALLOC_SIZE not working on AE350?

I review why I increase SPL_SYS_MALLOC_F_LEN and recall that it will
report memory size problem in spl_get_fit_load_buffer() of spl_fit.c.
But Increase CONFIG_SYS_SPL_MALLOC_SIZE is helpful for boards with
CONFIG_SYS_SPL_MALLOC_SIZE definition,
On Ae350 it is not define SYS_SPL_MALLOC_SIZE, so I increase
SPL_SYS_MALLOC_F_LEN instead.

Thanks,
Rick

>
> Regards,
> Bin


Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE

2021-10-24 Thread Rick Chen
Hi Bin,

> From: Bin Meng 
> Sent: Tuesday, October 19, 2021 4:55 PM
> To: Alexandre Ghiti 
> Cc: Heinrich Schuchardt ; Tom Rini 
> ; Leo Yu-Chi Liang(梁育齊) ; Rick 
> Jian-Zhi Chen(陳建志) ; Pragnesh Patel 
> ; Dimitri John Ledkov 
> ; Zong Li ; Green Wan 
> ; U-Boot Mailing List 
> Subject: Re: [PATCH 1/1] board: sifive: unmatched: enlarge 
> CONFIG_SYS_SPL_MALLOC_SIZE
>
> On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti 
>  wrote:
> >
> > Hi,
> >
> > On Fri, Oct 1, 2021 at 5:35 PM Bin Meng  wrote:
> > >
> > > Hi Heinrich,
> > >
> > > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt
> > >  wrote:
> > > >
> > > > Avoid an error like
> > > >
> > > > Could not get FIT buffer of 1725952 bytes
> > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > > No device tree specified in SPL image
> > > > ### ERROR ### Please RESET the board ###
> > > >
> > > > Signed-off-by: Heinrich Schuchardt
> > > > 
> > > > ---
> > > >  include/configs/sifive-unmatched.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/configs/sifive-unmatched.h
> > > > b/include/configs/sifive-unmatched.h
> > > > index f8ad2cce1f..8d3deabdd3 100644
> > > > --- a/include/configs/sifive-unmatched.h
> > > > +++ b/include/configs/sifive-unmatched.h
> > > > @@ -18,7 +18,7 @@
> > > >  #define CONFIG_SPL_BSS_MAX_SIZE0x0010
> > > >  #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SPL_BSS_START_ADDR + \
> > > >  CONFIG_SPL_BSS_MAX_SIZE)
> > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010
> > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0020
> > > >
> > > >  #define CONFIG_SPL_STACK   (0x0800 + 0x001D - \
> > > >  GENERATED_GBL_DATA_SIZE)
> > >
> > > What caused this?
> > >
> > > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN
> > > was increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error
> > > messages point to
> > >
> > > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html
> > >
> >
> > I fell into the same issue this morning and increasing
> > CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it even
> > more than Heinrich.
>
> Is this default build that caused Unmatched boot failure?
>
> @Rick Chen  can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was needed on 
> AE350?

It is needed for limited memory cases on AE350 platforms.

Thanks,
Rick

>
> Regards,
> Bin


Re: [PATCH 1/1] riscv: ae350: enable Coherence Manager for ae350

2021-09-23 Thread Rick Chen
> From: Leo Yu-Chi Liang(梁育齊) 
> Sent: Thursday, September 23, 2021 10:34 AM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Subject: [PATCH 1/1] riscv: ae350: enable Coherence Manager for ae350
>
> If Coherence Manager were not set in the beginning, u-boot-spl would 
> sometimes fail to boot to u-boot proper.
>
> Enable CM and I/D cache at the same time in harts_early_init
>
> Signed-off-by: Leo Yu-Chi Liang 
> ---
>  arch/riscv/cpu/ax25/cpu.c | 42 +++
>  1 file changed, 42 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH v2] board: sifive: Fix a potential build warning in board_fdt_blob_setup()

2021-09-17 Thread Rick Chen
> From: Bin Meng 
> Sent: Saturday, September 11, 2021 10:31 PM
> To: Zong Li ; Leo Yu-Chi Liang(梁育齊) 
> ; Rick Jian-Zhi Chen(陳建志) ; 
> u-boot@lists.denx.de
> Subject: [PATCH v2] board: sifive: Fix a potential build warning in 
> board_fdt_blob_setup()
>
> Commit 47d73ba4f4a4 ("board: sifive: overwrite board_fdt_blob_setup in u-boot 
> proper") added a board-specific implementation of board_fdt_blob_setup() 
> which takes a pointer as the return value, but it does not return anything if 
> CONFIG_OF_SEPARATE is not enabled. This will cause a build warning seen when 
> testing booting S-mode U-Boot directly from QEMU, per the instructions in [1]:
>
>   board/sifive/unleashed/unleashed.c: In function ‘board_fdt_blob_setup’:
>   board/sifive/unleashed/unleashed.c:125:1: warning: control reaches end of 
> non-void function [-Wreturn-type]
>
> Return &_end as the default case.
>
> [1] 
> https://qemu.readthedocs.io/en/latest/system/riscv/sifive_u.html#running-u-boot
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - Correct the commit title
>
>  board/sifive/unleashed/unleashed.c | 4 ++--  
> board/sifive/unmatched/unmatched.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH] riscv: Fix setting no-map in reserved memory nodes

2021-09-17 Thread Rick Chen
> From: Samuel Holland 
> Sent: Monday, September 13, 2021 12:06 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Cc: u-boot@lists.denx.de; Samuel Holland ; Atish Patra 
> ; Bin Meng ; Etienne Carriere 
> ; Sean Anderson ; Simon Glass 
> 
> Subject: [PATCH] riscv: Fix setting no-map in reserved memory nodes
>
> The no-map property is wrongly skipped if a no-map reserved memory node 
> follows one without that property. Fix this by not remembering the absence of 
> a no-map property across loop iterations.
>
> Fixes: d4ea649f179a ("riscv: Provide a mechanism to fix DT for reserved 
> memory")
> Signed-off-by: Samuel Holland 
> ---
>
>  arch/riscv/lib/fdt_fixup.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 09/14] lmb: riscv: Add arch_lmb_reserve()

2021-09-01 Thread Rick Chen
> From: Marek Vasut 
> Sent: Monday, August 16, 2021 2:13 AM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Atish Patra 
> ; Leo Yu-Chi Liang(梁育齊) ; Rick 
> Jian-Zhi Chen(陳建志) ; Simon Goldschmidt 
> ; Tom Rini 
> Subject: [PATCH 09/14] lmb: riscv: Add arch_lmb_reserve()
>
> Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
> It is rather likely this architecture also needs to cover U-Boot with LMB 
> before booting Linux.
>
> Signed-off-by: Marek Vasut 
> Cc: Atish Patra 
> Cc: Leo 
> Cc: Rick Chen 
> Cc: Simon Goldschmidt 
> Cc: Tom Rini 
> ---
>  arch/riscv/lib/bootm.c | 13 +++++
>  1 file changed, 13 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH 08/14] lmb: nds32: Add arch_lmb_reserve()

2021-09-01 Thread Rick Chen
> From: Marek Vasut 
> Sent: Monday, August 16, 2021 2:13 AM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Rick Jian-Zhi Chen(陳建志) 
> ; Simon Goldschmidt ; 
> Tom Rini 
> Subject: [PATCH 08/14] lmb: nds32: Add arch_lmb_reserve()
>
> Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
> It is rather likely this architecture also needs to cover U-Boot with LMB 
> before booting Linux.
>
> Signed-off-by: Marek Vasut 
> Cc: Rick Chen 
> Cc: Simon Goldschmidt 
> Cc: Tom Rini 
> ---
>  arch/nds32/lib/bootm.c | 13 +++++
>  1 file changed, 13 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH v5 2/5] common: board_r: support enable_caches for RISC-V

2021-09-01 Thread Rick Chen
> From: Zong Li 
> Sent: Wednesday, September 01, 2021 3:02 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v5 2/5] common: board_r: support enable_caches for RISC-V
>
> The enable_caches is a generic hook for architecture-implemented, we leverage 
> this function to enable caches for RISC-V
>
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/lib/cache.c | 4 
>  common/board_r.c   | 4 ++--
>  2 files changed, 6 insertions(+), 2 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH v5 5/5] riscv: lib: modify the indent

2021-09-01 Thread Rick Chen
> From: Zong Li 
> Sent: Wednesday, September 01, 2021 3:02 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v5 5/5] riscv: lib: modify the indent
>
> We usually use a space in function declaration, rather than a tab.
>
> Signed-off-by: Zong Li 
> Reviewed-by: Sean Anderson 
> ---
>  arch/riscv/include/asm/cache.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rick Chen 


Re: [PATCH v5 4/5] board: sifive: use ccache driver instead of helper function

2021-09-01 Thread Rick Chen
> From: Zong Li 
> Sent: Wednesday, September 01, 2021 3:02 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v5 4/5] board: sifive: use ccache driver instead of helper 
> function
>
> Invokes the common cache_init function to initialize ccache.
>
> Signed-off-by: Zong Li 
> Reviewed-by: Sean Anderson 
> ---
>  arch/riscv/cpu/fu540/Kconfig  |  2 +
>  arch/riscv/cpu/fu540/Makefile |  1 -
>  arch/riscv/cpu/fu540/cache.c  | 55 ---
>  arch/riscv/cpu/fu740/Kconfig  |  2 +
>  arch/riscv/cpu/fu740/Makefile |  1 -
>  arch/riscv/cpu/fu740/cache.c  | 55 ---
>  arch/riscv/include/asm/arch-fu540/cache.h | 14 --  
> arch/riscv/include/asm/arch-fu740/cache.h | 14 --
>  board/sifive/unleashed/unleashed.c| 10 +----
>  board/sifive/unmatched/unmatched.c| 11 ++---

Reviewed-by: Rick Chen 


Re: [PATCH v5 3/5] riscv: lib: implement enable_caches for sifive cache

2021-09-01 Thread Rick Chen
> From: Zong Li 
> Sent: Wednesday, September 01, 2021 3:02 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v5 3/5] riscv: lib: implement enable_caches for sifive cache
>
> The enable_caches is a generic hook for architecture-implemented, we define 
> this function to enable composable cache of sifive platforms.
>
> In sifive_cache, it invokes the generic cache_enable interface of cache 
> uclass to execute the relative implementation in SiFive ccache driver.
>
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/Kconfig|  5 +
>  arch/riscv/lib/Makefile   |  1 +
>  arch/riscv/lib/sifive_cache.c | 27 +++++++
>  3 files changed, 33 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH v4 2/4] riscv: lib: implement enable_caches for sifive cache

2021-08-31 Thread Rick Chen
> From: Zong Li 
> Sent: Tuesday, August 31, 2021 5:21 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v4 2/4] riscv: lib: implement enable_caches for sifive cache
>
> The enable_caches is a generic hook for architecture-implemented, we define 
> this function to enable composable cache of sifive platforms.
>
> In sifive_cache, it invokes the generic cache_enable interface of cache 
> uclass to execute the relative implementation in SiFive ccache driver.
>
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/Kconfig|  5 +
>  arch/riscv/lib/Makefile   |  1 +
>  arch/riscv/lib/sifive_cache.c | 27 +++
>  common/board_r.c  |  4 ++--
>  4 files changed, 35 insertions(+), 2 deletions(-)  create mode 100644 
> arch/riscv/lib/sifive_cache.c
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 
> 4b0c3dffa6..ec651fe0a4 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -179,6 +179,11 @@ config SPL_SIFIVE_CLINT
>   The SiFive CLINT block holds memory-mapped control and status 
> registers
>   associated with software and timer interrupts.
>
> +config SIFIVE_CACHE
> +   bool
> +   help
> + This enables the operations to configure SiFive cache
> +
>  config ANDES_PLIC
> bool
> depends on RISCV_MMODE || SPL_RISCV_MMODE diff --git 
> a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 
> c4cc41434b..06020fcc2a 100644
> --- a/arch/riscv/lib/Makefile
> +++ b/arch/riscv/lib/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
>  obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
>  obj-$(CONFIG_CMD_GO) += boot.o
>  obj-y  += cache.o
> +obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
>  ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
>  obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
>  obj-$(CONFIG_ANDES_PLIC) += andes_plic.o diff --git 
> a/arch/riscv/lib/sifive_cache.c b/arch/riscv/lib/sifive_cache.c new file mode 
> 100644 index 00..28154878fc
> --- /dev/null
> +++ b/arch/riscv/lib/sifive_cache.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021 SiFive, Inc
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void enable_caches(void)
> +{
> +   struct udevice *dev;
> +   int ret;
> +
> +   /* Enable ways of ccache */
> +   ret = uclass_get_device_by_driver(UCLASS_CACHE,
> + DM_DRIVER_GET(sifive_ccache),
> + );
> +   if (ret) {
> +   log_debug("Cannot enable cache ways");
> +   } else {
> +   ret = cache_enable(dev);
> +   if (ret)
> +   log_debug("ccache enable failed");
> +   }
> +}
> diff --git a/common/board_r.c b/common/board_r.c index e3e6248a1f..630c2451a2 
> 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -114,7 +114,7 @@ static int initr_reloc(void)
> return 0;
>  }
>
> -#ifdef CONFIG_ARM
> +#if defined(CONFIG_ARM) || defined(CONFIG_RISCV)

Here may cause other RISC-V platforms build error.
eq, ae350 will compile error as below:
common/board_r.o: in function `initr_caches':
/u-boot-riscv/common/board_r.c:124: undefined reference to `enable_caches'
Makefile:1795: recipe for target 'u-boot' failed

Maybe you can separate this part an isolate patch:
board_r: enable initr_caches for RISC-V ...
And also implement the week function for others.

Thanks,
Rick



>  /*
>   * Some of these functions are needed purely because the functions they
>   * call return void. If we change them to return 0, these stubs can go away.
> @@ -607,7 +607,7 @@ static init_fnc_t init_sequence_r[] = {
> initr_trace,
> initr_reloc,
> /* TODO: could x86/PPC have this also perhaps? */ -#ifdef CONFIG_ARM
> +#if defined(CONFIG_ARM) || defined(CONFIG_RISCV)
> initr_caches,
> /* Note: For Freescale LS2 SoCs, new MMU table is created in DDR.
>  *   A temporary mapping of IFC high region is since removed,
> --
> 2.32.0


Re: [PATCH v4 1/4] cache: add sifive composable cache driver

2021-08-31 Thread Rick Chen
> From: Zong Li 
> Sent: Tuesday, August 31, 2021 5:21 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; bmeng...@gmail.com; sean...@gmail.com; 
> green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; 
> u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH v4 1/4] cache: add sifive composable cache driver
>
> This driver is currently responsible for enabling all ccache ways.
> Composable cache could be configure as RAM or cache, we will use it as RAM at 
> the beginning to put the u-boot SPL there. In u-boot proper phrase, we will 
> use the composable cache as cache, and try to enable the cache ways.
>
> Signed-off-by: Zong Li 
> Reviewed-by: Sean Anderson 
> ---
>  drivers/cache/Kconfig   |  7 +++
>  drivers/cache/Makefile  |  1 +
>  drivers/cache/cache-sifive-ccache.c | 75 +
>  3 files changed, 83 insertions(+)
>  create mode 100644 drivers/cache/cache-sifive-ccache.c

Reviewed-by: Rick Chen 


Re: [PATCH] Convert CONFIG_SYS_MALLOC_LEN to Kconfig

2021-08-30 Thread Rick Chen
> From: U-Boot  On Behalf Of Tom Rini
> Sent: Sunday, August 29, 2021 9:35 AM
> To: u-boot@lists.denx.de
> Subject: [PATCH] Convert CONFIG_SYS_MALLOC_LEN to Kconfig
>
> This converts the following to Kconfig:
>CONFIG_SYS_MALLOC_LEN
>
> Signed-off-by: Tom Rini 
> ---

For riscv,

Reviewed-by: Rick Chen 


Re: [PATCH] Finish converting CONFIG_SYS_CACHELINE_SIZE to Kconfig

2021-08-29 Thread Rick Chen
> From: Tom Rini 
> Sent: Thursday, August 26, 2021 11:48 PM
> To: u-boot@lists.denx.de
> Cc: Alexey Brodkin ; Anup Patel 
> ; Atish Patra ; Bin Meng 
> ; Daniel Schwierzeck ; Leo 
> Yu-Chi Liang(梁育齊) ; Palmer Dabbelt 
> ; Paul Walmsley ; Rick Jian-Zhi 
> Chen(陳建志) ; Sean Anderson ; Simon 
> Glass 
> Subject: [PATCH] Finish converting CONFIG_SYS_CACHELINE_SIZE to Kconfig
>
> We move the SYS_CACHE_SHIFT_N options from arch/arm/Kconfig to arch/Kconfig, 
> and introduce SYS_CACHE_SHIFT_4 to provide a size of 16.
> Introduce select statements for other architectures based on current usage.  
> For MIPS, we take the existing arch-specific symbol and migrate to the 
> generic symbol.  This lets us remove a little bit of otherwise unused code.
>
> Cc: Alexey Brodkin 
> Cc: Anup Patel 
> Cc: Atish Patra 
> Cc: Bin Meng 
> Cc: Daniel Schwierzeck 
> Cc: Leo 
> Cc: Palmer Dabbelt 
> Cc: Paul Walmsley 
> Cc: Rick Chen 
> Cc: Sean Anderson 
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> ---
> I'm Cc'ing a bunch of RISC-V folks since that's where I'm least confident and 
> just put it per-board for now.
> ---
>  arch/Kconfig   | 25 +
>  arch/arc/include/asm/cache.h   |  3 ---
>  arch/arm/Kconfig   | 15 ---
>  arch/mips/Kconfig  | 26 +++---
>  arch/mips/include/asm/cache.h  | 12 +---
>  arch/mips/mach-bmips/Kconfig   | 20 ++--
>  arch/mips/mach-mtmips/Kconfig  |  4 ++--
>  arch/mips/mach-pic32/Kconfig   |  2 +-
>  arch/powerpc/cpu/mpc83xx/Kconfig   |  6 ++
>  arch/powerpc/cpu/mpc85xx/Kconfig   | 15 +++
>  arch/powerpc/cpu/mpc8xx/Kconfig|  2 ++
>  arch/powerpc/include/asm/cache.h   |  7 ---
>  arch/riscv/Kconfig |  2 ++

Reviewed-by: Rick Chen 


Re: [PATCH 3/3] Convert CONFIG_SYS_LOAD_ADDR to Kconfig

2021-08-25 Thread Rick Chen
> From: U-Boot  On Behalf Of Tom Rini
> Sent: Monday, August 23, 2021 10:26 PM
> To: u-boot@lists.denx.de
> Subject: [PATCH 3/3] Convert CONFIG_SYS_LOAD_ADDR to Kconfig
>
> Now that we have consistent usage, migrate this symbol to Kconfig.
>
> Signed-off-by: Tom Rini 
> ---
>  Kconfig| 14 ++

>  configs/adp-ae3xx_defconfig|  1 +
>  configs/adp-ag101p_defconfig   |  1 +
>  configs/ae350_rv32_defconfig   |  1 +
>  configs/ae350_rv32_spl_defconfig   |  1 +
>  configs/ae350_rv32_spl_xip_defconfig   |  1 +
>  configs/ae350_rv32_xip_defconfig   |  1 +
>  configs/ae350_rv64_defconfig   |  1 +
>  configs/ae350_rv64_spl_defconfig   |  1 +
>  configs/ae350_rv64_spl_xip_defconfig   |  1 +
>  configs/ae350_rv64_xip_defconfig   |  1 +

Reviewed-by: Rick Chen 


Re: [PATCH 05/12] mmc: nds32: ftsdc010: Convert to livetree

2021-08-08 Thread Rick Chen
> From: U-Boot  On Behalf Of Simon Glass
> Sent: Saturday, August 07, 2021 9:24 PM
> To: U-Boot Mailing List 
> Cc: Tom Rini ; Simon Glass ; Jaehoon 
> Chung ; Macpaul Lin ; Peng Fan 
> 
> Subject: [PATCH 05/12] mmc: nds32: ftsdc010: Convert to livetree
>
> Use the livetree API for this driver.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/mmc/ftsdc010_mci.c | 22 +++---
>  1 file changed, 7 insertions(+), 15 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH] riscv: cpu: fu740: Fix typo of date

2021-08-02 Thread Rick Chen
> From: U-Boot  On Behalf Of Zong Li
> Sent: Monday, August 02, 2021 3:34 PM
> To: u-boot@lists.denx.de
> Cc: Zong Li 
> Subject: [PATCH] riscv: cpu: fu740: Fix typo of date
>
> Fixed the typo of date of copyright declaration.
>
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/cpu/fu740/spl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rick Chen 


Re: [PATCH 4/5] riscv: ae350: dts: Fix #interrupt-cells for plic0 in 32-bit

2021-06-14 Thread Rick Chen
> From: Bin Meng 
> Sent: Friday, June 04, 2021 1:51 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; U-Boot Mailing List 
> Subject: [PATCH 4/5] riscv: ae350: dts: Fix #interrupt-cells for plic0 in 
> 32-bit
>
> All the device nodes that refer to plic0 as their interrupt parent have 2 
> cells encoded in their interrupts property, but plic0 only provides 1 cell in 
> #interrupt-cells which is incorrect.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/dts/ae350_32.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rick Chen 


Re: [PATCH 3/5] riscv: ae350: dts: Remove the unnecessary #address-cells in plic nodes

2021-06-14 Thread Rick Chen
> From: Bin Meng 
> Sent: Friday, June 04, 2021 1:51 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; U-Boot Mailing List 
> Subject: [PATCH 3/5] riscv: ae350: dts: Remove the unnecessary #address-cells 
> in plic nodes
>
> PLIC nodes don't have child nodes, so #address-cells is not needed.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/dts/ae350_32.dts | 2 --
>  arch/riscv/dts/ae350_64.dts | 2 --
>  2 files changed, 4 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 1/5] riscv: ae350: dts: Add SPDX license header

2021-06-14 Thread Rick Chen
> From: Bin Meng 
> Sent: Friday, June 04, 2021 1:51 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; U-Boot Mailing List 
> Subject: [PATCH 1/5] riscv: ae350: dts: Add SPDX license header
>
> The SPDX license header is currently missing. Add one.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/dts/ae350_32.dts | 2 ++
>  arch/riscv/dts/ae350_64.dts | 2 ++
>  2 files changed, 4 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" for SPL config

2021-06-14 Thread Rick Chen
> Hi Rick,
>
> On Sat, Jun 12, 2021 at 9:30 PM Rick Chen  wrote:
> >
> > HI Bin
> >
> > > Hi Rick,
> > >
> > > On Wed, Jun 9, 2021 at 3:06 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > > From: Bin Meng 
> > > > > Sent: Friday, June 04, 2021 1:51 PM
> > > > > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi 
> > > > > Liang(梁育齊) ; U-Boot Mailing List 
> > > > > 
> > > > > Subject: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" 
> > > > > for SPL config
> > > > >
> > > > > At present the AE350 SPL defconfig is using OF_PRIOR_STAGE. The 
> > > > > intention was to use gdb to load device tree before running U-Boot 
> > > > > SPL/proper from RAM. When we switch to OF_SEPARATE we will have to 
> > > > > use our own DT but without "u-boot,dm-spl" in several essential 
> > > > > nodes, SPL does not boot.
> > > >
> > > > Can you describe how do you verify and provide the steps about that
> > > > SPL boot fail that I can duplicate it. :)
> > >
> > > $ make ae350_rv64_spl_defconfig; make -j
> > > $ make menuconfig (change OF_PRIOR_STAGE to OF_EMBED or OF_SEPARATE)
> > >
> > > Load u-boot.bin to RAM
> >
> > It can boot with OF_EMBED.
> > But it compile fail with choosing OF_EMBED at the first time, fail
> > messages as below:
> >
> > binman: [Errno 2] No such file or directory: 'u-boot.dtb'
> > Makefile:1084: recipe for target 'all' failed
> > make: *** [all] Error 1
>
> Yes, this is a known issue of the binman conversion for SPL. OF_EMBED
> is a debugging purpose hence I am inclined to leave it as is.

Reviewed-by: Rick Chen 

>
> Regards,
> Bin


Re: [RFT PATCH] riscv: andes_plic: Fix riscv_get_ipi() mask

2021-06-14 Thread Rick Chen
Hi Bin

> From: Bin Meng 
> Sent: Monday, June 14, 2021 11:48 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; U-Boot Mailing List 
> Subject: Re: [RFT PATCH] riscv: andes_plic: Fix riscv_get_ipi() mask
>
> On Wed, Jun 9, 2021 at 3:55 PM Bin Meng  wrote:
> >
> > Current logic in riscv_get_ipi() for Andes PLICSW does not look good
> > to me. The mask to test IPI pending bits for a hart should be left
> > shifted by (8 * gd->arch.boot_hart), just the same as what is done in
> > riscv_send_ipi().
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> > It looks there is no datasheet released from Andes that describes how
> > PLICSW works, and its register fields. I can only get an understanding
> > from current U-Boot and OpenSBI PLICSW driver.
> >
> > This requires testing on Andes hardware, which I don't have access to.
> >
> >  arch/riscv/lib/andes_plic.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
>
> Ping?


Though there will be only one hart will jump to U-Boot proper currently,
and this delay loop seem to be unnecessary.
But it is still a good catch.

Thanks,
Rick

Tested-by: Rick Chen 
Reviewed-by: Rick Chen 


Re: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" for SPL config

2021-06-12 Thread Rick Chen
HI Bin

> Hi Rick,
>
> On Wed, Jun 9, 2021 at 3:06 PM Rick Chen  wrote:
> >
> > Hi Bin,
> >
> > > From: Bin Meng 
> > > Sent: Friday, June 04, 2021 1:51 PM
> > > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> > > ; U-Boot Mailing List 
> > > Subject: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" for 
> > > SPL config
> > >
> > > At present the AE350 SPL defconfig is using OF_PRIOR_STAGE. The intention 
> > > was to use gdb to load device tree before running U-Boot SPL/proper from 
> > > RAM. When we switch to OF_SEPARATE we will have to use our own DT but 
> > > without "u-boot,dm-spl" in several essential nodes, SPL does not boot.
> >
> > Can you describe how do you verify and provide the steps about that
> > SPL boot fail that I can duplicate it. :)
>
> $ make ae350_rv64_spl_defconfig; make -j
> $ make menuconfig (change OF_PRIOR_STAGE to OF_EMBED or OF_SEPARATE)
>
> Load u-boot.bin to RAM

It can boot with OF_EMBED.
But it compile fail with choosing OF_EMBED at the first time, fail
messages as below:

binman: [Errno 2] No such file or directory: 'u-boot.dtb'
Makefile:1084: recipe for target 'all' failed
make: *** [all] Error 1

Thanks,
Rick

>
> Regards,
> Bin


Re: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" for SPL config

2021-06-09 Thread Rick Chen
Hi Bin,

> From: Bin Meng 
> Sent: Friday, June 04, 2021 1:51 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; U-Boot Mailing List 
> Subject: [PATCH 5/5] riscv: ae350: dts: Add missing "u-boot,dm-spl" for SPL 
> config
>
> At present the AE350 SPL defconfig is using OF_PRIOR_STAGE. The intention was 
> to use gdb to load device tree before running U-Boot SPL/proper from RAM. 
> When we switch to OF_SEPARATE we will have to use our own DT but without 
> "u-boot,dm-spl" in several essential nodes, SPL does not boot.

Can you describe how do you verify and provide the steps about that
SPL boot fail that I can duplicate it. :)

Thanks,
Rick.

>
> Let's add all the required "u-boot,dm-spl" for SPL config.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/dts/ae350-u-boot.dtsi | 52 
>  arch/riscv/dts/ae350_32.dts  |  1 +
>  arch/riscv/dts/ae350_64.dts  |  1 +
>  3 files changed, 54 insertions(+)
>  create mode 100644 arch/riscv/dts/ae350-u-boot.dtsi
>
> diff --git a/arch/riscv/dts/ae350-u-boot.dtsi 
> b/arch/riscv/dts/ae350-u-boot.dtsi
> new file mode 100644
> index 00..0d4201cfae
> --- /dev/null
> +++ b/arch/riscv/dts/ae350-u-boot.dtsi
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +
> +/ {
> +   cpus {
> +   u-boot,dm-spl;
> +   CPU0: cpu@0 {
> +   u-boot,dm-spl;
> +   CPU0_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   CPU1: cpu@1 {
> +   u-boot,dm-spl;
> +   CPU1_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   CPU2: cpu@2 {
> +   u-boot,dm-spl;
> +   CPU2_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   CPU3: cpu@3 {
> +   u-boot,dm-spl;
> +   CPU3_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   };
> +
> +   memory@0 {
> +   u-boot,dm-spl;
> +   };
> +
> +   soc {
> +   u-boot,dm-spl;
> +
> +   plic1: interrupt-controller@e640 {
> +   u-boot,dm-spl;
> +   };
> +
> +   plmt0@e600 {
> +   u-boot,dm-spl;
> +   };
> +   };
> +
> +   serial0: serial@f030 {
> +   u-boot,dm-spl;
> +   };
> +
> +};
> diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts index 
> 70576846f2..083f676333 100644
> --- a/arch/riscv/dts/ae350_32.dts
> +++ b/arch/riscv/dts/ae350_32.dts
> @@ -3,6 +3,7 @@
>  /dts-v1/;
>
>  #include "binman.dtsi"
> +#include "ae350-u-boot.dtsi"
>
>  / {
> #address-cells = <1>;
> diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts index 
> 564e94a1db..74cff9122d 100644
> --- a/arch/riscv/dts/ae350_64.dts
> +++ b/arch/riscv/dts/ae350_64.dts
> @@ -3,6 +3,7 @@
>  /dts-v1/;
>
>  #include "binman.dtsi"
> +#include "ae350-u-boot.dtsi"
>
>  / {
> #address-cells = <2>;
> --
> 2.25.1
>
> 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 2/5] riscv: ae350: dts: Remove the unnecessary space in bootargs

2021-06-09 Thread Rick Chen
> From: Bin Meng 
> Sent: Friday, June 04, 2021 1:51 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; U-Boot Mailing List 
> Subject: [PATCH 2/5] riscv: ae350: dts: Remove the unnecessary space in 
> bootargs
>
> There are two spaces before "debug' in bootargs. Drop one.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/dts/ae350_32.dts | 2 +-
>  arch/riscv/dts/ae350_64.dts | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH] riscv: ae350: doc: Remove CONFIG_SKIP_LOWLEVEL_INIT

2021-06-06 Thread Rick Chen
> From: Bin Meng 
> Sent: Saturday, June 05, 2021 7:01 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; u-boot@lists.denx.de
> Cc: Bin Meng 
> Subject: [PATCH] riscv: ae350: doc: Remove CONFIG_SKIP_LOWLEVEL_INIT
>
> The doc says CONFIG_SKIP_LOWLEVEL_INIT is in ax25-ae350.h, while actually it 
> is not. Remove it.
>
> Signed-off-by: Bin Meng 
> ---
>
>  doc/board/AndesTech/ax25-ae350.rst | 19 ---
>  1 file changed, 4 insertions(+), 15 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH v2 1/1] sandbox: don't refer to symbol _init

2021-05-19 Thread Rick Chen
> From: U-Boot  On Behalf Of Heinrich Schuchardt
> Sent: Wednesday, May 19, 2021 6:03 PM
> To: Simon Glass 
> Cc: Ovidiu Panait ; Bin Meng 
> ; Stefan Roese ; Masahiro Yamada 
> ; u-boot@lists.denx.de; Heinrich Schuchardt 
> 
> Subject: [PATCH v2 1/1] sandbox: don't refer to symbol _init
>
> GCC provides a symbol _init in crti.o on x86_64 and aarch64 but not on 
> RISC-V. The following lines leads to a build error for sandbox_defconfig on 
> RISC-V due to the missing symbol:
>
> common/board_f.c:269:
> #elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP)
> gd->mon_len = (ulong)&_end - (ulong)_init;
>
> The sandbox code is not copied into the memory allocated using mmap().
> Hence we can safely use gd->mon_len = 0 to avoid the reference to _init.
>
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Bin Meng 
> ---
> v2:
> fix typo in commit message
> ---
>  common/board_f.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Reviewed-by: Rick Chen 


Re: [PATCH] riscv: Split SiFive CLINT support between SPL and U-Boot proper

2021-05-17 Thread Rick Chen
> From: Bin Meng 
> Sent: Tuesday, May 11, 2021 8:04 PM
> To: Rick Jian-Zhi Chen(陳建志) ; Sean Anderson 
> ; u-boot@lists.denx.de
> Cc: Anup Patel ; Bin Meng 
> Subject: [PATCH] riscv: Split SiFive CLINT support between SPL and U-Boot 
> proper
>
> At present there is only one Kconfig option CONFIG_SIFIVE_CLINT to control 
> the enabling of SiFive CLINT support in both SPL (M-mode) and U-Boot proper 
> (S-mode). So for a typical SPL config that the SiFive CLINT driver is enabled 
> in both SPL and U-Boot proper, that means the S-mode U-Boot tries to access 
> the memory-mapped CLINT registers directly, instead of the normal 'rdtime' 
> instruction.
>
> This was not a problem before, as the hardware does not forbid the access 
> from S-mode. However this becomes an issue now with OpenSBI commit 
> 8b569803475e ("lib: utils/sys: Add CLINT memregion in the root domain") that 
> the SiFive CLINT register space is protected by PMP for M-mode access only. 
> U-Boot proper does not boot any more with the latest OpenSBI, that access 
> exceptions are fired forever from U-Boot when trying to read the timer value 
> via the SiFive CLINT driver in U-Boot.
>
> To solve this, we need to split current SiFive CLINT support between SPL and 
> U-Boot proper, using 2 separate Kconfig options.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/riscv/Kconfig   | 9 -
>  arch/riscv/cpu/fu540/Kconfig | 2 +-
>  arch/riscv/cpu/generic/Kconfig   | 3 ++-
>  arch/riscv/include/asm/global_data.h | 2 +-
>  arch/riscv/lib/Makefile  | 2 +-
>  drivers/timer/Makefile   | 2 +-
>  6 files changed, 14 insertions(+), 6 deletions(-)

Reviewed-by: Rick Chen 


Re: FW: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb

2021-05-17 Thread Rick Chen
Hi Bin

> Hi Rick,
>
> On Wed, May 12, 2021 at 11:25 AM Rick Chen  wrote:
> >
> > HI Bin,
> >
> > >
> > > > Hi Rick,
> > > >
> > > > On Tue, May 11, 2021 at 8:49 AM Rick Chen  wrote:
> > > > >
> > > > > Hi Bin,
> > > > >
> > > > > > Hi Rick,
> > > > > >
> > > > > > On Mon, May 10, 2021 at 3:22 PM Rick Chen  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Bin
> > > > > > >
> > > > > > > > Hi Bin,
> > > > > > > >
> > > > > > > > > From: Bin Meng 
> > > > > > > > > Sent: Monday, May 10, 2021 2:58 PM
> > > > > > > > > To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> > > > > > > > > ; u-boot@lists.denx.de
> > > > > > > > > Subject: [PATCH v4 00/13] riscv: Switch to use binman to 
> > > > > > > > > generate u-boot.itb
> > > > > > > > >
> > > > > > > > > This series updates binman to handle creation of u-boot.itb 
> > > > > > > > > image for RISC-V boards.
> > > > > > > > >
> > > > > > > > > Azure results: PASS
> > > > > > > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=363=results
> > > > > > > > >
> > > > > > > > > The following tests were performed:
> > > > > > > > > * booting qemu-riscv{32|64}_spl_defconfig on QEMU virt
> > > > > > > > > * booting sifive_unleashed_defconfig on QEMU sifive_u
> > > > > > > > >
> > > > > > > > > AE350 SPL defconfigs are not tested. @Rick, could you please 
> > > > > > > > > test and report?
> > > > > > > >
> > > > > > > > OK. I will verify it on AE350.
> > > > > > >
> > > > > > > It fail as below messages:
> > > > > > >
> > > > > > > U-Boot SPL 2021.07-rc1-00218-g468b3b3 (May 10 2021 - 15:13:03 
> > > > > > > +0800)
> > > > > > > Trying to boot from RAM
> > > > > > > alloc space exhausted
> > > > > >
> > > > > > Looks it is running out of memory.
> > > > > >
> > > > > > > Could not get FIT buffer of 499076 bytes
> > > > > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > > > >
> > > > > > Could you please try increasing CONFIG_SYS_SPL_MALLOC_SIZE?
> > > > >
> > > > > I increased CONFIG_SYS_SPL_MALLOC_SIZE, but it is useless.
> > > > > But it boots successfully after increase CONFIG_SPL_SYS_MALLOC_F_LEN 
> > > > > larger.
> > > >
> > > > Thanks for testing. I am not sure why AE350 fails to boot because this
> > > > series only changes the way to assemble the bits.
> > > >
> > > > Could you please confirm if without this patch series, AE350 can boot?
> > >
> > > OK.
> >
> > 
> > I have verified AE350 without your patch, it works as below:
> > 
> > U-Boot SPL 2021.07-rc1-00194-g07b5310 (May 12 2021 - 10:59:48 +0800)
> > Trying to boot from RAM
> >
> > U-Boot 2021.07-rc1-00194-g07b5310 (May 12 2021 - 10:59:48 +0800)
> >
> > DRAM:  1 GiB
> > Flash: 64 MiB
> > MMC:   mmc@f0e0: 0
> > Loading Environment from SPIFlash... SF: Detected mx25u1635e with page
> > size 256 Bytes, erase size 4 KiB, total 2 MiB
> > OK
> > In:serial@f030
> > Out:   serial@f030
> > Err:   serial@f030
> > Net:   no alias for ethernet0
> >
> > Warning: mac@e010 (eth0) using random MAC address - 26:00:fa:12:76:ad
> > eth0: mac@e010
> > Hit any key to stop autoboot:  0
> > RISC-V #
> >
> > =
> > With your patch, it fail as below:
> > =
> >
> > U-Boot SPL 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:09:11 +0800)
> > Trying to boot from RAM
> > alloc space exhausted
> > Could not get FIT buffer of 499076 bytes
> > check CONFIG_SYS_SPL_MALLOC_SIZE
> > No device tree specified in SPL image
> >
> > ===
> > After increase CONFIG_SPL_SYS_MALLOC_F_LEN, it works as below
> > ===
> > U-Boot SPL 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:11:00 +0800)
> > Trying to boot from RAM
> >
> >
> > U-Boot 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:11:00 +0800)
> >
> > DRAM:  1 GiB
> > Flash: 64 MiB
> > MMC:   mmc@f0e0: 0
> > Loading Environment from SPIFlash... SF: Detected mx25u1635e with page
> > size 256 Bytes, erase size 4 KiB, total 2 MiB
> > OK
> > In:serial@f030
> > Out:   serial@f030
> > Err:   serial@f030
> > Net:   no alias for ethernet0
> >
> > Warning: mac@e010 (eth0) using random MAC address - e6:58:7e:7c:5f:49
> > eth0: mac@e010
> > Hit any key to stop autoboot:  0
> > RISC-V #
> >
> >
> > I found that it need larger heap size when spl try to get fit image
> > with using binman to generate u-boot.itb instead of
> > USE_SPL_FIT_GENERATOR.
> > But it is OK. I will send a patch for AE350 later.
>
> A patch for AE350 to increase CONFIG_SPL_SYS_MALLOC_F_LEN needs to be
> applied before this series.
>
> Would you please send the AE350 patch, and get this series applied?

OK, I will send the AE350 patch later.

Thanks,
Rick

>
> Regards,
> Bin


Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"

2021-05-13 Thread Rick Chen
> From: Bin Meng 
> Sent: Friday, May 14, 2021 11:50 AM
> To: Green Wan 
> Cc: Rick Jian-Zhi Chen(陳建志) ; Sean Anderson 
> ; U-Boot Mailing List 
> Subject: Re: [PATCH] Revert "riscv: cpu: fu740: clear feature disable CSR"
>
> On Fri, May 14, 2021 at 11:45 AM Green Wan  wrote:
> >
> > Hi Bin,
> >
> > Thanks, I'll include that revert. Just traced back the git log. My original 
> > patch is based on fu740. I guess it was merged to fu540 since fu740 series 
> > wasn't present yet.
> >
> > Hi Rick,
> >
> > Not sure whether you'll pick fu740 series soon or if any parts need more 
> > revisement. Do you prefer that I append both this revert and "disable CSR" 
> > patch to fu740 patch series? If so, I will create v9 patch and 
> > include these 2 patches.
> >
> > Or if you prefer to keep them separate from fu740 series, we can wait for 
> > fu740 patch merge and I'll create a separate patch for this revert 
> > and CSR disable.
> >
> > What do you think? Many thanks.
> >
>
> There are multiple breakages in current u-boot/master for SiFive Unleashed 
> board.
>
> We'd better apply them as soon as possible.

OK

Leo will help to apply it ASAP.

Thanks,
Rick

>
> Regards,
> Bin


Re: [PATCH] riscv: ax25-ae350: doc: Fix minor format issues

2021-05-12 Thread Rick Chen
> From: Bin Meng 
> Sent: Wednesday, May 12, 2021 11:26 PM
> To: Rick Jian-Zhi Chen(陳建志) ; u-boot@lists.denx.de
> Cc: Bin Meng 
> Subject: [PATCH] riscv: ax25-ae350: doc: Fix minor format issues
>
> This fixes two minor format issues of the ax25-ae350 reST file.
>
> Signed-off-by: Bin Meng 
> ---
>
>  doc/board/AndesTech/ax25-ae350.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH v5 05/13] binman: Add support for RISC-V OpenSBI fw_dynamic blob

2021-05-11 Thread Rick Chen
> From: Bin Meng 
> Sent: Monday, May 10, 2021 8:24 PM
> To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> ; u-boot@lists.denx.de
> Cc: Bin Meng 
> Subject: [PATCH v5 05/13] binman: Add support for RISC-V OpenSBI fw_dynamic 
> blob
>
> Add an entry for RISC-V OpenSBI's 'fw_dynamic' firmware payload.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - drop "size = <16>" in the binman node
>
>  tools/binman/entries.rst  | 13 +
>  tools/binman/etype/opensbi.py | 23 +++
>  tools/binman/ftest.py |  7 +++
>  tools/binman/test/201_opensbi.dts | 14 ++
>  4 files changed, 57 insertions(+)

Reviewed-by: Rick Chen 


Re: [PATCH v5 02/13] binman: Correct '-a' description in the doc

2021-05-11 Thread Rick Chen
> From: Bin Meng 
> Sent: Monday, May 10, 2021 8:24 PM
> To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> ; u-boot@lists.denx.de
> Cc: Bin Meng 
> Subject: [PATCH v5 02/13] binman: Correct '-a' description in the doc
>
> It needs a space around '-a'.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 
> ---
>
> (no changes since v1)
>
>  tools/binman/binman.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH v5 01/13] common: kconfig: Correct a typo in SPL_LOAD_FIT

2021-05-11 Thread Rick Chen
> From: Bin Meng 
> Sent: Monday, May 10, 2021 8:23 PM
> To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> ; u-boot@lists.denx.de
> Cc: Bin Meng 
> Subject: [PATCH v5 01/13] common: kconfig: Correct a typo in SPL_LOAD_FIT
>
> It should be FDT, not FTD.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 
> ---
>
> (no changes since v1)
>
>  common/Kconfig.boot | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rick Chen 


Re: [PATCH v5 12/13] riscv: ae350: Switch to use binman to generate u-boot.itb

2021-05-11 Thread Rick Chen
> From: Bin Meng 
> Sent: Monday, May 10, 2021 8:24 PM
> To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> ; u-boot@lists.denx.de
> Cc: Bin Meng 
> Subject: [PATCH v5 12/13] riscv: ae350: Switch to use binman to generate 
> u-boot.itb
>
> Use the new BINMAN_STANDALONE_FDT option for AE350 based SPL defconfigs, so 
> that binman is now used to generate u-boot.itb.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - new patch: "riscv: ae350: Switch to use binman to generate u-boot.itb"
>
>  arch/riscv/dts/ae350_32.dts  | 2 ++
>  arch/riscv/dts/ae350_64.dts  | 2 ++
>  board/AndesTech/ax25-ae350/Kconfig   | 1 +
>  configs/ae350_rv32_spl_defconfig | 2 ++
>  configs/ae350_rv32_spl_xip_defconfig | 2 ++
>  configs/ae350_rv64_spl_defconfig | 2 ++
>  configs/ae350_rv64_spl_xip_defconfig | 2 ++
>  7 files changed, 13 insertions(+)

Reviewed-by: Rick Chen 


Re: FW: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb

2021-05-11 Thread Rick Chen
HI Bin,

>
> > Hi Rick,
> >
> > On Tue, May 11, 2021 at 8:49 AM Rick Chen  wrote:
> > >
> > > Hi Bin,
> > >
> > > > Hi Rick,
> > > >
> > > > On Mon, May 10, 2021 at 3:22 PM Rick Chen  wrote:
> > > > >
> > > > > Hi Bin
> > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > > From: Bin Meng 
> > > > > > > Sent: Monday, May 10, 2021 2:58 PM
> > > > > > > To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> > > > > > > ; u-boot@lists.denx.de
> > > > > > > Subject: [PATCH v4 00/13] riscv: Switch to use binman to generate 
> > > > > > > u-boot.itb
> > > > > > >
> > > > > > > This series updates binman to handle creation of u-boot.itb image 
> > > > > > > for RISC-V boards.
> > > > > > >
> > > > > > > Azure results: PASS
> > > > > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=363=results
> > > > > > >
> > > > > > > The following tests were performed:
> > > > > > > * booting qemu-riscv{32|64}_spl_defconfig on QEMU virt
> > > > > > > * booting sifive_unleashed_defconfig on QEMU sifive_u
> > > > > > >
> > > > > > > AE350 SPL defconfigs are not tested. @Rick, could you please test 
> > > > > > > and report?
> > > > > >
> > > > > > OK. I will verify it on AE350.
> > > > >
> > > > > It fail as below messages:
> > > > >
> > > > > U-Boot SPL 2021.07-rc1-00218-g468b3b3 (May 10 2021 - 15:13:03 +0800)
> > > > > Trying to boot from RAM
> > > > > alloc space exhausted
> > > >
> > > > Looks it is running out of memory.
> > > >
> > > > > Could not get FIT buffer of 499076 bytes
> > > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > > >
> > > > Could you please try increasing CONFIG_SYS_SPL_MALLOC_SIZE?
> > >
> > > I increased CONFIG_SYS_SPL_MALLOC_SIZE, but it is useless.
> > > But it boots successfully after increase CONFIG_SPL_SYS_MALLOC_F_LEN 
> > > larger.
> >
> > Thanks for testing. I am not sure why AE350 fails to boot because this
> > series only changes the way to assemble the bits.
> >
> > Could you please confirm if without this patch series, AE350 can boot?
>
> OK.


I have verified AE350 without your patch, it works as below:

U-Boot SPL 2021.07-rc1-00194-g07b5310 (May 12 2021 - 10:59:48 +0800)
Trying to boot from RAM

U-Boot 2021.07-rc1-00194-g07b5310 (May 12 2021 - 10:59:48 +0800)

DRAM:  1 GiB
Flash: 64 MiB
MMC:   mmc@f0e0: 0
Loading Environment from SPIFlash... SF: Detected mx25u1635e with page
size 256 Bytes, erase size 4 KiB, total 2 MiB
OK
In:serial@f030
Out:   serial@f030
Err:   serial@f030
Net:   no alias for ethernet0

Warning: mac@e010 (eth0) using random MAC address - 26:00:fa:12:76:ad
eth0: mac@e010
Hit any key to stop autoboot:  0
RISC-V #

=
With your patch, it fail as below:
=

U-Boot SPL 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:09:11 +0800)
Trying to boot from RAM
alloc space exhausted
Could not get FIT buffer of 499076 bytes
check CONFIG_SYS_SPL_MALLOC_SIZE
No device tree specified in SPL image

===
After increase CONFIG_SPL_SYS_MALLOC_F_LEN, it works as below
===
U-Boot SPL 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:11:00 +0800)
Trying to boot from RAM


U-Boot 2021.07-rc1-00207-g28a2d21 (May 12 2021 - 11:11:00 +0800)

DRAM:  1 GiB
Flash: 64 MiB
MMC:   mmc@f0e0: 0
Loading Environment from SPIFlash... SF: Detected mx25u1635e with page
size 256 Bytes, erase size 4 KiB, total 2 MiB
OK
In:serial@f030
Out:   serial@f030
Err:   serial@f030
Net:   no alias for ethernet0

Warning: mac@e010 (eth0) using random MAC address - e6:58:7e:7c:5f:49
eth0: mac@e010
Hit any key to stop autoboot:  0
RISC-V #


I found that it need larger heap size when spl try to get fit image
with using binman to generate u-boot.itb instead of
USE_SPL_FIT_GENERATOR.
But it is OK. I will send a patch for AE350 later.

Thanks,
Rick




>
> >
> > Regards,
> > Bin


Re: FW: [PATCH] pwm: sifive: make set_config() and set_enable() work properly

2021-05-11 Thread Rick Chen
> From: U-Boot  On Behalf Of Vincent Chen
> Sent: Monday, May 03, 2021 3:27 PM
> To: s...@chromium.org; h...@denx.de
> Cc: u-boot@lists.denx.de; Vincent Chen 
> Subject: [PATCH] pwm: sifive: make set_config() and set_enable() work properly
>
> The pwm_sifive_set_config() and pwm_sifive_set_enable() cannot work properly 
> due to the wrong implementations. It will cause the u-boot PWM command to not 
> work as expected. The bugs will be resolved in this patch.
>
> Signed-off-by: Vincent Chen 
> ---
>  drivers/pwm/pwm-sifive.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)

Reviewed-by: Rick Chen 


Re: FW: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb

2021-05-10 Thread Rick Chen
> Hi Rick,
>
> On Tue, May 11, 2021 at 8:49 AM Rick Chen  wrote:
> >
> > Hi Bin,
> >
> > > Hi Rick,
> > >
> > > On Mon, May 10, 2021 at 3:22 PM Rick Chen  wrote:
> > > >
> > > > Hi Bin
> > > >
> > > > > Hi Bin,
> > > > >
> > > > > > From: Bin Meng 
> > > > > > Sent: Monday, May 10, 2021 2:58 PM
> > > > > > To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> > > > > > ; u-boot@lists.denx.de
> > > > > > Subject: [PATCH v4 00/13] riscv: Switch to use binman to generate 
> > > > > > u-boot.itb
> > > > > >
> > > > > > This series updates binman to handle creation of u-boot.itb image 
> > > > > > for RISC-V boards.
> > > > > >
> > > > > > Azure results: PASS
> > > > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=363=results
> > > > > >
> > > > > > The following tests were performed:
> > > > > > * booting qemu-riscv{32|64}_spl_defconfig on QEMU virt
> > > > > > * booting sifive_unleashed_defconfig on QEMU sifive_u
> > > > > >
> > > > > > AE350 SPL defconfigs are not tested. @Rick, could you please test 
> > > > > > and report?
> > > > >
> > > > > OK. I will verify it on AE350.
> > > >
> > > > It fail as below messages:
> > > >
> > > > U-Boot SPL 2021.07-rc1-00218-g468b3b3 (May 10 2021 - 15:13:03 +0800)
> > > > Trying to boot from RAM
> > > > alloc space exhausted
> > >
> > > Looks it is running out of memory.
> > >
> > > > Could not get FIT buffer of 499076 bytes
> > > > check CONFIG_SYS_SPL_MALLOC_SIZE
> > >
> > > Could you please try increasing CONFIG_SYS_SPL_MALLOC_SIZE?
> >
> > I increased CONFIG_SYS_SPL_MALLOC_SIZE, but it is useless.
> > But it boots successfully after increase CONFIG_SPL_SYS_MALLOC_F_LEN larger.
>
> Thanks for testing. I am not sure why AE350 fails to boot because this
> series only changes the way to assemble the bits.
>
> Could you please confirm if without this patch series, AE350 can boot?

OK.

>
> Regards,
> Bin


Re: FW: [PATCH v5 05/13] binman: Add support for RISC-V OpenSBI fw_dynamic blob

2021-05-10 Thread Rick Chen
> From: Bin Meng 
> Sent: Monday, May 10, 2021 8:24 PM
> To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> ; u-boot@lists.denx.de
> Cc: Bin Meng 
> Subject: [PATCH v5 05/13] binman: Add support for RISC-V OpenSBI fw_dynamic 
> blob
>
> Add an entry for RISC-V OpenSBI's 'fw_dynamic' firmware payload.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 
>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - drop "size = <16>" in the binman node
>
>  tools/binman/entries.rst  | 13 +
>  tools/binman/etype/opensbi.py | 23 +++
>  tools/binman/ftest.py |  7 +++
>  tools/binman/test/201_opensbi.dts | 14 ++
>  4 files changed, 57 insertions(+)

Reviewed-by: Rick Chen 


Re: FW: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb

2021-05-10 Thread Rick Chen
Hi Bin,

> Hi Rick,
>
> On Mon, May 10, 2021 at 3:22 PM Rick Chen  wrote:
> >
> > Hi Bin
> >
> > > Hi Bin,
> > >
> > > > From: Bin Meng 
> > > > Sent: Monday, May 10, 2021 2:58 PM
> > > > To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> > > > ; u-boot@lists.denx.de
> > > > Subject: [PATCH v4 00/13] riscv: Switch to use binman to generate 
> > > > u-boot.itb
> > > >
> > > > This series updates binman to handle creation of u-boot.itb image for 
> > > > RISC-V boards.
> > > >
> > > > Azure results: PASS
> > > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=363=results
> > > >
> > > > The following tests were performed:
> > > > * booting qemu-riscv{32|64}_spl_defconfig on QEMU virt
> > > > * booting sifive_unleashed_defconfig on QEMU sifive_u
> > > >
> > > > AE350 SPL defconfigs are not tested. @Rick, could you please test and 
> > > > report?
> > >
> > > OK. I will verify it on AE350.
> >
> > It fail as below messages:
> >
> > U-Boot SPL 2021.07-rc1-00218-g468b3b3 (May 10 2021 - 15:13:03 +0800)
> > Trying to boot from RAM
> > alloc space exhausted
>
> Looks it is running out of memory.
>
> > Could not get FIT buffer of 499076 bytes
> > check CONFIG_SYS_SPL_MALLOC_SIZE
>
> Could you please try increasing CONFIG_SYS_SPL_MALLOC_SIZE?

I increased CONFIG_SYS_SPL_MALLOC_SIZE, but it is useless.
But it boots successfully after increase CONFIG_SPL_SYS_MALLOC_F_LEN larger.

Thanks,
Rick

>
> > No device tree specified in SPL image
> > ### ERROR ### Please RESET the board ###
> >
> > Any comments ?
>
> Regards,
> Bin


Re: FW: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb

2021-05-10 Thread Rick Chen
Hi Bin

> Hi Bin,
>
> > From: Bin Meng 
> > Sent: Monday, May 10, 2021 2:58 PM
> > To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> > ; u-boot@lists.denx.de
> > Subject: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb
> >
> > This series updates binman to handle creation of u-boot.itb image for 
> > RISC-V boards.
> >
> > Azure results: PASS
> > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=363=results
> >
> > The following tests were performed:
> > * booting qemu-riscv{32|64}_spl_defconfig on QEMU virt
> > * booting sifive_unleashed_defconfig on QEMU sifive_u
> >
> > AE350 SPL defconfigs are not tested. @Rick, could you please test and 
> > report?
>
> OK. I will verify it on AE350.

It fail as below messages:

U-Boot SPL 2021.07-rc1-00218-g468b3b3 (May 10 2021 - 15:13:03 +0800)
Trying to boot from RAM
alloc space exhausted
Could not get FIT buffer of 499076 bytes
check CONFIG_SYS_SPL_MALLOC_SIZE
No device tree specified in SPL image
### ERROR ### Please RESET the board ###

Any comments ?

Thanks,
Rick

>
> Thanks,
> Rick


Re: FW: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb

2021-05-10 Thread Rick Chen
Hi Bin,

> From: Bin Meng 
> Sent: Monday, May 10, 2021 2:58 PM
> To: Simon Glass ; Rick Jian-Zhi Chen(陳建志) 
> ; u-boot@lists.denx.de
> Subject: [PATCH v4 00/13] riscv: Switch to use binman to generate u-boot.itb
>
> This series updates binman to handle creation of u-boot.itb image for RISC-V 
> boards.
>
> Azure results: PASS
> https://dev.azure.com/bmeng/GitHub/_build/results?buildId=363=results
>
> The following tests were performed:
> * booting qemu-riscv{32|64}_spl_defconfig on QEMU virt
> * booting sifive_unleashed_defconfig on QEMU sifive_u
>
> AE350 SPL defconfigs are not tested. @Rick, could you please test and report?

OK. I will verify it on AE350.

Thanks,
Rick


Re: [PATCH] riscv: Fix arch_fixup_fdt always failing without /chosen

2021-05-09 Thread Rick Chen
> If /chosen was missing, chosen_offset would never get updated with the new
> /chosen node. This would cause fdt_setprop_u32 to fail. This patch fixes
> this by setting chosen_offset. In addition, log any errors from setting
> boot-hartid as well.
>
> Fixes: 177c53fe6c6 ("riscv: Move all fdt fixups together")
> Signed-off-by: Sean Anderson 
> ---
> I have not actually tested this (nor observed the original failure). But this
> seemed buggy from inspection.
>
>  arch/riscv/lib/fdt_fixup.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

Good catch !

Reviewed-by: Rick Chen 


Re: [PATCH v6 2/7] riscv: cpu: fu740: Add support for cpu fu740

2021-05-02 Thread Rick Chen
> From: Green Wan [mailto:green@sifive.com]
> Sent: Thursday, April 08, 2021 9:40 PM
> Cc: bmeng...@gmail.com; Green Wan ; Rick Jian-Zhi 
> Chen(陳建志) ; Paul Walmsley ; 
> Palmer Dabbelt ; Anup Patel ; Atish 
> Patra ; Pragnesh Patel ; 
> Lukasz Majewski ; Joe Hershberger ; 
> Ramon Fried ; u-boot@lists.denx.de
> Subject: [PATCH v6 2/7] riscv: cpu: fu740: Add support for cpu fu740
>
> Add SiFive fu740 cpu to support RISC-V arch
>
> Signed-off-by: Green Wan 
> Reviewed-by: Bin Meng 
> ---
>  arch/riscv/Kconfig|  1 +
>  arch/riscv/cpu/fu740/Kconfig  | 37 +++
>  arch/riscv/cpu/fu740/Makefile | 12 +
>  arch/riscv/cpu/fu740/cache.c  | 55 +++
>  arch/riscv/cpu/fu740/cpu.c| 22 +
>  arch/riscv/cpu/fu740/dram.c   | 38 
>  arch/riscv/cpu/fu740/spl.c| 23 ++
>  arch/riscv/include/asm/arch-fu740/cache.h | 14 ++
>  arch/riscv/include/asm/arch-fu740/clk.h   | 14 ++
>  arch/riscv/include/asm/arch-fu740/gpio.h  | 38   
> arch/riscv/include/asm/arch-fu740/reset.h | 13 ++
>  arch/riscv/include/asm/arch-fu740/spl.h   | 14 ++
>  arch/riscv/lib/sifive_clint.c |  1 -

Refer to comments about [PATCH v7 1/8].
https://www.mail-archive.com/u-boot@lists.denx.de/msg405522.html
Hope same code base can be effective re-use in the future.

Reviewed-by: Rick Chen 


Re: [PATCH v7 0/8] Add FU740 chip and HiFive Unmatched board support

2021-05-02 Thread Rick Chen
Hi Green,

> Hi Rick,
>
> Thanks for quick response. See my reply below.
>
> On Mon, May 3, 2021 at 10:34 AM Rick Chen  wrote:
> >
> > Hi Green,
> >
> >
> > I did not sign the Reviewed-by for this patch "board: sifive: add
> > HiFive Unmatched board support" from v1 to v6.
> > But it just has been tagged in [v7,7/8] board: sifive: add HiFive
> > Unmatched board support by yourself.
>
> Sorry, I might have a quick conclusion when Reviewed-by is on our
> previous discussion in [v6 1/7]. We ended up splitting dts into two.
> One for fu740 and the other for Unmatched board specifically. And put
> them closer. Then, I added the review-by to them.
>
>  Here is the previous discussion. 
> "Makefile need the dts file, but it is not exist in this patch. It
> doesn't make sense.
>
> Maybe you can combine with the dts relative files in [PATCH v6 6/7]
> into one patch and name as :
> riscv: dts: ...
>
> LGTM.
> Other than that,
>
> Reviewed-by: Rick Chen  "
>
> "It is OK.
>
> You may arrange them nearby as below:
> 6/x riscv: dts: support fu740
> 7/x riscv: dst: support HiFive Unmatched board
>
> Thanks,
> Rick"
>
> >
> > [v6,6/7] board: sifive: add HiFive Unmatched board support
> > https://patchwork.ozlabs.org/project/uboot/patch/20210408134020.238658-7-green@sifive.com/
> >
> > [v7,7/8] board: sifive: add HiFive Unmatched board support
> > https://patchwork.ozlabs.org/project/uboot/patch/20210422091202.396956-8-green@sifive.com/
> >
> > Actually I don't like this patch that you mix every things (arch/,
> > drivers/, common/, doc/)together in this patch.
> > But it is OK for now.
>
> Noted. Thanks for reminding me.
>
> >
> > BTW, in [PATCH v7 1/8] riscv: cpu: fu740: Add support for cpu fu740
> > I found that arch/riscv/cpu/fu740/cpu.c and arch/riscv/fu540/cpu.c are
> > 100% the same.
> >
> > And about spl.c, they are only different in the annotation of Copyright
> > diff fu540/spl.c fu740/spl.c
> > 3c3
> > <  * Copyright (C) 2020 SiFive, Inc
> > ---
> > >  * Copyright (C) 2020-201 SiFive, Inc
> >
> > About the cache.c, they are just different in one character
> >
> > diff fu540/cache.c fu740/cache.c
> > 3c3
> > <  * Copyright (C) 2020 SiFive, Inc
> > ---
> > >  * Copyright (C) 2020-2021 SiFive, Inc
> > 10d9
> > < #include 
> > 12a12
> > > #include 
> > 34c34
> > <"sifive,fu540-c000-ccache");
> > ---
> > >"sifive,fu740-c000-ccache");
> >
> >
> > Originally, I am considering to tell you to re-use the same code base
> > instead of just copy and create.
> > After a few days of consideration, I feel it's OK for now.
> >
> You're right. As you mentioned, I also considered having common code.
> But I conservatively decided to keep separated files to handle
> possible differences among chips.
>
> > About
> > [PATCH v7 2/8] drivers: clk: add fu740 support and
> > [PATCH v7 4/8] drivers: pci: add pcie support for fu740,
> > there are still not get any Reviewed-by till now.
> > For me, it will be better if someone can tag a Reviewed-by here.
> >
> > Principally, it will be suggested to split drivers from RISC-V
> > relevant, do not mix them together as Palmer said.
>
> Not sure whether we'll have the driver reviewers very quick. What do
> you think of moving forward? I can try to ping some driver maintainers
> and see if we have someone to review them. =]

OK.
Maybe let's just wait for a period of time, if it still no furthermore response.
I can help to pull them via riscv tree.

Thanks,
Rick

>
> Thanks,
>
>
>
> >
> > Thanks,
> > Rick
> >
> > > From: Bin Meng 
> > > Sent: Thursday, April 29, 2021 8:27 PM
> > > To: Green Wan 
> > > Cc: Rick Jian-Zhi Chen(陳建志) ; Paul Walmsley 
> > > ; Palmer Dabbelt ; Anup 
> > > Patel ; Atish Patra ; Lukasz 
> > > Majewski ; Joe Hershberger ; Ramon 
> > > Fried ; U-Boot Mailing List 
> > > Subject: Re: [PATCH v7 0/8] Add FU740 chip and HiFive Unmatched board 
> > > support
> > >
> > > Hi Green,
> > >
> > > On Thu, Apr 29, 2021 at 7:11 PM Green Wan  wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > How should this patch set be proceeded?
> > > >
> > > > To summary the major changes,
> > > > - I've rebased to mainstream and merged pcie refactoring code which
> > > > based on pcie_dw_common.c
> > > > - separate unmatched dts into separated patch.
> > > >
> > >
> > > I don't have specific comments. Rick should pick this up via the riscv 
> > > tree. Thanks!
> > >
> > > Regards,
> > > Bin


Re: [PATCH v7 0/8] Add FU740 chip and HiFive Unmatched board support

2021-05-02 Thread Rick Chen
Hi Green,


I did not sign the Reviewed-by for this patch "board: sifive: add
HiFive Unmatched board support" from v1 to v6.
But it just has been tagged in [v7,7/8] board: sifive: add HiFive
Unmatched board support by yourself.

[v6,6/7] board: sifive: add HiFive Unmatched board support
https://patchwork.ozlabs.org/project/uboot/patch/20210408134020.238658-7-green@sifive.com/

[v7,7/8] board: sifive: add HiFive Unmatched board support
https://patchwork.ozlabs.org/project/uboot/patch/20210422091202.396956-8-green@sifive.com/

Actually I don't like this patch that you mix every things (arch/,
drivers/, common/, doc/)together in this patch.
But it is OK for now.

BTW, in [PATCH v7 1/8] riscv: cpu: fu740: Add support for cpu fu740
I found that arch/riscv/cpu/fu740/cpu.c and arch/riscv/fu540/cpu.c are
100% the same.

And about spl.c, they are only different in the annotation of Copyright
diff fu540/spl.c fu740/spl.c
3c3
<  * Copyright (C) 2020 SiFive, Inc
---
>  * Copyright (C) 2020-201 SiFive, Inc

About the cache.c, they are just different in one character

diff fu540/cache.c fu740/cache.c
3c3
<  * Copyright (C) 2020 SiFive, Inc
---
>  * Copyright (C) 2020-2021 SiFive, Inc
10d9
< #include 
12a12
> #include 
34c34
<"sifive,fu540-c000-ccache");
---
>"sifive,fu740-c000-ccache");


Originally, I am considering to tell you to re-use the same code base
instead of just copy and create.
After a few days of consideration, I feel it's OK for now.

About
[PATCH v7 2/8] drivers: clk: add fu740 support and
[PATCH v7 4/8] drivers: pci: add pcie support for fu740,
there are still not get any Reviewed-by till now.
For me, it will be better if someone can tag a Reviewed-by here.

Principally, it will be suggested to split drivers from RISC-V
relevant, do not mix them together as Palmer said.

Thanks,
Rick

> From: Bin Meng 
> Sent: Thursday, April 29, 2021 8:27 PM
> To: Green Wan 
> Cc: Rick Jian-Zhi Chen(陳建志) ; Paul Walmsley 
> ; Palmer Dabbelt ; Anup Patel 
> ; Atish Patra ; Lukasz Majewski 
> ; Joe Hershberger ; Ramon Fried 
> ; U-Boot Mailing List 
> Subject: Re: [PATCH v7 0/8] Add FU740 chip and HiFive Unmatched board support
>
> Hi Green,
>
> On Thu, Apr 29, 2021 at 7:11 PM Green Wan  wrote:
> >
> > Hi Bin,
> >
> > How should this patch set be proceeded?
> >
> > To summary the major changes,
> > - I've rebased to mainstream and merged pcie refactoring code which
> > based on pcie_dw_common.c
> > - separate unmatched dts into separated patch.
> >
>
> I don't have specific comments. Rick should pick this up via the riscv tree. 
> Thanks!
>
> Regards,
> Bin


Re: [PATCH] atcspi200: Add timeout mechanism in spi_xfer()

2021-04-22 Thread Rick Chen
> From: Dylan Dai-Rong Jhong(鍾岱融) 
> Sent: Thursday, April 01, 2021 4:49 PM
> To: ja...@amarulasolutions.com; u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Ruinland Chuan-Tzu Tsa(蔡傳資) 
> ; Alan Quey-Liang Kao(高魁良) ; 
> Leo Yu-Chi Liang(梁育齊) ; x57109...@gmail.com; Dylan 
> Dai-Rong Jhong(鍾岱融) 
> Subject: [PATCH] atcspi200: Add timeout mechanism in spi_xfer()
>
> Adding timeout mechanism to avoid spi driver from stucking in the while loop 
> in __atcspi200_spi_xfer().
>
> Signed-off-by: Dylan Jhong 
> ---
>  drivers/spi/atcspi200_spi.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Rick Chen 


Re: [RFC PATCH v6 2/2] arch: riscv: cpu: fu740: clear feature disable CSR

2021-04-16 Thread Rick Chen
> From: Green Wan [mailto:green@sifive.com]
> Sent: Thursday, April 15, 2021 4:45 PM
> Cc: Green Wan; Sean Anderson; Bin Meng; Rick Jian-Zhi Chen(陳建志); Bin Meng; 
> Simon Glass; Pragnesh Patel; Jagan Teki; Atish Patra; Leo Yu-Chi Liang(梁育齊); 
> u-boot@lists.denx.de
> Subject: [RFC PATCH v6 2/2] arch: riscv: cpu: fu740: clear feature disable CSR
>

nitpicky: arch

> Clear feature disable CSR to turn on all features of hart. The detail
> is specified at section, 'SiFive Feature Disable CSR', in user manual
>
> https://sifive.cdn.prismic.io/sifive/aee0dd4c-d156-496e-a6c4-db0cf54bbe68_sifive_U74MC_rtl_full_20G1.03.00_manual.pdf
>
> Signed-off-by: Green Wan 
> Reviewed-by: Sean Anderson 
> Reviewed-by: Bin Meng 
> ---
>  arch/riscv/cpu/fu740/spl.c | 15 +++
>  1 file changed, 15 insertions(+)

Reviewed-by: Rick Chen 


Re: [RFC PATCH v6 1/2] arch: riscv: cpu: Add callback to init each core

2021-04-16 Thread Rick Chen
> From: Green Wan [mailto:green@sifive.com]
> Sent: Thursday, April 15, 2021 4:45 PM
> Cc: Green Wan; Rick Jian-Zhi Chen(陳建志); Sean Anderson; Bin Meng; Simon Glass; 
> Pragnesh Patel; Jagan Teki; Atish Patra; Leo Yu-Chi Liang(梁育齊); Brad Kim; 
> u-boot@lists.denx.de
> Subject: [RFC PATCH v6 1/2] arch: riscv: cpu: Add callback to init each core

nitpicky, arch is redundant in title.

riscv: cpu: Add callback to init each core
will be fine.

>
> Add a callback harts_early_init() to start.S to allow different riscv
> hart perform setup code for each hart as early as possible. Since all
> the harts enter the callback, they must be able to run the same
> setup.
>
> Signed-off-by: Green Wan 
> ---
>  arch/riscv/cpu/cpu.c   | 11 +++
>  arch/riscv/cpu/start.S |  8 
>  2 files changed, 19 insertions(+)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index 85592f5bee..43c086ca19 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -140,3 +140,14 @@ int arch_early_init_r(void)
>  {
> return riscv_cpu_probe();
>  }
> +
> +/**
> + * harts_early_init() - A callback function called by start.S to configure
> + * feature settings of each hart.
> + *
> + * In a multi-core system, memory access shall be careful here, it shall
> + * take care race conditions.
> + */
> +__weak void harts_early_init(void)
> +{
> +}
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 8589509e01..42fc1a4406 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -117,6 +117,14 @@ call_board_init_f_0:
> mv  sp, a0
>  #endif
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)

This M-mode check can be remove, it is a repeat confirmation in
harts_early_init() of arch/riscv/cpu/fu740/spl.c

Other than that,

Reviewed-by: Rick Chen 

> +   /*
> +* Configure proprietary settings and customized CRSs of harts
> +*/
> +call_harts_early_init:
> +   jal harts_early_init
> +#endif
> +
>  #ifndef CONFIG_XIP
> /*
>  * Pick hart to initialize global data and run U-Boot. The other harts
> --
> 2.31.0


Re: [PATCH v6 1/7] riscv: dts: add fu740 support

2021-04-16 Thread Rick Chen
Hi Green

> On Thu, Apr 15, 2021 at 1:25 PM Rick Chen  wrote:
> >
> > Hi Green,
> >
> > > From: Green Wan [mailto:green@sifive.com]
> > > Sent: Thursday, April 08, 2021 9:40 PM
> > > Cc: bmeng...@gmail.com; Green Wan; Greentime Hu; Rick Jian-Zhi Chen(陳建志); 
> > > Paul Walmsley; Palmer Dabbelt; Anup Patel; Atish Patra; Pragnesh Patel; 
> > > Lukasz Majewski; Joe Hershberger; Ramon Fried; u-boot@lists.denx.de
> > > Subject: [PATCH v6 1/7] riscv: dts: add fu740 support
> > >
> > > Add dts support for fu740. The HiFive Unmatched support is based on
> > > fu740 cpu and drivers in following patch set.
> > >
> > > Signed-off-by: Green Wan 
> > > [greentime.hu: set fu740 speed to 1.2GHz]
> > > Signed-off-by: Greentime Hu 
> > > Reviewed-by: Bin Meng 
> > > ---
> > >  arch/riscv/dts/Makefile   |   1 +
> > >  arch/riscv/dts/fu740-c000-u-boot.dtsi | 105 ++
> > >  arch/riscv/dts/fu740-c000.dtsi| 329 ++
> > >  include/dt-bindings/clock/sifive-fu740-prci.h |  25 ++
> > >  include/dt-bindings/reset/sifive-fu740-prci.h |  19 +
> > >  5 files changed, 479 insertions(+)
> > >  create mode 100644 arch/riscv/dts/fu740-c000-u-boot.dtsi
> > >  create mode 100644 arch/riscv/dts/fu740-c000.dtsi
> > >  create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h
> > >  create mode 100644 include/dt-bindings/reset/sifive-fu740-prci.h
> > >
> > > diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> > > index 8138d89d84..ed32f56c9e 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_UNLEASHED) += hifive-unleashed-a00.dtb
> > > +dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
> >
> > Makefile need the dts file, but it is not exist in this patch. It
> > doesn't make sense.
> >
> > Maybe you can combine with the dts relative files in [PATCH v6 6/7]
> > into one patch and name as :
> > riscv: dts: ...
>
> Hi Rick,
>
> Thanks for review.
>
> How about move change of arch/riscv/dts/Makefile to [PATCH v6 6/7]
> since it's more like a board dependent change. This patch [1/7] is
> pure for fu740 dts review. I'd like to keep one for fu740 dts and the
> rest dts for unmatched board.
>
> What do you think of it?

It is OK.

You may arrange them nearby as below:
6/x riscv: dts: support fu740
7/x riscv: dst: support HiFive Unmatched board

Thanks,
Rick

>
> Thanks,
> -
> Green
>
> >
> > LGTM.
> > Other than that,
> >
> > Reviewed-by: Rick Chen 
> >
> > >  dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
> > >  dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
> > >
> > > diff --git a/arch/riscv/dts/fu740-c000-u-boot.dtsi 
> > > b/arch/riscv/dts/fu740-c000-u-boot.dtsi
> > > new file mode 100644
> > > index 00..a5d0688b06
> > > --- /dev/null
> > > +++ b/arch/riscv/dts/fu740-c000-u-boot.dtsi
> > > @@ -0,0 +1,105 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > +/*
> > > + * (C) Copyright 2020-2021 SiFive, Inc
> > > + */
> > > +
> > > +#include 
> > > +
> > > +/ {
> > > +   cpus {
> > > +   assigned-clocks = < PRCI_CLK_COREPLL>;
> > > +   assigned-clock-rates = <12>;
> > > +   u-boot,dm-spl;
> > > +   cpu0: cpu@0 {
> > > +   clocks = < PRCI_CLK_COREPLL>;
> > > +   u-boot,dm-spl;
> > > +   status = "okay";
> > > +   cpu0_intc: interrupt-controller {
> > > +   u-boot,dm-spl;
> > > +   };
> > > +   };
> > > +   cpu1: cpu@1 {
> > > +   clocks = < PRCI_CLK_COREPLL>;
> > > +   u-boot,dm-spl;
> > > +   cpu1_intc: interrupt-controller {
> > > +   u-boot,dm-spl;
> > > +   };
> > > +   };
> > > +   cpu2: cpu@2 {
> > > 

Re: [PATCH v6 1/7] riscv: dts: add fu740 support

2021-04-14 Thread Rick Chen
Hi Green,

> From: Green Wan [mailto:green@sifive.com]
> Sent: Thursday, April 08, 2021 9:40 PM
> Cc: bmeng...@gmail.com; Green Wan; Greentime Hu; Rick Jian-Zhi Chen(陳建志); 
> Paul Walmsley; Palmer Dabbelt; Anup Patel; Atish Patra; Pragnesh Patel; 
> Lukasz Majewski; Joe Hershberger; Ramon Fried; u-boot@lists.denx.de
> Subject: [PATCH v6 1/7] riscv: dts: add fu740 support
>
> Add dts support for fu740. The HiFive Unmatched support is based on
> fu740 cpu and drivers in following patch set.
>
> Signed-off-by: Green Wan 
> [greentime.hu: set fu740 speed to 1.2GHz]
> Signed-off-by: Greentime Hu 
> Reviewed-by: Bin Meng 
> ---
>  arch/riscv/dts/Makefile   |   1 +
>  arch/riscv/dts/fu740-c000-u-boot.dtsi | 105 ++
>  arch/riscv/dts/fu740-c000.dtsi| 329 ++
>  include/dt-bindings/clock/sifive-fu740-prci.h |  25 ++
>  include/dt-bindings/reset/sifive-fu740-prci.h |  19 +
>  5 files changed, 479 insertions(+)
>  create mode 100644 arch/riscv/dts/fu740-c000-u-boot.dtsi
>  create mode 100644 arch/riscv/dts/fu740-c000.dtsi
>  create mode 100644 include/dt-bindings/clock/sifive-fu740-prci.h
>  create mode 100644 include/dt-bindings/reset/sifive-fu740-prci.h
>
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index 8138d89d84..ed32f56c9e 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_UNLEASHED) += hifive-unleashed-a00.dtb
> +dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb

Makefile need the dts file, but it is not exist in this patch. It
doesn't make sense.

Maybe you can combine with the dts relative files in [PATCH v6 6/7]
into one patch and name as :
riscv: dts: ...

LGTM.
Other than that,

Reviewed-by: Rick Chen 

>  dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
>  dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
>
> diff --git a/arch/riscv/dts/fu740-c000-u-boot.dtsi 
> b/arch/riscv/dts/fu740-c000-u-boot.dtsi
> new file mode 100644
> index 00..a5d0688b06
> --- /dev/null
> +++ b/arch/riscv/dts/fu740-c000-u-boot.dtsi
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * (C) Copyright 2020-2021 SiFive, Inc
> + */
> +
> +#include 
> +
> +/ {
> +   cpus {
> +   assigned-clocks = < PRCI_CLK_COREPLL>;
> +   assigned-clock-rates = <12>;
> +   u-boot,dm-spl;
> +   cpu0: cpu@0 {
> +   clocks = < PRCI_CLK_COREPLL>;
> +   u-boot,dm-spl;
> +   status = "okay";
> +   cpu0_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   cpu1: cpu@1 {
> +   clocks = < PRCI_CLK_COREPLL>;
> +   u-boot,dm-spl;
> +   cpu1_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   cpu2: cpu@2 {
> +   clocks = < PRCI_CLK_COREPLL>;
> +   u-boot,dm-spl;
> +   cpu2_intc: interrupt-controller {
> +u-boot,dm-spl;
> +   };
> +   };
> +   cpu3: cpu@3 {
> +   clocks = < PRCI_CLK_COREPLL>;
> +   u-boot,dm-spl;
> +   cpu3_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   cpu4: cpu@4 {
> +   clocks = < PRCI_CLK_COREPLL>;
> +   u-boot,dm-spl;
> +   cpu4_intc: interrupt-controller {
> +   u-boot,dm-spl;
> +   };
> +   };
> +   };
> +
> +   soc {
> +   u-boot,dm-spl;
> +   clint: clint@200 {
> +   compatible = "riscv,clint0";
> +   interrupts-extended = <_intc 3 _intc 7
> +  _intc 3 _intc 7
> +  _intc 3 _intc 7
> +  _intc 3 _intc 7
> +  _intc 3 _intc 7>;
> +   reg = <0x0 0x200 0x0 0x1>;
&

Re: [RFC PATCH v5 2/2] board: sifive: unmatched: clear feature disable CSR

2021-04-13 Thread Rick Chen
Hi Green,

> From: Green Wan [mailto:green@sifive.com]
> Sent: Tuesday, April 13, 2021 5:32 PM
> Cc: Green Wan; Sean Anderson; Bin Meng; Rick Jian-Zhi Chen(陳建志); Paul 
> Walmsley; Pragnesh Patel; Bin Meng; Simon Glass; Atish Patra; Leo Yu-Chi 
> Liang(梁育齊); Brad Kim; open list
> Subject: [RFC PATCH v5 2/2] board: sifive: unmatched: clear feature disable 
> CSR
>
> Clear feature disable CSR to turn on all features of hart. The detail
> is specified at section, 'SiFive Feature Disable CSR', in user manual
>
> https://sifive.cdn.prismic.io/sifive/aee0dd4c-d156-496e-a6c4-db0cf54bbe68_sifive_U74MC_rtl_full_20G1.03.00_manual.pdf
>
> Signed-off-by: Green Wan 
> Reviewed-by: Sean Anderson 
> Reviewed-by: Bin Meng 
> ---
>  board/sifive/unmatched/spl.c | 15 +++

Is this CSR depends on unmatched board ?
I just wonder why not add in /arch/riscv/cpu/ and create fu74, just
like /arch/riscv/cpu/fu540/spl.c ?

Thanks,
Rick

>  1 file changed, 15 insertions(+)
>
> diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
> index 5e1333b09a..ed48dac511 100644
> --- a/board/sifive/unmatched/spl.c
> +++ b/board/sifive/unmatched/spl.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -22,6 +23,20 @@
>  #define MODE_SELECT_SD 0xb
>  #define MODE_SELECT_MASK   GENMASK(3, 0)
>
> +#define CSR_U74_FEATURE_DISABLE0x7c1
> +
> +void harts_early_init(void)
> +{
> +   /*
> +* Feature Disable CSR
> +*
> +* Clear feature disable CSR to '0' to turn on all features for
> +* each core. This operation must be in M-mode.
> +*/
> +   if (CONFIG_IS_ENABLED(RISCV_MMODE))
> +   csr_write(CSR_U74_FEATURE_DISABLE, 0);
> +}
> +
>  int spl_board_init_f(void)
>  {
> int ret;
> --
> 2.31.0


Re: [RFC PATCH v5 1/2] arch: riscv: cpu: Add callback to init each core

2021-04-13 Thread Rick Chen
> From: Green Wan [mailto:green@sifive.com]
> Sent: Tuesday, April 13, 2021 5:32 PM
> Cc: Green Wan; Rick Jian-Zhi Chen(陳建志); Paul Walmsley; Pragnesh Patel; Sean 
> Anderson; Bin Meng; Simon Glass; Atish Patra; Leo Yu-Chi Liang(梁育齊); Brad 
> Kim; open list
> Subject: [RFC PATCH v5 1/2] arch: riscv: cpu: Add callback to init each core
>
> Add a callback harts_early_init() to ./arch/riscv/cpu/start.S to

Please don't describe the file path because in the following log it
can be found obviously.
or you can reword as:
Add a callback harts_early_init() to start.S

> allow different riscv hart perform setup code for each hart as early
> as possible. Since all the harts enter the callback, they must be able
> to run the same setup.
>
> Signed-off-by: Green Wan 
> ---
>  arch/riscv/cpu/cpu.c   | 15 +++
>  arch/riscv/cpu/start.S | 12 
>  2 files changed, 27 insertions(+)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index 85592f5bee..b2b49812c4 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -140,3 +140,18 @@ int arch_early_init_r(void)
>  {
> return riscv_cpu_probe();
>  }
> +
> +/**
> + * harts_early_init() - A callback function called by
> + * ./arch/riscv/cpu/start.S to allow to disable/enable features of each

Don't describe the called path.
_weak function is a common usage in U-Boot, if someone grep the U-Boot
and will know how to use this callback.

allow to disable/enable features ...
it shall be reword as:
configure feature settings of each hart (Because someone maybe not
just enable or disable features but need to adjust the default value
or somewhat)

> + * core. For example, turn on or off the functional block of CPU harts.

Same meaning as disable/enable features of each hart. It is
unnecessary to describe again.

> + *
> + * In a multi-core system, this function must not access shared resources.
> + *
> + * Any access to such resources would probably be better done with
> + * available_harts_lock held. However, I doubt that any such access will be

The point is atomic instruction but not the available_harts_lock, it
is only a variable allocated in memory.
You may describe that:
Memory access shall be careful here, it shall take care race conditions.

> + * necessary.
> + */
> +__weak void harts_early_init(void)
> +{
> +}
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 8589509e01..a481102960 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -117,6 +117,18 @@ call_board_init_f_0:
> mv  sp, a0
>  #endif
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> +   /*
> +* Jump to harts_early_init() to perform init for each core. Not
> +* expect to access gd since gd is not initialized. All operations in 
> the
> +* function should affect core itself only. In multi-core system, any 
> access
> +* to common resource or registers outside core should be avoided or 
> need a
> +* protection for multicore.
> +*/

Don't describe too much duplicate words for harts_early_init in
start.S and cpu.c.
Here you just describe this callback can configure not standard or
customized CSRs.
And describe race condition issue of memory access in SMP system for
harts_early_init() in cpu.c

Thanks,
Rick

> +call_harts_early_init:
> +   jal harts_early_init
> +#endif
> +
>  #ifndef CONFIG_XIP
> /*
>  * Pick hart to initialize global data and run U-Boot. The other harts
> --
> 2.31.0


Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each core

2021-04-13 Thread Rick Chen
Hi Sean,

> On 4/13/21 12:12 AM, Rick Chen wrote:
> > Hi Sean
> >
> >> On 4/12/21 10:39 PM, Rick Chen wrote:
> >>> Hi Green,
> >>>
> >>>> From: Green Wan [mailto:green@sifive.com]
> >>>> Sent: Monday, April 12, 2021 10:33 AM
> >>>> To: Sean Anderson
> >>>> Cc: Rick Chen; Rick Jian-Zhi Chen(陳建志); Bin Meng; U-Boot Mailing List; 
> >>>> Paul Walmsley; Pragnesh Patel; Simon Glass; Atish Patra; Leo Yu-Chi 
> >>>> Liang(梁育齊); Brad Kim
> >>>> Subject: Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init 
> >>>> each core
> >>>>
> >>>> Hi Bin and Sean,
> >>>>
> >>>> While we keep the consistency of cache control discussion going, later
> >>>> today I'd like to send the v5 patch which is not directly relevant to
> >>>> cache control.
> >>>
> >>> I will prefer not to mix cache control issue into this patch.
> >>> Like I said, this callback is a init for all harts before lottery.
> >>
> >> Yes, but enabling caches is a very similar thing (this proposal even
> >> uses it to turn on caches, among other things). At the moment we have
> >> two calls to enable caches at almost the same time as what Green
> >> proposes. These calls only translate into work done on one platform. I
> >> think having one call (or perhaps two) for this purpose would help
> >> reduce codepaths across different platforms going forward.
> >>
> >
> > Maybe we can add two callbacks (early_lottery_init and
> > late_lottery_init) before and after lottery individually for all
> > scenarios.
>
> Yes, that is a possibility. But do we actually need that flexibility?
> This comes back around to my original question: why does ax25 disable
> cache on all harts before jumping to Linux?

clarify your above expressions:
only disable main hart (not all harts) before jumping to Linux.

Why you think it is a question to disable cache before jumping to Linux.
You can find many same cache flow in cleanup_before_linux of /arch/arm
Are they all the questions ?

Thanks,
Rick

>
> And of course, does this actually need to be done before the lottery?
>
> --Sean
>


Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each core

2021-04-12 Thread Rick Chen
Hi Sean

> On 4/12/21 10:39 PM, Rick Chen wrote:
> > Hi Green,
> >
> >> From: Green Wan [mailto:green@sifive.com]
> >> Sent: Monday, April 12, 2021 10:33 AM
> >> To: Sean Anderson
> >> Cc: Rick Chen; Rick Jian-Zhi Chen(陳建志); Bin Meng; U-Boot Mailing List; 
> >> Paul Walmsley; Pragnesh Patel; Simon Glass; Atish Patra; Leo Yu-Chi 
> >> Liang(梁育齊); Brad Kim
> >> Subject: Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init 
> >> each core
> >>
> >> Hi Bin and Sean,
> >>
> >> While we keep the consistency of cache control discussion going, later
> >> today I'd like to send the v5 patch which is not directly relevant to
> >> cache control.
> >
> > I will prefer not to mix cache control issue into this patch.
> > Like I said, this callback is a init for all harts before lottery.
>
> Yes, but enabling caches is a very similar thing (this proposal even
> uses it to turn on caches, among other things). At the moment we have
> two calls to enable caches at almost the same time as what Green
> proposes. These calls only translate into work done on one platform. I
> think having one call (or perhaps two) for this purpose would help
> reduce codepaths across different platforms going forward.
>

Maybe we can add two callbacks (early_lottery_init and
late_lottery_init) before and after lottery individually for all
scenarios.

Thanks,
Rick

> --Sean
>
> >
> > Thanks,
> > Rick
> >
> >>
> >> Regards,
> >> Green
> >>
> >> On Sun, Apr 11, 2021 at 11:43 PM Sean Anderson  wrote:
> >>>
> >>> On 4/9/21 12:05 PM, Green Wan wrote:
> >>>> Hi folks,
> >>>>
> >>>> Correct me if I'm wrong, like Rick mentioned, i/dcache
> >>>> enable/disable() is only called on the main hart. Right now the dummy
> >>>> i/dcache enable/disable are empty and shared among all riscv CPU. The
> >>>> ax25 is the only one that has its own implementation for now.
> >>>
> >>> Right, so why are caches are disabled on all harts before booting Linux
> >>> on ax25? Is there a requirement for this on ax25 which that other
> >>> platforms (which have always-on caches like k210, or which have
> >>> non-disableable caches like fuX40) do not have?
> >>>
> >>> --Sean
> >>>
> >>>>
> >>>> FU540/FU740 also leverages the dummy i/dcache enable/disable()
> >>>> functions (only main hart calls them). L2 cache on FU540/FU740 is
> >>>> enabled as SRAM purpose. And according to the HW design behavior, once
> >>>> L2 is enabled, it can't be disabled unless doing a reset.[1] The Linux
> >>>> L2$ driver will handle that according to the configuration of L2
> >>>> registers.
> >>>>
> >>>> [1] https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> >>>>
> >>>> Thanks,
> >>>>
> >>>> On Fri, Apr 9, 2021 at 9:18 PM Sean Anderson  wrote:
> >>>>>
> >>>>> On 4/9/21 4:16 AM, Rick Chen wrote:
> >>>>>> Hi Sean ,Bin
> >>>>>>
> >>>>>>> From: Bin Meng [mailto:bmeng...@gmail.com]
> >>>>>>> Sent: Tuesday, April 06, 2021 5:16 PM
> >>>>>>> To: Sean Anderson
> >>>>>>> Cc: Green Wan; Rick Jian-Zhi Chen(陳建志); Paul Walmsley; Pragnesh 
> >>>>>>> Patel; Bin Meng; Simon Glass; Atish Patra; Leo Yu-Chi Liang(梁育齊); 
> >>>>>>> Brad Kim; U-Boot Mailing List
> >>>>>>> Subject: Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to 
> >>>>>>> init each core
> >>>>>>>
> >>>>>>> On Sat, Apr 3, 2021 at 6:53 AM Sean Anderson  
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On 3/30/21 1:26 AM, Green Wan wrote:
> >>>>>>>>> Add a callback riscv_hart_early_init() to ./arch/riscv/cpu/start.S 
> >>>>>>>>> to
> >>>>>>>>> allow different riscv hart perform setup code for each hart as early
> >>>>>>>>> as possible. Since all the harts enter the callback, they must be 
> >>>>>>>>> able
> >>>>>>>>> to run the same setup.
> >>>>>>>>>
>

Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each core

2021-04-12 Thread Rick Chen
Hi Green,

> From: Green Wan [mailto:green@sifive.com]
> Sent: Tuesday, March 30, 2021 1:27 PM
> Cc: Green Wan; Rick Jian-Zhi Chen(陳建志); Paul Walmsley; Pragnesh Patel; Sean 
> Anderson; Bin Meng; Simon Glass; Atish Patra; Leo Yu-Chi Liang(梁育齊); Brad 
> Kim; u-boot@lists.denx.de
> Subject: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each core
>
> Add a callback riscv_hart_early_init() to ./arch/riscv/cpu/start.S to
> allow different riscv hart perform setup code for each hart as early
> as possible. Since all the harts enter the callback, they must be able
> to run the same setup.
>
> Signed-off-by: Green Wan 
> ---
>  arch/riscv/cpu/cpu.c   | 15 +++
>  arch/riscv/cpu/start.S | 14 ++
>  2 files changed, 29 insertions(+)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index 85592f5bee..1652e51137 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -140,3 +140,18 @@ int arch_early_init_r(void)
>  {
> return riscv_cpu_probe();
>  }
> +
> +/**
> + * riscv_hart_early_init() - A dummy function called by

Maybe you can rename as harts_early_init(), riscv seems to be extra prefix here.
And dummy sounds like a negative word, it will be better to describe
it as a callback for customize CSR features ...etc.

> + * ./arch/riscv/cpu/start.S to allow to disable/enable features of each core.
> + * For example, turn on or off the functional block of CPU harts.
> + *
> + * In a multi-core system, this function must not access shared resources.
> + *
> + * Any access to such resources would probably be better done with
> + * available_harts_lock held. However, I doubt that any such access will be
> + * necessary.
> + */
> +__weak void riscv_hart_early_init(void)
> +{
> +}
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index 8589509e01..ab73008f23 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -117,6 +117,20 @@ call_board_init_f_0:
> mv  sp, a0
>  #endif
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> +   /*
> +* Jump to riscv_hart_early_init() to perform init for each core. Not
> +* expect to access gd since gd is not initialized. All operations in 
> the
> +* function should affect core itself only. In multi-core system, any 
> access
> +* to common resource or registers outside core should be avoided or 
> need a
> +* protection for multicore.

You can emphasize this init is a callback for customize CSR settings
for all harts simply.
Any memory access is prohibited here.

> +*
> +* A dummy implementation is provided in ./arch/riscv/cpu/cpu.c.

This description for path is not necessary here.

Thanks,
Rick

> +*/
> +call_riscv_hart_early_init:
> +   jal riscv_hart_early_init
> +#endif
> +
>  #ifndef CONFIG_XIP
> /*
>  * Pick hart to initialize global data and run U-Boot. The other harts
> --
> 2.31.0


Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each core

2021-04-12 Thread Rick Chen
Hi Green,

> From: Green Wan [mailto:green@sifive.com]
> Sent: Monday, April 12, 2021 10:33 AM
> To: Sean Anderson
> Cc: Rick Chen; Rick Jian-Zhi Chen(陳建志); Bin Meng; U-Boot Mailing List; Paul 
> Walmsley; Pragnesh Patel; Simon Glass; Atish Patra; Leo Yu-Chi Liang(梁育齊); 
> Brad Kim
> Subject: Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each 
> core
>
> Hi Bin and Sean,
>
> While we keep the consistency of cache control discussion going, later
> today I'd like to send the v5 patch which is not directly relevant to
> cache control.

I will prefer not to mix cache control issue into this patch.
Like I said, this callback is a init for all harts before lottery.

Thanks,
Rick

>
> Regards,
> Green
>
> On Sun, Apr 11, 2021 at 11:43 PM Sean Anderson  wrote:
> >
> > On 4/9/21 12:05 PM, Green Wan wrote:
> > > Hi folks,
> > >
> > > Correct me if I'm wrong, like Rick mentioned, i/dcache
> > > enable/disable() is only called on the main hart. Right now the dummy
> > > i/dcache enable/disable are empty and shared among all riscv CPU. The
> > > ax25 is the only one that has its own implementation for now.
> >
> > Right, so why are caches are disabled on all harts before booting Linux
> > on ax25? Is there a requirement for this on ax25 which that other
> > platforms (which have always-on caches like k210, or which have
> > non-disableable caches like fuX40) do not have?
> >
> > --Sean
> >
> > >
> > > FU540/FU740 also leverages the dummy i/dcache enable/disable()
> > > functions (only main hart calls them). L2 cache on FU540/FU740 is
> > > enabled as SRAM purpose. And according to the HW design behavior, once
> > > L2 is enabled, it can't be disabled unless doing a reset.[1] The Linux
> > > L2$ driver will handle that according to the configuration of L2
> > > registers.
> > >
> > > [1] https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> > >
> > > Thanks,
> > >
> > > On Fri, Apr 9, 2021 at 9:18 PM Sean Anderson  wrote:
> > >>
> > >> On 4/9/21 4:16 AM, Rick Chen wrote:
> > >>> Hi Sean ,Bin
> > >>>
> > >>>> From: Bin Meng [mailto:bmeng...@gmail.com]
> > >>>> Sent: Tuesday, April 06, 2021 5:16 PM
> > >>>> To: Sean Anderson
> > >>>> Cc: Green Wan; Rick Jian-Zhi Chen(陳建志); Paul Walmsley; Pragnesh Patel; 
> > >>>> Bin Meng; Simon Glass; Atish Patra; Leo Yu-Chi Liang(梁育齊); Brad Kim; 
> > >>>> U-Boot Mailing List
> > >>>> Subject: Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init 
> > >>>> each core
> > >>>>
> > >>>> On Sat, Apr 3, 2021 at 6:53 AM Sean Anderson  wrote:
> > >>>>>
> > >>>>> On 3/30/21 1:26 AM, Green Wan wrote:
> > >>>>>> Add a callback riscv_hart_early_init() to ./arch/riscv/cpu/start.S to
> > >>>>>> allow different riscv hart perform setup code for each hart as early
> > >>>>>> as possible. Since all the harts enter the callback, they must be 
> > >>>>>> able
> > >>>>>> to run the same setup.
> > >>>>>>
> > >>>>>> Signed-off-by: Green Wan 
> > >>>>>> ---
> > >>>>>> arch/riscv/cpu/cpu.c   | 15 +++
> > >>>>>> arch/riscv/cpu/start.S | 14 ++
> > >>>>>> 2 files changed, 29 insertions(+)
> > >>>>>>
> > >>>>>> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > >>>>>> index 85592f5bee..1652e51137 100644
> > >>>>>> --- a/arch/riscv/cpu/cpu.c
> > >>>>>> +++ b/arch/riscv/cpu/cpu.c
> > >>>>>> @@ -140,3 +140,18 @@ int arch_early_init_r(void)
> > >>>>>> {
> > >>>>>> return riscv_cpu_probe();
> > >>>>>> }
> > >>>>>> +
> > >>>>>> +/**
> > >>>>>> + * riscv_hart_early_init() - A dummy function called by
> > >>>>>> + * ./arch/riscv/cpu/start.S to allow to disable/enable features of 
> > >>>>>> each core.
> > >>>>>> + * For example, turn on or off the functional block of CPU harts.
> > >>>>>> + *
> > >>>>>> + * In a mu

Re: [PATCH 1/1] cmd/exception: support ebreak exception on RISC-V

2021-04-12 Thread Rick Chen
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Friday, April 09, 2021 6:48 PM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] cmd/exception: support ebreak exception on RISC-V
>
> The ebreak instruction should generate a breakpoint exception.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/riscv/exception.c   | 10 ++
>  doc/usage/exception.rst |  3 +++
>  2 files changed, 13 insertions(+)

Reviewed-by: Rick Chen 


Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each core

2021-04-09 Thread Rick Chen
Hi Sean ,Bin

> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Tuesday, April 06, 2021 5:16 PM
> To: Sean Anderson
> Cc: Green Wan; Rick Jian-Zhi Chen(陳建志); Paul Walmsley; Pragnesh Patel; Bin 
> Meng; Simon Glass; Atish Patra; Leo Yu-Chi Liang(梁育齊); Brad Kim; U-Boot 
> Mailing List
> Subject: Re: [RFC PATCH v4 1/2] arch: riscv: cpu: Add callback to init each 
> core
>
> On Sat, Apr 3, 2021 at 6:53 AM Sean Anderson  wrote:
> >
> > On 3/30/21 1:26 AM, Green Wan wrote:
> > > Add a callback riscv_hart_early_init() to ./arch/riscv/cpu/start.S to
> > > allow different riscv hart perform setup code for each hart as early
> > > as possible. Since all the harts enter the callback, they must be able
> > > to run the same setup.
> > >
> > > Signed-off-by: Green Wan 
> > > ---
> > >   arch/riscv/cpu/cpu.c   | 15 +++
> > >   arch/riscv/cpu/start.S | 14 ++
> > >   2 files changed, 29 insertions(+)
> > >
> > > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > > index 85592f5bee..1652e51137 100644
> > > --- a/arch/riscv/cpu/cpu.c
> > > +++ b/arch/riscv/cpu/cpu.c
> > > @@ -140,3 +140,18 @@ int arch_early_init_r(void)
> > >   {
> > >   return riscv_cpu_probe();
> > >   }
> > > +
> > > +/**
> > > + * riscv_hart_early_init() - A dummy function called by
> > > + * ./arch/riscv/cpu/start.S to allow to disable/enable features of each 
> > > core.
> > > + * For example, turn on or off the functional block of CPU harts.
> > > + *
> > > + * In a multi-core system, this function must not access shared 
> > > resources.
> > > + *
> > > + * Any access to such resources would probably be better done with
> > > + * available_harts_lock held. However, I doubt that any such access will 
> > > be
> > > + * necessary.
> > > + */
> > > +__weak void riscv_hart_early_init(void)
> > > +{
> > > +}
> > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > > index 8589509e01..ab73008f23 100644
> > > --- a/arch/riscv/cpu/start.S
> > > +++ b/arch/riscv/cpu/start.S
> > > @@ -117,6 +117,20 @@ call_board_init_f_0:
> > >   mv  sp, a0
> > >   #endif
> > >
> > > +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> > > + /*
> > > +  * Jump to riscv_hart_early_init() to perform init for each core. 
> > > Not
> > > +  * expect to access gd since gd is not initialized. All operations 
> > > in the
> > > +  * function should affect core itself only. In multi-core system, 
> > > any access
> > > +  * to common resource or registers outside core should be avoided 
> > > or need a
> > > +  * protection for multicore.
> > > +  *
> > > +  * A dummy implementation is provided in ./arch/riscv/cpu/cpu.c.
> > > +  */
> > > +call_riscv_hart_early_init:
> > > + jal riscv_hart_early_init
> > > +#endif
> > > +
> >
> > I wonder if we could move the calls to icache_enable and dcache_enable
> > into this function. Though this would have the consequence of enabling
> > caches on all harts for CPUs which previously only enabled them for the
> > boot hart. I think ax25 is the only CPU which currently does this. Bin,
> > would this be an issue?

No, they are functions shall be called in different stage about lottery.
riscv_hart_early_init() is called before lottery for all harts.
It shall not move icache_enable() and dcache_enable() into
riscv_hart_early_init(), they are belong to the stage after lottery
only for main hart.

>
> Good catch. I believe AX25 cache support is currently somehow broken?

No, AX25 cache support is currently work well.

>
> I think Rick has to comment on this as he added this via commit:
>
> commit 52923c6db7f00e0197ec894c8c1bb8a7681974bb
> Author: Rick Chen 
> Date:   Wed Nov 7 09:34:06 2018 +0800
>
> riscv: cache: Implement i/dcache [status, enable, disable]
>
> AndeStar RISC-V(V5) provide mcache_ctl register which
> can configure I/D cache as enabled or disabled.
>
> This CSR will be encapsulated by CONFIG_RISCV_NDS.
> If you want to configure cache on AndeStar V5
> AE350 platform. YOu can enable [*] AndeStar V5 ISA support
> by make menuconfig.
>
> This approach also provide the expansion when the
> vender specific features are going to join in.
>
> Signed-off-by: Rick Chen 
> Cc: Greentime Hu 
>
> The original commit has i/d cache enabled on all harts. But it was
> later moved to boot hart due to SMP support.

Not all harts will enable i/d cache during startup currently, only
main hart will enable i/d cache here.
So only main hart will disable i/d cache in cleanup_before_linux().

Thanks,
Rick

>
> However on the cleanup side, it looks only the boot hart calls i/d
> cache disable?

>
> See arch/riscv/cpu/ax25/cpu.c:: cleanup_before_linux()
>
> Regards,
> Bin


Re: [PATCH v3 2/2] riscv: timer: Add support for an early timer

2021-01-11 Thread Rick Chen
Hi Pragnesh

> > From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> > Sent: Sunday, January 10, 2021 8:43 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; Sean Anderson; Simon 
> > Glass
> > Subject: [PATCH v3 2/2] riscv: timer: Add support for an early timer
> >
> > Added support for timer_early_get_count() and timer_early_get_rate()
> > This is mostly useful in tracing.
> >
> > Signed-off-by: Pragnesh Patel 
> > ---
> >
> > Changes in v3:
> > - Add IS_ENABLED(CONFIG_TIMER_EARLY) for timer_early_get_rate()
> >   and timer_early_get_count() functions.
>
> Reviewed-by: Rick Chen 

I am trying to merge to mainline, but it conflict with master.
Please rebase again,

Applying: trace: select TIMER_EARLY to avoid infinite recursion
Applying: riscv: timer: Add support for an early timer
error: patch failed: drivers/timer/andes_plmt_timer.c:17
error: drivers/timer/andes_plmt_timer.c: patch does not apply
error: patch failed: drivers/timer/sifive_clint_timer.c:14
error: drivers/timer/sifive_clint_timer.c: patch does not apply
Patch failed at 0002 riscv: timer: Add support for an early timer
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


Re: [PATCH v7 7/7] doc: board: Add Microchip MPFS Icicle Kit doc

2021-01-10 Thread Rick Chen
Hi Padmarao

> From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> Sent: Tuesday, December 22, 2020 9:12 PM
> To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志); 
> anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com; 
> lu...@denx.de; atish.pa...@wdc.com
> Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com; 
> ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com; 
> conor.doo...@microchip.com; Padmarao Begari
> Subject: [PATCH v7 7/7] doc: board: Add Microchip MPFS Icicle Kit doc
>
> This doc describes the procedure to build, flash and
> boot Linux using U-boot on Microchip MPFS Icicle Kit.
>
> Signed-off-by: Padmarao Begari 
> Reviewed-by: Anup Patel 
> Reviewed-by: Bin Meng 
> ---
>  doc/board/index.rst |   1 +
>  doc/board/microchip/index.rst   |   9 +
>  doc/board/microchip/mpfs_icicle.rst | 816 
>  3 files changed, 826 insertions(+)
>  create mode 100644 doc/board/microchip/index.rst
>  create mode 100644 doc/board/microchip/mpfs_icicle.rst

Please check the CI failure item as below:
https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/199014

/builds/u-boot/custodians/u-boot-riscv/doc/board/microchip/mpfs_icicle.rst:99:Unexpected
indentation.
199make[1]: *** [htmldocs] Error 1
200make: *** [htmldocs] Error 2
201doc/Makefile:69: recipe for target 'htmldocs' failed
202Makefile:2167: recipe for target 'htmldocs' failed

Thanks,
Rick


Re: [PATCH v3 2/2] riscv: timer: Add support for an early timer

2021-01-10 Thread Rick Chen
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Sunday, January 10, 2021 8:43 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; Sean Anderson; Simon Glass
> Subject: [PATCH v3 2/2] riscv: timer: Add support for an early timer
>
> Added support for timer_early_get_count() and timer_early_get_rate()
> This is mostly useful in tracing.
>
> Signed-off-by: Pragnesh Patel 
> ---
>
> Changes in v3:
> - Add IS_ENABLED(CONFIG_TIMER_EARLY) for timer_early_get_rate()
>   and timer_early_get_count() functions.

Reviewed-by: Rick Chen 


Re: [PATCH v2 2/2] riscv: timer: Add support for an early timer

2021-01-05 Thread Rick Chen
Hi Pragnesh

> On Tue, Jan 5, 2021 at 7:12 AM Sean Anderson  wrote:
> >
> > On 1/4/21 8:37 PM, Rick Chen wrote:
> > > Hi Pragnesh
> > >
> > >>> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> > >>> Sent: Tuesday, December 22, 2020 2:23 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.pa...@openfive.com; Pragnesh Patel; 
> > >>> Palmer Dabbelt; Sean Anderson; Claudiu Beznea; Simon Glass
> > >>> Subject: [PATCH v2 2/2] riscv: timer: Add support for an early timer
> > >>>
> > >>> Added support for timer_early_get_count() and timer_early_get_rate()
> > >>> This is mostly useful in tracing.
> > >>>
> > >>> Signed-off-by: Pragnesh Patel 
> > >>> ---
> > >>>
> > >>> Changes in v2:
> > >>> - make u-boot compile for qemu (include/configs/qemu-riscv.h)
> > >>>
> > >>>   drivers/timer/andes_plmt_timer.c   | 21 -
> > >>>   drivers/timer/riscv_timer.c| 21 -
> > >>>   drivers/timer/sifive_clint_timer.c | 21 -
> > >>>   include/configs/ax25-ae350.h   |  5 +
> > >>>   include/configs/qemu-riscv.h   |  5 +
> > >>>   include/configs/sifive-fu540.h |  5 +
> > >>>   6 files changed, 75 insertions(+), 3 deletions(-)
> > >>
> > >> Reviewed-by: Rick Chen 
> > >
> > > Please check about the CI failure item:
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/196578
> >
> > 404 for me (though I suspect it's really a 403).
>
> 404 for me also.
>

Followings are the errors from CI:

...
...
+
562 riscv: + microchip_mpfs_icicle
563+drivers/timer/sifive_clint_timer.c: In function 'timer_early_get_rate':
564+drivers/timer/sifive_clint_timer.c:28:9: error:
'RISCV_MMODE_TIMER_FREQ' undeclared (first use in this function)
565+ 28 | return RISCV_MMODE_TIMER_FREQ;
566+ | ^~
567+drivers/timer/sifive_clint_timer.c:28:9: note: each undeclared
identifier is reported only once for each function it appears in
568+drivers/timer/sifive_clint_timer.c: In function 'timer_early_get_count':
569+drivers/timer/sifive_clint_timer.c:37:41: error:
'RISCV_MMODE_TIMERBASE' undeclared (first use in this function)
570+ 37 | return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
571+ | ^
572+drivers/timer/sifive_clint_timer.c:15:36: note: in definition of
macro 'MTIME_REG'
573+ 15 | #define MTIME_REG(base) ((ulong)(base) + 0xbff8)
574+ | ^~~~
575+drivers/timer/sifive_clint_timer.c:29:1: error: control reaches
end of non-void function [-Werror=return-type]
576+ 29 | }
577+ | ^
578+drivers/timer/sifive_clint_timer.c:38:1: error: control reaches
end of non-void function [-Werror=return-type]
579+ 38 | }
580+cc1: all warnings being treated as errors
581+make[3]: *** [drivers/timer/sifive_clint_timer.o] Error 1
582+make[2]: *** [drivers/timer] Error 2
583+make[1]: *** [drivers] Error 2
584+make: *** [sub-make] Error 2
585 riscv: + sipeed_maix_bitm
586+drivers/timer/sifive_clint_timer.c: In function 'timer_early_get_rate':
587+drivers/timer/sifive_clint_timer.c:28:9: error:
'RISCV_MMODE_TIMER_FREQ' undeclared (first use in this function)
588+ 28 | return RISCV_MMODE_TIMER_FREQ;
589+ | ^~
590+drivers/timer/sifive_clint_timer.c:28:9: note: each undeclared
identifier is reported only once for each function it appears in
591+drivers/timer/sifive_clint_timer.c: In function 'timer_early_get_count':
592+drivers/timer/sifive_clint_timer.c:37:41: error:
'RISCV_MMODE_TIMERBASE' undeclared (first use in this function)
593+ 37 | return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
594+ | ^
595+drivers/timer/sifive_clint_timer.c:15:36: note: in definition of
macro 'MTIME_REG'
596+ 15 | #define MTIME_REG(base) ((ulong)(base) + 0xbff8)
597+ | ^~~~
598+drivers/timer/sifive_clint_timer.c:29:1: error: control reaches
end of non-void function [-Werror=return-type]
599+ 29 | }
600+ | ^
601+drivers/timer/sifive_clint_timer.c:38:1: error: control reaches
end of non-void function [-Werror=return-type]
602+ 38 | }
603+cc1: all warnings being treated as errors
604+make[3]: *** [drivers/timer/sifive_clint_timer.o] Error 1
605+make[2]: *** [drivers/timer] Error 2
606+make[1]: *** [drivers] Error 2
607+make: *** [sub-make] Error 2
608 riscv: + sipeed_maix_smode
609+driver

Re: [PATCH v7 2/7] net: macb: Add DMA 64-bit address support for macb

2021-01-04 Thread Rick Chen
Hi Joe

> From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> Sent: Tuesday, December 22, 2020 9:12 PM
> To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志); 
> anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com; 
> lu...@denx.de; atish.pa...@wdc.com
> Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com; 
> ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com; 
> conor.doo...@microchip.com; Padmarao Begari
> Subject: [PATCH v7 2/7] net: macb: Add DMA 64-bit address support for macb
>
> Enable 32-bit or 64-bit DMA in the macb driver based on the macb
> hardware compatibility and it is configured with structure macb_config
> in the driver.
>
> The Microchip PolarFire SoC Memory Protection Unit(MPU) gives the 64-bit
> DMA access with the GEM, the MPU transactions on the AXI bus is 64-bit
> not 32-bit So 64-bit DMA is enabled for the Microchip PolarFire SoC GEM.
>
> Signed-off-by: Padmarao Begari 
> Reviewed-by: Anup Patel 
> Tested-by: Bin Meng 
> ---
>  drivers/net/macb.c | 131 +++--
>  drivers/net/macb.h |   6 +++
>  2 files changed, 120 insertions(+), 17 deletions(-)
>

Do you have any comment with this series about net macb driver.
If you are ok with it, I will pull via riscv tree.

Thanks,
Rick

> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index b80a259ff7..626ee49227 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -83,7 +83,16 @@ struct macb_dma_desc {
> u32 ctrl;
>  };
>
> -#define DMA_DESC_BYTES(n)  (n * sizeof(struct macb_dma_desc))
> +struct macb_dma_desc_64 {
> +   u32 addrh;
> +   u32 unused;
> +};
> +
> +#define HW_DMA_CAP_32B 0
> +#define HW_DMA_CAP_64B 1
> +
> +#define DMA_DESC_SIZE  16
> +#define DMA_DESC_BYTES(n)  ((n) * DMA_DESC_SIZE)
>  #define MACB_TX_DMA_DESC_SIZE  (DMA_DESC_BYTES(MACB_TX_RING_SIZE))
>  #define MACB_RX_DMA_DESC_SIZE  (DMA_DESC_BYTES(MACB_RX_RING_SIZE))
>  #define MACB_TX_DUMMY_DMA_DESC_SIZE(DMA_DESC_BYTES(1))
> @@ -137,6 +146,7 @@ struct macb_device {
>
>  struct macb_config {
> unsigned intdma_burst_length;
> +   unsigned inthw_dma_cap;
>
> int (*clk_init)(struct udevice *dev, ulong rate);
>  };
> @@ -307,6 +317,24 @@ static inline void macb_invalidate_rx_buffer(struct 
> macb_device *macb)
>
>  #if defined(CONFIG_CMD_NET)
>
> +static struct macb_dma_desc_64 *macb_64b_desc(struct macb_dma_desc *desc)
> +{
> +   return (struct macb_dma_desc_64 *)((void *)desc
> +   + sizeof(struct macb_dma_desc));
> +}
> +
> +static void macb_set_addr(struct macb_device *macb, struct macb_dma_desc 
> *desc,
> + ulong addr)
> +{
> +   struct macb_dma_desc_64 *desc_64;
> +
> +   if (macb->config->hw_dma_cap & HW_DMA_CAP_64B) {
> +   desc_64 = macb_64b_desc(desc);
> +   desc_64->addrh = upper_32_bits(addr);
> +   }
> +   desc->addr = lower_32_bits(addr);
> +}
> +
>  static int _macb_send(struct macb_device *macb, const char *name, void 
> *packet,
>   int length)
>  {
> @@ -325,8 +353,12 @@ static int _macb_send(struct macb_device *macb, const 
> char *name, void *packet,
> macb->tx_head++;
> }
>
> +   if (macb->config->hw_dma_cap & HW_DMA_CAP_64B)
> +   tx_head = tx_head * 2;
> +
> macb->tx_ring[tx_head].ctrl = ctrl;
> -   macb->tx_ring[tx_head].addr = paddr;
> +   macb_set_addr(macb, >tx_ring[tx_head], paddr);
> +
> barrier();
> macb_flush_ring_desc(macb, TX);
> macb_writel(macb, NCR, MACB_BIT(TE) | MACB_BIT(RE) | 
> MACB_BIT(TSTART));
> @@ -363,19 +395,28 @@ static void reclaim_rx_buffers(struct macb_device *macb,
>unsigned int new_tail)
>  {
> unsigned int i;
> +   unsigned int count;
>
> i = macb->rx_tail;
>
> macb_invalidate_ring_desc(macb, RX);
> while (i > new_tail) {
> -   macb->rx_ring[i].addr &= ~MACB_BIT(RX_USED);
> +   if (macb->config->hw_dma_cap & HW_DMA_CAP_64B)
> +   count = i * 2;
> +   else
> +   count = i;
> +   macb->rx_ring[count].addr &= ~MACB_BIT(RX_USED);
> i++;
> if (i > MACB_RX_RING_SIZE)
> i = 0;
> }
>
> while (i < new_tail) {
> -   macb->rx_ring[i].addr &= ~MACB_BIT(RX_USED);
> +   if (macb->config->hw_dma_cap & HW_DMA_CAP_64B)
> +   count = i * 2;
> +   else
> +   count = i;
> +   macb->rx_ring[count].addr &= ~MACB_BIT(RX_USED);
> i++;
> }
>
> @@ -390,16 +431,25 @@ static int _macb_recv(struct macb_device *macb, uchar 
> **packetp)
> void *buffer;
> int length;
> u32 status;
> +   u8 

Re: [PATCH v2 2/2] riscv: timer: Add support for an early timer

2021-01-04 Thread Rick Chen
Hi Pragnesh

> > From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> > Sent: Tuesday, December 22, 2020 2:23 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.pa...@openfive.com; Pragnesh Patel; Palmer 
> > Dabbelt; Sean Anderson; Claudiu Beznea; Simon Glass
> > Subject: [PATCH v2 2/2] riscv: timer: Add support for an early timer
> >
> > Added support for timer_early_get_count() and timer_early_get_rate()
> > This is mostly useful in tracing.
> >
> > Signed-off-by: Pragnesh Patel 
> > ---
> >
> > Changes in v2:
> > - make u-boot compile for qemu (include/configs/qemu-riscv.h)
> >
> >  drivers/timer/andes_plmt_timer.c   | 21 -
> >  drivers/timer/riscv_timer.c| 21 -
> >  drivers/timer/sifive_clint_timer.c | 21 -
> >  include/configs/ax25-ae350.h   |  5 +
> >  include/configs/qemu-riscv.h   |  5 +
> >  include/configs/sifive-fu540.h |  5 +
> >  6 files changed, 75 insertions(+), 3 deletions(-)
>
> Reviewed-by: Rick Chen 

Please check about the CI failure item:
https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/196578

Thanks,
Rick


Re: [PATCH v7 1/7] riscv: Add DMA 64-bit address support

2021-01-04 Thread Rick Chen
> From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> Sent: Tuesday, December 22, 2020 9:12 PM
> To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志); 
> anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com; 
> lu...@denx.de; atish.pa...@wdc.com
> Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com; 
> ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com; 
> conor.doo...@microchip.com; Padmarao Begari
> Subject: [PATCH v7 1/7] riscv: Add DMA 64-bit address support
>
> dma_addr_t holds any valid DMA address. If the DMA API only uses 32/64-bit
> addresses, dma_addr_t need only be 32/64 bits wide.
>
> Signed-off-by: Padmarao Begari 
> Reviewed-by: Anup Patel 
> Reviewed-by: Bin Meng 
> ---
>  arch/riscv/Kconfig | 4 
>  arch/riscv/include/asm/types.h | 4 
>  2 files changed, 8 insertions(+)
>

Reviewed-by: Rick Chen 


Re: [PATCH] doc: qemu-riscv: Fix opensbi build instructions

2020-12-29 Thread Rick Chen
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Atish Patra
> Sent: Wednesday, December 23, 2020 3:50 AM
> To: U-Boot Mailing List
> Cc: Atish Patra; Anup Patel; Bin Meng; Heinrich Schuchardt; Jagan Teki; Marek 
> Vasut; Simon Goldschmidt; David Abdurachmanov; Tom Rini
> Subject: [PATCH] doc: qemu-riscv: Fix opensbi build instructions
>
> Latest opensbi uses generic platform for Qemu. Update the build
> instructions.
>
> Signed-off-by: Atish Patra 
> ---
>  doc/board/emulation/qemu-riscv.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Rick Chen 


Re: [PATCH v2 2/2] riscv: timer: Add support for an early timer

2020-12-29 Thread Rick Chen
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Tuesday, December 22, 2020 2:23 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.pa...@openfive.com; Pragnesh Patel; Palmer 
> Dabbelt; Sean Anderson; Claudiu Beznea; Simon Glass
> Subject: [PATCH v2 2/2] riscv: timer: Add support for an early timer
>
> Added support for timer_early_get_count() and timer_early_get_rate()
> This is mostly useful in tracing.
>
> Signed-off-by: Pragnesh Patel 
> ---
>
> Changes in v2:
> - make u-boot compile for qemu (include/configs/qemu-riscv.h)
>
>  drivers/timer/andes_plmt_timer.c   | 21 -
>  drivers/timer/riscv_timer.c| 21 -
>  drivers/timer/sifive_clint_timer.c | 21 -
>  include/configs/ax25-ae350.h   |  5 +
>  include/configs/qemu-riscv.h   |  5 +
>  include/configs/sifive-fu540.h |  5 +
>  6 files changed, 75 insertions(+), 3 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH v2 1/2] trace: select TIMER_EARLY to avoid infinite recursion

2020-12-29 Thread Rick Chen
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Tuesday, December 22, 2020 2:23 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.pa...@openfive.com; Pragnesh Patel; Simon Glass; 
> Stefan Roese; Joao Marcos Costa; Reuben Dowle; Weijie Gao; Marcin 
> Juszkiewicz; Michael Walle; Marek Szyprowski; Keerthy
> Subject: [PATCH v2 1/2] trace: select TIMER_EARLY to avoid infinite recursion
>
> When tracing functions is enabled this adds calls to
> __cyg_profile_func_enter() and __cyg_profile_func_exit() to the traced
> functions.
>
> __cyg_profile_func_enter() and __cyg_profile_func_exit() invoke
> timer_get_us() to record the entry and exit time.
>
> initr_dm() will make gd->dm_root = NULL and gd->timer = NULL, so
> timer_get_us() -> get_ticks() -> dm_timer_init() will lead to an
> indefinite recursion.
>
> So select TIMER_EARLY when tracing got enabled.
>
> Signed-off-by: Pragnesh Patel 
> ---
>
> Changes in v2:
> - new patch
>
>  lib/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rick Chen 


Re: [PATCH v2] riscv: Add support for SPI on Kendryte K210

2020-12-29 Thread Rick Chen
> This enables configs necessary for using SPI. The environment is saved to
> the very end of SPI flash. This is unlikely to be overwritten unless the
> entire flash is reprogrammed.
>
> This also supplies a default bootcommand. It loads an image and device tree
> from the first partition of the MMC. This is a minimal/least effort
> bootcmd, so suggestions (especially in the form of patches) are welcome. I
> didn't set up distro boot because I think it is unlikely that any
> general-purpose linux distros will ever be ported to this board.
>
> Signed-off-by: Sean Anderson 
> ---
> Sorry for the late follow-up Jagen.
>
> This patch was previously part of
> https://patchwork.ozlabs.org/project/uboot/list/?series=208443
>
> Changes in v2:
> - Add CONFIG_HUSH_PARSER to run the bootcmd
>   (In my haste I forgot to commit my changes)
>
>  board/sipeed/maix/Kconfig  |  16 ++
>  configs/sipeed_maix_bitm_defconfig |  11 +
>  doc/board/sipeed/maix.rst  | 319 -
>  include/configs/sipeed-maix.h  |   7 +-
>  4 files changed, 301 insertions(+), 52 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH 1/4] nds32: Remove dead reset_cpu() implementation

2020-12-20 Thread Rick Chen
> From: Harald Seiler [mailto:h...@denx.de]
> Sent: Tuesday, December 15, 2020 11:48 PM
> To: u-boot@lists.denx.de
> Cc: Harald Seiler; Tom Rini; Simon Glass; Rick Jian-Zhi Chen(陳建志)
> Subject: [PATCH 1/4] nds32: Remove dead reset_cpu() implementation
>
> nds32 is one of the only architectures which still have a reset_cpu()
> implementation that makes use of the `addr` parameter.  The rest of
> U-Boot now ignores it and passes 0 everywhere.  It turns out that even
> here, reset_cpu() is no longer referenced anywhere; reset is either not
> implemented (e.g. ae3xx) or realized using a WDT (e.g. ag101).
>
> Remove this left-over implementation in preparation for the removal of
> the `addr` parameter in the entire tree.
>
> Cc: Rick Chen 
> Signed-off-by: Harald Seiler 
> ---
>  arch/nds32/cpu/n1213/start.S | 22 ------
>  1 file changed, 22 deletions(-)

Reviewed-by: Rick Chen 


Re: [PATCH] riscv: timer: Add support for an early timer

2020-12-09 Thread Rick Chen
Hi Pragnesh


> Hi Rick,
>
> [...]
> >>
> >>Following are the configurations, steps and debug logs:
> >>
> >>+++ b/configs/ae350_rv64_defconfig
> >>q+CONFIG_TRACE=y
> >>+CONFIG_TRACE_BUFFER_SIZE=0x0100
> >>+CONFIG_TRACE_CALL_DEPTH_LIMIT=15
> >>+CONFIG_CMD_TRACE=y
> >>+CONFIG_TIMER_EARLY=y
> >>
> >>+++ b/configs/ae350_rv64_spl_defconfig
> >>+CONFIG_TRACE=y
> >>+CONFIG_TRACE_BUFFER_SIZE=0x0100
> >>+CONFIG_TRACE_CALL_DEPTH_LIMIT=15
> >>+CONFIG_CMD_TRACE=y
> >>+CONFIG_TIMER_EARLY=y
> >>
> >> case 1
> >>///
> >>ae350_rv64_defconfig with FTRACE=1, kernel booting is ok
> >> case 1
> >>///
> >>make FTRACE=1 ae350_rv64_defconfig
> >>make FTRACE=1
> >>///
> [...]
> >> case 2
> >>///
> >>ae350_rv64_spl_defconfig with FTRACE=1, kernel booting fail
> >> case 2
> >>///
> >>make FTRACE=1 ae350_rv64_spl_defconfig
> >>make FTRACE=1
> >>///
> >>///
> >>/
> [...]
> >>(hang here)
> >
> >Thanks for the logs.
> >
> >From logs, I can't find where it got stuck. Can you please use gdb to see 
> >where it
> >got stuck ?
> >
> >Meanwhile I will give it a try on HiFive Unleashed board.
>
> On HiFive Unleashed it works fine with tracing.
>
> U-Boot 2021.01-rc2-00049-gb2a38d1d0f (Dec 01 2020 - 15:04:41 +0530)
> CPU:   rv64imafdc
> Model: SiFive HiFive Unleashed A00
> DRAM:  8 GiB
> trace: enabled
> MMC:   spi@1005:mmc@0: 0
> Loading Environment from SPIFlash... SF: Detected is25wp256 with page size 
> 256 Bytes, erase size 4 KiB, total 32 MiB
> *** Warning - bad CRC, using default environment
> In:serial@1001
> Out:   serial@1001
> Err:   serial@1001
> Net:   eth0: ethernet@1009
> Hit any key to stop autoboot:  0
> =>
> => trace stats
> 178,750 function sites
>  25,359,991 function calls
>   1 untracked function calls
>   1,278,927 traced function calls (24358307 dropped due to overflow)
>  19 maximum observed call depth
>  15 call depth limit
>  25,238,922 calls not traced due to depth
> => fatload mmc 0:3 0x8600 hifive-unleashed-a00.dtb
> 7199 bytes read in 27 ms (259.8 KiB/s)
> => fatload mmc 0:3 0x8400 uImage
> 21421212 bytes read in 19496 ms (1 MiB/s)
> => bootm 0x8400 - 0x8600
> ## Booting kernel from Legacy Image at 8400 ...
>Image Name:   Linux
>Image Type:   RISC-V Linux Kernel Image (uncompressed)
>Data Size:21421148 Bytes = 20.4 MiB
>Load Address: 8020
>Entry Point:  8020
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 8600
>Booting using the fdt blob at 0x8600
>Loading Kernel Image
>Using Device Tree in place at 8600, end 86004c1e
> Starting kernel ...(fake run for tracing)
> Starting kernel ...
> [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
> [0.00] Linux version 5.8.0-rc3-16077-g9ebcfadb0610-dirty 
> (pragneshp@sachinj2-OptiPlex-7010) (riscv64-unknown-linux-gnu-gcc 
> (crosstool-NG 1.24.0.37-3f461da) 9.2.0, GNU ld (crosstool-NG 
> 1.24.0.37-3f461da) 2.32) #34 SMP Tue Jul 21 15:56:29 IST 2020
> [0.00] initrd not found or empty - disabling initrd
> [0.00] Zone ranges:
> [0.00]   DMA32[mem 0x8020-0x]
> [0.00]   Normal   [mem 0x0001-0x00027fff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x8020-0x00027fff]
> [0.00] Initmem setup node 0 [mem 
> 0x8020-0x00027fff]
> 
> Welcome to Buildroot
> buildroot login: root
> Password:
>

Please check about the CI failure item Job #95.56
https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/748298543

Thanks,
Rick


Re: [PATCH v5 0/7] Microchip PolarFire SoC support

2020-12-09 Thread Rick Chen
Hi Padmarao

> From: Padmarao Begari [mailto:padmarao.beg...@microchip.com]
> Sent: Thursday, December 03, 2020 4:32 AM
> To: u-boot@lists.denx.de; bmeng...@gmail.com; Rick Jian-Zhi Chen(陳建志); 
> anup.pa...@wdc.com; lukas.a...@aisec.fraunhofer.de; joe.hershber...@ni.com; 
> lu...@denx.de; atish.pa...@wdc.com
> Cc: cyril.j...@microchip.com; lewis.ha...@microchip.com; 
> ivan.grif...@emdalo.com; daire.mcnam...@emdalo.com; 
> conor.doo...@microchip.com; Padmarao Begari
> Subject: [PATCH v5 0/7] Microchip PolarFire SoC support
>
> This patch set adds Microchip PolarFire SoC Icicle Kit support
> to RISC-V U-Boot.
>
> The patches are based upon latest U-Boot tree
> (https://gitlab.denx.de/u-boot/u-boot.git) at commit id
> 80cbd731df50b9ab646940ea862b70bcaff37225
>
> All drivers namely: NS16550 Serial, Microchip clock,
> Cadence eMMC and Cadence MACB Ethernet work fine on actual
> Microchip PolarFire SoC Icicle Kit.
>
> Changes in v5:
> - Replace compatible string "microchip,polarfire-soc" with
>   "microchip,mpfs-icicle-kit" in the device tree
> - Use "mpfs" as identifier in place of "polarfire-soc", "pfsoc"
> - Fix some typos in doc
> - Rename the clock driver files clk_pfsoc_* to mpfs_clk_*
> - Rename pfsoc-clock.h to mpfs-clock.h
>
> Changes in v4:
> - Add dual-license GPL or MIT in the device tree
> - Replace microsemi compatible strings with microchip
> - Add MACB compatible string for Microchip PolarFire SoC ethernet
> - Update MACB driver for 32-bit/64-bit DMA based on compatible string
>
> Changes in v3:
> - Add 'default y if 64BIT' for config DMA_ADDR_T_64BIT
> - Update MACB driver for 32-bit/64-bit DMA based on design config register
> - Add phy-handle in MACB driver to read the phy address from device tree
> - Fix checkpatch warnings in the clock driver
> - Remove fu540 related compatible strings from soc device tree node
> - Move refclk device tree node under /soc device tree node
> - Use local-mac-address instead of mac-address in the device tree
> - Rename device tree to microchip-mpfs-icicle-kit.dts
> - Add U-Boot specific dts microchip-mpfs-icicle-kit-u-boot.dtsi file
> - Drop the imply DMA_ADDR_T_64BIT from board config
> - Fix some typos
> - Update doc with Microchip and Custom boot-flow
>
> Changes in v2:
> - Add clock frequency for the clint device tree node
> - Move peripheral device tree nodes under /soc device tree node
> - Device tree nodes are in order based on the address
> - Enable UART0 for U-Boot logs
> - Update doc for the U-Boot logs are on UART0
> - Move clock and reset index source into patch4
> - Remove "dma_addr_r" type in the macb driver
> - Add lower_32_bits() for 32-bit address in the macb driver
> - Add set_rate() returns the new clock rate in the clock driver
>
> Padmarao Begari (7):
>   riscv: Add DMA 64-bit address support
>   net: macb: Add DMA 64-bit address support for macb
>   net: macb: Add phy address to read it from device tree
>   clk: Add Microchip PolarFire SoC clock driver
>   riscv: dts: Add device tree for Microchip Icicle Kit
>   riscv: Add Microchip MPFS Icicle Kit support
>   doc: board: Add Microchip MPFS Icicle Kit doc
>

Please check about the CI failure item Job #95.59
https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/748298546

Thanks,
Rick

>  arch/riscv/Kconfig|   4 +
>  arch/riscv/dts/Makefile   |   1 +
>  .../dts/microchip-mpfs-icicle-kit-u-boot.dtsi |  14 +
>  arch/riscv/dts/microchip-mpfs-icicle-kit.dts  | 421 +
>  arch/riscv/include/asm/types.h|   4 +
>  board/microchip/mpfs_icicle/Kconfig   |  24 +
>  board/microchip/mpfs_icicle/mpfs_icicle.c |  97 +-
>  configs/microchip_mpfs_icicle_defconfig   |   9 +-
>  doc/board/index.rst   |   1 +
>  doc/board/microchip/index.rst |   9 +
>  doc/board/microchip/mpfs_icicle.rst   | 830 ++
>  drivers/clk/Kconfig   |   1 +
>  drivers/clk/Makefile  |   1 +
>  drivers/clk/microchip/Kconfig |   5 +
>  drivers/clk/microchip/Makefile|   1 +
>  drivers/clk/microchip/mpfs_clk.c  | 127 +++
>  drivers/clk/microchip/mpfs_clk.h  |  19 +
>  drivers/clk/microchip/mpfs_clk_cfg.c  | 134 +++
>  drivers/clk/microchip/mpfs_clk_periph.c   | 173 
>  drivers/net/macb.c| 144 ++-
>  drivers/net/macb.h|   6 +
>  include/configs/microchip_mpfs_icicle.h   |  60 +-
>  .../dt-bindings/clock/microchip,mpfs-clock.h  |  45 +
>  23 files changed, 2068 insertions(+), 62 deletions(-)
>  create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi
>  create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit.dts
>  create mode 100644 doc/board/microchip/index.rst
>  create mode 100644 doc/board/microchip/mpfs_icicle.rst
>  create mode 100644 drivers/clk/microchip/Kconfig
>  create mode 100644 

Re: [PATCH] riscv: timer: Add support for an early timer

2020-11-26 Thread Rick Chen
Hi, Pragnesh

> Hi Rick,
>
> >-Original Message-----
> >From: Rick Chen 
> >Sent: 26 November 2020 14:44
> >To: Pragnesh Patel 
> >Cc: Simon Glass ; U-Boot Mailing List  >b...@lists.denx.de>; Atish Patra ; Bin Meng
> >; Paul Walmsley ( Sifive) ;
> >Anup Patel ; Sagar Kadam
> >; Palmer Dabbelt ; rick
> >; Alan Kao ; Leo Liang
> >
> >Subject: Re: [PATCH] riscv: timer: Add support for an early timer
> >
> >[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 November 2020 13:08
> >> >To: Pragnesh Patel 
> >> >Cc: U-Boot Mailing List ; Atish Patra
> >> >; Bin Meng ; Paul Walmsley (
> >> >Sifive) ; Anup Patel ;
> >> >Sagar Kadam ; Palmer Dabbelt
> >> >; Simon Glass ; rick
> >> >; Alan Kao ; Leo Liang
> >> >
> >> >Subject: Re: [PATCH] riscv: timer: Add support for an early timer
> >> >
> >> >[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: Tuesday, November 17, 2020 7:05 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; Sean Anderson; Simon Glass; Bin Meng
> >> >> Subject: [PATCH] riscv: timer: Add support for an early timer
> >> >>
> >> >> Added support for timer_early_get_count() and
> >> >> timer_early_get_rate() This is mostly useful in tracing.
> >> >>
> >> >> Signed-off-by: Pragnesh Patel 
> >> >> ---
> >> >>  drivers/timer/andes_plmt_timer.c   | 21 -
> >> >>  drivers/timer/riscv_timer.c| 21 -
> >> >>  drivers/timer/sifive_clint_timer.c | 21 -
> >> >>  include/configs/ax25-ae350.h   |  5 +
> >> >>  include/configs/sifive-fu540.h |  5 +
> >> >>  5 files changed, 70 insertions(+), 3 deletions(-)
> >> >>
> >> >
> >> >I verify with ae350_rv64_defconfig
> >> >
> >> >make FTRACE=1 ae350_rv64_defconfig
> >> >make FTRACE=1
> >> >
> >> >and it boot fail as below:
> >> >
> >> >U-Boot 2021.01-rc2-00140-geb42715 (Nov 24 2020 - 15:02:18 +0800)
> >> >
> >> >DRAM:  1 GiB
> >> >trace: enabled
> >> >
> >> >DO you have any suggestions ?
> >>
> >> Please enable CONFIG_TIMER_EARLY=y in ae350_rv64_defconfig
> >>
> >> Actually in v2, I will make TRACE to select TIMER_EARLY like below,
> >>
> >> --- a/lib/Kconfig
> >> +++ b/lib/Kconfig
> >> @@ -210,6 +210,7 @@ config BITREVERSE
> >>  config TRACE
> >> bool "Support for tracing of function calls and timing"
> >> imply CMD_TRACE
> >> +   select TIMER_EARLY
> >>
> >> Let me know if you have any suggestion.
> >
> >OK.
> >
> >After add CONFIG_TIMER_EARLY, U-Boot boots ok.
> >But When I try to booting kernel with FTRACE=1, following are the test stats:
> >
> >ae350_rv64_spl_defconfig without FTRACE=1, kernel booting is ok.
> >ae350_rv64_spl_defconfig with FTRACE=1, kernel booting fail.
> >ae350_rv64_defconfig with FTRACE=1, kernel booting is ok
> >
> >The failure case seems not reasonable.
> >Any suggestions ?
>
> Strange, Can you please tell me which steps you follow and also send some 
> debug logs  if possible.
>

Following are the configurations, steps and debug logs:

+++ b/configs/ae350_rv64_defconfig
q+CONFIG_TRACE=y
+CONFIG_TRACE_BUFFER_SIZE=0x0100
+CONFIG_TRACE_CALL_DEPTH_LIMIT=15
+CONFIG_CMD_TRACE=y
+CONFIG_TIMER_EARLY=y

+++ b/configs/ae350_rv64_spl_defconfig
+CONFIG_TRACE=y
+CONFIG_TRACE_BUFFER_SIZE=0x0100
+CONFIG_TRACE_CALL_DEPTH_LIMIT=15
+CONFIG_CMD_TRACE=y
+CONFIG_TIMER_EARLY=y

 case 1

Re: [PATCH] riscv: timer: Add support for an early timer

2020-11-26 Thread Rick Chen
Hi Pragnesh

> Hi Rick,
>
> >-Original Message-----
> >From: Rick Chen 
> >Sent: 24 November 2020 13:08
> >To: Pragnesh Patel 
> >Cc: U-Boot Mailing List ; Atish Patra
> >; Bin Meng ; Paul Walmsley (
> >Sifive) ; Anup Patel ; Sagar
> >Kadam ; Palmer Dabbelt ;
> >Simon Glass ; rick ; Alan Kao
> >; Leo Liang 
> >Subject: Re: [PATCH] riscv: timer: Add support for an early timer
> >
> >[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: Tuesday, November 17, 2020 7:05 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; Sean
> >> Anderson; Simon Glass; Bin Meng
> >> Subject: [PATCH] riscv: timer: Add support for an early timer
> >>
> >> Added support for timer_early_get_count() and timer_early_get_rate()
> >> This is mostly useful in tracing.
> >>
> >> Signed-off-by: Pragnesh Patel 
> >> ---
> >>  drivers/timer/andes_plmt_timer.c   | 21 -
> >>  drivers/timer/riscv_timer.c| 21 -
> >>  drivers/timer/sifive_clint_timer.c | 21 -
> >>  include/configs/ax25-ae350.h   |  5 +
> >>  include/configs/sifive-fu540.h |  5 +
> >>  5 files changed, 70 insertions(+), 3 deletions(-)
> >>
> >
> >I verify with ae350_rv64_defconfig
> >
> >make FTRACE=1 ae350_rv64_defconfig
> >make FTRACE=1
> >
> >and it boot fail as below:
> >
> >U-Boot 2021.01-rc2-00140-geb42715 (Nov 24 2020 - 15:02:18 +0800)
> >
> >DRAM:  1 GiB
> >trace: enabled
> >
> >DO you have any suggestions ?
>
> Please enable CONFIG_TIMER_EARLY=y in ae350_rv64_defconfig
>
> Actually in v2, I will make TRACE to select TIMER_EARLY like below,
>
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -210,6 +210,7 @@ config BITREVERSE
>  config TRACE
> bool "Support for tracing of function calls and timing"
> imply CMD_TRACE
> +   select TIMER_EARLY
>
> Let me know if you have any suggestion.

OK.

After add CONFIG_TIMER_EARLY, U-Boot boots ok.
But When I try to booting kernel with FTRACE=1, following are the test stats:

ae350_rv64_spl_defconfig without FTRACE=1, kernel booting is ok.
ae350_rv64_spl_defconfig with FTRACE=1, kernel booting fail.
ae350_rv64_defconfig with FTRACE=1, kernel booting is ok

The failure case seems not reasonable.
Any suggestions ?

Thanks,
Rick

>
> >
> >Thanks,
> >Rick
> >
> >> diff --git a/drivers/timer/andes_plmt_timer.c
> >> b/drivers/timer/andes_plmt_timer.c
> >> index cec86718c7..74b795c97a 100644
> >> --- a/drivers/timer/andes_plmt_timer.c
> >> +++ b/drivers/timer/andes_plmt_timer.c
> >> @@ -17,11 +17,30 @@
> >>  /* mtime register */
> >>  #define MTIME_REG(base)((ulong)(base))
> >>
> >> -static u64 andes_plmt_get_count(struct udevice *dev)
> >> +static u64 notrace andes_plmt_get_count(struct udevice *dev)
> >>  {
> >> return readq((void __iomem *)MTIME_REG(dev->priv));  }
> >>
> >> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >> +/**
> >> + * timer_early_get_rate() - Get the timer rate before driver model
> >> +*/ unsigned long notrace timer_early_get_rate(void) {
> >> +   return RISCV_MMODE_TIMER_FREQ; }
> >> +
> >> +/**
> >> + * timer_early_get_count() - Get the timer count before driver model
> >> + *
> >> + */
> >> +u64 notrace timer_early_get_count(void) {
> >> +   return readq((void __iomem
> >> +*)MTIME_REG(RISCV_MMODE_TIMERBASE));
> >> +}
> >> +#endif
> >> +
> >>  static const struct timer_ops andes_plmt_ops = {
> >> .get_count = andes_plmt_get_count,  }; diff --git
> >> a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c index
> >> 21ae184057..a0f71ca897 100644
> >> --- a/drivers/timer/riscv_timer.c
> >> +++ b/drivers/timer/riscv_timer.c
> >> @@ -16,7 +16,7 @@
> >>  #include 
> >>  #include 
> >>
> >> -static u64 riscv_timer_get_count(struct udevice *dev)
> >> +static u64 notrace riscv_timer_get_count(stru

Re: [PATCH] riscv: timer: Add support for an early timer

2020-11-23 Thread Rick Chen
Hi Pragnesh,

> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Tuesday, November 17, 2020 7:05 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; Sean Anderson; Simon 
> Glass; Bin Meng
> Subject: [PATCH] riscv: timer: Add support for an early timer
>
> Added support for timer_early_get_count() and timer_early_get_rate()
> This is mostly useful in tracing.
>
> Signed-off-by: Pragnesh Patel 
> ---
>  drivers/timer/andes_plmt_timer.c   | 21 -
>  drivers/timer/riscv_timer.c| 21 -
>  drivers/timer/sifive_clint_timer.c | 21 -
>  include/configs/ax25-ae350.h   |  5 +
>  include/configs/sifive-fu540.h |  5 +
>  5 files changed, 70 insertions(+), 3 deletions(-)
>

I verify with ae350_rv64_defconfig

make FTRACE=1 ae350_rv64_defconfig
make FTRACE=1

and it boot fail as below:

U-Boot 2021.01-rc2-00140-geb42715 (Nov 24 2020 - 15:02:18 +0800)

DRAM:  1 GiB
trace: enabled

DO you have any suggestions ?

Thanks,
Rick

> diff --git a/drivers/timer/andes_plmt_timer.c 
> b/drivers/timer/andes_plmt_timer.c
> index cec86718c7..74b795c97a 100644
> --- a/drivers/timer/andes_plmt_timer.c
> +++ b/drivers/timer/andes_plmt_timer.c
> @@ -17,11 +17,30 @@
>  /* mtime register */
>  #define MTIME_REG(base)((ulong)(base))
>
> -static u64 andes_plmt_get_count(struct udevice *dev)
> +static u64 notrace andes_plmt_get_count(struct udevice *dev)
>  {
> return readq((void __iomem *)MTIME_REG(dev->priv));
>  }
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> +/**
> + * timer_early_get_rate() - Get the timer rate before driver model
> + */
> +unsigned long notrace timer_early_get_rate(void)
> +{
> +   return RISCV_MMODE_TIMER_FREQ;
> +}
> +
> +/**
> + * timer_early_get_count() - Get the timer count before driver model
> + *
> + */
> +u64 notrace timer_early_get_count(void)
> +{
> +   return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
> +}
> +#endif
> +
>  static const struct timer_ops andes_plmt_ops = {
> .get_count = andes_plmt_get_count,
>  };
> diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
> index 21ae184057..a0f71ca897 100644
> --- a/drivers/timer/riscv_timer.c
> +++ b/drivers/timer/riscv_timer.c
> @@ -16,7 +16,7 @@
>  #include 
>  #include 
>
> -static u64 riscv_timer_get_count(struct udevice *dev)
> +static u64 notrace riscv_timer_get_count(struct udevice *dev)
>  {
> __maybe_unused u32 hi, lo;
>
> @@ -31,6 +31,25 @@ static u64 riscv_timer_get_count(struct udevice *dev)
> return ((u64)hi << 32) | lo;
>  }
>
> +#if CONFIG_IS_ENABLED(RISCV_SMODE)
> +/**
> + * timer_early_get_rate() - Get the timer rate before driver model
> + */
> +unsigned long notrace timer_early_get_rate(void)
> +{
> +   return RISCV_SMODE_TIMER_FREQ;
> +}
> +
> +/**
> + * timer_early_get_count() - Get the timer count before driver model
> + *
> + */
> +u64 notrace timer_early_get_count(void)
> +{
> +   return riscv_timer_get_count(NULL);
> +}
> +#endif
> +
>  static int riscv_timer_probe(struct udevice *dev)
>  {
> struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> diff --git a/drivers/timer/sifive_clint_timer.c 
> b/drivers/timer/sifive_clint_timer.c
> index 00ce0f08d6..9ae05a0e7e 100644
> --- a/drivers/timer/sifive_clint_timer.c
> +++ b/drivers/timer/sifive_clint_timer.c
> @@ -14,11 +14,30 @@
>  /* mtime register */
>  #define MTIME_REG(base)((ulong)(base) + 0xbff8)
>
> -static u64 sifive_clint_get_count(struct udevice *dev)
> +static u64 notrace sifive_clint_get_count(struct udevice *dev)
>  {
> return readq((void __iomem *)MTIME_REG(dev->priv));
>  }
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> +/**
> + * timer_early_get_rate() - Get the timer rate before driver model
> + */
> +unsigned long notrace timer_early_get_rate(void)
> +{
> +   return RISCV_MMODE_TIMER_FREQ;
> +}
> +
> +/**
> + * timer_early_get_count() - Get the timer count before driver model
> + *
> + */
> +u64 notrace timer_early_get_count(void)
> +{
> +   return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
> +}
> +#endif
> +
>  static const struct timer_ops sifive_clint_ops = {
> .get_count = sifive_clint_get_count,
>  };
> diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
> index b2606e794d..bd9c371f83 100644
> --- a/include/configs/ax25-ae350.h
> +++ b/include/configs/ax25-ae350.h
> @@ -17,6 +17,11 @@
>  #endif
>  #endif
>
> +#define RISCV_MMODE_TIMERBASE   0xe600
> +#define RISCV_MMODE_TIMER_FREQ  6000
> +
> +#define RISCV_SMODE_TIMER_FREQ  6000
> +
>  /*
>   * CPU and Board Configuration Options
>   */
> diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
> 

Re: [PATCH] riscv: fix the wrong swap value register

2020-11-23 Thread Rick Chen
> From: Brad Kim [mailto:brad@semifive.com]
> Sent: Friday, November 13, 2020 7:48 PM
> To: Rick Jian-Zhi Chen(陳建志); lukas.a...@aisec.fraunhofer.de
> Cc: bmeng...@gmail.com; sean...@gmail.com; u-boot@lists.denx.de; Brad Kim
> Subject: [PATCH] riscv: fix the wrong swap value register
>
> Not s2 register, t1 register is correct
> Fortunately, it works because t1 register has a garbage value
>
> Signed-off-by: Brad Kim 
> ---
>  arch/riscv/cpu/start.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Rick Chen 

> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> index bbc737ed9a..8589509e01 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -123,7 +123,7 @@ call_board_init_f_0:
>  * wait for initialization to complete.
>  */
> la  t0, hart_lottery
> -   li  s2, 1
> +   li  t1, 1
> amoswap.w s2, t1, 0(t0)
> bnezs2, wait_for_gd_init
>  #else
> --
> 2.17.1
>


Re: [PATCH v3 1/1] riscv: Add timer_get_us() for tracing

2020-11-15 Thread Rick Chen
Hi Pragnesh

> Hi Rick,
>
> >-Original Message-----
> >From: Rick Chen 
> >Sent: 13 November 2020 13:37
> >To: Pragnesh Patel 
> >Cc: U-Boot Mailing List ; Atish Patra
> >; palmerdabb...@google.com; Bin Meng
> >; Paul Walmsley ( Sifive) ;
> >Anup Patel ; Sagar Kadam
> >; Sean Anderson ; rick
> >; Alan Kao ; Leo Liang
> >
> >Subject: Re: [PATCH v3 1/1] riscv: Add timer_get_us() for tracing
> >
> >[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: Wednesday, November 11, 2020 6:15 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; Sean Anderson; Heinrich
> >> Schuchardt; Simon Glass
> >> Subject: [PATCH v3 1/1] riscv: Add timer_get_us() for tracing
> >>
> >> Add timer_get_us() which is useful for tracing.
> >> For S-mode U-Boot, CSR_TIMEH and CSR_TIME will provide a timer ticks
> >> and For M-mode U-Boot, mtime register will provide the same.
> >>
> >> Signed-off-by: Pragnesh Patel 
> >> ---
> >>
> >> Changes in v3:
> >> - Added gd->arch.plmt in global data
> >> - For timer_get_us(), use readq() instead of andes_plmt_get_count()
> >>   and sifive_clint_get_count()
> >>
> >> Changes in v2:
> >> - Added timer_get_us() in riscv_timer.c, sifive_clint_timer.c
> >>   and andes_plmt_timer.c.
> >>
> >>
> >>  arch/riscv/include/asm/global_data.h |  3 +++
> >>  drivers/timer/andes_plmt_timer.c | 19 ++-
> >>  drivers/timer/riscv_timer.c  | 14 +-
> >>  drivers/timer/sifive_clint_timer.c   | 19 ++-
> >>  4 files changed, 52 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/riscv/include/asm/global_data.h
> >> b/arch/riscv/include/asm/global_data.h
> >> index d3a0b1d221..4e22ceb83f 100644
> >> --- a/arch/riscv/include/asm/global_data.h
> >> +++ b/arch/riscv/include/asm/global_data.h
> >> @@ -24,6 +24,9 @@ struct arch_global_data {  #ifdef CONFIG_ANDES_PLIC
> >> void __iomem *plic; /* plic base address */
> >>  #endif
> >> +#ifdef CONFIG_ANDES_PLMT
> >
> >It shall be CONFIG_ANDES_PLMT, or it will compile fail as below:

Sorry, it's shall be CONFIG_ANDES_PLMT_TIMER here // because of
obj-$(CONFIG_ANDES_PLMT_TIMER) += andes_plmt_timer.o
Or it will have a compiling error.

> >
> >drivers/timer/andes_plmt_timer.c: In function 'timer_get_us':
> >drivers/timer/andes_plmt_timer.c:36:15: error: 'struct arch_global_data' has 
> >no
> >member named 'plmt'; did you mean 'plic'?
> >  if (gd->arch.plmt) {
> >   ^~~~
> >   plic
> >drivers/timer/andes_plmt_timer.c:37:52: error: 'struct arch_global_data' has 
> >no
> >member named 'plmt'; did you mean 'plic'?
> >   ticks = readq((void __iomem *)MTIME_REG(gd->arch.plmt));
>
> No I did not get this. Why are you getting this error because plmt is already 
> defined ?
>
> >
> >And it is not proper to have dependency of data structure between
> >/arch/riscv/include/asm/* and /drivers/timer/* Maybe enable TIMER_EARLY and
> >use timer_get_us() of /lib/time.c will be better.
> >I also found that without dm_timer_init() in initf_dm(),
> >andes_plmt_get_count() will be executed ahead of andes_plmt_probe().
>
> Thanks Rick but me and Heinrich are working on different approach to use 
> existing dm_timer_init() from lib/time.c
>
> https://patchwork.ozlabs.org/project/uboot/patch/20201112071411.4202-1-xypron.g...@gmx.de/

OK

Thanks,
Rick

>
> >
> >Thanks,
> >Rick
> >
> >
> >> +   void __iomem *plmt; /* plmt base address */
> >> +#endif
> >>  #if CONFIG_IS_ENABLED(SMP)
> >> struct ipi_data ipi[CONFIG_NR_CPUS];  #endif diff --git
> >> a/drivers/timer/andes_plmt_timer.c b/drivers/timer/andes_plmt_timer.c
> >> index cec86718c7..7c50c46d9e 100644
> >> --- a/drivers/timer/andes_plmt_timer.c
> >> +++ b/drivers/timer/andes_plmt_timer.c
> >> @@ -13,11 +13,12 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  /* mtime register */

Re: [PATCH v3 1/1] riscv: Add timer_get_us() for tracing

2020-11-13 Thread Rick Chen
Hi Pragnesh

> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Wednesday, November 11, 2020 6:15 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; Sean Anderson; Heinrich Schuchardt; Simon 
> Glass
> Subject: [PATCH v3 1/1] riscv: Add timer_get_us() for tracing
>
> Add timer_get_us() which is useful for tracing.
> For S-mode U-Boot, CSR_TIMEH and CSR_TIME will provide
> a timer ticks and For M-mode U-Boot, mtime register will
> provide the same.
>
> Signed-off-by: Pragnesh Patel 
> ---
>
> Changes in v3:
> - Added gd->arch.plmt in global data
> - For timer_get_us(), use readq() instead of andes_plmt_get_count()
>   and sifive_clint_get_count()
>
> Changes in v2:
> - Added timer_get_us() in riscv_timer.c, sifive_clint_timer.c
>   and andes_plmt_timer.c.
>
>
>  arch/riscv/include/asm/global_data.h |  3 +++
>  drivers/timer/andes_plmt_timer.c | 19 ++-
>  drivers/timer/riscv_timer.c  | 14 +-
>  drivers/timer/sifive_clint_timer.c   | 19 ++-
>  4 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/include/asm/global_data.h 
> b/arch/riscv/include/asm/global_data.h
> index d3a0b1d221..4e22ceb83f 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -24,6 +24,9 @@ struct arch_global_data {
>  #ifdef CONFIG_ANDES_PLIC
> void __iomem *plic; /* plic base address */
>  #endif
> +#ifdef CONFIG_ANDES_PLMT

It shall be CONFIG_ANDES_PLMT, or it will compile fail as below:

drivers/timer/andes_plmt_timer.c: In function 'timer_get_us':
drivers/timer/andes_plmt_timer.c:36:15: error: 'struct
arch_global_data' has no member named 'plmt'; did you mean 'plic'?
  if (gd->arch.plmt) {
   ^~~~
   plic
drivers/timer/andes_plmt_timer.c:37:52: error: 'struct
arch_global_data' has no member named 'plmt'; did you mean 'plic'?
   ticks = readq((void __iomem *)MTIME_REG(gd->arch.plmt));

And it is not proper to have dependency of data structure between
/arch/riscv/include/asm/* and /drivers/timer/*
Maybe enable TIMER_EARLY and use timer_get_us() of /lib/time.c will be better.
I also found that without dm_timer_init() in initf_dm(),
andes_plmt_get_count() will be executed ahead of andes_plmt_probe().

Thanks,
Rick


> +   void __iomem *plmt; /* plmt base address */
> +#endif
>  #if CONFIG_IS_ENABLED(SMP)
> struct ipi_data ipi[CONFIG_NR_CPUS];
>  #endif
> diff --git a/drivers/timer/andes_plmt_timer.c 
> b/drivers/timer/andes_plmt_timer.c
> index cec86718c7..7c50c46d9e 100644
> --- a/drivers/timer/andes_plmt_timer.c
> +++ b/drivers/timer/andes_plmt_timer.c
> @@ -13,11 +13,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /* mtime register */
>  #define MTIME_REG(base)((ulong)(base))
>
> -static u64 andes_plmt_get_count(struct udevice *dev)
> +static u64 notrace andes_plmt_get_count(struct udevice *dev)
>  {
> return readq((void __iomem *)MTIME_REG(dev->priv));
>  }
> @@ -26,12 +27,28 @@ static const struct timer_ops andes_plmt_ops = {
> .get_count = andes_plmt_get_count,
>  };
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> +unsigned long notrace timer_get_us(void)
> +{
> +   u64 ticks;
> +
> +   /* FIXME: gd->arch.plmt should contain valid base address */
> +   if (gd->arch.plmt) {
> +   ticks = readq((void __iomem *)MTIME_REG(gd->arch.plmt));
> +   do_div(ticks, CONFIG_SYS_HZ);
> +   }
> +
> +   return ticks;
> +}
> +#endif
> +
>  static int andes_plmt_probe(struct udevice *dev)
>  {
> dev->priv = dev_read_addr_ptr(dev);
> if (!dev->priv)
> return -EINVAL;
>
> +   gd->arch.plmt = dev->priv;
> return timer_timebase_fallback(dev);
>  }
>
> diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
> index 21ae184057..7fa8773da3 100644
> --- a/drivers/timer/riscv_timer.c
> +++ b/drivers/timer/riscv_timer.c
> @@ -15,8 +15,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
> -static u64 riscv_timer_get_count(struct udevice *dev)
> +static u64 notrace riscv_timer_get_count(struct udevice *dev)
>  {
> __maybe_unused u32 hi, lo;
>
> @@ -31,6 +32,17 @@ static u64 riscv_timer_get_count(struct udevice *dev)
> return ((u64)hi << 32) | lo;
>  }
>
> +#if CONFIG_IS_ENABLED(RISCV_SMODE)
> +unsigned long notrace timer_get_us(void)
> +{
> +   u64 ticks;
> +
> +   ticks = riscv_timer_get_count(NULL);
> +   do_div(ticks, CONFIG_SYS_HZ);
> +   return ticks;
> +}
> +#endif
> +
>  static int riscv_timer_probe(struct udevice *dev)
>  {
> struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> diff --git a/drivers/timer/sifive_clint_timer.c 
> b/drivers/timer/sifive_clint_timer.c
> index 

Re: [PATCH 1/2] pinctrl: k210: Fix inverted IE and OE for I2C

2020-11-12 Thread Rick Chen
Hi Sean

> > I2C and SCCB previously shared defaults. However, SCCB needs OE_INV and
> > IE_INV set, but I2C cannot have those bits set. This adds a separate
> > default for SCCB.
> >
> > Signed-off-by: Sean Anderson 
> > Reported-by: Damien Le Moal 
> > ---
> >
> >  drivers/pinctrl/pinctrl-kendryte.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pinctrl/pinctrl-kendryte.c 
> > b/drivers/pinctrl/pinctrl-kendryte.c
> > index 5ad049d955..259a0b507b 100644
> > --- a/drivers/pinctrl/pinctrl-kendryte.c
> > +++ b/drivers/pinctrl/pinctrl-kendryte.c
> > @@ -55,8 +55,9 @@
> >
>
> Reviewed-by: Rick Chen 

Please check about the CI failure items:
https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/742884254

+drivers/pinctrl/pinctrl-kendryte.c:187:3: error:
'K210_PC_DEFAULT_SCCB' undeclared here (not in a function); did you
mean 'K210_PC_DEFAULT_SPI'?
1282+  187 |  [K210_PC_DEFAULT_##mode] = K210_PC_MODE_##mode
1283+  |   ^~~~
1284+drivers/pinctrl/pinctrl-kendryte.c:193:2: note: in expansion of
macro 'DEFAULT'
1285+  193 |  DEFAULT(SCCB),
1286+  |  ^~~
1287+drivers/pinctrl/pinctrl-kendryte.c:187:3: error: array index in
initializer not of integer type
1288+drivers/pinctrl/pinctrl-kendryte.c:187:3: note: (near
initialization for 'k210_pc_mode_id_to_mode')
1289+make[3]: *** [drivers/pinctrl/pinctrl-kendryte.o] Error 1
1290+make[2]: *** [drivers/pinctrl] Error 2
1291+make[1]: *** [drivers] Error 2
1292+make: *** [sub-make] Error 2
1293 riscv:  +   sipeed_maix_smode
1294+drivers/pinctrl/pinctrl-kendryte.c:187:3: error:
'K210_PC_DEFAULT_SCCB' undeclared here (not in a function); did you
mean 'K210_PC_DEFAULT_SPI'?
1295+  187 |  [K210_PC_DEFAULT_##mode] = K210_PC_MODE_##mode
1296+  |   ^~~~
1297+drivers/pinctrl/pinctrl-kendryte.c:193:2: note: in expansion of
macro 'DEFAULT'
1298+  193 |  DEFAULT(SCCB),
1299+  |  ^~~
1300+drivers/pinctrl/pinctrl-kendryte.c:187:3: error: array index in
initializer not of integer type
1301+drivers/pinctrl/pinctrl-kendryte.c:187:3: note: (near
initialization for 'k210_pc_mode_id_to_mode')
1302+make[3]: *** [drivers/pinctrl/pinctrl-kendryte.o] Error 1

Thanks,
Rick


Re: [PATCH v2 1/2] i2c: ocores: add i2c driver for OpenCores I2C controller

2020-11-12 Thread Rick Chen
Hi Pragnesh

> > From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> > Sent: Thursday, October 22, 2020 2:55 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(陳建志); pe...@korsgaard.com; Pragnesh Patel; Heiko Schocher
> > Subject: [PATCH v2 1/2] i2c: ocores: add i2c driver for OpenCores I2C 
> > controller
> >
> > Add support for the OpenCores I2C controller IP core
> > (See http://www.opencores.org/projects.cgi/web/i2c/overview).
> >
> > This driver implementation is inspired from the Linux OpenCores
> > I2C driver available.
> >
> > Thanks to Peter Korsgaard  for writing Linux
> > OpenCores I2C driver.
> >
> > Signed-off-by: Pragnesh Patel 
> > ---
> >
> > Changes in v2:
> > - Remove TYPE_SIFIVE_REV0 flag
> > - Update the Opencores I2C Controller Link
> >
> >  drivers/i2c/Kconfig  |   7 +
> >  drivers/i2c/Makefile |   1 +
> >  drivers/i2c/ocores_i2c.c | 636 +++
> >  3 files changed, 644 insertions(+)
> >  create mode 100644 drivers/i2c/ocores_i2c.c
> >
>
> Reviewed-by: Rick Chen 

Please check the CI failure item:
https://travis-ci.org/github/rickchen36/u-boot-riscv/jobs/743114190

+drivers/i2c/ocores_i2c.c: In function 'ocores_i2c_probe':
1291+drivers/i2c/ocores_i2c.c:523:4: error: implicit declaration of
function 'dev_err' [-Werror=implicit-function-declaration]
1292+  523 |dev_err(dev,
1293+  |^~~
1294+drivers/i2c/ocores_i2c.c:528:4: error: implicit declaration of
function 'dev_warn' [-Werror=implicit-function-declaration]
1295+  528 |dev_warn(dev,
1296+  |^~~~
1297+cc1: all warnings being treated as errors

Thanks,
Rick


Re: [PATCH v2 2/2] riscv: sifive/fu540: kconfig: Enable support for Opencores I2C controller

2020-11-10 Thread Rick Chen
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Thursday, October 22, 2020 2:55 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(陳建志); pe...@korsgaard.com; Pragnesh Patel; Palmer Dabbelt; Bin 
> Meng; Jagan Teki; Sean Anderson
> Subject: [PATCH v2 2/2] riscv: sifive/fu540: kconfig: Enable support for 
> Opencores I2C controller
>
> Enable support for SiFive FU540 Opencores I2C master controller.
>
> Signed-off-by: Pragnesh Patel 
> ---
>
> (no changes since v1)
>
>  arch/riscv/cpu/fu540/Kconfig | 2 ++
>  board/sifive/fu540/Kconfig   | 1 +
>  2 files changed, 3 insertions(+)
>

Reviewed-by: Rick Chen 


Re: [PATCH v2 1/2] i2c: ocores: add i2c driver for OpenCores I2C controller

2020-11-10 Thread Rick Chen
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Thursday, October 22, 2020 2:55 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(陳建志); pe...@korsgaard.com; Pragnesh Patel; Heiko Schocher
> Subject: [PATCH v2 1/2] i2c: ocores: add i2c driver for OpenCores I2C 
> controller
>
> Add support for the OpenCores I2C controller IP core
> (See http://www.opencores.org/projects.cgi/web/i2c/overview).
>
> This driver implementation is inspired from the Linux OpenCores
> I2C driver available.
>
> Thanks to Peter Korsgaard  for writing Linux
> OpenCores I2C driver.
>
> Signed-off-by: Pragnesh Patel 
> ---
>
> Changes in v2:
> - Remove TYPE_SIFIVE_REV0 flag
> - Update the Opencores I2C Controller Link
>
>  drivers/i2c/Kconfig  |   7 +
>  drivers/i2c/Makefile |   1 +
>  drivers/i2c/ocores_i2c.c | 636 +++
>  3 files changed, 644 insertions(+)
>  create mode 100644 drivers/i2c/ocores_i2c.c
>

Reviewed-by: Rick Chen 


Re: [RESEND,PATCH v2 1/1] riscv: Add timer_get_us() for tracing

2020-11-09 Thread Rick Chen
Hi Pragnesh

> Hi Rick,
>
> >-Original Message-----
> >From: Rick Chen 
> >Sent: 09 November 2020 13:44
> >To: Pragnesh Patel 
> >Cc: U-Boot Mailing List ; Atish Patra
> >; Bin Meng ; Paul Walmsley (
> >Sifive) ; Anup Patel ; Sagar
> >Kadam ; Simon Glass ; Sean
> >Anderson ; palmerdabb...@google.com; rick
> >; Alan Kao 
> >Subject: Re: [RESEND,PATCH v2 1/1] riscv: Add timer_get_us() for tracing
> >
> >[External Email] Do not click links or attachments unless you recognize the
> >sender and know the content is safe
> >
> >> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> >> Sent: Thursday, November 05, 2020 7:31 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; Sean Anderson; Claudiu
> >> Beznea; Simon Glass
> >> Subject: [RESEND,PATCH v2 1/1] riscv: Add timer_get_us() for tracing
> >>
> >> Add timer_get_us() which is useful for tracing.
> >> For S-mode U-Boot, CSR_TIMEH and CSR_TIME will provide a timer ticks
> >> and For M-mode U-Boot, mtime register will provide the same.
> >>
> >> Signed-off-by: Pragnesh Patel 
> >> ---
> >>  drivers/timer/andes_plmt_timer.c   | 16 +++-
> >>  drivers/timer/riscv_timer.c| 14 +-
> >>  drivers/timer/sifive_clint_timer.c | 16 +++-
> >>  3 files changed, 43 insertions(+), 3 deletions(-)
> >>
> >
> >I verify it fail as below:
> >
> >U-Boot 2020.10-20532-g0910882 (Nov 09 2020 - 15:51:31 +0800)
> >
> >DRAM:  1 GiB
> >trace: enabled
> >
> >Do you have any suggestion ?
>
> On which platform ?
>
> Do you follow this 
> https://patchwork.ozlabs.org/project/uboot/cover/20201105113032.26234-1-pragnesh.pa...@sifive.com/
>  ?
>

I verify on AE350 platform with the following configurations:

CONFIG_TRACE=y
CONFIG_TRACE_BUFFER_SIZE=0x0100
CONFIG_TRACE_CALL_DEPTH_LIMIT=15
CONFIG_CMD_TRACE=y

make FTRACE=1 ae350_rv64_defconfig
make FTRACE=1

After dig in and I found the root cause.
You can't use gd->arch.plic to record plmt base.
It conflicts with andes plic.

Thanks,
Rick

> >
> >Thanks,
> >Rick
> >
> >
> >> diff --git a/drivers/timer/andes_plmt_timer.c
> >> b/drivers/timer/andes_plmt_timer.c
> >> index cec86718c7..9d663e036e 100644
> >> --- a/drivers/timer/andes_plmt_timer.c
> >> +++ b/drivers/timer/andes_plmt_timer.c
> >> @@ -13,11 +13,12 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  /* mtime register */
> >>  #define MTIME_REG(base)((ulong)(base))
> >>
> >> -static u64 andes_plmt_get_count(struct udevice *dev)
> >> +static u64 notrace andes_plmt_get_count(struct udevice *dev)
> >>  {
> >> return readq((void __iomem *)MTIME_REG(dev->priv));  } @@
> >> -26,12 +27,25 @@ static const struct timer_ops andes_plmt_ops = {
> >> .get_count = andes_plmt_get_count,  };
> >>
> >> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> >> +unsigned long notrace timer_get_us(void) {
> >> +   u64 ticks;
> >> +
> >> +   /* FIXME: gd->arch.plic should contain valid base address */
> >> +   ticks = andes_plmt_get_count(gd->arch.plic);
>
> Here andes_plmt_get_count() should be replaced with MTIME_REG() macro. Will 
> update in v3.
>
> >> +   do_div(ticks, CONFIG_SYS_HZ);
> >> +   return ticks;
> >> +}
> >> +#endif
> >> +
> >>  static int andes_plmt_probe(struct udevice *dev)  {
> >> dev->priv = dev_read_addr_ptr(dev);
> >> if (!dev->priv)
> >> return -EINVAL;
> >>
> >> +   gd->arch.plic = dev->priv;
> >> return timer_timebase_fallback(dev);  }
> >>
> >> diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
> >> index 21ae184057..7fa8773da3 100644
> >> --- a/drivers/timer/riscv_timer.c
> >> +++ b/drivers/timer/riscv_timer.c
> >> @@ -15,8 +15,9 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >> -static u64 riscv_timer_get_count(struct udevice *dev)
> >> +static u64 notrace riscv_timer_get_count(struct udevice *dev)
> >&

Re: [RESEND,PATCH v2 1/1] riscv: Add timer_get_us() for tracing

2020-11-09 Thread Rick Chen
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com]
> Sent: Thursday, November 05, 2020 7:31 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; Sean Anderson; Claudiu Beznea; Simon Glass
> Subject: [RESEND,PATCH v2 1/1] riscv: Add timer_get_us() for tracing
>
> Add timer_get_us() which is useful for tracing.
> For S-mode U-Boot, CSR_TIMEH and CSR_TIME will provide
> a timer ticks and For M-mode U-Boot, mtime register will
> provide the same.
>
> Signed-off-by: Pragnesh Patel 
> ---
>  drivers/timer/andes_plmt_timer.c   | 16 +++-
>  drivers/timer/riscv_timer.c| 14 +-
>  drivers/timer/sifive_clint_timer.c | 16 +++-
>  3 files changed, 43 insertions(+), 3 deletions(-)
>

I verify it fail as below:

U-Boot 2020.10-20532-g0910882 (Nov 09 2020 - 15:51:31 +0800)

DRAM:  1 GiB
trace: enabled

Do you have any suggestion ?

Thanks,
Rick


> diff --git a/drivers/timer/andes_plmt_timer.c 
> b/drivers/timer/andes_plmt_timer.c
> index cec86718c7..9d663e036e 100644
> --- a/drivers/timer/andes_plmt_timer.c
> +++ b/drivers/timer/andes_plmt_timer.c
> @@ -13,11 +13,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /* mtime register */
>  #define MTIME_REG(base)((ulong)(base))
>
> -static u64 andes_plmt_get_count(struct udevice *dev)
> +static u64 notrace andes_plmt_get_count(struct udevice *dev)
>  {
> return readq((void __iomem *)MTIME_REG(dev->priv));
>  }
> @@ -26,12 +27,25 @@ static const struct timer_ops andes_plmt_ops = {
> .get_count = andes_plmt_get_count,
>  };
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> +unsigned long notrace timer_get_us(void)
> +{
> +   u64 ticks;
> +
> +   /* FIXME: gd->arch.plic should contain valid base address */
> +   ticks = andes_plmt_get_count(gd->arch.plic);
> +   do_div(ticks, CONFIG_SYS_HZ);
> +   return ticks;
> +}
> +#endif
> +
>  static int andes_plmt_probe(struct udevice *dev)
>  {
> dev->priv = dev_read_addr_ptr(dev);
> if (!dev->priv)
> return -EINVAL;
>
> +   gd->arch.plic = dev->priv;
> return timer_timebase_fallback(dev);
>  }
>
> diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
> index 21ae184057..7fa8773da3 100644
> --- a/drivers/timer/riscv_timer.c
> +++ b/drivers/timer/riscv_timer.c
> @@ -15,8 +15,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
> -static u64 riscv_timer_get_count(struct udevice *dev)
> +static u64 notrace riscv_timer_get_count(struct udevice *dev)
>  {
> __maybe_unused u32 hi, lo;
>
> @@ -31,6 +32,17 @@ static u64 riscv_timer_get_count(struct udevice *dev)
> return ((u64)hi << 32) | lo;
>  }
>
> +#if CONFIG_IS_ENABLED(RISCV_SMODE)
> +unsigned long notrace timer_get_us(void)
> +{
> +   u64 ticks;
> +
> +   ticks = riscv_timer_get_count(NULL);
> +   do_div(ticks, CONFIG_SYS_HZ);
> +   return ticks;
> +}
> +#endif
> +
>  static int riscv_timer_probe(struct udevice *dev)
>  {
> struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> diff --git a/drivers/timer/sifive_clint_timer.c 
> b/drivers/timer/sifive_clint_timer.c
> index 00ce0f08d6..166655e99d 100644
> --- a/drivers/timer/sifive_clint_timer.c
> +++ b/drivers/timer/sifive_clint_timer.c
> @@ -10,11 +10,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /* mtime register */
>  #define MTIME_REG(base)((ulong)(base) + 0xbff8)
>
> -static u64 sifive_clint_get_count(struct udevice *dev)
> +static u64 notrace sifive_clint_get_count(struct udevice *dev)
>  {
> return readq((void __iomem *)MTIME_REG(dev->priv));
>  }
> @@ -23,12 +24,25 @@ static const struct timer_ops sifive_clint_ops = {
> .get_count = sifive_clint_get_count,
>  };
>
> +#if CONFIG_IS_ENABLED(RISCV_MMODE)
> +unsigned long notrace timer_get_us(void)
> +{
> +   u64 ticks;
> +
> +   /* FIXME: gd->arch.clint should contain valid base address */
> +   ticks = sifive_clint_get_count(gd->arch.clint);
> +   do_div(ticks, CONFIG_SYS_HZ);
> +   return ticks;
> +}
> +#endif
> +
>  static int sifive_clint_probe(struct udevice *dev)
>  {
> dev->priv = dev_read_addr_ptr(dev);
> if (!dev->priv)
> return -EINVAL;
>
> +   gd->arch.clint = dev->priv;
> return timer_timebase_fallback(dev);
>  }
>
> --
> 2.17.1
>


Re: [PATCH 1/1] riscv: enable SATA disk on qemu-riscv64_defconfig

2020-11-03 Thread Rick Chen
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heinrich 
> Schuchardt
> Sent: Monday, November 02, 2020 7:37 PM
> To: Bin Meng
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt
> Subject: [PATCH 1/1] riscv: enable SATA disk on qemu-riscv64_defconfig
>
> Allow attaching a virtual SATA disk to qemu-riscv64_defconfig.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  configs/qemu-riscv64_defconfig | 6 ++
>  1 file changed, 6 insertions(+)
>

Reviewed-by: Rick Chen 


Re: [PATCH v4 0/7] wdt: Add support for watchdogs on Kendryte K210

2020-11-03 Thread Rick Chen
 於 2020年11月4日 週三 上午10:01寫道:
>
>
>
> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Sean Anderson
> Sent: Friday, October 23, 2020 9:30 PM
> To: u-boot@lists.denx.de
> Cc: Bin Meng; Marek Vasut; Jagan Teki; Simon Glass; Heinrich Schuchardt
> Subject: Re: [PATCH v4 0/7] wdt: Add support for watchdogs on Kendryte K210
>
>
> On 10/1/20 10:56 AM, Sean Anderson wrote:
> > On 9/9/20 5:04 PM, Sean Anderson wrote:
> >> This series depends on
> >> https://patchwork.ozlabs.org/project/uboot/list/?series=200642
> >>
> >> Changes in v4:
> >> - Fix build error without CONFIG_CLK
> >>
> >> Changes in v3:
> >> - Note dependency on "time: Fix get_ticks being non-monotonic"
> >> - Add a few signed-off-bys which were sent for version 1
> >>
> >> Changes in v2:
> >> - Fix fls being off-by-one when compared to log_2_n_round_up
> >> - Move watchdog enable to k210.dtsi as it does not depend on anything
> >>   board-specific.
> >>
> >> Sean Anderson (7):
> >>   wdt: dw: Switch to using fls for log2
> >>   wdt: dw: Switch to if(CONFIG()) instead of using #if
> >>   wdt: dw: Fix clock rate being off by 1000
> >>   wdt: dw: Enable the clock before using it
> >>   wdt: dw: Free the clock on error
> >>   riscv: Add watchdog bindings for the k210
> >>   riscv: Enable watchdog for the k210
> >>
> >>  arch/riscv/dts/k210.dtsi  |  1 -
> >>  board/sipeed/maix/Kconfig |  2 ++
> >>  drivers/watchdog/designware_wdt.c | 39 -------
> >>  3 files changed, 27 insertions(+), 15 deletions(-)
> >>
> >
> > *ping*
> >
> > Marek can these go into -next?
> >
> > --Sean
> >
>
> *second ping*
>
> It appears that an earlier version of this series [1] was assigned to
> Marek Vasut, but that the current version is assigned to Rick Chen. v2
> should be marked as superseded. Can this get picked up for the merge
> window?

Those patchs seem have been reviewed and tagged.
If no other comments furthermore.
I can help to pull via riscv tree later.

But it shall sync to master again:
Applying: wdt: dw: Switch to using fls for log2
Applying: wdt: dw: Switch to if(CONFIG()) instead of using #if
Applying: wdt: dw: Fix clock rate being off by 1000
error: patch failed: drivers/watchdog/designware_wdt.c:129
error: drivers/watchdog/designware_wdt.c: patch does not apply
Patch failed at 0003 wdt: dw: Fix clock rate being off by 1000

Thanks,
Rick

>
> --Sean
>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=194673
> [2] https://patchwork.ozlabs.org/project/uboot/list/?series=200657


Re: [PATCH] riscv: Fix efi header for RV32

2020-11-03 Thread Rick Chen
Hi Atish

> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heinrich 
> Schuchardt
> Sent: Wednesday, October 14, 2020 9:16 AM
> To: Bin Meng; Atish Patra
> Cc: U-Boot Mailing List; Anup Patel; Jagan Teki; Marek Vasut; Simon 
> Goldschmidt; David Abdurachmanov; Tom Rini
> Subject: Re: [PATCH] riscv: Fix efi header for RV32
>
> Am 14. Oktober 2020 03:03:28 MESZ schrieb Bin Meng :
> >On Wed, Oct 14, 2020 at 3:23 AM Atish Patra 
> >wrote:
> >>
> >> RV32 should use PE32 format instead of PE32+ as the efi header
> >format.
> >> This requires following changes
> >> 1. A different header magic value
> >> 2. An additional parameter known as BaseOfData. Currently, it is set
> >to
> >>zero in absence of any usage.
> >>
> >> Signed-off-by: Atish Patra 
> >> ---
> >>  arch/riscv/lib/crt0_riscv_efi.S | 7 ++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>

Reviewed-by: Rick Chen 

> >> diff --git a/arch/riscv/lib/crt0_riscv_efi.S
> >b/arch/riscv/lib/crt0_riscv_efi.S
> >> index 87fe1e56f906..4aaa49ad0777 100644
> >> --- a/arch/riscv/lib/crt0_riscv_efi.S
> >> +++ b/arch/riscv/lib/crt0_riscv_efi.S
> >> @@ -15,11 +15,13 @@
> >>  #define SAVE_LONG(reg, idx)sd  reg, (idx*SIZE_LONG)(sp)
> >>  #define LOAD_LONG(reg, idx)ld  reg, (idx*SIZE_LONG)(sp)
> >>  #define PE_MACHINE IMAGE_FILE_MACHINE_RISCV64
> >> +#define PE_MAGICIMAGE_NT_OPTIONAL_HDR64_MAGIC
> >
> >nits: the indentation seems to be incorrect
> >
> >>  #else
> >>  #define SIZE_LONG  4
> >>  #define SAVE_LONG(reg, idx)sw  reg, (idx*SIZE_LONG)(sp)
> >>  #define LOAD_LONG(reg, idx)lw  reg, (idx*SIZE_LONG)(sp)
> >>  #define PE_MACHINE IMAGE_FILE_MACHINE_RISCV32
> >> +#define PE_MAGICIMAGE_NT_OPTIONAL_HDR32_MAGIC
> >>  #endif
> >>
> >>
> >> @@ -48,7 +50,7 @@ coff_header:
> >>  IMAGE_FILE_LOCAL_SYMS_STRIPPED | \
> >>  IMAGE_FILE_DEBUG_STRIPPED)
> >>  optional_header:
> >> -   .short  IMAGE_NT_OPTIONAL_HDR64_MAGIC   /* PE32+ format */
> >
> >nits: PE32(+) ?
> >
> >> +   .short  PE_MAGIC/* PE32+ format */
> >> .byte   0x02/* MajorLinkerVersion
> >*/
> >> .byte   0x14/* MinorLinkerVersion
> >*/
> >> .long   _edata - _start /* SizeOfCode */
> >> @@ -56,6 +58,9 @@ optional_header:
> >> .long   0   /*
> >SizeOfUninitializedData */
> >> .long   _start - ImageBase  /*
> >AddressOfEntryPoint */
> >> .long   _start - ImageBase  /* BaseOfCode */
> >> +#if __riscv_xlen == 32
> >> +   .long   0   /* BaseOfData */
> >> +#endif
> >>
>
> The PE32 header has to be 96 bytes long, the PE32+ header 112 bytes long.
>
> See https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
>

Do you have any comments ?

The other headers seem for Windows-Specific Fields. If no other
comments furthermore.
I will pull it into riscv tree later.

Thanks,
Rick

> Best regards
>
> Heinrich
>
>
> >>  extra_header_fields:
> >> .quad   0   /* ImageBase */
> >
> >Looks good otherwise
> >Reviewed-by: Bin Meng 


Re: [PATCH v2 15/16] riscv: k210: Use AI as the parent clock of aisram, not PLL1

2020-11-03 Thread Rick Chen
> Testing showed that disabling AI while leaving PLL1 enabled disabled the
> aisram. This suggests that AI is a more appropriate clock for that ram
> bank.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v2:
> - New
>
>  arch/riscv/dts/k210.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Rick Chen 


Re: [PATCH v2 14/16] riscv: k210: Rename airam to aisram

2020-11-02 Thread Rick Chen
> This is more consistent with the naming of other ram banks, and matches
> what Linux is doing.
>
> Reported-by: Damien Le Moal 
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v2:
> - New
>
>  arch/riscv/dts/k210.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Rick Chen 


  1   2   3   4   5   6   7   >