* [U-Boot] [PATCH v7 01/15] riscv: Enable create symlink using kconfig
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
@ 2019-02-11 5:41 ` Anup Patel
2019-02-11 7:45 ` Bin Meng
2019-02-11 5:41 ` [U-Boot] [PATCH v7 02/15] riscv: Rename cpu/qemu to cpu/generic Anup Patel
` (15 subsequent siblings)
16 siblings, 1 reply; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:41 UTC (permalink / raw)
To: u-boot
We select CREATE_ARCH_SYMLINK for RISC-V so that we can have
include/asm/arch linked to include/asm/arch-xyz.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
---
arch/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 35e2712fce..4ebc66227e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -61,6 +61,7 @@ config PPC
config RISCV
bool "RISC-V architecture"
+ select CREATE_ARCH_SYMLINK
select SUPPORT_OF_CONTROL
select OF_CONTROL
select DM
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 02/15] riscv: Rename cpu/qemu to cpu/generic
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
2019-02-11 5:41 ` [U-Boot] [PATCH v7 01/15] riscv: Enable create symlink using kconfig Anup Patel
@ 2019-02-11 5:41 ` Anup Patel
2019-02-11 5:41 ` [U-Boot] [PATCH v7 03/15] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel
` (14 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:41 UTC (permalink / raw)
To: u-boot
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>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
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
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 03/15] riscv: Add asm/dma-mapping.h for DMA mappings
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
2019-02-11 5:41 ` [U-Boot] [PATCH v7 01/15] riscv: Enable create symlink using kconfig Anup Patel
2019-02-11 5:41 ` [U-Boot] [PATCH v7 02/15] riscv: Rename cpu/qemu to cpu/generic Anup Patel
@ 2019-02-11 5:41 ` Anup Patel
2019-02-11 5:41 ` [U-Boot] [PATCH v7 04/15] riscv: Add place-holder asm/arch/clk.h for driver compilation Anup Patel
` (13 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:41 UTC (permalink / raw)
To: u-boot
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>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.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
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 04/15] riscv: Add place-holder asm/arch/clk.h for driver compilation
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (2 preceding siblings ...)
2019-02-11 5:41 ` [U-Boot] [PATCH v7 03/15] riscv: Add asm/dma-mapping.h for DMA mappings Anup Patel
@ 2019-02-11 5:41 ` Anup Patel
2019-02-11 7:47 ` Bin Meng
2019-02-11 5:41 ` [U-Boot] [PATCH v7 05/15] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems Anup Patel
` (12 subsequent siblings)
16 siblings, 1 reply; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:41 UTC (permalink / raw)
To: u-boot
Some of the drivers (such as Cadence MACB ethernet driver) expect
asm/arch/clk.h to be provided by arch support so we add place-holder
asm/arch-generic/clk.h for RISC-V generic CPU.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
---
arch/riscv/include/asm/arch-generic/clk.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 arch/riscv/include/asm/arch-generic/clk.h
diff --git a/arch/riscv/include/asm/arch-generic/clk.h b/arch/riscv/include/asm/arch-generic/clk.h
new file mode 100644
index 0000000000..1631f5f0bd
--- /dev/null
+++ b/arch/riscv/include/asm/arch-generic/clk.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Anup Patel <anup.patel@wdc.com>
+ */
+
+#ifndef __ASM_RISCV_ARCH_CLK_H
+#define __ASM_RISCV_ARCH_CLK_H
+
+/* Note: This is a placeholder header for driver compilation. */
+
+#endif
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 04/15] riscv: Add place-holder asm/arch/clk.h for driver compilation
2019-02-11 5:41 ` [U-Boot] [PATCH v7 04/15] riscv: Add place-holder asm/arch/clk.h for driver compilation Anup Patel
@ 2019-02-11 7:47 ` Bin Meng
0 siblings, 0 replies; 51+ messages in thread
From: Bin Meng @ 2019-02-11 7:47 UTC (permalink / raw)
To: u-boot
On Mon, Feb 11, 2019 at 1:41 PM Anup Patel <Anup.Patel@wdc.com> wrote:
>
> Some of the drivers (such as Cadence MACB ethernet driver) expect
> asm/arch/clk.h to be provided by arch support so we add place-holder
> asm/arch-generic/clk.h for RISC-V generic CPU.
>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> ---
> arch/riscv/include/asm/arch-generic/clk.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> create mode 100644 arch/riscv/include/asm/arch-generic/clk.h
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 05/15] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (3 preceding siblings ...)
2019-02-11 5:41 ` [U-Boot] [PATCH v7 04/15] riscv: Add place-holder asm/arch/clk.h for driver compilation Anup Patel
@ 2019-02-11 5:41 ` Anup Patel
2019-02-11 5:41 ` [U-Boot] [PATCH v7 06/15] net: macb: Fix clk API usage for RISC-V systems Anup Patel
` (11 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:41 UTC (permalink / raw)
To: u-boot
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>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
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..b7b1207235 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 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;
+}
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 06/15] net: macb: Fix clk API usage for RISC-V systems
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (4 preceding siblings ...)
2019-02-11 5:41 ` [U-Boot] [PATCH v7 05/15] riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems Anup Patel
@ 2019-02-11 5:41 ` Anup Patel
2019-02-11 5:42 ` [U-Boot] [PATCH v7 07/15] net: macb: Fix GEM hardware detection Anup Patel
` (10 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:41 UTC (permalink / raw)
To: u-boot
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 | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index c9ee22279a..0254e211e6 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -1061,14 +1061,13 @@ static int macb_enable_clk(struct udevice *dev)
return -EINVAL;
/*
- * Zynq clock driver didn't support for enable or disable
- * clock. Hence, clk_enable() didn't apply for Zynq
+ * If clock driver didn't support enable or disable then
+ * we get -ENOSYS from clk_enable(). To handle this, we
+ * don't fail for ret == -ENOSYS.
*/
-#ifndef CONFIG_MACB_ZYNQ
ret = clk_enable(&clk);
- if (ret)
+ if (ret && ret != -ENOSYS)
return ret;
-#endif
clk_rate = clk_get_rate(&clk);
if (!clk_rate)
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 07/15] net: macb: Fix GEM hardware detection
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (5 preceding siblings ...)
2019-02-11 5:41 ` [U-Boot] [PATCH v7 06/15] net: macb: Fix clk API usage for RISC-V systems Anup Patel
@ 2019-02-11 5:42 ` Anup Patel
2019-02-11 5:42 ` [U-Boot] [PATCH v7 08/15] clk: Add SiFive FU540 PRCI clock driver Anup Patel
` (9 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:42 UTC (permalink / raw)
To: u-boot
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>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
---
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 0254e211e6..182331f61d 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -143,7 +143,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
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 08/15] clk: Add SiFive FU540 PRCI clock driver
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (6 preceding siblings ...)
2019-02-11 5:42 ` [U-Boot] [PATCH v7 07/15] net: macb: Fix GEM hardware detection Anup Patel
@ 2019-02-11 5:42 ` Anup Patel
2019-02-11 5:42 ` [U-Boot] [PATCH v7 09/15] clk: Add fixed-factor " Anup Patel
` (8 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:42 UTC (permalink / raw)
To: u-boot
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 51c931b906..ff60fc5c45 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -105,6 +105,7 @@ source "drivers/clk/mvebu/Kconfig"
source "drivers/clk/owl/Kconfig"
source "drivers/clk/renesas/Kconfig"
source "drivers/clk/sunxi/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 6a4ff9143b..de3d60ed05 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_ARCH_SUNXI) += sunxi/
obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
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
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 09/15] clk: Add fixed-factor clock driver
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (7 preceding siblings ...)
2019-02-11 5:42 ` [U-Boot] [PATCH v7 08/15] clk: Add SiFive FU540 PRCI clock driver Anup Patel
@ 2019-02-11 5:42 ` Anup Patel
2019-02-11 5:42 ` [U-Boot] [PATCH v7 10/15] drivers: serial_sifive: Fix baud rate calculation Anup Patel
` (7 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:42 UTC (permalink / raw)
To: u-boot
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>
---
arch/sandbox/dts/test.dts | 8 ++++
drivers/clk/Makefile | 4 +-
drivers/clk/clk_fixed_factor.c | 72 ++++++++++++++++++++++++++++++++++
test/dm/clk.c | 5 ++-
4 files changed, 87 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/clk_fixed_factor.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 1d011ded7c..cb8d686e46 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -203,6 +203,14 @@
#clock-cells = <0>;
clock-frequency = <1234>;
};
+
+ clk_fixed_factor: clk-fixed-factor {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <3>;
+ clock-mult = <2>;
+ clocks = <&clk_fixed>;
+ };
};
clk_sandbox: clk-sbox {
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index de3d60ed05..1d9d725cae 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..3487c11729
--- /dev/null
+++ b/drivers/clk/clk_fixed_factor.c
@@ -0,0 +1,72 @@
+// 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)
+{
+ uint64_t 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)
+{
+ 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);
+
+ 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,
+};
diff --git a/test/dm/clk.c b/test/dm/clk.c
index 898c034e27..112d5cbbc9 100644
--- a/test/dm/clk.c
+++ b/test/dm/clk.c
@@ -12,12 +12,15 @@
static int dm_test_clk(struct unit_test_state *uts)
{
- struct udevice *dev_fixed, *dev_clk, *dev_test;
+ struct udevice *dev_fixed, *dev_fixed_factor, *dev_clk, *dev_test;
ulong rate;
ut_assertok(uclass_get_device_by_name(UCLASS_CLK, "clk-fixed",
&dev_fixed));
+ ut_assertok(uclass_get_device_by_name(UCLASS_CLK, "clk-fixed-factor",
+ &dev_fixed_factor));
+
ut_assertok(uclass_get_device_by_name(UCLASS_CLK, "clk-sbox",
&dev_clk));
ut_asserteq(0, sandbox_clk_query_enable(dev_clk, SANDBOX_CLK_ID_SPI));
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 10/15] drivers: serial_sifive: Fix baud rate calculation
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (8 preceding siblings ...)
2019-02-11 5:42 ` [U-Boot] [PATCH v7 09/15] clk: Add fixed-factor " Anup Patel
@ 2019-02-11 5:42 ` Anup Patel
2019-02-11 5:42 ` [U-Boot] [PATCH v7 11/15] drivers: serial_sifive: Skip baudrate config if no input clock Anup Patel
` (6 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:42 UTC (permalink / raw)
To: u-boot
From: Atish Patra <atish.patra@wdc.com>
Compute the baud rate multipler with more precision.
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>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.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), ®s->div);
+ writel((uart_min_clk_divisor(clock, baud)), ®s->div);
}
static void _sifive_serial_init(struct uart_sifive *regs)
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 11/15] drivers: serial_sifive: Skip baudrate config if no input clock
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (9 preceding siblings ...)
2019-02-11 5:42 ` [U-Boot] [PATCH v7 10/15] drivers: serial_sifive: Fix baud rate calculation Anup Patel
@ 2019-02-11 5:42 ` Anup Patel
2019-02-11 5:43 ` [U-Boot] [PATCH v7 12/15] cpu: Bind timer driver for boot hart Anup Patel
` (5 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:42 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 12/15] cpu: Bind timer driver for boot hart
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (10 preceding siblings ...)
2019-02-11 5:42 ` [U-Boot] [PATCH v7 11/15] drivers: serial_sifive: Skip baudrate config if no input clock Anup Patel
@ 2019-02-11 5:43 ` Anup Patel
2019-02-11 5:43 ` [U-Boot] [PATCH v7 13/15] riscv: Add SiFive FU540 board support Anup Patel
` (4 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:43 UTC (permalink / raw)
To: u-boot
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>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
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
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 13/15] riscv: Add SiFive FU540 board support
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (11 preceding siblings ...)
2019-02-11 5:43 ` [U-Boot] [PATCH v7 12/15] cpu: Bind timer driver for boot hart Anup Patel
@ 2019-02-11 5:43 ` Anup Patel
2019-02-11 5:43 ` [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540 Anup Patel
` (3 subsequent siblings)
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:43 UTC (permalink / raw)
To: u-boot
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>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
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
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (12 preceding siblings ...)
2019-02-11 5:43 ` [U-Boot] [PATCH v7 13/15] riscv: Add SiFive FU540 board support Anup Patel
@ 2019-02-11 5:43 ` Anup Patel
2019-02-13 0:18 ` Kevin Hilman
2019-02-11 5:43 ` [U-Boot] [PATCH v7 15/15] riscv: Enable CONFIG_SYS_BOOT_RAMDISK_HIGH for using initrd Anup Patel
` (2 subsequent siblings)
16 siblings, 1 reply; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:43 UTC (permalink / raw)
To: u-boot
From: Atish Patra <atish.patra@wdc.com>
The readme guide describes the procedure to build, flash and boot Linux
using U-Boot on HiFive Unleashed. It also explains the current state of
U-boot support and future action items.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
---
doc/README.sifive-fu540 | 303 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 303 insertions(+)
create mode 100644 doc/README.sifive-fu540
diff --git a/doc/README.sifive-fu540 b/doc/README.sifive-fu540
new file mode 100644
index 0000000000..fd9f2a8e46
--- /dev/null
+++ b/doc/README.sifive-fu540
@@ -0,0 +1,303 @@
+FU540-C000 RISC-V SoC
+=====================
+The FU540-C000 is the world’s first 4+1 64-bit RISC‑V SoC from SiFive.
+
+The HiFive Unleashed development platform is based on FU540-C000 and capable
+of running Linux.
+
+Mainline support
+================
+The support for following drivers are already enabled:
+1. SiFive UART Driver.
+2. SiFive PRCI Driver for clock.
+3. Cadence MACB ethernet driver for networking support.
+
+TODO:
+1. SPI driver is still missing. So MMC card can't be used in U-Boot as of now.
+2. U-Boot expects the serial console device entry to be present under /chosen
+ DT node. Example:
+ chosen {
+ stdout-path = "/soc/serial at 10010000:115200";
+ };
+
+ Without a serial console U-Boot will panic.
+
+Building
+========
+1. Add the RISC-V toolchain to your PATH.
+2. Setup ARCH & cross compilation enviornment variable.
+ a. export ARCH=riscv
+ b. export CROSS_COMPILE=<riscv64 toolchain prefix>
+3. make sifive_fu540_defconfig
+4. make
+
+Flashing
+========
+The current U-Boot port is supported in S-mode only and loaded from DRAM.
+
+A prior stage (M-mode) firmware/bootloader (e.g OpenSBI or BBL) is required to
+load the u-boot.bin into memory and provide runtime services. The u-boot.bin
+can be given as a payload to the prior stage (M-mode) firmware/bootloader.
+
+The description of steps required to build the firmware is beyond the scope of
+this document. Please refer OpenSBI or BBL documenation.
+(Note: OpenSBI git repo is at https://github.com/riscv/opensbi.git)
+(Note: BBL git repo is at https://github.com/riscv/riscv-pk.git)
+
+Once the prior stage firmware/bootloader binary is generated, it should be
+copied to the first partition of the sdcard.
+
+sudo dd if=<prior_stage_firmware_binary> of=/dev/disk2s1 bs=1024
+
+Booting
+=======
+Once you plugin the sdcard and power up, you should see the U-Boot prompt.
+
+Sample boot log from HiFive Unleashed board
+===========================================
+U-Boot 2019.01-00019-gc7953536-dirty (Jan 22 2019 - 11:05:40 -0800)
+
+CPU: rv64imafdc
+Model: sifive,hifive-unleashed-a00
+DRAM: 8 GiB
+In: serial at 10010000
+Out: serial at 10010000
+Err: serial at 10010000
+Net:
+Warning: ethernet at 10090000 (eth0) using random MAC address - b6:75:4d:48:50:94
+eth0: ethernet at 10090000
+Hit any key to stop autoboot: 0
+=> version
+U-Boot 2019.01-00019-gc7953536-dirty (Jan 22 2019 - 11:05:40 -0800)
+
+riscv64-linux-gcc.br_real (Buildroot 2018.11-rc2-00003-ga0787e9) 8.2.0
+GNU ld (GNU Binutils) 2.31.1
+=>
+===============================================================================
+
+Now you can configure your networking, tftp server and use tftp boot method to
+load uImage.
+
+==========================================================================
+=> setenv ethaddr 70:B3:D5:92:F0:C2
+=> setenv ipaddr 10.196.157.189
+=> setenv serverip 10.11.143.218
+=> setenv gatewayip 10.196.156.1
+=> setenv netmask 255.255.252.0
+=> bdinfo
+boot_params = 0x0000000000000000
+DRAM bank = 0x0000000000000000
+-> start = 0x0000000080000000
+-> size = 0x0000000200000000
+relocaddr = 0x00000000fff90000
+reloc off = 0x000000007fd90000
+ethaddr = 70:B3:D5:92:F0:C2
+IP addr = 10.196.157.189
+baudrate = 115200 bps
+=> tftpboot uImage
+ethernet at 10090000: PHY present at 0
+ethernet at 10090000: Starting autonegotiation...
+ethernet at 10090000: Autonegotiation complete
+ethernet at 10090000: link up, 1000Mbps full-duplex (lpa: 0x3800)
+Using ethernet at 10090000 device
+TFTP from server 10.11.143.218; our IP address is 10.196.157.189; sending through gateway 10.196.156.1
+Filename 'uImage'.
+Load address: 0x80200000
+Loading: #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ #################################################################
+ ##########################################################
+ 2.5 MiB/s
+done
+Bytes transferred = 14939132 (e3f3fc hex)
+=> bootm 0x80200000 - 0x82200000
+## Booting kernel from Legacy Image at 80200000 ...
+ Image Name: Linux
+ Image Type: RISC-V Linux Kernel Image (uncompressed)
+ Data Size: 14939068 Bytes = 14.2 MiB
+ Load Address: 80200000
+ Entry Point: 80200000
+ Verifying Checksum ... OK
+## Flattened Device Tree blob at 82200000
+ Booting using the fdt blob at 0x82200000
+ Loading Kernel Image ... OK
+ Using Device Tree in place at 0000000082200000, end 0000000082205c69
+
+Starting kernel ...
+
+[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
+[ 0.000000] Linux version 5.0.0-rc1-00020-g4b51f736 (atish at jedi-01) (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21 17:39:27 PST 2019
+[ 0.000000] initrd not found or empty - disabling initrd
+[ 0.000000] Zone ranges:
+[ 0.000000] DMA32 [mem 0x0000000080200000-0x00000000ffffffff]
+[ 0.000000] Normal [mem 0x0000000100000000-0x000027ffffffffff]
+[ 0.000000] Movable zone start for each node
+[ 0.000000] Early memory node ranges
+[ 0.000000] node 0: [mem 0x0000000080200000-0x000000027fffffff]
+[ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000027fffffff]
+[ 0.000000] software IO TLB: mapped [mem 0xfbfff000-0xfffff000] (64MB)
+[ 0.000000] CPU with hartid=0 has a non-okay status of "masked"
+[ 0.000000] CPU with hartid=0 has a non-okay status of "masked"
+[ 0.000000] elf_hwcap is 0x112d
+[ 0.000000] percpu: Embedded 15 pages/cpu @(____ptrval____) s29720 r0 d31720 u61440
+[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 2067975
+[ 0.000000] Kernel command line: earlyprintk
+[ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
+[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
+[ 0.000000] Sorting __ex_table...
+[ 0.000000] Memory: 8178760K/8386560K available (3309K kernel code, 248K rwdata, 872K rodata, 9381K init, 763K bss, 207800K reserved, 0K cma-reserved)
+[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+[ 0.000000] rcu: Hierarchical RCU implementation.
+[ 0.000000] rcu: RCU event tracing is enabled.
+[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
+[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
+[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
+[ 0.000000] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
+[ 0.000000] plic: mapped 53 interrupts to 4 (out of 9) handlers.
+[ 0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [1]
+[ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
+[ 0.000008] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
+[ 0.000221] Console: colour dummy device 80x25
+[ 0.000902] printk: console [tty0] enabled
+[ 0.000963] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=10000)
+[ 0.001034] pid_max: default: 32768 minimum: 301
+[ 0.001541] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
+[ 0.001912] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
+[ 0.003542] rcu: Hierarchical SRCU implementation.
+[ 0.004347] smp: Bringing up secondary CPUs ...
+[ 1.040259] CPU1: failed to come online
+[ 2.080483] CPU2: failed to come online
+[ 3.120699] CPU3: failed to come online
+[ 3.120765] smp: Brought up 1 node, 1 CPU
+[ 3.121923] devtmpfs: initialized
+[ 3.124649] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+[ 3.124727] futex hash table entries: 1024 (order: 4, 65536 bytes)
+[ 3.125346] random: get_random_u32 called from bucket_table_alloc+0x72/0x172 with crng_init=0
+[ 3.125578] NET: Registered protocol family 16
+[ 3.126400] sifive-u54-prci 10000000.prci: Registered U54 core clocks
+[ 3.126649] sifive-gemgxl-mgmt 100a0000.cadence-gemgxl-mgmt: Registered clock switch 'cadence-gemgxl-mgmt'
+[ 3.135572] vgaarb: loaded
+[ 3.135858] SCSI subsystem initialized
+[ 3.136193] usbcore: registered new interface driver usbfs
+[ 3.136266] usbcore: registered new interface driver hub
+[ 3.136348] usbcore: registered new device driver usb
+[ 3.136446] pps_core: LinuxPPS API ver. 1 registered
+[ 3.136484] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
+[ 3.136575] PTP clock support registered
+[ 3.137256] clocksource: Switched to clocksource riscv_clocksource
+[ 3.142711] NET: Registered protocol family 2
+[ 3.143322] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes)
+[ 3.143634] TCP established hash table entries: 65536 (order: 7, 524288 bytes)
+[ 3.145799] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
+[ 3.149121] TCP: Hash tables configured (established 65536 bind 65536)
+[ 3.149591] UDP hash table entries: 4096 (order: 5, 131072 bytes)
+[ 3.150094] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
+[ 3.150781] NET: Registered protocol family 1
+[ 3.230693] workingset: timestamp_bits=62 max_order=21 bucket_order=0
+[ 3.241224] io scheduler mq-deadline registered
+[ 3.241269] io scheduler kyber registered
+[ 3.242143] sifive_gpio 10060000.gpio: SiFive GPIO chip registered 16 GPIOs
+[ 3.242357] pwm-sifivem 10020000.pwm: Unable to find controller clock
+[ 3.242439] pwm-sifivem 10021000.pwm: Unable to find controller clock
+[ 3.243228] xilinx-pcie 2000000000.pci: PCIe Link is DOWN
+[ 3.243289] xilinx-pcie 2000000000.pci: host bridge /soc/pci at 2000000000 ranges:
+[ 3.243360] xilinx-pcie 2000000000.pci: No bus range found for /soc/pci at 2000000000, using [bus 00-ff]
+[ 3.243447] xilinx-pcie 2000000000.pci: MEM 0x40000000..0x5fffffff -> 0x40000000
+[ 3.243591] xilinx-pcie 2000000000.pci: PCI host bridge to bus 0000:00
+[ 3.243636] pci_bus 0000:00: root bus resource [bus 00-ff]
+[ 3.243676] pci_bus 0000:00: root bus resource [mem 0x40000000-0x5fffffff]
+[ 3.276547] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+[ 3.277689] 10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 39, base_baud = 0) is a SiFive UART v0
+[ 3.786963] printk: console [ttySIF0] enabled
+[ 3.791504] 10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 40, base_baud = 0) is a SiFive UART v0
+[ 3.801251] sifive_spi 10040000.spi: mapped; irq=41, cs=1
+[ 3.806362] m25p80 spi0.0: unrecognized JEDEC id bytes: 9d, 70, 19
+[ 3.812084] m25p80: probe of spi0.0 failed with error -2
+[ 3.817453] sifive_spi 10041000.spi: mapped; irq=42, cs=4
+[ 3.823027] sifive_spi 10050000.spi: mapped; irq=43, cs=1
+[ 3.828604] libphy: Fixed MDIO Bus: probed
+[ 3.832623] macb: GEM doesn't support hardware ptp.
+[ 3.837196] libphy: MACB_mii_bus: probed
+[ 4.041156] Microsemi VSC8541 SyncE 10090000.ethernet-ffffffff:00: attached PHY driver [Microsemi VSC8541 SyncE] (mii_bus:phy_addr=10090000.ethernet-ffffffff:00, irq=POLL)
+[ 4.055779] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 12 (70:b3:d5:92:f0:c2)
+[ 4.065780] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+[ 4.072033] ehci-pci: EHCI PCI platform driver
+[ 4.076521] usbcore: registered new interface driver usb-storage
+[ 4.082843] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
+[ 4.127465] mmc_spi spi2.0: SD/MMC host mmc0, no DMA, no WP, no poweroff
+[ 4.133645] usbcore: registered new interface driver usbhid
+[ 4.138980] usbhid: USB HID core driver
+[ 4.143017] NET: Registered protocol family 17
+[ 4.147885] pwm-sifivem 10020000.pwm: SiFive PWM chip registered 4 PWMs
+[ 4.153945] pwm-sifivem 10021000.pwm: SiFive PWM chip registered 4 PWMs
+[ 4.186407] Freeing unused kernel memory: 9380K
+[ 4.190224] This architecture does not have kernel memory protection.
+[ 4.196609] Run /init as init process
+Starting logging: OK
+Starting mdev...
+[ 4.303785] mmc0: host does not support reading read-only switch, assuming write-enable
+[ 4.311109] mmc0: new SDHC card on SPI
+[ 4.317103] mmcblk0: mmc0:0000 SS08G 7.40 GiB
+[ 4.386471] mmcblk0: p1 p2
+sort: /sys/devices/platform/Fixed: No such file or directory
+modprobe: can't change directory to '/lib/modules': No such file or directory
+Initializing random[ 4.759075] random: dd: uninitialized urandom read (512 bytes read)
+ number generator... done.
+Starting network...
+udhcpc (v1.24.2) started
+Sending discover...
+Sending discover...
+[ 7.927510] macb 10090000.ethernet eth0: link up (1000/Full)
+Sending discover...
+Sending select for 10.196.157.190...
+Lease of 10.196.157.190 obtained, lease time 499743
+deleting routers
+adding dns 10.86.1.1
+adding dns 10.86.2.1
+/etc/init.d/S50dropbear
+Starting dropbear sshd: [ 12.772393] random: dropbear: uninitialized urandom read (32 bytes read)
+OK
+
+Welcome to Buildroot
+buildroot login:
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540
2019-02-11 5:43 ` [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540 Anup Patel
@ 2019-02-13 0:18 ` Kevin Hilman
2019-02-13 1:31 ` Atish Patra
0 siblings, 1 reply; 51+ messages in thread
From: Kevin Hilman @ 2019-02-13 0:18 UTC (permalink / raw)
To: u-boot
Anup Patel <Anup.Patel@wdc.com> writes:
> From: Atish Patra <atish.patra@wdc.com>
>
> The readme guide describes the procedure to build, flash and boot Linux
> using U-Boot on HiFive Unleashed. It also explains the current state of
> U-boot support and future action items.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Signed-off-by: Anup Patel <anup.patel@wdc.com>
> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
I'm testing this with the mainline kernel (v5.0-rc6) and running into
some problems getting kernel output on the serial console.
[...]
> +=> setenv ethaddr 70:B3:D5:92:F0:C2
> +=> setenv ipaddr 10.196.157.189
> +=> setenv serverip 10.11.143.218
> +=> setenv gatewayip 10.196.156.1
> +=> setenv netmask 255.255.252.0
> +=> bdinfo
> +boot_params = 0x0000000000000000
> +DRAM bank = 0x0000000000000000
> +-> start = 0x0000000080000000
> +-> size = 0x0000000200000000
> +relocaddr = 0x00000000fff90000
> +reloc off = 0x000000007fd90000
> +ethaddr = 70:B3:D5:92:F0:C2
> +IP addr = 10.196.157.189
> +baudrate = 115200 bps
> +=> tftpboot uImage
> +ethernet at 10090000: PHY present at 0
> +ethernet at 10090000: Starting autonegotiation...
> +ethernet at 10090000: Autonegotiation complete
> +ethernet at 10090000: link up, 1000Mbps full-duplex (lpa: 0x3800)
> +Using ethernet at 10090000 device
> +TFTP from server 10.11.143.218; our IP address is 10.196.157.189; sending through gateway 10.196.156.1
> +Filename 'uImage'.
> +Load address: 0x80200000
> +Loading: #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + #################################################################
> + ##########################################################
> + 2.5 MiB/s
> +done
> +Bytes transferred = 14939132 (e3f3fc hex)
> +=> bootm 0x80200000 - 0x82200000
First question: this doc doesn't explain how there is a DT at
0x82200000, and what it contains.
Trying this with a freshly build u-boot payload with OpenSBI, bootm
seems to detect a DT there, but I don't understand how it got there, or
what it is in it.
Looking a little closer, it appears that this DT (and the address) is
hard-coded in the OpenSBI code. This should proably be documented here
for clarity sake.
> +## Booting kernel from Legacy Image at 80200000 ...
> + Image Name: Linux
> + Image Type: RISC-V Linux Kernel Image (uncompressed)
> + Data Size: 14939068 Bytes = 14.2 MiB
> + Load Address: 80200000
> + Entry Point: 80200000
> + Verifying Checksum ... OK
> +## Flattened Device Tree blob at 82200000
> + Booting using the fdt blob at 0x82200000
> + Loading Kernel Image ... OK
> + Using Device Tree in place at 0000000082200000, end 0000000082205c69
> +
> +Starting kernel ...
Next, I'm able to DHCP and TFTP my uImage just like above, but I don't
see any output on the console after the "Starting kernel".
That suggests that whatever DT is present there doesn't have the right
settings for the serial console.
I tried setting the u-boot bootargs to "console=ttySIF0 earlyprintk",
but I'm still seeing nothing on the console.
Dumping the hard-coded OpenSBI DT from u-boot[1], it seem that the
chosen node has the right value (as documented in this patch):
Hmm, maybe I'm missing the obvious... is there even an upstream serial
driver for this UART in v5.0-rc6... (/me goes searching for the
compatible)... hmm, doesn't look like it.
> +[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
> +[ 0.000000] Linux version 5.0.0-rc1-00020-g4b51f736 (atish at jedi-01) (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21 17:39:27 PST 2019
Looks like you're testing with a handful of out-of-tree kernel patches.
Can you give a pointer to where you're building your kernel from?
I'm guessing at a minimum I at least need the serial driver.
Thanks,
Kevin
[1]
=> fdt addr 0x82200000
=> fdt list
/ {
#address-cells = <0x00000002>;
#size-cells = <0x00000002>;
compatible = "sifive,fu540g", "sifive,fu500";
model = "sifive,hifive-unleashed-a00";
aliases {
};
chosen {
};
firmware {
};
cpus {
};
memory at 80000000 {
};
soc {
};
};
=> fdt list /chosen
chosen {
stdout-path = "/soc/serial at 10010000:115200";
};
^ permalink raw reply [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540
2019-02-13 0:18 ` Kevin Hilman
@ 2019-02-13 1:31 ` Atish Patra
2019-02-13 9:52 ` Auer, Lukas
2019-02-13 22:39 ` Kevin Hilman
0 siblings, 2 replies; 51+ messages in thread
From: Atish Patra @ 2019-02-13 1:31 UTC (permalink / raw)
To: u-boot
> On Feb 12, 2019, at 4:18 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>
> Anup Patel <Anup.Patel@wdc.com> writes:
>
>> From: Atish Patra <atish.patra@wdc.com>
>>
>> The readme guide describes the procedure to build, flash and boot Linux
>> using U-Boot on HiFive Unleashed. It also explains the current state of
>> U-boot support and future action items.
>>
>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>> Signed-off-by: Anup Patel <anup.patel@wdc.com>
>> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
>
> I'm testing this with the mainline kernel (v5.0-rc6) and running into
> some problems getting kernel output on the serial console.
>
Unfortunately.
> [...]
>
>> +=> setenv ethaddr 70:B3:D5:92:F0:C2
>> +=> setenv ipaddr 10.196.157.189
>> +=> setenv serverip 10.11.143.218
>> +=> setenv gatewayip 10.196.156.1
>> +=> setenv netmask 255.255.252.0
>> +=> bdinfo
>> +boot_params = 0x0000000000000000
>> +DRAM bank = 0x0000000000000000
>> +-> start = 0x0000000080000000
>> +-> size = 0x0000000200000000
>> +relocaddr = 0x00000000fff90000
>> +reloc off = 0x000000007fd90000
>> +ethaddr = 70:B3:D5:92:F0:C2
>> +IP addr = 10.196.157.189
>> +baudrate = 115200 bps
>> +=> tftpboot uImage
>> +ethernet at 10090000: PHY present at 0
>> +ethernet at 10090000: Starting autonegotiation...
>> +ethernet at 10090000: Autonegotiation complete
>> +ethernet at 10090000: link up, 1000Mbps full-duplex (lpa: 0x3800)
>> +Using ethernet at 10090000 device
>> +TFTP from server 10.11.143.218; our IP address is 10.196.157.189; sending through gateway 10.196.156.1
>> +Filename 'uImage'.
>> +Load address: 0x80200000
>> +Loading: #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + #################################################################
>> + ##########################################################
>> + 2.5 MiB/s
>> +done
>> +Bytes transferred = 14939132 (e3f3fc hex)
>> +=> bootm 0x80200000 - 0x82200000
>
> First question: this doc doesn't explain how there is a DT at
> 0x82200000, and what it contains.
>
DT is being passed from the previous stage boot loader to OpenSBI and OpenSBI passed it to U-Boot
after modifying few entries (hart masks and plic entries).
There is a way to provide custom DT in OpenSBI as well.
> Trying this with a freshly build u-boot payload with OpenSBI, bootm
> seems to detect a DT there, but I don't understand how it got there, or
> what it is in it.
>
> Looking a little closer, it appears that this DT (and the address) is
> hard-coded in the OpenSBI code. This should proably be documented here
> for clarity sake.
>
I will update the document to add more clarity.
>> +## Booting kernel from Legacy Image at 80200000 ...
>> + Image Name: Linux
>> + Image Type: RISC-V Linux Kernel Image (uncompressed)
>> + Data Size: 14939068 Bytes = 14.2 MiB
>> + Load Address: 80200000
>> + Entry Point: 80200000
>> + Verifying Checksum ... OK
>> +## Flattened Device Tree blob at 82200000
>> + Booting using the fdt blob at 0x82200000
>> + Loading Kernel Image ... OK
>> + Using Device Tree in place at 0000000082200000, end 0000000082205c69
>> +
>> +Starting kernel ...
>
> Next, I'm able to DHCP and TFTP my uImage just like above, but I don't
> see any output on the console after the "Starting kernel".
>
> That suggests that whatever DT is present there doesn't have the right
> settings for the serial console.
>
> I tried setting the u-boot bootargs to "console=ttySIF0 earlyprintk",
> but I'm still seeing nothing on the console.
>
> Dumping the hard-coded OpenSBI DT from u-boot[1], it seem that the
> chosen node has the right value (as documented in this patch):
>
> Hmm, maybe I'm missing the obvious... is there even an upstream serial
> driver for this UART in v5.0-rc6... (/me goes searching for the
> compatible)... hmm, doesn't look like it.
>
Unfortunately, all the drivers for unleashed are not upstreamed yet. It is a mess and hopefully it will be resolved soon.
>> +[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>> +[ 0.000000] Linux version 5.0.0-rc1-00020-g4b51f736 (atish at jedi-01) (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21 17:39:27 PST 2019
>
> Looks like you're testing with a handful of out-of-tree kernel patches.
> Can you give a pointer to where you're building your kernel from?
>
Here is my branch based on 5.0-rc5 that should work.
https://github.com/atishp04/linux/ v5.0-rc5_unleashed_uboot
1-8 patches are mostly SMP fixes and currently under review. They should be part of next merge window.
------------------------------------------------------------------------------------------
1. 4a0edc9b RISC-V: Assign hwcap as per comman capabilities.
2. c29e4afa irqchip/irq-sifive-plic: Check and continue in case of an invalid cpuid.
3. 6c191098 clocksource/drivers/riscv: Add required checks during clock source init
4. d89bfcf6 RISC-V: Compare cpuid with NR_CPUS before mapping.
5. 474cb3e3 RISC-V: Allow hartid-to-cpuid function to fail.
6. 5e07a2f4 RISC-V: Remove NR_CPUs check during hartid search from DT
7. cf5f2ec6 RISC-V: Move cpuid to hartid mapping to SMP.
8. 7838fe36 RISC-V: Do not wait indefinitely in __cpu_up
------------------------------------------------------------------------------------------
The real mess is the following driver patches for unleashed board.
9. d46dc16f spi: sifive: no dma hack
10. e8ea1346 spi: add driver for the SiFive SPI controller
11. 120d5658 pcie-microsemi: added support for the Vera-board root complex
12. afb97b09 RISC-V: Networking fix Hack
13. 4ca6e585 pwm-sifive: add a driver for SiFive SoC PWM
14. ddb4b49e gpio-sifive: support GPIO on SiFive SoCs
15. f8859c7d u54-prci: driver for core U54 clocks
16. 27b6fd77 u54-prci: driver for core U54 clocks
17. dcd33855 gemgxl-mgmt: implement clock switch for GEM tx_clk
18. b25bb020 tty: serial: add driver for the SiFive UART
19. fd6f363f dt-bindings: serial: add documentation for the SiFive UART driver
Please make sure following configs are enabled in your config.
CONFIG_SERIAL_SIFIVE=y
CONFIG_SERIAL_SIFIVE_CONSOLE=y
CONFIG_SIFIVE_PLIC=y
CONFIG_SPI=y
CONFIG_SPI_SIFIVE=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SIFIVE=y
CONFIG_PWM_SIFIVE=y
CONFIG_CLK_U54_PRCI=y
CONFIG_CLK_GEMGXL_MGMT=y
I will update the document to mention about the driver patches as well. Sorry for the inconvenience caused.
Regards,
Atish
> I'm guessing at a minimum I at least need the serial driver.
>
> Thanks,
>
> Kevin
>
> [1]
> => fdt addr 0x82200000
> => fdt list
> / {
> #address-cells = <0x00000002>;
> #size-cells = <0x00000002>;
> compatible = "sifive,fu540g", "sifive,fu500";
> model = "sifive,hifive-unleashed-a00";
> aliases {
> };
> chosen {
> };
> firmware {
> };
> cpus {
> };
> memory at 80000000 {
> };
> soc {
> };
> };
> => fdt list /chosen
> chosen {
> stdout-path = "/soc/serial at 10010000:115200";
> };
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540
2019-02-13 1:31 ` Atish Patra
@ 2019-02-13 9:52 ` Auer, Lukas
2019-02-13 19:10 ` Atish Patra
2019-02-13 22:39 ` Kevin Hilman
1 sibling, 1 reply; 51+ messages in thread
From: Auer, Lukas @ 2019-02-13 9:52 UTC (permalink / raw)
To: u-boot
On Wed, 2019-02-13 at 01:31 +0000, Atish Patra wrote:
> > On Feb 12, 2019, at 4:18 PM, Kevin Hilman <khilman@baylibre.com>
> > wrote:
> >
> > Anup Patel <Anup.Patel@wdc.com> writes:
> >
> > > From: Atish Patra <atish.patra@wdc.com>
> > >
> > > The readme guide describes the procedure to build, flash and boot
> > > Linux
> > > using U-Boot on HiFive Unleashed. It also explains the current
> > > state of
> > > U-boot support and future action items.
> > >
> > > Signed-off-by: Atish Patra <atish.patra@wdc.com>
> > > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > > Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
> >
> > I'm testing this with the mainline kernel (v5.0-rc6) and running
> > into
> > some problems getting kernel output on the serial console.
> >
>
> Unfortunately.
>
> > [...]
> >
> > > +=> setenv ethaddr 70:B3:D5:92:F0:C2
> > > +=> setenv ipaddr 10.196.157.189
> > > +=> setenv serverip 10.11.143.218
> > > +=> setenv gatewayip 10.196.156.1
> > > +=> setenv netmask 255.255.252.0
> > > +=> bdinfo
> > > +boot_params = 0x0000000000000000
> > > +DRAM bank = 0x0000000000000000
> > > +-> start = 0x0000000080000000
> > > +-> size = 0x0000000200000000
> > > +relocaddr = 0x00000000fff90000
> > > +reloc off = 0x000000007fd90000
> > > +ethaddr = 70:B3:D5:92:F0:C2
> > > +IP addr = 10.196.157.189
> > > +baudrate = 115200 bps
> > > +=> tftpboot uImage
> > > +ethernet at 10090000: PHY present at 0
> > > +ethernet at 10090000: Starting autonegotiation...
> > > +ethernet at 10090000: Autonegotiation complete
> > > +ethernet at 10090000: link up, 1000Mbps full-duplex (lpa: 0x3800)
> > > +Using ethernet at 10090000 device
> > > +TFTP from server 10.11.143.218; our IP address is
> > > 10.196.157.189; sending through gateway 10.196.156.1
> > > +Filename 'uImage'.
> > > +Load address: 0x80200000
> > > +Loading:
> > > #################################################################
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ##########
> > > + #######################################################
> > > ###
> > > + 2.5 MiB/s
> > > +done
> > > +Bytes transferred = 14939132 (e3f3fc hex)
> > > +=> bootm 0x80200000 - 0x82200000
> >
> > First question: this doc doesn't explain how there is a DT at
> > 0x82200000, and what it contains.
> >
>
> DT is being passed from the previous stage boot loader to OpenSBI and
> OpenSBI passed it to U-Boot
> after modifying few entries (hart masks and plic entries).
>
> There is a way to provide custom DT in OpenSBI as well.
FYI, you can also use the fdtcontroladdr environment variable to pass
U-Boot's device tree, so the one passed by OpenSBI, to Linux.
Thanks,
Lukas
>
> > Trying this with a freshly build u-boot payload with OpenSBI, bootm
> > seems to detect a DT there, but I don't understand how it got
> > there, or
> > what it is in it.
> >
> > Looking a little closer, it appears that this DT (and the address)
> > is
> > hard-coded in the OpenSBI code. This should proably be documented
> > here
> > for clarity sake.
> >
>
> I will update the document to add more clarity.
>
> > > +## Booting kernel from Legacy Image at 80200000 ...
> > > + Image Name: Linux
> > > + Image Type: RISC-V Linux Kernel Image (uncompressed)
> > > + Data Size: 14939068 Bytes = 14.2 MiB
> > > + Load Address: 80200000
> > > + Entry Point: 80200000
> > > + Verifying Checksum ... OK
> > > +## Flattened Device Tree blob at 82200000
> > > + Booting using the fdt blob at 0x82200000
> > > + Loading Kernel Image ... OK
> > > + Using Device Tree in place at 0000000082200000, end
> > > 0000000082205c69
> > > +
> > > +Starting kernel ...
> >
> > Next, I'm able to DHCP and TFTP my uImage just like above, but I
> > don't
> > see any output on the console after the "Starting kernel".
> >
> > That suggests that whatever DT is present there doesn't have the
> > right
> > settings for the serial console.
> >
> > I tried setting the u-boot bootargs to "console=ttySIF0
> > earlyprintk",
> > but I'm still seeing nothing on the console.
> >
> > Dumping the hard-coded OpenSBI DT from u-boot[1], it seem that the
> > chosen node has the right value (as documented in this patch):
> >
> > Hmm, maybe I'm missing the obvious... is there even an upstream
> > serial
> > driver for this UART in v5.0-rc6... (/me goes searching for the
> > compatible)... hmm, doesn't look like it.
> >
>
> Unfortunately, all the drivers for unleashed are not upstreamed yet.
> It is a mess and hopefully it will be resolved soon.
>
> > > +[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
> > > 0x80200000
> > > +[ 0.000000] Linux version 5.0.0-rc1-00020-g4b51f736 (
> > > atish at jedi-01) (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21
> > > 17:39:27 PST 2019
> >
> > Looks like you're testing with a handful of out-of-tree kernel
> > patches.
> > Can you give a pointer to where you're building your kernel from?
> >
>
> Here is my branch based on 5.0-rc5 that should work.
>
> https://github.com/atishp04/linux/ v5.0-rc5_unleashed_uboot
>
> 1-8 patches are mostly SMP fixes and currently under review. They
> should be part of next merge window.
> -------------------------------------------------------------------
> -----------------------
> 1. 4a0edc9b RISC-V: Assign hwcap as per comman capabilities.
> 2. c29e4afa irqchip/irq-sifive-plic: Check and continue in case of an
> invalid cpuid.
> 3. 6c191098 clocksource/drivers/riscv: Add required checks during
> clock source init
> 4. d89bfcf6 RISC-V: Compare cpuid with NR_CPUS before mapping.
> 5. 474cb3e3 RISC-V: Allow hartid-to-cpuid function to fail.
> 6. 5e07a2f4 RISC-V: Remove NR_CPUs check during hartid search from DT
> 7. cf5f2ec6 RISC-V: Move cpuid to hartid mapping to SMP.
> 8. 7838fe36 RISC-V: Do not wait indefinitely in __cpu_up
> -------------------------------------------------------------------
> -----------------------
>
> The real mess is the following driver patches for unleashed board.
>
> 9. d46dc16f spi: sifive: no dma hack
> 10. e8ea1346 spi: add driver for the SiFive SPI controller
> 11. 120d5658 pcie-microsemi: added support for the Vera-board root
> complex
> 12. afb97b09 RISC-V: Networking fix Hack
> 13. 4ca6e585 pwm-sifive: add a driver for SiFive SoC PWM
> 14. ddb4b49e gpio-sifive: support GPIO on SiFive SoCs
> 15. f8859c7d u54-prci: driver for core U54 clocks
> 16. 27b6fd77 u54-prci: driver for core U54 clocks
> 17. dcd33855 gemgxl-mgmt: implement clock switch for GEM tx_clk
> 18. b25bb020 tty: serial: add driver for the SiFive UART
> 19. fd6f363f dt-bindings: serial: add documentation for the SiFive
> UART driver
>
> Please make sure following configs are enabled in your config.
>
> CONFIG_SERIAL_SIFIVE=y
> CONFIG_SERIAL_SIFIVE_CONSOLE=y
> CONFIG_SIFIVE_PLIC=y
> CONFIG_SPI=y
> CONFIG_SPI_SIFIVE=y
> CONFIG_GPIOLIB=y
> CONFIG_GPIO_SIFIVE=y
> CONFIG_PWM_SIFIVE=y
> CONFIG_CLK_U54_PRCI=y
> CONFIG_CLK_GEMGXL_MGMT=y
>
> I will update the document to mention about the driver patches as
> well. Sorry for the inconvenience caused.
>
> Regards,
> Atish
> > I'm guessing at a minimum I at least need the serial driver.
> >
> > Thanks,
> >
> > Kevin
> >
> > [1]
> > => fdt addr 0x82200000
> > => fdt list
> > / {
> > #address-cells = <0x00000002>;
> > #size-cells = <0x00000002>;
> > compatible = "sifive,fu540g", "sifive,fu500";
> > model = "sifive,hifive-unleashed-a00";
> > aliases {
> > };
> > chosen {
> > };
> > firmware {
> > };
> > cpus {
> > };
> > memory at 80000000 {
> > };
> > soc {
> > };
> > };
> > => fdt list /chosen
> > chosen {
> > stdout-path = "/soc/serial at 10010000:115200";
> > };
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540
2019-02-13 9:52 ` Auer, Lukas
@ 2019-02-13 19:10 ` Atish Patra
0 siblings, 0 replies; 51+ messages in thread
From: Atish Patra @ 2019-02-13 19:10 UTC (permalink / raw)
To: u-boot
On 2/13/19 1:52 AM, Auer, Lukas wrote:
> On Wed, 2019-02-13 at 01:31 +0000, Atish Patra wrote:
>>> On Feb 12, 2019, at 4:18 PM, Kevin Hilman <khilman@baylibre.com>
>>> wrote:
>>>
>>> Anup Patel <Anup.Patel@wdc.com> writes:
>>>
>>>> From: Atish Patra <atish.patra@wdc.com>
>>>>
>>>> The readme guide describes the procedure to build, flash and boot
>>>> Linux
>>>> using U-Boot on HiFive Unleashed. It also explains the current
>>>> state of
>>>> U-boot support and future action items.
>>>>
>>>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>>>> Signed-off-by: Anup Patel <anup.patel@wdc.com>
>>>> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
>>>
>>> I'm testing this with the mainline kernel (v5.0-rc6) and running
>>> into
>>> some problems getting kernel output on the serial console.
>>>
>>
>> Unfortunately.
>>
>>> [...]
>>>
>>>> +=> setenv ethaddr 70:B3:D5:92:F0:C2
>>>> +=> setenv ipaddr 10.196.157.189
>>>> +=> setenv serverip 10.11.143.218
>>>> +=> setenv gatewayip 10.196.156.1
>>>> +=> setenv netmask 255.255.252.0
>>>> +=> bdinfo
>>>> +boot_params = 0x0000000000000000
>>>> +DRAM bank = 0x0000000000000000
>>>> +-> start = 0x0000000080000000
>>>> +-> size = 0x0000000200000000
>>>> +relocaddr = 0x00000000fff90000
>>>> +reloc off = 0x000000007fd90000
>>>> +ethaddr = 70:B3:D5:92:F0:C2
>>>> +IP addr = 10.196.157.189
>>>> +baudrate = 115200 bps
>>>> +=> tftpboot uImage
>>>> +ethernet at 10090000: PHY present at 0
>>>> +ethernet at 10090000: Starting autonegotiation...
>>>> +ethernet at 10090000: Autonegotiation complete
>>>> +ethernet at 10090000: link up, 1000Mbps full-duplex (lpa: 0x3800)
>>>> +Using ethernet at 10090000 device
>>>> +TFTP from server 10.11.143.218; our IP address is
>>>> 10.196.157.189; sending through gateway 10.196.156.1
>>>> +Filename 'uImage'.
>>>> +Load address: 0x80200000
>>>> +Loading:
>>>> #################################################################
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ##########
>>>> + #######################################################
>>>> ###
>>>> + 2.5 MiB/s
>>>> +done
>>>> +Bytes transferred = 14939132 (e3f3fc hex)
>>>> +=> bootm 0x80200000 - 0x82200000
>>>
>>> First question: this doc doesn't explain how there is a DT at
>>> 0x82200000, and what it contains.
>>>
>>
>> DT is being passed from the previous stage boot loader to OpenSBI and
>> OpenSBI passed it to U-Boot
>> after modifying few entries (hart masks and plic entries).
>>
>> There is a way to provide custom DT in OpenSBI as well.
>
> FYI, you can also use the fdtcontroladdr environment variable to pass
> U-Boot's device tree, so the one passed by OpenSBI, to Linux.
>
> Thanks,
> Lukas
>
>>
>>> Trying this with a freshly build u-boot payload with OpenSBI, bootm
>>> seems to detect a DT there, but I don't understand how it got
>>> there, or
>>> what it is in it.
>>>
>>> Looking a little closer, it appears that this DT (and the address)
>>> is
>>> hard-coded in the OpenSBI code. This should proably be documented
>>> here
>>> for clarity sake.
>>>
>>
>> I will update the document to add more clarity.
>>
>>>> +## Booting kernel from Legacy Image at 80200000 ...
>>>> + Image Name: Linux
>>>> + Image Type: RISC-V Linux Kernel Image (uncompressed)
>>>> + Data Size: 14939068 Bytes = 14.2 MiB
>>>> + Load Address: 80200000
>>>> + Entry Point: 80200000
>>>> + Verifying Checksum ... OK
>>>> +## Flattened Device Tree blob at 82200000
>>>> + Booting using the fdt blob at 0x82200000
>>>> + Loading Kernel Image ... OK
>>>> + Using Device Tree in place at 0000000082200000, end
>>>> 0000000082205c69
>>>> +
>>>> +Starting kernel ...
>>>
>>> Next, I'm able to DHCP and TFTP my uImage just like above, but I
>>> don't
>>> see any output on the console after the "Starting kernel".
>>>
>>> That suggests that whatever DT is present there doesn't have the
>>> right
>>> settings for the serial console.
>>>
>>> I tried setting the u-boot bootargs to "console=ttySIF0
>>> earlyprintk",
>>> but I'm still seeing nothing on the console.
>>>
FYI: earlyprintk is disabled in v5.0rc5 in favor of earlycon.
so you need to use
CONFIG_CMDLINE="earlycon=sbi console=ttySIF0"
Regards,
Atish
>>> Dumping the hard-coded OpenSBI DT from u-boot[1], it seem that the
>>> chosen node has the right value (as documented in this patch):
>>>
>>> Hmm, maybe I'm missing the obvious... is there even an upstream
>>> serial
>>> driver for this UART in v5.0-rc6... (/me goes searching for the
>>> compatible)... hmm, doesn't look like it.
>>>
>>
>> Unfortunately, all the drivers for unleashed are not upstreamed yet.
>> It is a mess and hopefully it will be resolved soon.
>>
>>>> +[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 -
>>>> 0x80200000
>>>> +[ 0.000000] Linux version 5.0.0-rc1-00020-g4b51f736 (
>>>> atish at jedi-01) (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21
>>>> 17:39:27 PST 2019
>>>
>>> Looks like you're testing with a handful of out-of-tree kernel
>>> patches.
>>> Can you give a pointer to where you're building your kernel from?
>>>
>>
>> Here is my branch based on 5.0-rc5 that should work.
>>
>> https://github.com/atishp04/linux/ v5.0-rc5_unleashed_uboot
>>
>> 1-8 patches are mostly SMP fixes and currently under review. They
>> should be part of next merge window.
>> -------------------------------------------------------------------
>> -----------------------
>> 1. 4a0edc9b RISC-V: Assign hwcap as per comman capabilities.
>> 2. c29e4afa irqchip/irq-sifive-plic: Check and continue in case of an
>> invalid cpuid.
>> 3. 6c191098 clocksource/drivers/riscv: Add required checks during
>> clock source init
>> 4. d89bfcf6 RISC-V: Compare cpuid with NR_CPUS before mapping.
>> 5. 474cb3e3 RISC-V: Allow hartid-to-cpuid function to fail.
>> 6. 5e07a2f4 RISC-V: Remove NR_CPUs check during hartid search from DT
>> 7. cf5f2ec6 RISC-V: Move cpuid to hartid mapping to SMP.
>> 8. 7838fe36 RISC-V: Do not wait indefinitely in __cpu_up
>> -------------------------------------------------------------------
>> -----------------------
>>
>> The real mess is the following driver patches for unleashed board.
>>
>> 9. d46dc16f spi: sifive: no dma hack
>> 10. e8ea1346 spi: add driver for the SiFive SPI controller
>> 11. 120d5658 pcie-microsemi: added support for the Vera-board root
>> complex
>> 12. afb97b09 RISC-V: Networking fix Hack
>> 13. 4ca6e585 pwm-sifive: add a driver for SiFive SoC PWM
>> 14. ddb4b49e gpio-sifive: support GPIO on SiFive SoCs
>> 15. f8859c7d u54-prci: driver for core U54 clocks
>> 16. 27b6fd77 u54-prci: driver for core U54 clocks
>> 17. dcd33855 gemgxl-mgmt: implement clock switch for GEM tx_clk
>> 18. b25bb020 tty: serial: add driver for the SiFive UART
>> 19. fd6f363f dt-bindings: serial: add documentation for the SiFive
>> UART driver
>>
>> Please make sure following configs are enabled in your config.
>>
>> CONFIG_SERIAL_SIFIVE=y
>> CONFIG_SERIAL_SIFIVE_CONSOLE=y
>> CONFIG_SIFIVE_PLIC=y
>> CONFIG_SPI=y
>> CONFIG_SPI_SIFIVE=y
>> CONFIG_GPIOLIB=y
>> CONFIG_GPIO_SIFIVE=y
>> CONFIG_PWM_SIFIVE=y
>> CONFIG_CLK_U54_PRCI=y
>> CONFIG_CLK_GEMGXL_MGMT=y
>>
>> I will update the document to mention about the driver patches as
>> well. Sorry for the inconvenience caused.
>>
>> Regards,
>> Atish
>>> I'm guessing at a minimum I at least need the serial driver.
>>>
>>> Thanks,
>>>
>>> Kevin
>>>
>>> [1]
>>> => fdt addr 0x82200000
>>> => fdt list
>>> / {
>>> #address-cells = <0x00000002>;
>>> #size-cells = <0x00000002>;
>>> compatible = "sifive,fu540g", "sifive,fu500";
>>> model = "sifive,hifive-unleashed-a00";
>>> aliases {
>>> };
>>> chosen {
>>> };
>>> firmware {
>>> };
>>> cpus {
>>> };
>>> memory at 80000000 {
>>> };
>>> soc {
>>> };
>>> };
>>> => fdt list /chosen
>>> chosen {
>>> stdout-path = "/soc/serial at 10010000:115200";
>>> };
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540
2019-02-13 1:31 ` Atish Patra
2019-02-13 9:52 ` Auer, Lukas
@ 2019-02-13 22:39 ` Kevin Hilman
1 sibling, 0 replies; 51+ messages in thread
From: Kevin Hilman @ 2019-02-13 22:39 UTC (permalink / raw)
To: u-boot
Atish Patra <Atish.Patra@wdc.com> writes:
>> On Feb 12, 2019, at 4:18 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Anup Patel <Anup.Patel@wdc.com> writes:
>>
>>> From: Atish Patra <atish.patra@wdc.com>
>>>
>>> The readme guide describes the procedure to build, flash and boot Linux
>>> using U-Boot on HiFive Unleashed. It also explains the current state of
>>> U-boot support and future action items.
>>>
>>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>>> Signed-off-by: Anup Patel <anup.patel@wdc.com>
>>> Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
>>
>> I'm testing this with the mainline kernel (v5.0-rc6) and running into
>> some problems getting kernel output on the serial console.
>>
>
> Unfortunately.
>
[...]
>> First question: this doc doesn't explain how there is a DT at
>> 0x82200000, and what it contains.
>>
>
> DT is being passed from the previous stage boot loader to OpenSBI and OpenSBI passed it to U-Boot
> after modifying few entries (hart masks and plic entries).
>
> There is a way to provide custom DT in OpenSBI as well.
And if u-boot were load (or TFTP) a custom DT, this should work too,
right?
>> Trying this with a freshly build u-boot payload with OpenSBI, bootm
>> seems to detect a DT there, but I don't understand how it got there, or
>> what it is in it.
>>
>> Looking a little closer, it appears that this DT (and the address) is
>> hard-coded in the OpenSBI code. This should proably be documented here
>> for clarity sake.
>>
>
> I will update the document to add more clarity.
Thanks.
>>> +## Booting kernel from Legacy Image at 80200000 ...
>>> + Image Name: Linux
>>> + Image Type: RISC-V Linux Kernel Image (uncompressed)
>>> + Data Size: 14939068 Bytes = 14.2 MiB
>>> + Load Address: 80200000
>>> + Entry Point: 80200000
>>> + Verifying Checksum ... OK
>>> +## Flattened Device Tree blob at 82200000
>>> + Booting using the fdt blob at 0x82200000
>>> + Loading Kernel Image ... OK
>>> + Using Device Tree in place at 0000000082200000, end 0000000082205c69
>>> +
>>> +Starting kernel ...
>>
>> Next, I'm able to DHCP and TFTP my uImage just like above, but I don't
>> see any output on the console after the "Starting kernel".
>>
>> That suggests that whatever DT is present there doesn't have the right
>> settings for the serial console.
>>
>> I tried setting the u-boot bootargs to "console=ttySIF0 earlyprintk",
>> but I'm still seeing nothing on the console.
>>
>> Dumping the hard-coded OpenSBI DT from u-boot[1], it seem that the
>> chosen node has the right value (as documented in this patch):
>>
>> Hmm, maybe I'm missing the obvious... is there even an upstream serial
>> driver for this UART in v5.0-rc6... (/me goes searching for the
>> compatible)... hmm, doesn't look like it.
>>
>
> Unfortunately, all the drivers for unleashed are not upstreamed yet. It is a mess and hopefully it will be resolved soon.
>
>>> +[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
>>> +[ 0.000000] Linux version 5.0.0-rc1-00020-g4b51f736 (atish at jedi-01) (gcc version 7.2.0 (GCC)) #262 SMP Mon Jan 21 17:39:27 PST 2019
>>
>> Looks like you're testing with a handful of out-of-tree kernel patches.
>> Can you give a pointer to where you're building your kernel from?
>>
>
> Here is my branch based on 5.0-rc5 that should work.
Yes, building a kernel from there, using the config options you
mentioned works. Thanks.
> https://github.com/atishp04/linux/ v5.0-rc5_unleashed_uboot
>
> 1-8 patches are mostly SMP fixes and currently under review. They should be part of next merge window.
> ------------------------------------------------------------------------------------------
> 1. 4a0edc9b RISC-V: Assign hwcap as per comman capabilities.
> 2. c29e4afa irqchip/irq-sifive-plic: Check and continue in case of an invalid cpuid.
> 3. 6c191098 clocksource/drivers/riscv: Add required checks during clock source init
> 4. d89bfcf6 RISC-V: Compare cpuid with NR_CPUS before mapping.
> 5. 474cb3e3 RISC-V: Allow hartid-to-cpuid function to fail.
> 6. 5e07a2f4 RISC-V: Remove NR_CPUs check during hartid search from DT
> 7. cf5f2ec6 RISC-V: Move cpuid to hartid mapping to SMP.
> 8. 7838fe36 RISC-V: Do not wait indefinitely in __cpu_up
> ------------------------------------------------------------------------------------------
>
> The real mess is the following driver patches for unleashed board.
>
> 9. d46dc16f spi: sifive: no dma hack
> 10. e8ea1346 spi: add driver for the SiFive SPI controller
> 11. 120d5658 pcie-microsemi: added support for the Vera-board root complex
> 12. afb97b09 RISC-V: Networking fix Hack
> 13. 4ca6e585 pwm-sifive: add a driver for SiFive SoC PWM
> 14. ddb4b49e gpio-sifive: support GPIO on SiFive SoCs
> 15. f8859c7d u54-prci: driver for core U54 clocks
> 16. 27b6fd77 u54-prci: driver for core U54 clocks
> 17. dcd33855 gemgxl-mgmt: implement clock switch for GEM tx_clk
> 18. b25bb020 tty: serial: add driver for the SiFive UART
> 19. fd6f363f dt-bindings: serial: add documentation for the SiFive UART driver
>
> Please make sure following configs are enabled in your config.
>
> CONFIG_SERIAL_SIFIVE=y
> CONFIG_SERIAL_SIFIVE_CONSOLE=y
> CONFIG_SIFIVE_PLIC=y
> CONFIG_SPI=y
> CONFIG_SPI_SIFIVE=y
> CONFIG_GPIOLIB=y
> CONFIG_GPIO_SIFIVE=y
> CONFIG_PWM_SIFIVE=y
> CONFIG_CLK_U54_PRCI=y
> CONFIG_CLK_GEMGXL_MGMT=y
>
> I will update the document to mention about the driver patches as well. Sorry for the inconvenience caused.
Probably should mention the kernel config requirements too, if they are
not the defaults in upstream.
Kevin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 15/15] riscv: Enable CONFIG_SYS_BOOT_RAMDISK_HIGH for using initrd
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (13 preceding siblings ...)
2019-02-11 5:43 ` [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540 Anup Patel
@ 2019-02-11 5:43 ` Anup Patel
2019-02-11 15:37 ` [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Andreas Schwab
2019-02-13 23:44 ` Kevin Hilman
16 siblings, 0 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-11 5:43 UTC (permalink / raw)
To: u-boot
This patch enables CONFIG_SYS_BOOT_RAMDISK_HIGH for RISC-V
because bootm will update initrd location in DTB only if
CONFIG_SYS_BOOT_RAMDISK_HIGH is enabled. If we don't enable
this option then bootm assumes DTB already has initrd details
which is not the case most of the time.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
---
arch/riscv/include/asm/config.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/include/asm/config.h b/arch/riscv/include/asm/config.h
index 81bc975d2e..156cb94dc0 100644
--- a/arch/riscv/include/asm/config.h
+++ b/arch/riscv/include/asm/config.h
@@ -8,5 +8,6 @@
#define _ASM_CONFIG_H_
#define CONFIG_LMB
+#define CONFIG_SYS_BOOT_RAMDISK_HIGH
#endif
--
2.17.1
^ permalink raw reply related [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (14 preceding siblings ...)
2019-02-11 5:43 ` [U-Boot] [PATCH v7 15/15] riscv: Enable CONFIG_SYS_BOOT_RAMDISK_HIGH for using initrd Anup Patel
@ 2019-02-11 15:37 ` Andreas Schwab
2019-02-12 2:57 ` Anup Patel
2019-02-13 23:44 ` Kevin Hilman
16 siblings, 1 reply; 51+ messages in thread
From: Andreas Schwab @ 2019-02-11 15:37 UTC (permalink / raw)
To: u-boot
On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
> This patchset adds SiFive Freedom Unleashed (FU540) support
> to RISC-V U-Boot.
>
> The patches are based upon latest U-Boot source tree
> (git://git.denx.de/u-boot.git) at commit id
> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>
> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> MACB Ethernet work fine on actual SiFive Unleashed board and
> QEMU sifive_u machine.
Looks like the MACB driver cannot find the correct MAC address. That
makes it rather awkward for network boot.
Warning: ethernet at 10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4
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."
^ permalink raw reply [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-11 15:37 ` [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Andreas Schwab
@ 2019-02-12 2:57 ` Anup Patel
2019-02-12 6:22 ` Alexander Graf
2019-02-12 8:34 ` Andreas Schwab
0 siblings, 2 replies; 51+ messages in thread
From: Anup Patel @ 2019-02-12 2:57 UTC (permalink / raw)
To: u-boot
On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
>
> > This patchset adds SiFive Freedom Unleashed (FU540) support
> > to RISC-V U-Boot.
> >
> > The patches are based upon latest U-Boot source tree
> > (git://git.denx.de/u-boot.git) at commit id
> > dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >
> > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> > MACB Ethernet work fine on actual SiFive Unleashed board and
> > QEMU sifive_u machine.
>
> Looks like the MACB driver cannot find the correct MAC address. That
> makes it rather awkward for network boot.
>
> Warning: ethernet at 10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4
This is because we don't have place to put U-Boot environment
variables as of now on Unleashed board. This will be solved once
we have SPI driver and SPI_MMC driver for Unleased board.
In future, we will be saving "ethaddr" environment variable on
SPI_MMC so U-Boot will pick MAC address at boot-time from
SPI_MMC. Once this is achieved, the above warning will go away.
Regards,
Anup
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 2:57 ` Anup Patel
@ 2019-02-12 6:22 ` Alexander Graf
2019-02-12 6:35 ` Anup Patel
2019-02-12 8:34 ` Andreas Schwab
1 sibling, 1 reply; 51+ messages in thread
From: Alexander Graf @ 2019-02-12 6:22 UTC (permalink / raw)
To: u-boot
> Am 12.02.2019 um 03:57 schrieb Anup Patel <anup@brainfault.org>:
>
>> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote:
>>
>>> On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
>>>
>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>> to RISC-V U-Boot.
>>>
>>> The patches are based upon latest U-Boot source tree
>>> (git://git.denx.de/u-boot.git) at commit id
>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>
>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>> QEMU sifive_u machine.
>>
>> Looks like the MACB driver cannot find the correct MAC address. That
>> makes it rather awkward for network boot.
>>
>> Warning: ethernet at 10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4
>
> This is because we don't have place to put U-Boot environment
> variables as of now on Unleashed board. This will be solved once
> we have SPI driver and SPI_MMC driver for Unleased board.
>
> In future, we will be saving "ethaddr" environment variable on
> SPI_MMC so U-Boot will pick MAC address at boot-time from
> SPI_MMC. Once this is achieved, the above warning will go away.
How is the MAC determined in Linux?
Alex
>
> Regards,
> Anup
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 6:22 ` Alexander Graf
@ 2019-02-12 6:35 ` Anup Patel
2019-02-12 7:00 ` Alexander Graf
0 siblings, 1 reply; 51+ messages in thread
From: Anup Patel @ 2019-02-12 6:35 UTC (permalink / raw)
To: u-boot
On Tue, Feb 12, 2019 at 11:52 AM Alexander Graf <agraf@suse.de> wrote:
>
>
>
> > Am 12.02.2019 um 03:57 schrieb Anup Patel <anup@brainfault.org>:
> >
> >> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote:
> >>
> >>> On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
> >>>
> >>> This patchset adds SiFive Freedom Unleashed (FU540) support
> >>> to RISC-V U-Boot.
> >>>
> >>> The patches are based upon latest U-Boot source tree
> >>> (git://git.denx.de/u-boot.git) at commit id
> >>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >>>
> >>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >>> MACB Ethernet work fine on actual SiFive Unleashed board and
> >>> QEMU sifive_u machine.
> >>
> >> Looks like the MACB driver cannot find the correct MAC address. That
> >> makes it rather awkward for network boot.
> >>
> >> Warning: ethernet at 10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4
> >
> > This is because we don't have place to put U-Boot environment
> > variables as of now on Unleashed board. This will be solved once
> > we have SPI driver and SPI_MMC driver for Unleased board.
> >
> > In future, we will be saving "ethaddr" environment variable on
> > SPI_MMC so U-Boot will pick MAC address at boot-time from
> > SPI_MMC. Once this is achieved, the above warning will go away.
>
> How is the MAC determined in Linux?
In Linux, we have an "local-mac-address" DT property used by
quite a few drivers (including Cadence Ethernet driver) but it's not
uniform across Linux drivers.
In U-Boot, another option is to change the Candence MACB driver and
set "ethaddr" environment variable based on "local-mac-address" DT
property from driver probe. Suggestions ??
Regards,
Anup
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 6:35 ` Anup Patel
@ 2019-02-12 7:00 ` Alexander Graf
0 siblings, 0 replies; 51+ messages in thread
From: Alexander Graf @ 2019-02-12 7:00 UTC (permalink / raw)
To: u-boot
> Am 12.02.2019 um 07:35 schrieb Anup Patel <anup@brainfault.org>:
>
>> On Tue, Feb 12, 2019 at 11:52 AM Alexander Graf <agraf@suse.de> wrote:
>>
>>
>>
>>>> Am 12.02.2019 um 03:57 schrieb Anup Patel <anup@brainfault.org>:
>>>>
>>>>> On Mon, Feb 11, 2019 at 9:07 PM Andreas Schwab <schwab@suse.de> wrote:
>>>>>
>>>>> On Feb 11 2019, Anup Patel <Anup.Patel@wdc.com> wrote:
>>>>>
>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>> to RISC-V U-Boot.
>>>>>
>>>>> The patches are based upon latest U-Boot source tree
>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>
>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>> QEMU sifive_u machine.
>>>>
>>>> Looks like the MACB driver cannot find the correct MAC address. That
>>>> makes it rather awkward for network boot.
>>>>
>>>> Warning: ethernet at 10090000 (eth0) using random MAC address - 0e:14:15:06:ae:e4
>>>
>>> This is because we don't have place to put U-Boot environment
>>> variables as of now on Unleashed board. This will be solved once
>>> we have SPI driver and SPI_MMC driver for Unleased board.
>>>
>>> In future, we will be saving "ethaddr" environment variable on
>>> SPI_MMC so U-Boot will pick MAC address at boot-time from
>>> SPI_MMC. Once this is achieved, the above warning will go away.
>>
>> How is the MAC determined in Linux?
>
> In Linux, we have an "local-mac-address" DT property used by
> quite a few drivers (including Cadence Ethernet driver) but it's not
> uniform across Linux drivers.
>
> In U-Boot, another option is to change the Candence MACB driver and
> set "ethaddr" environment variable based on "local-mac-address" DT
> property from driver probe. Suggestions ??
That would be my quick fix suggestion, yes :). Or do it in the board file.
Alex
>
> Regards,
> Anup
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 2:57 ` Anup Patel
2019-02-12 6:22 ` Alexander Graf
@ 2019-02-12 8:34 ` Andreas Schwab
2019-02-12 8:35 ` Bin Meng
1 sibling, 1 reply; 51+ messages in thread
From: Andreas Schwab @ 2019-02-12 8:34 UTC (permalink / raw)
To: u-boot
On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote:
> This is because we don't have place to put U-Boot environment
> variables as of now on Unleashed board. This will be solved once
> we have SPI driver and SPI_MMC driver for Unleased board.
Isn't the MAC part of the initial DT?
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."
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 8:34 ` Andreas Schwab
@ 2019-02-12 8:35 ` Bin Meng
2019-02-12 9:09 ` Andreas Schwab
0 siblings, 1 reply; 51+ messages in thread
From: Bin Meng @ 2019-02-12 8:35 UTC (permalink / raw)
To: u-boot
On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote:
>
> > This is because we don't have place to put U-Boot environment
> > variables as of now on Unleashed board. This will be solved once
> > we have SPI driver and SPI_MMC driver for Unleased board.
>
> Isn't the MAC part of the initial DT?
>
My understanding is that U-Boot should fixup the DT using the
<ethaddr> environment value, before jumping to Linux.
Regards,
Bin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 8:35 ` Bin Meng
@ 2019-02-12 9:09 ` Andreas Schwab
2019-02-12 10:12 ` Bin Meng
0 siblings, 1 reply; 51+ messages in thread
From: Andreas Schwab @ 2019-02-12 9:09 UTC (permalink / raw)
To: u-boot
On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote:
>>
>> On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote:
>>
>> > This is because we don't have place to put U-Boot environment
>> > variables as of now on Unleashed board. This will be solved once
>> > we have SPI driver and SPI_MMC driver for Unleased board.
>>
>> Isn't the MAC part of the initial DT?
>>
>
> My understanding is that U-Boot should fixup the DT using the
> <ethaddr> environment value, before jumping to Linux.
But where does it get the env var from? Why would it need to modify the
MAC?
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."
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 9:09 ` Andreas Schwab
@ 2019-02-12 10:12 ` Bin Meng
2019-02-12 10:16 ` Alexander Graf
2019-02-12 10:22 ` Andreas Schwab
0 siblings, 2 replies; 51+ messages in thread
From: Bin Meng @ 2019-02-12 10:12 UTC (permalink / raw)
To: u-boot
On Tue, Feb 12, 2019 at 5:09 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote:
> >>
> >> On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote:
> >>
> >> > This is because we don't have place to put U-Boot environment
> >> > variables as of now on Unleashed board. This will be solved once
> >> > we have SPI driver and SPI_MMC driver for Unleased board.
> >>
> >> Isn't the MAC part of the initial DT?
> >>
> >
> > My understanding is that U-Boot should fixup the DT using the
> > <ethaddr> environment value, before jumping to Linux.
>
> But where does it get the env var from? Why would it need to modify the
> MAC?
>
The env var is stored in whatever supported media in U-Boot. Not like
PCI NICs which normally have EEPROM to store pre-flashed MAC address
by their vendors, for most embedded network controllers in the SoC,
normally there is no hardware provided mechanism to ensure a unique
MAC address, instead it relies on software to program one to the
hardware before bringing it up. In the U-Boot case, it's the <ethaddr>
env.
Regards,
Bin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 10:12 ` Bin Meng
@ 2019-02-12 10:16 ` Alexander Graf
2019-02-12 10:22 ` Andreas Schwab
1 sibling, 0 replies; 51+ messages in thread
From: Alexander Graf @ 2019-02-12 10:16 UTC (permalink / raw)
To: u-boot
On 02/12/2019 11:12 AM, Bin Meng wrote:
> On Tue, Feb 12, 2019 at 5:09 PM Andreas Schwab <schwab@suse.de> wrote:
>> On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>>> On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab <schwab@suse.de> wrote:
>>>> On Feb 12 2019, Anup Patel <anup@brainfault.org> wrote:
>>>>
>>>>> This is because we don't have place to put U-Boot environment
>>>>> variables as of now on Unleashed board. This will be solved once
>>>>> we have SPI driver and SPI_MMC driver for Unleased board.
>>>> Isn't the MAC part of the initial DT?
>>>>
>>> My understanding is that U-Boot should fixup the DT using the
>>> <ethaddr> environment value, before jumping to Linux.
>> But where does it get the env var from? Why would it need to modify the
>> MAC?
>>
> The env var is stored in whatever supported media in U-Boot. Not like
> PCI NICs which normally have EEPROM to store pre-flashed MAC address
> by their vendors, for most embedded network controllers in the SoC,
> normally there is no hardware provided mechanism to ensure a unique
> MAC address, instead it relies on software to program one to the
> hardware before bringing it up. In the U-Boot case, it's the <ethaddr>
> env.
Yes, and U-Boot can read it from the DT to populate ethaddr if its upper
layer does provide a stable MAC address through DT.
Alex
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 10:12 ` Bin Meng
2019-02-12 10:16 ` Alexander Graf
@ 2019-02-12 10:22 ` Andreas Schwab
2019-02-13 1:31 ` Bin Meng
1 sibling, 1 reply; 51+ messages in thread
From: Andreas Schwab @ 2019-02-12 10:22 UTC (permalink / raw)
To: u-boot
On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote:
> The env var is stored in whatever supported media in U-Boot. Not like
> PCI NICs which normally have EEPROM to store pre-flashed MAC address
> by their vendors, for most embedded network controllers in the SoC,
> normally there is no hardware provided mechanism to ensure a unique
> MAC address, instead it relies on software to program one to the
> hardware before bringing it up.
On the Hifive the MAC is part of the initial DT, so there is no need to
use a secondary store.
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."
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-12 10:22 ` Andreas Schwab
@ 2019-02-13 1:31 ` Bin Meng
2019-02-13 3:51 ` Anup Patel
2019-02-13 8:29 ` Alexander Graf
0 siblings, 2 replies; 51+ messages in thread
From: Bin Meng @ 2019-02-13 1:31 UTC (permalink / raw)
To: u-boot
On Tue, Feb 12, 2019 at 6:23 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> > The env var is stored in whatever supported media in U-Boot. Not like
> > PCI NICs which normally have EEPROM to store pre-flashed MAC address
> > by their vendors, for most embedded network controllers in the SoC,
> > normally there is no hardware provided mechanism to ensure a unique
> > MAC address, instead it relies on software to program one to the
> > hardware before bringing it up.
>
> On the Hifive the MAC is part of the initial DT, so there is no need to
> use a secondary store.
>
So for the HiFive board, who is supposed to guarantee the uniqueness
of the MAC address? Does SiFive program DT with different MAC to every
board they shipped? If so, we can just read "local-mac-address" from
DT in U-Boot.
Regards,
Bin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-13 1:31 ` Bin Meng
@ 2019-02-13 3:51 ` Anup Patel
2019-02-13 9:35 ` Andreas Schwab
2019-02-13 8:29 ` Alexander Graf
1 sibling, 1 reply; 51+ messages in thread
From: Anup Patel @ 2019-02-13 3:51 UTC (permalink / raw)
To: u-boot
On Wed, Feb 13, 2019 at 7:01 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Tue, Feb 12, 2019 at 6:23 PM Andreas Schwab <schwab@suse.de> wrote:
> >
> > On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > > The env var is stored in whatever supported media in U-Boot. Not like
> > > PCI NICs which normally have EEPROM to store pre-flashed MAC address
> > > by their vendors, for most embedded network controllers in the SoC,
> > > normally there is no hardware provided mechanism to ensure a unique
> > > MAC address, instead it relies on software to program one to the
> > > hardware before bringing it up.
> >
> > On the Hifive the MAC is part of the initial DT, so there is no need to
> > use a secondary store.
> >
>
> So for the HiFive board, who is supposed to guarantee the uniqueness
> of the MAC address? Does SiFive program DT with different MAC to every
> board they shipped? If so, we can just read "local-mac-address" from
> DT in U-Boot.
General practice (atlease what I have seen on few boards), is that board
will have unique MAC address printed/labelled for each Ethernet port. We
can just set-and-save "ethaddr" U-Boot env variable based on MAC address
printed on board.
Unfortunately, I was not able to find printed MAC address on Unleashed board.
Regards,
Anup
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-13 3:51 ` Anup Patel
@ 2019-02-13 9:35 ` Andreas Schwab
2019-02-13 9:46 ` Auer, Lukas
0 siblings, 1 reply; 51+ messages in thread
From: Andreas Schwab @ 2019-02-13 9:35 UTC (permalink / raw)
To: u-boot
On Feb 13 2019, Anup Patel <anup@brainfault.org> wrote:
> General practice (atlease what I have seen on few boards), is that board
> will have unique MAC address printed/labelled for each Ethernet port. We
> can just set-and-save "ethaddr" U-Boot env variable based on MAC address
> printed on board.
>
> Unfortunately, I was not able to find printed MAC address on Unleashed board.
It is derived from the serial number.
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."
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-13 9:35 ` Andreas Schwab
@ 2019-02-13 9:46 ` Auer, Lukas
0 siblings, 0 replies; 51+ messages in thread
From: Auer, Lukas @ 2019-02-13 9:46 UTC (permalink / raw)
To: u-boot
On Wed, 2019-02-13 at 10:35 +0100, Andreas Schwab wrote:
> On Feb 13 2019, Anup Patel <anup@brainfault.org> wrote:
>
> > General practice (atlease what I have seen on few boards), is that
> > board
> > will have unique MAC address printed/labelled for each Ethernet
> > port. We
> > can just set-and-save "ethaddr" U-Boot env variable based on MAC
> > address
> > printed on board.
> >
> > Unfortunately, I was not able to find printed MAC address on
> > Unleashed board.
>
> It is derived from the serial number.
>
Here is the relevant code from the FSBL [1]. The serial number is
stored in OTP memory.
There's also a U-Boot driver available [2], but I haven't tested or
looked at it in detail.
[1]:
https://github.com/sifive/freedom-u540-c000-bootloader/blob/master/fsbl/main.c#L377
[2]:
https://github.com/tmagik/HiFive_U-Boot/commit/6d842765de142b61f847852da7a9ce0d081d770c
Thanks,
Lukas
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-13 1:31 ` Bin Meng
2019-02-13 3:51 ` Anup Patel
@ 2019-02-13 8:29 ` Alexander Graf
2019-02-13 9:34 ` Andreas Schwab
1 sibling, 1 reply; 51+ messages in thread
From: Alexander Graf @ 2019-02-13 8:29 UTC (permalink / raw)
To: u-boot
On 13.02.19 02:31, Bin Meng wrote:
> On Tue, Feb 12, 2019 at 6:23 PM Andreas Schwab <schwab@suse.de> wrote:
>>
>> On Feb 12 2019, Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>>> The env var is stored in whatever supported media in U-Boot. Not like
>>> PCI NICs which normally have EEPROM to store pre-flashed MAC address
>>> by their vendors, for most embedded network controllers in the SoC,
>>> normally there is no hardware provided mechanism to ensure a unique
>>> MAC address, instead it relies on software to program one to the
>>> hardware before bringing it up.
>>
>> On the Hifive the MAC is part of the initial DT, so there is no need to
>> use a secondary store.
>>
>
> So for the HiFive board, who is supposed to guarantee the uniqueness
> of the MAC address? Does SiFive program DT with different MAC to every
> board they shipped? If so, we can just read "local-mac-address" from
> DT in U-Boot.
The DT is supplied via SD card, just like U-Boot is. So it's up to the
user to modify the DT and ensure that it contains a unique MAC address.
Alex
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-13 8:29 ` Alexander Graf
@ 2019-02-13 9:34 ` Andreas Schwab
0 siblings, 0 replies; 51+ messages in thread
From: Andreas Schwab @ 2019-02-13 9:34 UTC (permalink / raw)
To: u-boot
On Feb 13 2019, Alexander Graf <agraf@suse.de> wrote:
> The DT is supplied via SD card
That's not true by default. It is part of the FSBL, I think.
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."
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-11 5:41 [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Anup Patel
` (15 preceding siblings ...)
2019-02-11 15:37 ` [U-Boot] [PATCH v7 00/15] SiFive FU540 Support Andreas Schwab
@ 2019-02-13 23:44 ` Kevin Hilman
2019-02-13 23:58 ` Kevin Hilman
16 siblings, 1 reply; 51+ messages in thread
From: Kevin Hilman @ 2019-02-13 23:44 UTC (permalink / raw)
To: u-boot
Hi Anup,
Anup Patel <Anup.Patel@wdc.com> writes:
> This patchset adds SiFive Freedom Unleashed (FU540) support
> to RISC-V U-Boot.
>
> The patches are based upon latest U-Boot source tree
> (git://git.denx.de/u-boot.git) at commit id
> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>
> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> MACB Ethernet work fine on actual SiFive Unleashed board and
> QEMU sifive_u machine.
I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
and it worked fine. Then, I moved it to a lab with a 100Mb switch,
and DHCP doesn't work anymore.
Can you do some sanity testing with a 100Mb switch?
Kevin
^ permalink raw reply [flat|nested] 51+ messages in thread* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-13 23:44 ` Kevin Hilman
@ 2019-02-13 23:58 ` Kevin Hilman
2019-03-11 14:33 ` Bin Meng
0 siblings, 1 reply; 51+ messages in thread
From: Kevin Hilman @ 2019-02-13 23:58 UTC (permalink / raw)
To: u-boot
Kevin Hilman <khilman@baylibre.com> writes:
> Hi Anup,
>
> Anup Patel <Anup.Patel@wdc.com> writes:
>
>> This patchset adds SiFive Freedom Unleashed (FU540) support
>> to RISC-V U-Boot.
>>
>> The patches are based upon latest U-Boot source tree
>> (git://git.denx.de/u-boot.git) at commit id
>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>
>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>> MACB Ethernet work fine on actual SiFive Unleashed board and
>> QEMU sifive_u machine.
>
> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> and it worked fine. Then, I moved it to a lab with a 100Mb switch,
> and DHCP doesn't work anymore.
And to be clear, neither does TFTP if setting static
ipaddr/netmask/gatewayip etc.
Kevin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-02-13 23:58 ` Kevin Hilman
@ 2019-03-11 14:33 ` Bin Meng
2019-03-12 8:55 ` Palmer Dabbelt
0 siblings, 1 reply; 51+ messages in thread
From: Bin Meng @ 2019-03-11 14:33 UTC (permalink / raw)
To: u-boot
On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Kevin Hilman <khilman@baylibre.com> writes:
>
> > Hi Anup,
> >
> > Anup Patel <Anup.Patel@wdc.com> writes:
> >
> >> This patchset adds SiFive Freedom Unleashed (FU540) support
> >> to RISC-V U-Boot.
> >>
> >> The patches are based upon latest U-Boot source tree
> >> (git://git.denx.de/u-boot.git) at commit id
> >> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >>
> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >> MACB Ethernet work fine on actual SiFive Unleashed board and
> >> QEMU sifive_u machine.
> >
> > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> > and it worked fine. Then, I moved it to a lab with a 100Mb switch,
> > and DHCP doesn't work anymore.
>
> And to be clear, neither does TFTP if setting static
> ipaddr/netmask/gatewayip etc.
Sound to me a bug of the GEM driver on SiFive FU540 board.
Regards,
Bin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-03-11 14:33 ` Bin Meng
@ 2019-03-12 8:55 ` Palmer Dabbelt
2019-04-18 19:14 ` Kevin Hilman
0 siblings, 1 reply; 51+ messages in thread
From: Palmer Dabbelt @ 2019-03-12 8:55 UTC (permalink / raw)
To: u-boot
On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Kevin Hilman <khilman@baylibre.com> writes:
>>
>> > Hi Anup,
>> >
>> > Anup Patel <Anup.Patel@wdc.com> writes:
>> >
>> >> This patchset adds SiFive Freedom Unleashed (FU540) support
>> >> to RISC-V U-Boot.
>> >>
>> >> The patches are based upon latest U-Boot source tree
>> >> (git://git.denx.de/u-boot.git) at commit id
>> >> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>> >>
>> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>> >> MACB Ethernet work fine on actual SiFive Unleashed board and
>> >> QEMU sifive_u machine.
>> >
>> > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>> > and it worked fine. Then, I moved it to a lab with a 100Mb switch,
>> > and DHCP doesn't work anymore.
>>
>> And to be clear, neither does TFTP if setting static
>> ipaddr/netmask/gatewayip etc.
>
> Sound to me a bug of the GEM driver on SiFive FU540 board.
It looks to me like u-boot is missing a driver for the GEM clockmux in the
FU540. This is necessary to switch between the clock for 1G operation and 100M
operation. Without this you'll just get whatever clock was set up by the
previous boot stage (or even worse, reset).
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-03-12 8:55 ` Palmer Dabbelt
@ 2019-04-18 19:14 ` Kevin Hilman
2019-04-18 20:05 ` Atish Patra
0 siblings, 1 reply; 51+ messages in thread
From: Kevin Hilman @ 2019-04-18 19:14 UTC (permalink / raw)
To: u-boot
Palmer, Anup,
On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
> > On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
> >>
> >> Kevin Hilman <khilman@baylibre.com> writes:
> >>
> >> > Hi Anup,
> >> >
> >> > Anup Patel <Anup.Patel@wdc.com> writes:
> >> >
> >> >> This patchset adds SiFive Freedom Unleashed (FU540) support
> >> >> to RISC-V U-Boot.
> >> >>
> >> >> The patches are based upon latest U-Boot source tree
> >> >> (git://git.denx.de/u-boot.git) at commit id
> >> >> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >> >>
> >> >> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >> >> MACB Ethernet work fine on actual SiFive Unleashed board and
> >> >> QEMU sifive_u machine.
> >> >
> >> > I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> >> > and it worked fine. Then, I moved it to a lab with a 100Mb switch,
> >> > and DHCP doesn't work anymore.
> >>
> >> And to be clear, neither does TFTP if setting static
> >> ipaddr/netmask/gatewayip etc.
> >
> > Sound to me a bug of the GEM driver on SiFive FU540 board.
>
> It looks to me like u-boot is missing a driver for the GEM clockmux in the
> FU540. This is necessary to switch between the clock for 1G operation and 100M
> operation. Without this you'll just get whatever clock was set up by the
> previous boot stage (or even worse, reset).
Anyone know if this is fixed in u-boot yet? I've yet to try the
latest mainline u-boot, but will if if it's expected to work.
Kevin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-04-18 19:14 ` Kevin Hilman
@ 2019-04-18 20:05 ` Atish Patra
2019-04-18 23:16 ` Kevin Hilman
0 siblings, 1 reply; 51+ messages in thread
From: Atish Patra @ 2019-04-18 20:05 UTC (permalink / raw)
To: u-boot
On 4/18/19 12:15 PM, Kevin Hilman wrote:
> Palmer, Anup,
>
> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>>
>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>>>
>>>> Kevin Hilman <khilman@baylibre.com> writes:
>>>>
>>>>> Hi Anup,
>>>>>
>>>>> Anup Patel <Anup.Patel@wdc.com> writes:
>>>>>
>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>>> to RISC-V U-Boot.
>>>>>>
>>>>>> The patches are based upon latest U-Boot source tree
>>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>>
>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>>> QEMU sifive_u machine.
>>>>>
>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch,
>>>>> and DHCP doesn't work anymore.
>>>>
>>>> And to be clear, neither does TFTP if setting static
>>>> ipaddr/netmask/gatewayip etc.
>>>
>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
>>
>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
>> FU540. This is necessary to switch between the clock for 1G operation and 100M
>> operation. Without this you'll just get whatever clock was set up by the
>> previous boot stage (or even worse, reset).
>
> Anyone know if this is fixed in u-boot yet? I've yet to try the
> latest mainline u-boot, but will if if it's expected to work.
>
I have not seen a GEM driver for FU540 board. So I guess it is not fixed
it. Is it a blocker for setting up kernelCI for RISC-V ?
Regards,
Atish
> Kevin
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-04-18 20:05 ` Atish Patra
@ 2019-04-18 23:16 ` Kevin Hilman
2019-04-19 0:51 ` Atish Patra
0 siblings, 1 reply; 51+ messages in thread
From: Kevin Hilman @ 2019-04-18 23:16 UTC (permalink / raw)
To: u-boot
Atish Patra <atish.patra@wdc.com> writes:
> On 4/18/19 12:15 PM, Kevin Hilman wrote:
>> Palmer, Anup,
>>
>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>>>
>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>>>>
>>>>> Kevin Hilman <khilman@baylibre.com> writes:
>>>>>
>>>>>> Hi Anup,
>>>>>>
>>>>>> Anup Patel <Anup.Patel@wdc.com> writes:
>>>>>>
>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>>>> to RISC-V U-Boot.
>>>>>>>
>>>>>>> The patches are based upon latest U-Boot source tree
>>>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>>>
>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>>>> QEMU sifive_u machine.
>>>>>>
>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch,
>>>>>> and DHCP doesn't work anymore.
>>>>>
>>>>> And to be clear, neither does TFTP if setting static
>>>>> ipaddr/netmask/gatewayip etc.
>>>>
>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
>>>
>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
>>> FU540. This is necessary to switch between the clock for 1G operation and 100M
>>> operation. Without this you'll just get whatever clock was set up by the
>>> previous boot stage (or even worse, reset).
>>
>> Anyone know if this is fixed in u-boot yet? I've yet to try the
>> latest mainline u-boot, but will if if it's expected to work.
>>
>
> I have not seen a GEM driver for FU540 board. So I guess it is not fixed
> it. Is it a blocker for setting up kernelCI for RISC-V ?
Not really, that's only one of the remaining issue. For now, I have
connected it to a gigE switch, so u-boot networking is working.
But, the bigger blocker for kernelCI right now is not having
out-of-the-box mainline support. Mainline is still missing a serial
driver, and a handful of Kconfig options in the default defconfig to
make things boot[1].
If I use the 'v5.1-rc4_unleashed' from your github, along with my
kconfig fragment[1], things are working well.
But in order to automate this for kernelCI, we need all of that
upstream.
Kevin
[1] This is the config fragment I'm adding to the default defconfig in
mainline. I'm not exactly sure which ones are absolutely need for basic
boot.
CONFIG_SERIAL_SIFIVE=y
CONFIG_SERIAL_SIFIVE_CONSOLE=y
CONFIG_SIFIVE_PLIC=y
CONFIG_SPI=y
CONFIG_SPI_SIFIVE=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SIFIVE=y
CONFIG_PWM_SIFIVE=y
CONFIG_CLK_U54_PRCI=y
CONFIG_CLK_GEMGXL_MGMT=y
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-04-18 23:16 ` Kevin Hilman
@ 2019-04-19 0:51 ` Atish Patra
2019-04-19 20:38 ` Kevin Hilman
0 siblings, 1 reply; 51+ messages in thread
From: Atish Patra @ 2019-04-19 0:51 UTC (permalink / raw)
To: u-boot
On 4/18/19 4:16 PM, Kevin Hilman wrote:
> Atish Patra <atish.patra@wdc.com> writes:
>
>> On 4/18/19 12:15 PM, Kevin Hilman wrote:
>>> Palmer, Anup,
>>>
>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>>>>
>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>>>>>
>>>>>> Kevin Hilman <khilman@baylibre.com> writes:
>>>>>>
>>>>>>> Hi Anup,
>>>>>>>
>>>>>>> Anup Patel <Anup.Patel@wdc.com> writes:
>>>>>>>
>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>>>>> to RISC-V U-Boot.
>>>>>>>>
>>>>>>>> The patches are based upon latest U-Boot source tree
>>>>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>>>>
>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>>>>> QEMU sifive_u machine.
>>>>>>>
>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch,
>>>>>>> and DHCP doesn't work anymore.
>>>>>>
>>>>>> And to be clear, neither does TFTP if setting static
>>>>>> ipaddr/netmask/gatewayip etc.
>>>>>
>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
>>>>
>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
>>>> FU540. This is necessary to switch between the clock for 1G operation and 100M
>>>> operation. Without this you'll just get whatever clock was set up by the
>>>> previous boot stage (or even worse, reset).
>>>
>>> Anyone know if this is fixed in u-boot yet? I've yet to try the
>>> latest mainline u-boot, but will if if it's expected to work.
>>>
>>
>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed
>> it. Is it a blocker for setting up kernelCI for RISC-V ?
>
> Not really, that's only one of the remaining issue. For now, I have
> connected it to a gigE switch, so u-boot networking is working.
>
> But, the bigger blocker for kernelCI right now is not having
> out-of-the-box mainline support. Mainline is still missing a serial
> driver, and a handful of Kconfig options in the default defconfig to
> make things boot[1].
>
> If I use the 'v5.1-rc4_unleashed' from your github, along with my
> kconfig fragment[1], things are working well.
>
> But in order to automate this for kernelCI, we need all of that
> upstream.
>
Yeah. I agree. We need upstream drivers sooner than later.
I believe SiFive Team (Paul & co) are working on this.
He recently sent updated version of driver patches to the linux-riscv
mailing list.
> Kevin
>
> [1] This is the config fragment I'm adding to the default defconfig in
> mainline. I'm not exactly sure which ones are absolutely need for basic
> boot.
>
> CONFIG_SERIAL_SIFIVE=y
> CONFIG_SERIAL_SIFIVE_CONSOLE=y
> CONFIG_SIFIVE_PLIC=y
> CONFIG_SPI=y
> CONFIG_SPI_SIFIVE=y
> CONFIG_GPIOLIB=y
> CONFIG_GPIO_SIFIVE=y
> CONFIG_PWM_SIFIVE=y
> CONFIG_CLK_U54_PRCI=y
> CONFIG_CLK_GEMGXL_MGMT=y
>
My working config has enabled all of the above except CONFIG_PWM_SIFIVE.
I have not played around the config that much to find out absolute
minimum config. So this may not be the answer you are looking for :).
Regards,
Atish
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-04-19 0:51 ` Atish Patra
@ 2019-04-19 20:38 ` Kevin Hilman
2019-04-19 20:43 ` Kevin Hilman
0 siblings, 1 reply; 51+ messages in thread
From: Kevin Hilman @ 2019-04-19 20:38 UTC (permalink / raw)
To: u-boot
Atish Patra <atish.patra@wdc.com> writes:
> On 4/18/19 4:16 PM, Kevin Hilman wrote:
>> Atish Patra <atish.patra@wdc.com> writes:
>>
>>> On 4/18/19 12:15 PM, Kevin Hilman wrote:
>>>> Palmer, Anup,
>>>>
>>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>>>>>
>>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
>>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>>>>>>
>>>>>>> Kevin Hilman <khilman@baylibre.com> writes:
>>>>>>>
>>>>>>>> Hi Anup,
>>>>>>>>
>>>>>>>> Anup Patel <Anup.Patel@wdc.com> writes:
>>>>>>>>
>>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>>>>>> to RISC-V U-Boot.
>>>>>>>>>
>>>>>>>>> The patches are based upon latest U-Boot source tree
>>>>>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>>>>>
>>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>>>>>> QEMU sifive_u machine.
>>>>>>>>
>>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>>>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch,
>>>>>>>> and DHCP doesn't work anymore.
>>>>>>>
>>>>>>> And to be clear, neither does TFTP if setting static
>>>>>>> ipaddr/netmask/gatewayip etc.
>>>>>>
>>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
>>>>>
>>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
>>>>> FU540. This is necessary to switch between the clock for 1G operation and 100M
>>>>> operation. Without this you'll just get whatever clock was set up by the
>>>>> previous boot stage (or even worse, reset).
>>>>
>>>> Anyone know if this is fixed in u-boot yet? I've yet to try the
>>>> latest mainline u-boot, but will if if it's expected to work.
>>>>
>>>
>>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed
>>> it. Is it a blocker for setting up kernelCI for RISC-V ?
>>
>> Not really, that's only one of the remaining issue. For now, I have
>> connected it to a gigE switch, so u-boot networking is working.
>>
>> But, the bigger blocker for kernelCI right now is not having
>> out-of-the-box mainline support. Mainline is still missing a serial
>> driver, and a handful of Kconfig options in the default defconfig to
>> make things boot[1].
>>
>> If I use the 'v5.1-rc4_unleashed' from your github, along with my
>> kconfig fragment[1], things are working well.
>>
>> But in order to automate this for kernelCI, we need all of that
>> upstream.
>>
> Yeah. I agree. We need upstream drivers sooner than later.
> I believe SiFive Team (Paul & co) are working on this.
>
> He recently sent updated version of driver patches to the linux-riscv
> mailing list.
Yes, I'm trying to test all of those (hence our other discussion on the
DT thread)
>> [1] This is the config fragment I'm adding to the default defconfig in
>> mainline. I'm not exactly sure which ones are absolutely need for basic
>> boot.
>>
>> CONFIG_SERIAL_SIFIVE=y
>> CONFIG_SERIAL_SIFIVE_CONSOLE=y
>> CONFIG_SIFIVE_PLIC=y
>> CONFIG_SPI=y
>> CONFIG_SPI_SIFIVE=y
>> CONFIG_GPIOLIB=y
>> CONFIG_GPIO_SIFIVE=y
>> CONFIG_PWM_SIFIVE=y
>> CONFIG_CLK_U54_PRCI=y
>> CONFIG_CLK_GEMGXL_MGMT=y
>>
>
> My working config has enabled all of the above except CONFIG_PWM_SIFIVE.
> I have not played around the config that much to find out absolute
> minimum config. So this may not be the answer you are looking for :).
At least for kernelCI, we'll need to figure that out and get it upstream
if we want to boot test these.
Kevin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-04-19 20:38 ` Kevin Hilman
@ 2019-04-19 20:43 ` Kevin Hilman
2019-04-20 2:56 ` Atish Patra
0 siblings, 1 reply; 51+ messages in thread
From: Kevin Hilman @ 2019-04-19 20:43 UTC (permalink / raw)
To: u-boot
On Fri, Apr 19, 2019 at 1:38 PM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Atish Patra <atish.patra@wdc.com> writes:
>
> > On 4/18/19 4:16 PM, Kevin Hilman wrote:
> >> Atish Patra <atish.patra@wdc.com> writes:
> >>
> >>> On 4/18/19 12:15 PM, Kevin Hilman wrote:
> >>>> Palmer, Anup,
> >>>>
> >>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote:
> >>>>>
> >>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
> >>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
> >>>>>>>
> >>>>>>> Kevin Hilman <khilman@baylibre.com> writes:
> >>>>>>>
> >>>>>>>> Hi Anup,
> >>>>>>>>
> >>>>>>>> Anup Patel <Anup.Patel@wdc.com> writes:
> >>>>>>>>
> >>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
> >>>>>>>>> to RISC-V U-Boot.
> >>>>>>>>>
> >>>>>>>>> The patches are based upon latest U-Boot source tree
> >>>>>>>>> (git://git.denx.de/u-boot.git) at commit id
> >>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
> >>>>>>>>>
> >>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
> >>>>>>>>> QEMU sifive_u machine.
> >>>>>>>>
> >>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
> >>>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch,
> >>>>>>>> and DHCP doesn't work anymore.
> >>>>>>>
> >>>>>>> And to be clear, neither does TFTP if setting static
> >>>>>>> ipaddr/netmask/gatewayip etc.
> >>>>>>
> >>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
> >>>>>
> >>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
> >>>>> FU540. This is necessary to switch between the clock for 1G operation and 100M
> >>>>> operation. Without this you'll just get whatever clock was set up by the
> >>>>> previous boot stage (or even worse, reset).
> >>>>
> >>>> Anyone know if this is fixed in u-boot yet? I've yet to try the
> >>>> latest mainline u-boot, but will if if it's expected to work.
> >>>>
> >>>
> >>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed
> >>> it. Is it a blocker for setting up kernelCI for RISC-V ?
> >>
> >> Not really, that's only one of the remaining issue. For now, I have
> >> connected it to a gigE switch, so u-boot networking is working.
> >>
> >> But, the bigger blocker for kernelCI right now is not having
> >> out-of-the-box mainline support. Mainline is still missing a serial
> >> driver, and a handful of Kconfig options in the default defconfig to
> >> make things boot[1].
> >>
> >> If I use the 'v5.1-rc4_unleashed' from your github, along with my
> >> kconfig fragment[1], things are working well.
> >>
> >> But in order to automate this for kernelCI, we need all of that
> >> upstream.
> >>
> > Yeah. I agree. We need upstream drivers sooner than later.
> > I believe SiFive Team (Paul & co) are working on this.
> >
> > He recently sent updated version of driver patches to the linux-riscv
> > mailing list.
>
> Yes, I'm trying to test all of those (hence our other discussion on the
> DT thread)
>
> >> [1] This is the config fragment I'm adding to the default defconfig in
> >> mainline. I'm not exactly sure which ones are absolutely need for basic
> >> boot.
> >>
> >> CONFIG_SERIAL_SIFIVE=y
> >> CONFIG_SERIAL_SIFIVE_CONSOLE=y
> >> CONFIG_SIFIVE_PLIC=y
> >> CONFIG_SPI=y
> >> CONFIG_SPI_SIFIVE=y
> >> CONFIG_GPIOLIB=y
> >> CONFIG_GPIO_SIFIVE=y
> >> CONFIG_PWM_SIFIVE=y
> >> CONFIG_CLK_U54_PRCI=y
> >> CONFIG_CLK_GEMGXL_MGMT=y
> >>
> >
> > My working config has enabled all of the above except CONFIG_PWM_SIFIVE.
> > I have not played around the config that much to find out absolute
> > minimum config. So this may not be the answer you are looking for :).
>
> At least for kernelCI, we'll need to figure that out and get it upstream
> if we want to boot test these.
Oh, and one other u-boot question.
Any reason you didn't enable `booti` support in riscv u-boot? That
would allow you to boot the Image (or Image.gz) directly, instead of
the need to create a special image with u-boot header (uImage)
Kevin
^ permalink raw reply [flat|nested] 51+ messages in thread
* [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
2019-04-19 20:43 ` Kevin Hilman
@ 2019-04-20 2:56 ` Atish Patra
0 siblings, 0 replies; 51+ messages in thread
From: Atish Patra @ 2019-04-20 2:56 UTC (permalink / raw)
To: u-boot
On 4/19/19 1:44 PM, Kevin Hilman wrote:
> On Fri, Apr 19, 2019 at 1:38 PM Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Atish Patra <atish.patra@wdc.com> writes:
>>
>>> On 4/18/19 4:16 PM, Kevin Hilman wrote:
>>>> Atish Patra <atish.patra@wdc.com> writes:
>>>>
>>>>> On 4/18/19 12:15 PM, Kevin Hilman wrote:
>>>>>> Palmer, Anup,
>>>>>>
>>>>>> On Tue, Mar 12, 2019 at 1:55 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>>>>>>>
>>>>>>> On Mon, 11 Mar 2019 07:33:25 PDT (-0700), bmeng.cn at gmail.com wrote:
>>>>>>>> On Thu, Feb 14, 2019 at 7:58 AM Kevin Hilman <khilman@baylibre.com> wrote:
>>>>>>>>>
>>>>>>>>> Kevin Hilman <khilman@baylibre.com> writes:
>>>>>>>>>
>>>>>>>>>> Hi Anup,
>>>>>>>>>>
>>>>>>>>>> Anup Patel <Anup.Patel@wdc.com> writes:
>>>>>>>>>>
>>>>>>>>>>> This patchset adds SiFive Freedom Unleashed (FU540) support
>>>>>>>>>>> to RISC-V U-Boot.
>>>>>>>>>>>
>>>>>>>>>>> The patches are based upon latest U-Boot source tree
>>>>>>>>>>> (git://git.denx.de/u-boot.git) at commit id
>>>>>>>>>>> dbe70c7d4e3d5c705a98d82952e05a591efd0683
>>>>>>>>>>>
>>>>>>>>>>> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
>>>>>>>>>>> MACB Ethernet work fine on actual SiFive Unleashed board and
>>>>>>>>>>> QEMU sifive_u machine.
>>>>>>>>>>
>>>>>>>>>> I tested u-boot networking (DHCP, TFTP) on my desk with a gigE switch
>>>>>>>>>> and it worked fine. Then, I moved it to a lab with a 100Mb switch,
>>>>>>>>>> and DHCP doesn't work anymore.
>>>>>>>>>
>>>>>>>>> And to be clear, neither does TFTP if setting static
>>>>>>>>> ipaddr/netmask/gatewayip etc.
>>>>>>>>
>>>>>>>> Sound to me a bug of the GEM driver on SiFive FU540 board.
>>>>>>>
>>>>>>> It looks to me like u-boot is missing a driver for the GEM clockmux in the
>>>>>>> FU540. This is necessary to switch between the clock for 1G operation and 100M
>>>>>>> operation. Without this you'll just get whatever clock was set up by the
>>>>>>> previous boot stage (or even worse, reset).
>>>>>>
>>>>>> Anyone know if this is fixed in u-boot yet? I've yet to try the
>>>>>> latest mainline u-boot, but will if if it's expected to work.
>>>>>>
>>>>>
>>>>> I have not seen a GEM driver for FU540 board. So I guess it is not fixed
>>>>> it. Is it a blocker for setting up kernelCI for RISC-V ?
>>>>
>>>> Not really, that's only one of the remaining issue. For now, I have
>>>> connected it to a gigE switch, so u-boot networking is working.
>>>>
>>>> But, the bigger blocker for kernelCI right now is not having
>>>> out-of-the-box mainline support. Mainline is still missing a serial
>>>> driver, and a handful of Kconfig options in the default defconfig to
>>>> make things boot[1].
>>>>
>>>> If I use the 'v5.1-rc4_unleashed' from your github, along with my
>>>> kconfig fragment[1], things are working well.
>>>>
>>>> But in order to automate this for kernelCI, we need all of that
>>>> upstream.
>>>>
>>> Yeah. I agree. We need upstream drivers sooner than later.
>>> I believe SiFive Team (Paul & co) are working on this.
>>>
>>> He recently sent updated version of driver patches to the linux-riscv
>>> mailing list.
>>
>> Yes, I'm trying to test all of those (hence our other discussion on the
>> DT thread)
>>
>>>> [1] This is the config fragment I'm adding to the default defconfig in
>>>> mainline. I'm not exactly sure which ones are absolutely need for basic
>>>> boot.
>>>>
>>>> CONFIG_SERIAL_SIFIVE=y
>>>> CONFIG_SERIAL_SIFIVE_CONSOLE=y
>>>> CONFIG_SIFIVE_PLIC=y
>>>> CONFIG_SPI=y
>>>> CONFIG_SPI_SIFIVE=y
>>>> CONFIG_GPIOLIB=y
>>>> CONFIG_GPIO_SIFIVE=y
>>>> CONFIG_PWM_SIFIVE=y
>>>> CONFIG_CLK_U54_PRCI=y
>>>> CONFIG_CLK_GEMGXL_MGMT=y
>>>>
>>>
>>> My working config has enabled all of the above except CONFIG_PWM_SIFIVE.
>>> I have not played around the config that much to find out absolute
>>> minimum config. So this may not be the answer you are looking for :).
>>
>> At least for kernelCI, we'll need to figure that out and get it upstream
>> if we want to boot test these.
>
> Oh, and one other u-boot question.
>
> Any reason you didn't enable `booti` support in riscv u-boot? That
> would allow you to boot the Image (or Image.gz) directly, instead of
> the need to create a special image with u-boot header (uImage)
>
Yes. I am currently working on booti support. I should have a working
patch by next week.
Regards,
Atish
> Kevin
>
^ permalink raw reply [flat|nested] 51+ messages in thread