riscv: dts: starfive: jh7110-common: Sync downstream U-Boot changes
Subsystems (3)
v2 cover riscv: dts: starfive: jh7110-common: Sync downstream U-Boot changes
U-Boot boot loader has adopted using the Linux dt-rebasing tree for dts with StarFive VisionFive2 board target (and related JH7110 common boards). Sync the minimum changes from jh7110-common.dtsi needed for boot so these can be dropped from U-Boot.
Changes since v1:
Do not set unused eeprom label.
Do not set no-op zero-value assigned-clock-rates, adjust commit message.
E Shattow (5):
riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
riscv: dts: starfive: jh7110-common: qspi flash setting read-delay 2
cycles max 100MHz
riscv: dts: starfive: jh7110-common: assign 24MHz clock-frequency to
uart0
riscv: dts: starfive: jh7110-common: add eeprom node to i2c5
riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by
boot loader
.../boot/dts/starfive/jh7110-common.dtsi | 28 +++++++++++++++---- 1 file changed, 23 insertions(+), 5 deletions(-)
base-commit: 708d55db3edbe2ccf88d94b5f2e2b404bc0ba37c
Signature · 7 lines
2.47.2 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v2 1/5 riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8 -3
@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>, - <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>; }; &sysgpio {
Signature · 7 lines
2.47.2 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
Quoted 18 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,
arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 10 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8
-2- <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;
I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message itself.
/Emil
Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
Quoted 34 lines · Emil Renner Berthing
Quoted 18 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 10 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8
-2- <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message itself.
Quoted 1 line
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all JH7110 CPU board layouts and applications.
Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
1:
https://lore.kernel.org/all/[email protected]/
What is the correct thing to do here?
-E
Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
Quoted 191 lines · E Shattow
Quoted 34 lines · Emil Renner Berthing
Quoted 18 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 10 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8
-2- <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message itself.
Quoted 1 line
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all JH7110 CPU board layouts and applications.
Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
1:
https://lore.kernel.org/all/[email protected]/What is the correct thing to do here?
-E
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B9A24C02192 for <[email protected]>; Wed, 5 Feb 2025 13:10:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GY86gaXkDRjEBAUNvogHkHuyO230wjLSabDM8v7zKQQ=; b=Un7uhhDTAT8/9N FxyCZTIeuEf9Tz2EWguoSASPTIRzVsA8OD+zansoq7n0Em+ejnESLoVicWRdNflaSCojelA6mxlZr 79fy10oRgiIKMOAb1fwJcsq+rGF8jSdXwi0a2zKjGYb4u4ZNy/uLBiIynsSH/VCYysTKQK6p7wAiC 7RYsK3WfvbZKMTBmH2vKxA7ERtfZGfNAJqRjHzBM06+ZfEDf9V2UQ3pGUdGPoTZYkQoS8smFEx47Z U3KclAiQD6NRzOmPD/VXwUGXQEpLonSaLk7kbAdo3cWww6Wyou3w4XqxHQpym6FyLsKAWWSk7d4vx ZbYQckPNKc65NmLst1TA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tffB9-00000003Lk1-2ly8; Wed, 05 Feb 2025 13:10:55 +0000 Received: from freeshell.de ([2a01:4f8:231:482b::2]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tfetw-00000003I2R-42Et for [email protected]; Wed, 05 Feb 2025 12:53:10 +0000 Received: from [192.168.2.35] (unknown [98.97.25.24]) (Authenticated sender: e) by freeshell.de (Postfix) with ESMTPSA id 7ADA8B4C01E1; Wed, 5 Feb 2025 13:53:01 +0100 (CET)Message-ID: <[email protected]>
Date: Wed, 5 Feb 2025 04:52:59 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace
syscrg clock assignments
To: Emil Renner Berthing <[email protected]>,
Conor Dooley <[email protected]>, Emil Renner Berthing <[email protected]>, Rob Herring <[email protected]>, Krzysztof Kozlowski <[email protected]>, Paul Walmsley <[email protected]>, Palmer Dabbelt <[email protected]>, Albert Ou <[email protected]>
Cc: [email protected], [email protected],
[email protected]
References: <[email protected]>
<[email protected]> <CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Q@mail.gmail.com>
Content-Language: en-US
From: E Shattow <[email protected]>
In-Reply-To: <CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Q@mail.gmail.com>
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20250205_045309_156119_468548BF
X-CRM114-Status: GOOD ( 16.14 )
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <linux-riscv.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-riscv>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-riscv/>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-riscv>,
<mailto:[email protected]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-riscv" <[email protected]>
Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.orgQuoted 34 lines · Emil Renner Berthing
Quoted 18 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 10 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8
-2- <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message itself.
Quoted 1 line
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all JH7110 CPU board layouts and applications.
Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
Quoted 4 lines
1:
https://lore.kernel.org/all/[email protected]/What is the correct thing to do here?
Please see my reply in
https://lore.kernel.org/all/ZQ2PR01MB130736F5C893337606FD6937E6F1A@ZQ2PR01MB1307.CHNPR01.prod.partner.outlook.cn/
Thanks.
Best regards,
Hal
Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
Quoted 197 lines · Hal Feng
Quoted 191 lines · E Shattow
Quoted 34 lines · Emil Renner Berthing
Quoted 18 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 10 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8
-2- <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message itself.
Quoted 1 line
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all JH7110 CPU board layouts and applications.
Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
1:
https://lore.kernel.org/all/[email protected]/What is the correct thing to do here?
-E
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B9A24C02192 for <[email protected]>; Wed, 5 Feb 2025 13:10:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GY86gaXkDRjEBAUNvogHkHuyO230wjLSabDM8v7zKQQ=; b=Un7uhhDTAT8/9N FxyCZTIeuEf9Tz2EWguoSASPTIRzVsA8OD+zansoq7n0Em+ejnESLoVicWRdNflaSCojelA6mxlZr 79fy10oRgiIKMOAb1fwJcsq+rGF8jSdXwi0a2zKjGYb4u4ZNy/uLBiIynsSH/VCYysTKQK6p7wAiC 7RYsK3WfvbZKMTBmH2vKxA7ERtfZGfNAJqRjHzBM06+ZfEDf9V2UQ3pGUdGPoTZYkQoS8smFEx47Z U3KclAiQD6NRzOmPD/VXwUGXQEpLonSaLk7kbAdo3cWww6Wyou3w4XqxHQpym6FyLsKAWWSk7d4vx ZbYQckPNKc65NmLst1TA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tffB9-00000003Lk1-2ly8; Wed, 05 Feb 2025 13:10:55 +0000 Received: from freeshell.de ([2a01:4f8:231:482b::2]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tfetw-00000003I2R-42Et for [email protected]; Wed, 05 Feb 2025 12:53:10 +0000 Received: from [192.168.2.35] (unknown [98.97.25.24]) (Authenticated sender: e) by freeshell.de (Postfix) with ESMTPSA id 7ADA8B4C01E1; Wed, 5 Feb 2025 13:53:01 +0100 (CET)Message-ID: <[email protected]>
Date: Wed, 5 Feb 2025 04:52:59 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace
syscrg clock assignments
To: Emil Renner Berthing <[email protected]>,
Conor Dooley <[email protected]>, Emil Renner Berthing <[email protected]>, Rob Herring <[email protected]>, Krzysztof Kozlowski <[email protected]>, Paul Walmsley <[email protected]>, Palmer Dabbelt <[email protected]>, Albert Ou <[email protected]>
Cc: [email protected], [email protected],
[email protected]
References: <[email protected]>
<[email protected]> <CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Q@mail.gmail.com>
Content-Language: en-US
From: E Shattow <[email protected]>
In-Reply-To: <CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Q@mail.gmail.com>
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20250205_045309_156119_468548BF
X-CRM114-Status: GOOD ( 16.14 )
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <linux-riscv.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-riscv>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-riscv/>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-riscv>,
<mailto:[email protected]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-riscv" <[email protected]>
Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.orgQuoted 34 lines · Emil Renner Berthing
Quoted 18 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 10 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8
-2- <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message itself.
Quoted 1 line
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all JH7110 CPU board layouts and applications.
Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
Quoted 4 lines
1:
https://lore.kernel.org/all/[email protected]/What is the correct thing to do here?
Quoted 8 lines
Please see my reply in
https://lore.kernel.org/all/ZQ2PR01MB130736F5C893337606FD6937E6F1A@ZQ2PR01MB1307.CHNPR01.prod.partner.outlook.cn/Thanks.
Best regards,
Hal
What is the explanation to remove the (hardware default) CPU power supply 0.9V operation, and remove hardware default CPU speed?
I would think you will want jh7110.dtsi similar as follows:
cpu_opp: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-250000000 {
opp-hz = /bits/ 64 <250000000>;
opp-microvolt = <800000>;
};
opp-333000000 {
opp-hz = /bits/ 64 <333000000>;
opp-microvolt = <800000>;
};
opp-375000000 {
opp-hz = /bits/ 64 <375000000>;
opp-microvolt = <800000>;
};
opp-500000000 {
opp-hz = /bits/ 64 <500000000>;
opp-microvolt = <800000>;
};
opp-750000000 {
opp-hz = /bits/ 64 <750000000>;
opp-microvolt = <800000>;
};
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <900000>;
};
opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1040000>;
};
};I guess at the voltages here, you will have to provide a correction about what is realistic.
Board makers are designing their board layout with opp-1000000000 default voltage with default clock frequency and not opp-1500000000 on an increased voltage and maximum clock speed yes?
We should not exceed the hardware default CPU voltage (and clock frequency) for all boards without some very good reason, and I do not accept "because more voltage and higher frequency is faster" to be a reason to do this.
Hal, you have not explained why it is *necessary* to have this non-default voltage and clock frequency table for all boards. I know that using a JH7110 board that allows 1.5GHz operation results in thermal over-temperature and shutdown, where it then does no work at all and is not useful to me. I do accept that you want 1.5GHz operation, for a specific board that is no problem with me because I do not have that board to test if it is any problem; I have to trust that you have done this testing, then.
Summary of my thoughts are:
1. Yes to support for lower and higher core voltage and clock frequency
2. No to imposing non-default hardware profiles on all boards, unless there is some actual reason why it is strictly necessary (thermal performance testing, operational stability, power savings, ...)
Question follow-up:
1. Can we restore 1GHz operation ? I ask if there is a property or strategy here to force 1GHz maximum operation unless the user decides for exceeding the hardware default 0.9V ?
-E
RE: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
Quoted 275 lines · E Shattow
Quoted 21 lines · Hal Feng
Quoted 20 lines · E Shattow
Quoted 17 lines · Emil Renner Berthing
Quoted 16 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0@@ -359,9 +359,14 @@ spi_dev0: spi@0 { };Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-3&syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>, - <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>;Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 4 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0+ assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message
itself.
Quoted 29 lines
Quoted 29 lines
Quoted 2 lines
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all
JH7110 CPU board layouts and applications.Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
1:
https://lore.kernel.org/all/20240603020607.25122-1-xingyu.wu@starfive
tech.com/What is the correct thing to do here?
-E
Quoted 7 lines
Quoted 7 lines
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
<linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead. org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from bombadil.infradead.org (bombadil.infradead.org[198.137.202.133])
Quoted 1 line
Quoted 1 line
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384(256/256 bits))
Quoted 7 lines
Quoted 7 lines
(No client certificate requested)
by smtp.lore.kernel.org (Postfix) with ESMTPS id B9A24C02192 for <[email protected]>; Wed, 5 Feb 2025 13:10:59
+0000 (UTC)DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:
Quoted 1 line
Quoted 1 line
List-Archive:List-Unsubscribe:List-Id:In-Reply-
To:From:References:Cc:To:
Quoted 1 line
Quoted 1 line
Subject:MIME-Version:Date:Message-ID:Reply-To:Content-
ID:Content-Description:
Quoted 1 line
Quoted 1 line
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-
Cc Resent-Message-ID:Quoted 1 line
Quoted 1 line
List-Owner;bh=GY86gaXkDRjEBAUNvogHkHuyO230wjLSabDM8v7zKQQ=;
b=Un7uhhDTAT8/9NQuoted 1 line
Quoted 1 line
FxyCZTIeuEf9Tz2EWguoSASPTIRzVsA8OD+zansoq7n0Em+ejnESLoVic
WRdNflaSCojelA6mxlZrQuoted 1 line
Quoted 1 line
79fy10oRgiIKMOAb1fwJcsq+rGF8jSdXwi0a2zKjGYb4u4ZNy/uLBiIynsS
H/VCYysTKQK6p7wAiCQuoted 1 line
Quoted 1 line
7RYsK3WfvbZKMTBmH2vKxA7ERtfZGfNAJqRjHzBM06+ZfEDf9V2UQ3p
GUdGPoTZYkQoS8smFEx47ZQuoted 1 line
Quoted 1 line
U3KclAiQD6NRzOmPD/VXwUGXQEpLonSaLk7kbAdo3cWww6Wyou3
w4XqxHQpym6FyLsKAWWSk7d4vxQuoted 23 lines
Quoted 23 lines
ZbYQckPNKc65NmLst1TA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tffB9-00000003Lk1-2ly8; Wed, 05 Feb 2025 13:10:55 +0000 Received: from freeshell.de ([2a01:4f8:231:482b::2]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tfetw-00000003I2R-42Et for [email protected]; Wed, 05 Feb 2025 12:53:10 +0000 Received: from [192.168.2.35] (unknown [98.97.25.24]) (Authenticated sender: e) by freeshell.de (Postfix) with ESMTPSA id 7ADA8B4C01E1; Wed, 5 Feb 2025 13:53:01 +0100 (CET)Message-ID: <[email protected]>
Date: Wed, 5 Feb 2025 04:52:59 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common:
replace syscrg clock assignments
To: Emil Renner Berthing <[email protected]>,
Conor Dooley <[email protected]>, Emil Renner Berthing
<[email protected]>, Rob Herring <[email protected]>, KrzysztofQuoted 8 lines
Quoted 8 lines
Kozlowski <[email protected]>, Paul Walmsley <[email protected]>, Palmer Dabbelt <[email protected]>, Albert Ou <[email protected]>
Cc: [email protected], [email protected], [email protected]
References: <[email protected]>
<[email protected]> <CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Quoted 4 lines
Quoted 4 lines
Content-Language: en-US
From: E Shattow <[email protected]> In-Reply-To:
<CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Quoted 45 lines
Quoted 45 lines
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20250205_045309_156119_468548BF
X-CRM114-Status: GOOD ( 16.14 )
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <linux-riscv.lists.infradead.org> List-Unsubscribe:
<http://lists.infradead.org/mailman/options/linux-riscv>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-riscv/>
List-Post: <mailto:[email protected]> List-Help:
<mailto:[email protected]?subject=help> List-Subscribe:
<http://lists.infradead.org/mailman/listinfo/linux-riscv>,
<mailto:[email protected]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-riscv" <[email protected]> Errors-To:
linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.o rgQuoted 17 lines · Emil Renner Berthing
Quoted 16 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0@@ -359,9 +359,14 @@ spi_dev0: spi@0 { };Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-3&syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>, - <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>;Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 4 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0+ assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message
itself.
Quoted 21 lines
Quoted 21 lines
Quoted 2 lines
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all
JH7110 CPU board layouts and applications.Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
Quoted 8 lines
Quoted 5 lines
1:
https://lore.kernel.org/all/20240603020607.25122-1-xingyu.wu@starfive
tech.com/What is the correct thing to do here?
Please see my reply in
https://lore.kernel.org/all/ZQ2PR01MB130736F5C893337606FD6937E6F1A@
ZQ2Quoted 7 lines
PR01MB1307.CHNPR01.prod.partner.outlook.cn/
Thanks.
Best regards,
HalWhat is the explanation to remove the (hardware default) CPU power supply 0.9V operation, and remove hardware default CPU speed?
I would think you will want
jh7110.dtsisimilar as follows:cpu_opp: opp-table-0 { compatible = "operating-points-v2"; opp-shared; opp-250000000 { opp-hz = /bits/ 64 <250000000>; opp-microvolt = <800000>; }; opp-333000000 { opp-hz = /bits/ 64 <333000000>; opp-microvolt = <800000>; }; opp-375000000 { opp-hz = /bits/ 64 <375000000>; opp-microvolt = <800000>; }; opp-500000000 { opp-hz = /bits/ 64 <500000000>; opp-microvolt = <800000>; }; opp-750000000 { opp-hz = /bits/ 64 <750000000>; opp-microvolt = <800000>; }; opp-1000000000 {
Quoted 8 lines
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <900000>;
};
opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1040000>;
};
};This method doesn't make sense, because the division factor is an integer and changing clock pll0 frequently may cause errors.
Quoted 7 lines
I guess at the voltages here, you will have to provide a correction about what is realistic.
Board makers are designing their board layout with opp-1000000000 default voltage with default clock frequency and not opp-1500000000 on an increased voltage and maximum clock speed yes?
No, default CPU supply voltage or frequency were never designed for the board and JH7110 SoC. The default voltage I said in [1] means the default output voltage of PMIC AXP15060. When the board is powered up, the CPU supply which comes from PMIC is 0.9V, so the CPU can just run at 1.0GHz or lower. After that, the board can run at other frequency if the CPU supply voltage, pll0 clock frequency, division factor are set correctly. 1.5GHz is a stable frequency to run. We had done a lot of test at this frequency. Actually, JH7110 can even run at 1.75GHz, but that is not stable.
Quoted 10 lines
We should not exceed the hardware default CPU voltage (and clock frequency) for all boards without some very good reason, and I do not accept "because more voltage and higher frequency is faster" to be a reason to do this.
Hal, you have not explained why it is *necessary* to have this non-default voltage and clock frequency table for all boards. I know that using a JH7110 board that allows 1.5GHz operation results in thermal over-temperature and shutdown, where it then does no work at all and is not useful to me. I do
Really? Could you please give more detail to us? Thanks for your feedback. We had tested 1.5GHz under large loads many times and running at 1.5GHz is the requirement from some developers, so we upstreamed it before.
Quoted 11 lines
accept that you want 1.5GHz operation, for a specific board that is no problem with me because I do not have that board to test if it is any problem; I have to trust that you have done this testing, then.
Summary of my thoughts are:
1. Yes to support for lower and higher core voltage and clock frequency
2. No to imposing non-default hardware profiles on all boards, unless there is some actual reason why it is strictly necessary (thermal performance testing, operational stability, power savings, ...)
If some boards can't run at 1.5GHz, we can move node opp-table-0 to the board device tree from jh7110.dtsi. Then each board can set its own CPU frequency.
Best regards,
Hal
Quoted 8 lines
Question follow-up:
1. Can we restore 1GHz operation ? I ask if there is a property or strategy here to force 1GHz maximum operation unless the user decides for exceeding the hardware default 0.9V ?
-E
Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
Quoted 332 lines · Hal Feng
Quoted 275 lines · E Shattow
Quoted 21 lines · Hal Feng
Quoted 20 lines · E Shattow
Quoted 17 lines · Emil Renner Berthing
Quoted 16 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0@@ -359,9 +359,14 @@ spi_dev0: spi@0 { };Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-3&syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>, - <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>;Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 4 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0+ assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message
itself.
Quoted 29 lines
Quoted 29 lines
Quoted 2 lines
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all
JH7110 CPU board layouts and applications.Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
1:
https://lore.kernel.org/all/20240603020607.25122-1-xingyu.wu@starfive
tech.com/What is the correct thing to do here?
-E
Quoted 7 lines
Quoted 7 lines
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
<linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead. org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from bombadil.infradead.org (bombadil.infradead.org[198.137.202.133])
Quoted 1 line
Quoted 1 line
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384(256/256 bits))
Quoted 7 lines
Quoted 7 lines
(No client certificate requested)
by smtp.lore.kernel.org (Postfix) with ESMTPS id B9A24C02192 for <[email protected]>; Wed, 5 Feb 2025 13:10:59
+0000 (UTC)DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post:
Quoted 1 line
Quoted 1 line
List-Archive:List-Unsubscribe:List-Id:In-Reply-
To:From:References:Cc:To:
Quoted 1 line
Quoted 1 line
Subject:MIME-Version:Date:Message-ID:Reply-To:Content-
ID:Content-Description:
Quoted 1 line
Quoted 1 line
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-
Cc Resent-Message-ID:Quoted 1 line
Quoted 1 line
List-Owner;bh=GY86gaXkDRjEBAUNvogHkHuyO230wjLSabDM8v7zKQQ=;
b=Un7uhhDTAT8/9NQuoted 1 line
Quoted 1 line
FxyCZTIeuEf9Tz2EWguoSASPTIRzVsA8OD+zansoq7n0Em+ejnESLoVic
WRdNflaSCojelA6mxlZrQuoted 1 line
Quoted 1 line
79fy10oRgiIKMOAb1fwJcsq+rGF8jSdXwi0a2zKjGYb4u4ZNy/uLBiIynsS
H/VCYysTKQK6p7wAiCQuoted 1 line
Quoted 1 line
7RYsK3WfvbZKMTBmH2vKxA7ERtfZGfNAJqRjHzBM06+ZfEDf9V2UQ3p
GUdGPoTZYkQoS8smFEx47ZQuoted 1 line
Quoted 1 line
U3KclAiQD6NRzOmPD/VXwUGXQEpLonSaLk7kbAdo3cWww6Wyou3
w4XqxHQpym6FyLsKAWWSk7d4vxQuoted 23 lines
Quoted 23 lines
ZbYQckPNKc65NmLst1TA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tffB9-00000003Lk1-2ly8; Wed, 05 Feb 2025 13:10:55 +0000 Received: from freeshell.de ([2a01:4f8:231:482b::2]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tfetw-00000003I2R-42Et for [email protected]; Wed, 05 Feb 2025 12:53:10 +0000 Received: from [192.168.2.35] (unknown [98.97.25.24]) (Authenticated sender: e) by freeshell.de (Postfix) with ESMTPSA id 7ADA8B4C01E1; Wed, 5 Feb 2025 13:53:01 +0100 (CET)Message-ID: <[email protected]>
Date: Wed, 5 Feb 2025 04:52:59 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common:
replace syscrg clock assignments
To: Emil Renner Berthing <[email protected]>,
Conor Dooley <[email protected]>, Emil Renner Berthing
<[email protected]>, Rob Herring <[email protected]>, KrzysztofQuoted 8 lines
Quoted 8 lines
Kozlowski <[email protected]>, Paul Walmsley <[email protected]>, Palmer Dabbelt <[email protected]>, Albert Ou <[email protected]>
Cc: [email protected], [email protected], [email protected]
References: <[email protected]>
<[email protected]> <CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Quoted 4 lines
Quoted 4 lines
Content-Language: en-US
From: E Shattow <[email protected]> In-Reply-To:
<CAJM55Z-M9MsJAtPi-t=_tNV3oG_kdDiS6H=H3koJwTEwB8GJ-Quoted 45 lines
Quoted 45 lines
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20250205_045309_156119_468548BF
X-CRM114-Status: GOOD ( 16.14 )
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: <linux-riscv.lists.infradead.org> List-Unsubscribe:
<http://lists.infradead.org/mailman/options/linux-riscv>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-riscv/>
List-Post: <mailto:[email protected]> List-Help:
<mailto:[email protected]?subject=help> List-Subscribe:
<http://lists.infradead.org/mailman/listinfo/linux-riscv>,
<mailto:[email protected]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-riscv" <[email protected]> Errors-To:
linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.o rgQuoted 17 lines · Emil Renner Berthing
Quoted 16 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0@@ -359,9 +359,14 @@ spi_dev0: spi@0 { };Quoted 16 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-3&syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>, - <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>;Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 4 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0+ assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message
itself.
Quoted 21 lines
Quoted 21 lines
Quoted 2 lines
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all
JH7110 CPU board layouts and applications.Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
Quoted 8 lines
Quoted 5 lines
1:
https://lore.kernel.org/all/20240603020607.25122-1-xingyu.wu@starfive
tech.com/What is the correct thing to do here?
Please see my reply in
https://lore.kernel.org/all/ZQ2PR01MB130736F5C893337606FD6937E6F1A@
ZQ2Quoted 7 lines
PR01MB1307.CHNPR01.prod.partner.outlook.cn/
Thanks.
Best regards,
HalWhat is the explanation to remove the (hardware default) CPU power supply 0.9V operation, and remove hardware default CPU speed?
I would think you will want
jh7110.dtsisimilar as follows:cpu_opp: opp-table-0 { compatible = "operating-points-v2"; opp-shared; opp-250000000 { opp-hz = /bits/ 64 <250000000>; opp-microvolt = <800000>; }; opp-333000000 { opp-hz = /bits/ 64 <333000000>; opp-microvolt = <800000>; }; opp-375000000 { opp-hz = /bits/ 64 <375000000>; opp-microvolt = <800000>; }; opp-500000000 { opp-hz = /bits/ 64 <500000000>; opp-microvolt = <800000>; }; opp-750000000 { opp-hz = /bits/ 64 <750000000>; opp-microvolt = <800000>; }; opp-1000000000 {Quoted 8 lines
opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <900000>; }; opp-1500000000 { opp-hz = /bits/ 64 <1500000000>; opp-microvolt = <1040000>; }; };This method doesn't make sense, because the division factor is an integer and changing clock pll0 frequently may cause errors.
Quoted 7 lines
I guess at the voltages here, you will have to provide a correction about what is realistic.
Board makers are designing their board layout with opp-1000000000 default voltage with default clock frequency and not opp-1500000000 on an increased voltage and maximum clock speed yes?
No, default CPU supply voltage or frequency were never designed for the board and JH7110 SoC. The default voltage I said in [1] means the default output voltage of PMIC AXP15060. When the board is powered up, the CPU supply which comes from PMIC is 0.9V, so the CPU can just run at 1.0GHz or lower. After that, the board can run at other frequency if the CPU supply voltage, pll0 clock frequency, division factor are set correctly. 1.5GHz is a stable frequency to run. We had done a lot of test at this frequency. Actually, JH7110 can even run at 1.75GHz, but that is not stable.
Quoted 10 lines
We should not exceed the hardware default CPU voltage (and clock frequency) for all boards without some very good reason, and I do not accept "because more voltage and higher frequency is faster" to be a reason to do this.
Hal, you have not explained why it is *necessary* to have this non-default voltage and clock frequency table for all boards. I know that using a JH7110 board that allows 1.5GHz operation results in thermal over-temperature and shutdown, where it then does no work at all and is not useful to me. I do
Really? Could you please give more detail to us? Thanks for your feedback. We had tested 1.5GHz under large loads many times and running at 1.5GHz is the requirement from some developers, so we upstreamed it before.
Quoted 11 lines
accept that you want 1.5GHz operation, for a specific board that is no problem with me because I do not have that board to test if it is any problem; I have to trust that you have done this testing, then.
Summary of my thoughts are:
1. Yes to support for lower and higher core voltage and clock frequency
2. No to imposing non-default hardware profiles on all boards, unless there is some actual reason why it is strictly necessary (thermal performance testing, operational stability, power savings, ...)
Quoted 15 lines
If some boards can't run at 1.5GHz, we can move node opp-table-0 to the board device tree from
jh7110.dtsi. Then each board can set its own CPU frequency.Best regards,
HalQuoted 8 lines
Question follow-up:
1. Can we restore 1GHz operation ? I ask if there is a property or strategy here to force 1GHz maximum operation unless the user decides for exceeding the hardware default 0.9V ?
-E
I apologize Hal, this topic is more in-depth than my basic understanding about hardware design. Can we make this so we have six runtime frequencies around the manufacturer StarFive suggestion of 1.5GHz?:
250MHz
500MHz
750MHz
1GHz
1.25GHz
1.5GHz
1.75GHz (seven? you say this doesn't work well though.)
Is 250MHz stable?
I hear you say that it is an integer division, okay. How about a multiplier up from 250MHz though? That is a bad suggestion?
If you can be kind and explain to me - (I am dumb about this topic but I do want to learn) - and explain what is the limitation why this is an integer division and not a multiplier?
I've been asking other people in my peer group and none have this knowledge, so I do need help with this because your explanation is clear but lacks the basic theory which I did not learn yet (and no one I know has this knowledge either).
-E
Re: [PATCH v2 1/5] riscv: dts: starfive: jh7110-common: replace syscrg clock assignments
In reply to E ShattowQuoted 37 lines · E Shattow
Quoted 34 lines · Emil Renner Berthing
Quoted 18 lines · E Shattow
Replace syscrg assignments of clocks, clock parents, and rates with default settings for compatibility with downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -359,9 +359,14 @@ spi_dev0: spi@0 { }; &syscrg { - assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,arch/riscv/boot/dts/starfive/jh7110-common.dtsi spi_dev0: spi@0 { · line 369
Quoted 10 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +8
-2- <&pllclk JH7110_PLLCLK_PLL0_OUT>; - assigned-clock-rates = <500000000>, <1500000000>; + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_ROOT>, + <&syscrg JH7110_SYSCLK_BUS_ROOT>, + <&syscrg JH7110_SYSCLK_PERH_ROOT>, + <&syscrg JH7110_SYSCLK_QSPI_REF>; + assigned-clock-parents = <&pllclk JH7110_PLLCLK_PLL0_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&pllclk JH7110_PLLCLK_PLL2_OUT>, + <&syscrg JH7110_SYSCLK_QSPI_REF_SRC>;I think Conor asked about this too, but you still don't write why it's ok to drop the 500MHz and 1,5GHz assignments to the cpu-core and pll0 clocks respectively. You should add this to the commit message itself.
Quoted 4 lines
Quoted 1 line
/Emil
Is this a remedy for a bug in the JH7110 CPU? I'm not clear why tweaking the frequencies and increasing core voltage was ever needed.
I think it's quite common for SoCs come out of reset in a safe slow clock configuration and then expect software to set clock speeds to what the chip is really capable of.
Quoted 7 lines
This goes back to series "clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" [1].
Since [1] I have had problems with several passively cooled Milk-V Mars CM Lite systems powering off due to thermal limits. My experience then is that the specialized 1.5GHz operation is not appropriate for all JH7110 CPU board layouts and applications.
If that's the case then maybe only lower the clock speed on the Mars CM Lite boards.
Quoted 10 lines
Hal says I failed to get these assignments in Linux to work in U-Boot because U-Boot doesn't have driver support to increase CPU voltage, and Hal offering to add this to a driver in U-Boot... but that's the wrong way around in my opinion, unless there's some defect in the JH7110 CPU that it won't run reliably with hardware defaults.
1:
https://lore.kernel.org/all/[email protected]/What is the correct thing to do here?
I really don't think slowing down all the boards because of missing code in U-Boot is the right solution, but Hal also answered in the old thread.
/Emil
PATCH v2 2/5 riscv: dts: starfive: jh7110-common: qspi flash setting read-delay 2 cycles max 100MHz
In reply to E ShattowSync qspi flash setting to read-delay=2 and spi-max-frequency 100MHz for better compatibility with operating system and downstream boot loader SPL secondary program loader.
--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +2 -2
@@ -317,8 +317,8 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; - cdns,read-delay = <5>; - spi-max-frequency = <12000000>; + cdns,read-delay = <2>; + spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>; cdns,tsd2d-ns = <1>; cdns,tchsh-ns = <1>;
Signature · 1 line
2.47.2
Re: [PATCH v2 2/5] riscv: dts: starfive: jh7110-common: qspi flash setting read-delay 2 cycles max 100MHz
Quoted 3 lines · E Shattow
Sync qspi flash setting to read-delay=2 and spi-max-frequency 100MHz for better compatibility with operating system and downstream boot loader SPL secondary program loader.
Here you should be explaining why these values better describe the hardware. To me this just reads as "u-boot does this, so let's do the same" whith doesn't really explain anything.
/Emil
Quoted 25 lines
Signed-off-by E Shattow <[email protected]>Reviewed-by Hal Feng <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +2
-3@@ -317,8 +317,8 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; - cdns,read-delay = <5>; - spi-max-frequency = <12000000>; + cdns,read-delay = <2>; + spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>; cdns,tsd2d-ns = <1>; cdns,tchsh-ns = <1>; --2.47.2
Re: [PATCH v2 2/5] riscv: dts: starfive: jh7110-common: qspi flash setting read-delay 2 cycles max 100MHz
Hi Emil,
Quoted 28 lines · Emil Renner Berthing
Quoted 3 lines · E Shattow
Sync qspi flash setting to read-delay=2 and spi-max-frequency 100MHz for better compatibility with operating system and downstream boot loader SPL secondary program loader.
Here you should be explaining why these values better describe the hardware. To me this just reads as "u-boot does this, so let's do the same" whith doesn't really explain anything.
/Emil
Quoted 17 lines
Signed-off-by E Shattow <[email protected]>Reviewed-by Hal Feng <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-2@@ -317,8 +317,8 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; - cdns,read-delay = <5>; - spi-max-frequency = <12000000>;
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +2
-1+ cdns,read-delay = <2>; + spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>; cdns,tsd2d-ns = <1>; cdns,tchsh-ns = <1>; --2.47.2
That is true, there's not much to explain. It works at delay 2 and 100MHz max. I tried many delay values with the pre-existing 12MHz max, they did not work. I don't have more information than that except what I wrote about on the U-Boot mailing list [1]
The parameter training code in U-Boot when given max 100MHz has this at somewhere between delay 2 and delay 3, where delay 3 almost appears to work but there's data corruption, and delay 1 is totally non-functional. With all testing so far the delay 2 and max frequency 100MHz is reliable and also is a common occurrence in the Linux code base for similar qspi access.
My testing methodology was pretty extensive and I wrote about the result on the U-Boot mailing list, however here we're taking the success of that in U-Boot and literally just applying it to Linux where it also happens to align with some common similar assignments for other boards in the devicetree code base. It works and there's no deeper insight here.
Welcome to hear from anyone that might actually understand this hardware?
-E
Re: [PATCH v2 2/5] riscv: dts: starfive: jh7110-common: qspi flash setting read-delay 2 cycles max 100MHz
Quoted 55 lines · E Shattow
Hi Emil,
Quoted 28 lines · Emil Renner Berthing
Quoted 3 lines · E Shattow
Sync qspi flash setting to read-delay=2 and spi-max-frequency 100MHz for better compatibility with operating system and downstream boot loader SPL secondary program loader.
Here you should be explaining why these values better describe the hardware. To me this just reads as "u-boot does this, so let's do the same" whith doesn't really explain anything.
/Emil
Quoted 17 lines
Signed-off-by E Shattow <[email protected]>Reviewed-by Hal Feng <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-2@@ -317,8 +317,8 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; - cdns,read-delay = <5>; - spi-max-frequency = <12000000>;Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +2
-1+ cdns,read-delay = <2>; + spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>; cdns,tsd2d-ns = <1>; cdns,tchsh-ns = <1>; --2.47.2
That is true, there's not much to explain. It works at delay 2 and 100MHz max. I tried many delay values with the pre-existing 12MHz max, they did not work. I don't have more information than that except what I wrote about on the U-Boot mailing list [1]
The parameter training code in U-Boot when given max 100MHz has this at somewhere between delay 2 and delay 3, where delay 3 almost appears to work but there's data corruption, and delay 1 is totally non-functional. With all testing so far the delay 2 and max frequency 100MHz is reliable and also is a common occurrence in the Linux code base for similar qspi access.
Quoted 5 lines
My testing methodology was pretty extensive and I wrote about the result on the U-Boot mailing list, however here we're taking the success of that in U-Boot and literally just applying it to Linux where it also happens to align with some common similar assignments for other boards in the devicetree code base. It works and there's no deeper insight here.
This explanation is fine, but it should be in the commit message so we can go back and check why those numbers were chosen.
/Emil
PATCH v2 3/5 riscv: dts: starfive: jh7110-common: assign 24MHz clock-frequency to uart0
In reply to E ShattowSet uart0 clock-frequency for better compatibility with operating system and downstream boot loader SPL secondary program loader.
--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1 -0
@@ -635,6 +635,7 @@ GPOEN_DISABLE, }; &uart0 { + clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; status = "okay";
Signature · 1 line
2.47.2
Re: [PATCH v2 3/5] riscv: dts: starfive: jh7110-common: assign 24MHz clock-frequency to uart0
Quoted 13 lines · E Shattow
Set uart0 clock-frequency for better compatibility with operating system and downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 + 1 file changed, 1 insertion(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 641
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -635,6 +635,7 @@ GPOEN_DISABLE, }; &uart0 { + clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; status = "okay";
Best regards,
Hal
Re: [PATCH v2 3/5] riscv: dts: starfive: jh7110-common: assign 24MHz clock-frequency to uart0
In reply to E ShattowQuoted 13 lines · E Shattow
Set uart0 clock-frequency for better compatibility with operating system and downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 + 1 file changed, 1 insertion(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 641
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -635,6 +635,7 @@ GPOEN_DISABLE, }; &uart0 { + clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; status = "okay";
The uart0 node already has a reference to the uart0_core clock, so it shouldn't need this property.
/Emil
Re: [PATCH v2 3/5] riscv: dts: starfive: jh7110-common: assign 24MHz clock-frequency to uart0
Quoted 25 lines · Emil Renner Berthing
Quoted 13 lines · E Shattow
Set uart0 clock-frequency for better compatibility with operating system and downstream boot loader SPL secondary program loader.
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 + 1 file changed, 1 insertion(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 641
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -635,6 +635,7 @@ GPOEN_DISABLE, }; &uart0 { + clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; status = "okay";The uart0 node already has a reference to the
uart0_coreclock, so it shouldn't need this property.
Quoted 1 line
/Emil
Okay. I'll drop this patch from next version of the series, and asking on U-Boot mailing list what to do about it there [1]. Thanks for reviewing!
-E
1:
https://lore.kernel.org/u-boot/[email protected]/
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v2 4/5 riscv: dts: starfive: jh7110-common: add eeprom node to i2c5
In reply to E ShattowStarFive VisionFive2 and similar JH7110 boards have an eeprom compatible with Atmel 24c04. Add the node so this may be used with the at24 driver.
--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +6 -0
@@ -245,6 +245,12 @@ emmc_vdd: aldo4 { }; }; }; + + eeprom@50 { + compatible = "atmel,24c04"; + reg = <0x50>; + pagesize = <16>; + }; }; &i2c6 {
Signature · 1 line
2.47.2
Re: [PATCH v2 4/5] riscv: dts: starfive: jh7110-common: add eeprom node to i2c5
Quoted 14 lines · E Shattow
StarFive VisionFive2 and similar JH7110 boards have an eeprom compatible with Atmel 24c04. Add the node so this may be used with the at24 driver.
Signed-off-by E Shattow <[email protected]>Reviewed-by Hal Feng <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0
arch/riscv/boot/dts/starfive/jh7110-common.dtsi emmc_vdd: aldo4 { · line 253
Quoted 9 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +6
-0@@ -245,6 +245,12 @@ emmc_vdd: aldo4 { }; }; }; + + eeprom@50 { + compatible = "atmel,24c04"; + reg = <0x50>; + pagesize = <16>; + };
This looks right to me, thanks!
PATCH v2 5/5 riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
In reply to E ShattowAdd bootph-pre-ram hinting to jh7110-common.dtsi:
- i2c5_pins and i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial console
With this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110 OF_UPSTREAM board targets.
--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +6 -0
@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {
@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;
@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;
@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK,
@@ -413,6 +417,7 @@ GPI_SYS_I2C5_CLK)>, GPOEN_SYS_I2C5_DATA, GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */ + bootph-pre-ram; input-enable; input-schmitt-enable; };
@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;
Signature · 1 line
2.47.2
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 60 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleWith this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboard targets.Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +5
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK,@@ -413,6 +417,7 @@ GPI_SYS_I2C5_CLK)>, GPOEN_SYS_I2C5_DATA, GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */ + bootph-pre-ram; input-enable; input-schmitt-enable; };
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 652
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;
What about &mmc0, &mmc1, &qspi, &sysgpio, &mmc0_pins, &mmc1_pins, &i2c5? Why not add "bootph-pre-ram;" for them?
Best regards,
Hal
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 63 lines · Hal Feng
Quoted 62 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleWith this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboard targets.Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +5
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK,@@ -413,6 +417,7 @@ GPI_SYS_I2C5_CLK)>, GPOEN_SYS_I2C5_DATA, GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */ + bootph-pre-ram; input-enable; input-schmitt-enable; };@@ -641,6 +646,7 @@ GPOEN_DISABLE, };
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 652
Quoted 5 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0&uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,&mmc1_pins, &i2c5? Why not add "bootph-pre-ram;" for them?
Would they be needed before relocation of U-Boot to DRAM?
Best regards
Heinrich
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 69 lines · Heinrich Schuchardt
Quoted 59 lines · Hal Feng
Quoted 58 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleWith this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboard targets.Signed-off-by E Shattow <[email protected]>---
arch/riscv/boot/dts/starfive/jh7110-common.dtsi| 6 ++++++1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK,@@ -413,6 +417,7 @@ GPI_SYS_I2C5_CLK)>, GPOEN_SYS_I2C5_DATA, GPI_SYS_I2C5_DATA)>;bias-disable; /* external pull-up */ + bootph-pre-ram;
input-enable; input-schmitt-enable;
};arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE, };Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 652
Quoted 5 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0&uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,&mmc1_pins, &i2c5? Why not add "bootph-pre-ram;" for them?
Quoted 1 line
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in
U-Boot arch/riscv/dts/jh7110-common-u-boot.dtsi.
Best regards,
Hal
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 70 lines · Hal Feng
Quoted 69 lines · Heinrich Schuchardt
Quoted 67 lines · Hal Feng
Quoted 57 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleWith this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboard targets.Signed-off-by E Shattow <[email protected]>---
arch/riscv/boot/dts/starfive/jh7110-common.dtsi| 6 ++++++1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK,@@ -413,6 +417,7 @@ GPI_SYS_I2C5_CLK)>, GPOEN_SYS_I2C5_DATA, GPI_SYS_I2C5_DATA)>;bias-disable; /* external pull-up */ + bootph-pre-ram;
input-enable; input-schmitt-enable;
};arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 651
Quoted 6 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,&mmc1_pins, &i2c5? Why not add "bootph-pre-ram;" for them?
Quoted 8 lines
Quoted 1 line
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in
U-Bootarch/riscv/dts/jh7110-common-u-boot.dtsi.Best regards,
Hal
When I tested on Star64 there was none of those needed to boot. We can add more bootph-pre-ram as needed but I want to know how to test (because I did not see any need for these).
How do you test that these are needed?
-E
RE: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 84 lines · E Shattow
Quoted 10 lines · Hal Feng
Quoted 9 lines · Heinrich Schuchardt
Quoted 8 lines · Hal Feng
Quoted 7 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleQuoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
With this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboardtargets.
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Signed-off-by E Shattow <[email protected]>---
arch/riscv/boot/dts/starfive/jh7110-common.dtsi| 6 ++++++1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW,
GPOEN_SYS_I2C5_CLK, @@ -413,6 +417,7 @@GPI_SYS_I2C5_CLK)>,
GPOEN_SYS_I2C5_DATA,GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */
+ bootph-pre-ram;
input-enable;
input-schmitt-enable;
};arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 652
Quoted 6 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0}; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,
&mmc1_pins, &i2c5?Quoted 10 lines
Quoted 3 lines
Quoted 1 line
Why not add "bootph-pre-ram;" for them?
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in U-Boot
arch/riscv/dts/jh7110-common-u-boot.dtsi.Best regards,
Hal
Quoted 5 lines
When I tested on Star64 there was none of those needed to boot. We can add more bootph-pre-ram as needed but I want to know how to test (because I did not see any need for these).
How do you test that these are needed?
In my opinion, SPL need to read U-Boot from EMMC (mmc0) or SDcard (mmc1) or QSPI flash (qspi). Also it need to choose the correct DTB by reading EEPROM mounted on i2c5. To run mmc / i2c drivers, the pin configurations (sysgpio, mmc0/1_pins) are also needed.
Best regards,
Hal
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 90 lines · Hal Feng
Quoted 84 lines · E Shattow
Quoted 10 lines · Hal Feng
Quoted 9 lines · Heinrich Schuchardt
Quoted 8 lines · Hal Feng
Quoted 7 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleQuoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
With this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboardtargets.
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Quoted 49 lines
Signed-off-by E Shattow <[email protected]>---
arch/riscv/boot/dts/starfive/jh7110-common.dtsi| 6 ++++++1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW,
GPOEN_SYS_I2C5_CLK, @@ -413,6 +417,7 @@GPI_SYS_I2C5_CLK)>,
GPOEN_SYS_I2C5_DATA,GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */
+ bootph-pre-ram;
input-enable;
input-schmitt-enable;
};arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE,Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 652
Quoted 6 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0}; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,
&mmc1_pins, &i2c5?Quoted 10 lines
Quoted 3 lines
Quoted 1 line
Why not add "bootph-pre-ram;" for them?
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in U-Boot
arch/riscv/dts/jh7110-common-u-boot.dtsi.Best regards,
HalQuoted 5 lines
When I tested on Star64 there was none of those needed to boot. We can add more bootph-pre-ram as needed but I want to know how to test (because I did not see any need for these).
How do you test that these are needed?
Quoted 7 lines
In my opinion, SPL need to read U-Boot from EMMC (mmc0) or SDcard (mmc1) or QSPI flash (qspi). Also it need to choose the correct DTB by reading EEPROM mounted on i2c5. To run mmc / i2c drivers, the pin configurations (sysgpio, mmc0/1_pins) are also needed.
Best regards,
Hal
EMMC or SDcard are not possible to boot (via JH7110 boot ROM, distinct from QSPI boot of U-Boot and later EMMC or SDcard capability) in this way on some of the boards where transistor logic pairs GPIO0 and GPIO1 both-off or both-on. SDcard boot is officially recommended against as "not supported" by the StarFive reference documentation, and I suppose what remains is EMMC boot as valid though I have not heard of any users for this.
What is the test procedure for EMMC boot, can you explain and I will try it on the Star64?
-E
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 93 lines · E Shattow
Quoted 83 lines · Hal Feng
Quoted 83 lines · E Shattow
Quoted 10 lines · Hal Feng
Quoted 9 lines · Heinrich Schuchardt
Quoted 8 lines · Hal Feng
Quoted 7 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleQuoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
With this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboardtargets.
Quoted 47 lines
Quoted 47 lines
Quoted 47 lines
Quoted 47 lines
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK, @@ -413,6 +417,7 @@ GPI_SYS_I2C5_CLK)>,
GPOEN_SYS_I2C5_DATA,GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */
+ bootph-pre-ram;
input-enable; input-schmitt-enable;
};Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 651
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,
&mmc1_pins, &i2c5?Quoted 8 lines
Quoted 2 lines
Quoted 1 line
Why not add "bootph-pre-ram;" for them?
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in U-Boot
arch/riscv/dts/jh7110-common-u-boot.dtsi.Best regards,
HalWhen I tested on Star64 there was none of those needed to boot. We can add more bootph-pre-ram as needed but I want to know how to test (because I did not see any need for these).
Quoted 8 lines
Quoted 1 line
How do you test that these are needed?
In my opinion, SPL need to read U-Boot from EMMC (mmc0) or SDcard (mmc1) or QSPI flash (qspi). Also it need to choose the correct DTB by reading EEPROM mounted on i2c5. To run mmc / i2c drivers, the pin configurations (sysgpio, mmc0/1_pins) are also needed.
Best regards,
Hal
Quoted 7 lines
EMMC or SDcard are not possible to boot (via JH7110 boot ROM, distinct from QSPI boot of U-Boot and later EMMC or SDcard capability) in this way on some of the boards where transistor logic pairs GPIO0 and GPIO1 both-off or both-on. SDcard boot is officially recommended against as "not supported" by the StarFive reference documentation, and I suppose what remains is EMMC boot as valid though I have not heard of any users for this.
I tend to use SDcard boot on my deepcomputing fml13v01 board to test
before I flash the firmware to spi flash. I've not encountered issues. I have not tried eMMC but I assume it is the same.
Quoted 2 lines
What is the test procedure for EMMC boot, can you explain and I will try it on the Star64?
I believe this page contains enough info to use it:
https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html
Quoted 1 line
-E
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 114 lines · Maud Spierings
Quoted 98 lines · E Shattow
Quoted 94 lines · Hal Feng
Quoted 80 lines · E Shattow
Quoted 10 lines · Hal Feng
Quoted 9 lines · Heinrich Schuchardt
Quoted 8 lines · Hal Feng
Quoted 7 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleQuoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
With this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboardtargets.
Quoted 48 lines
Quoted 48 lines
Quoted 48 lines
Quoted 48 lines
Signed-off-by E Shattow <[email protected]>---
arch/riscv/boot/dts/starfive/jh7110-common.dtsi| 6 ++++++1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW,
GPOEN_SYS_I2C5_CLK, @@ -413,6 +417,7 @@GPI_SYS_I2C5_CLK)>,
GPOEN_SYS_I2C5_DATA,GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */ + bootph-pre-ram;
input-enable; input-schmitt-enable;
};Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 651
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,
&mmc1_pins, &i2c5?Quoted 8 lines
Quoted 2 lines
Quoted 1 line
Why not add "bootph-pre-ram;" for them?
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in U-Boot
arch/riscv/dts/jh7110-common-u-boot.dtsi.Best regards,
HalQuoted 6 lines
When I tested on Star64 there was none of those needed to boot. We can add
more bootph-pre-ram as needed but I want to know how to test (because I did not see any need for these).How do you test that these are needed?
In my opinion, SPL need to read U-Boot from EMMC (mmc0) or SDcard (mmc1) or
QSPI flash (qspi). Also it need to choose the correct DTB by reading EEPROM
mounted on i2c5. To run mmc / i2c drivers, the pin configurations (sysgpio, mmc0/1_pins)
are also needed.Quoted 2 lines
Best regards,
HalQuoted 7 lines
EMMC or SDcard are not possible to boot (via JH7110 boot ROM, distinct from QSPI boot of U-Boot and later EMMC or SDcard capability) in this way on some of the boards where transistor logic pairs GPIO0 and GPIO1 both-off or both-on. SDcard boot is officially recommended against as "not supported" by the StarFive reference documentation, and I suppose what remains is EMMC boot as valid though I have not heard of any users for this.
I tend to use SDcard boot on my deepcomputing fml13v01 board to test
before I flash the firmware to spi flash. I've not encountered issues. I have not tried eMMC but I assume it is the same.
Quoted 9 lines
Quoted 2 lines
What is the test procedure for EMMC boot, can you explain and I will try it on the Star64?
I believe this page contains enough info to use it:
https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html
Quoted 1 line
-E
I followed that info to get JH7110 ZBL SD Card boot mode to load U-Boot by adding only bootph-pre-ram to the &mmc1 node. However, no success for U-Boot with JH7110 ZBL eMMC boot mode. I additionally tried the build of U-Boot as the Star64 arrives from factory, and U-Boot release 2025.01, both which are also working for JH7110 ZBL SD card boot mode and not JH7110 ZBL eMMC boot mode. Obvious to me is that page does not contain enough info to test for eMMC, and/or I am doing this wrong.
When no valid eMMC device is present:
dwmci_s: Response Timeout.
BOOT fail,Error is 0xffffffffdwmci_s: Response Timeout.
BOOT fail,Error is 0xffffffff
With the prepared eMMC storage connected there is not any output.
What is the preparation and test procedure for JH7110 ZBL eMMC boot mode?
-E
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 142 lines · E Shattow
Quoted 114 lines · Maud Spierings
Quoted 98 lines · E Shattow
Quoted 94 lines · Hal Feng
Quoted 80 lines · E Shattow
Quoted 10 lines · Hal Feng
Quoted 9 lines · Heinrich Schuchardt
Quoted 8 lines · Hal Feng
Quoted 7 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleQuoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
With this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboardtargets.
Quoted 48 lines
Quoted 48 lines
Quoted 48 lines
Quoted 48 lines
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +5
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK, @@ -413,6 +417,7 @@
GPI_SYS_I2C5_CLK)>,
GPOEN_SYS_I2C5_DATA,GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */
+ bootph-pre-ram;
input-enable; input-schmitt-enable;
};Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 651
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,
&mmc1_pins, &i2c5?Quoted 8 lines
Quoted 2 lines
Quoted 1 line
Why not add "bootph-pre-ram;" for them?
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in U-Boot
arch/riscv/dts/jh7110-common-u-boot.dtsi.Best regards,
HalQuoted 6 lines
When I tested on Star64 there was none of those needed to boot. We can add
more bootph-pre-ram as needed but I want to know how to test (because I did not see any need for these).How do you test that these are needed?
In my opinion, SPL need to read U-Boot from EMMC (mmc0) or SDcard (mmc1) or
QSPI flash (qspi). Also it need to choose the correct DTB by reading EEPROM
mounted on i2c5. To run mmc / i2c drivers, the pin configurations (sysgpio, mmc0/1_pins)
are also needed.Quoted 2 lines
Best regards,
HalQuoted 7 lines
EMMC or SDcard are not possible to boot (via JH7110 boot ROM, distinct from QSPI boot of U-Boot and later EMMC or SDcard capability) in this way on some of the boards where transistor logic pairs GPIO0 and GPIO1 both-off or both-on. SDcard boot is officially recommended against as "not supported" by the StarFive reference documentation, and I suppose what remains is EMMC boot as valid though I have not heard of any users for this.
I tend to use SDcard boot on my deepcomputing fml13v01 board to test
before I flash the firmware to spi flash. I've not encountered issues. I have not tried eMMC but I assume it is the same.
Quoted 9 lines
Quoted 2 lines
What is the test procedure for EMMC boot, can you explain and I will try it on the Star64?
I believe this page contains enough info to use it:
https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html
Quoted 1 line
-E
I followed that info to get JH7110 ZBL SD Card boot mode to load U-Boot by adding only bootph-pre-ram to the &mmc1 node. However, no success for U-Boot with JH7110 ZBL eMMC boot mode. I additionally tried the build of U-Boot as the Star64 arrives from factory, and U-Boot release 2025.01, both which are also working for JH7110 ZBL SD card boot mode and not JH7110 ZBL eMMC boot mode. Obvious to me is that page does not contain enough info to test for eMMC, and/or I am doing this wrong.
When no valid eMMC device is present:
dwmci_s: Response Timeout.
BOOT fail,Error is0xffffffffdwmci_s: Response Timeout.
BOOT fail,Error is0xffffffff
Quoted 5 lines
With the prepared eMMC storage connected there is not any output.
What is the preparation and test procedure for JH7110 ZBL eMMC boot mode?
-E
Hello E,
I have tested on the StarFive VisionFive 2.
You can write U-Boot SPL to sector 0 of the eMMC and it will be booted. But with our code it will not find main U-Boot. (There seems to be a bug in our SPL code as it does not fall back to Y-modem.)
To allow adding a GPT table the vendor image therefore uses the fall-back to the backup SPL as follows.
With u-boot-spl.bin.normal.out starting at sector 4096 (byte 0x200000) add the following bytes to the GPT table:
Position 0x0000: 40 02 00 00 00 00 20 00 Position 0x0290: 40 02 00 00 00 00 20 00
The value 0x00000240 is the offset to the SPL header. The value 0x00200000 is the position of the backup SPL.
Likewise with u-boot-spl.bin.normal.out at sector 2048 (byte 0x100000) use:
Position 0x0000: 40 02 00 00 00 00 10 00 Position 0x0290: 40 02 00 00 00 00 10 00
Best regards
Heinrich
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 161 lines · Heinrich Schuchardt
Quoted 146 lines · E Shattow
Quoted 117 lines · Maud Spierings
Quoted 101 lines · E Shattow
Quoted 97 lines · Hal Feng
Quoted 82 lines · E Shattow
Quoted 10 lines · Hal Feng
Quoted 9 lines · Heinrich Schuchardt
Quoted 8 lines · Hal Feng
Quoted 7 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleQuoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
With this the U-Boot SPL secondary program loader may drop such
overrides when using dt-rebasing with JH7110OF_UPSTREAMboardtargets.
Quoted 48 lines
Quoted 48 lines
Quoted 48 lines
Quoted 48 lines
Signed-off-by E Shattow <[email protected]>---
arch/riscv/boot/dts/starfive/jh7110-common.dtsi| 6 ++++++1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +4
-0@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW,
GPOEN_SYS_I2C5_CLK, @@ -413,6 +417,7 @@GPI_SYS_I2C5_CLK)>,
GPOEN_SYS_I2C5_DATA,GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */ + bootph-pre-ram;
input-enable; input-schmitt-enable;
};Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi GPOEN_DISABLE, · line 651
Quoted 7 lines
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +1
-0@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>;What about &mmc0, &mmc1, &qspi, &sysgpio,
&mmc0_pins,
&mmc1_pins, &i2c5?Quoted 8 lines
Quoted 2 lines
Quoted 1 line
Why not add "bootph-pre-ram;" for them?
Would they be needed before relocation of U-Boot to DRAM?
Yeah, they are needed by SPL and they are set in U-Boot
arch/riscv/dts/jh7110-common-u-boot.dtsi.Best regards,
HalQuoted 7 lines
When I tested on Star64 there was none of those needed to boot. We can add
more bootph-pre-ram as needed but I want to know how to test (because I
did not see any need for these).How do you test that these are needed?
In my opinion, SPL need to read U-Boot from EMMC (mmc0) or SDcard (mmc1) or
QSPI flash (qspi). Also it need to choose the correct DTB by reading EEPROM
mounted on i2c5. To run mmc / i2c drivers, the pin configurations (sysgpio, mmc0/1_pins)
are also needed.Quoted 2 lines
Best regards,
HalQuoted 7 lines
EMMC or SDcard are not possible to boot (via JH7110 boot ROM, distinct from QSPI boot of U-Boot and later EMMC or SDcard capability) in this way on some of the boards where transistor logic pairs GPIO0 and GPIO1 both-off or both-on. SDcard boot is officially recommended against as "not supported" by the StarFive reference documentation, and I suppose what remains is EMMC boot as valid though I have not heard of any users for this.
I tend to use SDcard boot on my deepcomputing fml13v01 board to test
before I flash the firmware to spi flash. I've not encountered issues. I have not tried eMMC but I assume it is the same.
Quoted 10 lines
Quoted 3 lines
What is the test procedure for EMMC boot, can you explain and I will try
it on the Star64?I believe this page contains enough info to use it:
https://docs.u-boot.org/en/latest/board/starfive/visionfive2.html
Quoted 1 line
-E
I followed that info to get JH7110 ZBL SD Card boot mode to load U-Boot by adding only bootph-pre-ram to the &mmc1 node. However, no success for U-Boot with JH7110 ZBL eMMC boot mode. I additionally tried the build of U-Boot as the Star64 arrives from factory, and U-Boot release 2025.01, both which are also working for JH7110 ZBL SD card boot mode and not JH7110 ZBL eMMC boot mode. Obvious to me is that page does not contain enough info to test for eMMC, and/or I am doing this wrong.
When no valid eMMC device is present:
dwmci_s: Response Timeout.
BOOT fail,Error is0xffffffffdwmci_s: Response Timeout.
BOOT fail,Error is0xffffffffQuoted 5 lines
With the prepared eMMC storage connected there is not any output.
What is the preparation and test procedure for JH7110 ZBL eMMC boot mode?
-E
Hello E,
I have tested on the StarFive VisionFive 2.
You can write U-Boot SPL to sector 0 of the eMMC and it will be booted. But with our code it will not find main U-Boot. (There seems to be a bug in our SPL code as it does not fall back to Y-modem.)
Quoted 8 lines
To allow adding a GPT table the vendor image therefore uses the fall- back to the backup SPL as follows.
With u-boot-spl.bin.normal.out starting at sector 4096 (byte
0x200000) add the following bytes to the GPT table:Position
0x0000: 40 02 00 00 00 00 20 00
Position 0x0000 is within the executable code area of standard (or protective) MBR, and so GPT is not affected.
What about SD-card, does JH7110 loader code in MaskROM follow or ignore this treatment?
Quoted 1 line
Position
0x0290: 40 02 00 00 00 00 20 00
Position 0x0290 is within the "must be zeroes for the rest of the block" area of GPT header when sector size is 512 bytes. For eMMC we're working with 512byte sectors? If eMMC was written with standard MBR then what is this, just assumed to be somewhere inside the first partition? How does StarFive create distro images i.e. starfive-jh7110-202302-eMMC-minimal-desktop.img [1] for eMMC with these prepared values, is this documented officially or in the StarFive git repo history?
Quoted 5 lines
The value
0x00000240is the offset to the SPL header.The value
0x00200000is the position of the backup SPL.
Quoted 8 lines
Likewise with u-boot-spl.bin.normal.out at sector 2048 (byte
0x100000) use:Position
0x0000: 40 02 00 00 00 00 10 00
Position0x0290: 40 02 00 00 00 00 10 00Best regards
Heinrich
Thanks, Heinrich, helpful to know I was missing information. It does not answer for me the question of what the logic is in the JH7110 boot code for forming a correct test methodology. Anyway I learn a lot from this analysis and it is much appreciated!
Hal - I would like (and/or from anyone representing StarFive) some code listing of the JH7110 CPU MaskROM on what the SD-card and eMMC boot code
is actually doing ... if you want this supported or you should describe
the logic flow and magic numbers, offset locations, etc. expected so I can properly test for it. Aside, there is also a promise from 2023 January to release the supporting code for jh7110-recovery.bin SPL utility for writing SPI NOR flash and eMMC contents [2] that should be considered... where is the code and documentation to do what you want done?
-E
1: https://rvspace.org/en/project/VisionFive2_Debian_Wiki_202302_Release
2: https://github.com/starfive-tech/Tools/issues/2
Re: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
In reply to E ShattowQuoted 11 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial consoleWith this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboard targets.Signed-off-by E Shattow <[email protected]>
I can't find the booph-pre-ram property in any of the schemas in Documentation/devicetree/bindings. Does make ARCH=riscv <..> dtbs_check not complain about this?
/Emil
Quoted 59 lines
--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +6
-1@@ -28,6 +28,7 @@ chosen { memory@40000000 { device_type = "memory"; reg = <0x0 0x40000000 0x1 0x0>; + bootph-pre-ram; }; gpio-restart {@@ -247,6 +248,7 @@ emmc_vdd: aldo4 { }; eeprom@50 { + bootph-pre-ram; compatible = "atmel,24c04"; reg = <0x50>; pagesize = <16>;@@ -323,6 +325,7 @@ &qspi { nor_flash: flash@0 { compatible = "jedec,spi-nor"; reg = <0>; + bootph-pre-ram; cdns,read-delay = <2>; spi-max-frequency = <100000000>; cdns,tshsl-ns = <1>;@@ -405,6 +408,7 @@ GPOEN_SYS_I2C2_DATA, }; i2c5_pins: i2c5-0 { + bootph-pre-ram; i2c-pins { pinmux = <GPIOMUX(19, GPOUT_LOW, GPOEN_SYS_I2C5_CLK,@@ -413,6 +417,7 @@ GPI_SYS_I2C5_CLK)>, GPOEN_SYS_I2C5_DATA, GPI_SYS_I2C5_DATA)>; bias-disable; /* external pull-up */ + bootph-pre-ram; input-enable; input-schmitt-enable; };@@ -641,6 +646,7 @@ GPOEN_DISABLE, }; &uart0 { + bootph-pre-ram; clock-frequency = <24000000>; pinctrl-names = "default"; pinctrl-0 = <&uart0_pins>; --2.47.2
Conor Dooley
maintainerRe: [PATCH v2 5/5] riscv: dts: starfive: jh7110-common: bootph-pre-ram hinting needed by boot loader
Quoted 8 lines · Emil Renner Berthing
Quoted 7 lines · E Shattow
Add bootph-pre-ram hinting to
jh7110-common.dtsi:
-i2c5_pinsand i2c-pins subnode for connection to eeprom
- eeprom node
- qspi flash configuration subnode
- memory node
- uart0 for serial console
Quoted 8 lines
Quoted 4 lines
With this the U-Boot SPL secondary program loader may drop such overrides when using dt-rebasing with JH7110
OF_UPSTREAMboard targets.Signed-off-by E Shattow <[email protected]>I can't find the booph-pre-ram property in any of the schemas in
Documentation/devicetree/bindings. Does make ARCH=riscv <..>dtbs_checknot complain about this?
They come directly from dt-schema:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml