* [RFC] riscv: JH7110: move pll clocks to their own device node (Was: The latest U-boot...) visionfive2 1.3B board
2023-06-02 1:16 ` The latest U-boot reports an error when running on StarFive visionfive2 1.3B board yanhong wang
@ 2023-06-02 17:10 ` Torsten Duwe
2023-06-03 1:05 ` The latest U-boot reports an error when running on StarFive " Simon Glass
1 sibling, 0 replies; 3+ messages in thread
From: Torsten Duwe @ 2023-06-02 17:10 UTC (permalink / raw)
To: yanhong wang; +Cc: u-boot, Rick Chen, Leo, Simon Glass, Conor Dooley
> On 2023/5/31 2:11, Simon Glass wrote:
> > Hi Yanhong,
> >
> > Please can you send this to the mailing list and cc me?
> >
Yes, that would have prevented some grief.
[...]
> >> DRAM: 8 GiB
> >> initcall sequence 00000000fffe08b0 failed at call 000000004021611e (err=-19)
> >> ### ERROR ### Please RESET the board ###
> >>
> >> Roll back the most recent submission, and finally confirm that one of the submission affected [commit ID: 55171aedda88d12666e2a1bbc661dea1bec65337].
Here is the revert, along with a work in progress attempt to make the DT
match the hardware. Conor had asked me to share it, regardless of its
early stage. It compiles, and boots Linux kernels, but there is no PLL
driver I can find currently. So clocks are still hanging in PROBE_DEFER.
Torsten
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index 710b082766..6bb0ddf405 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
@@ -313,9 +313,9 @@
<&syscrg JH7110_SYSCLK_BUS_ROOT>,
<&syscrg JH7110_SYSCLK_PERH_ROOT>,
<&syscrg JH7110_SYSCLK_QSPI_REF>;
- assigned-clock-parents = <&syscrg JH7110_SYSCLK_PLL0_OUT>,
- <&syscrg JH7110_SYSCLK_PLL2_OUT>,
- <&syscrg JH7110_SYSCLK_PLL2_OUT>,
+ assigned-clock-parents = <&sys_syscon JH7110_SYSCLK_PLL0_OUT>,
+ <&sys_syscon JH7110_SYSCLK_PLL2_OUT>,
+ <&sys_syscon JH7110_SYSCLK_PLL2_OUT>,
<&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;
assigned-clock-rates = <0>, <0>, <0>, <0>;
};
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index 58e332e9d7..c9e820fa9b 100644
--- a/arch/riscv/dts/jh7110.dtsi
+++ b/arch/riscv/dts/jh7110.dtsi
@@ -500,6 +500,7 @@
sys_syscon: sys_syscon@13030000 {
compatible = "starfive,jh7110-sys-syscon","syscon";
reg = <0x0 0x13030000 0x0 0x1000>;
+ #clock-cells = <1>;
};
sysgpio: pinctrl@13040000 {
diff --git a/drivers/clk/starfive/clk-jh7110-pll.c b/drivers/clk/starfive/clk-jh7110-pll.c
index 02e6d9000e..f2f970e0d0 100644
--- a/drivers/clk/starfive/clk-jh7110-pll.c
+++ b/drivers/clk/starfive/clk-jh7110-pll.c
@@ -11,6 +11,7 @@
#include <clk-uclass.h>
#include <div64.h>
#include <dm/device.h>
+#include <dt-bindings/clock/starfive,jh7110-crg.h>
#include <linux/bitops.h>
#include <linux/clk-provider.h>
#include <linux/delay.h>
@@ -286,7 +287,10 @@ struct clk *starfive_jh7110_pll(const char *name, const char *parent_name,
if (!pll_clk || !base || !sysreg)
return ERR_PTR(-EINVAL);
-
+#ifdef DEBUG
+ printf("pll: %s - %s base: %p sysreg: %p\n",
+ parent_name, name, base, sysreg);
+#endif
pll = kzalloc(sizeof(*pll), GFP_KERNEL);
if (!pll)
return ERR_PTR(-ENOMEM);
@@ -314,8 +318,36 @@ struct clk *starfive_jh7110_pll(const char *name, const char *parent_name,
return clk;
}
+static int jh7110_pllclk_probe(struct udevice *dev)
+{
+ void __iomem *addr, *reg;
+
+ /* TODO: get below address(es) from OF DT! */
+ addr = (void __iomem *)0x13030000;
+ reg = (void __iomem *)0x13020000;
+
+ clk_dm(JH7110_SYSCLK_PLL0_OUT,
+ starfive_jh7110_pll("pll0_out", "oscillator", (void __iomem *)addr,
+ reg, &starfive_jh7110_pll0));
+ clk_dm(JH7110_SYSCLK_PLL1_OUT,
+ starfive_jh7110_pll("pll1_out", "oscillator", (void __iomem *)addr,
+ reg, &starfive_jh7110_pll1));
+ clk_dm(JH7110_SYSCLK_PLL2_OUT,
+ starfive_jh7110_pll("pll2_out", "oscillator", (void __iomem *)addr,
+ reg, &starfive_jh7110_pll2));
+ return 0;
+}
+
+static const struct udevice_id jh7110_pllclk_of_match[] = {
+ { .compatible = "starfive,jh7110-sys-syscon" },
+ { }
+};
+
U_BOOT_DRIVER(jh7110_clk_pllx) = {
.name = UBOOT_DM_CLK_JH7110_PLLX,
.id = UCLASS_CLK,
+ .of_match = jh7110_pllclk_of_match,
.ops = &clk_jh7110_ops,
+ .probe = jh7110_pllclk_probe,
};
+
diff --git a/drivers/clk/starfive/clk-jh7110.c b/drivers/clk/starfive/clk-jh7110.c
index a74b70906a..899a9bb49e 100644
--- a/drivers/clk/starfive/clk-jh7110.c
+++ b/drivers/clk/starfive/clk-jh7110.c
@@ -246,9 +246,11 @@ static int jh7110_syscrg_init(struct udevice *dev)
clk_dm(JH7110_SYSCLK_PLL0_OUT,
starfive_jh7110_pll("pll0_out", "oscillator", (void __iomem *)addr,
priv->reg, &starfive_jh7110_pll0));
+#if 0
clk_dm(JH7110_SYSCLK_PLL1_OUT,
starfive_jh7110_pll("pll1_out", "oscillator", (void __iomem *)addr,
priv->reg, &starfive_jh7110_pll1));
+#endif
clk_dm(JH7110_SYSCLK_PLL2_OUT,
starfive_jh7110_pll("pll2_out", "oscillator", (void __iomem *)addr,
priv->reg, &starfive_jh7110_pll2));
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 6775fb0b65..2bd2737440 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -436,7 +436,7 @@ int dm_init_and_scan(bool pre_reloc_only)
return ret;
}
}
- if (CONFIG_IS_ENABLED(DM_EVENT) && !(gd->flags & GD_FLG_RELOC)) {
+ if (CONFIG_IS_ENABLED(DM_EVENT) /* && !(gd->flags & GD_FLG_RELOC) */ ) {
ret = event_notify_null(EVT_DM_POST_INIT_F);
if (ret)
return log_msg_ret("ev", ret);
diff --git a/include/dt-bindings/clock/starfive,jh7110-crg.h b/include/dt-bindings/clock/starfive,jh7110-crg.h
index 77b70e7a83..6b182888a7 100644
--- a/include/dt-bindings/clock/starfive,jh7110-crg.h
+++ b/include/dt-bindings/clock/starfive,jh7110-crg.h
@@ -199,9 +199,9 @@
#define JH7110_SYSCLK_TDM_CLK_TDM_N 188
#define JH7110_SYSCLK_JTAG_CERTIFICATION_TRNG 189
-#define JH7110_SYSCLK_PLL0_OUT 190
-#define JH7110_SYSCLK_PLL1_OUT 191
-#define JH7110_SYSCLK_PLL2_OUT 192
+#define JH7110_SYSCLK_PLL0_OUT 0
+#define JH7110_SYSCLK_PLL1_OUT 1
+#define JH7110_SYSCLK_PLL2_OUT 2
#define JH7110_SYSCLK_END 193
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: The latest U-boot reports an error when running on StarFive visionfive2 1.3B board
2023-06-02 1:16 ` The latest U-boot reports an error when running on StarFive visionfive2 1.3B board yanhong wang
2023-06-02 17:10 ` [RFC] riscv: JH7110: move pll clocks to their own device node (Was: The latest U-boot...) " Torsten Duwe
@ 2023-06-03 1:05 ` Simon Glass
1 sibling, 0 replies; 3+ messages in thread
From: Simon Glass @ 2023-06-03 1:05 UTC (permalink / raw)
To: yanhong wang; +Cc: u-boot, Rick Chen, Leo, Torsten Duwe
Hi,
On Thu, 1 Jun 2023 at 19:16, yanhong wang <yanhong.wang@starfivetech.com> wrote:
>
>
>
> On 2023/5/31 2:11, Simon Glass wrote:
> > Hi Yanhong,
> >
> > Please can you send this to the mailing list and cc me?
> >
> > Regards,
> > Simon
> >
> > On Tue, 16 May 2023 at 20:48, yanhong wang
> > <yanhong.wang@starfivetech.com> wrote:
> >>
> >> Hi Simon Glass,
> >>
> >> Running the latest U-boot on the StarFive VisionFive 2 1.3B board prompts the following error message:
> >>
> >> U-Boot 2023.07-rc2-00133-g6e1852ca2c (May 17 2023 - 09:08:48 +0800)
> >>
> >> CPU: rv64imafdc_zba_zbb
> >> Model: StarFive VisionFive 2 v1.3B
> >> DRAM: 8 GiB
> >> initcall sequence 00000000fffe08b0 failed at call 000000004021611e (err=-19)
> >> ### ERROR ### Please RESET the board ###
> >>
> >> Roll back the most recent submission, and finally confirm that one of the submission affected [commit ID: 55171aedda88d12666e2a1bbc661dea1bec65337].
> >> The author of this submission is you, so I sent this email to learn more about the specific situation.
> >>
> >> Do you have any suggestions to solution this issue?
$ ./scripts/event_dump.py /tmp/b/starfive_visionfive2/u-boot
Event type Id Source location
-------------------- ------------------------------
------------------------------
EVT_DM_POST_INIT_F f:.text_rest arch/riscv/cpu/cpu.c:95
EVT_FT_FIXUP f:bootmeth_vbe_ft_fixup boot/vbe_request.c:153
EVT_FT_FIXUP f:bootmeth_vbe_simple_ft_fixup boot/vbe_simple_os.c:54
Looking at the first line, it is calling riscv_cpu_setup(). I'm not
sure why it is failing now, but didn't before, since the commit drops
the post-relocation call, leaving just the pre-relocation call. Is
this failing before or after relocation? (GD_FLAG_RELOC)
But you should look at why riscv_cpu_setup() needs to be called before
relocation and whether the CPU nodes in the devicetree need a
bootph-pre-ram property as per [1].
Regards,
Simon
[1] https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html?highlight=bootph-pre-ram#pre-relocation-support
^ permalink raw reply [flat|nested] 3+ messages in thread