[PATCH v3 2/4] doc: board: ti: am64: Add boot flow diagram
Add boot flow diagram for AM64 SoC. Suggested-by: Nishanth Menon Signed-off-by: Roger Quadros --- doc/board/ti/img/boot_diagram_am64.svg | 496 + 1 file changed, 496 insertions(+) create mode 100644 doc/board/ti/img/boot_diagram_am64.svg diff --git a/doc/board/ti/img/boot_diagram_am64.svg b/doc/board/ti/img/boot_diagram_am64.svg new file mode 100644 index 00..1b9b70b493 --- /dev/null +++ b/doc/board/ti/img/boot_diagram_am64.svg @@ -0,0 +1,496 @@ + +http://www.inkscape.org/namespaces/inkscape; xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd; xmlns:xlink="http://www.w3.org/1999/xlink; xmlns="http://www.w3.org/2000/svg; xmlns:svg="http://www.w3.org/2000/svg; xmlns:xhtml="http://www.w3.org/1999/xhtml;> + + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Cortex-R + + + +Cortex-R + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + ROM + + + +ROM + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Cortex-R SPL + + + +Cortex-R SPL + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Load and auth tiboot3.bin + + + +Load and auth t... + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Load system +config data + + + +Load system... + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + DDR Config + + + +DDR Config + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Load tispl.bin + + + +Load tispl.bin + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Start Cortex-A + + + +Start Cortex-A + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Start Cortex-A + + + +Start Cort... + + + + + + + + + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Cortex-A + + + +Cortex-A + + + + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Cortex-R/M +C6x/C7x + + + +Cortex-R/M... + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Aux f/w + + + +Aux f/w + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + TIFS/DMSC + + + +TIFS/DMSC + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + ROM + + + +ROM + + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Start SYSFW + + + +Start SYSFW + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + SYSFW + + + +SYSFW + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Security Enclave Boot Processor + + + +Security Enclave Boot... + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Boot Loader +Processor + + + +Boot Loader... + + + + + + +http://www.w3.org/TR/SVG11/feature#Extensibility;> + + + Main CPU + + + +Main CPU + + + + + + +http://www.w3.org/TR/SVG11/
[PATCH v3 1/4] board: ti: am64x: Recognize AM64-HSEVM
AM64-HSEVM is AM64-GPEVM with High Security Device.
Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header".
Signed-off-by: Roger Quadros
---
board/ti/am64x/evm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 96f4e3013a..a080b2b0d2 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -18,7 +18,8 @@
#include "../common/board_detect.h"
-#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
+#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
+ board_ti_k3_is("AM64-HSEVM"))
#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
--
2.34.1
[PATCH v3 0/4] arm: dts: k3-am64: Sync DT with Linux
Hi, This series syncs AM64 DT files from Linux v6.5-rc1. Tested on AM642-EVM GP SR1.0 and AM642-SK-EVM HS-FS SR2.0. Couldn't verify Linux boot on AM642-SK-EVM so would appreciate if someone can give a Tested-by for that. Thanks! cheers, -roger Changelog: v3: - include board DT file in -r5 DT file. - move including -u-boot.dtsi file at the top of -r5 DT file. - drop duplicate nodes - document why we need to delete clock/power properties from main_timer0 v2: - Sync with v6.5-rc1 - Rebase on latest uboot/master - CPSW node cleanup - Timer node cleanup Roger Quadros (4): board: ti: am64x: Recognize AM64-HSEVM doc: board: ti: am64: Add boot flow diagram Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node" arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 arch/arm/dts/k3-am64-main.dtsi | 171 - arch/arm/dts/k3-am64-mcu.dtsi | 53 ++- arch/arm/dts/k3-am64-thermal.dtsi | 33 ++ arch/arm/dts/k3-am64.dtsi | 22 +- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 67 ++-- arch/arm/dts/k3-am642-evm.dts | 173 +++-- arch/arm/dts/k3-am642-r5-evm.dts | 202 +- arch/arm/dts/k3-am642-r5-sk.dts| 209 +-- arch/arm/dts/k3-am642-sk-u-boot.dtsi | 120 ++ arch/arm/dts/k3-am642-sk.dts | 166 ++--- arch/arm/dts/k3-am642.dtsi | 1 + board/ti/am64x/evm.c | 3 +- doc/board/ti/img/boot_diagram_am64.svg | 496 + 13 files changed, insertions(+), 605 deletions(-) create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi create mode 100644 doc/board/ti/img/boot_diagram_am64.svg -- 2.34.1
Re: [PATCH v2 0/2] arm: dts: k3-am6: Sync DT with Linux
On 01/08/2023 15:37, Nishanth Menon wrote: > On 15:27-20230731, Roger Quadros wrote: >> Hi, >> >> This series syncs AM64 DT files from Linux v6.5-rc1. >> >> NOTE: I have only boot tested this on AM64-GP-EVM. >> I would appreciate a tested-by for AM64-sk EVM. Thanks. >> >> cheers, >> -roger >> >> Changelog: >> >> v2: >> - Sync with v6.5-rc1 >> - Rebase on latest uboot/master >> - CPSW node cleanup >> - Timer node cleanup >> >> Roger Quadros (2): >> board: ti: am64x: Recognize AM64-HSEVM >> arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 >> >> arch/arm/dts/k3-am64-main.dtsi| 171 +++-- >> arch/arm/dts/k3-am64-mcu.dtsi | 53 +++- >> arch/arm/dts/k3-am64-thermal.dtsi | 33 + >> arch/arm/dts/k3-am64.dtsi | 22 +--- >> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 ++- >> arch/arm/dts/k3-am642-evm.dts | 173 -- >> arch/arm/dts/k3-am642-r5-evm.dts | 26 +++- >> arch/arm/dts/k3-am642-r5-sk.dts | 31 - >> arch/arm/dts/k3-am642-sk-u-boot.dtsi | 43 ++- >> arch/arm/dts/k3-am642-sk.dts | 166 +--- >> arch/arm/dts/k3-am642.dtsi| 1 + >> board/ti/am64x/evm.c | 3 +- >> 12 files changed, 589 insertions(+), 175 deletions(-) >> create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi >> >> -- >> 2.34.1 >> > Could you also add documentation for u-boot (doc/board/ti/) > https://github.com/nmenon/fix-k3-dt-u-boot/commit/840ad0f07d6028e3758650f6d3d0d468438910ce > Yes, and will resolve all your comments on this series. Thanks. -- cheers, -roger
Re: [PATCH v2 0/2] arm: dts: k3-am6: Sync DT with Linux
On 31/07/2023 15:27, Roger Quadros wrote: > Hi, > > This series syncs AM64 DT files from Linux v6.5-rc1. > > NOTE: I have only boot tested this on AM64-GP-EVM. > I would appreciate a tested-by for AM64-sk EVM. Thanks. Also tested on AM64-SK SR2.0 HS-FS > > cheers, > -roger > > Changelog: > > v2: > - Sync with v6.5-rc1 > - Rebase on latest uboot/master > - CPSW node cleanup > - Timer node cleanup > > Roger Quadros (2): > board: ti: am64x: Recognize AM64-HSEVM > arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 > > arch/arm/dts/k3-am64-main.dtsi| 171 +++-- > arch/arm/dts/k3-am64-mcu.dtsi | 53 +++- > arch/arm/dts/k3-am64-thermal.dtsi | 33 + > arch/arm/dts/k3-am64.dtsi | 22 +--- > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 ++- > arch/arm/dts/k3-am642-evm.dts | 173 -- > arch/arm/dts/k3-am642-r5-evm.dts | 26 +++- > arch/arm/dts/k3-am642-r5-sk.dts | 31 - > arch/arm/dts/k3-am642-sk-u-boot.dtsi | 43 ++- > arch/arm/dts/k3-am642-sk.dts | 166 +--- > arch/arm/dts/k3-am642.dtsi| 1 + > board/ti/am64x/evm.c | 3 +- > 12 files changed, 589 insertions(+), 175 deletions(-) > create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi > -- cheers, -roger
[PATCH v2 2/2] arm: dts: k3-am64: Sync DT with Linux v6.5-rc1
Sync all am642-evm/am642-sk related DT files
with Linux v6.5-rc1.
- drop timer1 in favor of main_timer0 in am64-main.dtsi.
Need to delete clock & power domain properties of
main_timer1 in -r5.dts else won't boot.
- drop cpsw3g custom DT property 'mac_efuse' and custom
DT node cpsw-phy-sel as driver picks these from standard
property/node.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am64-main.dtsi| 171 +++--
arch/arm/dts/k3-am64-mcu.dtsi | 53 +++-
arch/arm/dts/k3-am64-thermal.dtsi | 33 +
arch/arm/dts/k3-am64.dtsi | 22 +---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 ++-
arch/arm/dts/k3-am642-evm.dts | 173 --
arch/arm/dts/k3-am642-r5-evm.dts | 26 +++-
arch/arm/dts/k3-am642-r5-sk.dts | 31 -
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 43 ++-
arch/arm/dts/k3-am642-sk.dts | 166 +---
arch/arm/dts/k3-am642.dtsi| 1 +
11 files changed, 587 insertions(+), 174 deletions(-)
create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 5e8036f32d..1664d9f024 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -228,12 +228,161 @@
};
};
+ main_timer0: timer@240 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x240 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 36 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 36 1>;
+ assigned-clock-parents = <_clks 36 2>;
+ power-domains = <_pds 36 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer1: timer@241 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x241 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 37 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 37 1>;
+ assigned-clock-parents = <_clks 37 2>;
+ power-domains = <_pds 37 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer2: timer@242 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x242 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 38 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 38 1>;
+ assigned-clock-parents = <_clks 38 2>;
+ power-domains = <_pds 38 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer3: timer@243 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x243 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 39 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 39 1>;
+ assigned-clock-parents = <_clks 39 2>;
+ power-domains = <_pds 39 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer4: timer@244 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x244 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 40 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 40 1>;
+ assigned-clock-parents = <_clks 40 2>;
+ power-domains = <_pds 40 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer5: timer@245 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x245 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 41 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 41 1>;
+ assigned-clock-parents = <_clks 41 2>;
+ power-domains = <_pds 41 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer6: timer@246 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x246 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 42 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 42 1>;
+ assigned-clock-parents = <_clks 42 2>;
+ power-domains = <_pds 42 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer7: timer@247 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x2470
[PATCH v2 1/2] board: ti: am64x: Recognize AM64-HSEVM
AM64-HSEVM is AM64-GPEVM with High Security Device.
Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header".
Signed-off-by: Roger Quadros
---
board/ti/am64x/evm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 96f4e3013a..a080b2b0d2 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -18,7 +18,8 @@
#include "../common/board_detect.h"
-#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
+#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
+ board_ti_k3_is("AM64-HSEVM"))
#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
--
2.34.1
[PATCH v2 0/2] arm: dts: k3-am6: Sync DT with Linux
Hi, This series syncs AM64 DT files from Linux v6.5-rc1. NOTE: I have only boot tested this on AM64-GP-EVM. I would appreciate a tested-by for AM64-sk EVM. Thanks. cheers, -roger Changelog: v2: - Sync with v6.5-rc1 - Rebase on latest uboot/master - CPSW node cleanup - Timer node cleanup Roger Quadros (2): board: ti: am64x: Recognize AM64-HSEVM arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 arch/arm/dts/k3-am64-main.dtsi| 171 +++-- arch/arm/dts/k3-am64-mcu.dtsi | 53 +++- arch/arm/dts/k3-am64-thermal.dtsi | 33 + arch/arm/dts/k3-am64.dtsi | 22 +--- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 ++- arch/arm/dts/k3-am642-evm.dts | 173 -- arch/arm/dts/k3-am642-r5-evm.dts | 26 +++- arch/arm/dts/k3-am642-r5-sk.dts | 31 - arch/arm/dts/k3-am642-sk-u-boot.dtsi | 43 ++- arch/arm/dts/k3-am642-sk.dts | 166 +--- arch/arm/dts/k3-am642.dtsi| 1 + board/ti/am64x/evm.c | 3 +- 12 files changed, 589 insertions(+), 175 deletions(-) create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi -- 2.34.1
Re: [PATCH V2 0/3] arm: dts: Sync k3-am62 with upstream
On 26/07/2023 18:10, Nishanth Menon wrote: > I have picked up part of Sjoerd's series[1] to keep it constrained just > to dts sync at this point rather than adding newer functionality on top. > > You can find the full series in [2]. > > Attempting am625 as a start of a series of clean ups for device tree for > u-boot, but will love to get any review comments to improve this series > up. > > This series also depends on: > > https://lore.kernel.org/r/20230724-ti-mdio-pinmux-v4-1-18541f976...@kernel.org > https://lore.kernel.org/r/20230722193151.117345-2-rog...@kernel.org > https://lore.kernel.org/r/20230722193151.117345-3-rog...@kernel.org > > baseline: > master 197aa22e6506 Merge branch 'master' of > git://git.denx.de/u-boot-coldfire > > Boot log: https://gist.github.com/nmenon/a1705c385189c2367d8cad1debcf8155 > > Changes since V1: > * Added dependency on CPSW cleanup patches. > * Dropped the hack done in u-boot.dtsi to use kernel dts as is for cpsw > > V1: https://lore.kernel.org/all/20230725125856.1807742-1...@ti.com/ > > Changes since RFC: > * dependencies are all merged on master now. > * No new dependencies in this series, though the issue with uboot dtb > not working for kernel is not a regression, it should probably be > handled as a fixup part of RC Cycle. > > RFC: https://lore.kernel.org/u-boot/20230713072019.3153871-1...@ti.com/ > > Nishanth Menon (1): > arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1 > > Sjoerd Simons (2): > omap: timer: add ti,am654-timer compatibility > arm: mach-k3: am62: Add timer0 id to the dev list > > arch/arm/dts/k3-am62-main.dtsi | 389 +++-- > arch/arm/dts/k3-am62-mcu.dtsi| 66 + > arch/arm/dts/k3-am62-thermal.dtsi| 33 +++ > arch/arm/dts/k3-am62-wakeup.dtsi | 33 ++- > arch/arm/dts/k3-am62.dtsi| 11 +- > arch/arm/dts/k3-am625-r5-sk.dts | 92 +- > arch/arm/dts/k3-am625-sk-u-boot.dtsi | 33 +-- > arch/arm/dts/k3-am625-sk.dts | 286 ++- > arch/arm/dts/k3-am625.dtsi | 54 +++- > arch/arm/dts/k3-am62x-sk-common.dtsi | 412 +++ > arch/arm/dts/k3-pinctrl.h| 53 > arch/arm/mach-k3/am62x/dev-data.c| 1 + > drivers/timer/omap-timer.c | 1 + > 13 files changed, 1066 insertions(+), 398 deletions(-) > create mode 100644 arch/arm/dts/k3-am62-thermal.dtsi > create mode 100644 arch/arm/dts/k3-am62x-sk-common.dtsi > create mode 100644 arch/arm/dts/k3-pinctrl.h > > [1] https://lore.kernel.org/all/20230406185542.1179073-1-sjo...@collabora.com/ > [2] > https://github.com/nmenon/fix-k3-dt-u-boot/commits/fdt-fixup-s1-am625-rev3.2 For this series: Reviewed-by: Roger Quadros
Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
Ravi, On 27/07/2023 08:36, Ravi Gunasekaran wrote: > > > On 7/26/23 6:22 PM, Nishanth Menon wrote: >> On 14:44-20230726, Ravi Gunasekaran wrote: >> [...] >>> If it is the former, then would a duplicate mdio node help keep the changes >>> to minimum? >> >> That is worse hack. How does it make sense to have two mdio nodes to >> represent the same hardware block? we are trying to get closer to kernel >> dts support not farther away from it. >> > > I know it's not a clean hack. In k3-am625-sk-u-boot.dtsi, as a hack, > the mdio pinctrl gets added to cpsw node. So was wondering if a duplicate > mdio pinctrl node could be added in the same file. Just wanted to know if we > could skip the changes in CPSW driver posted by Maxime. > > But Maxime's approach is much cleaner. We can just sync up kernel dts and not > keeping adding the hack to every K3 SoC's DT. > > Everything is sorted now as far as DT sync is concerned. Please see [1] and its dependencies. Only thing missing is to have proper MDIO DM support for TI platforms in u-boot. Then we can get rid of the MDIO hack in am65-cpsw driver. [1] - https://lore.kernel.org/all/20230726151027.2517151-1...@ti.com/ -- cheers, -roger
Re: [PATCH 3/3] arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
Nishanth, On 25/07/2023 15:58, Nishanth Menon wrote: > Update the am62 and am625 device-trees from linux v6.3-rc5 This needed the > followin > tweaks to the u-boot specific dtsi as well: > - Switch tick-timer to the main_timer as it's now defined in the main dtsi > - Secure proxies are defined in Soc dtsis > - Drop duplicate nodes - u-boot.dtsi is includes in r5-sk, no need for > either the definitions from main.dtsi OR duplication from u-boot.dtsi > - Add mdio pins to the cpsw3g pinctrl in u-boot dtsi. It moved to a subnode > in the > linux dtsi that u-boot doesn't use/support > > Cc: Francesco Dolcini > Cc: Sjoerd Simons > Cc: Wadim Egorov > Signed-off-by: Nishanth Menon > --- > > I decided not to pick up changes from Roger and Maxime as they are'nt > regression fixes, instead the fixups can be done on top of the basic > sync. This patch will cause a regression with Networking on Linux (cpsw3g) when u-boot's DT is passed to Linux. I will suggest that you pick Maxime's [1] and my [2] series before this patch and squash the DT changes proposed there with this patch to avoid any regression. Thanks! [1] - https://lore.kernel.org/all/20230724-ti-mdio-pinmux-v4-0-18541f976...@kernel.org/ [2] - https://lore.kernel.org/all/20230722193151.117345-1-rog...@kernel.org/ -- cheers, -roger
Re: [PATCH v4 1/2] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
On 24/07/2023 16:57, Maxime Ripard wrote: > The binding represents the MDIO controller as a child device tree > node of the MAC device tree node. > > The U-Boot driver mostly ignores that child device tree node and just > hardcodes the resources it uses to support both the MAC and MDIO in a > single driver. > > However, some resources like pinctrl muxing states are thus ignored. > This has been a problem with some device trees that will put some > pinctrl states on the MDIO device tree node, like the SK-AM62 Device > Tree does. > > Let's rework the driver a bit to create a dummy MDIO driver that we will > then get during our initialization to force the core to select the right > muxing. > > Signed-off-by: Maxime Ripard Acked-by: Roger Quadros
Re: [PATCH v2 3/3] fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
Hi Maxime,
On 24/07/2023 10:44, Maxime Ripard wrote:
> Hi,
>
> Thanks for your review
>
> On Sat, Jul 22, 2023 at 11:32:37AM +0300, Roger Quadros wrote:
>> On 21/07/2023 16:07, Maxime Ripard wrote:
>>> Dropping ranges entirely doesn't work since the register offset on the
>>> MDIO device node will now be completely off, so we need to adjust it to
>>> the right value without the translation.
>>>
>>> We also need to have an empty ranges property for the reg address to be
>>> properly evaluated.
>>>
>>> Signed-off-by: Maxime Ripard
>>> ---
>>> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> index db814ed02a7e..77c9e4cb87f7 100644
>>> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> @@ -119,8 +119,8 @@
>>> };
>>>
>>> {
>>> - /delete-property/ ranges;
>>
>> cpsw-phy-sel will be broken in u-boot after you remove
>> /delete-property/ ranges.
>
> I don't think it would?
>
> If we look at k3-am62-main.dtsi, we have:
>
> ranges = <0x00 0x00 0x00 0x0800 0x00 0x20>;
>
> There's an address-cells and size-cells of 2, so it translates any child
> node address between the range 0x00-0x20 to
> 0x0800-0x820.
>
> cpsw-mdio is thus translated to 0x08000f00.
>
> Nishanth patch was dropping that ranges property, which means that
This is not right. The ranges property should persist in the am62-main.dtsi.
I think you can assume that ranges property will still be there.
> (aside from breaking the address translation if we follow the spec),
> cpsw-mdio now has the address of its reg property: 0xf00.
>
> ...
>
>> To fix this up we need to teach the am65-cpsw driver to fetch
>> the cpsw-phy-sel address from the phys property instead and drop
>> the cpsw-phy-sel child.
>>
>>> bootph-pre-ram;
>>> + ranges;
>>
>> You don't have to add ranges here. am62-main.dtsi should have it in
>> the cpsw3g node.
>
> ...
>
> So I'm adding a new 1:1 address translation for spec-compliant code to
> still work.
>
> ...
>
>>>
>>> cpsw-phy-sel@04044 {
>>> compatible = "ti,am64-phy-gmii-sel";
>>> @@ -129,6 +129,10 @@
>>> };
>>> };
>>>
>>> +_mdio {
>>> + reg = <0x0 0x8000f00 0x0 0x100>;
>>> +};
>>> +
>
> ... And I'm setting the MDIO reg property to what the address was prior
> to the ranges property removal. The driver, if it follows ranges
> properly, will get exactly the same address.
>
> Now, onto your other comments:
>
>>> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> @@ -119,8 +119,8 @@
>>> };
>>>
>>> {
>>> - /delete-property/ ranges;
>>
>> cpsw-phy-sel will be broken in u-boot after you remove
>> /delete-property/ ranges.
>>
>> To fix this up we need to teach the am65-cpsw driver to fetch
>> the cpsw-phy-sel address from the phys property instead and drop
>> the cpsw-phy-sel child.
>
> I don't know the TI platform that well, but my understanding is that the
> address used to be 0x00104044, which was probably interpreted as such by
> U-Boot if we were missing ranges. I added back ranges to comply to the
> spec but with a 1:1 mapping so that address won't change.
>
> How is it broken exactly?
>
>>> @@ -129,6 +129,10 @@
>>> };
>>> };
>>>
>>> +_mdio {
>>> + reg = <0x0 0x8000f00 0x0 0x100>;
>>> +};
>>> +
>
>> This should not be required. The u-boot driver is still hard-coding
>> the MDIO address and Linux should get the right address based on
>> address translation of the child cpsw3g_mdio node.
>
> As pointed above, Linux will not get the same address anymore (and will
> actually return -EINVAL when decoding it), so no, it's very much needed.
>
Can you please re-base your patches on top of [1].
Hopefully all the issues/questions are resolved after that? Thanks.
[1] - https://lore.kernel.org/all/20230722193151.117345-1-rog...@kernel.org/
--
cheers,
-roger
Re: [PATCH v2 1/3] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
On 24/07/2023 11:39, Maxime Ripard wrote:
> On Sat, Jul 22, 2023 at 11:25:50AM +0300, Roger Quadros wrote:
>> On 21/07/2023 16:07, Maxime Ripard wrote:
>>> The binding represents the MDIO controller as a child device tree
>>> node of the MAC device tree node.
>>>
>>> The U-Boot driver mostly ignores that child device tree node and just
>>> hardcodes the resources it uses to support both the MAC and MDIO in a
>>> single driver.
>>>
>>> However, some resources like pinctrl muxing states are thus ignored.
>>> This has been a problem with some device trees that will put some
>>> pinctrl states on the MDIO device tree node, like the SK-AM62 Device
>>> Tree does.
>>
>> You don't clearly explain the problem.
>
> I'm sorry to hear that.
>
>> I think you need to mention that there wash a hackish solution in
>> place that was duplicating MDIO pinctrl node in the CPSW node. And
>> this causes problems in Linux (if booted with u-boot's device tree)
>> due to 2 drivers (CPSW and MDIO) racing for the same MDIO pinctrl
>> resource.
>
> I mean, ultimately, this hack was due to nothing but a workaround around
> the fact that U-Boot was ignoring the MDIO child node resources. This is
> the root cause. And once fixed, that hack can go away.
>
>> Then mention how you are fixing it.
>
> I'm fixing it by "rework[ing] the driver a bit to create a dummy MDIO
> driver that we will then get during our initialization to force the core
> to select the right muxing."
>
> If that's still not a clear explanation, please provide a better one so
> that we can move forward.
This is fine thanks.
>
>> By deleting the duplicate MDIO pinctrl entry from CPSW node.
>
> Not really, no. If I was only deleting the duplitate pinctrl entry,
> U-Boot would still be broken.
>
>>> Let's rework the driver a bit to create a dummy MDIO driver that we will
>>> then get during our initialization to force the core to select the right
>>> muxing.
>>>
>>> Signed-off-by: Maxime Ripard
>>> ---
>>> drivers/net/ti/Kconfig | 1 +
>>> drivers/net/ti/am65-cpsw-nuss.c | 67
>>> +
>>> 2 files changed, 68 insertions(+)
>>>
>>> diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
>>> index e13dbc940182..08c81f79adf9 100644
>>> --- a/drivers/net/ti/Kconfig
>>> +++ b/drivers/net/ti/Kconfig
>>> @@ -41,6 +41,7 @@ endchoice
>>> config TI_AM65_CPSW_NUSS
>>> bool "TI K3 AM65x MCU CPSW Nuss Ethernet controller driver"
>>> depends on ARCH_K3
>>> + imply DM_MDIO
>>> imply MISC_INIT_R
>>> imply MISC
>>> select PHYLIB
>>> diff --git a/drivers/net/ti/am65-cpsw-nuss.c
>>> b/drivers/net/ti/am65-cpsw-nuss.c
>>> index 3069550d53c2..ac7907e7ef70 100644
>>> --- a/drivers/net/ti/am65-cpsw-nuss.c
>>> +++ b/drivers/net/ti/am65-cpsw-nuss.c
>>> @@ -15,6 +15,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -580,14 +581,69 @@ static const struct soc_attr k3_mdio_soc_data[] = {
>>> { /* sentinel */ },
>>> };
>>>
>>> +static ofnode am65_cpsw_find_mdio(ofnode parent)
>>> +{
>>> + ofnode node;
>>> +
>>> + ofnode_for_each_subnode(node, parent)
>>> + if (ofnode_device_is_compatible(node, "ti,cpsw-mdio"))
>>> + return node;
>>> +
>>> + return ofnode_null();
>>> +}
>>> +
>>> +static int am65_cpsw_mdio_setup(struct udevice *dev)
>>> +{
>>> + struct am65_cpsw_priv *priv = dev_get_priv(dev);
>>> + struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
>>> + struct udevice *mdio_dev;
>>> + ofnode mdio;
>>> + int ret;
>>> +
>>> + mdio = am65_cpsw_find_mdio(dev_ofnode(cpsw_common->dev));
>>> + if (!ofnode_valid(mdio))
>>> + return -ENODEV;
>>
>> Do we really want to treat this as an error?
>>
>> As per Linux/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
>> mdio node is not a required property/child.
>
> Ack, I'll change it.
>
>>> +
>>> + /*
>>> +* The MDIO controller is represented in the DT binding by a
>>> +* subnode of the MAC controller.
>>> +*
>>> +* Our driver largely ignores that and supports MDIO by
>>> +* hardcoding the register offsets.
>>> +*
>>> +* However, some resources (clocks, pinctrl) might be tied to
>>> +* the MDIO node, and thus ignored.
>>> +*
>>> +* Clocks are not a concern at the moment since it's shared
>>> +* between the MAC and MDIO, so the driver handles both at the
>>> +* same time.
>>
>> I think you can drop the above 3 paras and instead say
>> "We don't yet have a DM device driver for the MDIO device and so its
>> pinctrl setting will be ignored."
>
> Ok.
>
> Maxime
--
cheers,
-roger
[RFC PATCH v2 4/4] arm: dts: k3-am625-sk-u-boot.dtsi: drop cpsw-phy-sel property
This was a custom property and we don't need it anymore.
We are now using the standard property "phys" to get the
PHY port control register.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index 54fdabdb8e..d33c2fca3d 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -128,14 +128,7 @@
};
{
- /delete-property/ ranges;
bootph-pre-ram;
-
- cpsw-phy-sel@04044 {
- compatible = "ti,am64-phy-gmii-sel";
- reg = <0x0 0x00104044 0x0 0x8>;
- bootph-pre-ram;
- };
};
_port1 {
--
2.34.1
[RFC PATCH v2 3/4] arm: dts: k3-am625-sk-u-boot.dtsi: drop mac_efuse
This was a custom property and we don't need it anymore.
We are now using the standard property "ti,syscon-efuse".
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index 249155733a..54fdabdb8e 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -128,9 +128,6 @@
};
{
- reg = <0x0 0x800 0x0 0x20>,
- <0x0 0x43000200 0x0 0x8>;
- reg-names = "cpsw_nuss", "mac_efuse";
/delete-property/ ranges;
bootph-pre-ram;
--
2.34.1
[PATCH v2 2/4] net: ti: am65-cpsw-nuss: Get port mode register from standard "phys" property
Approved DT binding has the port mode register in the
"phys" property. Get it from there instead of the custom
"cpsw-phy-sel" property.
This will allow us to keep DT in sync with Linux.
Signed-off-by: Roger Quadros
---
drivers/net/ti/am65-cpsw-nuss.c | 63 +++--
1 file changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index ee46676ec8..ce52106e52 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -102,7 +102,6 @@ struct am65_cpsw_common {
fdt_addr_t cpsw_base;
fdt_addr_t mdio_base;
fdt_addr_t ale_base;
- fdt_addr_t gmii_sel;
struct clk fclk;
struct power_domain pwrdmn;
@@ -232,18 +231,37 @@ out:
#define AM65_GMII_SEL_RGMII_IDMODE BIT(4)
-static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv *priv,
- phy_interface_t phy_mode, int slave)
+static int am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv *priv,
+phy_interface_t phy_mode)
{
- struct am65_cpsw_common *common = priv->cpsw_common;
- fdt_addr_t gmii_sel = common->gmii_sel + AM65_GMII_SEL_PORT_OFFS(slave);
- u32 reg;
- u32 mode = 0;
+ struct udevice *dev = priv->dev;
+ u32 offset, reg, phandle;
bool rgmii_id = false;
+ fdt_addr_t gmii_sel;
+ u32 mode = 0;
+ ofnode node;
+ int ret;
+
+ ret = ofnode_read_u32(dev_ofnode(dev), "phys", );
+ if (ret)
+ return ret;
+
+ ret = ofnode_read_u32_index(dev_ofnode(dev), "phys", 1, );
+ if (ret)
+ return ret;
+
+ node = ofnode_get_by_phandle(phandle);
+ if (!ofnode_valid(node))
+ return -ENODEV;
+
+ gmii_sel = ofnode_get_addr(node);
+ if (gmii_sel == FDT_ADDR_T_NONE)
+ return -ENODEV;
+ gmii_sel += AM65_GMII_SEL_PORT_OFFS(offset);
reg = readl(gmii_sel);
- dev_dbg(common->dev, "old gmii_sel: %08x\n", reg);
+ dev_dbg(dev, "old gmii_sel: %08x\n", reg);
switch (phy_mode) {
case PHY_INTERFACE_MODE_RMII:
@@ -262,7 +280,7 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
break;
default:
- dev_warn(common->dev,
+ dev_warn(dev,
"Unsupported PHY mode: %u. Defaulting to MII.\n",
phy_mode);
/* fallthrough */
@@ -275,15 +293,19 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
mode |= AM65_GMII_SEL_RGMII_IDMODE;
reg = mode;
- dev_dbg(common->dev, "gmii_sel PHY mode: %u, new gmii_sel: %08x\n",
+ dev_dbg(dev, "gmii_sel PHY mode: %u, new gmii_sel: %08x\n",
phy_mode, reg);
writel(reg, gmii_sel);
reg = readl(gmii_sel);
- if (reg != mode)
- dev_err(common->dev,
+ if (reg != mode) {
+ dev_err(dev,
"gmii_sel PHY mode NOT SET!: requested: %08x, gmii_sel:
%08x\n",
mode, reg);
+ return 0;
+ }
+
+ return 0;
}
static int am65_cpsw_start(struct udevice *dev)
@@ -708,7 +730,9 @@ static int am65_cpsw_port_probe(struct udevice *dev)
if (ret)
goto out;
- am65_cpsw_gmii_sel_k3(priv, pdata->phy_interface, priv->port_id);
+ ret = am65_cpsw_gmii_sel_k3(priv, pdata->phy_interface);
+ if (ret)
+ goto out;
ret = am65_cpsw_mdio_init(dev);
if (ret)
@@ -803,19 +827,6 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
AM65_CPSW_CPSW_NU_PORT_MACSL_OFFSET;
}
- node = dev_read_subnode(dev, "cpsw-phy-sel");
- if (!ofnode_valid(node)) {
- dev_err(dev, "can't find cpsw-phy-sel\n");
- ret = -ENOENT;
- goto out;
- }
-
- cpsw_common->gmii_sel = ofnode_get_addr(node);
- if (cpsw_common->gmii_sel == FDT_ADDR_T_NONE) {
- dev_err(dev, "failed to get gmii_sel base\n");
- goto out;
- }
-
cpsw_common->bus_freq =
dev_read_u32_default(dev, "bus_freq",
AM65_CPSW_MDIO_BUS_FREQ_DEF);
--
2.34.1
[PATCH v2 1/4] net: ti: am65-cpsw-nuss: Use approved property to get efuse address
The approved DT property for MAC efuse (ROM) address is
"ti,syscon-efuse".
Use that and drop custom property "mac_efuse".
Signed-off-by: Roger Quadros
---
drivers/net/ti/Kconfig | 1 +
drivers/net/ti/am65-cpsw-nuss.c | 52 +++--
2 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index e13dbc9401..d9f1c019a8 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -43,6 +43,7 @@ config TI_AM65_CPSW_NUSS
depends on ARCH_K3
imply MISC_INIT_R
imply MISC
+ imply SYSCON
select PHYLIB
help
This driver supports TI K3 MCU CPSW Nuss Ethernet controller
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 523a4c9f91..ee46676ec8 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -21,7 +21,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
@@ -101,7 +103,6 @@ struct am65_cpsw_common {
fdt_addr_t mdio_base;
fdt_addr_t ale_base;
fdt_addr_t gmii_sel;
- fdt_addr_t mac_efuse;
struct clk fclk;
struct power_domain pwrdmn;
@@ -516,24 +517,45 @@ static void am65_cpsw_stop(struct udevice *dev)
common->started = false;
}
+static int am65_cpsw_am654_get_efuse_macid(struct udevice *dev,
+ int slave, u8 *mac_addr)
+{
+ u32 mac_lo, mac_hi, offset;
+ struct regmap *syscon;
+ int ret;
+
+ syscon = syscon_regmap_lookup_by_phandle(dev, "ti,syscon-efuse");
+ if (IS_ERR(syscon)) {
+ if (PTR_ERR(syscon) == -ENODEV)
+ return 0;
+ return PTR_ERR(syscon);
+ }
+
+ ret = dev_read_u32_index(dev, "ti,syscon-efuse", 1, );
+ if (ret)
+ return ret;
+
+ regmap_read(syscon, offset, _lo);
+ regmap_read(syscon, offset + 4, _hi);
+
+ mac_addr[0] = (mac_hi >> 8) & 0xff;
+ mac_addr[1] = mac_hi & 0xff;
+ mac_addr[2] = (mac_lo >> 24) & 0xff;
+ mac_addr[3] = (mac_lo >> 16) & 0xff;
+ mac_addr[4] = (mac_lo >> 8) & 0xff;
+ mac_addr[5] = mac_lo & 0xff;
+
+ return 0;
+}
+
static int am65_cpsw_read_rom_hwaddr(struct udevice *dev)
{
struct am65_cpsw_priv *priv = dev_get_priv(dev);
- struct am65_cpsw_common *common = priv->cpsw_common;
struct eth_pdata *pdata = dev_get_plat(dev);
- u32 mac_hi, mac_lo;
-
- if (common->mac_efuse == FDT_ADDR_T_NONE)
- return -1;
- mac_lo = readl(common->mac_efuse);
- mac_hi = readl(common->mac_efuse + 4);
- pdata->enetaddr[0] = (mac_hi >> 8) & 0xff;
- pdata->enetaddr[1] = mac_hi & 0xff;
- pdata->enetaddr[2] = (mac_lo >> 24) & 0xff;
- pdata->enetaddr[3] = (mac_lo >> 16) & 0xff;
- pdata->enetaddr[4] = (mac_lo >> 8) & 0xff;
- pdata->enetaddr[5] = mac_lo & 0xff;
+ am65_cpsw_am654_get_efuse_macid(dev,
+ priv->port_id,
+ pdata->enetaddr);
return 0;
}
@@ -710,8 +732,6 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
cpsw_common->ss_base = dev_read_addr(dev);
if (cpsw_common->ss_base == FDT_ADDR_T_NONE)
return -EINVAL;
- cpsw_common->mac_efuse = devfdt_get_addr_name(dev, "mac_efuse");
- /* no err check - optional */
ret = power_domain_get_by_index(dev, _common->pwrdmn, 0);
if (ret) {
--
2.34.1
[PATCH v2 0/4] net: ti: am65-cpsw-nuss: Drop custom properties
Hi, This series gets rid of 2 custom properties (mac_efuse and cpsw-phy-sel) that were used in u-boot for the cpsw3g node. This makes it easier for us to have u-boot DT in sync with Linux. Last 2 patches are RFC so they can come separately. i.e. squashed with DT cleanup series from Nishanth. cheers, -roger Changelog: v2: - drop enabling CONFIG_SYSCON from defconfig. Use imply in Kconfig instead. - add patch to drop cpsw-phy-sel custom DT property. Roger Quadros (4): net: ti: am65-cpsw-nuss: Use approved property to get efuse address net: ti: am65-cpsw-nuss: Get port mode register from standard "phys" property arm: dts: k3-am625-sk-u-boot.dtsi: drop mac_efuse arm: dts: k3-am625-sk-u-boot.dtsi: drop cpsw-phy-sel property arch/arm/dts/k3-am625-sk-u-boot.dtsi | 10 --- drivers/net/ti/Kconfig | 1 + drivers/net/ti/am65-cpsw-nuss.c | 115 +-- 3 files changed, 74 insertions(+), 52 deletions(-) -- 2.34.1
Re: [PATCH v2 3/3] fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On 21/07/2023 16:07, Maxime Ripard wrote:
> Dropping ranges entirely doesn't work since the register offset on the
> MDIO device node will now be completely off, so we need to adjust it to
> the right value without the translation.
>
> We also need to have an empty ranges property for the reg address to be
> properly evaluated.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> index db814ed02a7e..77c9e4cb87f7 100644
> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> @@ -119,8 +119,8 @@
> };
>
> {
> - /delete-property/ ranges;
cpsw-phy-sel will be broken in u-boot after you remove /delete-property/ ranges.
To fix this up we need to teach the am65-cpsw driver to fetch
the cpsw-phy-sel address from the phys property instead and drop
the cpsw-phy-sel child.
> bootph-pre-ram;
> + ranges;
You don't have to add ranges here. am62-main.dtsi should have it in
the cpsw3g node.
>
> cpsw-phy-sel@04044 {
> compatible = "ti,am64-phy-gmii-sel";
> @@ -129,6 +129,10 @@
> };
> };
>
> +_mdio {
> + reg = <0x0 0x8000f00 0x0 0x100>;
> +};
> +
This should not be required. The u-boot driver is still hard-coding
the MDIO address and Linux should get the right address based on
address translation of the child cpsw3g_mdio node.
> _port1 {
> bootph-pre-ram;
> };
>
--
cheers,
-roger
Re: [PATCH v2 2/3] fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On 21/07/2023 16:07, Maxime Ripard wrote: > The MDIO pinctrl nodes can't be duplicated between the child and device, > because if we ever boot Linux with our DT it will try to attach that > pinctrl configuration to both the MAC and MDIO devices, which will > result in failure to probe. > > Signed-off-by: Maxime Ripard Acked-by: Roger Quadros
Re: [PATCH v2 1/3] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
On 21/07/2023 16:07, Maxime Ripard wrote:
> The binding represents the MDIO controller as a child device tree
> node of the MAC device tree node.
>
> The U-Boot driver mostly ignores that child device tree node and just
> hardcodes the resources it uses to support both the MAC and MDIO in a
> single driver.
>
> However, some resources like pinctrl muxing states are thus ignored.
> This has been a problem with some device trees that will put some
> pinctrl states on the MDIO device tree node, like the SK-AM62 Device
> Tree does.
You don't clearly explain the problem.
I think you need to mention that there wash a hackish solution in place
that was duplicating MDIO pinctrl node in the CPSW node. And this causes
problems in Linux (if booted with u-boot's device tree)
due to 2 drivers (CPSW and MDIO) racing for the same MDIO pinctrl resource.
Then mention how you are fixing it.
By deleting the duplicate MDIO pinctrl entry from CPSW node.
>
> Let's rework the driver a bit to create a dummy MDIO driver that we will
> then get during our initialization to force the core to select the right
> muxing.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/net/ti/Kconfig | 1 +
> drivers/net/ti/am65-cpsw-nuss.c | 67
> +
> 2 files changed, 68 insertions(+)
>
> diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
> index e13dbc940182..08c81f79adf9 100644
> --- a/drivers/net/ti/Kconfig
> +++ b/drivers/net/ti/Kconfig
> @@ -41,6 +41,7 @@ endchoice
> config TI_AM65_CPSW_NUSS
> bool "TI K3 AM65x MCU CPSW Nuss Ethernet controller driver"
> depends on ARCH_K3
> + imply DM_MDIO
> imply MISC_INIT_R
> imply MISC
> select PHYLIB
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 3069550d53c2..ac7907e7ef70 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -580,14 +581,69 @@ static const struct soc_attr k3_mdio_soc_data[] = {
> { /* sentinel */ },
> };
>
> +static ofnode am65_cpsw_find_mdio(ofnode parent)
> +{
> + ofnode node;
> +
> + ofnode_for_each_subnode(node, parent)
> + if (ofnode_device_is_compatible(node, "ti,cpsw-mdio"))
> + return node;
> +
> + return ofnode_null();
> +}
> +
> +static int am65_cpsw_mdio_setup(struct udevice *dev)
> +{
> + struct am65_cpsw_priv *priv = dev_get_priv(dev);
> + struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> + struct udevice *mdio_dev;
> + ofnode mdio;
> + int ret;
> +
> + mdio = am65_cpsw_find_mdio(dev_ofnode(cpsw_common->dev));
> + if (!ofnode_valid(mdio))
> + return -ENODEV;
Do we really want to treat this as an error?
As per Linux/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
mdio node is not a required property/child.
> +
> + /*
> + * The MDIO controller is represented in the DT binding by a
> + * subnode of the MAC controller.
> + *
> + * Our driver largely ignores that and supports MDIO by
> + * hardcoding the register offsets.
> + *
> + * However, some resources (clocks, pinctrl) might be tied to
> + * the MDIO node, and thus ignored.
> + *
> + * Clocks are not a concern at the moment since it's shared
> + * between the MAC and MDIO, so the driver handles both at the
> + * same time.
I think you can drop the above 3 paras and instead say
"We don't yet have a DM device driver for the MDIO device and so its
pinctrl setting will be ignored."
> + *
> + * However, we do need to make sure the pins states tied to the
> + * MDIO node are configured properly. Fortunately, the core DM
> + * does that for use when we get a device, so we can work around
> + * that whole issue by just requesting a dummy MDIO driver to
> + * probe, and our pins will get muxed.
> + */
> + ret = uclass_get_device_by_ofnode(UCLASS_MDIO, mdio, _dev);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> static int am65_cpsw_mdio_init(struct udevice *dev)
> {
> struct am65_cpsw_priv *priv = dev_get_priv(dev);
> struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
> + int ret;
>
> if (!priv->has_phy || cpsw_common->bus)
> return 0;
>
> + ret = am65_cpsw_mdio_setup(dev);
> + if (ret)
> + return ret;
> +
> cpsw_common->bus = cpsw_mdio_init(dev->name,
> cpsw_common->mdio_base,
> cpsw_common->bus_freq,
> @@ -854,3 +910,14 @@ U_BOOT_DRIVER(am65_cpsw_nuss_port) = {
> .plat_auto = sizeof(struct eth_pdata),
> .flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_OS_PREPARE,
> };
> +
> +static const struct udevice_id
Re: [PATCH] usb: cdns3: gadget: Configure speed in udc_start
On 19/07/2023 11:59, Ravi Gunasekaran wrote: > When one of the functions does not support super speed, the composite > driver forces the gadget to high speed. But the speed is never > configured in the cdns3 gadget driver. So configure the speed > in cdns3_gadget_udc_start just like in the kernel. > > Signed-off-by: Ravi Gunasekaran Reviewed-by: Roger Quadros
Re: [PATCH 4/4] fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On 21/07/2023 10:46, Maxime Ripard wrote:
> On Thu, Jul 20, 2023 at 06:27:56PM +0300, Roger Quadros wrote:
>>
>>
>> On 20/07/2023 12:55, Maxime Ripard wrote:
>>> Dropping ranges entirely doesn't work since the register offset on the
>>> MDIO device node will now be completely off, so we need to adjust it to
>>> the right value without the translation.
>>>
>>> We also need to have an empty ranges property for the reg address to be
>>> properly evaluated.
>>>
>>> Signed-off-by: Maxime Ripard
>>> ---
>>> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> index fe1c7408a89d..2ec3fff99f32 100644
>>> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
>>> @@ -122,8 +122,8 @@
>>> reg = <0x0 0x800 0x0 0x20>,
>>> <0x0 0x43000200 0x0 0x8>;
>>> reg-names = "cpsw_nuss", "mac_efuse";
>>> - /delete-property/ ranges;
>>> bootph-pre-ram;
>>> + ranges;
>>>
>>> cpsw-phy-sel@04044 {
>>> compatible = "ti,am64-phy-gmii-sel";
>>> @@ -132,6 +132,10 @@
>>> };
>>> };
>>>
>>> +_mdio {
>>> + reg = <0x0 0x8000f00 0x0 0x100>;
>>> +};
>>> +
>>
>> Why this change?
>>
>> Linux DT has
>> cpsw3g_mdio: mdio@f00 {
>> compatible = "ti,cpsw-mdio","ti,davinci_mdio";
>> reg = <0x00 0xf00 0x00 0x100>;
>>
>> And it is a child of cpsw3g node.
>
> Right, but Linux also has on the cpsw3g node:
> ranges = <0x00 0x00 0x00 0x0800 0x00 0x20>;
>
> Which means that child node don't get a 1:1 mapping but we get a
> 0x0800 offset.
The child nodes should get 0x0800 offset because they sit inside
CPSW address range.
The addition of cpsw-phy-sel@04044 node in u-boot.dtsi is wrong
as it sits in the control module and not in CPSW address range.
I'll send out the patch to teach am65-cpsw u-boot driver to correctly
fetch the cpsw-phy-sel via syscon handle phy.
The /delete-property/ ranges can then be removed.
>
> Nishanth's patch was removing the ranges property because the
> translation is troublesome for the new cpsw-phy-sel@04044 node (I
> assume), so we need to add the offset to the mdio node so that it still
> expresses the same base address.
No, ranges property should be there else address translation will fail
for MDIO node. And that's why you don't need to change the cpsw3g_mdio
address in this patch.
--
cheers,
-roger
[RFC PATCH 2/2] arm: dts: k3-am625-sk-u-boot.dtsi: drop mac_efuse
This was a custom property and we don't need it anymore.
We are now using the standard property "ti,syscon-efuse".
Signed-off-by: Roger Quadros
---
RFC because Nishanth can squash this into his DT sync series.
The /delete-property/ ranges also needs to be deleted along with the
duplicate cpsw-phy-sel@04044. But first will need to teach
the driver to deal with the syscon node properly. phys = <_gmii_sel n>;
Will send a follow up patch for that soon.
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index 249155733a..54fdabdb8e 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -128,9 +128,6 @@
};
{
- reg = <0x0 0x800 0x0 0x20>,
- <0x0 0x43000200 0x0 0x8>;
- reg-names = "cpsw_nuss", "mac_efuse";
/delete-property/ ranges;
bootph-pre-ram;
--
2.34.1
[PATCH 1/2] net: ti: am65-cpsw-nuss: Use approved property to get efuse address
The approved DT property for MAC efuse (ROM) address is
"ti,syscon-efuse".
Use that and drop custom property "mac_efuse".
Signed-off-by: Roger Quadros
---
configs/am62x_evm_a53_defconfig | 1 +
drivers/net/ti/am65-cpsw-nuss.c | 52 +++--
2 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 7c3bc184cf..6757fe662d 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -102,3 +102,4 @@ CONFIG_SYSRESET=y
CONFIG_SPL_SYSRESET=y
CONFIG_SYSRESET_TI_SCI=y
CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_SYSCON=y
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 523a4c9f91..ee46676ec8 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -21,7 +21,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
@@ -101,7 +103,6 @@ struct am65_cpsw_common {
fdt_addr_t mdio_base;
fdt_addr_t ale_base;
fdt_addr_t gmii_sel;
- fdt_addr_t mac_efuse;
struct clk fclk;
struct power_domain pwrdmn;
@@ -516,24 +517,45 @@ static void am65_cpsw_stop(struct udevice *dev)
common->started = false;
}
+static int am65_cpsw_am654_get_efuse_macid(struct udevice *dev,
+ int slave, u8 *mac_addr)
+{
+ u32 mac_lo, mac_hi, offset;
+ struct regmap *syscon;
+ int ret;
+
+ syscon = syscon_regmap_lookup_by_phandle(dev, "ti,syscon-efuse");
+ if (IS_ERR(syscon)) {
+ if (PTR_ERR(syscon) == -ENODEV)
+ return 0;
+ return PTR_ERR(syscon);
+ }
+
+ ret = dev_read_u32_index(dev, "ti,syscon-efuse", 1, );
+ if (ret)
+ return ret;
+
+ regmap_read(syscon, offset, _lo);
+ regmap_read(syscon, offset + 4, _hi);
+
+ mac_addr[0] = (mac_hi >> 8) & 0xff;
+ mac_addr[1] = mac_hi & 0xff;
+ mac_addr[2] = (mac_lo >> 24) & 0xff;
+ mac_addr[3] = (mac_lo >> 16) & 0xff;
+ mac_addr[4] = (mac_lo >> 8) & 0xff;
+ mac_addr[5] = mac_lo & 0xff;
+
+ return 0;
+}
+
static int am65_cpsw_read_rom_hwaddr(struct udevice *dev)
{
struct am65_cpsw_priv *priv = dev_get_priv(dev);
- struct am65_cpsw_common *common = priv->cpsw_common;
struct eth_pdata *pdata = dev_get_plat(dev);
- u32 mac_hi, mac_lo;
-
- if (common->mac_efuse == FDT_ADDR_T_NONE)
- return -1;
- mac_lo = readl(common->mac_efuse);
- mac_hi = readl(common->mac_efuse + 4);
- pdata->enetaddr[0] = (mac_hi >> 8) & 0xff;
- pdata->enetaddr[1] = mac_hi & 0xff;
- pdata->enetaddr[2] = (mac_lo >> 24) & 0xff;
- pdata->enetaddr[3] = (mac_lo >> 16) & 0xff;
- pdata->enetaddr[4] = (mac_lo >> 8) & 0xff;
- pdata->enetaddr[5] = mac_lo & 0xff;
+ am65_cpsw_am654_get_efuse_macid(dev,
+ priv->port_id,
+ pdata->enetaddr);
return 0;
}
@@ -710,8 +732,6 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
cpsw_common->ss_base = dev_read_addr(dev);
if (cpsw_common->ss_base == FDT_ADDR_T_NONE)
return -EINVAL;
- cpsw_common->mac_efuse = devfdt_get_addr_name(dev, "mac_efuse");
- /* no err check - optional */
ret = power_domain_get_by_index(dev, _common->pwrdmn, 0);
if (ret) {
--
2.34.1
[PATCH 0/2] net: ti: am65-cpsw-nuss: Drop custom property "mac_efuse"
Hi, We need to track the Device tree in Linux. The approved property for MAC address EFUSE is "ti,syscon-efuse". Use that and drop custom property "mac_efuse". cheers, -roger Roger Quadros (2): net: ti: am65-cpsw-nuss: Use approved property to get efuse address arm: dts: k3-am625-sk-u-boot.dtsi: drop mac_efuse arch/arm/dts/k3-am625-sk-u-boot.dtsi | 3 -- configs/am62x_evm_a53_defconfig | 1 + drivers/net/ti/am65-cpsw-nuss.c | 52 +++- 3 files changed, 37 insertions(+), 19 deletions(-) -- 2.34.1
Re: [PATCH 1/4] pinctrl: Create a select_state variant with the ofnode
On 20/07/2023 12:55, Maxime Ripard wrote:
> Some drivers might not follow entirely the driver/device association,
> and thus might support what should be multiple devices in a single
> driver.
>
> Such a driver is am65-cpsw-nuss, where the MAC and MDIO controllers are
> different device tree nodes, with their own resources (including pinctrl
> pins) but supported by a single driver tied to the MAC device in U-Boot.
>
> In order to get the proper pinctrl state, we would need to get the
> state from the MDIO device tree node, but tie it to the MAC device since
> it's the only thing we have access to.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/pinctrl/pinctrl-uclass.c | 15 +--
> include/dm/pinctrl.h | 26 --
> 2 files changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-uclass.c
> b/drivers/pinctrl/pinctrl-uclass.c
> index 73dd7b1038bb..9e28f1858cbd 100644
> --- a/drivers/pinctrl/pinctrl-uclass.c
> +++ b/drivers/pinctrl/pinctrl-uclass.c
> @@ -53,7 +53,8 @@ static int pinctrl_config_one(struct udevice *config)
> * @statename: state name, like "default"
> * @return: 0 on success, or negative error code on failure
> */
> -static int pinctrl_select_state_full(struct udevice *dev, const char
> *statename)
> +static int pinctrl_select_state_full(struct udevice *dev, ofnode node,
> + const char *statename)
> {
> char propname[32]; /* long enough */
> const fdt32_t *list;
> @@ -61,7 +62,7 @@ static int pinctrl_select_state_full(struct udevice *dev,
> const char *statename)
> struct udevice *config;
> int state, size, i, ret;
>
> - state = dev_read_stringlist_search(dev, "pinctrl-names", statename);
> + state = ofnode_stringlist_search(node, "pinctrl-names", statename);
> if (state < 0) {
> char *end;
> /*
> @@ -74,7 +75,7 @@ static int pinctrl_select_state_full(struct udevice *dev,
> const char *statename)
> }
>
> snprintf(propname, sizeof(propname), "pinctrl-%d", state);
> - list = dev_read_prop(dev, propname, );
> + list = ofnode_get_property(node, propname, );
> if (!list)
> return -ENOSYS;
>
> @@ -293,20 +294,22 @@ static int pinctrl_select_state_simple(struct udevice
> *dev)
> return ops->set_state_simple(pctldev, dev);
> }
>
> -int pinctrl_select_state(struct udevice *dev, const char *statename)
> +int pinctrl_select_state_by_ofnode(struct udevice *dev, ofnode node,
> +const char *statename)
> {
> /*
>* Some device which is logical like mmc.blk, do not have
>* a valid ofnode.
>*/
> - if (!dev_has_ofnode(dev))
> + if (!ofnode_valid(node))
> return 0;
> +
> /*
>* Try full-implemented pinctrl first.
>* If it fails or is not implemented, try simple one.
>*/
> if (CONFIG_IS_ENABLED(PINCTRL_FULL))
> - return pinctrl_select_state_full(dev, statename);
> + return pinctrl_select_state_full(dev, node, statename);
>
> return pinctrl_select_state_simple(dev);
> }
> diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h
> index e3e50afeaff0..be4679b7f20d 100644
> --- a/include/dm/pinctrl.h
> +++ b/include/dm/pinctrl.h
> @@ -502,6 +502,24 @@ static inline int pinctrl_generic_set_state(struct
> udevice *pctldev,
> #endif
>
> #if CONFIG_IS_ENABLED(PINCTRL)
> +/**
> + * pinctrl_select_state_by_ofnode() - Set a device to a given state using
> the given ofnode
> + * @dev: Peripheral device
> + * @ofnode: Device Tree node to get the state from
> + * @statename: State name, like "default"
> + *
> + * Return: 0 on success, or negative error code on failure
> + */
> +int pinctrl_select_state_by_ofnode(struct udevice *dev, ofnode node, const
> char *statename);
> +#else
> +static inline int pinctrl_select_state_by_ofnode(struct udevice *dev,
> + ofnode node,
> + const char *statename)
> +{
> + return -ENOSYS;
> +}
This allows & encourages one device driver to change another devices pinctrl
state
which doesn't look like a good idea to me.
Please see if an alternative solution pointed out in patch2 works
so we don't have to need this patch.
> +#endif
> +
> /**
> * pinctrl_select_state() - Set a device to a given state
> * @dev: Peripheral device
> @@ -509,14 +527,10 @@ static inline int pinctrl_generic_set_state(struct
> udevice *pctldev,
> *
> * Return: 0 on success, or negative error code on failure
> */
> -int pinctrl_select_state(struct udevice *dev, const char *statename);
> -#else
> -static inline int pinctrl_select_state(struct udevice *dev,
> -const char *statename)
> +static inline int pinctrl_select_state(struct udevice *dev, const char
> *statename)
Re: [PATCH 2/4] net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node
On 20/07/2023 12:55, Maxime Ripard wrote:
> The binding represents the MDIO controller as a child device tree
> node of the MAC device tree node.
>
> The U-Boot driver mostly ignores that child device tree node and just
> hardcodes the resources it uses to support both the MAC and MDIO in a
> single driver.
>
> However, some resources like pinctrl muxing states are thus ignored.
> This has been a problem with device trees since Linux 6.5-rc1 which will
> put some pinctrl states on the MDIO device tree node.
>
> Let's rework the driver a bit to fetch the pinctrl state from the MDIO
> node and apply it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/net/ti/am65-cpsw-nuss.c | 49
> +
> 1 file changed, 49 insertions(+)
>
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index f674b0baa359..2d579bf4af2c 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -696,6 +697,50 @@ out:
> return ret;
> }
>
> +static ofnode am65_cpsw_find_mdio(ofnode parent)
> +{
> + ofnode node;
> +
> + ofnode_for_each_subnode(node, parent)
> + if (ofnode_device_is_compatible(node, "ti,cpsw-mdio"))
> + return node;
> +
> + return ofnode_null();
> +}
> +
> +static int am65_cpsw_setup_mdio(struct udevice *dev)
> +{
> + ofnode mdio;
> + int ret;
> +
> + mdio = am65_cpsw_find_mdio(dev_ofnode(dev));
> + if (!ofnode_valid(mdio))
> + return -ENODEV;
> +
> + /*
> + * The MDIO controller is represented in the DT binding by a
> + * subnode of the MAC controller.
> + *
> + * Our driver largely ignores that and supports MDIO by
> + * hardcoding the register offsets.
> + *
> + * However, some resources (clocks, pinctrl) might be tied to
> + * the MDIO node, and thus ignored.
> + *
> + * Clocks are not a concern at the moment since it's shared
> + * between the MAC and MDIO, so the driver handles both at the
> + * same time.
> + *
> + * However, we do need to make sure the pins states tied to the
> + * MDIO node are configured properly.
> + */
Please mention this as a HACK: that needs to go away when davinci_mdio
and this driver properly supports MDIO infrastructure.
> + ret = pinctrl_select_state_by_ofnode(dev, mdio, "default");
Instead of modifying the API, can we have a dummy driver for the
"ti,davinci_mdio"
device that registers as class UCLASS_MDIO but does nothing else?
Then you can drop patch 1 and instead do
ret = uclass_get_device_by_ofnode(UCLASS_MDIO, node, _dev);
if (!ret)
pinctrl_select_state(mdio_dev, "default");
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> static int am65_cpsw_probe_nuss(struct udevice *dev)
> {
> struct am65_cpsw_common *cpsw_common = dev_get_priv(dev);
> @@ -728,6 +773,10 @@ static int am65_cpsw_probe_nuss(struct udevice *dev)
> AM65_CPSW_CPSW_NU_ALE_BASE;
> cpsw_common->mdio_base = cpsw_common->ss_base + AM65_CPSW_MDIO_BASE;
>
> + ret = am65_cpsw_setup_mdio(dev);
> + if (ret)
> + goto out;
> +
> ports_np = dev_read_subnode(dev, "ethernet-ports");
> if (!ofnode_valid(ports_np)) {
> ret = -ENOENT;
>
--
cheers,
-roger
Re: [PATCH 4/4] fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On 20/07/2023 12:55, Maxime Ripard wrote:
> Dropping ranges entirely doesn't work since the register offset on the
> MDIO device node will now be completely off, so we need to adjust it to
> the right value without the translation.
>
> We also need to have an empty ranges property for the reg address to be
> properly evaluated.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> index fe1c7408a89d..2ec3fff99f32 100644
> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> @@ -122,8 +122,8 @@
> reg = <0x0 0x800 0x0 0x20>,
> <0x0 0x43000200 0x0 0x8>;
> reg-names = "cpsw_nuss", "mac_efuse";
> - /delete-property/ ranges;
> bootph-pre-ram;
> + ranges;
>
> cpsw-phy-sel@04044 {
> compatible = "ti,am64-phy-gmii-sel";
> @@ -132,6 +132,10 @@
> };
> };
>
> +_mdio {
> + reg = <0x0 0x8000f00 0x0 0x100>;
> +};
> +
Why this change?
Linux DT has
cpsw3g_mdio: mdio@f00 {
compatible = "ti,cpsw-mdio","ti,davinci_mdio";
reg = <0x00 0xf00 0x00 0x100>;
And it is a child of cpsw3g node.
> _port1 {
> bootph-pre-ram;
> };
>
--
cheers,
-roger
Re: [RFC PATCH 4/4] arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1
On 13/07/2023 10:20, Nishanth Menon wrote:
> Update the am62 and am625 device-trees from linux v6.3-rc5 This needed the
> followin
> tweaks to the u-boot specific dtsi as well:
> - Switch tick-timer to the main_timer as it's now defined in the main dtsi
> - Secure proxies are defined in Soc dtsis
> - Drop duplicate nodes - u-boot.dtsi is includes in r5-sk, no need for
> either the definitions from main.dtsi OR duplication from u-boot.dtsi
> - Add mdio pins to the cpsw3g pinctrl in u-boot dtsi. It moved to a subnode
> in the
> linux dtsi that u-boot doesn't use/support
>
> Cc: Francesco Dolcini
> Cc: Sjoerd Simons
> Cc: Wadim Egorov
> Signed-off-by: Nishanth Menon
> ---
>
> This is a respin of Sjoerd's series.. quiet a bit of sync there. but
> should make it easier to add on newer boards by backporting from
> upstream kernel.
>
> arch/arm/dts/k3-am62-main.dtsi | 389 +++--
> arch/arm/dts/k3-am62-mcu.dtsi| 66 +
> arch/arm/dts/k3-am62-thermal.dtsi| 33 +++
> arch/arm/dts/k3-am62-wakeup.dtsi | 33 ++-
> arch/arm/dts/k3-am62.dtsi| 11 +-
> arch/arm/dts/k3-am625-r5-sk.dts | 92 +-
> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 24 +-
> arch/arm/dts/k3-am625-sk.dts | 286 ++-
> arch/arm/dts/k3-am625.dtsi | 54 +++-
> arch/arm/dts/k3-am62x-sk-common.dtsi | 412 +++
> arch/arm/dts/k3-pinctrl.h| 53
> 11 files changed, 1065 insertions(+), 388 deletions(-)
> create mode 100644 arch/arm/dts/k3-am62-thermal.dtsi
> create mode 100644 arch/arm/dts/k3-am62x-sk-common.dtsi
> create mode 100644 arch/arm/dts/k3-pinctrl.h
>
>
> diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> index a60c37f1dbf0..76589c7025a0 100644
> --- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
> @@ -9,7 +9,7 @@
> / {
> chosen {
> stdout-path = "serial2:115200n8";
> - tick-timer =
> + tick-timer = _timer0;
> };
>
> aliases {
> @@ -21,16 +21,13 @@
> };
> };
>
> -_main{
> +_main {
> bootph-pre-ram;
> +};
>
> - timer1: timer@240 {
> - compatible = "ti,omap5430-timer";
> - reg = <0x00 0x240 0x00 0x80>;
> - ti,timer-alwon;
> - clock-frequency = <2500>;
> - bootph-pre-ram;
> - };
> +_timer0 {
> + clock-frequency = <2500>;
> + bootph-pre-ram;
> };
>
> {
> @@ -77,10 +74,6 @@
> bootph-pre-ram;
> };
>
> -_uart1 {
> - bootph-pre-ram;
> -};
> -
> _mcu {
> bootph-pre-ram;
> };
> @@ -93,10 +86,6 @@
> bootph-pre-ram;
> };
>
> -_uart0 {
> - bootph-pre-ram;
> -};
> -
> {
> bootph-pre-ram;
> };
> @@ -135,6 +124,7 @@
> reg-names = "cpsw_nuss", "mac_efuse";
mac_efuse is another odd duck.
The efuse offset needs to be obtained from
"ti,syscon-efuse = <_conf 0x200>;"
which is already present in am62-main.dtsi
> /delete-property/ ranges;
Any idea why we delete ranges?
> bootph-pre-ram;
> + pinctrl-0 = <_mdio1_pins_default _rgmii1_pins_default>;
>
> cpsw-phy-sel@04044 {
> compatible = "ti,am64-phy-gmii-sel";
This can also go away.
Only bootph-pre-ram required.
--
cheers,
-roger
Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
On 20/07/2023 17:12, Maxime Ripard wrote: > Hi > > Sorry, I didn't receive Roger mail so I'll reply here > > On Thu, Jul 20, 2023 at 09:00:19AM -0500, Nishanth Menon wrote: >> On 16:56-20230720, Roger Quadros wrote: >>> Hi, >>> >>> On 20/07/2023 16:33, Ravi Gunasekaran wrote: >>>> >>>> >>>> On 7/20/2023 3:25 PM, Maxime Ripard wrote: >>>>> Hi, >>>>> >>>>> This series is based on: >>>>> https://lore.kernel.org/all/20230713072019.3153871-1...@ti.com/ >>>>> >>>>> It fixes the issue of Linux booting from the DT embedded by U-boot. The >>>>> main issue there is that U-Boot doesn't handle the MDIO child node that >>>>> might have resources attached to it. >>>>> >>>>> Thus, any pinctrl configuration that could be attached to the MDIO >>>>> child node is effectively ignored. Unfortunately, starting with 6.5-rc1, >>>>> Linux does just that. >>> >>> I didn't get this part. Linux does not ignore pinctrl configuration attached >>> to MDIO child node. What changed in 6.5-rc1? > > Linux doesn't ignore it, but Linux started putting pinctrl configuration > on the MDIO node, which is ignored by U-Boot. Linux always had MDIO pinctrl configuration in the MDIO node, way before 6.5-rc1. Let's not mention 6.5-rc1 here as it gives an indication that something in 6.5-rc1 caused this issue. ;) Earlier, u-boot didn't enable the MDIO node. With Nishanth's sync it does which is fine, but duplicating the MDIO pinctrl node in the CPSW node causes problems on Linux. I see you reverted that change in patch 3, but probably Nishanth can avoid it if we got this route. > >>>>> This was solved by duplicating the pinctrl configuration onto the MAC >>> >>> If I remember right, there is no driver model driver for MDIO in u-boot and >>> adding the mdio pinctrl into CPSW DT node was a hack in u-boot. > > Yeah, but we now have in the U-Boot DT two nodes referencing the same > pinctrl configuration: the CPSW and the MDIO node. Linux then tries to > assign that configuration to both devices and it fails. Understood. > >>>>> device node. Unfortunately, this doesn't work for Linux since now it has >>>>> two devices competing for the same pins. >>> >>> What has really changed here is that you are passing u-boot's device >>> tree to Linux. > > I didn't change anything. This is the default boot process if you don't > provide a DT in the ESP partition. > OK. >>> This has nothing to do with 6.5-rc1 right? > > The issue started to occur with Nishanth patch to sync with Linux > 6.5-rc1 device trees, so there's definitely a connection. > >>> I suppose your solution is still a hack but of lesser evil than >>> duplicating MDIO pinctrl in CPSW node. >>> >>> The proper solution would be to implement driver model for the >>> davinci MDIO driver. Siddharth has been working on this. If that is >>> close to ready we should just use that instead. >> >> But this allows for a cleaner device tree while the driver can be fixed >> up independently, correct? Unfortunately, Siddharth's driver model work, Yes. MDIO pinctrl no longer needs to be duplicated in CPSW node at u-boot. >> from what I understand, is around 2024 timeframe.. which is probably not >> something that helps us in the community at this point. OK, then we need to resort to some temporary solution like this then. > > Yeah, at the moment I have to choose between getting the MMC to work in > Linux or the Ethernet ports. The former is working thanks to your patch, > the latter is broken because of it. Ideally I'd like both :) > -- cheers, -roger
Re: [PATCH 0/4] net: ti: am65-cpsw-nuss: Fix DT binding handling of pinctrl
Hi, On 20/07/2023 16:33, Ravi Gunasekaran wrote: > > > On 7/20/2023 3:25 PM, Maxime Ripard wrote: >> Hi, >> >> This series is based on: >> https://lore.kernel.org/all/20230713072019.3153871-1...@ti.com/ >> >> It fixes the issue of Linux booting from the DT embedded by U-boot. The >> main issue there is that U-Boot doesn't handle the MDIO child node that >> might have resources attached to it. >> >> Thus, any pinctrl configuration that could be attached to the MDIO >> child node is effectively ignored. Unfortunately, starting with 6.5-rc1, >> Linux does just that. I didn't get this part. Linux does not ignore pinctrl configuration attached to MDIO child node. What changed in 6.5-rc1? >> >> This was solved by duplicating the pinctrl configuration onto the MAC If I remember right, there is no driver model driver for MDIO in u-boot and adding the mdio pinctrl into CPSW DT node was a hack in u-boot. >> device node. Unfortunately, this doesn't work for Linux since now it has >> two devices competing for the same pins. What has really changed here is that you are passing u-boot's device tree to Linux. This has nothing to do with 6.5-rc1 right? I suppose your solution is still a hack but of lesser evil than duplicating MDIO pinctrl in CPSW node. The proper solution would be to implement driver model for the davinci MDIO driver. Siddharth has been working on this. If that is close to ready we should just use that instead. >> >> Let me know what you think, >> Maxime >> >> Signed-off-by: Maxime Ripard >> --- >> Maxime Ripard (4): >> pinctrl: Create a select_state variant with the ofnode >> net: ti: am65-cpsw-nuss: Enforce pinctrl state on the MDIO child node >> fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1 >> fixup! arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1 >> >> arch/arm/dts/k3-am625-sk-u-boot.dtsi | 7 -- >> drivers/net/ti/am65-cpsw-nuss.c | 49 >> >> drivers/pinctrl/pinctrl-uclass.c | 15 ++- >> include/dm/pinctrl.h | 26 ++- >> 4 files changed, 83 insertions(+), 14 deletions(-) >> --- >> base-commit: acff6e7c553d5a839e885730a4018465a34ba5a7 >> change-id: 20230720-ti-mdio-pinmux-a12525dba973 >> >> Best regards, > > Adding Roger -- cheers, -roger
Re: [PATCH 0/2] arm: dts: k3-am6: Sync DT with Linux
On 18/07/2023 00:01, Nishanth Menon wrote: > On 17:56-20230710, Roger Quadros wrote: >> Hi, >> >> This series syncs AM64/AM62 DT files with Linux. >> >> cheeers, >> -roger >> >> Roger Quadros (2): >> arm: dts: k3-am64: Sync DT with Linux >> board: ti: am64x: Recognize AM64-HSEVM > > Roger, > We need to base on binman stuff. > I already posted am62x sync, but as you notice - there is a bunch more > cleanups to do there. > https://lore.kernel.org/all/20230713072019.3153871-1...@ti.com/ > > If you don'nt mind syncing with me on irc, we can work through the > details needed. > OK Nishanth. will ping you today on irc. -- cheers, -roger
Re: [PATCH v3 00/12] Remove unnecessary USBx dr_mode configuration.
On 13/07/2023 16:45, Julien Panis wrote: > For all TI platforms handled in this series, USBx dr_mode > was configured as peripheral in '-u-boot.dtsi'. > This series removes these fragments, and modifies dwc3 and > cdns3 USB drivers so that they override 'otg' to 'peripheral' > mode. > > This follows a discussion about a similar topic for am3 boards: > https://lore.kernel.org/u-boot/20230621-fix_usb_ether_init-v4-0-5f4977bb7...@baylibre.com/ > > Signed-off-by: Julien Panis > --- > Changes in v3: > - Handle 'otg' mode as 'peripheral' in cdns3 usb driver, which is used > by am64/j7200/j721e platforms. > - Link to v2: > https://lore.kernel.org/r/20230706-handle-otg-as-periph-v2-0-e26c028a2...@baylibre.com > > Changes in v2: > - Handle 'unknown' mode as 'otg' in dwc3 usb driver. > - Link to v1: > https://lore.kernel.org/r/20230706-handle-otg-as-periph-v1-0-bd85d15ff...@baylibre.com > > --- > Julien Panis (12): > usb: dwc3: Handle unknown mode as otg > arm: dts: dra7-evm-u-boot: Remove usb1 mode configuration > arm: dts: dra71-evm-u-boot: Remove usb1 mode configuration > arm: dts: dra72-evm-revc-u-boot: Remove usb1 mode configuration > arm: dts: dra72-evm-u-boot: Remove usb1 mode configuration > arm: dts: dra76-evm-u-boot: Remove usb1 mode configuration > arm: dts: keystone-k2e-evm-u-boot: Remove usb1 mode configuration > arm: dts: k3-am654-r5-base-board-u-boot: Remove usb mode configuration > usb: cdns3: Handle otg mode as peripheral > arm: dts: k3-am642-evm-u-boot: Remove usb0 mode configuration > arm: dts: k3-j7200-common-proc-board-u-boot: Remove usb0 mode > configuration > arm: dts: k3-j721e-common-proc-board-u-boot: Remove usb0 mode > configuration > > arch/arm/dts/dra7-evm-u-boot.dtsi | 1 - > arch/arm/dts/dra71-evm-u-boot.dtsi | 1 - > arch/arm/dts/dra72-evm-revc-u-boot.dtsi | 1 - > arch/arm/dts/dra72-evm-u-boot.dtsi | 1 - > arch/arm/dts/dra76-evm-u-boot.dtsi | 1 - > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 1 - > arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi | 5 - > arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 1 - > arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 1 - > arch/arm/dts/keystone-k2e-evm-u-boot.dtsi | 1 - > drivers/usb/cdns3/core.c| 4 > drivers/usb/dwc3/dwc3-generic.c | 4 ++-- > 12 files changed, 6 insertions(+), 16 deletions(-) > --- > base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f > change-id: 20230706-handle-otg-as-periph-4546e874cd15 > for this series: Acked-by: Roger Quadros -- cheers, -roger
Re: [RFC PATCH 2/2] board: ti: am65x: Move to using Extension framework
Hi Simon, On 10/07/2023 22:45, Simon Glass wrote: > Hi Roger, > > On Mon, 10 Jul 2023 at 08:51, Roger Quadros wrote: >> >> Support the Expansion cards via Extension framework. >> This should make 'expansion' command work to scan >> for expansion cards and apply DT overlays. >> >> Card detection code is moved to a library so >> other boards can benefit from it. >> >> Signed-off-by: Roger Quadros >> --- >> board/ti/am65x/evm.c | 264 - >> board/ti/common/Kconfig| 8 + >> board/ti/common/Makefile | 1 + >> board/ti/common/ti_card_detect.c | 155 + >> board/ti/common/ti_card_detect.h | 43 + >> configs/am65x_evm_a53_defconfig| 2 + >> configs/am65x_hs_evm_a53_defconfig | 2 + >> 7 files changed, 280 insertions(+), 195 deletions(-) >> create mode 100644 board/ti/common/ti_card_detect.c >> create mode 100644 board/ti/common/ti_card_detect.h > > Before this goes too far I think this should move to using a linker > list to declare the driver (or a driver-model driver if you prefer, > but that might be overkill). ti_card_detect.c This is not a device driver but just a helper library which is ultimately going to be used directly by the board files. e.g. see board/ti/am65x/evm.c > > What do people think? > > Regards, > Simon -- cheers, -roger
Re: [PATCH v2 00/11] Remove unnecessary USBx dr_mode configuration.
On 10/07/2023 16:54, Julien Panis wrote:
> For all TI platforms handled in this series, USBx dr_mode
> was configured as peripheral in '-u-boot.dtsi'.
> This series removes these fragments, since USBx dual-role
> feature is already handled as peripheral only in
> 'dwc3_glue_bind_common()' function of 'dwc3-generic.c' driver:
>
> static int dwc3_glue_bind_common(struct udevice *parent, ofnode node)
> {
> [...]
>
> switch (dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> case USB_DR_MODE_OTG:
>
> debug("%s: dr_mode: OTG or Peripheral\n", __func__);
> driver = "dwc3-generic-peripheral";
>
> break;
>
> [...]
> }
>
> This follows a discussion about a similar topic for am3 boards:
> https://lore.kernel.org/u-boot/20230621-fix_usb_ether_init-v4-0-5f4977bb7...@baylibre.com/
>
> Signed-off-by: Julien Panis
> ---
> Changes in v2:
> - Handle 'unknown' mode as 'otg' in dwc3 usb driver.
> - Link to v1:
> https://lore.kernel.org/r/20230706-handle-otg-as-periph-v1-0-bd85d15ff...@baylibre.com
>
> ---
> Julien Panis (11):
> usb: dwc3: Handle unknown mode as otg
> arm: dts: dra7-evm-u-boot: Remove usb1 mode configuration
> arm: dts: dra71-evm-u-boot: Remove usb1 mode configuration
> arm: dts: dra72-evm-revc-u-boot: Remove usb1 mode configuration
> arm: dts: dra72-evm-u-boot: Remove usb1 mode configuration
> arm: dts: dra76-evm-u-boot: Remove usb1 mode configuration
> arm: dts: k3-am642-evm-u-boot: Remove usb0 mode configuration
> arm: dts: k3-am654-r5-base-board-u-boot: Remove usb mode configuration
> arm: dts: k3-j7200-common-proc-board-u-boot: Remove usb0 mode
> configuration
> arm: dts: k3-j721e-common-proc-board-u-boot: Remove usb0 mode
> configuration
> arm: dts: keystone-k2e-evm-u-boot: Remove usb1 mode configuration
>
> arch/arm/dts/dra7-evm-u-boot.dtsi | 1 -
> arch/arm/dts/dra71-evm-u-boot.dtsi | 1 -
> arch/arm/dts/dra72-evm-revc-u-boot.dtsi | 1 -
> arch/arm/dts/dra72-evm-u-boot.dtsi | 1 -
> arch/arm/dts/dra76-evm-u-boot.dtsi | 1 -
> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 1 -
> arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi | 5 -
> arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 1 -
> arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 1 -
> arch/arm/dts/keystone-k2e-evm-u-boot.dtsi | 1 -
> drivers/usb/dwc3/dwc3-generic.c | 4 ++--
> 11 files changed, 2 insertions(+), 16 deletions(-)
> ---
> base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f
> change-id: 20230706-handle-otg-as-periph-4546e874cd15
>
> Best regards,
For this series:
Acked-by: Roger Quadros
[PATCH 1/2] arm: dts: k3-am64: Sync DT with Linux
Sync all am642-evm/am642-sk related DT files
with Linux.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am64-main.dtsi| 171 +++--
arch/arm/dts/k3-am64-mcu.dtsi | 53 +++-
arch/arm/dts/k3-am64-thermal.dtsi | 33 +
arch/arm/dts/k3-am64.dtsi | 22 +---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 10 +-
arch/arm/dts/k3-am642-evm.dts | 173 --
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 10 +-
arch/arm/dts/k3-am642-sk.dts | 166 +---
arch/arm/dts/k3-am642.dtsi| 1 +
arch/arm/dts/k3-pinctrl.h | 53
10 files changed, 566 insertions(+), 126 deletions(-)
create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi
create mode 100644 arch/arm/dts/k3-pinctrl.h
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 5e8036f32d..1664d9f024 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -228,12 +228,161 @@
};
};
+ main_timer0: timer@240 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x240 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 36 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 36 1>;
+ assigned-clock-parents = <_clks 36 2>;
+ power-domains = <_pds 36 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer1: timer@241 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x241 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 37 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 37 1>;
+ assigned-clock-parents = <_clks 37 2>;
+ power-domains = <_pds 37 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer2: timer@242 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x242 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 38 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 38 1>;
+ assigned-clock-parents = <_clks 38 2>;
+ power-domains = <_pds 38 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer3: timer@243 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x243 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 39 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 39 1>;
+ assigned-clock-parents = <_clks 39 2>;
+ power-domains = <_pds 39 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer4: timer@244 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x244 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 40 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 40 1>;
+ assigned-clock-parents = <_clks 40 2>;
+ power-domains = <_pds 40 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer5: timer@245 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x245 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 41 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 41 1>;
+ assigned-clock-parents = <_clks 41 2>;
+ power-domains = <_pds 41 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer6: timer@246 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x246 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 42 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 42 1>;
+ assigned-clock-parents = <_clks 42 2>;
+ power-domains = <_pds 42 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer7: timer@247 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x247 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 43 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 43 1>;
+ assigned-clock-parents = <_clks 43 2>;
+ power-domains = <_pds
[PATCH 2/2] board: ti: am64x: Recognize AM64-HSEVM
AM64-HSEVM is AM64-GPEVM with High Security Device.
Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header".
Signed-off-by: Roger Quadros
---
board/ti/am64x/evm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 96f4e3013a..a080b2b0d2 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -18,7 +18,8 @@
#include "../common/board_detect.h"
-#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
+#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
+ board_ti_k3_is("AM64-HSEVM"))
#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
--
2.34.1
[PATCH 0/2] arm: dts: k3-am6: Sync DT with Linux
Hi, This series syncs AM64/AM62 DT files with Linux. cheeers, -roger Roger Quadros (2): arm: dts: k3-am64: Sync DT with Linux board: ti: am64x: Recognize AM64-HSEVM arch/arm/dts/k3-am64-main.dtsi| 171 +++-- arch/arm/dts/k3-am64-mcu.dtsi | 53 +++- arch/arm/dts/k3-am64-thermal.dtsi | 33 + arch/arm/dts/k3-am64.dtsi | 22 +--- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 10 +- arch/arm/dts/k3-am642-evm.dts | 173 -- arch/arm/dts/k3-am642-sk-u-boot.dtsi | 10 +- arch/arm/dts/k3-am642-sk.dts | 166 +--- arch/arm/dts/k3-am642.dtsi| 1 + arch/arm/dts/k3-pinctrl.h | 53 board/ti/am64x/evm.c | 3 +- 11 files changed, 568 insertions(+), 127 deletions(-) create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi create mode 100644 arch/arm/dts/k3-pinctrl.h -- 2.34.1
[RFC PATCH 2/2] board: ti: am65x: Move to using Extension framework
Support the Expansion cards via Extension framework.
This should make 'expansion' command work to scan
for expansion cards and apply DT overlays.
Card detection code is moved to a library so
other boards can benefit from it.
Signed-off-by: Roger Quadros
---
board/ti/am65x/evm.c | 264 -
board/ti/common/Kconfig| 8 +
board/ti/common/Makefile | 1 +
board/ti/common/ti_card_detect.c | 155 +
board/ti/common/ti_card_detect.h | 43 +
configs/am65x_evm_a53_defconfig| 2 +
configs/am65x_hs_evm_a53_defconfig | 2 +
7 files changed, 280 insertions(+), 195 deletions(-)
create mode 100644 board/ti/common/ti_card_detect.c
create mode 100644 board/ti/common/ti_card_detect.h
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 706b219818..5bb187a062 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -22,21 +22,10 @@
#include
#include "../common/board_detect.h"
+#include "../common/ti_card_detect.h"
#define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
-/* Daughter card presence detection signals */
-enum {
- AM65X_EVM_APP_BRD_DET,
- AM65X_EVM_LCD_BRD_DET,
- AM65X_EVM_SERDES_BRD_DET,
- AM65X_EVM_HDMI_GPMC_BRD_DET,
- AM65X_EVM_BRD_DET_COUNT,
-};
-
-/* Max number of MAC addresses that are parsed/processed per daughter card */
-#define DAUGHTER_CARD_NO_OF_MAC_ADDR 8
-
/* Regiter that controls the SERDES0 lane and clock assignment */
#define CTRLMMR_SERDES0_CTRL0x00104080
#define PCIE_LANE0 0x1
@@ -99,6 +88,74 @@ int board_fit_config_name_match(const char *name)
}
#endif
+/* Expansion card Slot IDs */
+enum {
+ AM65X_EVM_APP_BRD_DET,
+ AM65X_EVM_LCD_BRD_DET,
+ AM65X_EVM_SERDES_BRD_DET,
+ AM65X_EVM_HDMI_GPMC_BRD_DET,
+ AM65X_EVM_BRD_DET_COUNT,
+};
+
+/* Expansion card slots */
+static const struct ti_card_slot_map am65x_slot_map[] = {
+ { "gpio@38_0", 0x52, }, /* AM65X_EVM_APP_BRD_DET */
+ { "gpio@38_1", 0x55, }, /* AM65X_EVM_LCD_BRD_DET */
+ { "gpio@38_2", 0x54, }, /* AM65X_EVM_SERDES_BRD_DET */
+ { "gpio@38_3", 0x53, }, /* AM65X_EVM_HDMI_GPMC_BRD_DET */
+};
+
+/* Supported Expansion cards */
+static const struct ti_card_info am65x_card_info[] = {
+ {
+ AM65X_EVM_APP_BRD_DET,
+ "AM6-GPAPPEVM",
+ "k3-am654-gp.dtbo",
+ 0,
+ TI_CARD_OWNER,
+ TI_CARD_VERSION_1,
+ },
+ {
+ AM65X_EVM_APP_BRD_DET,
+ "AM6-IDKAPPEVM",
+ "k3-am654-idk.dtbo",
+ 3,
+ TI_CARD_OWNER,
+ TI_CARD_VERSION_1,
+ },
+ {
+ AM65X_EVM_SERDES_BRD_DET,
+ "SER-PCIE2LEVM",
+ "k3-am654-pcie-usb2.dtbo",
+ 0,
+ TI_CARD_OWNER,
+ TI_CARD_VERSION_1,
+ },
+ {
+ AM65X_EVM_SERDES_BRD_DET,
+ "SER-PCIEUSBEVM",
+ "k3-am654-pcie-usb3.dtbo",
+ 0,
+ TI_CARD_OWNER,
+ TI_CARD_VERSION_1,
+ },
+ {
+ AM65X_EVM_LCD_BRD_DET,
+ "OLDI-LCD1EVM",
+ "k3-am654-evm-oldi-lcd1evm.dtbo",
+ 0,
+ TI_CARD_OWNER,
+ TI_CARD_VERSION_1,
+ },
+};
+
+int extension_board_scan(struct list_head *extension_list)
+{
+ return ti_card_detect(am65x_slot_map, ARRAY_SIZE(am65x_slot_map),
+ am65x_card_info, ARRAY_SIZE(am65x_card_info),
+ extension_list);
+}
+
#ifdef CONFIG_TI_I2C_BOARD_DETECT
int do_board_detect(void)
{
@@ -143,187 +200,7 @@ invalid_eeprom:
set_board_info_env_am6(name);
}
-static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
-{
- int ret;
-
- memset(desc, 0, sizeof(*desc));
-
- ret = dm_gpio_lookup_name(gpio_name, desc);
- if (ret < 0)
- return ret;
-
- /* Request GPIO, simply re-using the name as label */
- ret = dm_gpio_request(desc, gpio_name);
- if (ret < 0)
- return ret;
- return dm_gpio_set_dir_flags(desc, GPIOD_IS_IN);
-}
-
-static int probe_daughtercards(void)
-{
- struct ti_am6_eeprom ep;
- struct gpio_desc board_det_gpios[AM65X_EVM_BRD_DET_COUNT];
- char mac_addr[DAUGHTER_CARD_NO_OF_MAC_ADDR][TI_EEPROM_HDR_ETH_ALEN];
- u8 mac_addr_cnt;
- char name_overlays[1024] = { 0 };
- int i, j;
- int ret;
-
- /*
-* Daughter card presence detection signal name to GPIO (via I2C I/O
-* expander @ address 0x38) name and EEPROM I2C address mapping.
-
[RFC PATCH 1/2] board: ti: common: Add CONFIG_TI_CAPE_DETECT for cape detection
CONFIG_CMD_EXTENSION may be used on other TI boards that may
not require Cape detection logic.
Add CONFIG_TI_CAPE_DETECT for Cape detection logic so it can
be enabled independently.
Enable it by default only for platforms that require it. i.e. AM335X
Signed-off-by: Roger Quadros
---
board/ti/am335x/board.c | 8
board/ti/common/Kconfig | 8
board/ti/common/Makefile | 2 +-
board/ti/common/cape_detect.c | 2 +-
board/ti/common/cape_detect.h | 2 +-
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index ecb9fa02de..8bbabc5da8 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -86,6 +86,14 @@ void do_board_detect(void)
}
#endif
+int extension_board_scan(struct list_head *extension_list)
+{
+ if (IS_ENABLED(CONFIG_TI_CAPE_DETECT))
+ return ti_cape_extension_board_scan(extension_list);
+ else
+ return -EINVAL;
+}
+
#ifndef CONFIG_DM_SERIAL
struct serial_device *default_serial_console(void)
{
diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014..72ee2d6d0e 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -4,6 +4,14 @@ config TI_I2C_BOARD_DETECT
Support for detection board information on Texas Instrument's
Evaluation Boards which have I2C based EEPROM detection
+config TI_CAPE_DETECT
+ bool "Support BeagleBone Cape detection for TI platforms"
+ default y if TARGET_AM335X_EVM
+ depends on SUPPORT_EXTENSION_SCAN
+ help
+ Support Beagle Bone Cape detection for TI platforms
+ e.g. AM335x BeagleBone.
+
config EEPROM_BUS_ADDRESS
int "Board EEPROM's I2C bus address"
range 0 8
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index 3172d87b46..5db433f77f 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -2,4 +2,4 @@
# Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
-obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
+obj-${CONFIG_TI_CAPE_DETECT} += cape_detect.o
diff --git a/board/ti/common/cape_detect.c b/board/ti/common/cape_detect.c
index 2e6105cfbf..d345a4d8eb 100644
--- a/board/ti/common/cape_detect.c
+++ b/board/ti/common/cape_detect.c
@@ -21,7 +21,7 @@ static void sanitize_field(char *text, size_t size)
}
}
-int extension_board_scan(struct list_head *extension_list)
+int ti_cape_extension_board_scan(struct list_head *extension_list)
{
struct extension *cape;
struct am335x_cape_eeprom_id eeprom_header;
diff --git a/board/ti/common/cape_detect.h b/board/ti/common/cape_detect.h
index b0d5c9f18b..ea486adbb2 100644
--- a/board/ti/common/cape_detect.h
+++ b/board/ti/common/cape_detect.h
@@ -23,6 +23,6 @@ struct am335x_cape_eeprom_id {
#define CAPE_MAGIC 0xEE3355AA
-int extension_board_scan(struct list_head *extension_list);
+int ti_cape_extension_board_scan(struct list_head *extension_list);
#endif /* __CAPE_DETECT_H */
--
2.34.1
[RFC PATCH 0/2] board: ti: Use Extension framework
Hi, RFC as only build tested. Need to get early feedback before I spend more time on this. Newer TI boards (AM6/J7) are using a custom logic to detect expansion cards and set a 'name_overlays' environment variable. Then DT overlays are applied by again custom environment scripts during boot. Instead of that migrate to using the Extension framework. This allows the user to call 'extension scan' and 'extension apply' commands to detect extension cards and apply the DT overlays respectively. For Booting, I expect distro boot scripts to already support the extension framework via following environment 'extension_overlay_cmd' and 'extension_overlay_addr'. i.e. include/config_distro_bootcmd.h cheers, -roger Roger Quadros (2): board: ti: common: Add CONFIG_TI_CAPE_DETECT for cape detection board: ti: am65x: Move to using Extension framework board/ti/am335x/board.c| 8 + board/ti/am65x/evm.c | 264 - board/ti/common/Kconfig| 16 ++ board/ti/common/Makefile | 3 +- board/ti/common/cape_detect.c | 2 +- board/ti/common/cape_detect.h | 2 +- board/ti/common/ti_card_detect.c | 155 + board/ti/common/ti_card_detect.h | 43 + configs/am65x_evm_a53_defconfig| 2 + configs/am65x_hs_evm_a53_defconfig | 2 + 10 files changed, 299 insertions(+), 198 deletions(-) create mode 100644 board/ti/common/ti_card_detect.c create mode 100644 board/ti/common/ti_card_detect.h -- 2.34.1
Re: [PATCH 10/10] arm: dts: keystone-k2e-evm-u-boot: Remove usb1 mode configuration
On 10/07/2023 11:57, Julien Panis wrote:
> Hi Roger,
>
> On 7/10/23 09:53, Roger Quadros wrote:
>> Hi Julien,
>>
>> On 06/07/2023 19:07, Julien Panis wrote:
>>> USB1 dual-role feature is already handled as peripheral only
>>> in dwc3-generic driver.
>>>
>>> Signed-off-by: Julien Panis
>>> ---
>>> Â arch/arm/dts/keystone-k2e-evm-u-boot.dtsi | 1 -
>>> Â 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
>>> b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
>>> index 970d452f0804..a75f78377c28 100644
>>> --- a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
>>> +++ b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
>>> @@ -39,7 +39,6 @@
>>> Â {
>>> Â dwc3@2501 {
>>> Â phys = <_phy>;
>>> -Â Â Â dr_mode = "peripheral";
>>> Â snps,u2ss_inp3_quirk;
>>> Â status = "okay";
>>> Â };
>>>
>> keystone-k2e.dtsi nor keystone-k2e-evm.dtsi has dr_mode set anywhere.
>> In Linux, keystone-k2e-evm.dtsi has dr_mode as "peripheral".
>> Can we please have the same in u-boot as well?
>
> I can do that, but...
> ...shouldn't uboot dts have been sync'ed with linux dts before ?
This has to be manually done. Maybe this platform got left out?
Someone with access to K2E-EVM needs to do the sync and test if it works.
>
>>
>> Then, from dwc3_generic_of_to_plat()
>>
>> plat->dr_mode = usb_get_dr_mode(node);
>> if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
>> /* might be a leaf so check the parent for mode */
>> node = dev_ofnode(dev->parent);
>> plat->dr_mode = usb_get_dr_mode(node);
>> if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
>> pr_err("Invalid usb mode setup\n");
>> return -ENODEV;
>> }
>> }
>>
>> I suppose that should be changed to OTG by default instead of
>> complaining that it's invalid.
>>
>> FYI. From linux/devicetree/bindings/usb/usb-drd.yaml
>>
>> Â Â dr_mode:
>> description:
>> Â Â Tells Dual-Role USB controllers that we want to work on a particular
>> Â Â mode. In case this attribute isn't passed via DT, USB DRD controllers
>> Â Â should *default to OTG*.
>>
>
> I agree with you, I'll change that.
>
> Julien
--
cheers,
-roger
Re: [PATCH 10/10] arm: dts: keystone-k2e-evm-u-boot: Remove usb1 mode configuration
Hi Julien,
On 06/07/2023 19:07, Julien Panis wrote:
> USB1 dual-role feature is already handled as peripheral only
> in dwc3-generic driver.
>
> Signed-off-by: Julien Panis
> ---
> arch/arm/dts/keystone-k2e-evm-u-boot.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
> b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
> index 970d452f0804..a75f78377c28 100644
> --- a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
> +++ b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
> @@ -39,7 +39,6 @@
> {
> dwc3@2501 {
> phys = <_phy>;
> - dr_mode = "peripheral";
> snps,u2ss_inp3_quirk;
> status = "okay";
> };
>
keystone-k2e.dtsi nor keystone-k2e-evm.dtsi has dr_mode set anywhere.
In Linux, keystone-k2e-evm.dtsi has dr_mode as "peripheral".
Can we please have the same in u-boot as well?
Then, from dwc3_generic_of_to_plat()
plat->dr_mode = usb_get_dr_mode(node);
if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
/* might be a leaf so check the parent for mode */
node = dev_ofnode(dev->parent);
plat->dr_mode = usb_get_dr_mode(node);
if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
pr_err("Invalid usb mode setup\n");
return -ENODEV;
}
}
I suppose that should be changed to OTG by default instead of
complaining that it's invalid.
FYI. From linux/devicetree/bindings/usb/usb-drd.yaml
dr_mode:
description:
Tells Dual-Role USB controllers that we want to work on a particular
mode. In case this attribute isn't passed via DT, USB DRD controllers
should *default to OTG*.
--
cheers,
-roger
Re: [PATCH 3/6] arm: dts: k3-am642: Sync main_i2c0 with kernel
Hi Nishanth,
On 06/07/2023 15:38, Nishanth Menon wrote:
> On 21:10-20230704, Roger Quadros wrote:
>> main_i2c0 and pinmux should be in k3-am642-evm.dts.
>> Also add the I2C EEPROM.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 11 ---
>> arch/arm/dts/k3-am642-evm.dts | 20
>> 2 files changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> index 64857b0909..80c04d0117 100644
>> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> @@ -34,21 +34,10 @@
>>
>> _pmx0 {
>> bootph-pre-ram;
>> -main_i2c0_pins_default: main-i2c0-pins-default {
>> -bootph-pre-ram;
>> -pinctrl-single,pins = <
>> -AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
>> I2C0_SCL */
>> -AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
>> I2C0_SDA */
>> ->;
>> -};
>> };
>>
>> _i2c0 {
>> -status = "okay";
>> bootph-pre-ram;
>> -pinctrl-names = "default";
>> -pinctrl-0 = <_i2c0_pins_default>;
>> -clock-frequency = <40>;
>> };
>>
>> _uart0 {
>> diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
>> index 39feea78a0..529eb81538 100644
>> --- a/arch/arm/dts/k3-am642-evm.dts
>> +++ b/arch/arm/dts/k3-am642-evm.dts
>> @@ -233,6 +233,13 @@
>> >;
>> };
>>
>> +main_i2c0_pins_default: main-i2c0-default-pins {
>> +pinctrl-single,pins = <
>> +AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
>> I2C0_SCL */
>> +AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
>> I2C0_SDA */
>> +>;
>> +};
>> +
>> main_i2c1_pins_default: main-i2c1-pins-default {
>> pinctrl-single,pins = <
>> AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18)
>> I2C1_SCL */
>> @@ -335,6 +342,19 @@
>> status = "reserved";
>> };
>>
>> +_i2c0 {
>> +status = "okay";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_i2c0_pins_default>;
>> +clock-frequency = <40>;
>> +
>> +eeprom@50 {
>> +/* AT24CM01 */
>> +compatible = "atmel,24c1024";
>> +reg = <0x50>;
>> +};
>> +};
>> +
>> _i2c1 {
>> status = "okay";
>> pinctrl-names = "default";
>> --
>> 2.34.1
>>
>
> We should be getting this change again as part of sync back from kernel.
>
>
Got it.
Adding the EEPROM node causes I2C timeout error prints like below.
Any clue why that would be the case?
Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured
EEPROM not available at 0x50, trying to read at 0x51
Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured
Reading on-board EEPROM at 0x51 failed -121
--
cheers,
-roger
Re: [PATCH v4 0/2] Fix 'no USB device found' error.
Hi Julien, On 06/07/2023 13:40, Julien Panis wrote: > This series fixes the "No USB device found" error > for am335x-icev2 and am335x-evmsk. USB0 dual-role > feature is now handled as peripheral only in the > driver. > > The error was not produced for am335x-evm because > usb0 dr_mode was configured as peripheral in > 'am335x-evm-u-boot.dtsi'. This fragment is no > longer needed. > > Signed-off-by: Julien Panis > --- > Changes in v4: > - Handle usb dual-role feature as peripheral in ti-musb driver. > - Link to v3: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v3-1-40493e1d7...@baylibre.com > > Changes in v3: > - Remove usb0 dr_mode configuration from 'am335x-evm-u-boot.dtsi'. > - Link to v2: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v2-0-ff121f0e8...@baylibre.com > > Changes in v2: > - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c > - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' > and 'am335x-evmsk-u-boot.dtsi' device trees. > - Link to v1: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-215692399...@baylibre.com > > --- > Julien Panis (2): > musb-new: ti-musb: Handle usb dual-role feature as peripheral > arm: dts: am335x-evm-u-boot: Remove usb0 mode configuration for this series: Reviewed-by: Roger Quadros I also see other boards doing the wrong thing. i.e. replacing 'otg' with 'peripheral'. dra71-evm-u-boot.dtsi: dr_mode = "peripheral"; dra72-evm-revc-u-boot.dtsi: dr_mode = "peripheral"; dra72-evm-u-boot.dtsi: dr_mode = "peripheral"; dra76-evm-u-boot.dtsi: dr_mode = "peripheral"; dra7-evm-u-boot.dtsi: dr_mode = "peripheral"; k3-am642-evm-u-boot.dtsi: dr_mode="peripheral"; k3-am654-r5-base-board-u-boot.dtsi: dr_mode = "peripheral"; k3-am654-r5-base-board-u-boot.dtsi: dr_mode = "peripheral"; k3-j7200-common-proc-board-u-boot.dtsi: dr_mode = "peripheral"; k3-j721e-common-proc-board-u-boot.dtsi: dr_mode = "peripheral"; keystone-k2e-evm-u-boot.dtsi: dr_mode = "peripheral"; Is this something you can fix (in dwc3 driver) as it is on similar lines ;). Thanks! -- cheers, -roger
Re: [PATCH v2 0/2] Fix 'no USB device found' error.
On 06/07/2023 06:53, Tony Lindgren wrote: > * Tom Rini [230703 16:22]: >> On Mon, Jul 03, 2023 at 07:12:47PM +0300, Roger Quadros wrote: >>> Linux DT files are correct. USB0 is a dual-role port so it sets it to 'otg'. >>> u-boot doesn't support 'otg' so we need to override it to 'peripheral' in >>> -u-boot.dtsi >> >> Ah, thanks, that was the missing bit of background information. > > It would be best to parse dual-role feature in the driver to handle it as > peripheral only and keep the dts the same. +1 -- cheers, -roger
Re: [PATCH 1/6] board: ti: am64x: Recognize AM64-HSEVM
On 04/07/2023 21:10, Roger Quadros wrote:
> use "am64x_evm" board name in environment for both AM64-GPEVM and
> AM64-HSEVM.
>
> Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header"
>
> Signed-off-by: Roger Quadros
> ---
> board/ti/am64x/evm.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> index 96f4e3013a..42795cbd22 100644
> --- a/board/ti/am64x/evm.c
> +++ b/board/ti/am64x/evm.c
> @@ -18,7 +18,8 @@
>
> #include "../common/board_detect.h"
>
> -#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
> +#define board_is_am64x_evm() (board_ti_k3_is("AM64-GPEVM") || \
> + board_ti_k3_is("AM64-HSEVM"))
>
> #define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
> board_ti_k3_is("AM64B-SKEVM"))
> @@ -57,7 +58,7 @@ int board_fit_config_name_match(const char *name)
> {
> bool eeprom_read = board_ti_was_eeprom_read();
>
> - if (!eeprom_read || board_is_am64x_gpevm()) {
> + if (!eeprom_read || board_is_am64x_evm()) {
> if (!strcmp(name, "k3-am642-r5-evm") || !strcmp(name,
> "k3-am642-evm"))
> return 0;
> } else if (board_is_am64x_skevm()) {
> @@ -182,13 +183,13 @@ int checkboard(void)
> #ifdef CONFIG_BOARD_LATE_INIT
> static void setup_board_eeprom_env(void)
> {
> - char *name = "am64x_gpevm";
> + char *name = "am64x_evm";
>
> if (do_board_detect())
> goto invalid_eeprom;
>
> - if (board_is_am64x_gpevm())
> - name = "am64x_gpevm";
> + if (board_is_am64x_evm())
> + name = "am64x_evm";
"board/ti/am64x/am64x.env:if test $board_name = am64x_gpevm; then"
So I think it was a bad idea to change the name here.
Will revert this change.
> else if (board_is_am64x_skevm())
> name = "am64x_skevm";
> else
--
cheers,
-roger
[PATCH 6/6] configs: am64x_evm_a53_defconfig: Enable I2C GPIO drivers
We need the I2C GPIO drivers to detect expansion cards. Signed-off-by: Roger Quadros --- configs/am64x_evm_a53_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index 4589624e96..3a8d2ed3b6 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -105,7 +105,11 @@ CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80 CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_PCA953X=y +CONFIG_SPL_DM_PCA953X=y CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_DM_I2C_GPIO=y CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y -- 2.34.1
[PATCH 4/6] arm: dts: k3-am642-r5-evm: Add I2C0 and Card detect GPIOs
Card detect GPIOs are on I2C GPIO Expander on I2C0.
Enable I2C0 and GPIO Expander for r5-evm.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-r5-evm.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index e870492a69..01b4a61852 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -209,6 +209,13 @@
AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>;
};
+
+ main_i2c0_pins_default: main-i2c0-default-pins {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
I2C0_SCL */
+ AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
I2C0_SDA */
+ >;
+ };
};
{
@@ -267,6 +274,18 @@
/* EEPROM might be read before SYSFW is available */
_i2c0 {
/delete-property/ power-domains;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ tca9554: gpio@38 {
+/* TCA9554 */
+compatible = "nxp,pca9554";
+reg = <0x38>;
+gpio-controller;
+ #gpio-cells = <2>;
+};
};
{
--
2.34.1
[PATCH 5/6] arm: dts: k3-am642: Add I2C GPIO Expander
The I2C GPIO expander at address 0x38 is used for card detect GPIOs.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 4
arch/arm/dts/k3-am642-evm.dts | 8
2 files changed, 12 insertions(+)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 80c04d0117..f274d11697 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -40,6 +40,10 @@
bootph-pre-ram;
};
+ {
+ bootph-pre-ram;
+};
+
_uart0 {
bootph-pre-ram;
};
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 529eb81538..bc7e6f29b0 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -353,6 +353,14 @@
compatible = "atmel,24c1024";
reg = <0x50>;
};
+
+ tca9554: gpio@38 {
+ /* TCA9554 */
+ compatible = "nxp,pca9554";
+ reg = <0x38>;
+ gpio-controller;
+ #gpio-cells = <2>;
+};
};
_i2c1 {
--
2.34.1
[PATCH 3/6] arm: dts: k3-am642: Sync main_i2c0 with kernel
main_i2c0 and pinmux should be in k3-am642-evm.dts.
Also add the I2C EEPROM.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 11 ---
arch/arm/dts/k3-am642-evm.dts | 20
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 64857b0909..80c04d0117 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -34,21 +34,10 @@
_pmx0 {
bootph-pre-ram;
- main_i2c0_pins_default: main-i2c0-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
I2C0_SCL */
- AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
I2C0_SDA */
- >;
- };
};
_i2c0 {
- status = "okay";
bootph-pre-ram;
- pinctrl-names = "default";
- pinctrl-0 = <_i2c0_pins_default>;
- clock-frequency = <40>;
};
_uart0 {
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 39feea78a0..529eb81538 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -233,6 +233,13 @@
>;
};
+ main_i2c0_pins_default: main-i2c0-default-pins {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
I2C0_SCL */
+ AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
I2C0_SDA */
+ >;
+ };
+
main_i2c1_pins_default: main-i2c1-pins-default {
pinctrl-single,pins = <
AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18)
I2C1_SCL */
@@ -335,6 +342,19 @@
status = "reserved";
};
+_i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ eeprom@50 {
+ /* AT24CM01 */
+ compatible = "atmel,24c1024";
+ reg = <0x50>;
+ };
+};
+
_i2c1 {
status = "okay";
pinctrl-names = "default";
--
2.34.1
[PATCH 2/6] board: ti: am64x: Add HSE NAND card detection support
Add expansion card detection support. Add NAND card detection
support.
am64-sk EVM doesn't support daughtercards so let's restrict
daughtercard probing to am64-evm.
Signed-off-by: Roger Quadros
---
board/ti/am64x/evm.c | 177 +++
1 file changed, 177 insertions(+)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 42795cbd22..a7ddee9d64 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -24,6 +26,17 @@
#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
+#define AM64X_MAX_DAUGHTER_CARDS 8
+
+/* Daughter card presence detection signals */
+enum {
+ AM64X_EVM_HSE_BRD_DET,
+ AM64X_EVM_BRD_DET_COUNT,
+};
+
+/* Max number of MAC addresses that are parsed/processed per daughter card */
+#define DAUGHTER_CARD_NO_OF_MAC_ADDR 8
+
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
@@ -219,10 +232,170 @@ static void setup_serial(void)
snprintf(serial_string, sizeof(serial_string), "%016lx", board_serial);
env_set("serial#", serial_string);
}
+
#endif
#endif
#ifdef CONFIG_BOARD_LATE_INIT
+static const char *k3_dtbo_list[AM64X_MAX_DAUGHTER_CARDS] = {NULL};
+
+static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
+{
+ int ret;
+
+ memset(desc, 0, sizeof(*desc));
+
+ ret = dm_gpio_lookup_name(gpio_name, desc);
+ if (ret < 0) {
+ pr_err("Failed to lookup gpio %s: %d\n", gpio_name, ret);
+ return ret;
+ }
+
+ /* Request GPIO, simply re-using the name as label */
+ ret = dm_gpio_request(desc, gpio_name);
+ if (ret < 0) {
+ pr_err("Failed to request gpio %s: %d\n", gpio_name, ret);
+ return ret;
+ }
+
+ return dm_gpio_set_dir_flags(desc, GPIOD_IS_IN);
+}
+
+static int probe_daughtercards(void)
+{
+ struct ti_am6_eeprom ep;
+ struct gpio_desc board_det_gpios[AM64X_EVM_BRD_DET_COUNT];
+ char mac_addr[DAUGHTER_CARD_NO_OF_MAC_ADDR][TI_EEPROM_HDR_ETH_ALEN];
+ u8 mac_addr_cnt;
+ char name_overlays[1024] = { 0 };
+ int i, nb_dtbos = 0;
+ int ret;
+
+ /*
+* Daughter card presence detection signal name to GPIO (via I2C I/O
+* expander @ address 0x38) name and EEPROM I2C address mapping.
+*/
+ const struct {
+ char *gpio_name;
+ u8 i2c_addr;
+ } slot_map[AM64X_EVM_BRD_DET_COUNT] = {
+ { "gpio@38_0", 0x52, }, /* AM64X_EVM_HSE_BRD_DET */
+ };
+
+ /* Declaration of daughtercards to probe */
+ const struct {
+ u8 slot_index; /* Slot the card is installed */
+ char *card_name;/* EEPROM-programmed card name */
+ char *dtbo_name;/* Device tree overlay to apply */
+ u8 eth_offset; /* ethXaddr MAC address index offset */
+ } cards[] = {
+ {
+ AM64X_EVM_HSE_BRD_DET,
+ "TMDS64DC02EVM",
+ "k3-am642-evm-nand.dtbo",
+ 0,
+ },
+ };
+
+ /*
+* Initialize GPIO used for daughtercard slot presence detection and
+* keep the resulting handles in local array for easier access.
+*/
+ for (i = 0; i < AM64X_EVM_BRD_DET_COUNT; i++) {
+ ret = init_daughtercard_det_gpio(slot_map[i].gpio_name,
+_det_gpios[i]);
+ if (ret < 0)
+ return ret;
+ }
+
+ memset(k3_dtbo_list, 0, sizeof(k3_dtbo_list));
+ for (i = 0; i < ARRAY_SIZE(cards); i++) {
+ /* Obtain card-specific slot index and associated I2C address */
+ u8 slot_index = cards[i].slot_index;
+ u8 i2c_addr = slot_map[slot_index].i2c_addr;
+ const char *dtboname;
+
+ /*
+* The presence detection signal is active-low, hence skip
+* over this card slot if anything other than 0 is returned.
+*/
+ ret = dm_gpio_get_value(_det_gpios[slot_index]);
+ if (ret < 0)
+ return ret;
+ else if (ret)
+ continue;
+
+ /* Get and parse the daughter card EEPROM record */
+ ret = ti_i2c_eeprom_am6_get(CONFIG_EEPROM_BUS_ADDRESS, i2c_addr,
+ ,
+ (char **)mac_addr,
+ DAUGHTER_CARD_NO_OF_MAC_ADDR,
+
[PATCH 1/6] board: ti: am64x: Recognize AM64-HSEVM
use "am64x_evm" board name in environment for both AM64-GPEVM and
AM64-HSEVM.
Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header"
Signed-off-by: Roger Quadros
---
board/ti/am64x/evm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 96f4e3013a..42795cbd22 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -18,7 +18,8 @@
#include "../common/board_detect.h"
-#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
+#define board_is_am64x_evm() (board_ti_k3_is("AM64-GPEVM") || \
+ board_ti_k3_is("AM64-HSEVM"))
#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
@@ -57,7 +58,7 @@ int board_fit_config_name_match(const char *name)
{
bool eeprom_read = board_ti_was_eeprom_read();
- if (!eeprom_read || board_is_am64x_gpevm()) {
+ if (!eeprom_read || board_is_am64x_evm()) {
if (!strcmp(name, "k3-am642-r5-evm") || !strcmp(name,
"k3-am642-evm"))
return 0;
} else if (board_is_am64x_skevm()) {
@@ -182,13 +183,13 @@ int checkboard(void)
#ifdef CONFIG_BOARD_LATE_INIT
static void setup_board_eeprom_env(void)
{
- char *name = "am64x_gpevm";
+ char *name = "am64x_evm";
if (do_board_detect())
goto invalid_eeprom;
- if (board_is_am64x_gpevm())
- name = "am64x_gpevm";
+ if (board_is_am64x_evm())
+ name = "am64x_evm";
else if (board_is_am64x_skevm())
name = "am64x_skevm";
else
--
2.34.1
[PATCH 0/6] ti: k3-am642: Add daughtercard support
Hi, This series adds daughtercard detection support for am642-evm. NAND card support is added. cheers, -roger Roger Quadros (6): board: ti: am64x: Recognize AM64-HSEVM board: ti: am64x: Add HSE NAND card detection support arm: dts: k3-am642: Sync main_i2c0 with kernel arm: dts: k3-am642-r5-evm: Add I2C0 and Card detect GPIOs arm: dts: k3-am642: Add I2C GPIO Expander configs: am64x_evm_a53_defconfig: Enable I2C GPIO drivers arch/arm/dts/k3-am642-evm-u-boot.dtsi | 15 +- arch/arm/dts/k3-am642-evm.dts | 28 arch/arm/dts/k3-am642-r5-evm.dts | 19 +++ board/ti/am64x/evm.c | 188 +- configs/am64x_evm_a53_defconfig | 4 + 5 files changed, 238 insertions(+), 16 deletions(-) -- 2.34.1
Re: [PATCH v2 0/2] Fix 'no USB device found' error.
On 26/06/2023 10:32, Nishanth Menon wrote: > On 13:59-20230623, Tom Rini wrote: >> On Fri, Jun 23, 2023 at 09:42:01AM +0200, Julien Panis wrote: >>> >>> >>> On 6/22/23 17:49, Tom Rini wrote: On Thu, Jun 22, 2023 at 04:34:34PM +0200, Julien Panis wrote: > This series fixes usb0 dr_mode for am335x-icev2 > and am335x-evmsk. It must be set to 'peripheral' > in order to avoid 'no USB device found' error, > in usb_ether_init() function. > > Signed-off-by: Julien Panis > --- > Changes in v2: > - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c > - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' >and 'am335x-evmsk-u-boot.dtsi' device trees. > - Link to v1: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-215692399...@baylibre.com > > --- > Julien Panis (2): >arm: dts: am335x-icev2-u-boot: Configure peripheral mode for usb0 >arm: dts: am335x-evmsk-u-boot: Configure peripheral mode for usb0 > > arch/arm/dts/am335x-evmsk-u-boot.dtsi | 4 > arch/arm/dts/am335x-icev2-u-boot.dtsi | 4 > 2 files changed, 8 insertions(+) I'll ask the first question that Nishanth might also ask, which is why don't these belong in the kernel dts files? Thanks! >>> >>> That's a good question. :) Looping Nishanth... >>> usb0 dr_mode property is already overlayed for am335x-evm, >>> in 'am335x-evm-u-boot.dtsi'. So, it appeared more consistent >>> to me to do the same thing for am335x-icev2 and am335x-evmsk. >>> I guess that the goal is to configure usb0 as host by default at >>> kernel boot, since we do not necessarily want to use this usb0 >>> as peripheral from userspace. >>> Is it the right explanation @Vignesh @Nishanth ? >> >> It's I think even more likely that the am335x_evm fragment needs to go >> upstream too. > > Adding Tony to the thread, but I think it is better to send the changes > to upstream kernel. > Linux DT files are correct. USB0 is a dual-role port so it sets it to 'otg'. u-boot doesn't support 'otg' so we need to override it to 'peripheral' in -u-boot.dtsi -- cheers, -roger
Re: [PATCH v2 0/2] Fix 'no USB device found' error.
On 22/06/2023 17:34, Julien Panis wrote: > This series fixes usb0 dr_mode for am335x-icev2 > and am335x-evmsk. It must be set to 'peripheral' > in order to avoid 'no USB device found' error, > in usb_ether_init() function. > > Signed-off-by: Julien Panis > --- > Changes in v2: > - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c > - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' > and 'am335x-evmsk-u-boot.dtsi' device trees. > - Link to v1: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-215692399...@baylibre.com > > --- > Julien Panis (2): > arm: dts: am335x-icev2-u-boot: Configure peripheral mode for usb0 > arm: dts: am335x-evmsk-u-boot: Configure peripheral mode for usb0 > > arch/arm/dts/am335x-evmsk-u-boot.dtsi | 4 > arch/arm/dts/am335x-icev2-u-boot.dtsi | 4 > 2 files changed, 8 insertions(+) For this series: Reviewed-by: Roger Quadros -- cheers, -roger
Re: U-Boot OMAP GPMC ECC change
Hi Colin, On 19/05/2023 02:19, Colin Foster wrote: > Hi Roger, > > I really appreciate the help! > > On Thu, May 18, 2023 at 01:55:38PM +0300, Roger Quadros wrote: >> Hi Colin, >> >> On 17/05/2023 22:39, Colin Foster wrote: >>> >>> I swapped in just U-Boot (not the SPL) with your patch, and everything >>> seems to work! >>> >>> The issue of Uncorrectable ECC errors spam came from the SPL. Here's a >>> snippet of the boot log with the "ecc" print as well as your patch: >>> >> >> Thanks for the tests. Glad to hear issue is narrowed down to SPL. > > I can "fix" the issue by just commenting out the "ECC uncorrectable > errors" print :-) lol > >> >>> U-Boot SPL 2023.04-00029-g26a9ce5314-dirty (May 17 2023 - 12:06:49 -0700) >>> OMAP4460-GP ES1.1 >>> Trying to boot from NAND >>> ecc: 2420106 >>> ecc: ebd922f6 >>> ecc: 333f844f >>> ecc: ab812f72 >> >> This is clearly the issue. They should all have been 0. > > Interesting. With the "ecc" prints in U-Boot I also get some non-zero > values: > > ecc: 0 > ecc: 6bff997b > ecc: 6bff997b > ecc: 6bff997b > > > Once I'm booted, I can use nanddump. It seems like everything is correct > from the Linux side of things: > > # nanddump -f mlo_dump /dev/mtd0 > ECC failed: 0 > ECC corrected: 0 > Number of bad blocks: 0 > Number of bbt blocks: 0 > Block size 131072, page size 2048, OOB size 64 > Dumping data starting at 0x and ending at 0x0002... > > # nanddump -f uboot1_dump /dev/mtd1 > ECC failed: 0 > ECC corrected: 0 > Number of bad blocks: 0 > Number of bbt blocks: 0 > Block size 131072, page size 2048, OOB size 64 > Dumping data starting at 0x and ending at 0x0018... > > # nanddump -f uboot2_dump /dev/mtd2 > ECC failed: 0 > ECC corrected: 0 > Number of bad blocks: 0 > Number of bbt blocks: 0 > Block size 131072, page size 2048, OOB size 64 > Dumping data starting at 0x and ending at 0x0018... > > # nanddump -f /dev/null /dev/mtd3 > ECC failed: 0 > ECC corrected: 6 > Number of bad blocks: 0 > Number of bbt blocks: 0 > Block size 131072, page size 2048, OOB size 64 > Dumping data starting at 0x and ending at 0x1fce... > ECC: 1 corrected bitflip(s) at offset 0x0ab30800 > ECC: 1 corrected bitflip(s) at offset 0x0b008800 > ECC: 1 corrected bitflip(s) at offset 0x0deaa000 > ECC: 1 corrected bitflip(s) at offset 0x0ea5b000 > ECC: 1 corrected bitflip(s) at offset 0x0ecbc000 > ECC: 1 corrected bitflip(s) at offset 0x0ed61800 > > >> Can you please share your spl/u-boot.cfg? > > Attached Couple of questions there 1) CONFIG_MTDPARTS_DEFAULT "mtdparts=nandflash:0x2(xload_raw),0x18(u-boot),0x18(u-boot-2),0x1fce(main)" Is this correct and matches with what kernel sees? I couldn't see the NAND partition table in the Kernel Device tree patch. 2) #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x2 #define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND 0x1a These don't seem to match what you have defined in MTDPARTS_DEFAULT. Which one is correct? How do you flash the MLO and u-boot image to NAND? I tried on AM335x-EVM and it works fine both before and after commit 04fcd25873. Once change I had to do was to increase the u-boot partition size as u-boot image does not fit in original partition size. -boot log follows- U-Boot SPL 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 +0300) Trying to boot from NAND U-Boot 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 +0300) CPU : AM335X-GP rev 1.0 Model: TI AM335x EVM DRAM: 512 MiB Core: 156 devices, 17 uclasses, devicetree: separate WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout) NAND: 256 MiB MMC: OMAP SD/MMC: 0 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... not set. Validating first E-fuse MAC Net: eth2: ethernet@4a10, eth3: usb_ether Hit any key to stop autoboot: 0 => => mtd device nand0 , # parts = 10 #: namesizeoffset mask_flags 0: NAND.SPL0x0002 0x 0 1: NAND.SPL.backup10x0002 0x0002 0 2: NAND.SPL.backup20x0002 0x0004 0 3: NAND.SPL.backup30x0002 0x0006 0 4: NAND.u-boot-spl-os 0x0004 0x0008 0 5: NAND.u-boot 0x0020 0x000c 0 6: NAND.u-boot-env 0x0002 0x002c 0 7: NAND.u-boot-env.backup10x0002 0x002e 0 8: NAND.kernel 0x0070 0x0030 0 9: NAND.file-system0x0f60 0x00a0 0 -- cheers, -roger
Re: U-Boot OMAP GPMC ECC change
Hi Colin, On 17/05/2023 22:39, Colin Foster wrote: > Hi Roger, > > Thanks for the tests. I attached the files and commented in line... but > at the bottom of this email I have some findings... > > On Wed, May 17, 2023 at 04:30:55PM +0300, Roger Quadros wrote: >> Hi Colin, >> >> I just tested this on AM335x EVM which uses BCH8_CODE_HW but 8-bit NAND part. >> I see that you are using 16-bit NAND. >> >> One more difference in u-boot configuration. For me: >> CONFIG_NAND_OMAP_GPMC_PREFETCH=y >> >> Not sure if that matters but let's keep it set for now. >> >> For debug can you please apply the patch (at end) to u-boot at commit >> a95410696d21 >> (before breakage) and run the test. >> > All are attached. > > However I have some other initial findings: > > I swapped in just U-Boot (not the SPL) with your patch, and everything > seems to work! > > The issue of Uncorrectable ECC errors spam came from the SPL. Here's a > snippet of the boot log with the "ecc" print as well as your patch: > Thanks for the tests. Glad to hear issue is narrowed down to SPL. > U-Boot SPL 2023.04-00029-g26a9ce5314-dirty (May 17 2023 - 12:06:49 -0700) > OMAP4460-GP ES1.1 > Trying to boot from NAND > ecc: 2420106 > ecc: ebd922f6 > ecc: 333f844f > ecc: ab812f72 This is clearly the issue. They should all have been 0. > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > ecc: 2420106 > ecc: ebd922f6 > ecc: 333f844f > ecc: ab812f72 > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors Can you please share your spl/u-boot.cfg? We have a stripped down driver "am335x_spl_bch.c" that deals with NAND at SPL. I haven't really looked much at that driver but it relies on omap_gpmc.c for ecc.hwctl() read_buf() ecc.calculate() We didn't do any functional change to these functions in commit 04fcd25873 unless something slipped through the cracks. It seems to rely on following config options CFG_SYS_NAND_ECCPOS CONFIG_SYS_NAND_PAGE_COUNT CONFIG_SYS_NAND_PAGE_SIZE CONFIG_SYS_NAND_5_ADDR_CYCLE CFG_SYS_NAND_ECCSIZE CFG_SYS_NAND_ECCBYTES CONFIG_SYS_NAND_OOBSIZE Could you please share what they are set to for your SPL build? Meanwhile, I'll try to reproduce this on AM335x-EVM. -- cheers, -roger
Re: U-Boot OMAP GPMC ECC change
Hi Colin,
On 12/05/2023 19:05, Colin Foster wrote:
> Hi Roger,
>
> On Fri, May 12, 2023 at 02:53:07PM +0300, Roger Quadros wrote:
>>
>>
>> On 10/05/2023 18:38, Colin Foster wrote:
>>>
>>> This is still out-of-U-Boot. I have an include/configs/our_product.h
>>> file with this:
>>>
>>> """
>>> #define CFG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
>>> 12, \
>>> 13, 14, 15, 16, 17, 18, 19, 20,
>>> 21, 22, \
>>> 23, 24, 25, 26, 27, 28, 29, 30,
>>> 31, 32, \
>>> 33, 34, 35, 36, 37, 38, 39, 40,
>>> 41, \
>>> 42, 43, 44, 45, 46, 47, 48, 49,
>>> 50, 51, \
>>> 52, 53, 54, 55, 56, 57}
>>>
>>> #define CFG_SYS_NAND_ECCBYTES 14
>>> #define CFG_SYS_NAND_MAX_ECCPOS 57
>>
>> This should be 56 i.e. (57 - 2 + 1)
>> But it won't fix the issue you are facing. :P
>
> Oh, good catch. I know when I was trying to get this working I had to
> play with these values quite a bit. I must have missed changing this at
> one point.
>
>>
>>> #define CFG_SYS_NAND_ECCSIZE512
>>> #define CFG_SYS_NAND_MAX_OOBFREE2
>>> """
>>>
>>>
>>>> Can you please point me to the Linux device tree file if it exists?
>>>
>>> This is the latest submission. Still not accepted - I need to find time
>>> to button everything up and resubmit. My plan of attack was Kernel
>>> Acceptance, then U-Boot. Unfortunately my company lets the pesky
>>> "Shipping products" step get in the way :-)
>>>
>>> https://lkml.org/lkml/2023/2/22/939
>>>
>>> Or if you just want the ECC part:
>>>
>>> + nandflash: nand@0,0 {
>>> + compatible = "ti,omap2-nand";
>>> + reg = <0 0 4>;
>>> + interrupt-parent = <>;
>>> +
>>> + nand-bus-width = <16>;
>>> + ti,nand-ecc-opt = "bch8";
>>> + ti,elm-id=<>;
>>> + linux,mtd-name = "micron,nand";
>>>
>>>
>>> I think that's all the info you're looking for. Let me know if I missed
>>> something.
>>
>> Yes this is all I was looking for.
>>
>> Is CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW set in your u-boot config?
>
> Yes, it is set. I've attached our .config file. I just made a change to
> CONFIG_NAND_OMAP_GPMC_PREFETCH as a test, which didn't fix the issue.
>
> And as another sanity check, I reverted the patch and have functionality
> again:
>
I just tested this on AM335x EVM which uses BCH8_CODE_HW but 8-bit NAND part.
I see that you are using 16-bit NAND.
One more difference in u-boot configuration. For me:
CONFIG_NAND_OMAP_GPMC_PREFETCH=y
Not sure if that matters but let's keep it set for now.
For debug can you please apply the patch (at end) to u-boot at commit
a95410696d21
(before breakage) and run the test.
Test procedure:
> nand dump 0
> mmc dev 0
#replace 0 with whatever points to SD-card
> nand read $loadaddr 0 800
#loadaddr is any address in RAM which is free for use.
> fatwrite mmc 0:1 $loadaddr nand.org 800
- restore NAND page 0
> fatload mmc 0:1 $loadaddr nand.org
> nand write $loadaddr 0 800
Now please run the below test on the offending commit 04fcd25873 after applying
the patch (at end).
> nand dump 0
> mmc dev 0
#replace 0 with whatever points to SD-card
> fatload mmc 0:1 $loadaddr nand.org
> nand write $loadaddr 0 800
Please send me the logs of both tests and the nand.org file so I can try it out
here. Thanks!
--- patch starts---
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index be3cb3c601..ac06d5f019 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -300,6 +300,7 @@ static int omap_calculate_ecc(struct mtd_info *mtd, const
uint8_t *dat,
ecc_code[i++] = (val >> 0) & 0xFF;
ptr--;
}
+ printf("ecc: %x\n", val);
break;
case OMAP_ECC_BCH16_CODE_HW:
val = readl(_cfg->bch_result_4_6[0].bch_result_x[2]);
Re: [PATCH] phy: ti: phy-j721e-wiz: Add j721s2-wiz-10g module support
On 15/05/2023 13:50, Ravi Gunasekaran wrote: > Add support for j721s2-wiz-10g device to use clock-names interface > instead of explicitly defining clock nodes within device tree node. > > Signed-off-by: Ravi Gunasekaran Reviewed-by: Roger Quadros
Re: U-Boot OMAP GPMC ECC change
On 12/05/2023 19:05, Colin Foster wrote:
> Hi Roger,
>
> On Fri, May 12, 2023 at 02:53:07PM +0300, Roger Quadros wrote:
>>
>>
>> On 10/05/2023 18:38, Colin Foster wrote:
>>>
>>> This is still out-of-U-Boot. I have an include/configs/our_product.h
>>> file with this:
>>>
>>> """
>>> #define CFG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
>>> 12, \
>>> 13, 14, 15, 16, 17, 18, 19, 20,
>>> 21, 22, \
>>> 23, 24, 25, 26, 27, 28, 29, 30,
>>> 31, 32, \
>>> 33, 34, 35, 36, 37, 38, 39, 40,
>>> 41, \
>>> 42, 43, 44, 45, 46, 47, 48, 49,
>>> 50, 51, \
>>> 52, 53, 54, 55, 56, 57}
>>>
>>> #define CFG_SYS_NAND_ECCBYTES 14
>>> #define CFG_SYS_NAND_MAX_ECCPOS 57
>>
>> This should be 56 i.e. (57 - 2 + 1)
>> But it won't fix the issue you are facing. :P
>
> Oh, good catch. I know when I was trying to get this working I had to
> play with these values quite a bit. I must have missed changing this at
> one point.
>
>>
>>> #define CFG_SYS_NAND_ECCSIZE512
>>> #define CFG_SYS_NAND_MAX_OOBFREE2
>>> """
>>>
>>>
>>>> Can you please point me to the Linux device tree file if it exists?
>>>
>>> This is the latest submission. Still not accepted - I need to find time
>>> to button everything up and resubmit. My plan of attack was Kernel
>>> Acceptance, then U-Boot. Unfortunately my company lets the pesky
>>> "Shipping products" step get in the way :-)
>>>
>>> https://lkml.org/lkml/2023/2/22/939
>>>
>>> Or if you just want the ECC part:
>>>
>>> + nandflash: nand@0,0 {
>>> + compatible = "ti,omap2-nand";
>>> + reg = <0 0 4>;
>>> + interrupt-parent = <>;
>>> +
>>> + nand-bus-width = <16>;
>>> + ti,nand-ecc-opt = "bch8";
>>> + ti,elm-id=<>;
>>> + linux,mtd-name = "micron,nand";
>>>
>>>
>>> I think that's all the info you're looking for. Let me know if I missed
>>> something.
>>
>> Yes this is all I was looking for.
>>
>> Is CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW set in your u-boot config?
>
> Yes, it is set. I've attached our .config file. I just made a change to
> CONFIG_NAND_OMAP_GPMC_PREFETCH as a test, which didn't fix the issue.
>
> And as another sanity check, I reverted the patch and have functionality
> again:
>
>
> """
> U-Boot SPL 2023.04-00029-g316faf4c46-dirty (May 12 2023 - 09:02:58 -0700)
> OMAP4460-GP ES1.1
> Trying to boot from NAND
>
>
> U-Boot 2023.04-00029-g316faf4c46-dirty (May 12 2023 - 09:02:58 -0700)
>
> CPU : OMAP4460-GP ES1.1
> """
>
>
OK. next step is to dump calculated ECC values while reading a block
and see if it is different in failing case and then debug why.
Let me prepare a patch for that.
--
cheers,
-roger
Re: U-Boot OMAP GPMC ECC change
On 10/05/2023 18:38, Colin Foster wrote:
> Hi Roger,
>
> On Wed, May 10, 2023 at 12:42:43PM +0300, Roger Quadros wrote:
>> Hi Colin,
>>
>> On 09/05/2023 18:31, Colin Foster wrote:
>>> Hi Roger,
>>>
>>> I was looking to test my system against U-Boot 2023.04. I'm running an
>>> OMAP 4460 SOM (I've been waiting to get kernel acceptance before U-Boot,
>>> but that has slipped) and it boots from NAND.
>>>
>>> When I jumped from 2023.01 to 2023.04, I noticed I get spammed in the
>>> SPL by "omap-elm: uncorrectable ECC errors". I bisected, and this seems
>>> to be the result of commit 04fcd25873 ("mtd: rawnand: omap_gpmc: Fix
>>> BCH6/16 HW based correction").
>>
>> oops. Sorry about that.
>
> No worries!
>
>>>
>>> Is the multi-sector ECC generation something that should work in a
>>> backward-compatible way? Do you know of anything that might be going
>>> wrong here?
>>
>> The patch wasn't supposed to break anything.
>> I do not yet know what could be wrong. Most likely a wrong ECC
>> configuration is being used.
>>
>> Could you please share what ECC configuration you are using on your board?
>
> This is still out-of-U-Boot. I have an include/configs/our_product.h
> file with this:
>
> """
> #define CFG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, \
> 13, 14, 15, 16, 17, 18, 19, 20, 21,
> 22, \
> 23, 24, 25, 26, 27, 28, 29, 30, 31,
> 32, \
> 33, 34, 35, 36, 37, 38, 39, 40, 41, \
> 42, 43, 44, 45, 46, 47, 48, 49, 50,
> 51, \
> 52, 53, 54, 55, 56, 57}
>
> #define CFG_SYS_NAND_ECCBYTES 14
> #define CFG_SYS_NAND_MAX_ECCPOS 57
This should be 56 i.e. (57 - 2 + 1)
But it won't fix the issue you are facing. :P
> #define CFG_SYS_NAND_ECCSIZE512
> #define CFG_SYS_NAND_MAX_OOBFREE2
> """
>
>
>> Can you please point me to the Linux device tree file if it exists?
>
> This is the latest submission. Still not accepted - I need to find time
> to button everything up and resubmit. My plan of attack was Kernel
> Acceptance, then U-Boot. Unfortunately my company lets the pesky
> "Shipping products" step get in the way :-)
>
> https://lkml.org/lkml/2023/2/22/939
>
> Or if you just want the ECC part:
>
> + nandflash: nand@0,0 {
> + compatible = "ti,omap2-nand";
> + reg = <0 0 4>;
> + interrupt-parent = <>;
> +
> + nand-bus-width = <16>;
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id=<>;
> + linux,mtd-name = "micron,nand";
>
>
> I think that's all the info you're looking for. Let me know if I missed
> something.
Yes this is all I was looking for.
Is CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW set in your u-boot config?
--
cheers,
-roger
Re: [PATCH] usb: cdns3: gadget.c: Set fast access bit
On 05/05/2023 15:13, Ravi Gunasekaran wrote: > From: Aswath Govindraju > > When the device port is in a low power state [U3/L2/Not Connected], > accesses to usb device registers may take a long time. This could lead to > potential core hang when the controller registers are accessed after the > port is disabled by setting DEVDS field. Setting the fast register access > bit ensures that the PHY clock is keeping up in active state. > > Therefore, set fast access bit to ensure the accesses to device registers > are quick even in low power states. > > Signed-off-by: Aswath Govindraju Reviewed-by: Roger Quadros
Re: U-Boot OMAP GPMC ECC change
Hi Colin,
On 09/05/2023 18:31, Colin Foster wrote:
> Hi Roger,
>
> I was looking to test my system against U-Boot 2023.04. I'm running an
> OMAP 4460 SOM (I've been waiting to get kernel acceptance before U-Boot,
> but that has slipped) and it boots from NAND.
>
> When I jumped from 2023.01 to 2023.04, I noticed I get spammed in the
> SPL by "omap-elm: uncorrectable ECC errors". I bisected, and this seems
> to be the result of commit 04fcd25873 ("mtd: rawnand: omap_gpmc: Fix
> BCH6/16 HW based correction").
oops. Sorry about that.
>
> Is the multi-sector ECC generation something that should work in a
> backward-compatible way? Do you know of anything that might be going
> wrong here?
The patch wasn't supposed to break anything.
I do not yet know what could be wrong. Most likely a wrong ECC
configuration is being used.
Could you please share what ECC configuration you are using on your board?
Can you please point me to the Linux device tree file if it exists?
>
> Any advice would be greatly appreciated, as I find it is usually
> something simple I'm doing wrong that is causing most of my issues.
>
>
> Thanks,
>
> Colin Foster.
--
cheers,
-roger
Re: [EXTERNAL] Re: [PATCH] usb: cdns3: gadget.c: Set fast access bit
+Pawel & Peter On 09/05/2023 08:58, Ravi Gunasekaran wrote: > Hi Roger, > > On 05/05/23 6:02 pm, Roger Quadros wrote: >> Hi Ravi, >> >> On 05/05/2023 15:13, Ravi Gunasekaran wrote: >>> From: Aswath Govindraju >>> >>> When the device port is in a low power state [U3/L2/Not Connected], >>> accesses to usb device registers may take a long time. This could lead to >>> potential core hang when the controller registers are accessed after the >>> port is disabled by setting DEVDS field. Setting the fast register access >>> bit ensures that the PHY clock is keeping up in active state. >>> >>> Therefore, set fast access bit to ensure the accesses to device registers >>> are quick even in low power states. >>> >>> Signed-off-by: Aswath Govindraju >>> --- >>> drivers/usb/cdns3/gadget.c | 4 >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c >>> index fcaeab9cc1..fddc8c931a 100644 >>> --- a/drivers/usb/cdns3/gadget.c >>> +++ b/drivers/usb/cdns3/gadget.c >>> @@ -2321,6 +2321,9 @@ static void cdns3_gadget_config(struct cdns3_device >>> *priv_dev) >>> writel(USB_IEN_INIT, >usb_ien); >>> writel(USB_CONF_CLK2OFFDS | USB_CONF_L1DS, >usb_conf); >>> >>> + /* Set the Fast access bit */ >>> + writel(PUSB_PWR_FST_REG_ACCESS, _dev->regs->usb_pwr); >>> + >> >> Should this be done in cdns3_gadget_udc_start() so it is symmetric? >> > > cdns3_gadget_config() is called in cdns3_gadget_udc_start() and > cdns3_gadget_resume(). These settings seems to be needed during resume > as well. But this bit was never cleared in suspend so why do you need to set it again it in resume? The commit log says that this bit must be kept set in low power states. > >>> cdns3_configure_dmult(priv_dev, NULL); >>> >>> cdns3_gadget_pullup(_dev->gadget, 1); >>> @@ -2378,6 +2381,7 @@ static int cdns3_gadget_udc_stop(struct usb_gadget >>> *gadget) >>> >>> /* disable interrupt for device */ >>> writel(0, _dev->regs->usb_ien); >>> + writel(0, _dev->regs->usb_pwr); >>> writel(USB_CONF_DEVDS, _dev->regs->usb_conf); >>> >>> return ret; >>> >>> base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d >> -- cheers, -roger
Re: [PATCH] usb: cdns3: gadget.c: Set fast access bit
Hi Ravi, On 05/05/2023 15:13, Ravi Gunasekaran wrote: > From: Aswath Govindraju > > When the device port is in a low power state [U3/L2/Not Connected], > accesses to usb device registers may take a long time. This could lead to > potential core hang when the controller registers are accessed after the > port is disabled by setting DEVDS field. Setting the fast register access > bit ensures that the PHY clock is keeping up in active state. > > Therefore, set fast access bit to ensure the accesses to device registers > are quick even in low power states. > > Signed-off-by: Aswath Govindraju > --- > drivers/usb/cdns3/gadget.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c > index fcaeab9cc1..fddc8c931a 100644 > --- a/drivers/usb/cdns3/gadget.c > +++ b/drivers/usb/cdns3/gadget.c > @@ -2321,6 +2321,9 @@ static void cdns3_gadget_config(struct cdns3_device > *priv_dev) > writel(USB_IEN_INIT, >usb_ien); > writel(USB_CONF_CLK2OFFDS | USB_CONF_L1DS, >usb_conf); > > + /* Set the Fast access bit */ > + writel(PUSB_PWR_FST_REG_ACCESS, _dev->regs->usb_pwr); > + Should this be done in cdns3_gadget_udc_start() so it is symmetric? > cdns3_configure_dmult(priv_dev, NULL); > > cdns3_gadget_pullup(_dev->gadget, 1); > @@ -2378,6 +2381,7 @@ static int cdns3_gadget_udc_stop(struct usb_gadget > *gadget) > > /* disable interrupt for device */ > writel(0, _dev->regs->usb_ien); > + writel(0, _dev->regs->usb_pwr); > writel(USB_CONF_DEVDS, _dev->regs->usb_conf); > > return ret; > > base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d cheers, -roger
Re: [PATCH 04/23] arm: dts: k3-am642-sk: Fix mmc1 pinmux pull polarity
On 17/04/2023 14:12, Nishanth Menon wrote:
> On 13:42-20230417, Roger Quadros wrote:
>>
>>
>> On 14/04/2023 10:57, Nishanth Menon wrote:
>>> Fix the pinmux pull polarity.
>>>
>>> This is a pending upstream kernel updates as of v6.3-rc6.
>>>
>>> Signed-off-by: Nishanth Menon
>>> ---
>>> Sent to kernel.org
>>> https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
>>
>> Link to actual patch is
>> https://lore.kernel.org/linux-devicetree/20230414073328.381336-3...@ti.com/
>>
>>>
>>> arch/arm/dts/k3-am642-sk.dts | 16 +---
>>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
>>> index 4fb279489cfc..cc2027417e86 100644
>>> --- a/arch/arm/dts/k3-am642-sk.dts
>>> +++ b/arch/arm/dts/k3-am642-sk.dts
>>> @@ -223,15 +223,17 @@
>>>
>>> _pmx0 {
>>> main_mmc1_pins_default: main-mmc1-pins-default {
>>> + /* XXX: Kernel-Upstream: TODO: Upstream (pull changes) */
>>
>> Do we really want to sprinkle these comments in u-boot upstream?
>
> I have no other means to indicate that these nodes need to get to
> upstream kernel and when they do get into upstream kernel, what needs to
> be dropped from u-boot.
>
> I am open to suggestions here.
>
>> If we are quite sure this makes to upstream kernel we might as well pull
>> them into
>> u-boot as is.
>
> No, that has been the reason why the entire dt mismatch occurred in the
> first place. the subjective evaluation from various devs have been way
> off. if it makes it to kernel.org master, only then can we claim that
> the changes are in upstream.
In that case we do not accept any DT patches in u-boot till at least
Acked by kernel maintainer?
Re: [PATCH 04/23] arm: dts: k3-am642-sk: Fix mmc1 pinmux pull polarity
On 14/04/2023 10:57, Nishanth Menon wrote:
> Fix the pinmux pull polarity.
>
> This is a pending upstream kernel updates as of v6.3-rc6.
>
> Signed-off-by: Nishanth Menon
> ---
> Sent to kernel.org
> https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
Link to actual patch is
https://lore.kernel.org/linux-devicetree/20230414073328.381336-3...@ti.com/
>
> arch/arm/dts/k3-am642-sk.dts | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
> index 4fb279489cfc..cc2027417e86 100644
> --- a/arch/arm/dts/k3-am642-sk.dts
> +++ b/arch/arm/dts/k3-am642-sk.dts
> @@ -223,15 +223,17 @@
>
> _pmx0 {
> main_mmc1_pins_default: main-mmc1-pins-default {
> + /* XXX: Kernel-Upstream: TODO: Upstream (pull changes) */
Do we really want to sprinkle these comments in u-boot upstream?
If we are quite sure this makes to upstream kernel we might as well pull them
into
u-boot as is.
> pinctrl-single,pins = <
> - AM64X_IOPAD(0x0294, PIN_INPUT, 0) /* (J19) MMC1_CMD */
> + AM64X_IOPAD(0x029c, PIN_INPUT_PULLUP, 0) /* (C20)
> MMC1_SDWP */
> + AM64X_IOPAD(0x0298, PIN_INPUT_PULLUP, 0) /* (D19)
> MMC1_SDCD */
> + AM64X_IOPAD(0x0294, PIN_INPUT_PULLUP, 0) /* (J19)
> MMC1_CMD */
> AM64X_IOPAD(0x0290, PIN_INPUT, 0) /* (#N/A) MMC1_CLKLB
> */
> - AM64X_IOPAD(0x028c, PIN_INPUT, 0) /* (L20) MMC1_CLK */
> - AM64X_IOPAD(0x0288, PIN_INPUT, 0) /* (K21) MMC1_DAT0 */
> - AM64X_IOPAD(0x0284, PIN_INPUT, 0) /* (L21) MMC1_DAT1 */
> - AM64X_IOPAD(0x0280, PIN_INPUT, 0) /* (K19) MMC1_DAT2 */
> - AM64X_IOPAD(0x027c, PIN_INPUT, 0) /* (K18) MMC1_DAT3 */
> - AM64X_IOPAD(0x0298, PIN_INPUT, 0) /* (D19) MMC1_SDCD */
> + AM64X_IOPAD(0x028c, PIN_INPUT_PULLDOWN, 0) /* (L20)
> MMC1_CLK */
> + AM64X_IOPAD(0x0288, PIN_INPUT_PULLUP, 0) /* (K21)
> MMC1_DAT0 */
> + AM64X_IOPAD(0x0284, PIN_INPUT_PULLUP, 0) /* (L21)
> MMC1_DAT1 */
> + AM64X_IOPAD(0x0280, PIN_INPUT_PULLUP, 0) /* (K19)
> MMC1_DAT2 */
> + AM64X_IOPAD(0x027c, PIN_INPUT_PULLUP, 0) /* (K18)
> MMC1_DAT3 */
> >;
> };
>
cheers,
-roger
[u-boot PATCH v2 3/3] arm: dts: k3-am64: Fix CPSW3G ethernet
As MDIO driver does not support Driver Model, the
pinctrl settings in the MDIO node will not
be applied resulting in PHY not being detected.
To workaround this we add the MDIO pinctrl in
the CPSW3G node in the -u-boot.dtsi file.
Add the missing MDIO and RGMII pinctrl nodes in
k3-am642-r5-evm.dts
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 3 ++
arch/arm/dts/k3-am642-r5-evm.dts | 41 +++
2 files changed, 44 insertions(+)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index fa7750d634f..9b6c7e85cb4 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -113,6 +113,9 @@
<0x0 0x43000200 0x0 0x8>;
reg-names = "cpsw_nuss", "mac_efuse";
/delete-property/ ranges;
+ pinctrl-0 = <_pins_default/* HACK: as MDIO driver is not
DM enabled */
+_pins_default
+_pins_default>;
cpsw-phy-sel@04044 {
compatible = "ti,am64-phy-gmii-sel";
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index 92a6bfdc011..7493362ac65 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -167,6 +167,47 @@
AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19)
USB0_DRVVBUS */
>;
};
+
+ mdio1_pins_default: mdio1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2)
PRG0_PRU1_GPO19.MDIO0_MDC */
+ AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* (P5)
PRG0_PRU1_GPO18.MDIO0_MDIO */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x01cc, PIN_INPUT, 4) /* (W5)
PRG0_PRU1_GPO7.RGMII1_RD0 */
+ AM64X_IOPAD(0x01d4, PIN_INPUT, 4) /* (Y5)
PRG0_PRU1_GPO9.RGMII1_RD1 */
+ AM64X_IOPAD(0x01d8, PIN_INPUT, 4) /* (V6)
PRG0_PRU1_GPO10.RGMII1_RD2 */
+ AM64X_IOPAD(0x01f4, PIN_INPUT, 4) /* (V5)
PRG0_PRU1_GPO17.RGMII1_RD3 */
+ AM64X_IOPAD(0x0188, PIN_INPUT, 4) /* (AA5)
PRG0_PRU0_GPO10.RGMII1_RXC */
+ AM64X_IOPAD(0x0184, PIN_INPUT, 4) /* (W6)
PRG0_PRU0_GPO9.RGMII1_RX_CTL */
+ AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* (V15)
PRG1_PRU1_GPO7.RGMII1_TD0 */
+ AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* (V14)
PRG1_PRU1_GPO9.RGMII1_TD1 */
+ AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* (W14)
PRG1_PRU1_GPO10.RGMII1_TD2 */
+ AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* (AA14)
PRG1_PRU1_GPO17.RGMII1_TD3 */
+ AM64X_IOPAD(0x00e0, PIN_OUTPUT, 4) /* (U14)
PRG1_PRU0_GPO10.RGMII1_TXC */
+ AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* (U15)
PRG1_PRU0_GPO9.RGMII1_TX_CTL */
+ >;
+ };
+
+ rgmii2_pins_default: rgmii2-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0108, PIN_INPUT, 4) /* (W11)
PRG1_PRU1_GPO0.RGMII2_RD0 */
+ AM64X_IOPAD(0x010c, PIN_INPUT, 4) /* (V11)
PRG1_PRU1_GPO1.RGMII2_RD1 */
+ AM64X_IOPAD(0x0110, PIN_INPUT, 4) /* (AA12)
PRG1_PRU1_GPO2.RGMII2_RD2 */
+ AM64X_IOPAD(0x0114, PIN_INPUT, 4) /* (Y12)
PRG1_PRU1_GPO3.RGMII2_RD3 */
+ AM64X_IOPAD(0x0120, PIN_INPUT, 4) /* (U11)
PRG1_PRU1_GPO6.RGMII2_RXC */
+ AM64X_IOPAD(0x0118, PIN_INPUT, 4) /* (W12)
PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+ AM64X_IOPAD(0x0134, PIN_OUTPUT, 4) /* (AA10)
PRG1_PRU1_GPO11.RGMII2_TD0 */
+ AM64X_IOPAD(0x0138, PIN_OUTPUT, 4) /* (V10)
PRG1_PRU1_GPO12.RGMII2_TD1 */
+ AM64X_IOPAD(0x013c, PIN_OUTPUT, 4) /* (U10)
PRG1_PRU1_GPO13.RGMII2_TD2 */
+ AM64X_IOPAD(0x0140, PIN_OUTPUT, 4) /* (AA11)
PRG1_PRU1_GPO14.RGMII2_TD3 */
+ AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10)
PRG1_PRU1_GPO16.RGMII2_TXC */
+ AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
+ >;
+ };
};
{
--
2.34.1
[u-boot PATCH v2 2/3] arm: dts: k3-am6: Fix "EEPROM not available" error
We need to enable i2c0 so u-boot can read from EEPROM.
Signed-off-by: Roger Quadros
Reviewed-by: Tom Rini
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 055215cff8d..fa7750d634f 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -44,6 +44,7 @@
};
_i2c0 {
+ status = "okay";
u-boot,dm-spl;
pinctrl-names = "default";
pinctrl-0 = <_i2c0_pins_default>;
--
2.34.1
[u-boot PATCH v2 1/3] arm: dts: k3-am64: sync with Linux DT files
Sync AM64 DT files with Linux v6.2-rc4
Signed-off-by: Roger Quadros
Reviewed-by: Tom Rini
---
arch/arm/dts/k3-am64-main.dtsi | 551 +++--
arch/arm/dts/k3-am64-mcu.dtsi | 16 +-
arch/arm/dts/k3-am64.dtsi | 4 +
arch/arm/dts/k3-am642-evm.dts | 117 ---
arch/arm/dts/k3-am642-sk.dts | 225 ++
arch/arm/dts/k3-am642.dtsi | 2 +-
6 files changed, 787 insertions(+), 128 deletions(-)
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 57b0f53ac96..5e8036f32d7 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -59,7 +59,10 @@
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x00 0x0180 0x00 0x1>, /* GICD */
- <0x00 0x0184 0x00 0xC>; /* GICR */
+ <0x00 0x0184 0x00 0xC>, /* GICR */
+ <0x01 0x 0x00 0x2000>,/* GICC */
+ <0x01 0x0001 0x00 0x1000>,/* GICH */
+ <0x01 0x0002 0x00 0x2000>;/* GICV */
/*
* vcpumntirq:
* virtual CPU interface maintenance interrupt
@@ -171,7 +174,7 @@
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
- mboxes= <_proxy_main 12>,
+ mboxes = <_proxy_main 12>,
<_proxy_main 13>;
reg-names = "debug_messages";
reg = <0x00 0x44043000 0x00 0xfe0>;
@@ -217,6 +220,12 @@
reg = <0x4044 0x8>;
#phy-cells = <1>;
};
+
+ epwm_tbclk: clock@4140 {
+ compatible = "ti,am64-epwm-tbclk", "syscon";
+ reg = <0x4130 0x4>;
+ #clock-cells = <1>;
+ };
};
main_uart0: serial@280 {
@@ -228,6 +237,7 @@
power-domains = <_pds 146 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 146 0>;
clock-names = "fclk";
+ status = "disabled";
};
main_uart1: serial@281 {
@@ -239,6 +249,7 @@
power-domains = <_pds 152 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 152 0>;
clock-names = "fclk";
+ status = "disabled";
};
main_uart2: serial@282 {
@@ -250,6 +261,7 @@
power-domains = <_pds 153 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 153 0>;
clock-names = "fclk";
+ status = "disabled";
};
main_uart3: serial@283 {
@@ -261,6 +273,7 @@
power-domains = <_pds 154 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 154 0>;
clock-names = "fclk";
+ status = "disabled";
};
main_uart4: serial@284 {
@@ -272,6 +285,7 @@
power-domains = <_pds 155 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 155 0>;
clock-names = "fclk";
+ status = "disabled";
};
main_uart5: serial@285 {
@@ -283,6 +297,7 @@
power-domains = <_pds 156 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 156 0>;
clock-names = "fclk";
+ status = "disabled";
};
main_uart6: serial@286 {
@@ -294,6 +309,7 @@
power-domains = <_pds 158 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 158 0>;
clock-names = "fclk";
+ status = "disabled";
};
main_i2c0: i2c@2000 {
@@ -305,6 +321,7 @@
power-domains = <_pds 102 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 102 2>;
clock-names = "fck";
+ status = "disabled";
};
main_i2c1: i2c@2001 {
@@ -316,6 +333,7 @@
power-domains = <_pds 103 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 103 2>;
clock-names = "fck";
+ status = "disabled";
};
main_i2c2: i2c@2002 {
@@ -327,6 +345,7 @@
power-domains = <_pds 104 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 104 2>;
clock-names = "fck";
+ status = "disabled";
};
main_i2c3: i2c@2003 {
@@ -338,6 +357,7 @@
[u-boot PATCH v2 0/3] arm: dts: k3-am64: Sync DT files with Linux
Hi, This series syncs AM64 DT files with Linux v6.2-rc4. CPSW and Board EEPROM breakage are resolved in follow up patches. Only MMC and NFS boot have been tested. cheers, -roger Changelog: v2: - move CPSW3G fixes to -u-boot.dtsi file. Roger Quadros (3): arm: dts: k3-am64: sync with Linux DT files arm: dts: k3-am6: Fix "EEPROM not available" error arm: dts: k3-am64: Fix CPSW3G ethernet arch/arm/dts/k3-am64-main.dtsi| 551 +- arch/arm/dts/k3-am64-mcu.dtsi | 16 +- arch/arm/dts/k3-am64.dtsi | 4 + arch/arm/dts/k3-am642-evm-u-boot.dtsi | 4 + arch/arm/dts/k3-am642-evm.dts | 117 +++--- arch/arm/dts/k3-am642-r5-evm.dts | 41 ++ arch/arm/dts/k3-am642-sk.dts | 225 --- arch/arm/dts/k3-am642.dtsi| 2 +- 8 files changed, 832 insertions(+), 128 deletions(-) -- 2.34.1
Re: [u-boot PATCH] arm: dts: k3-am64-main: Add GPMC and ELM nodes
On 09/01/2023 19:29, Tom Rini wrote: > On Wed, Jan 04, 2023 at 11:53:06AM +0200, Roger Quadros wrote: > >> The GPMC is a unified memory controller dedicated for interfacing >> with external memory devices like >> - Asynchronous SRAM-like memories and ASICs >> - Asynchronous, synchronous, and page mode burst NOR flash >> - NAND flash >> - Pseudo-SRAM devices >> >> The ELM module is used for GPMC NAND accesses for detecting >> and correcting errors during reads due to NAND bitflips errors. >> >> 4-, 8-, and 16-bit error-correction levels are supported using >> the BCH (Bose-ChaudhurI-Hocquenghem) algorithm. >> >> Signed-off-by: Roger Quadros >> --- >> arch/arm/dts/k3-am64-main.dtsi | 26 ++ >> 1 file changed, 26 insertions(+) > > Can we get these changes by re-syncing the k3 dts files with the kernel? > Sure, will send an update. cheers, -roger
Re: Pull request for u-boot-nand-20230104
On 07/01/2023 20:46, Dario Binacchi wrote: > Hi, > > On Sat, Jan 7, 2023 at 7:36 PM Tom Rini wrote: >> >> On Sat, Jan 07, 2023 at 07:32:51PM +0100, Dario Binacchi wrote: >>> Hi, >>> >>> On Sat, Jan 7, 2023 at 6:30 PM Tom Rini wrote: >>>> >>>> On Sat, Jan 07, 2023 at 04:48:02PM +0200, Roger Quadros wrote: >>>> >>>>> >>>>> On 07/01/2023 16:19, Roger Quadros wrote: >>>>>> Hi, >>>>>> >>>>>> On 06/01/2023 20:59, Tom Rini wrote: >>>>>>> On Thu, Jan 05, 2023 at 09:10:55AM +0100, Dario Binacchi wrote: >>>>>>> >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> The following changes since commit >>>>>>>> a95410696d21d38b629c61a09c100197c5fc533a: >>>>>>>> >>>>>>>> Merge branch '2023-01-02-platform-updates' into next (2023-01-02 >>>>>>>> 18:07:41 -0500) >>>>>>>> >>>>>>>> are available in the Git repository at: >>>>>>>> >>>>>>>> https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git >>>>>>>> tags/u-boot-nand-20230104 >>>>>>>> >>>>>>>> for you to fetch changes up to >>>>>>>> 48f219cb16f88cd2e392e2f438409a00d3ddff54: >>>>>>>> >>>>>>>> mtd: rawnand: omap_elm: u-boot driver model support (2023-01-04 >>>>>>>> 17:24:30 +0100) >>>>>>>> >>>>>>>> Gitlab CI showed no issues: >>>>>>>> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14597 >>>>>>>> >>>>>>> >>>>>>> NAK. This commit: >>>>>>> commit 48f219cb16f88cd2e392e2f438409a00d3ddff54 >>>>>>> Author: Roger Quadros >>>>>>> Date: Tue Dec 20 12:22:03 2022 +0200 >>>>>>> >>>>>>> mtd: rawnand: omap_elm: u-boot driver model support >>>>>>> >>>>>>> Support u-boot driver model. We still retain >>>>>>> support legacy way of doing things if ELM_BASE >>>>>>> is defined in >>>>>>> >>>>>>> We could completely get rid of that if all >>>>>>> platforms defining ELM_BASE get rid of that definition >>>>>>> and enable CONFIG_SYS_NAND_SELF_INIT and are verified >>>>>>> to work. >>>>>>> >>>>>>> Signed-off-by: Roger Quadros >>>>>>> Signed-off-by: Michael Trimarchi >>>>>>> >>>>>>> Breaks am335x_evm thusly: >>>>>>> U-Boot SPL 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - >>>>>>> 13:56:52 -0500) >>>>>>> Trying to boot from MMC1 >>>>>>> >>>>>>> >>>>>>> U-Boot 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 >>>>>>> -0500) >>>>>>> >>>>>>> CPU : AM335X-GP rev 2.1 >>>>>>> Model: TI AM335x EVM >>>>>>> DRAM: 1 GiB >>>>>>> Error binding driver 'omap-elm': -96 >>>>>>> Some drivers failed to bind >>>>>>> Error binding driver 'ti_sysc': -96 >>>>>>> Some drivers failed to bind >>>>>>> Error binding driver 'simple_bus': -96 >>>>>>> Some drivers failed to bind >>>>>>> Error binding driver 'simple_bus': -96 >>>>>>> Some drivers failed to bind >>>>>>> Error binding driver 'simple_bus': -96 >>>>>>> Some drivers failed to bind >>>>>>> initcall sequence bffdbbe0 failed at call 808155a9 (err=-96) >>>>>>> ### ERROR ### Please RESET the board ### >>>>>>> >>>>>> >>>>>> Sorry about that. My broken am335x-evm has suddenly come alive. >>>>>> I will come up with a fix in a day or two. >>>>> >>>>> The below patch fixes boot on am335x-evm for me. >>>>> >>>>> Does it look reasonable? >>>>> >>>>> From 06e2695f8420a1fa6eaf3fcf2e5dbbf28c73a34d Mon Sep 17 00:00:00 2001 >>>>> From: Roger Quadros >>>>> Date: Sat, 7 Jan 2023 16:40:52 +0200 >>>>> Subject: [PATCH] mtd: rawnand: omap_elm: Fix boot on am335x-evm >>>>> >>>>> Prevent registering with Driver Model if CONFIG_SYS_NAND_SELF_INIT >>>>> is not enabled. >>>>> >>>>> Legacy OMAP2+ systems do not use driver model yet for >>>>> NAND/ELM and don't define CONFIG_SYS_NAND_SELF_INIT. >>>>> >>>>> Signed-off-by: Roger Quadros >>>> >>>> Reviewed-by: Tom Rini >>> >>> If Roger will submit this patch (I still don't see it with patchwork), >>> tomorrow >>> I will add to the other patches, I will run the tests and in case of success >>> I will submit a new pull-request. >>> Is this, Tom, the correct workflow? >> >> Patchwork likely doesn't like a patch in reply to a pull request, and >> I'd assume this should get folded in to the patch in question, to >> prevent breaking bisectability. > > Ok, I will add the changes to the "mtd: rawnand: omap_elm: u-boot > driver model support" patch, > and after the tests I will submit another pull-request. > > Thanks and regards, > Dario Thank you Dario and Tom. cheers, -roger
Re: Pull request for u-boot-nand-20230104
On 07/01/2023 16:19, Roger Quadros wrote:
> Hi,
>
> On 06/01/2023 20:59, Tom Rini wrote:
>> On Thu, Jan 05, 2023 at 09:10:55AM +0100, Dario Binacchi wrote:
>>
>>> Hi Tom,
>>>
>>> The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a:
>>>
>>> Merge branch '2023-01-02-platform-updates' into next (2023-01-02
>>> 18:07:41 -0500)
>>>
>>> are available in the Git repository at:
>>>
>>> https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
>>> tags/u-boot-nand-20230104
>>>
>>> for you to fetch changes up to 48f219cb16f88cd2e392e2f438409a00d3ddff54:
>>>
>>> mtd: rawnand: omap_elm: u-boot driver model support (2023-01-04
>>> 17:24:30 +0100)
>>>
>>> Gitlab CI showed no issues:
>>> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14597
>>>
>>
>> NAK. This commit:
>> commit 48f219cb16f88cd2e392e2f438409a00d3ddff54
>> Author: Roger Quadros
>> Date: Tue Dec 20 12:22:03 2022 +0200
>>
>> mtd: rawnand: omap_elm: u-boot driver model support
>>
>> Support u-boot driver model. We still retain
>> support legacy way of doing things if ELM_BASE
>> is defined in
>>
>> We could completely get rid of that if all
>> platforms defining ELM_BASE get rid of that definition
>> and enable CONFIG_SYS_NAND_SELF_INIT and are verified
>> to work.
>>
>> Signed-off-by: Roger Quadros
>> Signed-off-by: Michael Trimarchi
>>
>> Breaks am335x_evm thusly:
>> U-Boot SPL 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52
>> -0500)
>> Trying to boot from MMC1
>>
>>
>> U-Boot 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 -0500)
>>
>> CPU : AM335X-GP rev 2.1
>> Model: TI AM335x EVM
>> DRAM: 1 GiB
>> Error binding driver 'omap-elm': -96
>> Some drivers failed to bind
>> Error binding driver 'ti_sysc': -96
>> Some drivers failed to bind
>> Error binding driver 'simple_bus': -96
>> Some drivers failed to bind
>> Error binding driver 'simple_bus': -96
>> Some drivers failed to bind
>> Error binding driver 'simple_bus': -96
>> Some drivers failed to bind
>> initcall sequence bffdbbe0 failed at call 808155a9 (err=-96)
>> ### ERROR ### Please RESET the board ###
>>
>
> Sorry about that. My broken am335x-evm has suddenly come alive.
> I will come up with a fix in a day or two.
The below patch fixes boot on am335x-evm for me.
Does it look reasonable?
>From 06e2695f8420a1fa6eaf3fcf2e5dbbf28c73a34d Mon Sep 17 00:00:00 2001
From: Roger Quadros
Date: Sat, 7 Jan 2023 16:40:52 +0200
Subject: [PATCH] mtd: rawnand: omap_elm: Fix boot on am335x-evm
Prevent registering with Driver Model if CONFIG_SYS_NAND_SELF_INIT
is not enabled.
Legacy OMAP2+ systems do not use driver model yet for
NAND/ELM and don't define CONFIG_SYS_NAND_SELF_INIT.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_elm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/raw/omap_elm.c b/drivers/mtd/nand/raw/omap_elm.c
index e528a5348d5..56a2c39e4f6 100644
--- a/drivers/mtd/nand/raw/omap_elm.c
+++ b/drivers/mtd/nand/raw/omap_elm.c
@@ -199,6 +199,8 @@ void elm_init(void)
}
#endif
+#if CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
+
static int elm_probe(struct udevice *dev)
{
#ifndef ELM_BASE
@@ -224,3 +226,4 @@ U_BOOT_DRIVER(gpmc_elm) = {
.of_match = elm_ids,
.probe = elm_probe,
};
+#endif /* CONFIG_SYS_NAND_SELF_INIT */
--
2.34.1
cheers,
-roger
Re: Pull request for u-boot-nand-20230104
Hi, On 06/01/2023 20:59, Tom Rini wrote: > On Thu, Jan 05, 2023 at 09:10:55AM +0100, Dario Binacchi wrote: > >> Hi Tom, >> >> The following changes since commit a95410696d21d38b629c61a09c100197c5fc533a: >> >> Merge branch '2023-01-02-platform-updates' into next (2023-01-02 >> 18:07:41 -0500) >> >> are available in the Git repository at: >> >> https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git >> tags/u-boot-nand-20230104 >> >> for you to fetch changes up to 48f219cb16f88cd2e392e2f438409a00d3ddff54: >> >> mtd: rawnand: omap_elm: u-boot driver model support (2023-01-04 >> 17:24:30 +0100) >> >> Gitlab CI showed no issues: >> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/14597 >> > > NAK. This commit: > commit 48f219cb16f88cd2e392e2f438409a00d3ddff54 > Author: Roger Quadros > Date: Tue Dec 20 12:22:03 2022 +0200 > > mtd: rawnand: omap_elm: u-boot driver model support > > Support u-boot driver model. We still retain > support legacy way of doing things if ELM_BASE > is defined in > > We could completely get rid of that if all > platforms defining ELM_BASE get rid of that definition > and enable CONFIG_SYS_NAND_SELF_INIT and are verified > to work. > > Signed-off-by: Roger Quadros > Signed-off-by: Michael Trimarchi > > Breaks am335x_evm thusly: > U-Boot SPL 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 > -0500) > Trying to boot from MMC1 > > > U-Boot 2023.01-rc4-00388-g48f219cb16f8-dirty (Jan 06 2023 - 13:56:52 -0500) > > CPU : AM335X-GP rev 2.1 > Model: TI AM335x EVM > DRAM: 1 GiB > Error binding driver 'omap-elm': -96 > Some drivers failed to bind > Error binding driver 'ti_sysc': -96 > Some drivers failed to bind > Error binding driver 'simple_bus': -96 > Some drivers failed to bind > Error binding driver 'simple_bus': -96 > Some drivers failed to bind > Error binding driver 'simple_bus': -96 > Some drivers failed to bind > initcall sequence bffdbbe0 failed at call 808155a9 (err=-96) > ### ERROR ### Please RESET the board ### > Sorry about that. My broken am335x-evm has suddenly come alive. I will come up with a fix in a day or two. cheers, -roger
[u-boot PATCH] arm: dts: k3-am64-main: Add GPMC and ELM nodes
The GPMC is a unified memory controller dedicated for interfacing
with external memory devices like
- Asynchronous SRAM-like memories and ASICs
- Asynchronous, synchronous, and page mode burst NOR flash
- NAND flash
- Pseudo-SRAM devices
The ELM module is used for GPMC NAND accesses for detecting
and correcting errors during reads due to NAND bitflips errors.
4-, 8-, and 16-bit error-correction levels are supported using
the BCH (Bose-ChaudhurI-Hocquenghem) algorithm.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am64-main.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 57b0f53ac96..43b0219f247 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -877,4 +877,30 @@
assigned-clocks = <_clks 126 0>;
assigned-clock-parents = <_clks 126 2>;
};
+
+ gpmc0: memory-controller@3b00 {
+ compatible = "ti,am64-gpmc";
+ power-domains = <_pds 80 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 80 0>;
+ clock-names = "fck";
+ reg = <0x00 0x03b00 0x00 0x400>,
+ <0x00 0x05000 0x00 0x800>;
+ reg-names = "cfg", "data";
+ interrupts = ;
+ gpmc,num-cs = <3>;
+ gpmc,num-waitpins = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ elm0: ecc@2501 {
+ compatible = "ti,am64-elm";
+ reg = <0x00 0x2501 0x00 0x2000>;
+ interrupts = ;
+ power-domains = <_pds 54 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 54 0>;
+ clock-names = "fck";
+ };
};
--
2.34.1
Re: [u-boot][PATCH v2 8/8] mtd: rawnand: omap_elm: u-boot driver model support
Hi Michael,
On 22/12/2022 23:35, Michael Nazzareno Trimarchi wrote:
> Hi Roger
>
> On Wed, Dec 21, 2022 at 9:08 PM Michael Nazzareno Trimarchi
> wrote:
>>
>> Hi
>>
>> On Wed, Dec 21, 2022 at 8:57 PM Roger Quadros wrote:
>>>
>>> Hi Michael,
>>>
>>> On 21/12/2022 19:56, Michael Nazzareno Trimarchi wrote:
>>>> Hi Roger
>>>>
>>>> On Tue, Dec 20, 2022 at 11:22 AM Roger Quadros wrote:
>>>>>
>>>>> Support u-boot driver model. We still retain
>>>>> support legacy way of doing things if ELM_BASE
>>>>> is defined in
>>>>>
>>>>> We could completely get rid of that if all
>>>>> platforms defining ELM_BASE get rid of that definition
>>>>> and enable CONFIG_SYS_NAND_SELF_INIT and are verified
>>>>> to work.
>>>>>
>>>>> Signed-off-by: Roger Quadros
>>>>> ---
>>>>
>>>> When you post please include the relative changelog
>>>
>>> I put the changelog in the cover-letter.
>>>
>>
>> My bad, I'm always start from patch 1 and look on changes in every single
>> patch
>>
>
> Pipeline is running, I have fixed another minor problem in the build
Thanks. You mean __maybe_unused for omap_calculate_ecc_bch()?
cheers,
-roger
>
> Michael
>
>> Michael
>>
>>>
>>> cheers,
>>> -roger
>>>
>>>>
>>>> Michael
>>>>
>>>>> drivers/mtd/nand/raw/omap_elm.c | 35 ++-
>>>>> .../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6
>>>>> drivers/mtd/nand/raw/omap_gpmc.c | 12 ++-
>>>>> 3 files changed, 51 insertions(+), 2 deletions(-)
>>>>> rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
>>>>>
>>>>> diff --git a/drivers/mtd/nand/raw/omap_elm.c
>>>>> b/drivers/mtd/nand/raw/omap_elm.c
>>>>> index 35c6dd1f1bc..e528a5348d5 100644
>>>>> --- a/drivers/mtd/nand/raw/omap_elm.c
>>>>> +++ b/drivers/mtd/nand/raw/omap_elm.c
>>>>> @@ -15,9 +15,14 @@
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> -#include
>>>>> #include
>>>>>
>>>>> +#include
>>>>> +#include
>>>>> +#include
>>>>> +
>>>>> +#include "omap_elm.h"
>>>>> +
>>>>> #define DRIVER_NAME"omap-elm"
>>>>> #define ELM_DEFAULT_POLY (0)
>>>>>
>>>>> @@ -180,6 +185,7 @@ void elm_reset(void)
>>>>> ;
>>>>> }
>>>>>
>>>>> +#ifdef ELM_BASE
>>>>> /**
>>>>> * elm_init - Initialize ELM module
>>>>> *
>>>>> @@ -191,3 +197,30 @@ void elm_init(void)
>>>>> elm_cfg = (struct elm *)ELM_BASE;
>>>>> elm_reset();
>>>>> }
>>>>> +#endif
>>>>> +
>>>>> +static int elm_probe(struct udevice *dev)
>>>>> +{
>>>>> +#ifndef ELM_BASE
>>>>> + struct resource res;
>>>>> +
>>>>> + dev_read_resource(dev, 0, );
>>>>> + elm_cfg = devm_ioremap(dev, res.start, resource_size());
>>>>> + elm_reset();
>>>>> +#endif
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct udevice_id elm_ids[] = {
>>>>> + { .compatible = "ti,am3352-elm" },
>>>>> + { .compatible = "ti,am64-elm" },
>>>>> + { }
>>>>> +};
>>>>> +
>>>>> +U_BOOT_DRIVER(gpmc_elm) = {
>>>>> + .name = DRIVER_NAME,
>>>>> + .id = UCLASS_MTD,
>>>>> + .of_match = elm_ids,
>>>>> + .probe = elm_probe,
>>>>> +};
>>>>> diff --git a/include/linux/mtd/omap_elm.h
>>>>> b/drivers/mtd/nand/raw/omap_elm.h
>>>>> similarity index 97%
>>>>> rename from include/linux/mtd/omap_elm.h
>>>>> rename to drivers/mtd/nand/raw/omap_elm.h
>>>>> index f3db00d55de..a7f7bacb154 100644
>>>
Re: [u-boot][PATCH v2 8/8] mtd: rawnand: omap_elm: u-boot driver model support
Hi Michael,
On 21/12/2022 19:56, Michael Nazzareno Trimarchi wrote:
> Hi Roger
>
> On Tue, Dec 20, 2022 at 11:22 AM Roger Quadros wrote:
>>
>> Support u-boot driver model. We still retain
>> support legacy way of doing things if ELM_BASE
>> is defined in
>>
>> We could completely get rid of that if all
>> platforms defining ELM_BASE get rid of that definition
>> and enable CONFIG_SYS_NAND_SELF_INIT and are verified
>> to work.
>>
>> Signed-off-by: Roger Quadros
>> ---
>
> When you post please include the relative changelog
I put the changelog in the cover-letter.
cheers,
-roger
>
> Michael
>
>> drivers/mtd/nand/raw/omap_elm.c | 35 ++-
>> .../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6
>> drivers/mtd/nand/raw/omap_gpmc.c | 12 ++-
>> 3 files changed, 51 insertions(+), 2 deletions(-)
>> rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
>>
>> diff --git a/drivers/mtd/nand/raw/omap_elm.c
>> b/drivers/mtd/nand/raw/omap_elm.c
>> index 35c6dd1f1bc..e528a5348d5 100644
>> --- a/drivers/mtd/nand/raw/omap_elm.c
>> +++ b/drivers/mtd/nand/raw/omap_elm.c
>> @@ -15,9 +15,14 @@
>> #include
>> #include
>> #include
>> -#include
>> #include
>>
>> +#include
>> +#include
>> +#include
>> +
>> +#include "omap_elm.h"
>> +
>> #define DRIVER_NAME"omap-elm"
>> #define ELM_DEFAULT_POLY (0)
>>
>> @@ -180,6 +185,7 @@ void elm_reset(void)
>> ;
>> }
>>
>> +#ifdef ELM_BASE
>> /**
>> * elm_init - Initialize ELM module
>> *
>> @@ -191,3 +197,30 @@ void elm_init(void)
>> elm_cfg = (struct elm *)ELM_BASE;
>> elm_reset();
>> }
>> +#endif
>> +
>> +static int elm_probe(struct udevice *dev)
>> +{
>> +#ifndef ELM_BASE
>> + struct resource res;
>> +
>> + dev_read_resource(dev, 0, );
>> + elm_cfg = devm_ioremap(dev, res.start, resource_size());
>> + elm_reset();
>> +#endif
>> +
>> + return 0;
>> +}
>> +
>> +static const struct udevice_id elm_ids[] = {
>> + { .compatible = "ti,am3352-elm" },
>> + { .compatible = "ti,am64-elm" },
>> + { }
>> +};
>> +
>> +U_BOOT_DRIVER(gpmc_elm) = {
>> + .name = DRIVER_NAME,
>> + .id = UCLASS_MTD,
>> + .of_match = elm_ids,
>> + .probe = elm_probe,
>> +};
>> diff --git a/include/linux/mtd/omap_elm.h b/drivers/mtd/nand/raw/omap_elm.h
>> similarity index 97%
>> rename from include/linux/mtd/omap_elm.h
>> rename to drivers/mtd/nand/raw/omap_elm.h
>> index f3db00d55de..a7f7bacb154 100644
>> --- a/include/linux/mtd/omap_elm.h
>> +++ b/drivers/mtd/nand/raw/omap_elm.h
>> @@ -74,6 +74,12 @@ int elm_check_error(u8 *syndrome, enum bch_level
>> bch_type, u32 *error_count,
>> u32 *error_locations);
>> int elm_config(enum bch_level level);
>> void elm_reset(void);
>> +#ifdef ELM_BASE
>> void elm_init(void);
>> +#else
>> +static inline void elm_init(void)
>> +{
>> +}
>> +#endif
>> #endif /* __ASSEMBLY__ */
>> #endif /* __ASM_ARCH_ELM_H */
>> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
>> b/drivers/mtd/nand/raw/omap_gpmc.c
>> index ed6cdf93ad0..9692b78da3c 100644
>> --- a/drivers/mtd/nand/raw/omap_gpmc.c
>> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
>> @@ -20,7 +20,8 @@
>> #include
>> #include
>> #include
>> -#include
>> +
>> +#include "omap_elm.h"
>>
>> #ifndef GPMC_MAX_CS
>> #define GPMC_MAX_CS4
>> @@ -1249,6 +1250,15 @@ void board_nand_init(void)
>> struct udevice *dev;
>> int ret;
>>
>> +#ifdef CONFIG_NAND_OMAP_ELM
>> + ret = uclass_get_device_by_driver(UCLASS_MTD,
>> + DM_DRIVER_GET(gpmc_elm), );
>> + if (ret && ret != -ENODEV) {
>> + pr_err("%s: Failed to get ELM device: %d\n", __func__, ret);
>> + return;
>> + }
>> +#endif
>> +
>> ret = uclass_get_device_by_driver(UCLASS_MTD,
>> DM_DRIVER_GET(gpmc_nand), );
>> if (ret && ret != -ENODEV)
>> --
>> 2.34.1
>>
>
>
[u-boot][PATCH v2 8/8] mtd: rawnand: omap_elm: u-boot driver model support
Support u-boot driver model. We still retain
support legacy way of doing things if ELM_BASE
is defined in
We could completely get rid of that if all
platforms defining ELM_BASE get rid of that definition
and enable CONFIG_SYS_NAND_SELF_INIT and are verified
to work.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/omap_elm.c | 35 ++-
.../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6
drivers/mtd/nand/raw/omap_gpmc.c | 12 ++-
3 files changed, 51 insertions(+), 2 deletions(-)
rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
diff --git a/drivers/mtd/nand/raw/omap_elm.c b/drivers/mtd/nand/raw/omap_elm.c
index 35c6dd1f1bc..e528a5348d5 100644
--- a/drivers/mtd/nand/raw/omap_elm.c
+++ b/drivers/mtd/nand/raw/omap_elm.c
@@ -15,9 +15,14 @@
#include
#include
#include
-#include
#include
+#include
+#include
+#include
+
+#include "omap_elm.h"
+
#define DRIVER_NAME"omap-elm"
#define ELM_DEFAULT_POLY (0)
@@ -180,6 +185,7 @@ void elm_reset(void)
;
}
+#ifdef ELM_BASE
/**
* elm_init - Initialize ELM module
*
@@ -191,3 +197,30 @@ void elm_init(void)
elm_cfg = (struct elm *)ELM_BASE;
elm_reset();
}
+#endif
+
+static int elm_probe(struct udevice *dev)
+{
+#ifndef ELM_BASE
+ struct resource res;
+
+ dev_read_resource(dev, 0, );
+ elm_cfg = devm_ioremap(dev, res.start, resource_size());
+ elm_reset();
+#endif
+
+ return 0;
+}
+
+static const struct udevice_id elm_ids[] = {
+ { .compatible = "ti,am3352-elm" },
+ { .compatible = "ti,am64-elm" },
+ { }
+};
+
+U_BOOT_DRIVER(gpmc_elm) = {
+ .name = DRIVER_NAME,
+ .id = UCLASS_MTD,
+ .of_match = elm_ids,
+ .probe = elm_probe,
+};
diff --git a/include/linux/mtd/omap_elm.h b/drivers/mtd/nand/raw/omap_elm.h
similarity index 97%
rename from include/linux/mtd/omap_elm.h
rename to drivers/mtd/nand/raw/omap_elm.h
index f3db00d55de..a7f7bacb154 100644
--- a/include/linux/mtd/omap_elm.h
+++ b/drivers/mtd/nand/raw/omap_elm.h
@@ -74,6 +74,12 @@ int elm_check_error(u8 *syndrome, enum bch_level bch_type,
u32 *error_count,
u32 *error_locations);
int elm_config(enum bch_level level);
void elm_reset(void);
+#ifdef ELM_BASE
void elm_init(void);
+#else
+static inline void elm_init(void)
+{
+}
+#endif
#endif /* __ASSEMBLY__ */
#endif /* __ASM_ARCH_ELM_H */
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index ed6cdf93ad0..9692b78da3c 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -20,7 +20,8 @@
#include
#include
#include
-#include
+
+#include "omap_elm.h"
#ifndef GPMC_MAX_CS
#define GPMC_MAX_CS4
@@ -1249,6 +1250,15 @@ void board_nand_init(void)
struct udevice *dev;
int ret;
+#ifdef CONFIG_NAND_OMAP_ELM
+ ret = uclass_get_device_by_driver(UCLASS_MTD,
+ DM_DRIVER_GET(gpmc_elm), );
+ if (ret && ret != -ENODEV) {
+ pr_err("%s: Failed to get ELM device: %d\n", __func__, ret);
+ return;
+ }
+#endif
+
ret = uclass_get_device_by_driver(UCLASS_MTD,
DM_DRIVER_GET(gpmc_nand), );
if (ret && ret != -ENODEV)
--
2.34.1
[u-boot][PATCH v2 7/8] dt-bindings: mtd: Add ti, elm DT binding documentation
Adds DT binding documentation for the TI Error Location Module.
This is picked up from the Linux Kernel.
Signed-off-by: Roger Quadros
---
doc/device-tree-bindings/mtd/ti,elm.yaml | 72
1 file changed, 72 insertions(+)
create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
diff --git a/doc/device-tree-bindings/mtd/ti,elm.yaml
b/doc/device-tree-bindings/mtd/ti,elm.yaml
new file mode 100644
index 000..87128c00459
--- /dev/null
+++ b/doc/device-tree-bindings/mtd/ti,elm.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/ti,elm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments Error Location Module (ELM).
+
+maintainers:
+ - Roger Quadros
+
+description:
+ ELM module is used together with GPMC and NAND Flash to detect
+ errors and the location of the error based on BCH algorithms
+ so they can be corrected if possible.
+
+properties:
+ compatible:
+enum:
+ - ti,am3352-elm
+ - ti,am64-elm
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+description: Functional clock.
+
+ clock-names:
+items:
+ - const: fck
+
+ power-domains:
+maxItems: 1
+
+ ti,hwmods:
+description:
+ Name of the HWMOD associated with ELM. This is for legacy
+ platforms only.
+$ref: /schemas/types.yaml#/definitions/string
+deprecated: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,am64-elm
+then:
+ required:
+- clocks
+- clock-names
+- power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+elm: ecc@0 {
+compatible = "ti,am3352-elm";
+reg = <0x0 0x2000>;
+interrupts = <4>;
+};
--
2.34.1
[u-boot][PATCH v2 6/8] mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
The symbol is required for NAND support in SPL when using OMAP_GPMC driver. Signed-off-by: Roger Quadros --- drivers/mtd/nand/raw/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index e53c9284a0d..458b5faeb65 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -574,7 +574,8 @@ config SYS_NAND_ONFI_DETECTION config SYS_NAND_PAGE_COUNT hex "NAND chip page count" depends on SPL_NAND_SUPPORT && (NAND_ATMEL || NAND_MXC || \ - SPL_NAND_AM33XX_BCH || SPL_NAND_LOAD || SPL_NAND_SIMPLE) + SPL_NAND_AM33XX_BCH || SPL_NAND_LOAD || SPL_NAND_SIMPLE || \ + NAND_OMAP_GPMC) help Number of pages in the NAND chip. -- 2.34.1
[u-boot][PATCH v2 5/8] mtd: rawnand: omap_gpmc: Add SPL NAND support
Enables SPL NAND support for ARCH_K3 by enabling
SPL_NAND_INIT and SPL_SYS_NAND_SELF_INIT.
Legacy OMAP2plus platforms still rely on SPL_NAND_AM33XX_BCH
instead.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/Kconfig | 5
drivers/mtd/nand/raw/Makefile| 2 +-
drivers/mtd/nand/raw/omap_gpmc.c | 40
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 3f4851b93bd..e53c9284a0d 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -26,6 +26,9 @@ config TPL_SYS_NAND_SELF_INIT
config TPL_NAND_INIT
bool
+config SPL_NAND_INIT
+ bool
+
config SYS_MAX_NAND_DEVICE
int "Maximum number of NAND devices to support"
default 1
@@ -199,6 +202,8 @@ config NAND_OMAP_GPMC
bool "Support OMAP GPMC NAND controller"
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
select SYS_NAND_SELF_INIT if ARCH_K3
+ select SPL_NAND_INIT if ARCH_K3
+ select SPL_SYS_NAND_SELF_INIT if ARCH_K3
help
Enables omap_gpmc.c driver for OMAPx and AM platforms.
GPMC controller is used for parallel NAND flash devices, and can
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index a398aa9d886..6fe33d2485b 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SPL_NAND_BASE) += nand_base.o nand_amd.o
nand_hynix.o \
nand_macronix.o nand_micron.o \
nand_samsung.o nand_toshiba.o
obj-$(CONFIG_SPL_NAND_IDENT) += nand_ids.o nand_timings.o
-obj-$(CONFIG_TPL_NAND_INIT) += nand.o
+obj-$(CONFIG_$(SPL_TPL_)NAND_INIT) += nand.o
ifeq ($(CONFIG_SPL_ENV_SUPPORT),y)
obj-$(CONFIG_ENV_IS_IN_NAND) += nand_util.o
endif
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 61e025db9a5..ed6cdf93ad0 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -1263,3 +1263,43 @@ int board_nand_init(struct nand_chip *nand)
}
#endif /* CONFIG_SYS_NAND_SELF_INIT */
+
+#if defined(CONFIG_SPL_NAND_INIT)
+
+/* nand_init() is provided by nand.c */
+
+/* Unselect after operation */
+void nand_deselect(void)
+{
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
+
+ if (nand_chip->select_chip)
+ nand_chip->select_chip(mtd, -1);
+}
+
+static int nand_is_bad_block(int block)
+{
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
+
+ loff_t ofs = block * CONFIG_SYS_NAND_BLOCK_SIZE;
+
+ return nand_chip->block_bad(mtd, ofs);
+}
+
+static int nand_read_page(int block, int page, uchar *dst)
+{
+ int page_addr = block * CONFIG_SYS_NAND_PAGE_COUNT + page;
+ loff_t ofs = page_addr * CONFIG_SYS_NAND_PAGE_SIZE;
+ int ret;
+ size_t len = CONFIG_SYS_NAND_PAGE_SIZE;
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
+
+ ret = nand_read(mtd, ofs, , dst);
+ if (ret)
+ printf("nand_read failed %d\n", ret);
+
+ return ret;
+}
+
+#include "nand_spl_loaders.c"
+#endif /* CONFIG_SPL_NAND_INIT */
--
2.34.1
[u-boot][PATCH v2 4/8] mtd: rawnand: omap_gpmc: support u-boot driver model
Adds driver model support.
We need to be able to self initialize the NAND controller/chip
at probe and so enable CONFIG_SYS_NAND_SELF_INIT.
Doing so requires nand_register() API which is provided by nand.c
and needs to be enabled during SPL build via CONFIG_SPL_NAND_INIT.
But nand.c also provides nand_init() so we need to get rid of nand_init()
in omap_gpmc driver if CONFIG_SPL_NAND_INIT is set.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/omap_gpmc.c | 64 +++-
2 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 8aaba8b1a2c..3f4851b93bd 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -198,6 +198,7 @@ config NAND_LPC32XX_SLC
config NAND_OMAP_GPMC
bool "Support OMAP GPMC NAND controller"
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
+ select SYS_NAND_SELF_INIT if ARCH_K3
help
Enables omap_gpmc.c driver for OMAPx and AM platforms.
GPMC controller is used for parallel NAND flash devices, and can
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index e772a914c88..61e025db9a5 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_ARCH_OMAP2PLUS
@@ -1121,7 +1122,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
hardware, uint32_t eccstrength)
* nand_scan about special functionality. See the defines for further
* explanation
*/
-int board_nand_init(struct nand_chip *nand)
+int gpmc_nand_init(struct nand_chip *nand)
{
int32_t gpmc_config = 0;
int cs = cs_next++;
@@ -1201,3 +1202,64 @@ int board_nand_init(struct nand_chip *nand)
return 0;
}
+
+/* First NAND chip for SPL use only */
+static __maybe_unused struct nand_chip *nand_chip;
+
+#if CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
+
+static int gpmc_nand_probe(struct udevice *dev)
+{
+ struct nand_chip *nand = dev_get_priv(dev);
+ struct mtd_info *mtd = nand_to_mtd(nand);
+ int ret;
+
+ gpmc_nand_init(nand);
+
+ ret = nand_scan(mtd, CONFIG_SYS_NAND_MAX_CHIPS);
+ if (ret)
+ return ret;
+
+ ret = nand_register(0, mtd);
+ if (ret)
+ return ret;
+
+ if (!nand_chip)
+ nand_chip = nand;
+
+ return 0;
+}
+
+static const struct udevice_id gpmc_nand_ids[] = {
+ { .compatible = "ti,am64-nand" },
+ { .compatible = "ti,omap2-nand" },
+ { }
+};
+
+U_BOOT_DRIVER(gpmc_nand) = {
+ .name = "gpmc-nand",
+ .id = UCLASS_MTD,
+ .of_match = gpmc_nand_ids,
+ .probe = gpmc_nand_probe,
+ .priv_auto = sizeof(struct nand_chip),
+};
+
+void board_nand_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MTD,
+ DM_DRIVER_GET(gpmc_nand), );
+ if (ret && ret != -ENODEV)
+ pr_err("%s: Failed to get GPMC device: %d\n", __func__, ret);
+}
+
+#else
+
+int board_nand_init(struct nand_chip *nand)
+{
+ return gpmc_nand_init(nand);
+}
+
+#endif /* CONFIG_SYS_NAND_SELF_INIT */
--
2.34.1
[u-boot][PATCH v2 3/8] dt-bindings: mtd: Add ti, gpmc-nand DT binding documentation
Add DT binding documentation for the TI GPMC NAND controller.
This is picked up from the Linux Kernel.
Signed-off-by: Roger Quadros
---
.../mtd/ti,gpmc-nand.yaml | 129 ++
1 file changed, 129 insertions(+)
create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
diff --git a/doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
b/doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
new file mode 100644
index 000..4ac198814b7
--- /dev/null
+++ b/doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/ti,gpmc-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments GPMC NAND Flash controller.
+
+maintainers:
+ - Tony Lindgren
+ - Roger Quadros
+
+description:
+ GPMC NAND controller/Flash is represented as a child of the
+ GPMC controller node.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - ti,am64-nand
+ - ti,omap2-nand
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description: Interrupt for fifoevent
+ - description: Interrupt for termcount
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ ti,nand-ecc-opt:
+description: Desired ECC algorithm
+$ref: /schemas/types.yaml#/definitions/string
+enum: [sw, ham1, bch4, bch8, bch16]
+
+ ti,nand-xfer-type:
+description: Data transfer method between controller and chip.
+$ref: /schemas/types.yaml#/definitions/string
+enum: [prefetch-polled, polled, prefetch-dma, prefetch-irq]
+default: prefetch-polled
+
+ ti,elm-id:
+description:
+ phandle to the ELM (Error Location Module).
+$ref: /schemas/types.yaml#/definitions/phandle
+
+ nand-bus-width:
+description:
+ Bus width to the NAND chip
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [8, 16]
+default: 8
+
+ rb-gpios:
+description:
+ GPIO connection to R/B signal from NAND chip
+maxItems: 1
+
+patternProperties:
+ "@[0-9a-f]+$":
+$ref: "/schemas/mtd/partitions/partition.yaml"
+
+allOf:
+ - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml"
+
+required:
+ - compatible
+ - reg
+ - ti,nand-ecc-opt
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+
+gpmc: memory-controller@5000 {
+ compatible = "ti,am3352-gpmc";
+ dmas = < 52 0>;
+ dma-names = "rxtx";
+ clocks = <_gclk>;
+ clock-names = "fck";
+ reg = <0x5000 0x2000>;
+ interrupts = ;
+ gpmc,num-cs = <7>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ ranges = <0 0 0x0800 0x0100>; /* CS0 space. Min partition =
16MB */
+ nand@0,0 {
+compatible = "ti,omap2-nand";
+reg = <0 0 4>; /* device IO registers */
+interrupt-parent = <>;
+interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
+ <1 IRQ_TYPE_NONE>; /* termcount */
+ti,nand-xfer-type = "prefetch-dma";
+ti,nand-ecc-opt = "bch16";
+ti,elm-id = <>;
+#address-cells = <1>;
+#size-cells = <1>;
+
+/* NAND generic properties */
+nand-bus-width = <8>;
+rb-gpios = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
+
+/* GPMC properties*/
+gpmc,device-width = <1>;
+
+partition@0 {
+ label = "NAND.SPL";
+ reg = <0x 0x0004>;
+};
+partition@1 {
+ label = "NAND.SPL.backup1";
+ reg = <0x0004 0x0004>;
+};
+ };
+};
--
2.34.1
[u-boot][PATCH v2 1/8] mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
The BCH detection hardware can generate ECC bytes for multiple
sectors in one go. Use that feature.
correct() only corrects one sector at a time so we need to call it
repeatedly for each sector.
Signed-off-by: Roger Quadros
Reviewed-by: Michael Trimarchi
---
drivers/mtd/nand/raw/omap_gpmc.c | 325 +--
1 file changed, 223 insertions(+), 102 deletions(-)
diff --git a/drivers/mtd/nand/raw/omap_gpmc.c b/drivers/mtd/nand/raw/omap_gpmc.c
index 69fc09be097..e772a914c88 100644
--- a/drivers/mtd/nand/raw/omap_gpmc.c
+++ b/drivers/mtd/nand/raw/omap_gpmc.c
@@ -27,6 +27,9 @@
#define BADBLOCK_MARKER_LENGTH 2
#define SECTOR_BYTES 512
+#define ECCSIZE0_SHIFT 12
+#define ECCSIZE1_SHIFT 22
+#define ECC1RESULTSIZE 0x1
#define ECCCLEAR (0x1 << 8)
#define ECCRESULTREG1 (0x1 << 0)
/* 4 bit padding to make byte aligned, 56 = 52 + 4 */
@@ -186,72 +189,35 @@ static int __maybe_unused omap_correct_data(struct
mtd_info *mtd, uint8_t *dat,
__maybe_unused
static void omap_enable_hwecc(struct mtd_info *mtd, int32_t mode)
{
- struct nand_chip*nand = mtd_to_nand(mtd);
- struct omap_nand_info *info = nand_get_controller_data(nand);
+ struct nand_chip *nand = mtd_to_nand(mtd);
+ struct omap_nand_info *info = nand_get_controller_data(nand);
unsigned int dev_width = (nand->options & NAND_BUSWIDTH_16) ? 1 : 0;
- unsigned int ecc_algo = 0;
- unsigned int bch_type = 0;
- unsigned int eccsize1 = 0x00, eccsize0 = 0x00, bch_wrapmode = 0x00;
- u32 ecc_size_config_val = 0;
- u32 ecc_config_val = 0;
- int cs = info->cs;
+ u32 val;
- /* configure GPMC for specific ecc-scheme */
- switch (info->ecc_scheme) {
- case OMAP_ECC_HAM1_CODE_SW:
- return;
- case OMAP_ECC_HAM1_CODE_HW:
- ecc_algo = 0x0;
- bch_type = 0x0;
- bch_wrapmode = 0x00;
- eccsize0 = 0xFF;
- eccsize1 = 0xFF;
+ /* Clear ecc and enable bits */
+ writel(ECCCLEAR | ECCRESULTREG1, _cfg->ecc_control);
+
+ /* program ecc and result sizes */
+ val = nand->ecc.size >> 1) - 1) << ECCSIZE1_SHIFT) |
+ ECC1RESULTSIZE);
+ writel(val, _cfg->ecc_size_config);
+
+ switch (mode) {
+ case NAND_ECC_READ:
+ case NAND_ECC_WRITE:
+ writel(ECCCLEAR | ECCRESULTREG1, _cfg->ecc_control);
break;
- case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
- case OMAP_ECC_BCH8_CODE_HW:
- ecc_algo = 0x1;
- bch_type = 0x1;
- if (mode == NAND_ECC_WRITE) {
- bch_wrapmode = 0x01;
- eccsize0 = 0; /* extra bits in nibbles per sector */
- eccsize1 = 28; /* OOB bits in nibbles per sector */
- } else {
- bch_wrapmode = 0x01;
- eccsize0 = 26; /* ECC bits in nibbles per sector */
- eccsize1 = 2; /* non-ECC bits in nibbles per sector */
- }
- break;
- case OMAP_ECC_BCH16_CODE_HW:
- ecc_algo = 0x1;
- bch_type = 0x2;
- if (mode == NAND_ECC_WRITE) {
- bch_wrapmode = 0x01;
- eccsize0 = 0; /* extra bits in nibbles per sector */
- eccsize1 = 52; /* OOB bits in nibbles per sector */
- } else {
- bch_wrapmode = 0x01;
- eccsize0 = 52; /* ECC bits in nibbles per sector */
- eccsize1 = 0; /* non-ECC bits in nibbles per sector */
- }
+ case NAND_ECC_READSYN:
+ writel(ECCCLEAR, _cfg->ecc_control);
break;
default:
- return;
+ printf("%s: error: unrecognized Mode[%d]!\n", __func__, mode);
+ break;
}
- /* Clear ecc and enable bits */
- writel(ECCCLEAR | ECCRESULTREG1, _cfg->ecc_control);
- /* Configure ecc size for BCH */
- ecc_size_config_val = (eccsize1 << 22) | (eccsize0 << 12);
- writel(ecc_size_config_val, _cfg->ecc_size_config);
-
- /* Configure device details for BCH engine */
- ecc_config_val = ((ecc_algo << 16) | /* HAM1 | BCHx */
- (bch_type << 12)| /* BCH4/BCH8/BCH16 */
- (bch_wrapmode << 8) | /* wrap mode */
- (dev_width << 7)| /* bus width */
- (0x0 << 4) | /* number of sectors */
- (cs << 1) | /* ECC CS */
- (0x1)); /* enable ECC */
- writel(ecc_config_val, _cfg-&g
[u-boot][PATCH v2 2/8] mtd: rawnand: nand_base: Allow base driver to be used in SPL without nand_bbt
nand_bbt.c is not being built with the nand_base driver during SPL
build. This results in build failures if we try to access any nand_bbt
related functions.
Don't use any nand_bbt functions for SPL build.
Signed-off-by: Roger Quadros
---
drivers/mtd/nand/raw/nand_base.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index bc61ad03eb0..9eba360d55f 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -447,7 +447,10 @@ static int nand_default_block_markbad(struct mtd_info
*mtd, loff_t ofs)
static int nand_block_markbad_lowlevel(struct mtd_info *mtd, loff_t ofs)
{
struct nand_chip *chip = mtd_to_nand(mtd);
- int res, ret = 0;
+ int ret = 0;
+#ifndef CONFIG_SPL_BUILD
+ int res;
+#endif
if (!(chip->bbt_options & NAND_BBT_NO_OOB_BBM)) {
struct erase_info einfo;
@@ -465,12 +468,14 @@ static int nand_block_markbad_lowlevel(struct mtd_info
*mtd, loff_t ofs)
nand_release_device(mtd);
}
+#ifndef CONFIG_SPL_BUILD
/* Mark block bad in BBT */
if (chip->bbt) {
res = nand_markbad_bbt(mtd, ofs);
if (!ret)
ret = res;
}
+#endif
if (!ret)
mtd->ecc_stats.badblocks++;
@@ -517,7 +522,11 @@ static int nand_block_isreserved(struct mtd_info *mtd,
loff_t ofs)
if (!chip->bbt)
return 0;
/* Return info from the table */
+#ifndef CONFIG_SPL_BUILD
return nand_isreserved_bbt(mtd, ofs);
+#else
+ return 0;
+#endif
}
/**
@@ -543,7 +552,11 @@ static int nand_block_checkbad(struct mtd_info *mtd,
loff_t ofs, int allowbbt)
return chip->block_bad(mtd, ofs);
/* Return info from the table */
+#ifndef CONFIG_SPL_BUILD
return nand_isbad_bbt(mtd, ofs, allowbbt);
+#else
+ return 0;
+#endif
}
/**
@@ -3752,8 +3765,11 @@ static void nand_set_defaults(struct nand_chip *chip,
int busw)
chip->write_byte = busw ? nand_write_byte16 : nand_write_byte;
if (!chip->read_buf || chip->read_buf == nand_read_buf)
chip->read_buf = busw ? nand_read_buf16 : nand_read_buf;
+
+#ifndef CONFIG_SPL_BUILD
if (!chip->scan_bbt)
chip->scan_bbt = nand_default_bbt;
+#endif
if (!chip->controller) {
chip->controller = >hwcontrol;
--
2.34.1
[u-boot][PATCH v2 0/8] rawnand: omap_gpmc: driver model support
Hi Michael & Dario,
This series adds driver model support for rawnand: omap_gpmc
and omap_elm drivers.
This will enable the driver to be used on K2/K3 platforms as well.
This series along with remaining patches required to get NAND working on
AM6x EVM is available here
https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-2.0
cheers,
-roger
Changelog:
v2:
- Fixed build warning and failures for am335x_guardian, chiliboard, and cm_t32
- use __maybe_unused struct nand_chip to fix build warning
- make elm_probe() a NOP if ELM_BASE is defined. This should not interfere
with existing platforms that don't use Driver Model for ELM driver.
Roger Quadros (8):
mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
mtd: rawnand: nand_base: Allow base driver to be used in SPL without
nand_bbt
dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation
mtd: rawnand: omap_gpmc: support u-boot driver model
mtd: rawnand: omap_gpmc: Add SPL NAND support
mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
dt-bindings: mtd: Add ti,elm DT binding documentation
mtd: rawnand: omap_elm: u-boot driver model support
doc/device-tree-bindings/mtd/ti,elm.yaml | 72 +++
.../mtd/ti,gpmc-nand.yaml | 129 +
drivers/mtd/nand/raw/Kconfig | 9 +-
drivers/mtd/nand/raw/Makefile | 2 +-
drivers/mtd/nand/raw/nand_base.c | 18 +-
drivers/mtd/nand/raw/omap_elm.c | 35 +-
.../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6 +
drivers/mtd/nand/raw/omap_gpmc.c | 441 +-
8 files changed, 604 insertions(+), 108 deletions(-)
create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
--
2.34.1
Re: [u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support
On 17/12/2022 15:51, Michael Nazzareno Trimarchi wrote: > Hi > > Minimal diff > > diff --git a/configs/chiliboard_defconfig b/configs/chiliboard_defconfig > index 458c4558fd..c7f8fd2e25 100644 > --- a/configs/chiliboard_defconfig > +++ b/configs/chiliboard_defconfig > @@ -47,12 +47,14 @@ CONFIG_CMD_MTDPARTS=y > CONFIG_MTDIDS_DEFAULT="nand0=800.nand" > > CONFIG_MTDPARTS_DEFAULT="mtdparts=800.nand:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)" > CONFIG_OF_CONTROL=y > +CONFIG_SPL_OF_CONTROL=y > CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_IS_IN_MMC=y > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_NET_RETRY_COUNT=10 > CONFIG_BOOTP_SEND_HOSTNAME=y > +CONFIG_SPL_DM=y > CONFIG_BOOTCOUNT_LIMIT=y > CONFIG_SYS_BOOTCOUNT_BE=y > CONFIG_SYS_I2C_LEGACY=y This worked perfectly. But this platform my not yet be utilizing DM for NAND/ELM driver yet so is this change acceptable? cheers, -roger > > On Sat, Dec 17, 2022 at 2:46 PM Michael Nazzareno Trimarchi > wrote: >> >> Hi >> >> take my config >> >> Michael >> >> On Sat, Dec 17, 2022 at 2:43 PM Roger Quadros wrote: >>> >>> On 17/12/2022 15:38, Michael Nazzareno Trimarchi wrote: >>>> Hi >>>> >>>> On Sat, Dec 17, 2022 at 2:00 PM Roger Quadros wrote: >>>>> >>>>> Hi Michael & Dario, >>>>> >>>>> On 12/12/2022 11:39, Michael Nazzareno Trimarchi wrote: >>>>>> Hi Roger >>>>>> >>>>>> Most of the building problem can be tested with this configuration >>>>>> >>>>>> make ARCH=arm chiliboard_defconfig >>>>> >>>>> I resolved the original issue for all boards but now face a new issue >>>>> only with the chiliboard. >>>>> >>>>> arm-none-linux-gnueabihf-ld.bfd: drivers/mtd/nand/raw/omap_elm.o: in >>>>> function `dev_read_resource': >>>>> /work/u-boot/include/dm/read.h:1139: undefined reference to >>>>> `ofnode_read_resource' >>>>> AR common/built-in.o >>>>> make[2]: *** [/work/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] >>>>> Error 1 >>>>> make[1]: *** [/work/u-boot/Makefile:2071: spl/u-boot-spl] Error 2 >>>>> make[1]: *** Waiting for unfinished jobs >>>>> make[1]: Leaving directory '/tmp' >>>>> make: *** [Makefile:177: sub-make] Error 2 >>>>> >>>>> The following config options are set >>>>> CONFIG_DM_DEV_READ_INLINE=y >>>> >>>> What happen is that is not set? >>> >>> I removed "default y" for it in drivers/core/Kconfig >>> >>> Now I get >>> >>> arm-none-linux-gnueabihf-ld.bfd: drivers/mtd/nand/raw/omap_elm.o: in >>> function `elm_probe': >>> /work/u-boot/drivers/mtd/nand/raw/omap_elm.c:206: undefined reference to >>> `dev_read_resource' >>> make[2]: *** [/work/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 >>> make[1]: *** [/work/u-boot/Makefile:2071: spl/u-boot-spl] Error 2 >>> make[1]: *** Waiting for unfinished jobs >>> >>> cheers, >>> -roger >>> >>>> >>>> Michael >>>> >>>>> CONFIG_SUPPORT_OF_CONTROL=y >>>>> >>>>> My understanding is that in case of spl build (Makefile.spl), the >>>>> drivers/core/ofnode.o does not seem to be included >>>>> thus causing the linking error. >>>>> >>>>> Any suggestions how to fix this? >>>>> >>>>> I've pushed the patches here >>>>> https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-1.4 >>>>> >>>>> cheers, >>>>> -roger >>>>> >>>>>> >>>>>> Michael >>>>>> >>>>>> On Mon, Dec 12, 2022 at 10:27 AM Dario Binacchi >>>>>> wrote: >>>>>>> >>>>>>> Hi Roger, >>>>>>> >>>>>>> On Mon, Dec 12, 2022 at 10:12 AM Roger Quadros >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Dario, >>>>>>>> >>>>>>>&
Re: [u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support
On 17/12/2022 15:38, Michael Nazzareno Trimarchi wrote: > Hi > > On Sat, Dec 17, 2022 at 2:00 PM Roger Quadros wrote: >> >> Hi Michael & Dario, >> >> On 12/12/2022 11:39, Michael Nazzareno Trimarchi wrote: >>> Hi Roger >>> >>> Most of the building problem can be tested with this configuration >>> >>> make ARCH=arm chiliboard_defconfig >> >> I resolved the original issue for all boards but now face a new issue >> only with the chiliboard. >> >> arm-none-linux-gnueabihf-ld.bfd: drivers/mtd/nand/raw/omap_elm.o: in >> function `dev_read_resource': >> /work/u-boot/include/dm/read.h:1139: undefined reference to >> `ofnode_read_resource' >> AR common/built-in.o >> make[2]: *** [/work/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 >> make[1]: *** [/work/u-boot/Makefile:2071: spl/u-boot-spl] Error 2 >> make[1]: *** Waiting for unfinished jobs >> make[1]: Leaving directory '/tmp' >> make: *** [Makefile:177: sub-make] Error 2 >> >> The following config options are set >> CONFIG_DM_DEV_READ_INLINE=y > > What happen is that is not set? I removed "default y" for it in drivers/core/Kconfig Now I get arm-none-linux-gnueabihf-ld.bfd: drivers/mtd/nand/raw/omap_elm.o: in function `elm_probe': /work/u-boot/drivers/mtd/nand/raw/omap_elm.c:206: undefined reference to `dev_read_resource' make[2]: *** [/work/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 make[1]: *** [/work/u-boot/Makefile:2071: spl/u-boot-spl] Error 2 make[1]: *** Waiting for unfinished jobs cheers, -roger > > Michael > >> CONFIG_SUPPORT_OF_CONTROL=y >> >> My understanding is that in case of spl build (Makefile.spl), the >> drivers/core/ofnode.o does not seem to be included >> thus causing the linking error. >> >> Any suggestions how to fix this? >> >> I've pushed the patches here >> https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-1.4 >> >> cheers, >> -roger >> >>> >>> Michael >>> >>> On Mon, Dec 12, 2022 at 10:27 AM Dario Binacchi >>> wrote: >>>> >>>> Hi Roger, >>>> >>>> On Mon, Dec 12, 2022 at 10:12 AM Roger Quadros wrote: >>>>> >>>>> Hi Dario, >>>>> >>>>> On 11/12/2022 15:56, Dario Binacchi wrote: >>>>>> Hi Roger, >>>>>> >>>>>> On Fri, Nov 25, 2022 at 1:38 PM Roger Quadros wrote: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> On 08/11/2022 11:26, Michael Nazzareno Trimarchi wrote: >>>>>>>> Hi Roger >>>>>>>> >>>>>>>> On Fri, Nov 4, 2022 at 2:27 PM Roger Quadros wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 11/10/2022 14:49, Roger Quadros wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This series adds driver model support for rawnand: omap_gpmc >>>>>>>>>> and omap_elm drivers. >>>>>>>>>> >>>>>>>>>> This will enable the driver to be used on K2/K3 platforms as well. >>>>>>>>> >>>>>>>>> Any comments on patches 5 and later? Thanks >>>>>>>>> >>>>>>>> >>>>>>>> We will try to close this week. >>>>>>> >>>>>>> Could you please give your comments on the last few patches. Thanks! >>>>>>> >>>>>>> cheers, >>>>>>> -roger >>>>>>> >>>>>>>> >>>>>>>> Michael >>>>>>>> >>>>>>>>> >>>>>>>>> cheers, >>>>>>>>> -roger >>>>>>>>> >>>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> -roger >>>>>>>>>> >>>>>>>>>> Roger Quadros (14): >>>>>>>>>> mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h >>>>>>>>>> mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms >>>>>>>>>> mtd: rawnand: omap_gpmc: Fix build warning on 64-bit pla
Re: [u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support
Hi Michael & Dario, On 12/12/2022 11:39, Michael Nazzareno Trimarchi wrote: > Hi Roger > > Most of the building problem can be tested with this configuration > > make ARCH=arm chiliboard_defconfig I resolved the original issue for all boards but now face a new issue only with the chiliboard. arm-none-linux-gnueabihf-ld.bfd: drivers/mtd/nand/raw/omap_elm.o: in function `dev_read_resource': /work/u-boot/include/dm/read.h:1139: undefined reference to `ofnode_read_resource' AR common/built-in.o make[2]: *** [/work/u-boot/scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 make[1]: *** [/work/u-boot/Makefile:2071: spl/u-boot-spl] Error 2 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory '/tmp' make: *** [Makefile:177: sub-make] Error 2 The following config options are set CONFIG_DM_DEV_READ_INLINE=y CONFIG_SUPPORT_OF_CONTROL=y My understanding is that in case of spl build (Makefile.spl), the drivers/core/ofnode.o does not seem to be included thus causing the linking error. Any suggestions how to fix this? I've pushed the patches here https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-1.4 cheers, -roger > > Michael > > On Mon, Dec 12, 2022 at 10:27 AM Dario Binacchi > wrote: >> >> Hi Roger, >> >> On Mon, Dec 12, 2022 at 10:12 AM Roger Quadros wrote: >>> >>> Hi Dario, >>> >>> On 11/12/2022 15:56, Dario Binacchi wrote: >>>> Hi Roger, >>>> >>>> On Fri, Nov 25, 2022 at 1:38 PM Roger Quadros wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> On 08/11/2022 11:26, Michael Nazzareno Trimarchi wrote: >>>>>> Hi Roger >>>>>> >>>>>> On Fri, Nov 4, 2022 at 2:27 PM Roger Quadros wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 11/10/2022 14:49, Roger Quadros wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This series adds driver model support for rawnand: omap_gpmc >>>>>>>> and omap_elm drivers. >>>>>>>> >>>>>>>> This will enable the driver to be used on K2/K3 platforms as well. >>>>>>> >>>>>>> Any comments on patches 5 and later? Thanks >>>>>>> >>>>>> >>>>>> We will try to close this week. >>>>> >>>>> Could you please give your comments on the last few patches. Thanks! >>>>> >>>>> cheers, >>>>> -roger >>>>> >>>>>> >>>>>> Michael >>>>>> >>>>>>> >>>>>>> cheers, >>>>>>> -roger >>>>>>> >>>>>>>> >>>>>>>> cheers, >>>>>>>> -roger >>>>>>>> >>>>>>>> Roger Quadros (14): >>>>>>>> mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h >>>>>>>> mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms >>>>>>>> mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms >>>>>>>> mtd: rawnand: omap_gpmc: Optimize NAND reads >>>>>>>> mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction >>>>>>>> mtd: rawnand: nand_base: Allow base driver to be used in SPL without >>>>>>>> nand_bbt >>>>>>>> mtd: rawnand: nand_spl_loaders: Fix cast type build warning >>>>>>>> mtd: rawnand: omap_gpmc: Reduce .bss usage >>>>>>>> dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation >>>>>>>> mtd: rawnand: omap_gpmc: support u-boot driver model >>>>>>>> mtd: rawnand: omap_gpmc: Add SPL NAND support >>>>>>>> mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC >>>>>>>> dt-bindings: mtd: Add ti,elm DT binding documentation >>>>>>>> mtd: rawnand: omap_elm: u-boot driver model support >>>>>>>> >>>>>>>> doc/device-tree-bindings/mtd/ti,elm.yaml | 72 +++ >>>>>>>> .../mtd/ti,gpmc-nand.yaml | 129 + >>>>>>>> drivers/mtd/nand/raw/Kconfig | 11 +- >>>>>>>> drivers/mtd/nand/raw/Makefile | 2 +- >>>>>>>> drivers/mtd/n
Re: [u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support
Hi Dario,
On 11/12/2022 15:56, Dario Binacchi wrote:
> Hi Roger,
>
> On Fri, Nov 25, 2022 at 1:38 PM Roger Quadros wrote:
>>
>> Hi Michael,
>>
>> On 08/11/2022 11:26, Michael Nazzareno Trimarchi wrote:
>>> Hi Roger
>>>
>>> On Fri, Nov 4, 2022 at 2:27 PM Roger Quadros wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 11/10/2022 14:49, Roger Quadros wrote:
>>>>> Hi,
>>>>>
>>>>> This series adds driver model support for rawnand: omap_gpmc
>>>>> and omap_elm drivers.
>>>>>
>>>>> This will enable the driver to be used on K2/K3 platforms as well.
>>>>
>>>> Any comments on patches 5 and later? Thanks
>>>>
>>>
>>> We will try to close this week.
>>
>> Could you please give your comments on the last few patches. Thanks!
>>
>> cheers,
>> -roger
>>
>>>
>>> Michael
>>>
>>>>
>>>> cheers,
>>>> -roger
>>>>
>>>>>
>>>>> cheers,
>>>>> -roger
>>>>>
>>>>> Roger Quadros (14):
>>>>> mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h
>>>>> mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
>>>>> mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms
>>>>> mtd: rawnand: omap_gpmc: Optimize NAND reads
>>>>> mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
>>>>> mtd: rawnand: nand_base: Allow base driver to be used in SPL without
>>>>> nand_bbt
>>>>> mtd: rawnand: nand_spl_loaders: Fix cast type build warning
>>>>> mtd: rawnand: omap_gpmc: Reduce .bss usage
>>>>> dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation
>>>>> mtd: rawnand: omap_gpmc: support u-boot driver model
>>>>> mtd: rawnand: omap_gpmc: Add SPL NAND support
>>>>> mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
>>>>> dt-bindings: mtd: Add ti,elm DT binding documentation
>>>>> mtd: rawnand: omap_elm: u-boot driver model support
>>>>>
>>>>> doc/device-tree-bindings/mtd/ti,elm.yaml | 72 +++
>>>>> .../mtd/ti,gpmc-nand.yaml | 129 +
>>>>> drivers/mtd/nand/raw/Kconfig | 11 +-
>>>>> drivers/mtd/nand/raw/Makefile | 2 +-
>>>>> drivers/mtd/nand/raw/nand_base.c | 18 +-
>>>>> drivers/mtd/nand/raw/nand_spl_loaders.c | 2 +-
>>>>> drivers/mtd/nand/raw/omap_elm.c | 33 +-
>>>>> .../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6 +
>>>>> drivers/mtd/nand/raw/omap_gpmc.c | 500 +-
>>>>> 9 files changed, 637 insertions(+), 136 deletions(-)
>>>>> create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
>>>>> create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
>>>>> rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
>>>>>
>>>
>>>
>>>
>
> I tried to merge your whole series but after the second fix and the
> third time the CI/CD pipeline failed
Do you have the link to the failure?
> I thought it's better you fix the problems. So, I only accepted some
> of the first few patches in the series:
> 01/14 mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h
> 02/14 mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
> 03/14 mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms
> 04/14 mtd: rawnand: omap_gpmc: Optimize NAND reads
> 07/14 mtd: rawnand: nand_spl_loaders: Fix cast type build warning
> 08/14 mtd: rawnand: omap_gpmc: Reduce .bss usage
>
> For the others, please fix them to run the tests successfully.
No problem. I will try to fix and run them through the CI testing myself
before re-posting.
cheers,
-roger
Re: [u-boot][PATCH 05/14] mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
On 30/11/2022 10:11, Dario Binacchi wrote: > Hi Tom, > > On Tue, Nov 29, 2022 at 5:18 PM Tom Rini wrote: >> >> On Tue, Nov 29, 2022 at 04:25:13PM +0100, Dario Binacchi wrote: >>> Hi Roger, >>> >>> On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote: >>>> >>>> The BCH detection hardware can generate ECC bytes for multiple >>>> sectors in one go. Use that feature. >>>> >>>> correct() only corrects one sector at a time so we need to call it >>>> repeatedly for each sector. >>>> >>>> Signed-off-by: Roger Quadros >> [snip] >>>> +/** >>>> + * omap_calculate_ecc_bch - ECC generator for 1 sector >>>> + * @mtd:MTD device structure >>>> + * @dat: The pointer to data on which ecc is computed >>>> + * @ecc_code: The ecc_code buffer >>>> + * >>>> + * Support calculating of BCH4/8/16 ECC vectors for one sector. This is >>>> used >>>> + * when SW based correction is required as ECC is required for one sector >>>> + * at a time. >>>> + */ >>>> +static int omap_calculate_ecc_bch(struct mtd_info *mtd, >>>> + const u_char *dat, u_char *ecc_calc) >>> >>> Please add __maybe_unused. Without it the CI/CD pipeline fails: >>> >>>arm: + devkit8000 >>> +drivers/mtd/nand/raw/omap_gpmc.c:442:12: error: >>> 'omap_calculate_ecc_bch' defined but not used >>> [-Werror=unused-function] >>> + 442 | static int omap_calculate_ecc_bch(struct mtd_info *mtd, >>> + |^~ >>> +cc1: all warnings being treated as errors >> >> While not a firm rule, a general suggestion is if it's easy to fix a CI >> error like this, do so (and add Signed-off-by tag) during testing a PR >> rather than ask for a resubmit. Unless there's other more complex >> changes needed as well. > > I'll do it. Thanks for the suggestion and the explanation. Thanks for saving me from a re-spin. :) -- cheers, -roger
Re: [u-boot][PATCH 06/14] mtd: rawnand: nand_base: Allow base driver to be used in SPL without nand_bbt
Hi Michael,
On 28/11/2022 16:27, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote:
>>
>> nand_bbt.c is not being built with the nand_base driver during SPL
>> build. This results in build failures if we try to access any nand_bbt
>> related functions.
>>
>> Don't use any nand_bbt functions for SPL build.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/mtd/nand/raw/nand_base.c | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/raw/nand_base.c
>> b/drivers/mtd/nand/raw/nand_base.c
>> index 4b09a11288..826ae633ce 100644
>> --- a/drivers/mtd/nand/raw/nand_base.c
>> +++ b/drivers/mtd/nand/raw/nand_base.c
>> @@ -447,7 +447,10 @@ static int nand_default_block_markbad(struct mtd_info
>> *mtd, loff_t ofs)
>> static int nand_block_markbad_lowlevel(struct mtd_info *mtd, loff_t ofs)
>> {
>> struct nand_chip *chip = mtd_to_nand(mtd);
>> - int res, ret = 0;
>> + int ret = 0;
>> +#ifndef CONFIG_SPL_BUILD
>> + int res;
>> +#endif
>>
>> if (!(chip->bbt_options & NAND_BBT_NO_OOB_BBM)) {
>> struct erase_info einfo;
>> @@ -465,12 +468,14 @@ static int nand_block_markbad_lowlevel(struct mtd_info
>> *mtd, loff_t ofs)
>> nand_release_device(mtd);
>> }
>>
>> +#ifndef CONFIG_SPL_BUILD
>> /* Mark block bad in BBT */
>> if (chip->bbt) {
>> res = nand_markbad_bbt(mtd, ofs);
>> if (!ret)
>> ret = res;
>> }
>> +#endif
>>
>> if (!ret)
>> mtd->ecc_stats.badblocks++;
>> @@ -517,7 +522,11 @@ static int nand_block_isreserved(struct mtd_info *mtd,
>> loff_t ofs)
>> if (!chip->bbt)
>> return 0;
>> /* Return info from the table */
>> +#ifndef CONFIG_SPL_BUILD
>> return nand_isreserved_bbt(mtd, ofs);
>> +#else
>> + return 0;
>> +#endif
>> }
>>
>> /**
>> @@ -543,7 +552,11 @@ static int nand_block_checkbad(struct mtd_info *mtd,
>> loff_t ofs, int allowbbt)
>> return chip->block_bad(mtd, ofs);
>>
>> /* Return info from the table */
>> +#ifndef CONFIG_SPL_BUILD
>> return nand_isbad_bbt(mtd, ofs, allowbbt);
>> +#else
>> + return 0;
>> +#endif
>> }
>
> Can you please send me the config that let this fail?
I've pushed a test branch here where relevant changes are done to
am64x_evm_a53_defconfig
https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-1.0-test
Attaching the resulting spl/u-boot.cfg that causes the failure
>
> Michael
>>
>> /**
>> @@ -3752,8 +3765,11 @@ static void nand_set_defaults(struct nand_chip *chip,
>> int busw)
>> chip->write_byte = busw ? nand_write_byte16 :
>> nand_write_byte;
>> if (!chip->read_buf || chip->read_buf == nand_read_buf)
>> chip->read_buf = busw ? nand_read_buf16 : nand_read_buf;
>> +
>> +#ifndef CONFIG_SPL_BUILD
>> if (!chip->scan_bbt)
>> chip->scan_bbt = nand_default_bbt;
>> +#endif
>>
>> if (!chip->controller) {
>> chip->controller = >hwcontrol;
>> --
>> 2.17.1
>>
>
>
--
cheers,
-roger#define CONFIG_CMD_MTD 1
#define CONFIG_ETH 1
#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
#define CONFIG_SPL_FIT_SOURCE ""
#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x28
#define CONFIG_CMD_FAT 1
#define CONFIG_TI_K3_PSIL 1
#define CONFIG_SPL_DM_SERIAL 1
#define CONFIG_TOOLS_SHA1 1
#define CONFIG_EFI_DEVICE_PATH_UTIL 1
#define CONFIG_BOOTM_NETBSD 1
#define CONFIG_OF_SPL_REMOVE_PROPS "interrupt-parent interrupts"
#define CONFIG_CMD_FDT 1
#define CONFIG_SPL_DFU 1
#define CONFIG_OMAP_SERIAL 1
#define CONFIG_NAND_OMAP_GPMC 1
#define CONFIG_USB_GADGET_DOWNLOAD 1
#define CONFIG_SYS_CLK_FREQ 0
#define CONFIG_BOOTMETH_VBE_SIMPLE 1
#define CONFIG_CMD_ITEST 1
#define CONFIG_SPL_POWER_DOMAIN 1
#define CONFIG_REMOTEPROC_TI_K3_ARM64 1
#define CONFIG_BOOTM_VXWORKS 1
#define CONFIG_ERR_PTR_OFFSET 0x0
#define CONFIG_CMD_EDITENV 1
#define CONFIG_OF_OVERLAY_LIST ""
#define CONFIG_SPL_SPRINTF 1
#define CONFIG_SPL_DMA 1
#define CONFIG_CMD_MTDPARTS 1
#define CONFIG_EFI_PLATFORM_LANG_CODES "en-US"
#define CONFIG_SPL_NAND_SUPPORT 1
#define CONFIG_ARM_PSCI_FW 1
#define CONFIG_CMD_SETEXPR 1
#define CONFIG_TOOLS_SHA384 1
Re: [u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support
Hi Michael,
On 08/11/2022 11:26, Michael Nazzareno Trimarchi wrote:
> Hi Roger
>
> On Fri, Nov 4, 2022 at 2:27 PM Roger Quadros wrote:
>>
>> Hi,
>>
>> On 11/10/2022 14:49, Roger Quadros wrote:
>>> Hi,
>>>
>>> This series adds driver model support for rawnand: omap_gpmc
>>> and omap_elm drivers.
>>>
>>> This will enable the driver to be used on K2/K3 platforms as well.
>>
>> Any comments on patches 5 and later? Thanks
>>
>
> We will try to close this week.
Could you please give your comments on the last few patches. Thanks!
cheers,
-roger
>
> Michael
>
>>
>> cheers,
>> -roger
>>
>>>
>>> cheers,
>>> -roger
>>>
>>> Roger Quadros (14):
>>> mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h
>>> mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
>>> mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms
>>> mtd: rawnand: omap_gpmc: Optimize NAND reads
>>> mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
>>> mtd: rawnand: nand_base: Allow base driver to be used in SPL without
>>> nand_bbt
>>> mtd: rawnand: nand_spl_loaders: Fix cast type build warning
>>> mtd: rawnand: omap_gpmc: Reduce .bss usage
>>> dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation
>>> mtd: rawnand: omap_gpmc: support u-boot driver model
>>> mtd: rawnand: omap_gpmc: Add SPL NAND support
>>> mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
>>> dt-bindings: mtd: Add ti,elm DT binding documentation
>>> mtd: rawnand: omap_elm: u-boot driver model support
>>>
>>> doc/device-tree-bindings/mtd/ti,elm.yaml | 72 +++
>>> .../mtd/ti,gpmc-nand.yaml | 129 +
>>> drivers/mtd/nand/raw/Kconfig | 11 +-
>>> drivers/mtd/nand/raw/Makefile | 2 +-
>>> drivers/mtd/nand/raw/nand_base.c | 18 +-
>>> drivers/mtd/nand/raw/nand_spl_loaders.c | 2 +-
>>> drivers/mtd/nand/raw/omap_elm.c | 33 +-
>>> .../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6 +
>>> drivers/mtd/nand/raw/omap_gpmc.c | 500 +-
>>> 9 files changed, 637 insertions(+), 136 deletions(-)
>>> create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
>>> create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
>>> rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
>>>
>
>
>
Re: [u-boot][PATCH 00/14] rawnand: omap_gpmc: driver model support
Hi,
On 11/10/2022 14:49, Roger Quadros wrote:
> Hi,
>
> This series adds driver model support for rawnand: omap_gpmc
> and omap_elm drivers.
>
> This will enable the driver to be used on K2/K3 platforms as well.
Any comments on patches 5 and later? Thanks
cheers,
-roger
>
> cheers,
> -roger
>
> Roger Quadros (14):
> mtd: rawnand: omap_gpmc: Deprecate asm/arch/mem.h
> mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
> mtd: rawnand: omap_gpmc: Fix build warning on 64-bit platforms
> mtd: rawnand: omap_gpmc: Optimize NAND reads
> mtd: rawnand: omap_gpmc: Fix BCH6/16 HW based correction
> mtd: rawnand: nand_base: Allow base driver to be used in SPL without
> nand_bbt
> mtd: rawnand: nand_spl_loaders: Fix cast type build warning
> mtd: rawnand: omap_gpmc: Reduce .bss usage
> dt-bindings: mtd: Add ti,gpmc-nand DT binding documentation
> mtd: rawnand: omap_gpmc: support u-boot driver model
> mtd: rawnand: omap_gpmc: Add SPL NAND support
> mtd: rawnand: omap_gpmc: Enable SYS_NAND_PAGE_COUNT for OMAP_GPMC
> dt-bindings: mtd: Add ti,elm DT binding documentation
> mtd: rawnand: omap_elm: u-boot driver model support
>
> doc/device-tree-bindings/mtd/ti,elm.yaml | 72 +++
> .../mtd/ti,gpmc-nand.yaml | 129 +
> drivers/mtd/nand/raw/Kconfig | 11 +-
> drivers/mtd/nand/raw/Makefile | 2 +-
> drivers/mtd/nand/raw/nand_base.c | 18 +-
> drivers/mtd/nand/raw/nand_spl_loaders.c | 2 +-
> drivers/mtd/nand/raw/omap_elm.c | 33 +-
> .../mtd => drivers/mtd/nand/raw}/omap_elm.h | 6 +
> drivers/mtd/nand/raw/omap_gpmc.c | 500 +-
> 9 files changed, 637 insertions(+), 136 deletions(-)
> create mode 100644 doc/device-tree-bindings/mtd/ti,elm.yaml
> create mode 100644 doc/device-tree-bindings/mtd/ti,gpmc-nand.yaml
> rename {include/linux/mtd => drivers/mtd/nand/raw}/omap_elm.h (97%)
>
Re: Binman entry 'u-boot-any' not found in list
Hi Neha,
On 31/10/2022 05:40, Neha Malcom Francis wrote:
> Hi Simon,
>
> On 30/10/22 07:13, Simon Glass wrote:
>> Hi Neha,
>>
>> On Fri, 28 Oct 2022 at 04:58, Fabio Estevam wrote:
>>>
>>> [Adding Alper - binmam maintainer and Oliver, who faced the same issue on
>>> imx8]
>>>
>>> On Fri, Oct 28, 2022 at 7:56 AM Neha Malcom Francis
>>> wrote:
Hi!
U-Boot build for J721E with binman enabled on the latest tip of the
master branch throws an error when I try to use u-boot-spl-nodtb entry
in my dtsi.
What I'm trying to do is, to show I've made a small example
(https://github.com/nehamalcom/u-boot/commit/f53dc83944f7774008afbb24fff42904862e9efe)
that is:
{
foo {
filename = "foo.bin";
u-boot-spl-nodtb {
};
};
};
which throws the error
(https://gist.github.com/nehamalcom/4d855db7e4d5bd03aa29099b0e915e53):
binman: Section '/binman/foo': Symbol '_binman_u_boot_any_prop_image_pos'
in entry '/binman/foo/u-boot-spl-nodtb': Entry 'u-boot-any' not
found in list (u-boot-spl-nodtb,main-section)
This can be traced to the WriteSymbols() in etype/u_boot_spl_nodtb.py.
On commenting out this function since it's not necessary in our
use-case, the build was successful
(https://github.com/nehamalcom/u-boot/commit/5666721860e1d2f759440a00c4aee8b6e89b54b3)
Why is binman not picking up on the "any" and choosing u-boot-spl-nodtb
from the list?
>>
>> You might need this patch?
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20221021002320.1169603-5-...@chromium.org/
>
> Even after applying this patch, the entry is not working for me.
Probably because that patch doesn't deal with CONFIG_SPL case, only CONFIG_TPL
and CONFIG_VPL?
Can you please try to do the same for CONFIG_SPL?
e.g.
#ifdef CONFIG_SPL
binman_sym_declare(ulong, u_boot_spl, image_pos);
binman_sym_declare(ulong, u_boot_spl, size);
#endif
cheers,
-roger
[PATCH v2] spl: spl_legacy: Fix NAND boot on OMAP3 BeagleBoard
OMAP3 BeagleBoard NAND boot hangs when spl_load_legacy_img() tries
to read the header into 'struct hdr' which is allocated on the
stack.
As the header has already been read once before by spl_nand.c,
we can avoid the extra header allocation and read here by
simply passing around the pointer to the header.
This fixes NAND boot on OMAP3 BeagleBoard.
Signed-off-by: Roger Quadros
Reviewed-By: Michael Trimarchi
---
Changelog:
v2:
- Explained that extra allocation is avoided in commit message
common/spl/spl_legacy.c | 19 ---
common/spl/spl_nand.c | 2 +-
common/spl/spl_nor.c| 6 +-
include/spl.h | 7 +--
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c
index ae8731c782..2e9226c990 100644
--- a/common/spl/spl_legacy.c
+++ b/common/spl/spl_legacy.c
@@ -77,32 +77,29 @@ static inline int spl_image_get_comp(const struct
image_header *hdr)
int spl_load_legacy_img(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev,
- struct spl_load_info *load, ulong header)
+ struct spl_load_info *load, ulong offset,
+ struct image_header *hdr)
{
__maybe_unused SizeT lzma_len;
__maybe_unused void *src;
- struct image_header hdr;
ulong dataptr;
int ret;
- /* Read header into local struct */
- load->read(load, header, sizeof(hdr), );
-
/*
* If the payload is compressed, the decompressed data should be
* directly write to its load address.
*/
- if (spl_image_get_comp() != IH_COMP_NONE)
+ if (spl_image_get_comp(hdr) != IH_COMP_NONE)
spl_image->flags |= SPL_COPY_PAYLOAD_ONLY;
- ret = spl_parse_image_header(spl_image, bootdev, );
+ ret = spl_parse_image_header(spl_image, bootdev, hdr);
if (ret)
return ret;
/* Read image */
- switch (spl_image_get_comp()) {
+ switch (spl_image_get_comp(hdr)) {
case IH_COMP_NONE:
- dataptr = header;
+ dataptr = offset;
/*
* Image header will be skipped only if SPL_COPY_PAYLOAD_ONLY
@@ -119,7 +116,7 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
lzma_len = LZMA_LEN;
/* dataptr points to compressed payload */
- dataptr = header + sizeof(hdr);
+ dataptr = offset + sizeof(hdr);
debug("LZMA: Decompressing %08lx to %08lx\n",
dataptr, spl_image->load_addr);
@@ -143,7 +140,7 @@ int spl_load_legacy_img(struct spl_image_info *spl_image,
default:
debug("Compression method %s is not supported\n",
- genimg_get_comp_short_name(image_get_comp()));
+ genimg_get_comp_short_name(image_get_comp(hdr)));
return -EINVAL;
}
diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 7b7579a2df..5eb67b5468 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -119,7 +119,7 @@ static int spl_nand_load_element(struct spl_image_info
*spl_image,
load.bl_len = 1;
load.read = spl_nand_legacy_read;
- return spl_load_legacy_img(spl_image, bootdev, , offset);
+ return spl_load_legacy_img(spl_image, bootdev, , offset,
header);
} else {
err = spl_parse_image_header(spl_image, bootdev, header);
if (err)
diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index 7986e930d2..f00a5c395b 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -111,10 +111,14 @@ static int spl_nor_load_image(struct spl_image_info
*spl_image,
/* Legacy image handling */
if (IS_ENABLED(CONFIG_SPL_LEGACY_IMAGE_FORMAT)) {
+ struct image_header hdr;
+
load.bl_len = 1;
load.read = spl_nor_load_read;
+ spl_nor_load_read(, spl_nor_get_uboot_base(), sizeof(hdr),
);
return spl_load_legacy_img(spl_image, bootdev, ,
- spl_nor_get_uboot_base());
+ spl_nor_get_uboot_base(),
+ );
}
return 0;
diff --git a/include/spl.h b/include/spl.h
index aac6648f94..7fa5e51c39 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -353,7 +353,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
* spl_load_legacy_img() - Loads a legacy image from a device.
* @spl_image: Image description to set up
* @load: Structure containing the information required to load data.
- * @header:Pointer to image header (including appended image)
+ * @offset:Pointer to image
+ * @hdr: Pointer to image header
*
* Reads an
