[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Anup Patel]

This patchset adds SiFive Freedom Unleashed (FU540) support
to RISC-V U-Boot.

The patches are based upon latest RISC-V U-Boot tree
(git://git.denx.de/u-boot-riscv.git) at commit id
91882c472d8c0aef4db699d3f2de55bf43d4ae4b

All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
MACB Ethernet work fine on actual SiFive Unleashed board and
QEMU sifive_u machine.

Changes since v1:
 - Re-ordered SoB in patches with multiple SoB
 - Simplified board_get_usable_ram_top() added by PATCH3

Anup Patel (7):
  riscv: Rename cpu/qemu to cpu/generic
  riscv: Add asm/dma-mapping.h for DMA mappings
  riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems
  net: macb: Fix clk API usage for RISC-V systems
  clk: Add SiFive FU540 PRCI clock driver
  clk: Add fixed-factor clock driver
  riscv: Add SiFive FU540 board support

Atish Patra (4):
  net: macb: Fix GEM hardware detection
  drivers: serial_sifive: Fix baud rate calculation
  drivers: serial_sifive: Skip baudrate config if no input clock
  cpu: Bind timer driver for boot hart

 arch/riscv/Kconfig                            |   6 +-
 arch/riscv/cpu/{qemu => generic}/Kconfig      |   2 +-
 arch/riscv/cpu/{qemu => generic}/Makefile     |   0
 arch/riscv/cpu/{qemu => generic}/cpu.c        |   0
 arch/riscv/cpu/generic/dram.c                 |  37 ++
 arch/riscv/cpu/qemu/dram.c                    |  17 -
 arch/riscv/include/asm/dma-mapping.h          |  38 ++
 board/emulation/qemu-riscv/Kconfig            |   4 +-
 .../qemu-riscv => sifive/fu540}/Kconfig       |  36 +-
 board/sifive/fu540/MAINTAINERS                |   9 +
 board/sifive/fu540/Makefile                   |   5 +
 board/sifive/fu540/fu540.c                    |  17 +
 configs/sifive_fu540_defconfig                |  11 +
 drivers/clk/Kconfig                           |   1 +
 drivers/clk/Makefile                          |   5 +-
 drivers/clk/clk_fixed_factor.c                |  74 +++
 drivers/clk/sifive/Kconfig                    |  19 +
 drivers/clk/sifive/Makefile                   |   5 +
 .../clk/sifive/analogbits-wrpll-cln28hpc.h    | 101 +++
 drivers/clk/sifive/fu540-prci.c               | 604 ++++++++++++++++++
 drivers/clk/sifive/wrpll-cln28hpc.c           | 390 +++++++++++
 drivers/cpu/riscv_cpu.c                       |   7 +-
 drivers/net/macb.c                            |   6 +-
 drivers/serial/serial_sifive.c                |  60 +-
 include/configs/sifive-fu540.h                |  43 ++
 include/dt-bindings/clk/sifive-fu540-prci.h   |  29 +
 26 files changed, 1465 insertions(+), 61 deletions(-)
 rename arch/riscv/cpu/{qemu => generic}/Kconfig (91%)
 rename arch/riscv/cpu/{qemu => generic}/Makefile (100%)
 rename arch/riscv/cpu/{qemu => generic}/cpu.c (100%)
 create mode 100644 arch/riscv/cpu/generic/dram.c
 delete mode 100644 arch/riscv/cpu/qemu/dram.c
 create mode 100644 arch/riscv/include/asm/dma-mapping.h
 copy board/{emulation/qemu-riscv => sifive/fu540}/Kconfig (57%)
 create mode 100644 board/sifive/fu540/MAINTAINERS
 create mode 100644 board/sifive/fu540/Makefile
 create mode 100644 board/sifive/fu540/fu540.c
 create mode 100644 configs/sifive_fu540_defconfig
 create mode 100644 drivers/clk/clk_fixed_factor.c
 create mode 100644 drivers/clk/sifive/Kconfig
 create mode 100644 drivers/clk/sifive/Makefile
 create mode 100644 drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
 create mode 100644 drivers/clk/sifive/fu540-prci.c
 create mode 100644 drivers/clk/sifive/wrpll-cln28hpc.c
 create mode 100644 include/configs/sifive-fu540.h
 create mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h

-- 
2.17.1

[U-Boot] [PATCH v2 01/11] riscv: Rename cpu/qemu to cpu/generic

[Anup Patel]

The QEMU CPU support under arch/riscv is pretty much generic
and works fine for SiFive Unleashed as well. In fact, there
will be quite a few RISC-V SOCs for which QEMU CPU support
will work fine.

This patch renames cpu/qemu to cpu/generic to indicate the
above fact. If there are SOC specific errata workarounds
required in cpu/generic then those can be done at runtime
in cpu/generic based on CPU vendor specific DT compatible
string.

Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 arch/riscv/Kconfig                        | 2 +-
 arch/riscv/cpu/{qemu => generic}/Kconfig  | 2 +-
 arch/riscv/cpu/{qemu => generic}/Makefile | 0
 arch/riscv/cpu/{qemu => generic}/cpu.c    | 0
 arch/riscv/cpu/{qemu => generic}/dram.c   | 0
 board/emulation/qemu-riscv/Kconfig        | 4 ++--
 6 files changed, 4 insertions(+), 4 deletions(-)
 rename arch/riscv/cpu/{qemu => generic}/Kconfig (91%)
 rename arch/riscv/cpu/{qemu => generic}/Makefile (100%)
 rename arch/riscv/cpu/{qemu => generic}/cpu.c (100%)
 rename arch/riscv/cpu/{qemu => generic}/dram.c (100%)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c45e4d73a8..6879047ff7 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -22,7 +22,7 @@ source "board/emulation/qemu-riscv/Kconfig"
 
 # platform-specific options below
 source "arch/riscv/cpu/ax25/Kconfig"
-source "arch/riscv/cpu/qemu/Kconfig"
+source "arch/riscv/cpu/generic/Kconfig"
 
 # architecture-specific options below
 
diff --git a/arch/riscv/cpu/qemu/Kconfig b/arch/riscv/cpu/generic/Kconfig
similarity index 91%
rename from arch/riscv/cpu/qemu/Kconfig
rename to arch/riscv/cpu/generic/Kconfig
index f48751e6de..1d6ab5032d 100644
--- a/arch/riscv/cpu/qemu/Kconfig
+++ b/arch/riscv/cpu/generic/Kconfig
@@ -2,7 +2,7 @@
 #
 # Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
 
-config QEMU_RISCV
+config GENERIC_RISCV
 	bool
 	select ARCH_EARLY_INIT_R
 	imply CPU
diff --git a/arch/riscv/cpu/qemu/Makefile b/arch/riscv/cpu/generic/Makefile
similarity index 100%
rename from arch/riscv/cpu/qemu/Makefile
rename to arch/riscv/cpu/generic/Makefile
diff --git a/arch/riscv/cpu/qemu/cpu.c b/arch/riscv/cpu/generic/cpu.c
similarity index 100%
rename from arch/riscv/cpu/qemu/cpu.c
rename to arch/riscv/cpu/generic/cpu.c
diff --git a/arch/riscv/cpu/qemu/dram.c b/arch/riscv/cpu/generic/dram.c
similarity index 100%
rename from arch/riscv/cpu/qemu/dram.c
rename to arch/riscv/cpu/generic/dram.c
diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig
index 0d865acf10..88d07d568e 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -7,7 +7,7 @@ config SYS_VENDOR
 	default "emulation"
 
 config SYS_CPU
-	default "qemu"
+	default "generic"
 
 config SYS_CONFIG_NAME
 	default "qemu-riscv"
@@ -18,7 +18,7 @@ config SYS_TEXT_BASE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
 	def_bool y
-	select QEMU_RISCV
+	select GENERIC_RISCV
 	imply SYS_NS16550
 	imply VIRTIO_MMIO
 	imply VIRTIO_NET
-- 
2.17.1

[U-Boot] [PATCH v2 01/11] riscv: Rename cpu/qemu to cpu/generic

[Auer, Lukas]

On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> The QEMU CPU support under arch/riscv is pretty much generic
> and works fine for SiFive Unleashed as well. In fact, there
> will be quite a few RISC-V SOCs for which QEMU CPU support
> will work fine.
> 
> This patch renames cpu/qemu to cpu/generic to indicate the
> above fact. If there are SOC specific errata workarounds
> required in cpu/generic then those can be done at runtime
> in cpu/generic based on CPU vendor specific DT compatible
> string.
> 
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/riscv/Kconfig                        | 2 +-
>  arch/riscv/cpu/{qemu => generic}/Kconfig  | 2 +-
>  arch/riscv/cpu/{qemu => generic}/Makefile | 0
>  arch/riscv/cpu/{qemu => generic}/cpu.c    | 0
>  arch/riscv/cpu/{qemu => generic}/dram.c   | 0
>  board/emulation/qemu-riscv/Kconfig        | 4 ++--
>  6 files changed, 4 insertions(+), 4 deletions(-)
>  rename arch/riscv/cpu/{qemu => generic}/Kconfig (91%)
>  rename arch/riscv/cpu/{qemu => generic}/Makefile (100%)
>  rename arch/riscv/cpu/{qemu => generic}/cpu.c (100%)
>  rename arch/riscv/cpu/{qemu => generic}/dram.c (100%)
> 

Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>

[U-Boot] [PATCH v2 01/11] riscv: Rename cpu/qemu to cpu/generic

[Bin Meng]

On Fri, Jan 18, 2019 at 7:18 PM Anup Patel <Anup.Patel@wdc.com> wrote:
>
> The QEMU CPU support under arch/riscv is pretty much generic
> and works fine for SiFive Unleashed as well. In fact, there
> will be quite a few RISC-V SOCs for which QEMU CPU support
> will work fine.
>
> This patch renames cpu/qemu to cpu/generic to indicate the
> above fact. If there are SOC specific errata workarounds
> required in cpu/generic then those can be done at runtime
> in cpu/generic based on CPU vendor specific DT compatible
> string.
>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/riscv/Kconfig                        | 2 +-
>  arch/riscv/cpu/{qemu => generic}/Kconfig  | 2 +-
>  arch/riscv/cpu/{qemu => generic}/Makefile | 0
>  arch/riscv/cpu/{qemu => generic}/cpu.c    | 0
>  arch/riscv/cpu/{qemu => generic}/dram.c   | 0
>  board/emulation/qemu-riscv/Kconfig        | 4 ++--
>  6 files changed, 4 insertions(+), 4 deletions(-)
>  rename arch/riscv/cpu/{qemu => generic}/Kconfig (91%)
>  rename arch/riscv/cpu/{qemu => generic}/Makefile (100%)
>  rename arch/riscv/cpu/{qemu => generic}/cpu.c (100%)
>  rename arch/riscv/cpu/{qemu => generic}/dram.c (100%)
>

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

[U-Boot] [PATCH v2 02/11] riscv: Add asm/dma-mapping.h for DMA mappings

[Anup Patel]

This patch adds asm/dma-mapping.h for Linux-like DMA mappings
APIs required by some of the drivers (such as, Cadance MACB
Ethernet driver).

Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 arch/riscv/include/asm/dma-mapping.h | 38 ++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 arch/riscv/include/asm/dma-mapping.h

diff --git a/arch/riscv/include/asm/dma-mapping.h b/arch/riscv/include/asm/dma-mapping.h
new file mode 100644
index 0000000000..3d930c90ec
--- /dev/null
+++ b/arch/riscv/include/asm/dma-mapping.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2018 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ *   Anup Patel <anup.patel@wdc.com>
+ */
+
+#ifndef __ASM_RISCV_DMA_MAPPING_H
+#define __ASM_RISCV_DMA_MAPPING_H
+
+#include <linux/dma-direction.h>
+
+#define dma_mapping_error(x, y)	0
+
+static inline void *dma_alloc_coherent(size_t len, unsigned long *handle)
+{
+	*handle = (unsigned long)memalign(ARCH_DMA_MINALIGN, len);
+	return (void *)*handle;
+}
+
+static inline void dma_free_coherent(void *addr)
+{
+	free(addr);
+}
+
+static inline unsigned long dma_map_single(volatile void *vaddr, size_t len,
+					   enum dma_data_direction dir)
+{
+	return (unsigned long)vaddr;
+}
+
+static inline void dma_unmap_single(volatile void *vaddr, size_t len,
+				    unsigned long paddr)
+{
+}
+
+#endif /* __ASM_RISCV_DMA_MAPPING_H */
-- 
2.17.1

[U-Boot] [PATCH v2 02/11] riscv: Add asm/dma-mapping.h for DMA mappings

[Auer, Lukas]

On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> This patch adds asm/dma-mapping.h for Linux-like DMA mappings
> APIs required by some of the drivers (such as, Cadance MACB
> Ethernet driver).
> 
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/riscv/include/asm/dma-mapping.h | 38
> ++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
>  create mode 100644 arch/riscv/include/asm/dma-mapping.h
> 

Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>

[U-Boot] [PATCH v2 03/11] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems

[Anup Patel]

On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot
DMA mapping APIs will generate DMA addresses beyond 4GB. This
breaks DMA programming in 32bit DMA capable devices (such as
Cadence MACB ethernet). For example, If DRAM is more then 2GB
on QEMU sifive_u machine then Cadence MACB ethernet stops working
for U-Boot because it is a 32bit DMA capable device.

To handle 32bit DMA capable devices on 64bit systems, we provide
custom implementation of board_get_usable_ram_top() which ensures
that usable ram top is not more then 4GB. This in-turn ensures
that U-Boot always runs within 4GB hence DMA addresses generated
by DMA mapping APIs will be within 4GB too.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 arch/riscv/cpu/generic/dram.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/riscv/cpu/generic/dram.c b/arch/riscv/cpu/generic/dram.c
index 84d87d2a7f..5725d3c7ae 100644
--- a/arch/riscv/cpu/generic/dram.c
+++ b/arch/riscv/cpu/generic/dram.c
@@ -5,6 +5,9 @@
 
 #include <common.h>
 #include <fdtdec.h>
+#include <linux/sizes.h>
+
+DECLARE_GLOBAL_DATA_PTR;
 
 int dram_init(void)
 {
@@ -15,3 +18,20 @@ int dram_init_banksize(void)
 {
 	return fdtdec_setup_memory_banksize();
 }
+
+ulong board_get_usable_ram_top(ulong total_size)
+{
+#ifdef CONFIG_64BIT
+	/*
+	 * Ensure that we run from first 4GB so that all
+	 * addresses used by U-Boot are 32bit addresses.
+	 *
+	 * This in-turn ensures that 32bit DMA capabale
+	 * devices work fine because DMA mapping APIs will
+	 * provide 32bit DMA addresses only.
+	 */
+	if (gd->ram_top > SZ_4G)
+		return SZ_4G;
+#endif
+	return gd->ram_top;
+}
-- 
2.17.1

[U-Boot] [PATCH v2 03/11] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems

[Auer, Lukas]

On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot
> DMA mapping APIs will generate DMA addresses beyond 4GB. This
> breaks DMA programming in 32bit DMA capable devices (such as
> Cadence MACB ethernet). For example, If DRAM is more then 2GB
> on QEMU sifive_u machine then Cadence MACB ethernet stops working
> for U-Boot because it is a 32bit DMA capable device.
> 
> To handle 32bit DMA capable devices on 64bit systems, we provide
> custom implementation of board_get_usable_ram_top() which ensures
> that usable ram top is not more then 4GB. This in-turn ensures
> that U-Boot always runs within 4GB hence DMA addresses generated
> by DMA mapping APIs will be within 4GB too.
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/riscv/cpu/generic/dram.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 

Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>

With one nit below.

> diff --git a/arch/riscv/cpu/generic/dram.c
> b/arch/riscv/cpu/generic/dram.c
> index 84d87d2a7f..5725d3c7ae 100644
> --- a/arch/riscv/cpu/generic/dram.c
> +++ b/arch/riscv/cpu/generic/dram.c
> @@ -5,6 +5,9 @@
>  
>  #include <common.h>
>  #include <fdtdec.h>
> +#include <linux/sizes.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
>  
>  int dram_init(void)
>  {
> @@ -15,3 +18,20 @@ int dram_init_banksize(void)
>  {
>  	return fdtdec_setup_memory_banksize();
>  }
> +
> +ulong board_get_usable_ram_top(ulong total_size)
> +{
> +#ifdef CONFIG_64BIT
> +	/*
> +	 * Ensure that we run from first 4GB so that all
> +	 * addresses used by U-Boot are 32bit addresses.
> +	 *
> +	 * This in-turn ensures that 32bit DMA capabale

nit: capable

> +	 * devices work fine because DMA mapping APIs will
> +	 * provide 32bit DMA addresses only.
> +	 */
> +	if (gd->ram_top > SZ_4G)
> +		return SZ_4G;
> +#endif
> +	return gd->ram_top;
> +}

[U-Boot] [PATCH v2 03/11] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems

[Anup Patel]

> -----Original Message-----
> From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> Sent: Monday, January 21, 2019 1:35 AM
> To: sjg at chromium.org; bmeng.cn at gmail.com; rick at andestech.com; Anup
> Patel <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> yamada.masahiro at socionext.com
> Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org; u-
> boot at lists.denx.de; agraf at suse.de; Atish Patra <Atish.Patra@wdc.com>
> Subject: Re: [PATCH v2 03/11] riscv: generic: Ensure that U-Boot runs within
> 4GB for 64bit systems
> 
> On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot
> DMA
> > mapping APIs will generate DMA addresses beyond 4GB. This breaks DMA
> > programming in 32bit DMA capable devices (such as Cadence MACB
> > ethernet). For example, If DRAM is more then 2GB on QEMU sifive_u
> > machine then Cadence MACB ethernet stops working for U-Boot because
> it
> > is a 32bit DMA capable device.
> >
> > To handle 32bit DMA capable devices on 64bit systems, we provide
> > custom implementation of board_get_usable_ram_top() which ensures
> that
> > usable ram top is not more then 4GB. This in-turn ensures that U-Boot
> > always runs within 4GB hence DMA addresses generated by DMA mapping
> > APIs will be within 4GB too.
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > Reviewed-by: Alexander Graf <agraf@suse.de>
> > ---
> >  arch/riscv/cpu/generic/dram.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> 
> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> 
> With one nit below.
> 
> > diff --git a/arch/riscv/cpu/generic/dram.c
> > b/arch/riscv/cpu/generic/dram.c index 84d87d2a7f..5725d3c7ae 100644
> > --- a/arch/riscv/cpu/generic/dram.c
> > +++ b/arch/riscv/cpu/generic/dram.c
> > @@ -5,6 +5,9 @@
> >
> >  #include <common.h>
> >  #include <fdtdec.h>
> > +#include <linux/sizes.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> >
> >  int dram_init(void)
> >  {
> > @@ -15,3 +18,20 @@ int dram_init_banksize(void)  {
> >  	return fdtdec_setup_memory_banksize();  }
> > +
> > +ulong board_get_usable_ram_top(ulong total_size) { #ifdef
> > +CONFIG_64BIT
> > +	/*
> > +	 * Ensure that we run from first 4GB so that all
> > +	 * addresses used by U-Boot are 32bit addresses.
> > +	 *
> > +	 * This in-turn ensures that 32bit DMA capabale
> 
> nit: capable

Sure, will update.

> 
> > +	 * devices work fine because DMA mapping APIs will
> > +	 * provide 32bit DMA addresses only.
> > +	 */
> > +	if (gd->ram_top > SZ_4G)
> > +		return SZ_4G;
> > +#endif
> > +	return gd->ram_top;
> > +}

Regards,
Anup

[U-Boot] [PATCH v2 03/11] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems

[Bin Meng]

On Fri, Jan 18, 2019 at 7:19 PM Anup Patel <Anup.Patel@wdc.com> wrote:
>
> On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot
> DMA mapping APIs will generate DMA addresses beyond 4GB. This
> breaks DMA programming in 32bit DMA capable devices (such as
> Cadence MACB ethernet). For example, If DRAM is more then 2GB
> on QEMU sifive_u machine then Cadence MACB ethernet stops working
> for U-Boot because it is a 32bit DMA capable device.
>
> To handle 32bit DMA capable devices on 64bit systems, we provide
> custom implementation of board_get_usable_ram_top() which ensures
> that usable ram top is not more then 4GB. This in-turn ensures
> that U-Boot always runs within 4GB hence DMA addresses generated
> by DMA mapping APIs will be within 4GB too.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/riscv/cpu/generic/dram.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

But see one comment below:

> diff --git a/arch/riscv/cpu/generic/dram.c b/arch/riscv/cpu/generic/dram.c
> index 84d87d2a7f..5725d3c7ae 100644
> --- a/arch/riscv/cpu/generic/dram.c
> +++ b/arch/riscv/cpu/generic/dram.c
> @@ -5,6 +5,9 @@
>
>  #include <common.h>
>  #include <fdtdec.h>
> +#include <linux/sizes.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
>  int dram_init(void)
>  {
> @@ -15,3 +18,20 @@ int dram_init_banksize(void)
>  {
>         return fdtdec_setup_memory_banksize();
>  }
> +
> +ulong board_get_usable_ram_top(ulong total_size)
> +{
> +#ifdef CONFIG_64BIT
> +       /*
> +        * Ensure that we run from first 4GB so that all
> +        * addresses used by U-Boot are 32bit addresses.
> +        *
> +        * This in-turn ensures that 32bit DMA capabale
> +        * devices work fine because DMA mapping APIs will
> +        * provide 32bit DMA addresses only.
> +        */
> +       if (gd->ram_top > SZ_4G)
> +               return SZ_4G;
> +#endif
> +       return gd->ram_top;
> +}

I was wondering whether we should change this for 32-bit too, given
it's a valid configuration to have more than 4GB memory in a 32-bit
system.

Regards,
Bin

[U-Boot] [PATCH v2 03/11] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems

[Anup Patel]

> -----Original Message-----
> From: Bin Meng [mailto:bmeng.cn at gmail.com]
> Sent: Tuesday, January 22, 2019 7:37 AM
> To: Anup Patel <Anup.Patel@wdc.com>
> Cc: Rick Chen <rick@andestech.com>; Joe Hershberger
> <joe.hershberger@ni.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
> Masahiro Yamada <yamada.masahiro@socionext.com>; Simon Glass
> <sjg@chromium.org>; Alexander Graf <agraf@suse.de>; Palmer Dabbelt
> <palmer@sifive.com>; Paul Walmsley <paul.walmsley@sifive.com>; Atish
> Patra <Atish.Patra@wdc.com>; Christoph Hellwig <hch@infradead.org>; U-
> Boot Mailing List <u-boot@lists.denx.de>
> Subject: Re: [PATCH v2 03/11] riscv: generic: Ensure that U-Boot runs within
> 4GB for 64bit systems
> 
> On Fri, Jan 18, 2019 at 7:19 PM Anup Patel <Anup.Patel@wdc.com> wrote:
> >
> > On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot
> DMA
> > mapping APIs will generate DMA addresses beyond 4GB. This breaks DMA
> > programming in 32bit DMA capable devices (such as Cadence MACB
> > ethernet). For example, If DRAM is more then 2GB on QEMU sifive_u
> > machine then Cadence MACB ethernet stops working for U-Boot because
> it
> > is a 32bit DMA capable device.
> >
> > To handle 32bit DMA capable devices on 64bit systems, we provide
> > custom implementation of board_get_usable_ram_top() which ensures
> that
> > usable ram top is not more then 4GB. This in-turn ensures that U-Boot
> > always runs within 4GB hence DMA addresses generated by DMA mapping
> > APIs will be within 4GB too.
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > Reviewed-by: Alexander Graf <agraf@suse.de>
> > ---
> >  arch/riscv/cpu/generic/dram.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> 
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> 
> But see one comment below:
> 
> > diff --git a/arch/riscv/cpu/generic/dram.c
> > b/arch/riscv/cpu/generic/dram.c index 84d87d2a7f..5725d3c7ae 100644
> > --- a/arch/riscv/cpu/generic/dram.c
> > +++ b/arch/riscv/cpu/generic/dram.c
> > @@ -5,6 +5,9 @@
> >
> >  #include <common.h>
> >  #include <fdtdec.h>
> > +#include <linux/sizes.h>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> >
> >  int dram_init(void)
> >  {
> > @@ -15,3 +18,20 @@ int dram_init_banksize(void)  {
> >         return fdtdec_setup_memory_banksize();  }
> > +
> > +ulong board_get_usable_ram_top(ulong total_size) { #ifdef
> > +CONFIG_64BIT
> > +       /*
> > +        * Ensure that we run from first 4GB so that all
> > +        * addresses used by U-Boot are 32bit addresses.
> > +        *
> > +        * This in-turn ensures that 32bit DMA capabale
> > +        * devices work fine because DMA mapping APIs will
> > +        * provide 32bit DMA addresses only.
> > +        */
> > +       if (gd->ram_top > SZ_4G)
> > +               return SZ_4G;
> > +#endif
> > +       return gd->ram_top;
> > +}
> 
> I was wondering whether we should change this for 32-bit too, given it's a
> valid configuration to have more than 4GB memory in a 32-bit system.

We had considered this but "gd->ram_top" is "unsigned long" so on
32bit system it will be 32bit only. In other words, value of "gd->ram_top"
on 32bit system can never exceed 4GB.

Regards,
Anup

[U-Boot] [PATCH v2 04/11] net: macb: Fix clk API usage for RISC-V systems

[Anup Patel]

This patch does following fixes in MACB ethernet driver
for using it on RISC-V systems (particularly QEMU sifive_u
machine):
1. asm/arch/clk.h is not available on RISC-V port so include
   it only for non-RISC-V systems.
2. Don't fail in macb_enable_clk() if clk_enable() returns
   -ENOSYS because we get -ENOSYS for fixed-rate clocks.

Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
 drivers/net/macb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 94c89c762b..9a06b523cc 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -38,7 +38,9 @@
 #include <linux/mii.h>
 #include <asm/io.h>
 #include <asm/dma-mapping.h>
+#ifndef CONFIG_RISCV
 #include <asm/arch/clk.h>
+#endif
 #include <linux/errno.h>
 
 #include "macb.h"
@@ -1066,7 +1068,7 @@ static int macb_enable_clk(struct udevice *dev)
 	 */
 #ifndef CONFIG_MACB_ZYNQ
 	ret = clk_enable(&clk);
-	if (ret)
+	if (ret && ret != -ENOSYS)
 		return ret;
 #endif
 
-- 
2.17.1

[U-Boot] [PATCH v2 05/11] net: macb: Fix GEM hardware detection

[Anup Patel]

From: Atish Patra <atish.patra@wdc.com>

Fix MID bit field check to correctly identify all GEM hardwares.

The check is updated as per macb driver in Linux location:
<linux_sources>/drivers/net/ethernet/cadence/macb_main.c:259

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 drivers/net/macb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 9a06b523cc..e04ec9a0a3 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -145,7 +145,7 @@ struct macb_device {
 
 static int macb_is_gem(struct macb_device *macb)
 {
-	return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) == 0x2;
+	return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) >= 0x2;
 }
 
 #ifndef cpu_is_sama5d2
-- 
2.17.1

[U-Boot] [PATCH v2 05/11] net: macb: Fix GEM hardware detection

[Alexander Graf]

On 18.01.19 12:19, Anup Patel wrote:
> From: Atish Patra <atish.patra@wdc.com>
> 
> Fix MID bit field check to correctly identify all GEM hardwares.
> 
> The check is updated as per macb driver in Linux location:
> <linux_sources>/drivers/net/ethernet/cadence/macb_main.c:259
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>

This is missing your SoB.


Alex

> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  drivers/net/macb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 9a06b523cc..e04ec9a0a3 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -145,7 +145,7 @@ struct macb_device {
>  
>  static int macb_is_gem(struct macb_device *macb)
>  {
> -	return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) == 0x2;
> +	return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) >= 0x2;
>  }
>  
>  #ifndef cpu_is_sama5d2
> 

[U-Boot] [PATCH v2 05/11] net: macb: Fix GEM hardware detection

[Anup Patel]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Friday, January 18, 2019 5:22 PM
> To: Anup Patel <Anup.Patel@wdc.com>; Rick Chen <rick@andestech.com>;
> Bin Meng <bmeng.cn@gmail.com>; Joe Hershberger
> <joe.hershberger@ni.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
> Masahiro Yamada <yamada.masahiro@socionext.com>; Simon Glass
> <sjg@chromium.org>
> Cc: Palmer Dabbelt <palmer@sifive.com>; Paul Walmsley
> <paul.walmsley@sifive.com>; Atish Patra <Atish.Patra@wdc.com>;
> Christoph Hellwig <hch@infradead.org>; U-Boot Mailing List <u-
> boot at lists.denx.de>
> Subject: Re: [PATCH v2 05/11] net: macb: Fix GEM hardware detection
> 
> 
> 
> On 18.01.19 12:19, Anup Patel wrote:
> > From: Atish Patra <atish.patra@wdc.com>
> >
> > Fix MID bit field check to correctly identify all GEM hardwares.
> >
> > The check is updated as per macb driver in Linux location:
> > <linux_sources>/drivers/net/ethernet/cadence/macb_main.c:259
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> 
> This is missing your SoB.

Sure, I will add my SoB.

Since the work was done by Atish independently, I thought my
SoB is not required.

Regards,
Anup

[U-Boot] [PATCH v2 05/11] net: macb: Fix GEM hardware detection

[Alexander Graf]

On 18.01.19 14:03, Anup Patel wrote:
> 
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Friday, January 18, 2019 5:22 PM
>> To: Anup Patel <Anup.Patel@wdc.com>; Rick Chen <rick@andestech.com>;
>> Bin Meng <bmeng.cn@gmail.com>; Joe Hershberger
>> <joe.hershberger@ni.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
>> Masahiro Yamada <yamada.masahiro@socionext.com>; Simon Glass
>> <sjg@chromium.org>
>> Cc: Palmer Dabbelt <palmer@sifive.com>; Paul Walmsley
>> <paul.walmsley@sifive.com>; Atish Patra <Atish.Patra@wdc.com>;
>> Christoph Hellwig <hch@infradead.org>; U-Boot Mailing List <u-
>> boot at lists.denx.de>
>> Subject: Re: [PATCH v2 05/11] net: macb: Fix GEM hardware detection
>>
>>
>>
>> On 18.01.19 12:19, Anup Patel wrote:
>>> From: Atish Patra <atish.patra@wdc.com>
>>>
>>> Fix MID bit field check to correctly identify all GEM hardwares.
>>>
>>> The check is updated as per macb driver in Linux location:
>>> <linux_sources>/drivers/net/ethernet/cadence/macb_main.c:259
>>>
>>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>>
>> This is missing your SoB.
> 
> Sure, I will add my SoB.
> 
> Since the work was done by Atish independently, I thought my
> SoB is not required.

Imagine the SoB as a marker for "this went through my hands". If you
send a patch from someone else - even though you did modify a single
line - it still went through your hands and thus your SoB should occur
at the end.

Similarly the first SoB usually means "this was the original author".

So imagine you started to work on a patch, then Atish improved it and
eventually you send it out, the SoB chain would look like this:

  Signed-off-by: Anup Patel <Anup.Patel@wdc.com>
  Signed-off-by: Atish Patra <atish.patra@wdc.com>
  Signed-off-by: Anup Patel <Anup.Patel@wdc.com>

But you don't have to be too nit-picky about that part. The one thing
people will care about is that the original author is in the SoB list
and that your SoB is at the end of the list, because you are the one
sending the patch set.


Alex

[U-Boot] [PATCH v2 05/11] net: macb: Fix GEM hardware detection

[Anup Patel]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Friday, January 18, 2019 6:41 PM
> To: Anup Patel <Anup.Patel@wdc.com>; Rick Chen <rick@andestech.com>;
> Bin Meng <bmeng.cn@gmail.com>; Joe Hershberger
> <joe.hershberger@ni.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
> Masahiro Yamada <yamada.masahiro@socionext.com>; Simon Glass
> <sjg@chromium.org>
> Cc: Palmer Dabbelt <palmer@sifive.com>; Paul Walmsley
> <paul.walmsley@sifive.com>; Atish Patra <Atish.Patra@wdc.com>;
> Christoph Hellwig <hch@infradead.org>; U-Boot Mailing List <u-
> boot at lists.denx.de>
> Subject: Re: [PATCH v2 05/11] net: macb: Fix GEM hardware detection
> 
> 
> 
> On 18.01.19 14:03, Anup Patel wrote:
> >
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf at suse.de]
> >> Sent: Friday, January 18, 2019 5:22 PM
> >> To: Anup Patel <Anup.Patel@wdc.com>; Rick Chen
> <rick@andestech.com>;
> >> Bin Meng <bmeng.cn@gmail.com>; Joe Hershberger
> >> <joe.hershberger@ni.com>; Lukas Auer
> >> <lukas.auer@aisec.fraunhofer.de>; Masahiro Yamada
> >> <yamada.masahiro@socionext.com>; Simon Glass <sjg@chromium.org>
> >> Cc: Palmer Dabbelt <palmer@sifive.com>; Paul Walmsley
> >> <paul.walmsley@sifive.com>; Atish Patra <Atish.Patra@wdc.com>;
> >> Christoph Hellwig <hch@infradead.org>; U-Boot Mailing List <u-
> >> boot at lists.denx.de>
> >> Subject: Re: [PATCH v2 05/11] net: macb: Fix GEM hardware detection
> >>
> >>
> >>
> >> On 18.01.19 12:19, Anup Patel wrote:
> >>> From: Atish Patra <atish.patra@wdc.com>
> >>>
> >>> Fix MID bit field check to correctly identify all GEM hardwares.
> >>>
> >>> The check is updated as per macb driver in Linux location:
> >>> <linux_sources>/drivers/net/ethernet/cadence/macb_main.c:259
> >>>
> >>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> >>
> >> This is missing your SoB.
> >
> > Sure, I will add my SoB.
> >
> > Since the work was done by Atish independently, I thought my SoB is
> > not required.
> 
> Imagine the SoB as a marker for "this went through my hands". If you send a
> patch from someone else - even though you did modify a single line - it still
> went through your hands and thus your SoB should occur at the end.
> 
> Similarly the first SoB usually means "this was the original author".
> 
> So imagine you started to work on a patch, then Atish improved it and
> eventually you send it out, the SoB chain would look like this:
> 
>   Signed-off-by: Anup Patel <Anup.Patel@wdc.com>
>   Signed-off-by: Atish Patra <atish.patra@wdc.com>
>   Signed-off-by: Anup Patel <Anup.Patel@wdc.com>
> 
> But you don't have to be too nit-picky about that part. The one thing people
> will care about is that the original author is in the SoB list and that your SoB is
> at the end of the list, because you are the one sending the patch set.

Thanks for the info.

I was not aware of this convention around SoB.

Regards,
Anup

[U-Boot] [PATCH v2 05/11] net: macb: Fix GEM hardware detection

[Auer, Lukas]

On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> From: Atish Patra <atish.patra@wdc.com>
> 
> Fix MID bit field check to correctly identify all GEM hardwares.
> 
> The check is updated as per macb driver in Linux location:
> <linux_sources>/drivers/net/ethernet/cadence/macb_main.c:259
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  drivers/net/macb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>

[U-Boot] [PATCH v2 06/11] clk: Add SiFive FU540 PRCI clock driver

[Anup Patel]

Add driver code for the SiFive FU540 PRCI IP block.  This IP block
handles reset and clock control for the SiFive FU540 device and
implements SoC-level clock tree controls and dividers.

Based on code written by Wesley Terpstra <wesley@sifive.com>
found in commit 999529edf517ed75b56659d456d221b2ee56bb60 of:
https://github.com/riscv/riscv-linux

Boot and PLL rate change were tested on a SiFive HiFive Unleashed
board.

Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 drivers/clk/Kconfig                           |   1 +
 drivers/clk/Makefile                          |   1 +
 drivers/clk/sifive/Kconfig                    |  19 +
 drivers/clk/sifive/Makefile                   |   5 +
 .../clk/sifive/analogbits-wrpll-cln28hpc.h    | 101 +++
 drivers/clk/sifive/fu540-prci.c               | 604 ++++++++++++++++++
 drivers/clk/sifive/wrpll-cln28hpc.c           | 390 +++++++++++
 include/dt-bindings/clk/sifive-fu540-prci.h   |  29 +
 8 files changed, 1150 insertions(+)
 create mode 100644 drivers/clk/sifive/Kconfig
 create mode 100644 drivers/clk/sifive/Makefile
 create mode 100644 drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
 create mode 100644 drivers/clk/sifive/fu540-prci.c
 create mode 100644 drivers/clk/sifive/wrpll-cln28hpc.c
 create mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index eadf7f8250..ce462f5717 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -104,6 +104,7 @@ source "drivers/clk/imx/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/owl/Kconfig"
 source "drivers/clk/renesas/Kconfig"
+source "drivers/clk/sifive/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 9acbb1a650..2f4446568c 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
 obj-$(CONFIG_CLK_OWL) += owl/
 obj-$(CONFIG_CLK_RENESAS) += renesas/
+obj-$(CONFIG_CLK_SIFIVE) += sifive/
 obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
 obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
 obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
new file mode 100644
index 0000000000..81fc9f8fda
--- /dev/null
+++ b/drivers/clk/sifive/Kconfig
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config CLK_ANALOGBITS_WRPLL_CLN28HPC
+	bool
+
+config CLK_SIFIVE
+	bool "SiFive SoC driver support"
+	depends on CLK
+	help
+	  SoC drivers for SiFive Linux-capable SoCs.
+
+config CLK_SIFIVE_FU540_PRCI
+	bool "PRCI driver for SiFive FU540 SoCs"
+	depends on CLK_SIFIVE
+	select CLK_ANALOGBITS_WRPLL_CLN28HPC
+	help
+	  Supports the Power Reset Clock interface (PRCI) IP block found in
+	  FU540 SoCs.  If this kernel is meant to run on a SiFive FU540 SoC,
+	  enable this driver.
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
new file mode 100644
index 0000000000..1155e07e37
--- /dev/null
+++ b/drivers/clk/sifive/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_CLK_ANALOGBITS_WRPLL_CLN28HPC)	+= wrpll-cln28hpc.o
+
+obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)		+= fu540-prci.o
diff --git a/drivers/clk/sifive/analogbits-wrpll-cln28hpc.h b/drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
new file mode 100644
index 0000000000..4432e24749
--- /dev/null
+++ b/drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
@@ -0,0 +1,101 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Copyright (C) 2018 SiFive, Inc.
+ * Wesley Terpstra
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __LINUX_CLK_ANALOGBITS_WRPLL_CLN28HPC_H
+#define __LINUX_CLK_ANALOGBITS_WRPLL_CLN28HPC_H
+
+#include <linux/types.h>
+
+/* DIVQ_VALUES: number of valid DIVQ values */
+#define DIVQ_VALUES				6
+
+/*
+ * Bit definitions for struct analogbits_wrpll_cfg.flags
+ *
+ * WRPLL_FLAGS_BYPASS_FLAG: if set, the PLL is either in bypass, or should be
+ *	programmed to enter bypass
+ * WRPLL_FLAGS_RESET_FLAG: if set, the PLL is in reset
+ * WRPLL_FLAGS_INT_FEEDBACK_FLAG: if set, the PLL is configured for internal
+ *	feedback mode
+ * WRPLL_FLAGS_EXT_FEEDBACK_FLAG: if set, the PLL is configured for external
+ *	feedback mode (not yet supported by this driver)
+ *
+ * The flags WRPLL_FLAGS_INT_FEEDBACK_FLAG and WRPLL_FLAGS_EXT_FEEDBACK_FLAG are
+ * mutually exclusive.  If both bits are set, or both are zero, the struct
+ * analogbits_wrpll_cfg record is uninitialized or corrupt.
+ */
+#define WRPLL_FLAGS_BYPASS_SHIFT		0
+#define WRPLL_FLAGS_BYPASS_MASK		BIT(WRPLL_FLAGS_BYPASS_SHIFT)
+#define WRPLL_FLAGS_RESET_SHIFT		1
+#define WRPLL_FLAGS_RESET_MASK		BIT(WRPLL_FLAGS_RESET_SHIFT)
+#define WRPLL_FLAGS_INT_FEEDBACK_SHIFT	2
+#define WRPLL_FLAGS_INT_FEEDBACK_MASK	BIT(WRPLL_FLAGS_INT_FEEDBACK_SHIFT)
+#define WRPLL_FLAGS_EXT_FEEDBACK_SHIFT	3
+#define WRPLL_FLAGS_EXT_FEEDBACK_MASK	BIT(WRPLL_FLAGS_EXT_FEEDBACK_SHIFT)
+
+/**
+ * struct analogbits_wrpll_cfg - WRPLL configuration values
+ * @divr: reference divider value (6 bits), as presented to the PLL signals.
+ * @divf: feedback divider value (9 bits), as presented to the PLL signals.
+ * @divq: output divider value (3 bits), as presented to the PLL signals.
+ * @flags: PLL configuration flags.  See above for more information.
+ * @range: PLL loop filter range.  See below for more information.
+ * @_output_rate_cache: cached output rates, swept across DIVQ.
+ * @_parent_rate: PLL refclk rate for which values are valid
+ * @_max_r: maximum possible R divider value, given @parent_rate
+ * @_init_r: initial R divider value to start the search from
+ *
+ * @divr, @divq, @divq, @range represent what the PLL expects to see
+ * on its input signals.  Thus @divr and @divf are the actual divisors
+ * minus one.  @divq is a power-of-two divider; for example, 1 =
+ * divide-by-2 and 6 = divide-by-64.  0 is an invalid @divq value.
+ *
+ * When initially passing a struct analogbits_wrpll_cfg record, the
+ * record should be zero-initialized with the exception of the @flags
+ * field.  The only flag bits that need to be set are either
+ * WRPLL_FLAGS_INT_FEEDBACK or WRPLL_FLAGS_EXT_FEEDBACK.
+ *
+ * Field names beginning with an underscore should be considered
+ * private to the wrpll-cln28hpc.c code.
+ */
+struct analogbits_wrpll_cfg {
+	u8 divr;
+	u8 divq;
+	u8 range;
+	u8 flags;
+	u16 divf;
+	u32 _output_rate_cache[DIVQ_VALUES];
+	unsigned long _parent_rate;
+	u8 _max_r;
+	u8 _init_r;
+};
+
+/*
+ * Function prototypes
+ */
+
+int analogbits_wrpll_configure_for_rate(struct analogbits_wrpll_cfg *c,
+					u32 target_rate,
+					unsigned long parent_rate);
+
+unsigned int analogbits_wrpll_calc_max_lock_us(struct analogbits_wrpll_cfg *c);
+
+unsigned long analogbits_wrpll_calc_output_rate(struct analogbits_wrpll_cfg *c,
+						unsigned long parent_rate);
+
+#endif /* __LINUX_CLK_ANALOGBITS_WRPLL_CLN28HPC_H */
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
new file mode 100644
index 0000000000..e1b5f8e6a9
--- /dev/null
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -0,0 +1,604 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Copyright (C) 2018 SiFive, Inc.
+ * Wesley Terpstra
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * The FU540 PRCI implements clock and reset control for the SiFive
+ * FU540-C000 chip.   This driver assumes that it has sole control
+ * over all PRCI resources.
+ *
+ * This driver is based on the PRCI driver written by Wesley Terpstra.
+ *
+ * Refer, commit 999529edf517ed75b56659d456d221b2ee56bb60 of:
+ * https://github.com/riscv/riscv-linux
+ *
+ * References:
+ * - SiFive FU540-C000 manual v1p0, Chapter 7 "Clocking and Reset"
+ */
+
+#include <asm/io.h>
+#include <clk-uclass.h>
+#include <clk.h>
+#include <common.h>
+#include <div64.h>
+#include <dm.h>
+#include <errno.h>
+
+#include <linux/math64.h>
+#include <dt-bindings/clk/sifive-fu540-prci.h>
+
+#include "analogbits-wrpll-cln28hpc.h"
+
+/*
+ * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
+ *     hfclk and rtcclk
+ */
+#define EXPECTED_CLK_PARENT_COUNT	2
+
+/*
+ * Register offsets and bitmasks
+ */
+
+/* COREPLLCFG0 */
+#define PRCI_COREPLLCFG0_OFFSET		0x4
+#define PRCI_COREPLLCFG0_DIVR_SHIFT	0
+#define PRCI_COREPLLCFG0_DIVR_MASK	(0x3f << PRCI_COREPLLCFG0_DIVR_SHIFT)
+#define PRCI_COREPLLCFG0_DIVF_SHIFT	6
+#define PRCI_COREPLLCFG0_DIVF_MASK	(0x1ff << PRCI_COREPLLCFG0_DIVF_SHIFT)
+#define PRCI_COREPLLCFG0_DIVQ_SHIFT	15
+#define PRCI_COREPLLCFG0_DIVQ_MASK	(0x7 << PRCI_COREPLLCFG0_DIVQ_SHIFT)
+#define PRCI_COREPLLCFG0_RANGE_SHIFT	18
+#define PRCI_COREPLLCFG0_RANGE_MASK	(0x7 << PRCI_COREPLLCFG0_RANGE_SHIFT)
+#define PRCI_COREPLLCFG0_BYPASS_SHIFT	24
+#define PRCI_COREPLLCFG0_BYPASS_MASK	(0x1 << PRCI_COREPLLCFG0_BYPASS_SHIFT)
+#define PRCI_COREPLLCFG0_FSE_SHIFT	25
+#define PRCI_COREPLLCFG0_FSE_MASK	(0x1 << PRCI_COREPLLCFG0_FSE_SHIFT)
+#define PRCI_COREPLLCFG0_LOCK_SHIFT	31
+#define PRCI_COREPLLCFG0_LOCK_MASK	(0x1 << PRCI_COREPLLCFG0_LOCK_SHIFT)
+
+/* DDRPLLCFG0 */
+#define PRCI_DDRPLLCFG0_OFFSET		0xc
+#define PRCI_DDRPLLCFG0_DIVR_SHIFT	0
+#define PRCI_DDRPLLCFG0_DIVR_MASK	(0x3f << PRCI_DDRPLLCFG0_DIVR_SHIFT)
+#define PRCI_DDRPLLCFG0_DIVF_SHIFT	6
+#define PRCI_DDRPLLCFG0_DIVF_MASK	(0x1ff << PRCI_DDRPLLCFG0_DIVF_SHIFT)
+#define PRCI_DDRPLLCFG0_DIVQ_SHIFT	15
+#define PRCI_DDRPLLCFG0_DIVQ_MASK	(0x7 << PRCI_DDRPLLCFG0_DIVQ_SHIFT)
+#define PRCI_DDRPLLCFG0_RANGE_SHIFT	18
+#define PRCI_DDRPLLCFG0_RANGE_MASK	(0x7 << PRCI_DDRPLLCFG0_RANGE_SHIFT)
+#define PRCI_DDRPLLCFG0_BYPASS_SHIFT	24
+#define PRCI_DDRPLLCFG0_BYPASS_MASK	(0x1 << PRCI_DDRPLLCFG0_BYPASS_SHIFT)
+#define PRCI_DDRPLLCFG0_FSE_SHIFT	25
+#define PRCI_DDRPLLCFG0_FSE_MASK	(0x1 << PRCI_DDRPLLCFG0_FSE_SHIFT)
+#define PRCI_DDRPLLCFG0_LOCK_SHIFT	31
+#define PRCI_DDRPLLCFG0_LOCK_MASK	(0x1 << PRCI_DDRPLLCFG0_LOCK_SHIFT)
+
+/* DDRPLLCFG1 */
+#define PRCI_DDRPLLCFG1_OFFSET		0x10
+#define PRCI_DDRPLLCFG1_CKE_SHIFT	24
+#define PRCI_DDRPLLCFG1_CKE_MASK	(0x1 << PRCI_DDRPLLCFG1_CKE_SHIFT)
+
+/* GEMGXLPLLCFG0 */
+#define PRCI_GEMGXLPLLCFG0_OFFSET	0x1c
+#define PRCI_GEMGXLPLLCFG0_DIVR_SHIFT	0
+#define PRCI_GEMGXLPLLCFG0_DIVR_MASK	\
+			(0x3f << PRCI_GEMGXLPLLCFG0_DIVR_SHIFT)
+#define PRCI_GEMGXLPLLCFG0_DIVF_SHIFT	6
+#define PRCI_GEMGXLPLLCFG0_DIVF_MASK	\
+			(0x1ff << PRCI_GEMGXLPLLCFG0_DIVF_SHIFT)
+#define PRCI_GEMGXLPLLCFG0_DIVQ_SHIFT	15
+#define PRCI_GEMGXLPLLCFG0_DIVQ_MASK	(0x7 << PRCI_GEMGXLPLLCFG0_DIVQ_SHIFT)
+#define PRCI_GEMGXLPLLCFG0_RANGE_SHIFT	18
+#define PRCI_GEMGXLPLLCFG0_RANGE_MASK	\
+			(0x7 << PRCI_GEMGXLPLLCFG0_RANGE_SHIFT)
+#define PRCI_GEMGXLPLLCFG0_BYPASS_SHIFT 24
+#define PRCI_GEMGXLPLLCFG0_BYPASS_MASK	\
+			(0x1 << PRCI_GEMGXLPLLCFG0_BYPASS_SHIFT)
+#define PRCI_GEMGXLPLLCFG0_FSE_SHIFT	25
+#define PRCI_GEMGXLPLLCFG0_FSE_MASK	\
+			(0x1 << PRCI_GEMGXLPLLCFG0_FSE_SHIFT)
+#define PRCI_GEMGXLPLLCFG0_LOCK_SHIFT	31
+#define PRCI_GEMGXLPLLCFG0_LOCK_MASK	(0x1 << PRCI_GEMGXLPLLCFG0_LOCK_SHIFT)
+
+/* GEMGXLPLLCFG1 */
+#define PRCI_GEMGXLPLLCFG1_OFFSET	0x20
+#define PRCI_GEMGXLPLLCFG1_CKE_SHIFT	24
+#define PRCI_GEMGXLPLLCFG1_CKE_MASK	(0x1 << PRCI_GEMGXLPLLCFG1_CKE_SHIFT)
+
+/* CORECLKSEL */
+#define PRCI_CORECLKSEL_OFFSET		0x24
+#define PRCI_CORECLKSEL_CORECLKSEL_SHIFT 0
+#define PRCI_CORECLKSEL_CORECLKSEL_MASK \
+			(0x1 << PRCI_CORECLKSEL_CORECLKSEL_SHIFT)
+
+/* DEVICESRESETREG */
+#define PRCI_DEVICESRESETREG_OFFSET	0x28
+#define PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_SHIFT 0
+#define PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_MASK \
+			(0x1 << PRCI_DEVICESRESETREG_DDR_CTRL_RST_N_SHIFT)
+#define PRCI_DEVICESRESETREG_DDR_AXI_RST_N_SHIFT 1
+#define PRCI_DEVICESRESETREG_DDR_AXI_RST_N_MASK \
+			(0x1 << PRCI_DEVICESRESETREG_DDR_AXI_RST_N_SHIFT)
+#define PRCI_DEVICESRESETREG_DDR_AHB_RST_N_SHIFT 2
+#define PRCI_DEVICESRESETREG_DDR_AHB_RST_N_MASK \
+			(0x1 << PRCI_DEVICESRESETREG_DDR_AHB_RST_N_SHIFT)
+#define PRCI_DEVICESRESETREG_DDR_PHY_RST_N_SHIFT 3
+#define PRCI_DEVICESRESETREG_DDR_PHY_RST_N_MASK \
+			(0x1 << PRCI_DEVICESRESETREG_DDR_PHY_RST_N_SHIFT)
+#define PRCI_DEVICESRESETREG_GEMGXL_RST_N_SHIFT 5
+#define PRCI_DEVICESRESETREG_GEMGXL_RST_N_MASK \
+			(0x1 << PRCI_DEVICESRESETREG_GEMGXL_RST_N_SHIFT)
+
+/* CLKMUXSTATUSREG */
+#define PRCI_CLKMUXSTATUSREG_OFFSET		0x2c
+#define PRCI_CLKMUXSTATUSREG_TLCLKSEL_STATUS_SHIFT 1
+#define PRCI_CLKMUXSTATUSREG_TLCLKSEL_STATUS_MASK \
+			(0x1 << PRCI_CLKMUXSTATUSREG_TLCLKSEL_STATUS_SHIFT)
+
+/*
+ * Private structures
+ */
+
+/**
+ * struct __prci_data - per-device-instance data
+ * @va: base virtual address of the PRCI IP block
+ * @parent: parent clk instance
+ *
+ * PRCI per-device instance data
+ */
+struct __prci_data {
+	void *base;
+	struct clk parent;
+};
+
+/**
+ * struct __prci_wrpll_data - WRPLL configuration and integration data
+ * @c: WRPLL current configuration record
+ * @bypass: fn ptr to code to bypass the WRPLL (if applicable; else NULL)
+ * @no_bypass: fn ptr to code to not bypass the WRPLL (if applicable; else NULL)
+ * @cfg0_offs: WRPLL CFG0 register offset (in bytes) from the PRCI base address
+ *
+ * @bypass and @no_bypass are used for WRPLL instances that contain a separate
+ * external glitchless clock mux downstream from the PLL.  The WRPLL internal
+ * bypass mux is not glitchless.
+ */
+struct __prci_wrpll_data {
+	struct analogbits_wrpll_cfg c;
+	void (*bypass)(struct __prci_data *pd);
+	void (*no_bypass)(struct __prci_data *pd);
+	u8 cfg0_offs;
+};
+
+struct __prci_clock;
+
+struct __prci_clock_ops {
+	int (*set_rate)(struct __prci_clock *pc,
+			unsigned long rate,
+			unsigned long parent_rate);
+	unsigned long (*round_rate)(struct __prci_clock *pc,
+				    unsigned long rate,
+				    unsigned long *parent_rate);
+	unsigned long (*recalc_rate)(struct __prci_clock *pc,
+				     unsigned long parent_rate);
+};
+
+/**
+ * struct __prci_clock - describes a clock device managed by PRCI
+ * @name: user-readable clock name string - should match the manual
+ * @parent_name: parent name for this clock
+ * @ops: struct clk_ops for the Linux clock framework to use for control
+ * @hw: Linux-private clock data
+ * @pwd: WRPLL-specific data, associated with this clock (if not NULL)
+ * @pd: PRCI-specific data associated with this clock (if not NULL)
+ *
+ * PRCI clock data.  Used by the PRCI driver to register PRCI-provided
+ * clocks to the Linux clock infrastructure.
+ */
+struct __prci_clock {
+	const char *name;
+	const char *parent_name;
+	const struct __prci_clock_ops *ops;
+	struct __prci_wrpll_data *pwd;
+	struct __prci_data *pd;
+};
+
+/*
+ * Private functions
+ */
+
+/**
+ * __prci_readl() - read from a PRCI register
+ * @pd: PRCI context
+ * @offs: register offset to read from (in bytes, from PRCI base address)
+ *
+ * Read the register located@offset @offs from the base virtual
+ * address of the PRCI register target described by @pd, and return
+ * the value to the caller.
+ *
+ * Context: Any context.
+ *
+ * Return: the contents of the register described by @pd and @offs.
+ */
+static u32 __prci_readl(struct __prci_data *pd, u32 offs)
+{
+	return readl(pd->base + offs);
+}
+
+static void __prci_writel(u32 v, u32 offs, struct __prci_data *pd)
+{
+	return writel(v, pd->base + offs);
+}
+
+/* WRPLL-related private functions */
+
+/**
+ * __prci_wrpll_unpack() - unpack WRPLL configuration registers into parameters
+ * @c: ptr to a struct analogbits_wrpll_cfg record to write config into
+ * @r: value read from the PRCI PLL configuration register
+ *
+ * Given a value @r read from an FU540 PRCI PLL configuration register,
+ * split it into fields and populate it into the WRPLL configuration record
+ * pointed to by @c.
+ *
+ * The COREPLLCFG0 macros are used below, but the other *PLLCFG0 macros
+ * have the same register layout.
+ *
+ * Context: Any context.
+ */
+static void __prci_wrpll_unpack(struct analogbits_wrpll_cfg *c, u32 r)
+{
+	u32 v;
+
+	v = r & PRCI_COREPLLCFG0_DIVR_MASK;
+	v >>= PRCI_COREPLLCFG0_DIVR_SHIFT;
+	c->divr = v;
+
+	v = r & PRCI_COREPLLCFG0_DIVF_MASK;
+	v >>= PRCI_COREPLLCFG0_DIVF_SHIFT;
+	c->divf = v;
+
+	v = r & PRCI_COREPLLCFG0_DIVQ_MASK;
+	v >>= PRCI_COREPLLCFG0_DIVQ_SHIFT;
+	c->divq = v;
+
+	v = r & PRCI_COREPLLCFG0_RANGE_MASK;
+	v >>= PRCI_COREPLLCFG0_RANGE_SHIFT;
+	c->range = v;
+
+	c->flags &= (WRPLL_FLAGS_INT_FEEDBACK_MASK |
+		     WRPLL_FLAGS_EXT_FEEDBACK_MASK);
+
+	if (r & PRCI_COREPLLCFG0_FSE_MASK)
+		c->flags |= WRPLL_FLAGS_INT_FEEDBACK_MASK;
+	else
+		c->flags |= WRPLL_FLAGS_EXT_FEEDBACK_MASK;
+}
+
+/**
+ * __prci_wrpll_pack() - pack PLL configuration parameters into a register value
+ * @c: pointer to a struct analogbits_wrpll_cfg record containing the PLL's cfg
+ *
+ * Using a set of WRPLL configuration values pointed to by @c,
+ * assemble a PRCI PLL configuration register value, and return it to
+ * the caller.
+ *
+ * Context: Any context.  Caller must ensure that the contents of the
+ *          record pointed to by @c do not change during the execution
+ *          of this function.
+ *
+ * Returns: a value suitable for writing into a PRCI PLL configuration
+ *          register
+ */
+static u32 __prci_wrpll_pack(struct analogbits_wrpll_cfg *c)
+{
+	u32 r = 0;
+
+	r |= c->divr << PRCI_COREPLLCFG0_DIVR_SHIFT;
+	r |= c->divf << PRCI_COREPLLCFG0_DIVF_SHIFT;
+	r |= c->divq << PRCI_COREPLLCFG0_DIVQ_SHIFT;
+	r |= c->range << PRCI_COREPLLCFG0_RANGE_SHIFT;
+	if (c->flags & WRPLL_FLAGS_INT_FEEDBACK_MASK)
+		r |= PRCI_COREPLLCFG0_FSE_MASK;
+
+	return r;
+}
+
+/**
+ * __prci_wrpll_read_cfg() - read the WRPLL configuration from the PRCI
+ * @pd: PRCI context
+ * @pwd: PRCI WRPLL metadata
+ *
+ * Read the current configuration of the PLL identified by @pwd from
+ * the PRCI identified by @pd, and store it into the local configuration
+ * cache in @pwd.
+ *
+ * Context: Any context.  Caller must prevent the records pointed to by
+ *          @pd and @pwd from changing during execution.
+ */
+static void __prci_wrpll_read_cfg(struct __prci_data *pd,
+				  struct __prci_wrpll_data *pwd)
+{
+	__prci_wrpll_unpack(&pwd->c, __prci_readl(pd, pwd->cfg0_offs));
+}
+
+/**
+ * __prci_wrpll_write_cfg() - write WRPLL configuration into the PRCI
+ * @pd: PRCI context
+ * @pwd: PRCI WRPLL metadata
+ * @c: WRPLL configuration record to write
+ *
+ * Write the WRPLL configuration described by @c into the WRPLL
+ * configuration register identified by @pwd in the PRCI instance
+ * described by @c.  Make a cached copy of the WRPLL's current
+ * configuration so it can be used by other code.
+ *
+ * Context: Any context.  Caller must prevent the records pointed to by
+ *          @pd and @pwd from changing during execution.
+ */
+static void __prci_wrpll_write_cfg(struct __prci_data *pd,
+				   struct __prci_wrpll_data *pwd,
+				   struct analogbits_wrpll_cfg *c)
+{
+	__prci_writel(__prci_wrpll_pack(c), pwd->cfg0_offs, pd);
+
+	memcpy(&pwd->c, c, sizeof(struct analogbits_wrpll_cfg));
+}
+
+/* Core clock mux control */
+
+/**
+ * __prci_coreclksel_use_hfclk() - switch the CORECLK mux to output HFCLK
+ * @pd: struct __prci_data * for the PRCI containing the CORECLK mux reg
+ *
+ * Switch the CORECLK mux to the HFCLK input source; return once complete.
+ *
+ * Context: Any context.  Caller must prevent concurrent changes to the
+ *          PRCI_CORECLKSEL_OFFSET register.
+ */
+static void __prci_coreclksel_use_hfclk(struct __prci_data *pd)
+{
+	u32 r;
+
+	r = __prci_readl(pd, PRCI_CORECLKSEL_OFFSET);
+	r |= PRCI_CORECLKSEL_CORECLKSEL_MASK;
+	__prci_writel(r, PRCI_CORECLKSEL_OFFSET, pd);
+
+	r = __prci_readl(pd, PRCI_CORECLKSEL_OFFSET); /* barrier */
+}
+
+/**
+ * __prci_coreclksel_use_corepll() - switch the CORECLK mux to output COREPLL
+ * @pd: struct __prci_data * for the PRCI containing the CORECLK mux reg
+ *
+ * Switch the CORECLK mux to the PLL output clock; return once complete.
+ *
+ * Context: Any context.  Caller must prevent concurrent changes to the
+ *          PRCI_CORECLKSEL_OFFSET register.
+ */
+static void __prci_coreclksel_use_corepll(struct __prci_data *pd)
+{
+	u32 r;
+
+	r = __prci_readl(pd, PRCI_CORECLKSEL_OFFSET);
+	r &= ~PRCI_CORECLKSEL_CORECLKSEL_MASK;
+	__prci_writel(r, PRCI_CORECLKSEL_OFFSET, pd);
+
+	r = __prci_readl(pd, PRCI_CORECLKSEL_OFFSET); /* barrier */
+}
+
+static unsigned long sifive_fu540_prci_wrpll_recalc_rate(
+						struct __prci_clock *pc,
+						unsigned long parent_rate)
+{
+	struct __prci_wrpll_data *pwd = pc->pwd;
+
+	return analogbits_wrpll_calc_output_rate(&pwd->c, parent_rate);
+}
+
+static unsigned long sifive_fu540_prci_wrpll_round_rate(
+						struct __prci_clock *pc,
+						unsigned long rate,
+						unsigned long *parent_rate)
+{
+	struct __prci_wrpll_data *pwd = pc->pwd;
+	struct analogbits_wrpll_cfg c;
+
+	memcpy(&c, &pwd->c, sizeof(c));
+
+	analogbits_wrpll_configure_for_rate(&c, rate, *parent_rate);
+
+	return analogbits_wrpll_calc_output_rate(&c, *parent_rate);
+}
+
+static int sifive_fu540_prci_wrpll_set_rate(struct __prci_clock *pc,
+					    unsigned long rate,
+					    unsigned long parent_rate)
+{
+	struct __prci_wrpll_data *pwd = pc->pwd;
+	struct __prci_data *pd = pc->pd;
+	int r;
+
+	r = analogbits_wrpll_configure_for_rate(&pwd->c, rate, parent_rate);
+	if (r)
+		return -ERANGE;
+
+	if (pwd->bypass)
+		pwd->bypass(pd);
+
+	__prci_wrpll_write_cfg(pd, pwd, &pwd->c);
+
+	udelay(analogbits_wrpll_calc_max_lock_us(&pwd->c));
+
+	if (pwd->no_bypass)
+		pwd->no_bypass(pd);
+
+	return 0;
+}
+
+static const struct __prci_clock_ops sifive_fu540_prci_wrpll_clk_ops = {
+	.set_rate = sifive_fu540_prci_wrpll_set_rate,
+	.round_rate = sifive_fu540_prci_wrpll_round_rate,
+	.recalc_rate = sifive_fu540_prci_wrpll_recalc_rate,
+};
+
+static const struct __prci_clock_ops sifive_fu540_prci_wrpll_ro_clk_ops = {
+	.recalc_rate = sifive_fu540_prci_wrpll_recalc_rate,
+};
+
+/* TLCLKSEL clock integration */
+
+static unsigned long sifive_fu540_prci_tlclksel_recalc_rate(
+						struct __prci_clock *pc,
+						unsigned long parent_rate)
+{
+	struct __prci_data *pd = pc->pd;
+	u32 v;
+	u8 div;
+
+	v = __prci_readl(pd, PRCI_CLKMUXSTATUSREG_OFFSET);
+	v &= PRCI_CLKMUXSTATUSREG_TLCLKSEL_STATUS_MASK;
+	div = v ? 1 : 2;
+
+	return div_u64(parent_rate, div);
+}
+
+static const struct __prci_clock_ops sifive_fu540_prci_tlclksel_clk_ops = {
+	.recalc_rate = sifive_fu540_prci_tlclksel_recalc_rate,
+};
+
+/*
+ * PRCI integration data for each WRPLL instance
+ */
+
+static struct __prci_wrpll_data __prci_corepll_data = {
+	.cfg0_offs = PRCI_COREPLLCFG0_OFFSET,
+	.bypass = __prci_coreclksel_use_hfclk,
+	.no_bypass = __prci_coreclksel_use_corepll,
+};
+
+static struct __prci_wrpll_data __prci_ddrpll_data = {
+	.cfg0_offs = PRCI_DDRPLLCFG0_OFFSET,
+};
+
+static struct __prci_wrpll_data __prci_gemgxlpll_data = {
+	.cfg0_offs = PRCI_GEMGXLPLLCFG0_OFFSET,
+};
+
+/*
+ * List of clock controls provided by the PRCI
+ */
+
+static struct __prci_clock __prci_init_clocks[] = {
+	[PRCI_CLK_COREPLL] = {
+		.name = "corepll",
+		.parent_name = "hfclk",
+		.ops = &sifive_fu540_prci_wrpll_clk_ops,
+		.pwd = &__prci_corepll_data,
+	},
+	[PRCI_CLK_DDRPLL] = {
+		.name = "ddrpll",
+		.parent_name = "hfclk",
+		.ops = &sifive_fu540_prci_wrpll_ro_clk_ops,
+		.pwd = &__prci_ddrpll_data,
+	},
+	[PRCI_CLK_GEMGXLPLL] = {
+		.name = "gemgxlpll",
+		.parent_name = "hfclk",
+		.ops = &sifive_fu540_prci_wrpll_clk_ops,
+		.pwd = &__prci_gemgxlpll_data,
+	},
+	[PRCI_CLK_TLCLK] = {
+		.name = "tlclk",
+		.parent_name = "corepll",
+		.ops = &sifive_fu540_prci_tlclksel_clk_ops,
+	},
+};
+
+static ulong sifive_fu540_prci_get_rate(struct clk *clk)
+{
+	struct __prci_clock *pc;
+
+	if (ARRAY_SIZE(__prci_init_clocks) <= clk->id)
+		return -ENXIO;
+
+	pc = &__prci_init_clocks[clk->id];
+	if (!pc->pd || !pc->ops->recalc_rate)
+		return -ENXIO;
+
+	return pc->ops->recalc_rate(pc, clk_get_rate(&pc->pd->parent));
+}
+
+static ulong sifive_fu540_prci_set_rate(struct clk *clk, ulong rate)
+{
+	int err;
+	struct __prci_clock *pc;
+
+	if (ARRAY_SIZE(__prci_init_clocks) <= clk->id)
+		return -ENXIO;
+
+	pc = &__prci_init_clocks[clk->id];
+	if (!pc->pd || !pc->ops->set_rate)
+		return -ENXIO;
+
+	err = pc->ops->set_rate(pc, rate, clk_get_rate(&pc->pd->parent));
+	if (err)
+		return err;
+
+	return rate;
+}
+
+static int sifive_fu540_prci_probe(struct udevice *dev)
+{
+	int i, err;
+	struct __prci_clock *pc;
+	struct __prci_data *pd = dev_get_priv(dev);
+
+	pd->base = (void *)dev_read_addr(dev);
+	if (IS_ERR(pd->base))
+		return PTR_ERR(pd->base);
+
+	err = clk_get_by_index(dev, 0, &pd->parent);
+	if (err)
+		return err;
+
+	for (i = 0; i < ARRAY_SIZE(__prci_init_clocks); ++i) {
+		pc = &__prci_init_clocks[i];
+		pc->pd = pd;
+		if (pc->pwd)
+			__prci_wrpll_read_cfg(pd, pc->pwd);
+	}
+
+	return 0;
+}
+
+static struct clk_ops sifive_fu540_prci_ops = {
+	.set_rate = sifive_fu540_prci_set_rate,
+	.get_rate = sifive_fu540_prci_get_rate,
+};
+
+static const struct udevice_id sifive_fu540_prci_ids[] = {
+	{ .compatible = "sifive,fu540-c000-prci0" },
+	{ .compatible = "sifive,aloeprci0" },
+	{ }
+};
+
+U_BOOT_DRIVER(sifive_fu540_prci) = {
+	.name = "sifive-fu540-prci",
+	.id = UCLASS_CLK,
+	.of_match = sifive_fu540_prci_ids,
+	.probe = sifive_fu540_prci_probe,
+	.ops = &sifive_fu540_prci_ops,
+	.priv_auto_alloc_size = sizeof(struct __prci_data),
+};
diff --git a/drivers/clk/sifive/wrpll-cln28hpc.c b/drivers/clk/sifive/wrpll-cln28hpc.c
new file mode 100644
index 0000000000..d377849693
--- /dev/null
+++ b/drivers/clk/sifive/wrpll-cln28hpc.c
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Copyright (C) 2018 SiFive, Inc.
+ * Wesley Terpstra
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * This library supports configuration parsing and reprogramming of
+ * the CLN28HPC variant of the Analog Bits Wide Range PLL.  The
+ * intention is for this library to be reusable for any device that
+ * integrates this PLL; thus the register structure and programming
+ * details are expected to be provided by a separate IP block driver.
+ *
+ * The bulk of this code is primarily useful for clock configurations
+ * that must operate at arbitrary rates, as opposed to clock configurations
+ * that are restricted by software or manufacturer guidance to a small,
+ * pre-determined set of performance points.
+ *
+ * References:
+ * - Analog Bits "Wide Range PLL Datasheet", version 2015.10.01
+ * - SiFive FU540-C000 Manual v1p0, Chapter 7 "Clocking and Reset"
+ */
+
+#include <linux/bug.h>
+#include <linux/err.h>
+#include <linux/log2.h>
+#include <linux/math64.h>
+
+#include "analogbits-wrpll-cln28hpc.h"
+
+/* MIN_INPUT_FREQ: minimum input clock frequency, in Hz (Fref_min) */
+#define MIN_INPUT_FREQ			7000000
+
+/* MAX_INPUT_FREQ: maximum input clock frequency, in Hz (Fref_max) */
+#define MAX_INPUT_FREQ			600000000
+
+/* MIN_POST_DIVIDE_REF_FREQ: minimum post-divider reference frequency, in Hz */
+#define MIN_POST_DIVR_FREQ		7000000
+
+/* MAX_POST_DIVIDE_REF_FREQ: maximum post-divider reference frequency, in Hz */
+#define MAX_POST_DIVR_FREQ		200000000
+
+/* MIN_VCO_FREQ: minimum VCO frequency, in Hz (Fvco_min) */
+#define MIN_VCO_FREQ			2400000000UL
+
+/* MAX_VCO_FREQ: maximum VCO frequency, in Hz (Fvco_max) */
+#define MAX_VCO_FREQ			4800000000ULL
+
+/* MAX_DIVQ_DIVISOR: maximum output divisor.  Selected by DIVQ = 6 */
+#define MAX_DIVQ_DIVISOR		64
+
+/* MAX_DIVR_DIVISOR: maximum reference divisor.  Selected by DIVR = 63 */
+#define MAX_DIVR_DIVISOR		64
+
+/* MAX_LOCK_US: maximum PLL lock time, in microseconds (tLOCK_max) */
+#define MAX_LOCK_US			70
+
+/*
+ * ROUND_SHIFT: number of bits to shift to avoid precision loss in the rounding
+ *              algorithm
+ */
+#define ROUND_SHIFT			20
+
+/*
+ * Private functions
+ */
+
+/**
+ * __wrpll_calc_filter_range() - determine PLL loop filter bandwidth
+ * @post_divr_freq: input clock rate after the R divider
+ *
+ * Select the value to be presented to the PLL RANGE input signals, based
+ * on the input clock frequency after the post-R-divider @post_divr_freq.
+ * This code follows the recommendations in the PLL datasheet for filter
+ * range selection.
+ *
+ * Return: The RANGE value to be presented to the PLL configuration inputs,
+ *         or -1 upon error.
+ */
+static int __wrpll_calc_filter_range(unsigned long post_divr_freq)
+{
+	u8 range;
+
+	if (post_divr_freq < MIN_POST_DIVR_FREQ ||
+	    post_divr_freq > MAX_POST_DIVR_FREQ) {
+		WARN(1, "%s: post-divider reference freq out of range: %lu",
+		     __func__, post_divr_freq);
+		return -1;
+	}
+
+	if (post_divr_freq < 11000000)
+		range = 1;
+	else if (post_divr_freq < 18000000)
+		range = 2;
+	else if (post_divr_freq < 30000000)
+		range = 3;
+	else if (post_divr_freq < 50000000)
+		range = 4;
+	else if (post_divr_freq < 80000000)
+		range = 5;
+	else if (post_divr_freq < 130000000)
+		range = 6;
+	else
+		range = 7;
+
+	return range;
+}
+
+/**
+ * __wrpll_calc_fbdiv() - return feedback fixed divide value
+ * @c: ptr to a struct analogbits_wrpll_cfg record to read from
+ *
+ * The internal feedback path includes a fixed by-two divider; the
+ * external feedback path does not.  Return the appropriate divider
+ * value (2 or 1) depending on whether internal or external feedback
+ * is enabled.  This code doesn't test for invalid configurations
+ * (e.g. both or neither of WRPLL_FLAGS_*_FEEDBACK are set); it relies
+ * on the caller to do so.
+ *
+ * Context: Any context.  Caller must protect the memory pointed to by
+ *          @c from simultaneous modification.
+ *
+ * Return: 2 if internal feedback is enabled or 1 if external feedback
+ *         is enabled.
+ */
+static u8 __wrpll_calc_fbdiv(struct analogbits_wrpll_cfg *c)
+{
+	return (c->flags & WRPLL_FLAGS_INT_FEEDBACK_MASK) ? 2 : 1;
+}
+
+/**
+ * __wrpll_calc_divq() - determine DIVQ based on target PLL output clock rate
+ * @target_rate: target PLL output clock rate
+ * @vco_rate: pointer to a u64 to store the computed VCO rate into
+ *
+ * Determine a reasonable value for the PLL Q post-divider, based on the
+ * target output rate @target_rate for the PLL.  Along with returning the
+ * computed Q divider value as the return value, this function stores the
+ * desired target VCO rate into the variable pointed to by @vco_rate.
+ *
+ * Context: Any context.  Caller must protect the memory pointed to by
+ *          @vco_rate from simultaneous access or modification.
+ *
+ * Return: a positive integer DIVQ value to be programmed into the hardware
+ *         upon success, or 0 upon error (since 0 is an invalid DIVQ value)
+ */
+static u8 __wrpll_calc_divq(u32 target_rate, u64 *vco_rate)
+{
+	u64 s;
+	u8 divq = 0;
+
+	if (!vco_rate) {
+		WARN_ON(1);
+		goto wcd_out;
+	}
+
+	s = div_u64(MAX_VCO_FREQ, target_rate);
+	if (s <= 1) {
+		divq = 1;
+		*vco_rate = MAX_VCO_FREQ;
+	} else if (s > MAX_DIVQ_DIVISOR) {
+		divq = ilog2(MAX_DIVQ_DIVISOR);
+		*vco_rate = MIN_VCO_FREQ;
+	} else {
+		divq = ilog2(s);
+		*vco_rate = target_rate << divq;
+	}
+
+wcd_out:
+	return divq;
+}
+
+/**
+ * __wrpll_update_parent_rate() - update PLL data when parent rate changes
+ * @c: ptr to a struct analogbits_wrpll_cfg record to write PLL data to
+ * @parent_rate: PLL input refclk rate (pre-R-divider)
+ *
+ * Pre-compute some data used by the PLL configuration algorithm when
+ * the PLL's reference clock rate changes.  The intention is to avoid
+ * computation when the parent rate remains constant - expected to be
+ * the common case.
+ *
+ * Returns: 0 upon success or -1 if the reference clock rate is out of range.
+ */
+static int __wrpll_update_parent_rate(struct analogbits_wrpll_cfg *c,
+				      unsigned long parent_rate)
+{
+	u8 max_r_for_parent;
+
+	if (parent_rate > MAX_INPUT_FREQ || parent_rate < MIN_POST_DIVR_FREQ)
+		return -1;
+
+	c->_parent_rate = parent_rate;
+	max_r_for_parent = div_u64(parent_rate, MIN_POST_DIVR_FREQ);
+	c->_max_r = min_t(u8, MAX_DIVR_DIVISOR, max_r_for_parent);
+
+	/* Round up */
+	c->_init_r = div_u64(parent_rate + MAX_POST_DIVR_FREQ - 1,
+			     MAX_POST_DIVR_FREQ);
+
+	return 0;
+}
+
+/*
+ * Public functions
+ */
+
+/**
+ * analogbits_wrpll_configure() - compute PLL configuration for a target rate
+ * @c: ptr to a struct analogbits_wrpll_cfg record to write into
+ * @target_rate: target PLL output clock rate (post-Q-divider)
+ * @parent_rate: PLL input refclk rate (pre-R-divider)
+ *
+ * Given a pointer to a PLL context @c, a desired PLL target output
+ * rate @target_rate, and a reference clock input rate @parent_rate,
+ * compute the appropriate PLL signal configuration values.  PLL
+ * reprogramming is not glitchless, so the caller should switch any
+ * downstream logic to a different clock source or clock-gate it
+ * before presenting these values to the PLL configuration signals.
+ *
+ * The caller must pass this function a pre-initialized struct
+ * analogbits_wrpll_cfg record: either initialized to zero (with the
+ * exception of the .name and .flags fields) or read from the PLL.
+ *
+ * Context: Any context.  Caller must protect the memory pointed to by @c
+ *          from simultaneous access or modification.
+ *
+ * Return: 0 upon success; anything else upon failure.
+ */
+int analogbits_wrpll_configure_for_rate(struct analogbits_wrpll_cfg *c,
+					u32 target_rate,
+					unsigned long parent_rate)
+{
+	unsigned long ratio;
+	u64 target_vco_rate, delta, best_delta, f_pre_div, vco, vco_pre;
+	u32 best_f, f, post_divr_freq, fbcfg;
+	u8 fbdiv, divq, best_r, r;
+
+	if (!c)
+		return -1;
+
+	if (c->flags == 0) {
+		WARN(1, "%s called with uninitialized PLL config", __func__);
+		return -1;
+	}
+
+	fbcfg = WRPLL_FLAGS_INT_FEEDBACK_MASK | WRPLL_FLAGS_EXT_FEEDBACK_MASK;
+	if ((c->flags & fbcfg) == fbcfg) {
+		WARN(1, "%s called with invalid PLL config", __func__);
+		return -1;
+	}
+
+	if (c->flags == WRPLL_FLAGS_EXT_FEEDBACK_MASK) {
+		WARN(1, "%s: external feedback mode not currently supported",
+		     __func__);
+		return -1;
+	}
+
+	/* Initialize rounding data if it hasn't been initialized already */
+	if (parent_rate != c->_parent_rate) {
+		if (__wrpll_update_parent_rate(c, parent_rate)) {
+			pr_err("%s: PLL input rate is out of range\n",
+			       __func__);
+			return -1;
+		}
+	}
+
+	c->flags &= ~WRPLL_FLAGS_RESET_MASK;
+
+	/* Put the PLL into bypass if the user requests the parent clock rate */
+	if (target_rate == parent_rate) {
+		c->flags |= WRPLL_FLAGS_BYPASS_MASK;
+		return 0;
+	}
+	c->flags &= ~WRPLL_FLAGS_BYPASS_MASK;
+
+	/* Calculate the Q shift and target VCO rate */
+	divq = __wrpll_calc_divq(target_rate, &target_vco_rate);
+	if (divq == 0)
+		return -1;
+	c->divq = divq;
+
+	/* Precalculate the pre-Q divider target ratio */
+	ratio = div64_u64((target_vco_rate << ROUND_SHIFT), parent_rate);
+
+	fbdiv = __wrpll_calc_fbdiv(c);
+	best_r = 0;
+	best_f = 0;
+	best_delta = MAX_VCO_FREQ;
+
+	/*
+	 * Consider all values for R which land within
+	 * [MIN_POST_DIVR_FREQ, MAX_POST_DIVR_FREQ]; prefer smaller R
+	 */
+	for (r = c->_init_r; r <= c->_max_r; ++r) {
+		/* What is the best F we can pick in this case? */
+		f_pre_div = ratio * r;
+		f = (f_pre_div + (1 << ROUND_SHIFT)) >> ROUND_SHIFT;
+		f >>= (fbdiv - 1);
+
+		post_divr_freq = div_u64(parent_rate, r);
+		vco_pre = fbdiv * post_divr_freq;
+		vco = vco_pre * f;
+
+		/* Ensure rounding didn't take us out of range */
+		if (vco > target_vco_rate) {
+			--f;
+			vco = vco_pre * f;
+		} else if (vco < MIN_VCO_FREQ) {
+			++f;
+			vco = vco_pre * f;
+		}
+
+		delta = abs(target_rate - vco);
+		if (delta < best_delta) {
+			best_delta = delta;
+			best_r = r;
+			best_f = f;
+		}
+	}
+
+	c->divr = best_r - 1;
+	c->divf = best_f - 1;
+
+	post_divr_freq = div_u64(parent_rate, best_r);
+
+	/* Pick the best PLL jitter filter */
+	c->range = __wrpll_calc_filter_range(post_divr_freq);
+
+	return 0;
+}
+
+/**
+ * analogbits_wrpll_calc_output_rate() - calculate the PLL's target output rate
+ * @c: ptr to a struct analogbits_wrpll_cfg record to read from
+ * @parent_rate: PLL refclk rate
+ *
+ * Given a pointer to the PLL's current input configuration @c and the
+ * PLL's input reference clock rate @parent_rate (before the R
+ * pre-divider), calculate the PLL's output clock rate (after the Q
+ * post-divider)
+ *
+ * Context: Any context.  Caller must protect the memory pointed to by @c
+ *          from simultaneous modification.
+ *
+ * Return: the PLL's output clock rate, in Hz.
+ */
+unsigned long analogbits_wrpll_calc_output_rate(struct analogbits_wrpll_cfg *c,
+						unsigned long parent_rate)
+{
+	u8 fbdiv;
+	u64 n;
+
+	WARN(c->flags & WRPLL_FLAGS_EXT_FEEDBACK_MASK,
+	     "external feedback mode not yet supported");
+
+	fbdiv = __wrpll_calc_fbdiv(c);
+	n = parent_rate * fbdiv * (c->divf + 1);
+	n = div_u64(n, (c->divr + 1));
+	n >>= c->divq;
+
+	return n;
+}
+
+/**
+ * analogbits_wrpll_calc_max_lock_us() - return the time for the PLL to lock
+ * @c: ptr to a struct analogbits_wrpll_cfg record to read from
+ *
+ * Return the minimum amount of time (in microseconds) that the caller
+ * must wait after reprogramming the PLL to ensure that it is locked
+ * to the input frequency and stable.  This is likely to depend on the DIVR
+ * value; this is under discussion with the manufacturer.
+ *
+ * Return: the minimum amount of time the caller must wait for the PLL
+ *         to lock (in microseconds)
+ */
+unsigned int analogbits_wrpll_calc_max_lock_us(struct analogbits_wrpll_cfg *c)
+{
+	return MAX_LOCK_US;
+}
diff --git a/include/dt-bindings/clk/sifive-fu540-prci.h b/include/dt-bindings/clk/sifive-fu540-prci.h
new file mode 100644
index 0000000000..531523ea62
--- /dev/null
+++ b/include/dt-bindings/clk/sifive-fu540-prci.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Copyright (C) 2018 SiFive, Inc.
+ * Wesley Terpstra
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __LINUX_CLK_SIFIVE_FU540_PRCI_H
+#define __LINUX_CLK_SIFIVE_FU540_PRCI_H
+
+/* Clock indexes for use by Device Tree data */
+
+#define PRCI_CLK_COREPLL		0
+#define PRCI_CLK_DDRPLL			1
+#define PRCI_CLK_GEMGXLPLL		2
+#define PRCI_CLK_TLCLK			3
+
+#endif
-- 
2.17.1

[U-Boot] [PATCH v2 06/11] clk: Add SiFive FU540 PRCI clock driver

[Auer, Lukas]

Hi Anup,

On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> Add driver code for the SiFive FU540 PRCI IP block.  This IP block
> handles reset and clock control for the SiFive FU540 device and
> implements SoC-level clock tree controls and dividers.
> 
> Based on code written by Wesley Terpstra <wesley@sifive.com>
> found in commit 999529edf517ed75b56659d456d221b2ee56bb60 of:
> https://github.com/riscv/riscv-linux
> 
> Boot and PLL rate change were tested on a SiFive HiFive Unleashed
> board.
> 
> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  drivers/clk/Kconfig                           |   1 +
>  drivers/clk/Makefile                          |   1 +
>  drivers/clk/sifive/Kconfig                    |  19 +
>  drivers/clk/sifive/Makefile                   |   5 +
>  .../clk/sifive/analogbits-wrpll-cln28hpc.h    | 101 +++
>  drivers/clk/sifive/fu540-prci.c               | 604
> ++++++++++++++++++
>  drivers/clk/sifive/wrpll-cln28hpc.c           | 390 +++++++++++
>  include/dt-bindings/clk/sifive-fu540-prci.h   |  29 +
>  8 files changed, 1150 insertions(+)
>  create mode 100644 drivers/clk/sifive/Kconfig
>  create mode 100644 drivers/clk/sifive/Makefile
>  create mode 100644 drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
>  create mode 100644 drivers/clk/sifive/fu540-prci.c
>  create mode 100644 drivers/clk/sifive/wrpll-cln28hpc.c
>  create mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h
> 

The corresponding patch series for the Linux Kernel [1] includes code
comments, which have not been addressed yet in this version of the
driver. Are you planning on syncing it with the Linux driver once it is
upstream, or incorporating the comments directly?

[1]: 
https://patchwork.kernel.org/project/linux-clk/list/?series=33383&state=%2A&archive=both

> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index eadf7f8250..ce462f5717 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -104,6 +104,7 @@ source "drivers/clk/imx/Kconfig"
>  source "drivers/clk/mvebu/Kconfig"
>  source "drivers/clk/owl/Kconfig"
>  source "drivers/clk/renesas/Kconfig"
> +source "drivers/clk/sifive/Kconfig"
>  source "drivers/clk/tegra/Kconfig"
>  source "drivers/clk/uniphier/Kconfig"
>  
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 9acbb1a650..2f4446568c 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
>  obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
>  obj-$(CONFIG_CLK_OWL) += owl/
>  obj-$(CONFIG_CLK_RENESAS) += renesas/
> +obj-$(CONFIG_CLK_SIFIVE) += sifive/
>  obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
>  obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
>  obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
> diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
> new file mode 100644
> index 0000000000..81fc9f8fda
> --- /dev/null
> +++ b/drivers/clk/sifive/Kconfig
> @@ -0,0 +1,19 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +config CLK_ANALOGBITS_WRPLL_CLN28HPC
> +	bool

The analogbits library is not specific to SiFive. The Linux Kernel
patch series adds it as a standalone entry to make it available to
other drivers. I think the same thing would also make sense here.

Thanks,
Lukas

[U-Boot] [PATCH v2 06/11] clk: Add SiFive FU540 PRCI clock driver

[Anup Patel]

> -----Original Message-----
> From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> Sent: Monday, January 21, 2019 1:43 AM
> To: sjg at chromium.org; bmeng.cn at gmail.com; rick at andestech.com; Anup
> Patel <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> yamada.masahiro at socionext.com
> Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org; u-
> boot at lists.denx.de; agraf at suse.de; Atish Patra <Atish.Patra@wdc.com>
> Subject: Re: [PATCH v2 06/11] clk: Add SiFive FU540 PRCI clock driver
> 
> Hi Anup,
> 
> On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> > Add driver code for the SiFive FU540 PRCI IP block.  This IP block
> > handles reset and clock control for the SiFive FU540 device and
> > implements SoC-level clock tree controls and dividers.
> >
> > Based on code written by Wesley Terpstra <wesley@sifive.com> found in
> > commit 999529edf517ed75b56659d456d221b2ee56bb60 of:
> > https://github.com/riscv/riscv-linux
> >
> > Boot and PLL rate change were tested on a SiFive HiFive Unleashed
> > board.
> >
> > Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > Reviewed-by: Alexander Graf <agraf@suse.de>
> > ---
> >  drivers/clk/Kconfig                           |   1 +
> >  drivers/clk/Makefile                          |   1 +
> >  drivers/clk/sifive/Kconfig                    |  19 +
> >  drivers/clk/sifive/Makefile                   |   5 +
> >  .../clk/sifive/analogbits-wrpll-cln28hpc.h    | 101 +++
> >  drivers/clk/sifive/fu540-prci.c               | 604
> > ++++++++++++++++++
> >  drivers/clk/sifive/wrpll-cln28hpc.c           | 390 +++++++++++
> >  include/dt-bindings/clk/sifive-fu540-prci.h   |  29 +
> >  8 files changed, 1150 insertions(+)
> >  create mode 100644 drivers/clk/sifive/Kconfig  create mode 100644
> > drivers/clk/sifive/Makefile  create mode 100644
> > drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
> >  create mode 100644 drivers/clk/sifive/fu540-prci.c  create mode
> > 100644 drivers/clk/sifive/wrpll-cln28hpc.c
> >  create mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h
> >
> 
> The corresponding patch series for the Linux Kernel [1] includes code
> comments, which have not been addressed yet in this version of the driver.
> Are you planning on syncing it with the Linux driver once it is upstream, or
> incorporating the comments directly?
> 
> [1]:
> https://patchwork.kernel.org/project/linux-
> clk/list/?series=33383&state=%2A&archive=both

Yes, the Linux patches might take some time to merge so unblock
this patch series we took the first version as reference. Later once
it is merged we will send one sync-up patch to U-Boot.

> 
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> > eadf7f8250..ce462f5717 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -104,6 +104,7 @@ source "drivers/clk/imx/Kconfig"
> >  source "drivers/clk/mvebu/Kconfig"
> >  source "drivers/clk/owl/Kconfig"
> >  source "drivers/clk/renesas/Kconfig"
> > +source "drivers/clk/sifive/Kconfig"
> >  source "drivers/clk/tegra/Kconfig"
> >  source "drivers/clk/uniphier/Kconfig"
> >
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> > 9acbb1a650..2f4446568c 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -22,6 +22,7 @@ obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
> >  obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
> >  obj-$(CONFIG_CLK_OWL) += owl/
> >  obj-$(CONFIG_CLK_RENESAS) += renesas/
> > +obj-$(CONFIG_CLK_SIFIVE) += sifive/
> >  obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
> >  obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
> >  obj-$(CONFIG_CLK_UNIPHIER) += uniphier/ diff --git
> > a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig new file
> > mode 100644 index 0000000000..81fc9f8fda
> > --- /dev/null
> > +++ b/drivers/clk/sifive/Kconfig
> > @@ -0,0 +1,19 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +config CLK_ANALOGBITS_WRPLL_CLN28HPC
> > +	bool
> 
> The analogbits library is not specific to SiFive. The Linux Kernel patch series
> adds it as a standalone entry to make it available to other drivers. I think the
> same thing would also make sense here.

Based on other CLK drivers, it seems analogbits library is not generic enough
might require more work to become generic PLL library.

To unblock this patch series, we have made it SiFive specific. Later if it is
accepted in Linux as standalone library then we will refactor here as well.

IMHO, analogbits library is not generic enough so might be difficult to
take it as standalone library in Linux.

Regards,
Anup

[U-Boot] [PATCH v2 06/11] clk: Add SiFive FU540 PRCI clock driver

[Auer, Lukas]

On Mon, 2019-01-21 at 05:55 +0000, Anup Patel wrote:
> > -----Original Message-----
> > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> > Sent: Monday, January 21, 2019 1:43 AM
> > To: sjg at chromium.org; bmeng.cn at gmail.com; rick at andestech.com; Anup
> > Patel <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > yamada.masahiro at socionext.com
> > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org;
> > u-
> > boot at lists.denx.de; agraf at suse.de; Atish Patra <Atish.Patra@wdc.com
> > >
> > Subject: Re: [PATCH v2 06/11] clk: Add SiFive FU540 PRCI clock
> > driver
> > 
> > Hi Anup,
> > 
> > On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> > > Add driver code for the SiFive FU540 PRCI IP block.  This IP
> > > block
> > > handles reset and clock control for the SiFive FU540 device and
> > > implements SoC-level clock tree controls and dividers.
> > > 
> > > Based on code written by Wesley Terpstra <wesley@sifive.com>
> > > found in
> > > commit 999529edf517ed75b56659d456d221b2ee56bb60 of:
> > > https://github.com/riscv/riscv-linux
> > > 
> > > Boot and PLL rate change were tested on a SiFive HiFive Unleashed
> > > board.
> > > 
> > > Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
> > > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > > Reviewed-by: Alexander Graf <agraf@suse.de>
> > > ---
> > >  drivers/clk/Kconfig                           |   1 +
> > >  drivers/clk/Makefile                          |   1 +
> > >  drivers/clk/sifive/Kconfig                    |  19 +
> > >  drivers/clk/sifive/Makefile                   |   5 +
> > >  .../clk/sifive/analogbits-wrpll-cln28hpc.h    | 101 +++
> > >  drivers/clk/sifive/fu540-prci.c               | 604
> > > ++++++++++++++++++
> > >  drivers/clk/sifive/wrpll-cln28hpc.c           | 390 +++++++++++
> > >  include/dt-bindings/clk/sifive-fu540-prci.h   |  29 +
> > >  8 files changed, 1150 insertions(+)
> > >  create mode 100644 drivers/clk/sifive/Kconfig  create mode
> > > 100644
> > > drivers/clk/sifive/Makefile  create mode 100644
> > > drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
> > >  create mode 100644 drivers/clk/sifive/fu540-prci.c  create mode
> > > 100644 drivers/clk/sifive/wrpll-cln28hpc.c
> > >  create mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h
> > > 
> > 
> > The corresponding patch series for the Linux Kernel [1] includes
> > code
> > comments, which have not been addressed yet in this version of the
> > driver.
> > Are you planning on syncing it with the Linux driver once it is
> > upstream, or
> > incorporating the comments directly?
> > 
> > [1]:
> > https://patchwork.kernel.org/project/linux-
> > clk/list/?series=33383&state=%2A&archive=both
> 
> Yes, the Linux patches might take some time to merge so unblock
> this patch series we took the first version as reference. Later once
> it is merged we will send one sync-up patch to U-Boot.

That sounds good, thanks!

> 
> > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> > > eadf7f8250..ce462f5717 100644
> > > --- a/drivers/clk/Kconfig
> > > +++ b/drivers/clk/Kconfig
> > > @@ -104,6 +104,7 @@ source "drivers/clk/imx/Kconfig"
> > >  source "drivers/clk/mvebu/Kconfig"
> > >  source "drivers/clk/owl/Kconfig"
> > >  source "drivers/clk/renesas/Kconfig"
> > > +source "drivers/clk/sifive/Kconfig"
> > >  source "drivers/clk/tegra/Kconfig"
> > >  source "drivers/clk/uniphier/Kconfig"
> > > 
> > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> > > 9acbb1a650..2f4446568c 100644
> > > --- a/drivers/clk/Makefile
> > > +++ b/drivers/clk/Makefile
> > > @@ -22,6 +22,7 @@ obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
> > >  obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
> > >  obj-$(CONFIG_CLK_OWL) += owl/
> > >  obj-$(CONFIG_CLK_RENESAS) += renesas/
> > > +obj-$(CONFIG_CLK_SIFIVE) += sifive/
> > >  obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
> > >  obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
> > >  obj-$(CONFIG_CLK_UNIPHIER) += uniphier/ diff --git
> > > a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig new
> > > file
> > > mode 100644 index 0000000000..81fc9f8fda
> > > --- /dev/null
> > > +++ b/drivers/clk/sifive/Kconfig
> > > @@ -0,0 +1,19 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +
> > > +config CLK_ANALOGBITS_WRPLL_CLN28HPC
> > > +	bool
> > 
> > The analogbits library is not specific to SiFive. The Linux Kernel
> > patch series
> > adds it as a standalone entry to make it available to other
> > drivers. I think the
> > same thing would also make sense here.
> 
> Based on other CLK drivers, it seems analogbits library is not
> generic enough
> might require more work to become generic PLL library.
> 
> To unblock this patch series, we have made it SiFive specific. Later
> if it is
> accepted in Linux as standalone library then we will refactor here as
> well.
> 
> IMHO, analogbits library is not generic enough so might be difficult
> to
> take it as standalone library in Linux.
> 

That makes sense. I agree, the best option will be to include the
library the same way as in Linux.

Thanks,
Lukas

[U-Boot] [PATCH v2 07/11] clk: Add fixed-factor clock driver

[Anup Patel]

This patch adds fixed-factor clock driver which derives clock
rate by dividing (div) and multiplying (mult) fixed factors
to a parent clock.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
---
 drivers/clk/Makefile           |  4 +-
 drivers/clk/clk_fixed_factor.c | 74 ++++++++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/clk_fixed_factor.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 2f4446568c..fa59259ea3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -4,7 +4,9 @@
 # Wolfgang Denk, DENX Software Engineering, wd at denx.de.
 #
 
-obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o clk_fixed_rate.o
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
+obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
 
 obj-y += imx/
 obj-y += tegra/
diff --git a/drivers/clk/clk_fixed_factor.c b/drivers/clk/clk_fixed_factor.c
new file mode 100644
index 0000000000..eab1724c26
--- /dev/null
+++ b/drivers/clk/clk_fixed_factor.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Author: Anup Patel <anup.patel@wdc.com>
+ */
+
+#include <common.h>
+#include <clk-uclass.h>
+#include <div64.h>
+#include <dm.h>
+
+struct clk_fixed_factor {
+	struct clk parent;
+	unsigned int div;
+	unsigned int mult;
+};
+
+#define to_clk_fixed_factor(dev)	\
+	((struct clk_fixed_factor *)dev_get_platdata(dev))
+
+static ulong clk_fixed_factor_get_rate(struct clk *clk)
+{
+	int ret;
+	struct clk_fixed_factor *ff = to_clk_fixed_factor(clk->dev);
+
+	if (clk->id != 0)
+		return -EINVAL;
+
+	ret = clk_get_rate(&ff->parent);
+	if (IS_ERR_VALUE(ret))
+		return ret;
+
+	do_div(ret, ff->div);
+
+	return ret * ff->mult;
+}
+
+const struct clk_ops clk_fixed_factor_ops = {
+	.get_rate = clk_fixed_factor_get_rate,
+};
+
+static int clk_fixed_factor_ofdata_to_platdata(struct udevice *dev)
+{
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+	int err;
+	struct clk_fixed_factor *ff = to_clk_fixed_factor(dev);
+
+	err = clk_get_by_index(dev, 0, &ff->parent);
+	if (err)
+		return err;
+
+	ff->div = dev_read_u32_default(dev, "clock-div", 1);
+	ff->mult = dev_read_u32_default(dev, "clock-mult", 1);
+#endif
+
+	return 0;
+}
+
+static const struct udevice_id clk_fixed_factor_match[] = {
+	{
+		.compatible = "fixed-factor-clock",
+	},
+	{ /* sentinel */ }
+};
+
+U_BOOT_DRIVER(clk_fixed_factor) = {
+	.name = "fixed_factor_clock",
+	.id = UCLASS_CLK,
+	.of_match = clk_fixed_factor_match,
+	.ofdata_to_platdata = clk_fixed_factor_ofdata_to_platdata,
+	.platdata_auto_alloc_size = sizeof(struct clk_fixed_factor),
+	.ops = &clk_fixed_factor_ops,
+};
-- 
2.17.1

[U-Boot] [PATCH v2 07/11] clk: Add fixed-factor clock driver

[Simon Glass]

Hi Anup,

On Fri, 18 Jan 2019 at 04:19, Anup Patel <Anup.Patel@wdc.com> wrote:
>
> This patch adds fixed-factor clock driver which derives clock
> rate by dividing (div) and multiplying (mult) fixed factors
> to a parent clock.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> ---
>  drivers/clk/Makefile           |  4 +-
>  drivers/clk/clk_fixed_factor.c | 74 ++++++++++++++++++++++++++++++++++
>  2 files changed, 77 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/clk_fixed_factor.c

Can you please update test/dm/clk.c to test this? You'll need to add
this clock to sandbox.

Regards,
Simon

[U-Boot] [PATCH v2 07/11] clk: Add fixed-factor clock driver

[Anup Patel]

> -----Original Message-----
> From: Simon Glass [mailto:sjg at chromium.org]
> Sent: Thursday, January 31, 2019 3:34 PM
> To: Anup Patel <Anup.Patel@wdc.com>
> Cc: Rick Chen <rick@andestech.com>; Bin Meng <bmeng.cn@gmail.com>;
> Joe Hershberger <joe.hershberger@ni.com>; Lukas Auer
> <lukas.auer@aisec.fraunhofer.de>; Masahiro Yamada
> <yamada.masahiro@socionext.com>; Alexander Graf <agraf@suse.de>;
> Palmer Dabbelt <palmer@sifive.com>; Paul Walmsley
> <paul.walmsley@sifive.com>; Atish Patra <Atish.Patra@wdc.com>;
> Christoph Hellwig <hch@infradead.org>; U-Boot Mailing List <u-
> boot at lists.denx.de>
> Subject: Re: [PATCH v2 07/11] clk: Add fixed-factor clock driver
> 
> Hi Anup,
> 
> On Fri, 18 Jan 2019 at 04:19, Anup Patel <Anup.Patel@wdc.com> wrote:
> >
> > This patch adds fixed-factor clock driver which derives clock rate by
> > dividing (div) and multiplying (mult) fixed factors to a parent clock.
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > ---
> >  drivers/clk/Makefile           |  4 +-
> >  drivers/clk/clk_fixed_factor.c | 74
> > ++++++++++++++++++++++++++++++++++
> >  2 files changed, 77 insertions(+), 1 deletion(-)  create mode 100644
> > drivers/clk/clk_fixed_factor.c
> 
> Can you please update test/dm/clk.c to test this? You'll need to add this clock
> to sandbox.

Okay, will do.

Regards,
Anup

[U-Boot] [PATCH v2 08/11] drivers: serial_sifive: Fix baud rate calculation

[Anup Patel]

From: Atish Patra <atish.patra@wdc.com>

Compute the baud rate multipler with more precision.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 drivers/serial/serial_sifive.c | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/serial_sifive.c b/drivers/serial/serial_sifive.c
index 341728a690..ea4d35d48c 100644
--- a/drivers/serial/serial_sifive.c
+++ b/drivers/serial/serial_sifive.c
@@ -33,16 +33,40 @@ struct uart_sifive {
 };
 
 struct sifive_uart_platdata {
-	unsigned int clock;
+	unsigned long clock;
 	int saved_input_char;
 	struct uart_sifive *regs;
 };
 
+/**
+ * Find minimum divisor divides in_freq to max_target_hz;
+ * Based on uart driver n SiFive FSBL.
+ *
+ * f_baud = f_in / (div + 1) => div = (f_in / f_baud) - 1
+ * The nearest integer solution requires rounding up as to not exceed
+ * max_target_hz.
+ * div  = ceil(f_in / f_baud) - 1
+ *	= floor((f_in - 1 + f_baud) / f_baud) - 1
+ * This should not overflow as long as (f_in - 1 + f_baud) does not exceed
+ * 2^32 - 1, which is unlikely since we represent frequencies in kHz.
+ */
+static inline unsigned int uart_min_clk_divisor(unsigned long in_freq,
+						unsigned long max_target_hz)
+{
+	unsigned long quotient =
+			(in_freq + max_target_hz - 1) / (max_target_hz);
+	/* Avoid underflow */
+	if (quotient == 0)
+		return 0;
+	else
+		return quotient - 1;
+}
+
 /* Set up the baud rate in gd struct */
 static void _sifive_serial_setbrg(struct uart_sifive *regs,
 				  unsigned long clock, unsigned long baud)
 {
-	writel((u32)((clock / baud) - 1), &regs->div);
+	writel((uart_min_clk_divisor(clock, baud)), &regs->div);
 }
 
 static void _sifive_serial_init(struct uart_sifive *regs)
-- 
2.17.1

[U-Boot] [PATCH v2 08/11] drivers: serial_sifive: Fix baud rate calculation

[Alexander Graf]

On 18.01.19 12:19, Anup Patel wrote:
> From: Atish Patra <atish.patra@wdc.com>
> 
> Compute the baud rate multipler with more precision.
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>

Same here.

Alex

[U-Boot] [PATCH v2 08/11] drivers: serial_sifive: Fix baud rate calculation

[Anup Patel]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Friday, January 18, 2019 5:22 PM
> To: Anup Patel <Anup.Patel@wdc.com>; Rick Chen <rick@andestech.com>;
> Bin Meng <bmeng.cn@gmail.com>; Joe Hershberger
> <joe.hershberger@ni.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
> Masahiro Yamada <yamada.masahiro@socionext.com>; Simon Glass
> <sjg@chromium.org>
> Cc: Palmer Dabbelt <palmer@sifive.com>; Paul Walmsley
> <paul.walmsley@sifive.com>; Atish Patra <Atish.Patra@wdc.com>;
> Christoph Hellwig <hch@infradead.org>; U-Boot Mailing List <u-
> boot at lists.denx.de>
> Subject: Re: [PATCH v2 08/11] drivers: serial_sifive: Fix baud rate calculation
> 
> 
> 
> On 18.01.19 12:19, Anup Patel wrote:
> > From: Atish Patra <atish.patra@wdc.com>
> >
> > Compute the baud rate multipler with more precision.
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> 
> Same here.
> 
> Alex

Sure, I will add my SoB.

Regards,
Anup

[U-Boot] [PATCH v2 08/11] drivers: serial_sifive: Fix baud rate calculation

[Auer, Lukas]

On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> From: Atish Patra <atish.patra@wdc.com>
> 
> Compute the baud rate multipler with more precision.
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  drivers/serial/serial_sifive.c | 28 ++++++++++++++++++++++++++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 

Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>

[U-Boot] [PATCH v2 09/11] drivers: serial_sifive: Skip baudrate config if no input clock

[Anup Patel]

From: Atish Patra <atish.patra@wdc.com>

It is possible that input clock is not available because clk
device was not available and 'clock-frequency' DT property is
also not available.

In this case, instead of failing we should just skip baudrate
config by returning zero.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 drivers/serial/serial_sifive.c | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/serial/serial_sifive.c b/drivers/serial/serial_sifive.c
index ea4d35d48c..537bc7a975 100644
--- a/drivers/serial/serial_sifive.c
+++ b/drivers/serial/serial_sifive.c
@@ -99,27 +99,27 @@ static int _sifive_serial_getc(struct uart_sifive *regs)
 
 static int sifive_serial_setbrg(struct udevice *dev, int baudrate)
 {
-	int err;
+	int ret;
 	struct clk clk;
 	struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
+	u32 clock = 0;
 
-	err = clk_get_by_index(dev, 0, &clk);
-	if (!err) {
-		err = clk_get_rate(&clk);
-		if (!IS_ERR_VALUE(err))
-			platdata->clock = err;
-	} else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS) {
+	ret = clk_get_by_index(dev, 0, &clk);
+	if (IS_ERR_VALUE(ret)) {
 		debug("SiFive UART failed to get clock\n");
-		return err;
-	}
-
-	if (!platdata->clock)
-		platdata->clock = dev_read_u32_default(dev, "clock-frequency", 0);
-	if (!platdata->clock) {
-		debug("SiFive UART clock not defined\n");
-		return -EINVAL;
+		ret = dev_read_u32(dev, "clock-frequency", &clock);
+		if (IS_ERR_VALUE(ret)) {
+			debug("SiFive UART clock not defined\n");
+			return 0;
+		}
+	} else {
+		clock = clk_get_rate(&clk);
+		if (IS_ERR_VALUE(clock)) {
+			debug("SiFive UART clock get rate failed\n");
+			return 0;
+		}
 	}
-
+	platdata->clock = clock;
 	_sifive_serial_setbrg(platdata->regs, platdata->clock, baudrate);
 
 	return 0;
-- 
2.17.1

[U-Boot] [PATCH v2 09/11] drivers: serial_sifive: Skip baudrate config if no input clock

[Auer, Lukas]

Hi Anup,

On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> From: Atish Patra <atish.patra@wdc.com>
> 
> It is possible that input clock is not available because clk
> device was not available and 'clock-frequency' DT property is
> also not available.

Why would the clock device not be available?
I suspect the problem is that the clock driver is not probed pre-
relocation. Adding DM_FLAG_PRE_RELOC to the driver flags would fix
this.

> 
> In this case, instead of failing we should just skip baudrate
> config by returning zero.

Won't this cause issues if an incorrect baudrate is set?

Thanks,
Lukas

> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  drivers/serial/serial_sifive.c | 32 ++++++++++++++++----------------
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/serial/serial_sifive.c
> b/drivers/serial/serial_sifive.c
> index ea4d35d48c..537bc7a975 100644
> --- a/drivers/serial/serial_sifive.c
> +++ b/drivers/serial/serial_sifive.c
> @@ -99,27 +99,27 @@ static int _sifive_serial_getc(struct uart_sifive
> *regs)
>  
>  static int sifive_serial_setbrg(struct udevice *dev, int baudrate)
>  {
> -	int err;
> +	int ret;
>  	struct clk clk;
>  	struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
> +	u32 clock = 0;
>  
> -	err = clk_get_by_index(dev, 0, &clk);
> -	if (!err) {
> -		err = clk_get_rate(&clk);
> -		if (!IS_ERR_VALUE(err))
> -			platdata->clock = err;
> -	} else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS)
> {
> +	ret = clk_get_by_index(dev, 0, &clk);
> +	if (IS_ERR_VALUE(ret)) {
>  		debug("SiFive UART failed to get clock\n");
> -		return err;
> -	}
> -
> -	if (!platdata->clock)
> -		platdata->clock = dev_read_u32_default(dev, "clock-
> frequency", 0);
> -	if (!platdata->clock) {
> -		debug("SiFive UART clock not defined\n");
> -		return -EINVAL;
> +		ret = dev_read_u32(dev, "clock-frequency", &clock);
> +		if (IS_ERR_VALUE(ret)) {
> +			debug("SiFive UART clock not defined\n");
> +			return 0;
> +		}
> +	} else {
> +		clock = clk_get_rate(&clk);
> +		if (IS_ERR_VALUE(clock)) {
> +			debug("SiFive UART clock get rate failed\n");
> +			return 0;
> +		}
>  	}
> -
> +	platdata->clock = clock;
>  	_sifive_serial_setbrg(platdata->regs, platdata->clock,
> baudrate);
>  
>  	return 0;

[U-Boot] [PATCH v2 09/11] drivers: serial_sifive: Skip baudrate config if no input clock

[Atish Patra]

On 1/20/19 12:22 PM, Auer, Lukas wrote:
> Hi Anup,
> 
> On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
>> From: Atish Patra <atish.patra@wdc.com>
>>
>> It is possible that input clock is not available because clk
>> device was not available and 'clock-frequency' DT property is
>> also not available.
> 
> Why would the clock device not be available?
> I suspect the problem is that the clock driver is not probed pre-
> relocation. Adding DM_FLAG_PRE_RELOC to the driver flags would fix
> this.
> 

The problem is serial driver gets probed first before clock driver even 
if we add DM_FLAG_PRE_RELOC.

>>
>> In this case, instead of failing we should just skip baudrate
>> config by returning zero.
> 
> Won't this cause issues if an incorrect baudrate is set?
> 
It might be possible that baudrate is configured by earlier boot stage.
Thus, any early information can be displayed in console by the serial 
driver even if it is not configured correctly by u-boot.


Regards,
Atish
> Thanks,
> Lukas
> 
>>
>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>> Signed-off-by: Anup Patel <anup.patel@wdc.com>
>> Reviewed-by: Alexander Graf <agraf@suse.de>
>> ---
>>   drivers/serial/serial_sifive.c | 32 ++++++++++++++++----------------
>>   1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/serial/serial_sifive.c
>> b/drivers/serial/serial_sifive.c
>> index ea4d35d48c..537bc7a975 100644
>> --- a/drivers/serial/serial_sifive.c
>> +++ b/drivers/serial/serial_sifive.c
>> @@ -99,27 +99,27 @@ static int _sifive_serial_getc(struct uart_sifive
>> *regs)
>>   
>>   static int sifive_serial_setbrg(struct udevice *dev, int baudrate)
>>   {
>> -	int err;
>> +	int ret;
>>   	struct clk clk;
>>   	struct sifive_uart_platdata *platdata = dev_get_platdata(dev);
>> +	u32 clock = 0;
>>   
>> -	err = clk_get_by_index(dev, 0, &clk);
>> -	if (!err) {
>> -		err = clk_get_rate(&clk);
>> -		if (!IS_ERR_VALUE(err))
>> -			platdata->clock = err;
>> -	} else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS)
>> {
>> +	ret = clk_get_by_index(dev, 0, &clk);
>> +	if (IS_ERR_VALUE(ret)) {
>>   		debug("SiFive UART failed to get clock\n");
>> -		return err;
>> -	}
>> -
>> -	if (!platdata->clock)
>> -		platdata->clock = dev_read_u32_default(dev, "clock-
>> frequency", 0);
>> -	if (!platdata->clock) {
>> -		debug("SiFive UART clock not defined\n");
>> -		return -EINVAL;
>> +		ret = dev_read_u32(dev, "clock-frequency", &clock);
>> +		if (IS_ERR_VALUE(ret)) {
>> +			debug("SiFive UART clock not defined\n");
>> +			return 0;
>> +		}
>> +	} else {
>> +		clock = clk_get_rate(&clk);
>> +		if (IS_ERR_VALUE(clock)) {
>> +			debug("SiFive UART clock get rate failed\n");
>> +			return 0;
>> +		}
>>   	}
>> -
>> +	platdata->clock = clock;
>>   	_sifive_serial_setbrg(platdata->regs, platdata->clock,
>> baudrate);
>>   
>>   	return 0;
> 

[U-Boot] [PATCH v2 09/11] drivers: serial_sifive: Skip baudrate config if no input clock

[Auer, Lukas]

On Sun, 2019-01-20 at 17:07 -0800, Atish Patra wrote:
> On 1/20/19 12:22 PM, Auer, Lukas wrote:
> > Hi Anup,
> > 
> > On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> > > From: Atish Patra <atish.patra@wdc.com>
> > > 
> > > It is possible that input clock is not available because clk
> > > device was not available and 'clock-frequency' DT property is
> > > also not available.
> > 
> > Why would the clock device not be available?
> > I suspect the problem is that the clock driver is not probed pre-
> > relocation. Adding DM_FLAG_PRE_RELOC to the driver flags would fix
> > this.
> > 
> 
> The problem is serial driver gets probed first before clock driver
> even 
> if we add DM_FLAG_PRE_RELOC.

That makes sense. I just browsed through the code to see what other
boards do here. The serial driver for the MPC83xx SoC series directly
probes the clock driver (see get_serial_clock in
driver/clk/mpc83xx_clk.c called from the serial driver). Maybe we
should do something similar here?

> 
> > > In this case, instead of failing we should just skip baudrate
> > > config by returning zero.
> > 
> > Won't this cause issues if an incorrect baudrate is set?
> > 
> It might be possible that baudrate is configured by earlier boot
> stage.
> Thus, any early information can be displayed in console by the
> serial 
> driver even if it is not configured correctly by u-boot.
> 

Yes, it is very likely not going to be a problem, but if we can fix it
it would be great :)

Thanks,
Lukas

> 
> Regards,
> Atish
> > Thanks,
> > Lukas
> > 
> > > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > > Reviewed-by: Alexander Graf <agraf@suse.de>
> > > ---
> > >   drivers/serial/serial_sifive.c | 32 ++++++++++++++++-----------
> > > -----
> > >   1 file changed, 16 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/drivers/serial/serial_sifive.c
> > > b/drivers/serial/serial_sifive.c
> > > index ea4d35d48c..537bc7a975 100644
> > > --- a/drivers/serial/serial_sifive.c
> > > +++ b/drivers/serial/serial_sifive.c
> > > @@ -99,27 +99,27 @@ static int _sifive_serial_getc(struct
> > > uart_sifive
> > > *regs)
> > >   
> > >   static int sifive_serial_setbrg(struct udevice *dev, int
> > > baudrate)
> > >   {
> > > -	int err;
> > > +	int ret;
> > >   	struct clk clk;
> > >   	struct sifive_uart_platdata *platdata =
> > > dev_get_platdata(dev);
> > > +	u32 clock = 0;
> > >   
> > > -	err = clk_get_by_index(dev, 0, &clk);
> > > -	if (!err) {
> > > -		err = clk_get_rate(&clk);
> > > -		if (!IS_ERR_VALUE(err))
> > > -			platdata->clock = err;
> > > -	} else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS)
> > > {
> > > +	ret = clk_get_by_index(dev, 0, &clk);
> > > +	if (IS_ERR_VALUE(ret)) {
> > >   		debug("SiFive UART failed to get clock\n");
> > > -		return err;
> > > -	}
> > > -
> > > -	if (!platdata->clock)
> > > -		platdata->clock = dev_read_u32_default(dev, "clock-
> > > frequency", 0);
> > > -	if (!platdata->clock) {
> > > -		debug("SiFive UART clock not defined\n");
> > > -		return -EINVAL;
> > > +		ret = dev_read_u32(dev, "clock-frequency", &clock);
> > > +		if (IS_ERR_VALUE(ret)) {
> > > +			debug("SiFive UART clock not defined\n");
> > > +			return 0;
> > > +		}
> > > +	} else {
> > > +		clock = clk_get_rate(&clk);
> > > +		if (IS_ERR_VALUE(clock)) {
> > > +			debug("SiFive UART clock get rate failed\n");
> > > +			return 0;
> > > +		}
> > >   	}
> > > -
> > > +	platdata->clock = clock;
> > >   	_sifive_serial_setbrg(platdata->regs, platdata->clock,
> > > baudrate);
> > >   
> > >   	return 0;

[U-Boot] [PATCH v2 09/11] drivers: serial_sifive: Skip baudrate config if no input clock

[Auer, Lukas]

On Mon, 2019-01-21 at 12:39 +0000, Auer, Lukas wrote:
> On Sun, 2019-01-20 at 17:07 -0800, Atish Patra wrote:
> > On 1/20/19 12:22 PM, Auer, Lukas wrote:
> > > Hi Anup,
> > > 
> > > On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> > > > From: Atish Patra <atish.patra@wdc.com>
> > > > 
> > > > It is possible that input clock is not available because clk
> > > > device was not available and 'clock-frequency' DT property is
> > > > also not available.
> > > 
> > > Why would the clock device not be available?
> > > I suspect the problem is that the clock driver is not probed pre-
> > > relocation. Adding DM_FLAG_PRE_RELOC to the driver flags would
> > > fix
> > > this.
> > > 
> > 
> > The problem is serial driver gets probed first before clock driver
> > even 
> > if we add DM_FLAG_PRE_RELOC.
> 
> That makes sense. I just browsed through the code to see what other
> boards do here. The serial driver for the MPC83xx SoC series directly
> probes the clock driver (see get_serial_clock in
> driver/clk/mpc83xx_clk.c called from the serial driver). Maybe we
> should do something similar here?
> 

What are your thoughts on this, can you add something like it?

Thanks,
Lukas

> > > > In this case, instead of failing we should just skip baudrate
> > > > config by returning zero.
> > > 
> > > Won't this cause issues if an incorrect baudrate is set?
> > > 
> > It might be possible that baudrate is configured by earlier boot
> > stage.
> > Thus, any early information can be displayed in console by the
> > serial 
> > driver even if it is not configured correctly by u-boot.
> > 
> 
> Yes, it is very likely not going to be a problem, but if we can fix
> it
> it would be great :)
> 
> Thanks,
> Lukas
> 
> > Regards,
> > Atish
> > > Thanks,
> > > Lukas
> > > 
> > > > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > > > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > > > Reviewed-by: Alexander Graf <agraf@suse.de>
> > > > ---
> > > >   drivers/serial/serial_sifive.c | 32 ++++++++++++++++---------
> > > > --
> > > > -----
> > > >   1 file changed, 16 insertions(+), 16 deletions(-)
> > > > 
> > > > diff --git a/drivers/serial/serial_sifive.c
> > > > b/drivers/serial/serial_sifive.c
> > > > index ea4d35d48c..537bc7a975 100644
> > > > --- a/drivers/serial/serial_sifive.c
> > > > +++ b/drivers/serial/serial_sifive.c
> > > > @@ -99,27 +99,27 @@ static int _sifive_serial_getc(struct
> > > > uart_sifive
> > > > *regs)
> > > >   
> > > >   static int sifive_serial_setbrg(struct udevice *dev, int
> > > > baudrate)
> > > >   {
> > > > -	int err;
> > > > +	int ret;
> > > >   	struct clk clk;
> > > >   	struct sifive_uart_platdata *platdata =
> > > > dev_get_platdata(dev);
> > > > +	u32 clock = 0;
> > > >   
> > > > -	err = clk_get_by_index(dev, 0, &clk);
> > > > -	if (!err) {
> > > > -		err = clk_get_rate(&clk);
> > > > -		if (!IS_ERR_VALUE(err))
> > > > -			platdata->clock = err;
> > > > -	} else if (err != -ENOENT && err != -ENODEV && err !=
> > > > -ENOSYS)
> > > > {
> > > > +	ret = clk_get_by_index(dev, 0, &clk);
> > > > +	if (IS_ERR_VALUE(ret)) {
> > > >   		debug("SiFive UART failed to get clock\n");
> > > > -		return err;
> > > > -	}
> > > > -
> > > > -	if (!platdata->clock)
> > > > -		platdata->clock = dev_read_u32_default(dev,
> > > > "clock-
> > > > frequency", 0);
> > > > -	if (!platdata->clock) {
> > > > -		debug("SiFive UART clock not defined\n");
> > > > -		return -EINVAL;
> > > > +		ret = dev_read_u32(dev, "clock-frequency",
> > > > &clock);
> > > > +		if (IS_ERR_VALUE(ret)) {
> > > > +			debug("SiFive UART clock not
> > > > defined\n");
> > > > +			return 0;
> > > > +		}
> > > > +	} else {
> > > > +		clock = clk_get_rate(&clk);
> > > > +		if (IS_ERR_VALUE(clock)) {
> > > > +			debug("SiFive UART clock get rate
> > > > failed\n");
> > > > +			return 0;
> > > > +		}
> > > >   	}
> > > > -
> > > > +	platdata->clock = clock;
> > > >   	_sifive_serial_setbrg(platdata->regs, platdata->clock,
> > > > baudrate);
> > > >   
> > > >   	return 0;
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 10/11] cpu: Bind timer driver for boot hart

[Anup Patel]

From: Atish Patra <atish.patra@wdc.com>

Currently, timer driver is bound only for hart0.

There is no mandatory requirement that hart0 should always
come up. In fact, HiFive Unleashed SoC hart0 doesn't boot
in S-mode because it only has M-mode.

The timer driver should be bound for boot hart.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 drivers/cpu/riscv_cpu.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 5e15df590e..f77c126499 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -10,6 +10,8 @@
 #include <dm/device-internal.h>
 #include <dm/lists.h>
 
+DECLARE_GLOBAL_DATA_PTR;
+
 static int riscv_cpu_get_desc(struct udevice *dev, char *buf, int size)
 {
 	const char *isa;
@@ -62,7 +64,6 @@ static int riscv_cpu_bind(struct udevice *dev)
 
 	/* save the hart id */
 	plat->cpu_id = dev_read_addr(dev);
-
 	/* first examine the property in current cpu node */
 	ret = dev_read_u32(dev, "timebase-frequency", &plat->timebase_freq);
 	/* if not found, then look at the parent /cpus node */
@@ -71,7 +72,7 @@ static int riscv_cpu_bind(struct udevice *dev)
 			     &plat->timebase_freq);
 
 	/*
-	 * Bind riscv-timer driver on hart 0
+	 * Bind riscv-timer driver on boot hart.
 	 *
 	 * We only instantiate one timer device which is enough for U-Boot.
 	 * Pass the "timebase-frequency" value as the driver data for the
@@ -80,7 +81,7 @@ static int riscv_cpu_bind(struct udevice *dev)
 	 * Return value is not checked since it's possible that the timer
 	 * driver is not included.
 	 */
-	if (!plat->cpu_id && plat->timebase_freq) {
+	if (plat->cpu_id == gd->arch.boot_hart && plat->timebase_freq) {
 		drv = lists_driver_lookup_name("riscv_timer");
 		if (!drv) {
 			debug("Cannot find the timer driver, not included?\n");
-- 
2.17.1

[U-Boot] [PATCH v2 10/11] cpu: Bind timer driver for boot hart

[Alexander Graf]

On 18.01.19 12:19, Anup Patel wrote:
> From: Atish Patra <atish.patra@wdc.com>
> 
> Currently, timer driver is bound only for hart0.
> 
> There is no mandatory requirement that hart0 should always
> come up. In fact, HiFive Unleashed SoC hart0 doesn't boot
> in S-mode because it only has M-mode.
> 
> The timer driver should be bound for boot hart.
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>

... and here :)

> Reviewed-by: Alexander Graf <agraf@suse.de>


Alex

[U-Boot] [PATCH v2 10/11] cpu: Bind timer driver for boot hart

[Anup Patel]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Friday, January 18, 2019 5:22 PM
> To: Anup Patel <Anup.Patel@wdc.com>; Rick Chen <rick@andestech.com>;
> Bin Meng <bmeng.cn@gmail.com>; Joe Hershberger
> <joe.hershberger@ni.com>; Lukas Auer <lukas.auer@aisec.fraunhofer.de>;
> Masahiro Yamada <yamada.masahiro@socionext.com>; Simon Glass
> <sjg@chromium.org>
> Cc: Palmer Dabbelt <palmer@sifive.com>; Paul Walmsley
> <paul.walmsley@sifive.com>; Atish Patra <Atish.Patra@wdc.com>;
> Christoph Hellwig <hch@infradead.org>; U-Boot Mailing List <u-
> boot at lists.denx.de>
> Subject: Re: [PATCH v2 10/11] cpu: Bind timer driver for boot hart
> 
> 
> 
> On 18.01.19 12:19, Anup Patel wrote:
> > From: Atish Patra <atish.patra@wdc.com>
> >
> > Currently, timer driver is bound only for hart0.
> >
> > There is no mandatory requirement that hart0 should always come up. In
> > fact, HiFive Unleashed SoC hart0 doesn't boot in S-mode because it
> > only has M-mode.
> >
> > The timer driver should be bound for boot hart.
> >
> > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> 
> ... and here :)
> 

Sure, I will add my SoB.

Regards,
Anup

[U-Boot] [PATCH v2 10/11] cpu: Bind timer driver for boot hart

[Auer, Lukas]

On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> From: Atish Patra <atish.patra@wdc.com>
> 
> Currently, timer driver is bound only for hart0.
> 
> There is no mandatory requirement that hart0 should always
> come up. In fact, HiFive Unleashed SoC hart0 doesn't boot
> in S-mode because it only has M-mode.
> 
> The timer driver should be bound for boot hart.
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  drivers/cpu/riscv_cpu.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 

Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>

[U-Boot] [PATCH v2 10/11] cpu: Bind timer driver for boot hart

[Bin Meng]

On Fri, Jan 18, 2019 at 7:19 PM Anup Patel <Anup.Patel@wdc.com> wrote:
>
> From: Atish Patra <atish.patra@wdc.com>
>
> Currently, timer driver is bound only for hart0.
>
> There is no mandatory requirement that hart0 should always
> come up. In fact, HiFive Unleashed SoC hart0 doesn't boot
> in S-mode because it only has M-mode.
>
> The timer driver should be bound for boot hart.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  drivers/cpu/riscv_cpu.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

This patch adds SiFive FU540 board support. For now, only
SiFive serial, SiFive PRCI, and Cadance MACB drivers are
only enabled. The SiFive FU540 defconfig by default builds
U-Boot for S-Mode because U-Boot on SiFive FU540 will run
in S-Mode as payload of BBL or OpenSBI.

Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
---
 arch/riscv/Kconfig             |  4 ++++
 board/sifive/fu540/Kconfig     | 42 +++++++++++++++++++++++++++++++++
 board/sifive/fu540/MAINTAINERS |  9 +++++++
 board/sifive/fu540/Makefile    |  5 ++++
 board/sifive/fu540/fu540.c     | 17 ++++++++++++++
 configs/sifive_fu540_defconfig | 11 +++++++++
 include/configs/sifive-fu540.h | 43 ++++++++++++++++++++++++++++++++++
 7 files changed, 131 insertions(+)
 create mode 100644 board/sifive/fu540/Kconfig
 create mode 100644 board/sifive/fu540/MAINTAINERS
 create mode 100644 board/sifive/fu540/Makefile
 create mode 100644 board/sifive/fu540/fu540.c
 create mode 100644 configs/sifive_fu540_defconfig
 create mode 100644 include/configs/sifive-fu540.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6879047ff7..36512a8995 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -14,11 +14,15 @@ config TARGET_AX25_AE350
 config TARGET_QEMU_VIRT
 	bool "Support QEMU Virt Board"
 
+config TARGET_SIFIVE_FU540
+	bool "Support SiFive FU540 Board"
+
 endchoice
 
 # board-specific options below
 source "board/AndesTech/ax25-ae350/Kconfig"
 source "board/emulation/qemu-riscv/Kconfig"
+source "board/sifive/fu540/Kconfig"
 
 # platform-specific options below
 source "arch/riscv/cpu/ax25/Kconfig"
diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
new file mode 100644
index 0000000000..6be3d88144
--- /dev/null
+++ b/board/sifive/fu540/Kconfig
@@ -0,0 +1,42 @@
+if TARGET_SIFIVE_FU540
+
+config SYS_BOARD
+	default "fu540"
+
+config SYS_VENDOR
+	default "sifive"
+
+config SYS_CPU
+	default "generic"
+
+config SYS_CONFIG_NAME
+	default "sifive-fu540"
+
+config SYS_TEXT_BASE
+	default 0x80000000 if !RISCV_SMODE
+	default 0x80200000 if RISCV_SMODE
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+	def_bool y
+	select GENERIC_RISCV
+	imply CMD_DHCP
+	imply CMD_EXT2
+	imply CMD_EXT4
+	imply CMD_FAT
+	imply CMD_FS_GENERIC
+	imply CMD_NET
+	imply CMD_PING
+	imply CLK_SIFIVE
+	imply CLK_SIFIVE_FU540_PRCI
+	imply DOS_PARTITION
+	imply EFI_PARTITION
+	imply IP_DYN
+	imply ISO_PARTITION
+	imply MACB
+	imply MII
+	imply NET_RANDOM_ETHADDR
+	imply PHY_LIB
+	imply PHY_MSCC
+	imply SIFIVE_SERIAL
+
+endif
diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS
new file mode 100644
index 0000000000..702d803ad8
--- /dev/null
+++ b/board/sifive/fu540/MAINTAINERS
@@ -0,0 +1,9 @@
+SiFive FU540 BOARD
+M:	Paul Walmsley <paul.walmsley@sifive.com>
+M:	Palmer Dabbelt <palmer@sifive.com>
+M:	Anup Patel <anup.patel@wdc.com>
+M:	Atish Patra <atish.patra@wdc.com>
+S:	Maintained
+F:	board/sifive/fu540/
+F:	include/configs/sifive-fu540.h
+F:	configs/sifive_fu540_defconfig
diff --git a/board/sifive/fu540/Makefile b/board/sifive/fu540/Makefile
new file mode 100644
index 0000000000..6e1862c475
--- /dev/null
+++ b/board/sifive/fu540/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2019 Western Digital Corporation or its affiliates.
+
+obj-y	+= fu540.o
diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
new file mode 100644
index 0000000000..5adc4a3d4a
--- /dev/null
+++ b/board/sifive/fu540/fu540.c
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ *   Anup Patel <anup.patel@wdc.com>
+ */
+
+#include <common.h>
+#include <dm.h>
+
+int board_init(void)
+{
+	/* For now nothing to do here. */
+
+	return 0;
+}
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
new file mode 100644
index 0000000000..2f8cca9de0
--- /dev/null
+++ b/configs/sifive_fu540_defconfig
@@ -0,0 +1,11 @@
+CONFIG_RISCV=y
+CONFIG_TARGET_SIFIVE_FU540=y
+CONFIG_RISCV_SMODE=y
+CONFIG_ARCH_RV64I=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_CMD_MII=y
+CONFIG_OF_PRIOR_STAGE=y
diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
new file mode 100644
index 0000000000..7007b5f6af
--- /dev/null
+++ b/include/configs/sifive-fu540.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ *   Anup Patel <anup.patel@wdc.com>
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include <linux/sizes.h>
+
+#define CONFIG_SYS_SDRAM_BASE		0x80000000
+#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE + SZ_2M)
+
+#define CONFIG_SYS_LOAD_ADDR		(CONFIG_SYS_SDRAM_BASE + SZ_2M)
+
+#define CONFIG_SYS_MALLOC_LEN		SZ_8M
+
+#define CONFIG_SYS_BOOTM_LEN		SZ_16M
+
+#define CONFIG_STANDALONE_LOAD_ADDR	0x80200000
+
+/* Environment options */
+#define CONFIG_ENV_SIZE			SZ_4K
+
+#define BOOT_TARGET_DEVICES(func) \
+	func(DHCP, dhcp, na)
+
+#include <config_distro_bootcmd.h>
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+	"fdt_high=0xffffffffffffffff\0" \
+	"initrd_high=0xffffffffffffffff\0" \
+	"kernel_addr_r=0x80600000\0" \
+	"fdt_addr_r=0x82200000\0" \
+	"scriptaddr=0x82300000\0" \
+	"pxefile_addr_r=0x82400000\0" \
+	"ramdisk_addr_r=0x82500000\0" \
+	BOOTENV
+
+#endif /* __CONFIG_H */
-- 
2.17.1

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Auer, Lukas]

Hi Anup,

On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> This patch adds SiFive FU540 board support. For now, only
> SiFive serial, SiFive PRCI, and Cadance MACB drivers are
> only enabled. The SiFive FU540 defconfig by default builds
> U-Boot for S-Mode because U-Boot on SiFive FU540 will run
> in S-Mode as payload of BBL or OpenSBI.
> 
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/riscv/Kconfig             |  4 ++++
>  board/sifive/fu540/Kconfig     | 42
> +++++++++++++++++++++++++++++++++
>  board/sifive/fu540/MAINTAINERS |  9 +++++++
>  board/sifive/fu540/Makefile    |  5 ++++
>  board/sifive/fu540/fu540.c     | 17 ++++++++++++++
>  configs/sifive_fu540_defconfig | 11 +++++++++
>  include/configs/sifive-fu540.h | 43
> ++++++++++++++++++++++++++++++++++
>  7 files changed, 131 insertions(+)
>  create mode 100644 board/sifive/fu540/Kconfig
>  create mode 100644 board/sifive/fu540/MAINTAINERS
>  create mode 100644 board/sifive/fu540/Makefile
>  create mode 100644 board/sifive/fu540/fu540.c
>  create mode 100644 configs/sifive_fu540_defconfig
>  create mode 100644 include/configs/sifive-fu540.h
> 

Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>

Can you add a short README on how to flash and use U-Boot on the HiFive
Unleashed?

Please also see one more comment below.

> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 6879047ff7..36512a8995 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -14,11 +14,15 @@ config TARGET_AX25_AE350
>  config TARGET_QEMU_VIRT
>  	bool "Support QEMU Virt Board"
>  
> +config TARGET_SIFIVE_FU540
> +	bool "Support SiFive FU540 Board"
> +
>  endchoice
>  
>  # board-specific options below
>  source "board/AndesTech/ax25-ae350/Kconfig"
>  source "board/emulation/qemu-riscv/Kconfig"
> +source "board/sifive/fu540/Kconfig"
>  
>  # platform-specific options below
>  source "arch/riscv/cpu/ax25/Kconfig"
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> new file mode 100644
> index 0000000000..6be3d88144
> --- /dev/null
> +++ b/board/sifive/fu540/Kconfig
> @@ -0,0 +1,42 @@
> +if TARGET_SIFIVE_FU540
> +
> +config SYS_BOARD
> +	default "fu540"
> +
> +config SYS_VENDOR
> +	default "sifive"
> +
> +config SYS_CPU
> +	default "generic"
> +
> +config SYS_CONFIG_NAME
> +	default "sifive-fu540"
> +
> +config SYS_TEXT_BASE
> +	default 0x80000000 if !RISCV_SMODE
> +	default 0x80200000 if RISCV_SMODE
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> +	def_bool y
> +	select GENERIC_RISCV
> +	imply CMD_DHCP
> +	imply CMD_EXT2
> +	imply CMD_EXT4
> +	imply CMD_FAT
> +	imply CMD_FS_GENERIC
> +	imply CMD_NET
> +	imply CMD_PING
> +	imply CLK_SIFIVE
> +	imply CLK_SIFIVE_FU540_PRCI
> +	imply DOS_PARTITION
> +	imply EFI_PARTITION
> +	imply IP_DYN
> +	imply ISO_PARTITION
> +	imply MACB
> +	imply MII
> +	imply NET_RANDOM_ETHADDR
> +	imply PHY_LIB
> +	imply PHY_MSCC
> +	imply SIFIVE_SERIAL
> +
> +endif
> diff --git a/board/sifive/fu540/MAINTAINERS
> b/board/sifive/fu540/MAINTAINERS
> new file mode 100644
> index 0000000000..702d803ad8
> --- /dev/null
> +++ b/board/sifive/fu540/MAINTAINERS
> @@ -0,0 +1,9 @@
> +SiFive FU540 BOARD
> +M:	Paul Walmsley <paul.walmsley@sifive.com>
> +M:	Palmer Dabbelt <palmer@sifive.com>
> +M:	Anup Patel <anup.patel@wdc.com>
> +M:	Atish Patra <atish.patra@wdc.com>
> +S:	Maintained
> +F:	board/sifive/fu540/
> +F:	include/configs/sifive-fu540.h
> +F:	configs/sifive_fu540_defconfig
> diff --git a/board/sifive/fu540/Makefile
> b/board/sifive/fu540/Makefile
> new file mode 100644
> index 0000000000..6e1862c475
> --- /dev/null
> +++ b/board/sifive/fu540/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2019 Western Digital Corporation or its affiliates.
> +
> +obj-y	+= fu540.o
> diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> new file mode 100644
> index 0000000000..5adc4a3d4a
> --- /dev/null
> +++ b/board/sifive/fu540/fu540.c
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + *
> + * Authors:
> + *   Anup Patel <anup.patel@wdc.com>
> + */
> +
> +#include <common.h>
> +#include <dm.h>
> +
> +int board_init(void)
> +{
> +	/* For now nothing to do here. */
> +
> +	return 0;
> +}
> diff --git a/configs/sifive_fu540_defconfig
> b/configs/sifive_fu540_defconfig
> new file mode 100644
> index 0000000000..2f8cca9de0
> --- /dev/null
> +++ b/configs/sifive_fu540_defconfig
> @@ -0,0 +1,11 @@
> +CONFIG_RISCV=y
> +CONFIG_TARGET_SIFIVE_FU540=y
> +CONFIG_RISCV_SMODE=y
> +CONFIG_ARCH_RV64I=y
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_FIT=y
> +CONFIG_DISPLAY_CPUINFO=y
> +CONFIG_DISPLAY_BOARDINFO=y
> +CONFIG_CMD_MII=y
> +CONFIG_OF_PRIOR_STAGE=y
> diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-
> fu540.h
> new file mode 100644
> index 0000000000..7007b5f6af
> --- /dev/null
> +++ b/include/configs/sifive-fu540.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + *
> + * Authors:
> + *   Anup Patel <anup.patel@wdc.com>
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +#include <linux/sizes.h>
> +
> +#define CONFIG_SYS_SDRAM_BASE		0x80000000
> +#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE
> + SZ_2M)
> +
> +#define CONFIG_SYS_LOAD_ADDR		(CONFIG_SYS_SDRAM_BASE + SZ_2M)
> +
> +#define CONFIG_SYS_MALLOC_LEN		SZ_8M
> +
> +#define CONFIG_SYS_BOOTM_LEN		SZ_16M
> +
> +#define CONFIG_STANDALONE_LOAD_ADDR	0x80200000
> +
> +/* Environment options */
> +#define CONFIG_ENV_SIZE			SZ_4K
> +
> +#define BOOT_TARGET_DEVICES(func) \
> +	func(DHCP, dhcp, na)
> +
> +#include <config_distro_bootcmd.h>
> +
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> +	"fdt_high=0xffffffffffffffff\0" \
> +	"initrd_high=0xffffffffffffffff\0" \
> +	"kernel_addr_r=0x80600000\0" \
> +	"fdt_addr_r=0x82200000\0" \
> +	"scriptaddr=0x82300000\0" \
> +	"pxefile_addr_r=0x82400000\0" \
> +	"ramdisk_addr_r=0x82500000\0" \
> +	BOOTENV

I think it would be helpful to define the kernel command line using the
bootargs environment variable here. For testing I used
"bootargs=console=ttySI0 earlyprintk root=/dev/mmcblk0p2 rootwait"
locally.

Thanks,
Lukas

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Atish Patra]

On 1/20/19 12:26 PM, Auer, Lukas wrote:
> Hi Anup,
> 
> On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
>> This patch adds SiFive FU540 board support. For now, only
>> SiFive serial, SiFive PRCI, and Cadance MACB drivers are
>> only enabled. The SiFive FU540 defconfig by default builds
>> U-Boot for S-Mode because U-Boot on SiFive FU540 will run
>> in S-Mode as payload of BBL or OpenSBI.
>>
>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>> Signed-off-by: Anup Patel <anup.patel@wdc.com>
>> Reviewed-by: Alexander Graf <agraf@suse.de>
>> ---
>>   arch/riscv/Kconfig             |  4 ++++
>>   board/sifive/fu540/Kconfig     | 42
>> +++++++++++++++++++++++++++++++++
>>   board/sifive/fu540/MAINTAINERS |  9 +++++++
>>   board/sifive/fu540/Makefile    |  5 ++++
>>   board/sifive/fu540/fu540.c     | 17 ++++++++++++++
>>   configs/sifive_fu540_defconfig | 11 +++++++++
>>   include/configs/sifive-fu540.h | 43
>> ++++++++++++++++++++++++++++++++++
>>   7 files changed, 131 insertions(+)
>>   create mode 100644 board/sifive/fu540/Kconfig
>>   create mode 100644 board/sifive/fu540/MAINTAINERS
>>   create mode 100644 board/sifive/fu540/Makefile
>>   create mode 100644 board/sifive/fu540/fu540.c
>>   create mode 100644 configs/sifive_fu540_defconfig
>>   create mode 100644 include/configs/sifive-fu540.h
>>
> 
> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> 
> Can you add a short README on how to flash and use U-Boot on the HiFive
> Unleashed?
> 

Thanks for the review. Sure. We will add a README document.

> Please also see one more comment below.
> 
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index 6879047ff7..36512a8995 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -14,11 +14,15 @@ config TARGET_AX25_AE350
>>   config TARGET_QEMU_VIRT
>>   	bool "Support QEMU Virt Board"
>>   
>> +config TARGET_SIFIVE_FU540
>> +	bool "Support SiFive FU540 Board"
>> +
>>   endchoice
>>   
>>   # board-specific options below
>>   source "board/AndesTech/ax25-ae350/Kconfig"
>>   source "board/emulation/qemu-riscv/Kconfig"
>> +source "board/sifive/fu540/Kconfig"
>>   
>>   # platform-specific options below
>>   source "arch/riscv/cpu/ax25/Kconfig"
>> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
>> new file mode 100644
>> index 0000000000..6be3d88144
>> --- /dev/null
>> +++ b/board/sifive/fu540/Kconfig
>> @@ -0,0 +1,42 @@
>> +if TARGET_SIFIVE_FU540
>> +
>> +config SYS_BOARD
>> +	default "fu540"
>> +
>> +config SYS_VENDOR
>> +	default "sifive"
>> +
>> +config SYS_CPU
>> +	default "generic"
>> +
>> +config SYS_CONFIG_NAME
>> +	default "sifive-fu540"
>> +
>> +config SYS_TEXT_BASE
>> +	default 0x80000000 if !RISCV_SMODE
>> +	default 0x80200000 if RISCV_SMODE
>> +
>> +config BOARD_SPECIFIC_OPTIONS # dummy
>> +	def_bool y
>> +	select GENERIC_RISCV
>> +	imply CMD_DHCP
>> +	imply CMD_EXT2
>> +	imply CMD_EXT4
>> +	imply CMD_FAT
>> +	imply CMD_FS_GENERIC
>> +	imply CMD_NET
>> +	imply CMD_PING
>> +	imply CLK_SIFIVE
>> +	imply CLK_SIFIVE_FU540_PRCI
>> +	imply DOS_PARTITION
>> +	imply EFI_PARTITION
>> +	imply IP_DYN
>> +	imply ISO_PARTITION
>> +	imply MACB
>> +	imply MII
>> +	imply NET_RANDOM_ETHADDR
>> +	imply PHY_LIB
>> +	imply PHY_MSCC
>> +	imply SIFIVE_SERIAL
>> +
>> +endif
>> diff --git a/board/sifive/fu540/MAINTAINERS
>> b/board/sifive/fu540/MAINTAINERS
>> new file mode 100644
>> index 0000000000..702d803ad8
>> --- /dev/null
>> +++ b/board/sifive/fu540/MAINTAINERS
>> @@ -0,0 +1,9 @@
>> +SiFive FU540 BOARD
>> +M:	Paul Walmsley <paul.walmsley@sifive.com>
>> +M:	Palmer Dabbelt <palmer@sifive.com>
>> +M:	Anup Patel <anup.patel@wdc.com>
>> +M:	Atish Patra <atish.patra@wdc.com>
>> +S:	Maintained
>> +F:	board/sifive/fu540/
>> +F:	include/configs/sifive-fu540.h
>> +F:	configs/sifive_fu540_defconfig
>> diff --git a/board/sifive/fu540/Makefile
>> b/board/sifive/fu540/Makefile
>> new file mode 100644
>> index 0000000000..6e1862c475
>> --- /dev/null
>> +++ b/board/sifive/fu540/Makefile
>> @@ -0,0 +1,5 @@
>> +# SPDX-License-Identifier: GPL-2.0+
>> +#
>> +# Copyright (c) 2019 Western Digital Corporation or its affiliates.
>> +
>> +obj-y	+= fu540.o
>> diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
>> new file mode 100644
>> index 0000000000..5adc4a3d4a
>> --- /dev/null
>> +++ b/board/sifive/fu540/fu540.c
>> @@ -0,0 +1,17 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
>> + *
>> + * Authors:
>> + *   Anup Patel <anup.patel@wdc.com>
>> + */
>> +
>> +#include <common.h>
>> +#include <dm.h>
>> +
>> +int board_init(void)
>> +{
>> +	/* For now nothing to do here. */
>> +
>> +	return 0;
>> +}
>> diff --git a/configs/sifive_fu540_defconfig
>> b/configs/sifive_fu540_defconfig
>> new file mode 100644
>> index 0000000000..2f8cca9de0
>> --- /dev/null
>> +++ b/configs/sifive_fu540_defconfig
>> @@ -0,0 +1,11 @@
>> +CONFIG_RISCV=y
>> +CONFIG_TARGET_SIFIVE_FU540=y
>> +CONFIG_RISCV_SMODE=y
>> +CONFIG_ARCH_RV64I=y
>> +CONFIG_DISTRO_DEFAULTS=y
>> +CONFIG_NR_DRAM_BANKS=1
>> +CONFIG_FIT=y
>> +CONFIG_DISPLAY_CPUINFO=y
>> +CONFIG_DISPLAY_BOARDINFO=y
>> +CONFIG_CMD_MII=y
>> +CONFIG_OF_PRIOR_STAGE=y
>> diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-
>> fu540.h
>> new file mode 100644
>> index 0000000000..7007b5f6af
>> --- /dev/null
>> +++ b/include/configs/sifive-fu540.h
>> @@ -0,0 +1,43 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
>> + *
>> + * Authors:
>> + *   Anup Patel <anup.patel@wdc.com>
>> + */
>> +
>> +#ifndef __CONFIG_H
>> +#define __CONFIG_H
>> +
>> +#include <linux/sizes.h>
>> +
>> +#define CONFIG_SYS_SDRAM_BASE		0x80000000
>> +#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE
>> + SZ_2M)
>> +
>> +#define CONFIG_SYS_LOAD_ADDR		(CONFIG_SYS_SDRAM_BASE + SZ_2M)
>> +
>> +#define CONFIG_SYS_MALLOC_LEN		SZ_8M
>> +
>> +#define CONFIG_SYS_BOOTM_LEN		SZ_16M
>> +
>> +#define CONFIG_STANDALONE_LOAD_ADDR	0x80200000
>> +
>> +/* Environment options */
>> +#define CONFIG_ENV_SIZE			SZ_4K
>> +
>> +#define BOOT_TARGET_DEVICES(func) \
>> +	func(DHCP, dhcp, na)
>> +
>> +#include <config_distro_bootcmd.h>
>> +
>> +#define CONFIG_EXTRA_ENV_SETTINGS \
>> +	"fdt_high=0xffffffffffffffff\0" \
>> +	"initrd_high=0xffffffffffffffff\0" \
>> +	"kernel_addr_r=0x80600000\0" \
>> +	"fdt_addr_r=0x82200000\0" \
>> +	"scriptaddr=0x82300000\0" \
>> +	"pxefile_addr_r=0x82400000\0" \
>> +	"ramdisk_addr_r=0x82500000\0" \
>> +	BOOTENV
> 
> I think it would be helpful to define the kernel command line using the
> bootargs environment variable here. For testing I used
> "bootargs=console=ttySI0 earlyprintk root=/dev/mmcblk0p2 rootwait"
> locally.
> 
The root partition might be different in different setup. For example, 
if expansion board is connected, root partition might be on sata or nvme 
drive. Should we add a fixed root partition to the bootargs ?

Regards,
Atish
> Thanks,
> Lukas
> 

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Auer, Lukas]

On Sun, 2019-01-20 at 17:22 -0800, Atish Patra wrote:
> On 1/20/19 12:26 PM, Auer, Lukas wrote:
> > Hi Anup,
> > 
> > On Fri, 2019-01-18 at 11:19 +0000, Anup Patel wrote:
> > > This patch adds SiFive FU540 board support. For now, only
> > > SiFive serial, SiFive PRCI, and Cadance MACB drivers are
> > > only enabled. The SiFive FU540 defconfig by default builds
> > > U-Boot for S-Mode because U-Boot on SiFive FU540 will run
> > > in S-Mode as payload of BBL or OpenSBI.
> > > 
> > > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > > Reviewed-by: Alexander Graf <agraf@suse.de>
> > > ---
> > >   arch/riscv/Kconfig             |  4 ++++
> > >   board/sifive/fu540/Kconfig     | 42
> > > +++++++++++++++++++++++++++++++++
> > >   board/sifive/fu540/MAINTAINERS |  9 +++++++
> > >   board/sifive/fu540/Makefile    |  5 ++++
> > >   board/sifive/fu540/fu540.c     | 17 ++++++++++++++
> > >   configs/sifive_fu540_defconfig | 11 +++++++++
> > >   include/configs/sifive-fu540.h | 43
> > > ++++++++++++++++++++++++++++++++++
> > >   7 files changed, 131 insertions(+)
> > >   create mode 100644 board/sifive/fu540/Kconfig
> > >   create mode 100644 board/sifive/fu540/MAINTAINERS
> > >   create mode 100644 board/sifive/fu540/Makefile
> > >   create mode 100644 board/sifive/fu540/fu540.c
> > >   create mode 100644 configs/sifive_fu540_defconfig
> > >   create mode 100644 include/configs/sifive-fu540.h
> > > 
> > 
> > Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> > 
> > Can you add a short README on how to flash and use U-Boot on the
> > HiFive
> > Unleashed?
> > 
> 
> Thanks for the review. Sure. We will add a README document.
> 
> > Please also see one more comment below.
> > 
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index 6879047ff7..36512a8995 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -14,11 +14,15 @@ config TARGET_AX25_AE350
> > >   config TARGET_QEMU_VIRT
> > >   	bool "Support QEMU Virt Board"
> > >   
> > > +config TARGET_SIFIVE_FU540
> > > +	bool "Support SiFive FU540 Board"
> > > +
> > >   endchoice
> > >   
> > >   # board-specific options below
> > >   source "board/AndesTech/ax25-ae350/Kconfig"
> > >   source "board/emulation/qemu-riscv/Kconfig"
> > > +source "board/sifive/fu540/Kconfig"
> > >   
> > >   # platform-specific options below
> > >   source "arch/riscv/cpu/ax25/Kconfig"
> > > diff --git a/board/sifive/fu540/Kconfig
> > > b/board/sifive/fu540/Kconfig
> > > new file mode 100644
> > > index 0000000000..6be3d88144
> > > --- /dev/null
> > > +++ b/board/sifive/fu540/Kconfig
> > > @@ -0,0 +1,42 @@
> > > +if TARGET_SIFIVE_FU540
> > > +
> > > +config SYS_BOARD
> > > +	default "fu540"
> > > +
> > > +config SYS_VENDOR
> > > +	default "sifive"
> > > +
> > > +config SYS_CPU
> > > +	default "generic"
> > > +
> > > +config SYS_CONFIG_NAME
> > > +	default "sifive-fu540"
> > > +
> > > +config SYS_TEXT_BASE
> > > +	default 0x80000000 if !RISCV_SMODE
> > > +	default 0x80200000 if RISCV_SMODE
> > > +
> > > +config BOARD_SPECIFIC_OPTIONS # dummy
> > > +	def_bool y
> > > +	select GENERIC_RISCV
> > > +	imply CMD_DHCP
> > > +	imply CMD_EXT2
> > > +	imply CMD_EXT4
> > > +	imply CMD_FAT
> > > +	imply CMD_FS_GENERIC
> > > +	imply CMD_NET
> > > +	imply CMD_PING
> > > +	imply CLK_SIFIVE
> > > +	imply CLK_SIFIVE_FU540_PRCI
> > > +	imply DOS_PARTITION
> > > +	imply EFI_PARTITION
> > > +	imply IP_DYN
> > > +	imply ISO_PARTITION
> > > +	imply MACB
> > > +	imply MII
> > > +	imply NET_RANDOM_ETHADDR
> > > +	imply PHY_LIB
> > > +	imply PHY_MSCC
> > > +	imply SIFIVE_SERIAL
> > > +
> > > +endif
> > > diff --git a/board/sifive/fu540/MAINTAINERS
> > > b/board/sifive/fu540/MAINTAINERS
> > > new file mode 100644
> > > index 0000000000..702d803ad8
> > > --- /dev/null
> > > +++ b/board/sifive/fu540/MAINTAINERS
> > > @@ -0,0 +1,9 @@
> > > +SiFive FU540 BOARD
> > > +M:	Paul Walmsley <paul.walmsley@sifive.com>
> > > +M:	Palmer Dabbelt <palmer@sifive.com>
> > > +M:	Anup Patel <anup.patel@wdc.com>
> > > +M:	Atish Patra <atish.patra@wdc.com>
> > > +S:	Maintained
> > > +F:	board/sifive/fu540/
> > > +F:	include/configs/sifive-fu540.h
> > > +F:	configs/sifive_fu540_defconfig
> > > diff --git a/board/sifive/fu540/Makefile
> > > b/board/sifive/fu540/Makefile
> > > new file mode 100644
> > > index 0000000000..6e1862c475
> > > --- /dev/null
> > > +++ b/board/sifive/fu540/Makefile
> > > @@ -0,0 +1,5 @@
> > > +# SPDX-License-Identifier: GPL-2.0+
> > > +#
> > > +# Copyright (c) 2019 Western Digital Corporation or its
> > > affiliates.
> > > +
> > > +obj-y	+= fu540.o
> > > diff --git a/board/sifive/fu540/fu540.c
> > > b/board/sifive/fu540/fu540.c
> > > new file mode 100644
> > > index 0000000000..5adc4a3d4a
> > > --- /dev/null
> > > +++ b/board/sifive/fu540/fu540.c
> > > @@ -0,0 +1,17 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (c) 2019 Western Digital Corporation or its
> > > affiliates.
> > > + *
> > > + * Authors:
> > > + *   Anup Patel <anup.patel@wdc.com>
> > > + */
> > > +
> > > +#include <common.h>
> > > +#include <dm.h>
> > > +
> > > +int board_init(void)
> > > +{
> > > +	/* For now nothing to do here. */
> > > +
> > > +	return 0;
> > > +}
> > > diff --git a/configs/sifive_fu540_defconfig
> > > b/configs/sifive_fu540_defconfig
> > > new file mode 100644
> > > index 0000000000..2f8cca9de0
> > > --- /dev/null
> > > +++ b/configs/sifive_fu540_defconfig
> > > @@ -0,0 +1,11 @@
> > > +CONFIG_RISCV=y
> > > +CONFIG_TARGET_SIFIVE_FU540=y
> > > +CONFIG_RISCV_SMODE=y
> > > +CONFIG_ARCH_RV64I=y
> > > +CONFIG_DISTRO_DEFAULTS=y
> > > +CONFIG_NR_DRAM_BANKS=1
> > > +CONFIG_FIT=y
> > > +CONFIG_DISPLAY_CPUINFO=y
> > > +CONFIG_DISPLAY_BOARDINFO=y
> > > +CONFIG_CMD_MII=y
> > > +CONFIG_OF_PRIOR_STAGE=y
> > > diff --git a/include/configs/sifive-fu540.h
> > > b/include/configs/sifive-
> > > fu540.h
> > > new file mode 100644
> > > index 0000000000..7007b5f6af
> > > --- /dev/null
> > > +++ b/include/configs/sifive-fu540.h
> > > @@ -0,0 +1,43 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * Copyright (c) 2019 Western Digital Corporation or its
> > > affiliates.
> > > + *
> > > + * Authors:
> > > + *   Anup Patel <anup.patel@wdc.com>
> > > + */
> > > +
> > > +#ifndef __CONFIG_H
> > > +#define __CONFIG_H
> > > +
> > > +#include <linux/sizes.h>
> > > +
> > > +#define CONFIG_SYS_SDRAM_BASE		0x80000000
> > > +#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_SDRAM_BASE
> > > + SZ_2M)
> > > +
> > > +#define CONFIG_SYS_LOAD_ADDR		(CONFIG_SYS_SDRAM_BASE
> > > + SZ_2M)
> > > +
> > > +#define CONFIG_SYS_MALLOC_LEN		SZ_8M
> > > +
> > > +#define CONFIG_SYS_BOOTM_LEN		SZ_16M
> > > +
> > > +#define CONFIG_STANDALONE_LOAD_ADDR	0x80200000
> > > +
> > > +/* Environment options */
> > > +#define CONFIG_ENV_SIZE			SZ_4K
> > > +
> > > +#define BOOT_TARGET_DEVICES(func) \
> > > +	func(DHCP, dhcp, na)
> > > +
> > > +#include <config_distro_bootcmd.h>
> > > +
> > > +#define CONFIG_EXTRA_ENV_SETTINGS \
> > > +	"fdt_high=0xffffffffffffffff\0" \
> > > +	"initrd_high=0xffffffffffffffff\0" \
> > > +	"kernel_addr_r=0x80600000\0" \
> > > +	"fdt_addr_r=0x82200000\0" \
> > > +	"scriptaddr=0x82300000\0" \
> > > +	"pxefile_addr_r=0x82400000\0" \
> > > +	"ramdisk_addr_r=0x82500000\0" \
> > > +	BOOTENV
> > 
> > I think it would be helpful to define the kernel command line using
> > the
> > bootargs environment variable here. For testing I used
> > "bootargs=console=ttySI0 earlyprintk root=/dev/mmcblk0p2 rootwait"
> > locally.
> > 
> The root partition might be different in different setup. For
> example, 
> if expansion board is connected, root partition might be on sata or
> nvme 
> drive. Should we add a fixed root partition to the bootargs ?
> 

Hm, good point. It's probably better to leave it as is and document it
as part of the boot flow in the board README.

Thanks,
Lukas

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Jan 18 2019, Anup Patel <Anup.Patel@wdc.com> wrote:

> This patch adds SiFive FU540 board support. For now, only
> SiFive serial, SiFive PRCI, and Cadance MACB drivers are
> only enabled. The SiFive FU540 defconfig by default builds
> U-Boot for S-Mode because U-Boot on SiFive FU540 will run
> in S-Mode as payload of BBL or OpenSBI.

What am I expected to see when started with BBL?  All I see is the logo,
then nothing.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Mon, Jan 21, 2019 at 7:26 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Jan 18 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
>
> > This patch adds SiFive FU540 board support. For now, only
> > SiFive serial, SiFive PRCI, and Cadance MACB drivers are
> > only enabled. The SiFive FU540 defconfig by default builds
> > U-Boot for S-Mode because U-Boot on SiFive FU540 will run
> > in S-Mode as payload of BBL or OpenSBI.
>
> What am I expected to see when started with BBL?  All I see is the logo,
> then nothing.
>

Here's the log of BBL+U-Boot on QEMU sifive_u machine:

anup at anup-ubuntu64:~/Work/riscv-test$ qemu-system-riscv64 -M sifive_u
-m 256M -display none -serial stdio -kernel build-riscv-pk-uboot/bbl
bbl loader


U-Boot 2019.01-00018-gc3a9211ebc (Jan 21 2019 - 21:36:12 +0530)

CPU:   rv64imafdcsu
Model: ucbbar,spike-bare,qemu
DRAM:  256 MiB
In:    uart at 10013000
Out:   uart at 10013000
Err:   uart at 10013000
Net:
Warning: ethernet at 100900fc (eth0) using random MAC address - 02:4a:de:c3:c8:80
eth0: ethernet at 100900fc
Hit any key to stop autoboot:  0
ethernet at 100900fc: PHY present at 0
ethernet at 100900fc: link up, 1000Mbps full-duplex (lpa: 0x7c00)
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using ethernet at 100900fc device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x82300000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
ethernet at 100900fc: PHY present at 0
ethernet at 100900fc: link up, 1000Mbps full-duplex (lpa: 0x7c00)
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (0 ms)
Using ethernet at 100900fc device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x80600000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=> ping 10.0.2.2
ethernet at 100900fc: PHY present at 0
ethernet at 100900fc: link up, 1000Mbps full-duplex (lpa: 0x7c00)
Using ethernet at 100900fc device
host 10.0.2.2 is alive
=>
ethernet at 100900fc: PHY present at 0
ethernet at 100900fc: link up, 1000Mbps full-duplex (lpa: 0x7c00)
Using ethernet at 100900fc device
host 10.0.2.2 is alive
=> qemu-system-riscv64: terminating on signal 2


On real board, we generally boot OpenSBI+U-Boot. We will
try and share log of BBL+U-Boot on real board but the log will
look exactly like above.

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:

> On real board, we generally boot OpenSBI+U-Boot. We will
> try and share log of BBL+U-Boot on real board but the log will
> look exactly like above.

Nothing is seen on the real board.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Mon, Jan 21, 2019 at 10:06 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:
>
> > On real board, we generally boot OpenSBI+U-Boot. We will
> > try and share log of BBL+U-Boot on real board but the log will
> > look exactly like above.
>
> Nothing is seen on the real board.

There is a fix required in BBL for real board. We have not send
this fix to riscv-pk.

BBL does not set "stdout-path" in /chosen DT node so you are not
seeing any output from U-Boot on real board. On QEMU, "stdout-path"
is set in DTB by QEMU itself so we don't see any issue on QEMU.

We typically run OpenSBI+U-Boot on real board and OpenSBI sets
"stdout-path" properly before jumping to next stage (i.e. U-Boot) so
even we don't see this issue at our end.

You can easily hack BBL for above fix at your end.

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:

> There is a fix required in BBL for real board. We have not send
> this fix to riscv-pk.

Where can I find the patch?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Mon, Jan 21, 2019 at 10:40 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:
>
> > There is a fix required in BBL for real board. We have not send
> > this fix to riscv-pk.
>
> Where can I find the patch?

The fix is to set following DT prop in /chosen DT node:
stdout-path = "/soc/serial at 10010000:115200"

As we can see, the "stdout-path" is specific to SiFive
FU540 board so setting it in BBL is a nasty hack
hence we did not push it anywhere.

Ideally, we should set above mentioned stdout-path
DT prop in SiFive FU540 DTS passed by FSBL.

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:

> On Mon, Jan 21, 2019 at 10:40 PM Andreas Schwab <schwab@suse.de> wrote:
>>
>> On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:
>>
>> > There is a fix required in BBL for real board. We have not send
>> > this fix to riscv-pk.
>>
>> Where can I find the patch?
>
> The fix is to set following DT prop in /chosen DT node:
> stdout-path = "/soc/serial at 10010000:115200"

How can I do that?  I cannot find any function in fdt.c to add new
nodes.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Atish Patra]

On 1/22/19 1:30 AM, Andreas Schwab wrote:
> On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:
> 
>> On Mon, Jan 21, 2019 at 10:40 PM Andreas Schwab <schwab@suse.de> wrote:
>>>
>>> On Jan 21 2019, Anup Patel <anup@brainfault.org> wrote:
>>>
>>>> There is a fix required in BBL for real board. We have not send
>>>> this fix to riscv-pk.
>>>

Just to clarify, we hacked U-boot to add the serial driver not BBL.
Later, we modified the DT directly in OpenSBI to add the required node.

>>> Where can I find the patch?
>>
>> The fix is to set following DT prop in /chosen DT node:
>> stdout-path = "/soc/serial at 10010000:115200"
> 
> How can I do that?I cannot find any function in fdt.c to add new
> nodes.
>   

There are several ways to do the hack.

BBL doesn't have libfdt included by default. Libfdt is included in 
u-boot. You can try adding that node in u-boot.

or
Here is another hack in U-boot until the OpenSBI is available (Early 
next week).

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index ffcd6d15..aa5ee2cc 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -54,6 +54,16 @@ static int serial_check_stdout(const void *blob, 
struct udevice **devp)
         }
         if (node < 0)
                 node = fdt_path_offset(blob, "console");
+
+       if (node < 0) {
+               const char *sname;
+               sname = fdt_get_alias(blob, "serial0");
+               printf("sname = [%s]\n", sname);
+               if (sname)
+                       node = fdt_path_offset(blob, sname);
+               printf("node = [%d]\n", node);
+       }
+
         if (!uclass_get_device_by_of_offset(UCLASS_SERIAL, node, devp))
                 return 0;


or you can try to edit the DT directly and update the FSBL if you are 
comfortable with it.

Apologies, for the inconvenience. Sending these patches to U-boot 
doesn't make any sense its very board specific. In an ideal world, DT 
should be fixed directly to address these issues.

Regards,
Atish
> Andreas.
> 

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Jan 23 2019, Atish Patra <atish.patra@wdc.com> wrote:

> or you can try to edit the DT directly and update the FSBL if you are
> comfortable with it.

I think it would make sense to add the node in the board init function.
That way it would work whether or not the FSBL is updated.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

> -----Original Message-----
> From: Andreas Schwab [mailto:schwab at suse.de]
> Sent: Thursday, January 24, 2019 3:24 PM
> To: Atish Patra <Atish.Patra@wdc.com>
> Cc: Anup Patel <anup@brainfault.org>; Anup Patel <Anup.Patel@wdc.com>;
> Joe Hershberger <joe.hershberger@ni.com>; U-Boot Mailing List <u-
> boot at lists.denx.de>; Palmer Dabbelt <palmer@sifive.com>; Alexander Graf
> <agraf@suse.de>; Christoph Hellwig <hch@infradead.org>; Paul Walmsley
> <paul.walmsley@sifive.com>
> Subject: Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
> 
> On Jan 23 2019, Atish Patra <atish.patra@wdc.com> wrote:
> 
> > or you can try to edit the DT directly and update the FSBL if you are
> > comfortable with it.
> 
> I think it would make sense to add the node in the board init function.
> That way it would work whether or not the FSBL is updated.

Best way is to either fix in DTS itself or BBL/OpenSBI.

For BBL it is difficult due to lack of matured FDT manipulation APIs.
My bad for previous misinformation about BBL. I thought Atish had
hacked this in BBL but he had hacked U-Boot.

We already have taken care of this in OpenSBI using LibFDT so with
OpenSBI no hacks would be required.

We are just few days away from OpenSBI being made public so no point
of adding work-around for "stdout-path" in U-Boot as well.

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Alexander Graf]

On 24.01.19 11:43, Anup Patel wrote:
> 
> 
>> -----Original Message-----
>> From: Andreas Schwab [mailto:schwab at suse.de]
>> Sent: Thursday, January 24, 2019 3:24 PM
>> To: Atish Patra <Atish.Patra@wdc.com>
>> Cc: Anup Patel <anup@brainfault.org>; Anup Patel <Anup.Patel@wdc.com>;
>> Joe Hershberger <joe.hershberger@ni.com>; U-Boot Mailing List <u-
>> boot at lists.denx.de>; Palmer Dabbelt <palmer@sifive.com>; Alexander Graf
>> <agraf@suse.de>; Christoph Hellwig <hch@infradead.org>; Paul Walmsley
>> <paul.walmsley@sifive.com>
>> Subject: Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
>>
>> On Jan 23 2019, Atish Patra <atish.patra@wdc.com> wrote:
>>
>>> or you can try to edit the DT directly and update the FSBL if you are
>>> comfortable with it.
>>
>> I think it would make sense to add the node in the board init function.
>> That way it would work whether or not the FSBL is updated.
> 
> Best way is to either fix in DTS itself or BBL/OpenSBI.
> 
> For BBL it is difficult due to lack of matured FDT manipulation APIs.
> My bad for previous misinformation about BBL. I thought Atish had
> hacked this in BBL but he had hacked U-Boot.
> 
> We already have taken care of this in OpenSBI using LibFDT so with
> OpenSBI no hacks would be required.
> 
> We are just few days away from OpenSBI being made public so no point
> of adding work-around for "stdout-path" in U-Boot as well.

I disagree. We want people to easily use this code, and not use it as a
means to push for the OpenSBI vs BBL discussion.

So IMHO a quirk that adds the stdout-path property in an early board
init function is the best way to move forward here. That way the "good"
case keeps behaving the same, but we stay compatible to current,
existing previous stage firmware.

Please, don't *ever* consider DT something that you "just modify". If
anything worked with a DT before, you are required to keep it that way.
Otherwise you break the compatibility contract between your firmware layers.


Alex

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Thu, Jan 24, 2019 at 4:16 PM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> On 24.01.19 11:43, Anup Patel wrote:
> >
> >
> >> -----Original Message-----
> >> From: Andreas Schwab [mailto:schwab at suse.de]
> >> Sent: Thursday, January 24, 2019 3:24 PM
> >> To: Atish Patra <Atish.Patra@wdc.com>
> >> Cc: Anup Patel <anup@brainfault.org>; Anup Patel <Anup.Patel@wdc.com>;
> >> Joe Hershberger <joe.hershberger@ni.com>; U-Boot Mailing List <u-
> >> boot at lists.denx.de>; Palmer Dabbelt <palmer@sifive.com>; Alexander Graf
> >> <agraf@suse.de>; Christoph Hellwig <hch@infradead.org>; Paul Walmsley
> >> <paul.walmsley@sifive.com>
> >> Subject: Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
> >>
> >> On Jan 23 2019, Atish Patra <atish.patra@wdc.com> wrote:
> >>
> >>> or you can try to edit the DT directly and update the FSBL if you are
> >>> comfortable with it.
> >>
> >> I think it would make sense to add the node in the board init function.
> >> That way it would work whether or not the FSBL is updated.
> >
> > Best way is to either fix in DTS itself or BBL/OpenSBI.
> >
> > For BBL it is difficult due to lack of matured FDT manipulation APIs.
> > My bad for previous misinformation about BBL. I thought Atish had
> > hacked this in BBL but he had hacked U-Boot.
> >
> > We already have taken care of this in OpenSBI using LibFDT so with
> > OpenSBI no hacks would be required.
> >
> > We are just few days away from OpenSBI being made public so no point
> > of adding work-around for "stdout-path" in U-Boot as well.
>
> I disagree. We want people to easily use this code, and not use it as a
> means to push for the OpenSBI vs BBL discussion.
>
> So IMHO a quirk that adds the stdout-path property in an early board
> init function is the best way to move forward here. That way the "good"
> case keeps behaving the same, but we stay compatible to current,
> existing previous stage firmware.
>
> Please, don't *ever* consider DT something that you "just modify". If
> anything worked with a DT before, you are required to keep it that way.
> Otherwise you break the compatibility contract between your firmware layers.

No issues, I will try to add it board_init().

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Alexander Graf]

On 24.01.19 12:05, Anup Patel wrote:
> On Thu, Jan 24, 2019 at 4:16 PM Alexander Graf <agraf@suse.de> wrote:
>>
>>
>>
>> On 24.01.19 11:43, Anup Patel wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Andreas Schwab [mailto:schwab at suse.de]
>>>> Sent: Thursday, January 24, 2019 3:24 PM
>>>> To: Atish Patra <Atish.Patra@wdc.com>
>>>> Cc: Anup Patel <anup@brainfault.org>; Anup Patel <Anup.Patel@wdc.com>;
>>>> Joe Hershberger <joe.hershberger@ni.com>; U-Boot Mailing List <u-
>>>> boot at lists.denx.de>; Palmer Dabbelt <palmer@sifive.com>; Alexander Graf
>>>> <agraf@suse.de>; Christoph Hellwig <hch@infradead.org>; Paul Walmsley
>>>> <paul.walmsley@sifive.com>
>>>> Subject: Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
>>>>
>>>> On Jan 23 2019, Atish Patra <atish.patra@wdc.com> wrote:
>>>>
>>>>> or you can try to edit the DT directly and update the FSBL if you are
>>>>> comfortable with it.
>>>>
>>>> I think it would make sense to add the node in the board init function.
>>>> That way it would work whether or not the FSBL is updated.
>>>
>>> Best way is to either fix in DTS itself or BBL/OpenSBI.
>>>
>>> For BBL it is difficult due to lack of matured FDT manipulation APIs.
>>> My bad for previous misinformation about BBL. I thought Atish had
>>> hacked this in BBL but he had hacked U-Boot.
>>>
>>> We already have taken care of this in OpenSBI using LibFDT so with
>>> OpenSBI no hacks would be required.
>>>
>>> We are just few days away from OpenSBI being made public so no point
>>> of adding work-around for "stdout-path" in U-Boot as well.
>>
>> I disagree. We want people to easily use this code, and not use it as a
>> means to push for the OpenSBI vs BBL discussion.
>>
>> So IMHO a quirk that adds the stdout-path property in an early board
>> init function is the best way to move forward here. That way the "good"
>> case keeps behaving the same, but we stay compatible to current,
>> existing previous stage firmware.
>>
>> Please, don't *ever* consider DT something that you "just modify". If
>> anything worked with a DT before, you are required to keep it that way.
>> Otherwise you break the compatibility contract between your firmware layers.
> 
> No issues, I will try to add it board_init().

Board_init() is too late. This needs to go into early_board_init_f().
IIUC Andreas is prototyping that approach right now.


Alex

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Thu, Jan 24, 2019 at 4:48 PM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> On 24.01.19 12:05, Anup Patel wrote:
> > On Thu, Jan 24, 2019 at 4:16 PM Alexander Graf <agraf@suse.de> wrote:
> >>
> >>
> >>
> >> On 24.01.19 11:43, Anup Patel wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Andreas Schwab [mailto:schwab at suse.de]
> >>>> Sent: Thursday, January 24, 2019 3:24 PM
> >>>> To: Atish Patra <Atish.Patra@wdc.com>
> >>>> Cc: Anup Patel <anup@brainfault.org>; Anup Patel <Anup.Patel@wdc.com>;
> >>>> Joe Hershberger <joe.hershberger@ni.com>; U-Boot Mailing List <u-
> >>>> boot at lists.denx.de>; Palmer Dabbelt <palmer@sifive.com>; Alexander Graf
> >>>> <agraf@suse.de>; Christoph Hellwig <hch@infradead.org>; Paul Walmsley
> >>>> <paul.walmsley@sifive.com>
> >>>> Subject: Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
> >>>>
> >>>> On Jan 23 2019, Atish Patra <atish.patra@wdc.com> wrote:
> >>>>
> >>>>> or you can try to edit the DT directly and update the FSBL if you are
> >>>>> comfortable with it.
> >>>>
> >>>> I think it would make sense to add the node in the board init function.
> >>>> That way it would work whether or not the FSBL is updated.
> >>>
> >>> Best way is to either fix in DTS itself or BBL/OpenSBI.
> >>>
> >>> For BBL it is difficult due to lack of matured FDT manipulation APIs.
> >>> My bad for previous misinformation about BBL. I thought Atish had
> >>> hacked this in BBL but he had hacked U-Boot.
> >>>
> >>> We already have taken care of this in OpenSBI using LibFDT so with
> >>> OpenSBI no hacks would be required.
> >>>
> >>> We are just few days away from OpenSBI being made public so no point
> >>> of adding work-around for "stdout-path" in U-Boot as well.
> >>
> >> I disagree. We want people to easily use this code, and not use it as a
> >> means to push for the OpenSBI vs BBL discussion.
> >>
> >> So IMHO a quirk that adds the stdout-path property in an early board
> >> init function is the best way to move forward here. That way the "good"
> >> case keeps behaving the same, but we stay compatible to current,
> >> existing previous stage firmware.
> >>
> >> Please, don't *ever* consider DT something that you "just modify". If
> >> anything worked with a DT before, you are required to keep it that way.
> >> Otherwise you break the compatibility contract between your firmware layers.
> >
> > No issues, I will try to add it board_init().
>
> Board_init() is too late. This needs to go into early_board_init_f().
> IIUC Andreas is prototyping that approach right now.

Thanks Alex and Andreas.

My latest patches are in riscv_sifive_fu540_v4 branch of
https://github.com/avpatel/u-boot

I can include Andreas's patch in my v5. If he is fine with it.

Regards,
Anup

>
>
> Alex

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Jan 24 2019, Alexander Graf <agraf@suse.de> wrote:

> Board_init() is too late. This needs to go into early_board_init_f().

I don't think we can modify the DT that early.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Alexander Graf]

On 24.01.19 14:38, Andreas Schwab wrote:
> On Jan 24 2019, Alexander Graf <agraf@suse.de> wrote:
> 
>> Board_init() is too late. This needs to go into early_board_init_f().
> 
> I don't think we can modify the DT that early.

I'm sure we can. Worst case we have to copy it over to RAM first.

What obstacle exactly did you run into? Did you try to prototype the
change in a QEMU environment first to get some better debugging insights?


Alex

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Jan 24 2019, Alexander Graf <agraf@suse.de> wrote:

> On 24.01.19 14:38, Andreas Schwab wrote:
>> On Jan 24 2019, Alexander Graf <agraf@suse.de> wrote:
>> 
>>> Board_init() is too late. This needs to go into early_board_init_f().
>> 
>> I don't think we can modify the DT that early.
>
> I'm sure we can. Worst case we have to copy it over to RAM first.

reserve_fdt is only called much later.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Thu, Jan 24, 2019 at 7:27 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Jan 24 2019, Alexander Graf <agraf@suse.de> wrote:
>
> > On 24.01.19 14:38, Andreas Schwab wrote:
> >> On Jan 24 2019, Alexander Graf <agraf@suse.de> wrote:
> >>
> >>> Board_init() is too late. This needs to go into early_board_init_f().
> >>
> >> I don't think we can modify the DT that early.
> >
> > I'm sure we can. Worst case we have to copy it over to RAM first.
>
> reserve_fdt is only called much later.

OpenSBI is public now.

Can try with https://github.com/riscv/opensbi.git ?

There is README for SiFive FU540 at
<opensbi_sources>/docs/platform/sifive_fu540.md

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Feb 03 2019, Anup Patel <anup@brainfault.org> wrote:

> Can try with https://github.com/riscv/opensbi.git ?

 AS-DEP    platform/sifive/fu540/firmware/fw_payload.dep
/bin/sh: -g: command not found

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Atish Patra]

Probably your cross compilation is not set. Can you try this ?

export ARCH=riscv
export CROSS_COMPILE= <riscv cross compile prefix>

Sent from my iPhone

> On Feb 4, 2019, at 11:17 AM, Andreas Schwab <schwab@suse.de> wrote:
> 
>> On Feb 03 2019, Anup Patel <anup@brainfault.org> wrote:
>> 
>> Can try with https://github.com/riscv/opensbi.git ?
> 
> AS-DEP    platform/sifive/fu540/firmware/fw_payload.dep
> /bin/sh: -g: command not found
> 
> Andreas.
> 
> -- 
> Andreas Schwab, SUSE Labs, schwab at suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Feb 04 2019, Atish Patra <Atish.Patra@wdc.com> wrote:

> Probably your cross compilation is not set. Can you try this ?
>
> export ARCH=riscv
> export CROSS_COMPILE= <riscv cross compile prefix>

There is no cross compile prefix.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Mon, Feb 4, 2019 at 6:40 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 04 2019, Atish Patra <Atish.Patra@wdc.com> wrote:
>
> > Probably your cross compilation is not set. Can you try this ?
> >
> > export ARCH=riscv
> > export CROSS_COMPILE= <riscv cross compile prefix>
>
> There is no cross compile prefix.
>

The OpenSBI build is similar to Linux and U-Boot. We expect
CROSS_COMPILE environment variable to be set.

Make sure, CROSS_COMPILE environment variable is set and
exported before running make.

Example, if you cross-compiler is riscv64-unknown-linux-gnu-gcc
then do:
# export CROSS_COMPILE=riscv64-unknown-linux-gnu-

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Feb 05 2019, Anup Patel <anup@brainfault.org> wrote:

> The OpenSBI build is similar to Linux and U-Boot. We expect
> CROSS_COMPILE environment variable to be set.

Why?  That doesn't make sense.

> Example, if you cross-compiler

I don't have a cross compiler.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Tue, Feb 5, 2019 at 6:21 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 05 2019, Anup Patel <anup@brainfault.org> wrote:
>
> > The OpenSBI build is similar to Linux and U-Boot. We expect
> > CROSS_COMPILE environment variable to be set.
>
> Why?  That doesn't make sense.

Use of CROSS_COMPILE environment variable is
pretty common across open-source projects to support
cross compilation.

>
> > Example, if you cross-compiler
>
> I don't have a cross compiler.

Okay, if you are doing native compilation then
make sure CROSS_COMPILE is not set so that
makefile will take native compiler instead of
cross-compiler.

Regards.
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Feb 05 2019, Anup Patel <anup@brainfault.org> wrote:

> Okay, if you are doing native compilation then
> make sure CROSS_COMPILE is not set so that
> makefile will take native compiler instead of
> cross-compiler.

 AS-DEP    platform/sifive/fu540/firmware/fw_payload.dep
/bin/sh: -g: command not found

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Tue, Feb 5, 2019 at 7:10 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 05 2019, Anup Patel <anup@brainfault.org> wrote:
>
> > Okay, if you are doing native compilation then
> > make sure CROSS_COMPILE is not set so that
> > makefile will take native compiler instead of
> > cross-compiler.
>
>  AS-DEP    platform/sifive/fu540/firmware/fw_payload.dep
> /bin/sh: -g: command not found

Can you share output of make with "V=1" parameter?

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

mkdir -p `dirname /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep`; echo " AS-DEP    platform/sifive/fu540/firmware/fw_payload.dep"; echo -n `dirname /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep`/ > /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep &&  -g -Wall -nostdlib -D__ASSEMBLY__ -fno-omit-frame-pointer -fno-optimize-sibling-calls -mno-save-restore -mstrict-align -I/net/hawking/daten/src/riscv/opensbi/platform/sifive/fu540/include -I/net/hawking/daten/src/riscv/opensbi/platform/common/include -I/net/hawking/daten/src/riscv/opensbi/include -I/net/hawking/daten/src/riscv/opensbi/platform/common/libfdt/   -DFW_TEXT_START=0x80000000 -DFW_JUMP_ADDR=0x80200000 -DFW_JUMP_FDT_ADDR=0x82200000 -DFW_PAYLOAD_PATH=/boot/Image-5.0.0-rc5-00011-gcf1db34127ee -DFW_PAYLOAD_OFFSET=0x200000 -DFW_PAYLOAD_FDT_ADDR=0x82200000 -mabi=lp64 -march=rv64imafdc -mcmodel=medany  -I/net/hawking/daten/src/riscv/opensbi/firmware -D__OBJNAME__=fw_payload.dep -MM /net/hawking/daten/src/riscv/opensbi/firmware/fw_payload.S >> /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep || rm -f /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Tue, Feb 5, 2019 at 8:09 PM Andreas Schwab <schwab@suse.de> wrote:
>
> mkdir -p `dirname /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep`; echo " AS-DEP    platform/sifive/fu540/firmware/fw_payload.dep"; echo -n `dirname /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep`/ > /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep &&  -g -Wall -nostdlib -D__ASSEMBLY__ -fno-omit-frame-pointer -fno-optimize-sibling-calls -mno-save-restore -mstrict-align -I/net/hawking/daten/src/riscv/opensbi/platform/sifive/fu540/include -I/net/hawking/daten/src/riscv/opensbi/platform/common/include -I/net/hawking/daten/src/riscv/opensbi/include -I/net/hawking/daten/src/riscv/opensbi/platform/common/libfdt/   -DFW_TEXT_START=0x80000000 -DFW_JUMP_ADDR=0x80200000 -DFW_JUMP_FDT_ADDR=0x82200000 -DFW_PAYLOAD_PATH=/boot/Image-5.0.0-rc5-00011-gcf1db34127ee -DFW_PAYLOAD_OFFSET=0x200000 -DFW_PAYLOAD_FDT_ADDR=0x82200000 -mabi=lp64 -march=rv64imafdc -mcmodel=medany  -I/net/hawking/daten/src/riscv/opensbi/firmware -D__OBJNAME__=fw_payload.dep -MM /net/hawking/daten/src/riscv/opensbi/firmware/fw_payload.S >> /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep || rm -f /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep

Ahh, looks like it is not picking up "CC" set by Makefile. This might
be because you have removed "-R" from MAKEFLAGS.

CC should be either "$(CROSS_COMPILE)gcc" or "gcc".

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Andreas Schwab]

On Feb 05 2019, Anup Patel <anup@brainfault.org> wrote:

> Ahh, looks like it is not picking up "CC" set by Makefile. This might
> be because you have removed "-R" from MAKEFLAGS.

Nope.  That fixed it.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Anup Patel]

On Tue, Feb 5, 2019 at 8:30 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 05 2019, Anup Patel <anup@brainfault.org> wrote:
>
> > Ahh, looks like it is not picking up "CC" set by Makefile. This might
> > be because you have removed "-R" from MAKEFLAGS.
>
> Nope.  That fixed it.

Cool, I had already approved your PR on OpenSBI Github.

Most of us just do cross-compilation so thanks for trying
native compilation.

Regards,
Anup

[U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support

[Bin Meng]

On Fri, Jan 18, 2019 at 7:19 PM Anup Patel <Anup.Patel@wdc.com> wrote:
>
> This patch adds SiFive FU540 board support. For now, only
> SiFive serial, SiFive PRCI, and Cadance MACB drivers are
> only enabled. The SiFive FU540 defconfig by default builds
> U-Boot for S-Mode because U-Boot on SiFive FU540 will run
> in S-Mode as payload of BBL or OpenSBI.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/riscv/Kconfig             |  4 ++++
>  board/sifive/fu540/Kconfig     | 42 +++++++++++++++++++++++++++++++++
>  board/sifive/fu540/MAINTAINERS |  9 +++++++
>  board/sifive/fu540/Makefile    |  5 ++++
>  board/sifive/fu540/fu540.c     | 17 ++++++++++++++
>  configs/sifive_fu540_defconfig | 11 +++++++++
>  include/configs/sifive-fu540.h | 43 ++++++++++++++++++++++++++++++++++
>  7 files changed, 131 insertions(+)
>  create mode 100644 board/sifive/fu540/Kconfig
>  create mode 100644 board/sifive/fu540/MAINTAINERS
>  create mode 100644 board/sifive/fu540/Makefile
>  create mode 100644 board/sifive/fu540/fu540.c
>  create mode 100644 configs/sifive_fu540_defconfig
>  create mode 100644 include/configs/sifive-fu540.h
>

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Auer, Lukas]

Hi Anup,

On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> This patchset adds SiFive Freedom Unleashed (FU540) support
> to RISC-V U-Boot.
> 
> The patches are based upon latest RISC-V U-Boot tree
> (git://git.denx.de/u-boot-riscv.git) at commit id
> 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> 
> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> MACB Ethernet work fine on actual SiFive Unleashed board and
> QEMU sifive_u machine.
> 

Thanks for working on this! Are you also planning on adding the
features of the FSBL to U-Boot to remove it from the boot flow?

I was able to run U-Boot and boot Linux successfully on a SiFive HiFive
Unleashed board with this patch series. I had to make one more change,
because U-Boot was not able to find a serial driver and paniced as a
result.

I fixed this by making the serial driver available pre-relocation. For
this, the soc compatible has to be added to cpu/generic/cpu.c and the
serial driver must have the DM_FLAG_PRE_RELOC flag set.

Another way would be to add a "stdout-path" property to the chosen node
of the device tree.

Thanks,
Lukas

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Atish Patra]

On 1/20/19 12:34 PM, Auer, Lukas wrote:
> Hi Anup,
> 
> On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
>> This patchset adds SiFive Freedom Unleashed (FU540) support
>> to RISC-V U-Boot.
>>
>> The patches are based upon latest RISC-V U-Boot tree
>> (git://git.denx.de/u-boot-riscv.git) at commit id
>> 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
>>
>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>> MACB Ethernet work fine on actual SiFive Unleashed board and
>> QEMU sifive_u machine.
>>
> 
> Thanks for working on this! Are you also planning on adding the
> features of the FSBL to U-Boot to remove it from the boot flow?
> 

That would also mean that adding M-mode capability in U-boot. As of now 
the expected boot flow is

ZSBL->FSBL------->BBL/OpenSBI--------->U-boot------------->Linux
(M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S Mode from 
DRAM)

This is not the mandated boot flow but running the last stage boot 
loader from S-mode gives flexibility in virtualization in future.

> I was able to run U-Boot and boot Linux successfully on a SiFive HiFive
> Unleashed board with this patch series. I had to make one more change,
> because U-Boot was not able to find a serial driver and paniced as a
> result.
> 
> I fixed this by making the serial driver available pre-relocation. For
> this, the soc compatible has to be added to cpu/generic/cpu.c and the
> serial driver must have the DM_FLAG_PRE_RELOC flag set.
> 
> Another way would be to add a "stdout-path" property to the chosen node
> of the device tree.
> 

Currently, we modified the DT to add stdout-path in prior stage boot loader.

Regards,
Atish
> Thanks,
> Lukas
> 

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Anup Patel]

> -----Original Message-----
> From: Atish Patra [mailto:atish.patra at wdc.com]
> Sent: Monday, January 21, 2019 7:07 AM
> To: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> yamada.masahiro at socionext.com
> Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org; u-
> boot at lists.denx.de; agraf at suse.de
> Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> 
> On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > Hi Anup,
> >
> > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> >> This patchset adds SiFive Freedom Unleashed (FU540) support to RISC-V
> >> U-Boot.
> >>
> >> The patches are based upon latest RISC-V U-Boot tree
> >> (git://git.denx.de/u-boot-riscv.git) at commit id
> >> 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> >>
> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance MACB
> >> Ethernet work fine on actual SiFive Unleashed board and QEMU sifive_u
> >> machine.
> >>
> >
> > Thanks for working on this! Are you also planning on adding the
> > features of the FSBL to U-Boot to remove it from the boot flow?
> >
> 
> That would also mean that adding M-mode capability in U-boot. As of now
> the expected boot flow is
> 
> ZSBL->FSBL------->BBL/OpenSBI--------->U-boot------------->Linux
> (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S Mode
> from
> DRAM)
> 
> This is not the mandated boot flow but running the last stage boot loader
> from S-mode gives flexibility in virtualization in future.

To elaborate more on what Atish already mentioned, our rationale behind
ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader) is
as follows:
1. We don't want to replicate FSBL code (DRAM and other system-level init)
in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc)
2. We don't want to replicate SBI runtime implementation in general
purpose bootloaders (U-Boot, UEFI/Tianocore, etc)
3. We want to use general purpose bootloader (U-Boot, UEFI/Tianocore, etc)
inside Guest/VM (S-mode)

Of course, above boot flow is not mandatory. There could be RISC-V systems
where prior booting stages (such as ZSBL and FSBL) don't exist so users have
following options:
1. Run U-Boot in M-mode for such RISC-V systems and link to OpenSBI static
library for SBI runtime services
2. Run U-Boot in S-mode but do most system-level initialization (including
DRAM init) in OpenSBI firmware. In other words, use following booting flow:
OpenSBI (M-mode) -> U-Boot (S-mode)

For point1 above, we will first try it with U-Boot M-mode on QEMU Virt
machine.

> 
> > I was able to run U-Boot and boot Linux successfully on a SiFive
> > HiFive Unleashed board with this patch series. I had to make one more
> > change, because U-Boot was not able to find a serial driver and
> > paniced as a result.
> >
> > I fixed this by making the serial driver available pre-relocation. For
> > this, the soc compatible has to be added to cpu/generic/cpu.c and the
> > serial driver must have the DM_FLAG_PRE_RELOC flag set.
> >
> > Another way would be to add a "stdout-path" property to the chosen
> > node of the device tree.
> >
> 
> Currently, we modified the DT to add stdout-path in prior stage boot loader.
> 
> Regards,
> Atish
> > Thanks,
> > Lukas
> >
Regards,
Anup

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Bin Meng]

Hi Anup,

On Mon, Jan 21, 2019 at 12:04 PM Anup Patel <Anup.Patel@wdc.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Atish Patra [mailto:atish.patra at wdc.com]
> > Sent: Monday, January 21, 2019 7:07 AM
> > To: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > yamada.masahiro at socionext.com
> > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org; u-
> > boot at lists.denx.de; agraf at suse.de
> > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> >
> > On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > > Hi Anup,
> > >
> > > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > >> This patchset adds SiFive Freedom Unleashed (FU540) support to RISC-V
> > >> U-Boot.
> > >>
> > >> The patches are based upon latest RISC-V U-Boot tree
> > >> (git://git.denx.de/u-boot-riscv.git) at commit id
> > >> 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> > >>
> > >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance MACB
> > >> Ethernet work fine on actual SiFive Unleashed board and QEMU sifive_u
> > >> machine.
> > >>
> > >
> > > Thanks for working on this! Are you also planning on adding the
> > > features of the FSBL to U-Boot to remove it from the boot flow?
> > >
> >
> > That would also mean that adding M-mode capability in U-boot. As of now
> > the expected boot flow is
> >
> > ZSBL->FSBL------->BBL/OpenSBI--------->U-boot------------->Linux
> > (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S Mode
> > from
> > DRAM)
> >
> > This is not the mandated boot flow but running the last stage boot loader
> > from S-mode gives flexibility in virtualization in future.
>
> To elaborate more on what Atish already mentioned, our rationale behind
> ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader) is
> as follows:
> 1. We don't want to replicate FSBL code (DRAM and other system-level init)
> in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc)
> 2. We don't want to replicate SBI runtime implementation in general
> purpose bootloaders (U-Boot, UEFI/Tianocore, etc)
> 3. We want to use general purpose bootloader (U-Boot, UEFI/Tianocore, etc)
> inside Guest/VM (S-mode)
>
> Of course, above boot flow is not mandatory. There could be RISC-V systems
> where prior booting stages (such as ZSBL and FSBL) don't exist so users have
> following options:
> 1. Run U-Boot in M-mode for such RISC-V systems and link to OpenSBI static
> library for SBI runtime services
> 2. Run U-Boot in S-mode but do most system-level initialization (including
> DRAM init) in OpenSBI firmware. In other words, use following booting flow:
> OpenSBI (M-mode) -> U-Boot (S-mode)
>
> For point1 above, we will first try it with U-Boot M-mode on QEMU Virt
> machine.

Has the OpenSBI project be started somewhere?

Regards,
Bin

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Anup Patel]

> -----Original Message-----
> From: Bin Meng [mailto:bmeng.cn at gmail.com]
> Sent: Monday, January 21, 2019 11:44 AM
> To: Anup Patel <Anup.Patel@wdc.com>
> Cc: Atish Patra <Atish.Patra@wdc.com>; Auer, Lukas
> <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> rick at andestech.com; joe.hershberger at ni.com;
> yamada.masahiro at socionext.com; paul.walmsley at sifive.com;
> palmer at sifive.com; hch at infradead.org; u-boot at lists.denx.de;
> agraf at suse.de
> Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> 
> Hi Anup,
> 
> On Mon, Jan 21, 2019 at 12:04 PM Anup Patel <Anup.Patel@wdc.com>
> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Atish Patra [mailto:atish.patra at wdc.com]
> > > Sent: Monday, January 21, 2019 7:07 AM
> > > To: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> > > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > > <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > > yamada.masahiro at socionext.com
> > > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org;
> > > u- boot at lists.denx.de; agraf at suse.de
> > > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > >
> > > On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > > > Hi Anup,
> > > >
> > > > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > > >> This patchset adds SiFive Freedom Unleashed (FU540) support to
> > > >> RISC-V U-Boot.
> > > >>
> > > >> The patches are based upon latest RISC-V U-Boot tree
> > > >> (git://git.denx.de/u-boot-riscv.git) at commit id
> > > >> 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> > > >>
> > > >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance MACB
> > > >> Ethernet work fine on actual SiFive Unleashed board and QEMU
> > > >> sifive_u machine.
> > > >>
> > > >
> > > > Thanks for working on this! Are you also planning on adding the
> > > > features of the FSBL to U-Boot to remove it from the boot flow?
> > > >
> > >
> > > That would also mean that adding M-mode capability in U-boot. As of
> > > now the expected boot flow is
> > >
> > > ZSBL->FSBL------->BBL/OpenSBI--------->U-boot------------->Linux
> > > (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S
> Mode
> > > from
> > > DRAM)
> > >
> > > This is not the mandated boot flow but running the last stage boot
> > > loader from S-mode gives flexibility in virtualization in future.
> >
> > To elaborate more on what Atish already mentioned, our rationale
> > behind
> > ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader) is
> > as follows:
> > 1. We don't want to replicate FSBL code (DRAM and other system-level
> > init) in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc) 2.
> > We don't want to replicate SBI runtime implementation in general
> > purpose bootloaders (U-Boot, UEFI/Tianocore, etc) 3. We want to use
> > general purpose bootloader (U-Boot, UEFI/Tianocore, etc) inside
> > Guest/VM (S-mode)
> >
> > Of course, above boot flow is not mandatory. There could be RISC-V
> > systems where prior booting stages (such as ZSBL and FSBL) don't exist
> > so users have following options:
> > 1. Run U-Boot in M-mode for such RISC-V systems and link to OpenSBI
> > static library for SBI runtime services 2. Run U-Boot in S-mode but do
> > most system-level initialization (including DRAM init) in OpenSBI
> > firmware. In other words, use following booting flow:
> > OpenSBI (M-mode) -> U-Boot (S-mode)
> >
> > For point1 above, we will first try it with U-Boot M-mode on QEMU Virt
> > machine.
> 
> Has the OpenSBI project be started somewhere?

Yes, it exist on Github under https://github.com/riscv

Currently, OpenSBI is at-par with BBL in-terms of SBI implementation
but it is extensible and supports lot more boards/targets namely:
1. QEMU virt machine
2. QEMU sifive_u machine
3. SiFive FU540 Unleashed board
4. Kendryte K210 board

We are almost there and just need some more time for finishing
touches. We will be making is Public very soon (few more days)
so stay tuned.

Of course, we will need help from everyone to make OpenSBI
better after all it be a community driver open-source project.

There is SBI extensions spec under discussion which will be
added in OpenSBI once it is frozen.

All of us will be present at up-coming FOSDEM19 to talk about
SBI extensions, OpenSBI project, and other stuff.

Best Regards,
Anup Patel

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Bin Meng]

Hi Anup,

On Mon, Jan 21, 2019 at 2:41 PM Anup Patel <Anup.Patel@wdc.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Bin Meng [mailto:bmeng.cn at gmail.com]
> > Sent: Monday, January 21, 2019 11:44 AM
> > To: Anup Patel <Anup.Patel@wdc.com>
> > Cc: Atish Patra <Atish.Patra@wdc.com>; Auer, Lukas
> > <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> > rick at andestech.com; joe.hershberger at ni.com;
> > yamada.masahiro at socionext.com; paul.walmsley at sifive.com;
> > palmer at sifive.com; hch at infradead.org; u-boot at lists.denx.de;
> > agraf at suse.de
> > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> >
> > Hi Anup,
> >
> > On Mon, Jan 21, 2019 at 12:04 PM Anup Patel <Anup.Patel@wdc.com>
> > wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Atish Patra [mailto:atish.patra at wdc.com]
> > > > Sent: Monday, January 21, 2019 7:07 AM
> > > > To: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> > > > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > > > <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > > > yamada.masahiro at socionext.com
> > > > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org;
> > > > u- boot at lists.denx.de; agraf at suse.de
> > > > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > > >
> > > > On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > > > > Hi Anup,
> > > > >
> > > > > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > > > >> This patchset adds SiFive Freedom Unleashed (FU540) support to
> > > > >> RISC-V U-Boot.
> > > > >>
> > > > >> The patches are based upon latest RISC-V U-Boot tree
> > > > >> (git://git.denx.de/u-boot-riscv.git) at commit id
> > > > >> 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> > > > >>
> > > > >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance MACB
> > > > >> Ethernet work fine on actual SiFive Unleashed board and QEMU
> > > > >> sifive_u machine.
> > > > >>
> > > > >
> > > > > Thanks for working on this! Are you also planning on adding the
> > > > > features of the FSBL to U-Boot to remove it from the boot flow?
> > > > >
> > > >
> > > > That would also mean that adding M-mode capability in U-boot. As of
> > > > now the expected boot flow is
> > > >
> > > > ZSBL->FSBL------->BBL/OpenSBI--------->U-boot------------->Linux
> > > > (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S
> > Mode
> > > > from
> > > > DRAM)
> > > >
> > > > This is not the mandated boot flow but running the last stage boot
> > > > loader from S-mode gives flexibility in virtualization in future.
> > >
> > > To elaborate more on what Atish already mentioned, our rationale
> > > behind
> > > ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader) is
> > > as follows:
> > > 1. We don't want to replicate FSBL code (DRAM and other system-level
> > > init) in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc) 2.
> > > We don't want to replicate SBI runtime implementation in general
> > > purpose bootloaders (U-Boot, UEFI/Tianocore, etc) 3. We want to use
> > > general purpose bootloader (U-Boot, UEFI/Tianocore, etc) inside
> > > Guest/VM (S-mode)
> > >
> > > Of course, above boot flow is not mandatory. There could be RISC-V
> > > systems where prior booting stages (such as ZSBL and FSBL) don't exist
> > > so users have following options:
> > > 1. Run U-Boot in M-mode for such RISC-V systems and link to OpenSBI
> > > static library for SBI runtime services 2. Run U-Boot in S-mode but do
> > > most system-level initialization (including DRAM init) in OpenSBI
> > > firmware. In other words, use following booting flow:
> > > OpenSBI (M-mode) -> U-Boot (S-mode)
> > >
> > > For point1 above, we will first try it with U-Boot M-mode on QEMU Virt
> > > machine.
> >
> > Has the OpenSBI project be started somewhere?
>
> Yes, it exist on Github under https://github.com/riscv
>

I did not find the project under https://github.com/riscv. Maybe it is
an internal one at present?

> Currently, OpenSBI is at-par with BBL in-terms of SBI implementation
> but it is extensible and supports lot more boards/targets namely:
> 1. QEMU virt machine
> 2. QEMU sifive_u machine
> 3. SiFive FU540 Unleashed board
> 4. Kendryte K210 board
>
> We are almost there and just need some more time for finishing
> touches. We will be making is Public very soon (few more days)
> so stay tuned.
>
> Of course, we will need help from everyone to make OpenSBI
> better after all it be a community driver open-source project.
>
> There is SBI extensions spec under discussion which will be
> added in OpenSBI once it is frozen.
>

I've recently posted an question regarding "mhartid" access from
S-mode in the RISC-V ISA ML [1]. If we cannot fix the issue from the
architecture level, then we may have to consider adding "mhartid"
emulation in the SBI. I will copy you guys on that email thread.

> All of us will be present at up-coming FOSDEM19 to talk about
> SBI extensions, OpenSBI project, and other stuff.
>

[1] https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/13afxTuYIcc

Regards,
Bin

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Auer, Lukas]

On Mon, 2019-01-21 at 04:04 +0000, Anup Patel wrote:
> > -----Original Message-----
> > From: Atish Patra [mailto:atish.patra at wdc.com]
> > Sent: Monday, January 21, 2019 7:07 AM
> > To: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > yamada.masahiro at socionext.com
> > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org;
> > u-
> > boot at lists.denx.de; agraf at suse.de
> > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > 
> > On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > > Hi Anup,
> > > 
> > > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > > > This patchset adds SiFive Freedom Unleashed (FU540) support to
> > > > RISC-V
> > > > U-Boot.
> > > > 
> > > > The patches are based upon latest RISC-V U-Boot tree
> > > > (git://git.denx.de/u-boot-riscv.git) at commit id
> > > > 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> > > > 
> > > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> > > > MACB
> > > > Ethernet work fine on actual SiFive Unleashed board and QEMU
> > > > sifive_u
> > > > machine.
> > > > 
> > > 
> > > Thanks for working on this! Are you also planning on adding the
> > > features of the FSBL to U-Boot to remove it from the boot flow?
> > > 
> > 
> > That would also mean that adding M-mode capability in U-boot. As of
> > now
> > the expected boot flow is
> > 
> > ZSBL->FSBL------->BBL/OpenSBI--------->U-boot------------->Linux
> > (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S Mode
> > from
> > DRAM)
> > 
> > This is not the mandated boot flow but running the last stage boot
> > loader
> > from S-mode gives flexibility in virtualization in future.
> 
> To elaborate more on what Atish already mentioned, our rationale
> behind
> ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader) is
> as follows:
> 1. We don't want to replicate FSBL code (DRAM and other system-level
> init)
> in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc)
> 2. We don't want to replicate SBI runtime implementation in general
> purpose bootloaders (U-Boot, UEFI/Tianocore, etc)
> 3. We want to use general purpose bootloader (U-Boot, UEFI/Tianocore,
> etc)
> inside Guest/VM (S-mode)
> 
> Of course, above boot flow is not mandatory. There could be RISC-V
> systems
> where prior booting stages (such as ZSBL and FSBL) don't exist so
> users have
> following options:
> 1. Run U-Boot in M-mode for such RISC-V systems and link to OpenSBI
> static
> library for SBI runtime services
> 2. Run U-Boot in S-mode but do most system-level initialization
> (including
> DRAM init) in OpenSBI firmware. In other words, use following booting
> flow:
> OpenSBI (M-mode) -> U-Boot (S-mode)
> 
> For point1 above, we will first try it with U-Boot M-mode on QEMU
> Virt
> machine.
> 

Thank you for the explanation, Anup and Atish!
I am actually less concerned about adding DRAM initialization into   
U-Boot (but that would be nice to have) and more about having a better
separation of tasks. At the moment, bootloader tasks are included in
both the FSBL (device trees) and BBL (disable the monitor hart). While
the current implementation works fine, it will get complicated as soon
as we have more boards (and importantly, more complicated boards) using
these chips. At this point, the manufacturer will have at least two
board specific software components to update, the FSBL and U-Boot. This
is unneeded complexity, I think.
For the same reason, I agree with you that it does not make sense to
implement the SBI in U-Boot. OpenSBI is better suited to handle this.

A boot flow that could be used in this case is the following.

ZSBL -> U-Boot SPL (M-mode) -> OpenSBI -> U-Boot proper (S-mode)

Thanks,
Lukas

> > > I was able to run U-Boot and boot Linux successfully on a SiFive
> > > HiFive Unleashed board with this patch series. I had to make one
> > > more
> > > change, because U-Boot was not able to find a serial driver and
> > > paniced as a result.
> > > 
> > > I fixed this by making the serial driver available pre-
> > > relocation. For
> > > this, the soc compatible has to be added to cpu/generic/cpu.c and
> > > the
> > > serial driver must have the DM_FLAG_PRE_RELOC flag set.
> > > 
> > > Another way would be to add a "stdout-path" property to the
> > > chosen
> > > node of the device tree.
> > > 
> > 
> > Currently, we modified the DT to add stdout-path in prior stage
> > boot loader.
> > 
> > Regards,
> > Atish
> > > Thanks,
> > > Lukas
> > > 
> Regards,
> Anup

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Anup Patel]

> -----Original Message-----
> From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> Sent: Tuesday, January 22, 2019 5:21 PM
> To: sjg at chromium.org; bmeng.cn at gmail.com; rick at andestech.com; Anup
> Patel <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> yamada.masahiro at socionext.com; Atish Patra <Atish.Patra@wdc.com>
> Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org; u-
> boot at lists.denx.de; agraf at suse.de
> Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> 
> On Mon, 2019-01-21 at 04:04 +0000, Anup Patel wrote:
> > > -----Original Message-----
> > > From: Atish Patra [mailto:atish.patra at wdc.com]
> > > Sent: Monday, January 21, 2019 7:07 AM
> > > To: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>; sjg at chromium.org;
> > > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > > <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > > yamada.masahiro at socionext.com
> > > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org;
> > > u-
> > > boot at lists.denx.de; agraf at suse.de
> > > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > >
> > > On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > > > Hi Anup,
> > > >
> > > > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > > > > This patchset adds SiFive Freedom Unleashed (FU540) support to
> > > > > RISC-V U-Boot.
> > > > >
> > > > > The patches are based upon latest RISC-V U-Boot tree
> > > > > (git://git.denx.de/u-boot-riscv.git) at commit id
> > > > > 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> > > > >
> > > > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance MACB
> > > > > Ethernet work fine on actual SiFive Unleashed board and QEMU
> > > > > sifive_u machine.
> > > > >
> > > >
> > > > Thanks for working on this! Are you also planning on adding the
> > > > features of the FSBL to U-Boot to remove it from the boot flow?
> > > >
> > >
> > > That would also mean that adding M-mode capability in U-boot. As of
> > > now the expected boot flow is
> > >
> > > ZSBL->FSBL------->BBL/OpenSBI--------->U-boot------------->Linux
> > > (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S
> Mode
> > > from
> > > DRAM)
> > >
> > > This is not the mandated boot flow but running the last stage boot
> > > loader from S-mode gives flexibility in virtualization in future.
> >
> > To elaborate more on what Atish already mentioned, our rationale
> > behind
> > ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader) is
> > as follows:
> > 1. We don't want to replicate FSBL code (DRAM and other system-level
> > init)
> > in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc) 2. We
> > don't want to replicate SBI runtime implementation in general purpose
> > bootloaders (U-Boot, UEFI/Tianocore, etc) 3. We want to use general
> > purpose bootloader (U-Boot, UEFI/Tianocore,
> > etc)
> > inside Guest/VM (S-mode)
> >
> > Of course, above boot flow is not mandatory. There could be RISC-V
> > systems where prior booting stages (such as ZSBL and FSBL) don't exist
> > so users have following options:
> > 1. Run U-Boot in M-mode for such RISC-V systems and link to OpenSBI
> > static library for SBI runtime services 2. Run U-Boot in S-mode but do
> > most system-level initialization (including DRAM init) in OpenSBI
> > firmware. In other words, use following booting
> > flow:
> > OpenSBI (M-mode) -> U-Boot (S-mode)
> >
> > For point1 above, we will first try it with U-Boot M-mode on QEMU Virt
> > machine.
> >
> 
> Thank you for the explanation, Anup and Atish!
> I am actually less concerned about adding DRAM initialization into
> U-Boot (but that would be nice to have) and more about having a better
> separation of tasks. At the moment, bootloader tasks are included in
> both the FSBL (device trees) and BBL (disable the monitor hart). While
> the current implementation works fine, it will get complicated as soon
> as we have more boards (and importantly, more complicated boards) using
> these chips. At this point, the manufacturer will have at least two
> board specific software components to update, the FSBL and U-Boot. This
> is unneeded complexity, I think.
> For the same reason, I agree with you that it does not make sense to
> implement the SBI in U-Boot. OpenSBI is better suited to handle this.
> 
> A boot flow that could be used in this case is the following.
> 
> ZSBL -> U-Boot SPL (M-mode) -> OpenSBI -> U-Boot proper (S-mode)

In this boot flow we have U-Boot SPL in-place of FSBL. At very high-level
it is very similar to the boot flow we mentioned.

If we use more generic names to describe the boot flow then it would be:
ROM (on-chip ROM, M-mode) -> LOADER (on-chip SRAM, M-mode) -> RUNTIME (DRAM, M-mode) -> BOOTLOADER (DRAM, S-mode)

I agree that ROM, LOADER, and RUNTIME will be mostly board specific
But BOOTLOADER can be more generic such that it can run on multiple
Boards.

For example:
All drivers for SiFive FU540 in U-Boot are DT-based. If we enable these
drivers for QEMU RISC-V board then we have unified U-Boot image which
works on QEMU virt machine, QEMU sifive_u machine, and SiFive FU540
board. We have tried this ourselves and this actually works.

We can certainly have a generic RISC-V board support in U-Boot where
enabled drivers are DT-based. With this generic RISC-V board support
we can aim for unified U-Boot images which works on multiple boards.

Regards,
Anup

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Auer, Lukas]

On Tue, 2019-01-22 at 12:31 +0000, Anup Patel wrote:
> > -----Original Message-----
> > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> > Sent: Tuesday, January 22, 2019 5:21 PM
> > To: sjg at chromium.org; bmeng.cn at gmail.com; rick at andestech.com; Anup
> > Patel <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > yamada.masahiro at socionext.com; Atish Patra <Atish.Patra@wdc.com>
> > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org;
> > u-
> > boot at lists.denx.de; agraf at suse.de
> > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > 
> > On Mon, 2019-01-21 at 04:04 +0000, Anup Patel wrote:
> > > > -----Original Message-----
> > > > From: Atish Patra [mailto:atish.patra at wdc.com]
> > > > Sent: Monday, January 21, 2019 7:07 AM
> > > > To: Auer, Lukas <lukas.auer@aisec.fraunhofer.de>; 
> > > > sjg at chromium.org;
> > > > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > > > <Anup.Patel@wdc.com>; joe.hershberger at ni.com;
> > > > yamada.masahiro at socionext.com
> > > > Cc: paul.walmsley at sifive.com; palmer at sifive.com; 
> > > > hch at infradead.org;
> > > > u-
> > > > boot at lists.denx.de; agraf at suse.de
> > > > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > > > 
> > > > On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > > > > Hi Anup,
> > > > > 
> > > > > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > > > > > This patchset adds SiFive Freedom Unleashed (FU540) support
> > > > > > to
> > > > > > RISC-V U-Boot.
> > > > > > 
> > > > > > The patches are based upon latest RISC-V U-Boot tree
> > > > > > (git://git.denx.de/u-boot-riscv.git) at commit id
> > > > > > 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> > > > > > 
> > > > > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> > > > > > MACB
> > > > > > Ethernet work fine on actual SiFive Unleashed board and
> > > > > > QEMU
> > > > > > sifive_u machine.
> > > > > > 
> > > > > 
> > > > > Thanks for working on this! Are you also planning on adding
> > > > > the
> > > > > features of the FSBL to U-Boot to remove it from the boot
> > > > > flow?
> > > > > 
> > > > 
> > > > That would also mean that adding M-mode capability in U-boot.
> > > > As of
> > > > now the expected boot flow is
> > > > 
> > > > ZSBL->FSBL------->BBL/OpenSBI--------->U-boot-------------
> > > > >Linux
> > > > (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S
> > Mode
> > > > from
> > > > DRAM)
> > > > 
> > > > This is not the mandated boot flow but running the last stage
> > > > boot
> > > > loader from S-mode gives flexibility in virtualization in
> > > > future.
> > > 
> > > To elaborate more on what Atish already mentioned, our rationale
> > > behind
> > > ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader)
> > > is
> > > as follows:
> > > 1. We don't want to replicate FSBL code (DRAM and other system-
> > > level
> > > init)
> > > in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc) 2.
> > > We
> > > don't want to replicate SBI runtime implementation in general
> > > purpose
> > > bootloaders (U-Boot, UEFI/Tianocore, etc) 3. We want to use
> > > general
> > > purpose bootloader (U-Boot, UEFI/Tianocore,
> > > etc)
> > > inside Guest/VM (S-mode)
> > > 
> > > Of course, above boot flow is not mandatory. There could be RISC-
> > > V
> > > systems where prior booting stages (such as ZSBL and FSBL) don't
> > > exist
> > > so users have following options:
> > > 1. Run U-Boot in M-mode for such RISC-V systems and link to
> > > OpenSBI
> > > static library for SBI runtime services 2. Run U-Boot in S-mode
> > > but do
> > > most system-level initialization (including DRAM init) in OpenSBI
> > > firmware. In other words, use following booting
> > > flow:
> > > OpenSBI (M-mode) -> U-Boot (S-mode)
> > > 
> > > For point1 above, we will first try it with U-Boot M-mode on QEMU
> > > Virt
> > > machine.
> > > 
> > 
> > Thank you for the explanation, Anup and Atish!
> > I am actually less concerned about adding DRAM initialization into
> > U-Boot (but that would be nice to have) and more about having a
> > better
> > separation of tasks. At the moment, bootloader tasks are included
> > in
> > both the FSBL (device trees) and BBL (disable the monitor hart).
> > While
> > the current implementation works fine, it will get complicated as
> > soon
> > as we have more boards (and importantly, more complicated boards)
> > using
> > these chips. At this point, the manufacturer will have at least two
> > board specific software components to update, the FSBL and U-Boot.
> > This
> > is unneeded complexity, I think.
> > For the same reason, I agree with you that it does not make sense
> > to
> > implement the SBI in U-Boot. OpenSBI is better suited to handle
> > this.
> > 
> > A boot flow that could be used in this case is the following.
> > 
> > ZSBL -> U-Boot SPL (M-mode) -> OpenSBI -> U-Boot proper (S-mode)
> 
> In this boot flow we have U-Boot SPL in-place of FSBL. At very high-
> level
> it is very similar to the boot flow we mentioned.
> 
> If we use more generic names to describe the boot flow then it would
> be:
> ROM (on-chip ROM, M-mode) -> LOADER (on-chip SRAM, M-mode) -> RUNTIME
> (DRAM, M-mode) -> BOOTLOADER (DRAM, S-mode)

That's true, the boot flow is more or less the same. The big difference
is that we have one less software project that must be tested and
maintained. :)

> 
> I agree that ROM, LOADER, and RUNTIME will be mostly board specific
> But BOOTLOADER can be more generic such that it can run on multiple
> Boards.
> 
> For example:
> All drivers for SiFive FU540 in U-Boot are DT-based. If we enable
> these
> drivers for QEMU RISC-V board then we have unified U-Boot image which
> works on QEMU virt machine, QEMU sifive_u machine, and SiFive FU540
> board. We have tried this ourselves and this actually works.
> 
> We can certainly have a generic RISC-V board support in U-Boot where
> enabled drivers are DT-based. With this generic RISC-V board support
> we can aim for unified U-Boot images which works on multiple boards.
> 
> Regards,
> Anup

I do agree that a generic bootloader would be a very good thing to have
and I think we should try to keep everything reasonably generic.
However, I also think that we will likely need some degree of board-
specific configuration, which can probably be limited to the device
trees and U-Boot config.

Thanks,
Lukas

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Paul Walmsley]

On Tue, 22 Jan 2019, Auer, Lukas wrote:

> For the same reason, I agree with you that it does not make sense to 
> implement the SBI in U-Boot. OpenSBI is better suited to handle this.

It should be possible to link the OpenSBI library with U-boot, then allow 
U-boot to use SBI services itself, and to expose the SBI services to 
whatever it boots.  So the OpenSBI boot firmware wouldn't be used, but the 
underlying library code would be.  That simplifies the boot flow, since 
the (separate) OpenSBI firmware would no longer be needed.

> A boot flow that could be used in this case is the following.
> 
> ZSBL -> U-Boot SPL (M-mode) -> OpenSBI -> U-Boot proper (S-mode)

There are other boot flows that are common on ARM platforms:

- Boot ROM -> SPL -> U-boot -> Linux
- Boot ROM -> SPL -> U-boot -> (SBI implementation / TEE) -> Linux

It would be good if we could avoid prejudicing against any of these boot 
flows.


- Paul

[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

[Auer, Lukas]

On Sat, 2019-02-02 at 09:06 -0800, Paul Walmsley wrote:
> On Tue, 22 Jan 2019, Auer, Lukas wrote:
> 
> > For the same reason, I agree with you that it does not make sense
> > to 
> > implement the SBI in U-Boot. OpenSBI is better suited to handle
> > this.
> 
> It should be possible to link the OpenSBI library with U-boot, then
> allow 
> U-boot to use SBI services itself, and to expose the SBI services to 
> whatever it boots.  So the OpenSBI boot firmware wouldn't be used,
> but the 
> underlying library code would be.  That simplifies the boot flow,
> since 
> the (separate) OpenSBI firmware would no longer be needed.
> 

Yes, that would also work. I am not at all against integrating the
OpenSBI library into U-Boot. Having a separate SBI implementation
instead of a shared one (OpenSBI) is what I think does not make sense.

Thanks,
Lukas

> > A boot flow that could be used in this case is the following.
> > 
> > ZSBL -> U-Boot SPL (M-mode) -> OpenSBI -> U-Boot proper (S-mode)
> 
> There are other boot flows that are common on ARM platforms:
> 
> - Boot ROM -> SPL -> U-boot -> Linux
> - Boot ROM -> SPL -> U-boot -> (SBI implementation / TEE) -> Linux
> 
> It would be good if we could avoid prejudicing against any of these
> boot 
> flows.
> 
> 
> - Paul