Re: [PATCH v7 1/7] configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM
On 06/10/23 10:15, Manorit Chawdhry wrote: > From: Udit Kumar > > The malloc capacity in DRAM at R5 SPL is set to 1MB which isn't > sufficient to load the new tispl.bin to > enable loading of tispl.bin the size is increased by 256KB to 1.25MB. > > Cc: Nikhil M Jain > Signed-off-by: Udit Kumar > Reviewed-by: Nishanth Menon > Signed-off-by: Manorit Chawdhry > --- > configs/j721s2_evm_r5_defconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Nikhil M Jain > diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig > index 1e66ac23d05b..e2b83b337809 100644 > --- a/configs/j721s2_evm_r5_defconfig > +++ b/configs/j721s2_evm_r5_defconfig > @@ -42,6 +42,7 @@ CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y > CONFIG_SPL_BOARD_INIT=y > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > CONFIG_SPL_STACK_R=y > +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x14 > CONFIG_SPL_SEPARATE_BSS=y > CONFIG_SYS_SPL_MALLOC=y > CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y >
[PATCH v7 7/7] board: ti: j721s2: MAINTAINERS: Update the MAINTAINERS File.
Update the MAINTAINERS file and propose a new MAINTAINER for j721s2 due to the previous MAINTAINER not being associated with TI. Reviewed-by: Nishanth Menon Signed-off-by: Manorit Chawdhry --- board/ti/j721s2/MAINTAINERS | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/board/ti/j721s2/MAINTAINERS b/board/ti/j721s2/MAINTAINERS index 323bd2353a7e..08c8d110ac0a 100644 --- a/board/ti/j721s2/MAINTAINERS +++ b/board/ti/j721s2/MAINTAINERS @@ -1,16 +1,23 @@ J721S2 BOARD -M: Aswath Govindraju +M: Manorit Chawdhry S: Maintained F: board/ti/j721s2 +F: arch/arm/mach-k3/j721s2 +F: doc/board/ti/j721s2_evm.rst F: include/configs/j721s2_evm.h F: configs/j721s2_evm_r5_defconfig F: configs/j721s2_evm_a72_defconfig F: arch/arm/dts/k3-j721s2.dtsi F: arch/arm/dts/k3-j721s2-main.dtsi F: arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi +F: arch/arm/dts/k3-j721s2-thermal.dtsi F: arch/arm/dts/k3-j721s2-som-p0.dtsi F: arch/arm/dts/k3-j721s2-common-proc-board.dts F: arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi -F: arch/arm/dts//k3-j721s2-r5-common-proc-board.dts +F: arch/arm/dts/k3-j721s2-r5-common-proc-board.dts F: arch/arm/dts/k3-j721s2-ddr.dtsi F: arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi +F: arch/arm/dts/k3-am68-sk-som.dtsi +F: arch/arm/dts/k3-am68-sk-base-board.dts +F: arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi +F: arch/arm/dts/k3-am68-sk-r5-base-board.dts -- 2.41.0
[PATCH v7 6/7] docs: board: ti: Add j721s2_evm documentation
Add the documentation for J721S2-EVM and SK-AM68 TRM for J721S2/AM68: https://www.ti.com/lit/pdf/spruj28 Product Page for J721S2: https://www.ti.com/tool/J721S2XSOMXEVM Product Page for AM68: https://www.ti.com/tool/SK-AM68 Reviewed-by: Neha Malcom Francis Reviewed-by: Nishanth Menon Signed-off-by: Manorit Chawdhry --- doc/board/ti/j721s2_evm.rst | 341 doc/board/ti/k3.rst | 1 + 2 files changed, 342 insertions(+) diff --git a/doc/board/ti/j721s2_evm.rst b/doc/board/ti/j721s2_evm.rst new file mode 100644 index ..fec2acabe845 --- /dev/null +++ b/doc/board/ti/j721s2_evm.rst @@ -0,0 +1,341 @@ +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +.. sectionauthor:: Manorit Chawdhry + +J721S2 and AM68 Platforms += + +Introduction: +- +The J721S2 family of SoCs are part of K3 Multicore SoC architecture platform +targeting automotive applications. They are designed as a low power, high +performance and highly integrated device architecture, adding significant +enhancement on processing power, graphics capability, video and imaging +processing, virtualization and coherent memory support. + +The AM68 Starter Kit/Evaluation Module (EVM) is based on the J721S2 family +of SoCs. They are designed for machine vision, traffic monitoring, retail +automation, and factory automation. + +The device is partitioned into three functional domains, each containing +specific processing cores and peripherals: + +1. Wake-up (WKUP) domain: +* ARM Cortex-M4F processor, runs TI Foundational Security (TIFS) + +2. Microcontroller (MCU) domain: +* Dual core ARM Cortex-R5F processor, runs device management + and SoC early boot + +3. MAIN domain: +* Dual core 64-bit ARM Cortex-A72, runs HLOS + +More info can be found in TRM: https://www.ti.com/lit/pdf/spruj28 + +Platform information: + +* https://www.ti.com/tool/J721S2XSOMXEVM +* https://www.ti.com/tool/SK-AM68 + +Boot Flow: +-- +Below is the pictorial representation of boot flow: + +.. image:: img/boot_diagram_k3_current.svg + +- On this platform, "TI Foundational Security" (TIFS) functions as the + security enclave master while "Device Manager" (DM), also known as the + "TISCI server" in TI terminology, offers all the essential services. + +- As illustrated in the diagram above, R5 SPL manages power and clock + services independently before handing over control to "DM". The A72 or + the C7x (Aux core) software components request TIFS/DM to handle + security or device management services. + +Sources: + + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_boot_sources +:end-before: .. k3_rst_include_end_boot_sources + +Build procedure: + +0. Setup the environment variables: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_desc +:end-before: .. k3_rst_include_end_common_env_vars_desc + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_board_env_vars_desc +:end-before: .. k3_rst_include_end_board_env_vars_desc + +Set the variables corresponding to this platform: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_defn +:end-before: .. k3_rst_include_end_common_env_vars_defn +.. code-block:: bash + + $ export UBOOT_CFG_CORTEXR=j721s2_evm_r5_defconfig + $ export UBOOT_CFG_CORTEXA=j721s2_evm_a72_defconfig + $ export TFA_BOARD=generic + $ export TFA_EXTRA_ARGS="K3_USART=0x8" + $ # The following is not a typo, j784s4 is the OP-TEE platform for j721s2 + $ export OPTEE_PLATFORM=k3-j784s4 + $ export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8" + +.. j721s2_evm_rst_include_start_build_steps + +1. Trusted Firmware-A: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_tfa +:end-before: .. k3_rst_include_end_build_steps_tfa + + +2. OP-TEE: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_optee +:end-before: .. k3_rst_include_end_build_steps_optee + +3. U-Boot: + +.. _j721s2_evm_rst_u_boot_r5: + +* 3.1 R5: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_spl_r5 +:end-before: .. k3_rst_include_end_build_steps_spl_r5 + +.. _j721s2_evm_rst_u_boot_a72: + +* 3.2 A72: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_uboot +:end-before: .. k3_rst_include_end_build_steps_uboot +.. j721s2_evm_rst_include_end_build_steps + +Target Images +-- +In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC +variant (GP, HS-FS, HS-SE) requires a different source for these files. + + - GP + +* tiboot3-j721s2-gp-evm.bin from :ref:`step 3.1 ` +* tispl.bin_unsigned, u-boot.img_unsigned from :ref:`step 3.2 ` + + - HS-FS + +* tiboot3-j721s2-hs-fs-evm.bin from :ref:`step 3.1 ` +* tispl.bin, u-boot.img from :ref:`step 3.2 ` + + - HS-SE + +* tiboot3-j721s2-hs-evm.bin from :ref:`step
[PATCH v7 5/7] arm: dts: k3-am68: Sync from Linux tag v6.6-rc1
The following commit syncs the device tree from Linux tag
v6.6-rc1 to U-boot and fixes the following to be compatible with
the future syncs -
- Include k3-am68-sk-base-board.dts file
Remove the duplicated pinmuxes from r5 and -u-boot.dtsi files and
include k3-am68-sk-base-board.dts for Linux fixes to propagate
to U-boot.
- Fixing the mcu_timer0
Remove timer0 and use the mcu_timer0 defined in mcu-wakeup.dtsi
- Fixing secure proxy nodes
Linux DT now have these nodes defined so remove them and rename to
use the Linux DT ones.
- Remove cpsw node
The compatible is now fixed and the node is not required in
-u-boot specifically
- Remove aliases and chosen node
Use these from Linux and don't override when not required.
- Remove /delete-property/ from sdhci nodes
We have the necessary clock and dev data so remove these.
- Remove dummy_clocks and fs_loader0
These weren't being used anywhere so remove it.
- Remove mcu_ringacc override
All these have been put in a single commit to not break the
bisectability.
Reviewed-by: Neha Malcom Francis
Reviewed-by: Nishanth Menon
Signed-off-by: Manorit Chawdhry
---
arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 119 +++---
arch/arm/dts/k3-am68-sk-base-board.dts | 524 +
arch/arm/dts/k3-am68-sk-r5-base-board.dts | 151 +--
arch/arm/dts/k3-am68-sk-som.dtsi | 112 +-
4 files changed, 453 insertions(+), 453 deletions(-)
diff --git a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
index 79faa1b5737d..4f34347586e0 100644
--- a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
@@ -1,69 +1,36 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-j721s2-binman.dtsi"
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
- aliases {
- serial0 = _uart0;
- serial1 = _uart0;
- serial2 = _uart8;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
- ethernet0 = _port1;
- mmc1 = _sdhci1;
- };
-};
-
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
};
_main {
- bootph-pre-ram;
+ bootph-all;
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_mcu_wakeup {
- bootph-pre-ram;
-
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
- bootph-pre-ram;
- };
+ bootph-all;
chipid@4314 {
- bootph-pre-ram;
+ bootph-all;
};
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_ringacc {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
- bootph-pre-ram;
+ bootph-all;
};
_udmap {
@@ -75,78 +42,94 @@
<0x0 0x2840 0x0 0x2000>;
reg-names = "gcfg", "rchan", "rchanrt", "tchan",
"tchanrt", "rflow";
- bootph-pre-ram;
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart8_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_mmc1_pins_default {
- bootph-pre-ram;
+ bootph-all;
+};
+
+_usbss0_pins_default {
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
+};
+
+_pmx1 {
+ bootph-all;
+};
+
+_pmx2 {
+ bootph-all;
+};
+
+_pmx3 {
+ bootph-all;
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
_uart8 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
-_cpsw {
- reg = <0x0 0x4600 0x0 0x20>,
- <0x0 0x40f00200 0x0 0x8>;
- reg-names = "cpsw_nuss", "mac_efuse";
- /delete-property/ ranges;
+_sdhci1 {
+ bootph-all;
+};
- cpsw-phy-sel@40f04040 {
-
[PATCH v7 4/7] arm: dts: k3-j721s2: Sync from Linux tag v6.6-rc1
The following commit syncs the device tree from Linux tag
v6.6-rc1 to U-boot and fixes the following to be compatible with
the future syncs -
- Include k3-j721s2-common-proc-board.dts file
Remove the duplicated pinmuxes from r5 and -u-boot.dtsi files and
include k3-j721s2-common-proc-board.dts for Linux fixes to propagate
to U-boot.
- Fixing the mcu_timer0
Remove timer0 and use the mcu_timer0 defined in mcu-wakeup.dtsi
- Fixing secure proxy nodes
Linux DT now have these nodes defined so remove them and rename to
use the Linux DT ones.
- Remove cpsw node
The compatible is now fixed and the node is not required in
-u-boot specifically
- Remove aliases and chosen node
Use these from Linux and don't override when not required.
- Remove /delete-property/ from sdhci nodes
We have the necessary clock and dev data so remove these.
- Remove dummy_clocks and fs_loader0
These weren't being used anywhere so remove it.
- Remove mcu_ringacc override
All these have been put in a single commit to not break the
bisectability.
Reviewed-by: Neha Malcom Francis
Reviewed-by: Nishanth Menon
Signed-off-by: Manorit Chawdhry
---
.../dts/k3-j721s2-common-proc-board-u-boot.dtsi| 112 ++-
arch/arm/dts/k3-j721s2-common-proc-board.dts | 376 ++
arch/arm/dts/k3-j721s2-main.dtsi | 777 -
arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 374 +-
arch/arm/dts/k3-j721s2-r5-common-proc-board.dts| 158 +
arch/arm/dts/k3-j721s2-som-p0.dtsi | 172 ++---
arch/arm/dts/k3-j721s2-thermal.dtsi| 101 +++
arch/arm/dts/k3-j721s2.dtsi| 12 +-
8 files changed, 1613 insertions(+), 469 deletions(-)
diff --git a/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
index f940ffee8787..a3ebf5996eac 100644
--- a/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721s2-common-proc-board-u-boot.dtsi
@@ -1,68 +1,36 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2021-2023 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-j721s2-binman.dtsi"
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
- aliases {
- serial0 = _uart0;
- serial1 = _uart0;
- serial2 = _uart8;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
- ethernet0 = _port1;
- };
-};
-
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
};
_main {
- bootph-pre-ram;
+ bootph-all;
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_mcu_wakeup {
- bootph-pre-ram;
-
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
- bootph-pre-ram;
- };
+ bootph-all;
chipid@4314 {
- bootph-pre-ram;
+ bootph-all;
};
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_ringacc {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
- bootph-pre-ram;
+ bootph-all;
};
_udmap {
@@ -74,78 +42,86 @@
<0x0 0x2840 0x0 0x2000>;
reg-names = "gcfg", "rchan", "rchanrt", "tchan",
"tchanrt", "rflow";
- bootph-pre-ram;
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart8_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_mmc1_pins_default {
- bootph-pre-ram;
+ bootph-all;
+};
+
+_usbss0_pins_default {
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
_uart8 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
+};
+
+_sdhci0 {
+ bootph-all;
};
-_cpsw {
- reg = <0x0 0x4600 0x0
[PATCH v7 3/7] arm: mach-k3: j721s2: Add mcu_timer0 id to the dev list
mcu_timer0 is used by u-boot as the tick-timer. Add it to the soc
devices lsit so it an be enabled via the k3 power controller.
Reviewed-by: Neha Malcom Francis
Reviewed-by: Nishanth Menon
Signed-off-by: Manorit Chawdhry
---
arch/arm/mach-k3/j721s2/dev-data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-k3/j721s2/dev-data.c
b/arch/arm/mach-k3/j721s2/dev-data.c
index 8c999a3c5a8b..df70c5e5d7c0 100644
--- a/arch/arm/mach-k3/j721s2/dev-data.c
+++ b/arch/arm/mach-k3/j721s2/dev-data.c
@@ -47,6 +47,7 @@ static struct ti_lpsc soc_lpsc_list[] = {
};
static struct ti_dev soc_dev_list[] = {
+ PSC_DEV(35, _lpsc_list[0]),
PSC_DEV(108, _lpsc_list[0]),
PSC_DEV(109, _lpsc_list[0]),
PSC_DEV(110, _lpsc_list[0]),
--
2.41.0
[PATCH v7 2/7] Revert "arm: dts: k3-j7*: ddr: Update to 0.10 version of DDR config tool"
The update causes instability in am68-sk boards so revert the patch in the meantime till fix is available. This reverts commit f1edf4bb6aa19732574ac23ca90cb9a0ba395ec1. Signed-off-by: Manorit Chawdhry --- arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi | 98 +++--- arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi | 464 +-- 2 files changed, 281 insertions(+), 281 deletions(-) diff --git a/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi b/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi index a0285ce0520e..5a6f9b11b8e3 100644 --- a/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi +++ b/arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi @@ -1,9 +1,9 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/ - * This file was generated by the Jacinto7_DDRSS_RegConfigTool, Revision: 0.10.0 - * This file was generated on 04/12/2023 - */ + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + * This file was generated by the Jacinto7_DDRSS_RegConfigTool, Revision: 0.9.1 + * This file was generated on 07/17/2022 +*/ #define DDRSS_PLL_FHS_CNT 10 #define DDRSS_PLL_FREQUENCY_0 2750 @@ -54,11 +54,11 @@ #define DDRSS_CTL_41_DATA 0x1B60008B #define DDRSS_CTL_42_DATA 0x2000422B #define DDRSS_CTL_43_DATA 0x000A0A09 -#define DDRSS_CTL_44_DATA 0x040003C5 +#define DDRSS_CTL_44_DATA 0x0400078A #define DDRSS_CTL_45_DATA 0x1E161104 -#define DDRSS_CTL_46_DATA 0x1000922C +#define DDRSS_CTL_46_DATA 0x10012458 #define DDRSS_CTL_47_DATA 0x1E161110 -#define DDRSS_CTL_48_DATA 0x1000922C +#define DDRSS_CTL_48_DATA 0x10012458 #define DDRSS_CTL_49_DATA 0x02030410 #define DDRSS_CTL_50_DATA 0x2C040500 #define DDRSS_CTL_51_DATA 0x082D2C2D @@ -71,11 +71,11 @@ #define DDRSS_CTL_58_DATA 0x00010100 #define DDRSS_CTL_59_DATA 0x0301 #define DDRSS_CTL_60_DATA 0x1008 -#define DDRSS_CTL_61_DATA 0x0063 +#define DDRSS_CTL_61_DATA 0x00CE #define DDRSS_CTL_62_DATA 0x0256 -#define DDRSS_CTL_63_DATA 0x1035 +#define DDRSS_CTL_63_DATA 0x2073 #define DDRSS_CTL_64_DATA 0x0256 -#define DDRSS_CTL_65_DATA 0x1035 +#define DDRSS_CTL_65_DATA 0x2073 #define DDRSS_CTL_66_DATA 0x0005 #define DDRSS_CTL_67_DATA 0x0004 #define DDRSS_CTL_68_DATA 0x00950012 @@ -112,27 +112,27 @@ #define DDRSS_CTL_99_DATA 0x #define DDRSS_CTL_100_DATA 0x00040005 #define DDRSS_CTL_101_DATA 0x -#define DDRSS_CTL_102_DATA 0x18C0 -#define DDRSS_CTL_103_DATA 0x18C0 -#define DDRSS_CTL_104_DATA 0x18C0 -#define DDRSS_CTL_105_DATA 0x18C0 -#define DDRSS_CTL_106_DATA 0x18C0 +#define DDRSS_CTL_102_DATA 0x3380 +#define DDRSS_CTL_103_DATA 0x3380 +#define DDRSS_CTL_104_DATA 0x3380 +#define DDRSS_CTL_105_DATA 0x3380 +#define DDRSS_CTL_106_DATA 0x3380 #define DDRSS_CTL_107_DATA 0x -#define DDRSS_CTL_108_DATA 0x02B5 -#define DDRSS_CTL_109_DATA 0x00040D40 -#define DDRSS_CTL_110_DATA 0x00040D40 -#define DDRSS_CTL_111_DATA 0x00040D40 -#define DDRSS_CTL_112_DATA 0x00040D40 -#define DDRSS_CTL_113_DATA 0x00040D40 +#define DDRSS_CTL_108_DATA 0x05A2 +#define DDRSS_CTL_109_DATA 0x00081CC0 +#define DDRSS_CTL_110_DATA 0x00081CC0 +#define DDRSS_CTL_111_DATA 0x00081CC0 +#define DDRSS_CTL_112_DATA 0x00081CC0 +#define DDRSS_CTL_113_DATA 0x00081CC0 #define DDRSS_CTL_114_DATA 0x -#define DDRSS_CTL_115_DATA 0x7173 -#define DDRSS_CTL_116_DATA 0x00040D40 -#define DDRSS_CTL_117_DATA 0x00040D40 -#define DDRSS_CTL_118_DATA 0x00040D40 -#define DDRSS_CTL_119_DATA 0x00040D40 -#define DDRSS_CTL_120_DATA 0x00040D40 +#define DDRSS_CTL_115_DATA 0xE325 +#define DDRSS_CTL_116_DATA 0x00081CC0 +#define DDRSS_CTL_117_DATA 0x00081CC0 +#define DDRSS_CTL_118_DATA 0x00081CC0 +#define DDRSS_CTL_119_DATA 0x00081CC0 +#define DDRSS_CTL_120_DATA 0x00081CC0 #define DDRSS_CTL_121_DATA 0x -#define DDRSS_CTL_122_DATA 0x7173 +#define DDRSS_CTL_122_DATA 0xE325 #define DDRSS_CTL_123_DATA 0x #define DDRSS_CTL_124_DATA 0x #define DDRSS_CTL_125_DATA 0x @@ -399,29 +399,29 @@ #define DDRSS_CTL_386_DATA 0x #define DDRSS_CTL_387_DATA 0x3A3A1B00 #define DDRSS_CTL_388_DATA 0x000A -#define DDRSS_CTL_389_DATA 0x00C6 +#define DDRSS_CTL_389_DATA 0x019C #define DDRSS_CTL_390_DATA 0x0200 #define DDRSS_CTL_391_DATA 0x0200 #define DDRSS_CTL_392_DATA 0x0200 #define DDRSS_CTL_393_DATA 0x0200 -#define DDRSS_CTL_394_DATA 0x0252 -#define DDRSS_CTL_395_DATA 0x07BC +#define DDRSS_CTL_394_DATA 0x04D4 +#define DDRSS_CTL_395_DATA 0x1018 #define DDRSS_CTL_396_DATA 0x0204 -#define DDRSS_CTL_397_DATA 0x206A +#define DDRSS_CTL_397_DATA 0x40E6 #define DDRSS_CTL_398_DATA 0x0200 #define DDRSS_CTL_399_DATA 0x0200 #define DDRSS_CTL_400_DATA 0x0200 #define DDRSS_CTL_401_DATA 0x0200 -#define DDRSS_CTL_402_DATA 0x613E -#define DDRSS_CTL_403_DATA 0x00014424 +#define DDRSS_CTL_402_DATA 0xC2B2 +#define
[PATCH v7 1/7] configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM
From: Udit Kumar The malloc capacity in DRAM at R5 SPL is set to 1MB which isn't sufficient to load the new tispl.bin to enable loading of tispl.bin the size is increased by 256KB to 1.25MB. Cc: Nikhil M Jain Signed-off-by: Udit Kumar Reviewed-by: Nishanth Menon Signed-off-by: Manorit Chawdhry --- configs/j721s2_evm_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig index 1e66ac23d05b..e2b83b337809 100644 --- a/configs/j721s2_evm_r5_defconfig +++ b/configs/j721s2_evm_r5_defconfig @@ -42,6 +42,7 @@ CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x14 CONFIG_SPL_SEPARATE_BSS=y CONFIG_SYS_SPL_MALLOC=y CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y -- 2.41.0
[PATCH v7 0/7] J721S2 DTS Sync from v6.6-rc1 to u-boot
The sync tries to ensure that U-boot remains functional with the updated Linux DTS and all the fixes from Linux move to U-boot during the sync. The series tries to sync from Linux v6.6-rc1 along with addition of the documentation for J721S2 that had been previously missing. DMA fixes [0] are currently being upstreamed to Linux. Test Logs are included in [1] [0]: https://lore.kernel.org/all/20230810174356.3322583-1-vigne...@ti.com/ [1]: https://gist.github.com/manorit2001/dbad09fd00e8b7c3872e85874c8e648c Signed-off-by: Manorit Chawdhry --- Changes in v7: - Convert bootph-pre-ram to bootph-all in -u-boot.dtsi (Refer to https://lore.kernel.org/all/capnjgz3mgwx8t0a0sofpher_xd77pe3hte9dnye1rubveb9...@mail.gmail.com/) - Link to v6: https://lore.kernel.org/r/20230921-b4-upstream-j721s2-r5-pinmux-v6-0-ca9639c1a...@ti.com --- Manorit Chawdhry (6): Revert "arm: dts: k3-j7*: ddr: Update to 0.10 version of DDR config tool" arm: mach-k3: j721s2: Add mcu_timer0 id to the dev list arm: dts: k3-j721s2: Sync from Linux tag v6.6-rc1 arm: dts: k3-am68: Sync from Linux tag v6.6-rc1 docs: board: ti: Add j721s2_evm documentation board: ti: j721s2: MAINTAINERS: Update the MAINTAINERS File. Udit Kumar (1): configs: j721s2_evm_r5_defconfig: Increase malloc pool size in DRAM arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 119 ++-- arch/arm/dts/k3-am68-sk-base-board.dts | 524 +- arch/arm/dts/k3-am68-sk-r5-base-board.dts | 151 +--- arch/arm/dts/k3-am68-sk-som.dtsi | 112 +-- arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi| 98 +-- .../dts/k3-j721s2-common-proc-board-u-boot.dtsi| 112 ++- arch/arm/dts/k3-j721s2-common-proc-board.dts | 376 ++ arch/arm/dts/k3-j721s2-ddr-evm-lp4-4266.dtsi | 464 ++-- arch/arm/dts/k3-j721s2-main.dtsi | 777 - arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 374 +- arch/arm/dts/k3-j721s2-r5-common-proc-board.dts| 158 + arch/arm/dts/k3-j721s2-som-p0.dtsi | 172 ++--- arch/arm/dts/k3-j721s2-thermal.dtsi| 101 +++ arch/arm/dts/k3-j721s2.dtsi| 12 +- arch/arm/mach-k3/j721s2/dev-data.c | 1 + board/ti/j721s2/MAINTAINERS| 11 +- configs/j721s2_evm_r5_defconfig| 1 + doc/board/ti/j721s2_evm.rst| 341 + doc/board/ti/k3.rst| 1 + 19 files changed, 2700 insertions(+), 1205 deletions(-) --- base-commit: e29b932aa07fa0226d325b35d96cd4eea0370129 change-id: 20230816-b4-upstream-j721s2-r5-pinmux-25c4cd61b258 Best regards, -- Manorit Chawdhry
Re: [PATCH] arm: dts: k3-j721e-sk/common-proc-board: Fix boot
Hi Nishanth,
On 05/10/23 23:45, Nishanth Menon wrote:
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node
as pre-reloc after relocation") A53 u-boot proper is broken. This is
because nodes marked as 'bootph-pre-ram' are not available at u-boot
proper before relocation.
To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.
Fixes: 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1")
Cc: Neha Francis
Signed-off-by: Nishanth Menon
Thanks for this patch!
Tested-by: Neha Malcom Francis
(Tested on J721E-EVM and J721E-sk)
--
Thanking You
Neha Malcom Francis
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
Hi Nishanth, On 06:26-20231005, Nishanth Menon wrote: > On 10:29-20231005, Manorit Chawdhry wrote: > > Hi Nishanth, > > > > On 07:24-20231004, Nishanth Menon wrote: > > > On 10:43-20231004, Manorit Chawdhry wrote: > > > > > > > These are required to remove the firewall configurations that are done > > > > by ROM, those are not the ones that are being handled by OIDs. The > > > > > > I am not sure I understand this clearly. OIDs are setup to open up > > > firewalls or close firewalls as the system requires and since it > > > is authenticated, not compromiseable.- U-boot by itself (even if > > > authenticated), is not a secure entity for it to dictate the firewall > > > configuration (u-boot must be assumed to be compromised after > > > authentication is complete). So, doing firewall configuration via APIs > > > after boot, to me looks broken approach. > > > > > > > I know U-boot ain't that secure given the most trusted entity is always > > gonna be the software that starts up the system, we can't expect those > > to be doing all the work and based on that we have the secure boot > > designed to configure firewalls (that are not owned by anymore) and > > U-boot R5 being one of the early bootloaders do come as a part of it. > > > > Regarding the OIDs thing, I don't think the OID in question is looked by > > ROM and ROM always configures some firewalls for it's usecase that are > > present in those arrays. > > > > The OID that we are using in the series that you had shared is looked by > > TIFS instead of ROM and TIFS is the entity that is authenticating the > > binary along with setting up the firewalls. > > > > > > current series that is being worked on is to add additional firewalling > > > > support with OIDs that TIFS will be handling. > > > > The above patch is > > > > essentially added to have the same development experience on GP devices > > > > similar to HS after the secure boot is done so that people don't end up > > > > > > huh? the code seems to blindly call the > > > remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); > > > where is the distinction of HS vs GP here? This implementation looks > > > completely broken to me at least.. please correct what I missed here. > > > > Since this call is used across all SoCs there wasn't any point to make > > the differentiation between GP and HS here, remove_fwl_configs > > internally handles looking at the firewalls and disabling them if they > > are enabled ( Which would be only in the case of HS devices ), for GP it > > would automatically by a noop. > > Correct me if I understand the security chain here: > > ROM sets up firewalls that are needed by itself > TIFS (in multicertificate will setup it's own firewalls) > R5 SPL comes along and opens up other firewalls > Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to > set up firewalls to protect themselves (enforced by TIFS) > A53 SPL and U-boot itself startups but has no ability to change the > protection firewalls enforced by x509 OIDs. > > Further, firewalls have lockdown bit that enforces the setting (and > cannot be over-ridden) till system restart is requested > > Is this correct? If so, needs to be clearly documented. Yes, this seems correct. Will be updating it in the upstream documentation in another series. Thanks and regards, Manorit > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D
Re: [PATCH 05/25] treewide: Correct use of long help
On Thu, Oct 05, 2023 at 07:41:49PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 5 Oct 2023 at 08:53, Tom Rini wrote: > > > > On Wed, Oct 04, 2023 at 07:23:47PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sun, 24 Sept 2023 at 17:27, Tom Rini wrote: > > > > > > > > On Sun, Sep 24, 2023 at 02:39:23PM -0600, Simon Glass wrote: > > > > > Some commands assume that CONFIG_SYS_LONGHELP is always defined. > > > > > Declaration of long help should be bracketed by an #ifdef to avoid an > > > > > 'unused variable' warning. > > > > > > > > > > Fix this treewide. > > > > > > > > > > Signed-off-by: Simon Glass > > > > [snip] > > > > > diff --git a/arch/arm/mach-imx/cmd_dek.c b/arch/arm/mach-imx/cmd_dek.c > > > > > index 6fa5b41fcd38..25ea7d3b37da 100644 > > > > > --- a/arch/arm/mach-imx/cmd_dek.c > > > > > +++ b/arch/arm/mach-imx/cmd_dek.c > > > > > @@ -393,11 +393,12 @@ static int do_dek_blob(struct cmd_tbl *cmdtp, > > > > > int flag, int argc, > > > > > return blob_encap_dek(src_addr, dst_addr, len); > > > > > } > > > > > > > > > > -/***/ > > > > > +#if IS_ENABLED(CONFIG_SYS_LONGHELP) > > > > > static char dek_blob_help_text[] = > > > > > "src dst len- Encapsulate and create blob of data\n" > > > > > " $len bits long at address $src and\n" > > > > > " store the result at address $dst.\n"; > > > > > +#endif > > > > > > > > > > U_BOOT_CMD( > > > > > dek_blob, 4, 1, do_dek_blob, > > > > > > > > This really doesn't read nicely. I would rather (globally and fix > > > > existing users) __maybe_unused this instead. I think there's just one > > > > example today that isn't "foo_help_text". > > > > > > Hmm, what do you think about adding a __longhelp symbol to cause the > > > linker to discard it when not needed? > > > > Well, I don't think we need linker list magic when __maybe_unused will > > just have them be discarded normally. > > Yes, perhaps things are in a better state than they used to be, but > there is a linker discard for commands at present. Yes, but __maybe_unused means we don't get a warning about it, and it's literally discarded as part of --gc-sections as it done everywhere with maybe 3 exceptions? -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/25] treewide: Correct use of long help
Hi Tom,
On Thu, 5 Oct 2023 at 08:53, Tom Rini wrote:
>
> On Wed, Oct 04, 2023 at 07:23:47PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 24 Sept 2023 at 17:27, Tom Rini wrote:
> > >
> > > On Sun, Sep 24, 2023 at 02:39:23PM -0600, Simon Glass wrote:
> > > > Some commands assume that CONFIG_SYS_LONGHELP is always defined.
> > > > Declaration of long help should be bracketed by an #ifdef to avoid an
> > > > 'unused variable' warning.
> > > >
> > > > Fix this treewide.
> > > >
> > > > Signed-off-by: Simon Glass
> > > [snip]
> > > > diff --git a/arch/arm/mach-imx/cmd_dek.c b/arch/arm/mach-imx/cmd_dek.c
> > > > index 6fa5b41fcd38..25ea7d3b37da 100644
> > > > --- a/arch/arm/mach-imx/cmd_dek.c
> > > > +++ b/arch/arm/mach-imx/cmd_dek.c
> > > > @@ -393,11 +393,12 @@ static int do_dek_blob(struct cmd_tbl *cmdtp, int
> > > > flag, int argc,
> > > > return blob_encap_dek(src_addr, dst_addr, len);
> > > > }
> > > >
> > > > -/***/
> > > > +#if IS_ENABLED(CONFIG_SYS_LONGHELP)
> > > > static char dek_blob_help_text[] =
> > > > "src dst len- Encapsulate and create blob of data\n"
> > > > " $len bits long at address $src and\n"
> > > > " store the result at address $dst.\n";
> > > > +#endif
> > > >
> > > > U_BOOT_CMD(
> > > > dek_blob, 4, 1, do_dek_blob,
> > >
> > > This really doesn't read nicely. I would rather (globally and fix
> > > existing users) __maybe_unused this instead. I think there's just one
> > > example today that isn't "foo_help_text".
> >
> > Hmm, what do you think about adding a __longhelp symbol to cause the
> > linker to discard it when not needed?
>
> Well, I don't think we need linker list magic when __maybe_unused will
> just have them be discarded normally.
Yes, perhaps things are in a better state than they used to be, but
there is a linker discard for commands at present.
SECTIONS
{
#ifndef CONFIG_CMDLINE
/DISCARD/ : { *(__u_boot_list_2_cmd_*) }
#endif
...
from:
c1352119fd0 arm: x86: Drop command-line code when CONFIG_CMDLINE is disabled
I wonder if we can remove it? I suppose once this series is sorted out
we could have a test to make sure no command is making it into the
image when ~CMDLINE
Regards,
Simon
Re: [PATCH] sphinx: Bump urllib3 version
On Thu, 5 Oct 2023 at 10:27, Tom Rini wrote: > > While not a direct issue for us, urllib3 before 1.26.17 is vulnerable to > CVE-2023-43804 to bump our version up. > > Reported-by: GitHub dependabot > Signed-off-by: Tom Rini > --- > Cc: Heinrich Schuchardt > --- > doc/sphinx/requirements.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 1/1] [u-boot][master][PATCH v4] pico-imx7d: add baseboard SD card boot detect
On Thu, Oct 5, 2023 at 6:40 PM wrote:
>
> From: Benjamin Szőke
>
> Take over codes from Techenxion to support mmc autodetect boot for pico-imx7d.
>
> Signed-off-by: Benjamin Szőke
Still not good:
WARNING: Possible unwrapped commit description (prefer a maximum 75
chars per line)
#57:
Take over codes from Techenxion to support mmc autodetect boot for pico-imx7d.
WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
where possible
#90: FILE: board/technexion/pico-imx7d/pico-imx7d.c:134:
+#if CONFIG_IS_ENABLED(FSL_ESDHC_IMX)
CHECK: Unnecessary parentheses around 'autodetect_str != NULL'
#95: FILE: board/technexion/pico-imx7d/pico-imx7d.c:139:
+ if ((autodetect_str != NULL) &&
+ (strcmp(autodetect_str, "yes") == 0)) {
CHECK: Comparison to NULL could be written "autodetect_str"
#95: FILE: board/technexion/pico-imx7d/pico-imx7d.c:139:
+ if ((autodetect_str != NULL) &&
CHECK: Alignment should match open parenthesis
#96: FILE: board/technexion/pico-imx7d/pico-imx7d.c:140:
+ if ((autodetect_str != NULL) &&
+ (strcmp(autodetect_str, "yes") == 0)) {
ERROR: switch and case should be at the same indent
#111: FILE: board/technexion/pico-imx7d/pico-imx7d.c:155:
+ switch (get_boot_device()) {
+ case SD3_BOOT:
+ case MMC3_BOOT:
[...]
+ case SD1_BOOT:
[...]
+ default:
ERROR: trailing whitespace
#127: FILE: board/technexion/pico-imx7d/pico-imx7d.c:171:
+^I$
WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
where possible
#140: FILE: board/technexion/pico-imx7d/pico-imx7d.c:224:
+#if CONFIG_IS_ENABLED(FSL_ESDHC_IMX)
WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
where possible
#141: FILE: board/technexion/pico-imx7d/pico-imx7d.c:225:
+#if defined(CONFIG_ENV_IS_IN_MMC) || defined(CONFIG_ENV_IS_NOWHERE)
WARNING: Move const after static - use 'static const iomux_v3_cfg_t'
#178: FILE: board/technexion/pico-imx7d/spl.c:165:
+static iomux_v3_cfg_t const usdhc1_pads[] = {
WARNING: Move const after static - use 'static const iomux_v3_cfg_t'
#189: FILE: board/technexion/pico-imx7d/spl.c:176:
+static iomux_v3_cfg_t const usdhc3_emmc_pads[] = {
CHECK: Lines should not end with a '('
#238: FILE: board/technexion/pico-imx7d/spl.c:225:
+ imx_iomux_v3_setup_multiple_pads(
CHECK: Lines should not end with a '('
#242: FILE: board/technexion/pico-imx7d/spl.c:229:
+ imx_iomux_v3_setup_multiple_pads(
ERROR: switch and case should be at the same indent
#246: FILE: board/technexion/pico-imx7d/spl.c:233:
+ switch (get_boot_device()) {
+ case SD1_BOOT:
[...]
+ case MMC3_BOOT:
[...]
+ case SD3_BOOT:
+ default:
total: 3 errors, 6 warnings, 5 checks, 220 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
[PATCH 1/1] [u-boot][master][PATCH v4] pico-imx7d: add baseboard SD card boot detect
From: Benjamin Szőke
Take over codes from Techenxion to support mmc autodetect boot for pico-imx7d.
Signed-off-by: Benjamin Szőke
---
board/technexion/pico-imx7d/pico-imx7d.c | 57 +++
board/technexion/pico-imx7d/spl.c| 91 ++--
include/configs/pico-imx7d.h | 4 +-
3 files changed, 144 insertions(+), 8 deletions(-)
diff --git a/board/technexion/pico-imx7d/pico-imx7d.c
b/board/technexion/pico-imx7d/pico-imx7d.c
index 6e98b85b28..a3fa915b49 100644
--- a/board/technexion/pico-imx7d/pico-imx7d.c
+++ b/board/technexion/pico-imx7d/pico-imx7d.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -13,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -129,6 +131,49 @@ int board_phy_config(struct phy_device *phydev)
}
#endif
+#if CONFIG_IS_ENABLED(FSL_ESDHC_IMX)
+int check_mmc_autodetect(void)
+{
+ char *autodetect_str = env_get("mmcautodetect");
+
+ if ((autodetect_str != NULL) &&
+ (strcmp(autodetect_str, "yes") == 0)) {
+ return 1;
+ }
+
+ return 0;
+}
+
+void board_late_mmc_init(void)
+{
+ int dev_no = 0;
+ char cmd[32];
+
+ if (!check_mmc_autodetect())
+ return;
+
+ switch (get_boot_device()) {
+ case SD3_BOOT:
+ case MMC3_BOOT:
+ env_set("bootdev", "MMC3");
+ dev_no = 2;
+ break;
+ case SD1_BOOT:
+ env_set("bootdev", "SD1");
+ dev_no = 0;
+ break;
+ default:
+ printf("Wrong boot device!");
+ }
+
+ /* Set mmcdev env */
+ env_set_ulong("mmcdev", dev_no);
+
+ sprintf(cmd, "mmc dev %d", dev_no);
+ run_command(cmd, 0);
+}
+#endif
+
static void setup_iomux_uart(void)
{
imx_iomux_v3_setup_multiple_pads(uart5_pads, ARRAY_SIZE(uart5_pads));
@@ -176,6 +221,12 @@ int board_late_init(void)
set_wdog_reset(wdog);
+#if CONFIG_IS_ENABLED(FSL_ESDHC_IMX)
+#if defined(CONFIG_ENV_IS_IN_MMC) || defined(CONFIG_ENV_IS_NOWHERE)
+ board_late_mmc_init();
+#endif /* CONFIG_ENV_IS_IN_MMC or CONFIG_ENV_IS_NOWHERE */
+#endif
+
/*
* Do not assert internal WDOG_RESET_B_DEB(controlled by bit 4),
* since we use PMIC_PWRON to reset the board.
@@ -210,3 +261,9 @@ int board_ehci_hcd_init(int port)
}
return 0;
}
+
+/* This should be defined for each board */
+__weak int mmc_map_to_kernel_blk(int dev_no)
+{
+ return dev_no;
+}
diff --git a/board/technexion/pico-imx7d/spl.c
b/board/technexion/pico-imx7d/spl.c
index c6b21aaa42..2fe76145be 100644
--- a/board/technexion/pico-imx7d/spl.c
+++ b/board/technexion/pico-imx7d/spl.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -159,7 +160,20 @@ void reset_cpu(void)
#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
-static iomux_v3_cfg_t const usdhc3_pads[] = {
+#define USDHC1_CD_GPIO IMX_GPIO_NR(5, 0)
+/* EMMC/SD */
+static iomux_v3_cfg_t const usdhc1_pads[] = {
+ MX7D_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_CMD__SD1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+
+#define USDHC3_CD_GPIO IMX_GPIO_NR(1, 14)
+static iomux_v3_cfg_t const usdhc3_emmc_pads[] = {
MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -173,20 +187,83 @@ static iomux_v3_cfg_t const usdhc3_pads[] = {
MX7D_PAD_GPIO1_IO14__GPIO1_IO14 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
};
-static struct fsl_esdhc_cfg usdhc_cfg[1] = {
+static struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC3_BASE_ADDR},
+ {USDHC1_BASE_ADDR},
};
int board_mmc_getcd(struct mmc *mmc)
{
- /* Assume uSDHC3 emmc is always present */
- return 1;
+ struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
+ int ret = 0;
+
+ switch (cfg->esdhc_base) {
+ case USDHC1_BASE_ADDR:
+ ret = !gpio_get_value(USDHC1_CD_GPIO); /* Assume uSDHC1 sd is
always present */
+ break;
+ case USDHC3_BASE_ADDR:
+ ret = !gpio_get_value(USDHC3_CD_GPIO); /* Assume uSDHC3 emmc is
always present */
+ break;
+ }
+
+ return ret;
}
int board_mmc_init(struct bd_info
[RFC PATCH v2 4/4] HACK: enable access to `ubi 0:volname` block devices
---
disk/part.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/disk/part.c b/disk/part.c
index a4b6d265da..7c995f583c 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -14,6 +14,9 @@
#include
#include
#include
+#include
+#include
+#include
#undef PART_DEBUG
@@ -524,6 +527,58 @@ int blk_get_device_part_str(const char *ifname, const char
*dev_part_str,
}
#endif
+#if IS_ENABLED(CONFIG_CMD_UBI) && !IS_ENABLED(CONFIG_SPL_BUILD)
+ /*
+* Also special-case UBI, which may use names to find the specific
+* volumes, so this deviates a bit from the typical devnum:partnum
+* syntax.
+*/
+ if (!strcmp(ifname, "ubi")) {
+ dev = dectoul(dev_part_str, );
+ if (*ep == ':') {
+ struct udevice *ubi_dev = NULL;
+ struct udevice *vol_dev = NULL;
+ part_str = [1];
+
+ ret = uclass_find_device(UCLASS_UBI, dev, _dev);
+ if (!ubi_dev || ret) {
+ printf("** Cannot find UBI %x\n", dev);
+ return -EINVAL;
+ }
+
+ part = dectoul(part_str, );
+ if (!*ep) {
+ struct udevice *tmp_dev;
+ device_foreach_child(tmp_dev, ubi_dev) {
+ struct blk_desc *desc =
dev_get_uclass_plat(tmp_dev);
+ if (desc->devnum == part) {
+ vol_dev = tmp_dev;
+ break;
+ }
+ }
+ } else {
+ ret = device_find_child_by_name(ubi_dev,
part_str, _dev);
+ }
+
+ if (!vol_dev || ret) {
+ printf("** UBI volume %s not found\n",
part_str);
+ return -EINVAL;
+ }
+
+ ret = device_probe(vol_dev);
+ if (ret)
+ return ret;
+
+ *desc = dev_get_uclass_plat(vol_dev);
+ part_get_info_whole_disk(*desc, info);
+ return 0;
+ }
+
+ printf("UBIFS not mounted, use ubifsmount to mount volume
first!\n");
+ return -EINVAL;
+ }
+#endif
+
/* If no dev_part_str, use bootdevice environment variable */
if (CONFIG_IS_ENABLED(ENV_SUPPORT)) {
if (!dev_part_str || !strlen(dev_part_str) ||
--
2.41.0
[RFC PATCH v2 3/4] disk: part: fall-through if "ubi" requested but ubifs not mounted
Since we're adding the ability to access static UBI volumes as block
devices, it is no longer an error to use the "ubi" ifname with UBIFS
unmounted.
Ideally, the access to UBIFS should instead be called "ubifs" but it
would break backwards compatibility to change this. Instead, use the
UBIFS mount status to disambiguate what the user means by "ubi"
There is no change in functionality in this patch: UBIFS access works
the same and an error still occurs when using "ubi" without UBIFS
mounted. The only difference is that now, the error message is a plain
"Bad device specification" and does not suggest using ubifsmount.
Signed-off-by: Sam Edwards
---
disk/part.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 72241b7b23..a4b6d265da 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -511,15 +511,13 @@ int blk_get_device_part_str(const char *ifname, const
char *dev_part_str,
#if IS_ENABLED(CONFIG_CMD_UBIFS) && !IS_ENABLED(CONFIG_SPL_BUILD)
/*
-* Special-case ubi, ubi goes through a mtd, rather than through
-* a regular block device.
+* Special-case ubifs, which does not go through the block device layer
+* and also must be mounted ahead of time. U-Boot has historically
+* called this "ubi" too, even though *static* UBI volumes are
+* accessible as block devices. For backward compatibility, assume that
+* when UBIFS is mounted, the user intends "ubi" to mean "ubifs."
*/
- if (!strcmp(ifname, "ubi")) {
- if (!ubifs_is_mounted()) {
- printf("UBIFS not mounted, use ubifsmount to mount
volume first!\n");
- return -EINVAL;
- }
-
+ if (ubifs_is_mounted() && !strcmp(ifname, "ubi")) {
strcpy((char *)info->type, BOOT_PART_TYPE);
strcpy((char *)info->name, "UBI");
return 0;
--
2.41.0
[RFC PATCH v2 1/4] mtd: ubi: register UBI attachments as DM devices
This is in preparation for exposing static UBI volumes as block devices.
A UBI uclass and driver are introduced, and a "ubi0" virtual device
with the proper driver is created below whichever MTD device is
attached as the active UBI partition. This virtual device will soon
be the parent for the BLK devices that represent the static volumes.
Signed-off-by: Sam Edwards
---
cmd/ubi.c| 11 ++
drivers/mtd/ubi/Makefile | 1 +
drivers/mtd/ubi/ubi-uclass.c | 74
include/dm/uclass-id.h | 1 +
include/ubi_uboot.h | 5 +++
5 files changed, 92 insertions(+)
create mode 100644 drivers/mtd/ubi/ubi-uclass.c
diff --git a/cmd/ubi.c b/cmd/ubi.c
index 0a6a80bdd1..314c7f60f4 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -560,6 +560,13 @@ static int ubi_detach(void)
cmd_ubifs_umount();
#endif
+#ifdef CONFIG_DM_MTD
+ /*
+* Clean up any UBI devices in DM
+*/
+ ubi_dm_unbind_all();
+#endif
+
/*
* Call ubi_exit() before re-initializing the UBI subsystem
*/
@@ -598,6 +605,10 @@ int ubi_part(char *part_name, const char
*vid_header_offset)
return err;
}
+#ifdef CONFIG_DM_MTD
+ ubi_dm_bind(0);
+#endif
+
ubi = ubi_devices[0];
return 0;
diff --git a/drivers/mtd/ubi/Makefile b/drivers/mtd/ubi/Makefile
index 30d00fbdfe..375075f75e 100644
--- a/drivers/mtd/ubi/Makefile
+++ b/drivers/mtd/ubi/Makefile
@@ -7,3 +7,4 @@ obj-y += attach.o build.o vtbl.o vmt.o upd.o kapi.o eba.o io.o
wl.o crc32.o
obj-$(CONFIG_MTD_UBI_FASTMAP) += fastmap.o
obj-y += misc.o
obj-y += debug.o
+obj-$(CONFIG_DM_MTD) += ubi-uclass.o
diff --git a/drivers/mtd/ubi/ubi-uclass.c b/drivers/mtd/ubi/ubi-uclass.c
new file mode 100644
index 00..f8971e793e
--- /dev/null
+++ b/drivers/mtd/ubi/ubi-uclass.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * ubi-uclass.c - UBI partition and volume block device uclass driver
+ *
+ * Copyright (C) 2023 Sam Edwards
+ */
+
+#define LOG_CATEGORY UCLASS_UBI
+
+#include
+#include
+#include
+#include
+
+int ubi_dm_bind(unsigned int index)
+{
+ struct udevice *dev;
+ int ret;
+ char name[16];
+ const char *name_dup;
+ struct ubi_device *ubi = ubi_devices[index];
+ const struct mtd_info *mtd = ubi->mtd;
+
+ /* MTD partitions are not in DM; navigate to the real MTD device */
+ if (mtd->parent)
+ mtd = mtd->parent;
+
+ snprintf(name, sizeof(name), "ubi%u", index);
+ name_dup = strdup(name);
+ ret = device_bind(mtd->dev, DM_DRIVER_GET(ubi), name_dup, ubi,
+ ofnode_null(), );
+ if (ret) {
+ free((void *)name_dup);
+ return ret;
+ }
+
+ device_set_name_alloced(dev);
+
+ return 0;
+}
+
+int ubi_dm_unbind_all(void)
+{
+ int ret;
+ struct uclass *uc;
+ struct udevice *dev;
+ struct udevice *next;
+
+ ret = uclass_get(UCLASS_UBI, );
+ if (ret)
+ return ret;
+
+ uclass_foreach_dev_safe(dev, next, uc) {
+ ret = device_remove(dev, DM_REMOVE_NORMAL);
+ if (ret)
+ return ret;
+
+ ret = device_unbind(dev);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+U_BOOT_DRIVER(ubi) = {
+ .id = UCLASS_UBI,
+ .name = "ubi_dev",
+};
+
+UCLASS_DRIVER(ubi) = {
+ .id = UCLASS_UBI,
+ .name = "ubi",
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 0432c95c9e..ee11fbb38d 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -140,6 +140,7 @@ enum uclass_id {
UCLASS_THERMAL, /* Thermal sensor */
UCLASS_TIMER, /* Timer device */
UCLASS_TPM, /* Trusted Platform Module TIS interface */
+ UCLASS_UBI, /* Unsorted Block Images MTD partition */
UCLASS_UFS, /* Universal Flash Storage */
UCLASS_USB, /* USB bus */
UCLASS_USB_DEV_GENERIC, /* USB generic device */
diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
index 6da348eb62..9d37848f03 100644
--- a/include/ubi_uboot.h
+++ b/include/ubi_uboot.h
@@ -52,6 +52,11 @@ extern int ubi_part(char *part_name, const char
*vid_header_offset);
extern int ubi_volume_write(char *volume, void *buf, size_t size);
extern int ubi_volume_read(char *volume, char *buf, size_t size);
+#ifdef CONFIG_DM_MTD
+extern int ubi_dm_bind(unsigned int);
+extern int ubi_dm_unbind_all(void);
+#endif
+
extern struct ubi_device *ubi_devices[];
int cmd_ubifs_mount(char *vol_name);
int cmd_ubifs_umount(void);
--
2.41.0
[RFC PATCH v2 2/4] mtd: ubi: bind block device driver for static volumes
This makes static UBI volumes readable as block devices, however
no mechanism for selecting these volume devices yet exists.
Signed-off-by: Sam Edwards
---
drivers/mtd/ubi/ubi-uclass.c | 111 +++
1 file changed, 111 insertions(+)
diff --git a/drivers/mtd/ubi/ubi-uclass.c b/drivers/mtd/ubi/ubi-uclass.c
index f8971e793e..b2c47bfe0c 100644
--- a/drivers/mtd/ubi/ubi-uclass.c
+++ b/drivers/mtd/ubi/ubi-uclass.c
@@ -8,10 +8,120 @@
#define LOG_CATEGORY UCLASS_UBI
#include
+#include
#include
#include
#include
+static ulong ubi_bread(struct udevice *dev, lbaint_t lba, lbaint_t blkcnt,
+ void *dst)
+{
+ int err, lnum;
+ struct blk_desc *blk = dev_get_uclass_plat(dev);
+ struct ubi_device *ubi = dev_get_plat(dev->parent);
+ struct ubi_volume *vol = ubi->volumes[blk->devnum];
+ lbaint_t lba_per_peb = vol->usable_leb_size / blk->blksz;
+ lbaint_t lba_off, lba_len, total = 0;
+
+ while (blkcnt) {
+ lnum = lba / lba_per_peb;
+ lba_off = lba % lba_per_peb;
+ lba_len = lba_per_peb - lba_off;
+ if (lba_len > blkcnt)
+ lba_len = blkcnt;
+
+ err = ubi_eba_read_leb(ubi, vol, lnum, dst,
+ lba_off << blk->log2blksz,
+ lba_len << blk->log2blksz, 0);
+ if (err) {
+ pr_err("UBI read error %x\n", err);
+ break;
+ }
+
+ lba += lba_len;
+ blkcnt -= lba_len;
+ dst += lba_len << blk->log2blksz;
+ total += lba_len;
+ }
+
+ return total;
+}
+
+static const struct blk_ops ubi_block_ops = {
+ .read = ubi_bread,
+};
+
+U_BOOT_DRIVER(ubi_block) = {
+ .name = "ubi_block",
+ .id = UCLASS_BLK,
+ .ops= _block_ops,
+};
+
+static bool is_power_of_two(unsigned int x)
+{
+ return (x & -x) == x;
+}
+
+static unsigned int choose_blksz_for_volume(const struct ubi_volume *vol)
+{
+ /*
+* U-Boot assumes a power-of-two blksz; however, UBI LEBs are
+* very often not suitably sized. To solve this, we divide the
+* LEBs into a whole number of LBAs per LEB, such that each LBA
+* addresses a power-of-two-sized block. To choose the blksz,
+* we either:
+* 1) Use the volume alignment, if it's a non-unity power of
+*two. The LEB size is a multiple of this alignment, and it
+*allows the user to force a particular blksz if needed for
+*their use case.
+* 2) Otherwise, find the greatest power-of-two factor of the
+*LEB size.
+*/
+ if (vol->alignment > 1 && is_power_of_two(vol->alignment))
+ return vol->alignment;
+
+ unsigned int blksz = 1;
+ while ((vol->usable_leb_size & blksz) == 0)
+ blksz <<= 1;
+ return blksz;
+}
+
+static int ubi_post_bind(struct udevice *dev)
+{
+ int i;
+ int ret;
+ unsigned int blksz;
+ lbaint_t lba;
+ struct udevice *blkdev;
+ struct ubi_device *ubi = dev_get_plat(dev);
+
+ for (i = 0; i < ubi->vtbl_slots; i++) {
+ struct ubi_volume *vol = ubi->volumes[i];
+ if (!vol || vol->vol_id >= UBI_INTERNAL_VOL_START ||
+ vol->vol_type != UBI_STATIC_VOLUME)
+ continue;
+
+ if (vol->updating || vol->upd_marker) {
+ pr_err("** UBI volume %d (\"%s\") midupdate; ignored\n",
+ vol->vol_id, vol->name);
+ continue;
+ }
+
+ blksz = choose_blksz_for_volume(vol);
+ lba = DIV_ROUND_UP((unsigned long long)vol->used_bytes, blksz);
+
+ pr_debug("UBI volume %d (\"%s\"): %lu blocks, %d bytes each\n",
+vol->vol_id, vol->name, lba, blksz);
+
+ ret = blk_create_device(dev, "ubi_block", vol->name, UCLASS_UBI,
+ vol->vol_id, blksz, lba, );
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
int ubi_dm_bind(unsigned int index)
{
struct udevice *dev;
@@ -71,4 +181,5 @@ U_BOOT_DRIVER(ubi) = {
UCLASS_DRIVER(ubi) = {
.id = UCLASS_UBI,
.name = "ubi",
+ .post_bind = ubi_post_bind,
};
--
2.41.0
[RFC PATCH v2 0/4] mtd: ubi: Enable accessing RO filesystems in UBI vols
Hi list,
This is the second version of my RFC patchset to treat static UBI volumes as DM
block devices, allowing users to access read-only filesystems (SquashFS, EROFS)
contained within such volumes.
This is a rebased and updated version, as requested by Heiko.
Previously, we have agreed on a syntax, which my downstream is now starting to
use:
=> ls ubi 0:rootfs /boot
=> ls ubi 0:2 /boot
This is still not yet ready for mainline inclusion, because the actual UBI DM
access is happening in disk/part.c, which is not "clean" with the way the
DM/legacy switching is currently plumbed. I'm still looking for guidance on how
to name/implement block functions for looking up a *subvolume* block device by
type+parentidx+{name,ID}.
Changes v1->v2:
- Rebased onto next post-2023.10's release.
- Fix NULL dereference caused by passing NULL to `blk_create_device`
- Parse UBI index/volume numbers with `dectoul` instead of `hextoul`, to match
Linux's behavior of treating these numbers as decimal.
- Do not treat a valid decimal number as a volume name, even if the volume ID
doesn't exist, to match Linux's behavior of always treating decimal numbers
as volume IDs.
Cheers,
Sam
Sam Edwards (4):
mtd: ubi: register UBI attachments as DM devices
mtd: ubi: bind block device driver for static volumes
disk: part: fall-through if "ubi" requested but ubifs not mounted
HACK: enable access to `ubi 0:volname` block devices
cmd/ubi.c| 11 +++
disk/part.c | 69 +++--
drivers/mtd/ubi/Makefile | 1 +
drivers/mtd/ubi/ubi-uclass.c | 185 +++
include/dm/uclass-id.h | 1 +
include/ubi_uboot.h | 5 +
6 files changed, 264 insertions(+), 8 deletions(-)
create mode 100644 drivers/mtd/ubi/ubi-uclass.c
--
2.41.0
Re: [PATCH] test: Fix SPL tests not being run
On 10/2/23 14:56, Simon Glass wrote:
> Hi Sean,
>
> On Mon, 2 Oct 2023 at 08:38, Sean Anderson wrote:
>>
>> On 10/1/23 15:36, Simon Glass wrote:
>> > Hi Sean,
>> >
>> > On Fri, 29 Sept 2023 at 10:12, Sean Anderson
>> > wrote:
>> >>
>> >> On 9/29/23 12:06, Sean Anderson wrote:
>> >> > SPL doesn't have OF_LIVE enabled, so we can only run tests with a flat
>> >> > tree. Don't skip them even if they don't use the devicetree.
>> >> >
>> >> > Fixes: 6ec5178c0ef ("test: Skip flat-tree tests if devicetree is not
>> >> > used")
>> >> > Signed-off-by: Sean Anderson
>> >> > ---
>> >> >
>> >> > test/test-main.c | 3 ++-
>> >> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/test/test-main.c b/test/test-main.c
>> >> > index 778bf0a18a0..edb20bc4b9c 100644
>> >> > --- a/test/test-main.c
>> >> > +++ b/test/test-main.c
>> >> > @@ -476,7 +476,8 @@ static int ut_run_test_live_flat(struct
>> >> > unit_test_state *uts,
>> >> >* (for sandbox we handle this by copying the tree, but not for
>> >> > other
>> >> >*boards)
>> >> >*/
>> >> > - if ((test->flags & UT_TESTF_SCAN_FDT) &&
>> >> > + if ((!CONFIG_IS_ENABLED(OF_LIVE) ||
>> >> > + (test->flags & UT_TESTF_SCAN_FDT)) &&
>> >> > !(test->flags & UT_TESTF_LIVE_TREE) &&
>> >> > (CONFIG_IS_ENABLED(OFNODE_MULTI_TREE) ||
>> >> >!(test->flags & UT_TESTF_OTHER_FDT)) &&
>> >>
>> >> Upon further review, do we even need 6ec5178c0ef in the first place?
>> >> ut_test_run_on_flattree looks like it's trying to do the same thing.
>> >
>> > Well one problem is that many tests are not run at all unless OF_LIVE
>> > is enabled. The code as is is assuming that OF_LIVE is active.
>> >
>> > On boards where OF_LIVE is not active, many tests won't run at all
>> > unless they are marked with UT_TESTF_SCAN_FDT.
>> >
>> > So I think that UT_TESTF_SCAN_FDT line needs to be removed.
>>
>> OK, so to clarify, since 6ec5178c0ef added that UT_TESTF_SCAN_FDT, you would
>> like to
>> revert that commit?
>
> Yes, I think that will work...but just check that tests without the
> UT_TESTF_SCAN_FDT flag don't then run twice with sandbox. There was
> perhaps something else wrong at the time.
Actually, upon further review, I think that the above patch is correct. A
revert would
cause tests with UT_TESTF_DM but without UT_TESTF_SCAN_FDT to run twice.
--Sean
Re: [PATCH 16/16] board: rzg2l: Add RZ/G2L SMARC EVK board
On 03/10/2023 14:36, Marek Vasut wrote:
> On 9/20/23 14:42, Paul Barker wrote:
>> The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
>> System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
>> carrier board.
>>
>> The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
>> devicetree blob to the bootloader as an argument in the same was
>> previous R-Car gen3/gen4 SoCs. This blob contains a compatible string
>> which can be used to identify the particular SoC we are running on and
>> this is used to select the appropriate device tree to load.
>>
>> The configuration renesas_rzg2l_smarc_defconfig is added to support
>> building for this target. In the future this defconfig will be extended
>> to support other SoCs and evaluation boards from the RZ/G2L family.
>>
>> Signed-off-by: Paul Barker
>> Reviewed-by: Biju Das
>> Reviewed-by: Lad Prabhakar
>> ---
>> arch/arm/mach-rmobile/Kconfig.rzg2l | 14 +
>> board/renesas/rzg2l/Kconfig | 18 +++
>> board/renesas/rzg2l/MAINTAINERS | 6 +++
>> board/renesas/rzg2l/Makefile | 4 ++
>> board/renesas/rzg2l/rzg2l.c | 76 +++
>> configs/renesas_rzg2l_smarc_defconfig | 52 ++
>> include/configs/rzg2l-smarc.h | 14 +
>> 7 files changed, 184 insertions(+)
>> create mode 100644 board/renesas/rzg2l/Kconfig
>> create mode 100644 board/renesas/rzg2l/MAINTAINERS
>> create mode 100644 board/renesas/rzg2l/Makefile
>> create mode 100644 board/renesas/rzg2l/rzg2l.c
>> create mode 100644 configs/renesas_rzg2l_smarc_defconfig
>> create mode 100644 include/configs/rzg2l-smarc.h
>>
>> diff --git a/arch/arm/mach-rmobile/Kconfig.rzg2l
>> b/arch/arm/mach-rmobile/Kconfig.rzg2l
>> index 7d268e8c366a..1fe49e323300 100644
>> --- a/arch/arm/mach-rmobile/Kconfig.rzg2l
>> +++ b/arch/arm/mach-rmobile/Kconfig.rzg2l
>> @@ -9,6 +9,20 @@ config R9A07G044L
>> help
>>Enable support for the R9A07G044L SoC used in the RZ/G2L.
>>
>> +choice
>> +prompt "Renesas RZ/G2L Family Board selection"
>> +default TARGET_RZG2L_SMARC_EVK
>> +
>> +config TARGET_RZG2L_SMARC_EVK
>> +bool "Renesas RZ/G2L SMARC EVK"
>> +imply R9A07G044L
>> +help
>> + Enable support for the RZ/G2L SMARC evaluation board.
>> +
>> +source "board/renesas/rzg2l/Kconfig"
>> +
>> +endchoice
>> +
>> config MULTI_DTB_FIT_UNCOMPRESS_SZ
>> default 0x8 if TARGET_RZG2L_SMARC_EVK
>>
>> diff --git a/board/renesas/rzg2l/Kconfig b/board/renesas/rzg2l/Kconfig
>> new file mode 100644
>> index ..1335fc7ae806
>> --- /dev/null
>> +++ b/board/renesas/rzg2l/Kconfig
>> @@ -0,0 +1,18 @@
>> +# Copyright (C) 2023 Renesas Electronics Corporation
>> +# SPDX-License-Identifier: GPL-2.0+
>> +
>> +if TARGET_RZG2L_SMARC_EVK
>> +
>> +config SYS_SOC
>> +default "rmobile"
>> +
>> +config SYS_BOARD
>> +default "rzg2l"
>> +
>> +config SYS_VENDOR
>> +default "renesas"
>> +
>> +config SYS_CONFIG_NAME
>> +default "rzg2l-smarc"
>> +
>> +endif
>> diff --git a/board/renesas/rzg2l/MAINTAINERS
>> b/board/renesas/rzg2l/MAINTAINERS
>> new file mode 100644
>> index ..0a51391c1fc9
>> --- /dev/null
>> +++ b/board/renesas/rzg2l/MAINTAINERS
>> @@ -0,0 +1,6 @@
>> +RENESAS RZG2L BOARD FAMILY
>> +M: Paul Barker
>> +S: Supported
>> +F: arch/arm/dts/rz-smarc-common.dtsi
>
> I suspect there should be more files here, right ?
> You likely want to be CCed on things like rzg2l clock, scif, and so on.
>
>> +N: rzg2l
>> +N: r9a07g044
>> diff --git a/board/renesas/rzg2l/Makefile b/board/renesas/rzg2l/Makefile
>> new file mode 100644
>> index ..466935fc8158
>> --- /dev/null
>> +++ b/board/renesas/rzg2l/Makefile
>> @@ -0,0 +1,4 @@
>> +# Copyright (C) 2023 Renesas Electronics Corporation
>> +# SPDX-License-Identifier: GPL-2.0+
>> +
>> +obj-y := rzg2l.o
>
>> diff --git a/board/renesas/rzg2l/rzg2l.c b/board/renesas/rzg2l/rzg2l.c
>> new file mode 100644
>> index ..2b1bb3546c26
>> --- /dev/null
>> +++ b/board/renesas/rzg2l/rzg2l.c
>> @@ -0,0 +1,76 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * RZ/G2L board support.
>> + * Copyright (C) 2023 Renesas Electronics Corporation
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#if IS_ENABLED(CONFIG_MULTI_DTB_FIT)
>> +/* If the firmware passed a device tree, use it for board identification. */
>> +extern u64 rcar_atf_boot_args[];
>> +
>> +static bool is_rzg2l_board(const char *board_name)
>> +{
>> +void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
>> +
>> +return fdt_node_check_compatible(atf_fdt_blob, 0, board_name) == 0;
>> +}
>> +
>> +int board_fit_config_name_match(const char *name)
>> +{
>> +void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
>> +
>> +if (fdt_magic(atf_fdt_blob) != FDT_MAGIC)
>> +return -1;
>> +
>> +if (is_rzg2l_board("renesas,r9a07g044l2"))
>> +return strcmp(name,
error on h616 ID axp806 legacy kernel
In the legacy kernel, when starting, the error appears: the chip id is 0x5d00 ic cant match axp, please check... well, in the axp.h code the id is defined as 0x40, I tried changing it to 0x5d00, but it does not accept the u-boot compilation error, does anyone know how to change it, it seems to be an error in the number of registers available in the .h
Re: [PATCH] arm: dts: k3-j721e-sk/common-proc-board: Fix boot
On Thu, Oct 05, 2023 at 01:15:14PM -0500, Nishanth Menon wrote:
> Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node
> as pre-reloc after relocation") A53 u-boot proper is broken. This is
> because nodes marked as 'bootph-pre-ram' are not available at u-boot
> proper before relocation.
>
> To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.
>
> Fixes: 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1")
> Cc: Neha Francis
> Signed-off-by: Nishanth Menon
Tested-by: Tom Rini # J721E-EVM GP
--
Tom
signature.asc
Description: PGP signature
H616 DRAM support on mailine kernel
dears, How can I edit the drm parameters directly in the mainline kernel, since the mainline dts does not have these options like the legacy one, I saw that the dram.c drives in the legacy and mailline are similar, for example: [dram_para] dram_clk = 600 dram_type = 3 dram_dx_odt = 0x03030303 dram_dx_dri = 0x0e0e0e0e dram_ca_dri = 0x1f12 dram_odt_en = 1 dram_para1 = 0x30fb dram_para2 = 0x dram_mr0 = 0x840 in the mainline kernel
Re: [PATCH 10/16] serial: sh: Add RZ/G2L SCIF support
On 10/5/23 18:18, Paul Barker wrote:
On 04/10/2023 13:26, Marek Vasut wrote:
On 10/4/23 10:48, Paul Barker wrote:
On 03/10/2023 14:23, Marek Vasut wrote:
On 9/20/23 14:42, Paul Barker wrote:
+ if (IS_ENABLED(CONFIG_RZG2L)) {
+ struct reset_ctl rst;
+ int ret;
+
+ ret = reset_get_by_index(dev, 0, );
+ if (ret < 0) {
+ dev_err(dev, "failed to get reset line\n");
+ return ret;
+ }
+
+ ret = reset_deassert();
+ if (ret < 0) {
+ dev_err(dev, "failed to de-assert reset line\n");
+ return ret;
+ }
+ }
devm_reset_control_get_optional() or something should do here too , right ?
Note that R-Car does have SCIF reset too, so this can be generic code.
For R-Car systems the current behaviour is working and well tested, we
concluded that we shouldn't change it so this reset de-assert was made
RZ/G2L specific.
I can test on R-Car just fine, no worries.
SH R2Dplus is even tested in CI nightly.
For RZ/G2L, de-asserting the reset is not optional.
Let's avoid special-cases like that.
Looking at this again, I don't see how we can avoid a special case here,
de-asserting the reset is required for the RZ/G2L. It may be optional on
other SoCs (I don't know), but it's definitely not optional here, so I
don't think we should be using the devm_reset_control_get_optional()
function.
I'd say let's just unconditionally assume reset is needed for all
platforms. That should work, right ?
Re: [PATCH 11/16] mmc: renesas-sdhi: Initialize module on RZ/G2L
On 10/5/23 18:35, Paul Barker wrote:
On 03/10/2023 14:25, Marek Vasut wrote:
On 9/20/23 14:42, Paul Barker wrote:
On the Renesas RZ/G2L SoC family, we must ensure that the required clock
signals are enabled and the reset signal is de-asserted before we try to
communicate with the SDHI module.
Signed-off-by: Paul Barker
Reviewed-by: Biju Das
Reviewed-by: Lad Prabhakar
---
drivers/mmc/renesas-sdhi.c | 61 ++
1 file changed, 61 insertions(+)
diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 8e716f74491f..170c5dcc2ebe 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include "tmio-common.h"
@@ -964,6 +965,8 @@ static int renesas_sdhi_probe(struct udevice *dev)
u32 quirks = dev_get_driver_data(dev);
struct fdt_resource reg_res;
DECLARE_GLOBAL_DATA_PTR;
+ struct clk imclk2, aclk;
+ struct reset_ctl rst;
int ret;
priv->clk_get_rate = renesas_sdhi_clk_get_rate;
@@ -1012,6 +1015,49 @@ static int renesas_sdhi_probe(struct udevice *dev)
goto err_clkh;
}
+ if (IS_ENABLED(CONFIG_RZG2L)) {
+ /*
+* On members of the RZ/G2L SoC family, we need to enable
+* additional chip detect and bus clocks, then release the SDHI
+* module from reset.
+*/
This could use a separate function, and then, use bulk clock API via
clk_get_bulk() and co .
There are 4 clocks defined in the dtb: "core", "clkh", "cd", "aclk".
During probe, we want to enable "core", "cd" (aka "imclk2" in the
datasheet) and "aclk" but not "clkh". The driver enables "clkh" later as
needed for high speed modes. So I don't think we want to bulk enable
everything here.
Aha, OK
By "separate function", are you suggesting an entire separate probe
function for RZ/G2L SDHI? Or just moving what's inside the
if(IS_ENABLED(CONFIG_RZG2L)) into a new function which we can call from
renesas_sdhi_probe()?
The later, to avoid this huge ifdef within the probe
if (IS_ENABLED(CONFIG_RZG2L))
rzg2l_do_whatever_extra_stuff_is_needed();
Thanks !
Re: [PATCH v5 2/2] arm: dts: j7200: dts sync with Linux 6.6-rc1
On 13:12-20231005, Reid Tonking wrote: > Sync j7200 dts with Linux 6.6-rc1 > > - k3-j7200-r5-common-proc-board.dts now inherits from > k3-j7200-common-proc-board.dts instead of k3-j7200-som-p0.dtsi. This > allows us to trim down the r5 file considerably by using existing > properties > > - remove pimux nodes from r5 file > > - remove duplicate nodes & node properties from r5/u-boot files > > - mcu_timer0 now used instead of timer1 > > mcu_timer0 device id added to dev-data.c file in order to work > > - remove cpsw node > > This node is no longer required since the compatible is now fixed > > - remove dummy_clock_19_2_mhz > > This node wasn't being used anyhere, so it was removed > > - remove dummy_clock_200mhz > > main_sdhci0 & main_sdhci1 no longer need dummy clock for eMMC/SD > > - fix secure proxy node > > mcu_secproxy changed to used secure_prxy_mcu which is already > defined in k3-j7200-mcu-wakeup.dtsi > > - removed _ringacc property override since they're present in > v6.6-rc1 > > Signed-off-by: Reid Tonking Reviewed-by: Nishanth Menon [...] -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH] arm: dts: k3-j721e-sk/common-proc-board: Fix boot
Since commit 9e644284ab81 ("dm: core: Report bootph-pre-ram/sram node
as pre-reloc after relocation") A53 u-boot proper is broken. This is
because nodes marked as 'bootph-pre-ram' are not available at u-boot
proper before relocation.
To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.
Fixes: 69b19ca67bcb ("arm: dts: k3-j721e: Sync with v6.6-rc1")
Cc: Neha Francis
Signed-off-by: Nishanth Menon
---
The original patch was reviewed prior to commit 9e644284ab81
However the recent break in u-boot requires fixup to maintain sanity.
Neha: I have only build tested this and have assumed this follows the
same pattern of fails with other platforms - please test and review for
functionality.
.../k3-j721e-common-proc-board-u-boot.dtsi| 82 +--
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 70
2 files changed, 76 insertions(+), 76 deletions(-)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index c638af63c180..cd95907b981b 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -6,27 +6,27 @@
#include "k3-j721e-binman.dtsi"
_main {
- bootph-pre-ram;
+ bootph-all;
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_mcu_wakeup {
- bootph-pre-ram;
+ bootph-all;
chipid@4314 {
- bootph-pre-ram;
+ bootph-all;
};
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_ringacc {
- bootph-pre-ram;
+ bootph-all;
};
_udmap {
@@ -38,144 +38,144 @@
<0x0 0x2840 0x0 0x2000>;
reg-names = "gcfg", "rchan", "rchanrt", "tchan",
"tchanrt", "rflow";
- bootph-pre-ram;
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
_sdhci0 {
- bootph-pre-ram;
+ bootph-all;
};
_sdhci1 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_usbss0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
dr_mode = "peripheral";
- bootph-pre-ram;
+ bootph-all;
};
_mmc1_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
status = "okay";
};
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
status = "okay";
};
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_esm {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_fss0_ospi0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_gpio0 {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
flash@0 {
- bootph-pre-ram;
+ bootph-all;
};
};
{
- bootph-pre-ram;
+ bootph-all;
flash@0 {
- bootph-pre-ram;
+ bootph-all;
};
};
_fss0_hpb0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_gpio_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_fss0_ospi1_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
index 57da7c210a8d..370fe5190b2d 100644
--- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
@@ -6,27 +6,27 @@
#include "k3-j721e-binman.dtsi"
_main {
- bootph-pre-ram;
+ bootph-all;
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_mcu_wakeup {
- bootph-pre-ram;
+ bootph-all;
chipid@4314 {
- bootph-pre-ram;
+ bootph-all;
};
};
_navss {
- bootph-pre-ram;
+ bootph-all;
};
_ringacc {
- bootph-pre-ram;
+ bootph-all;
};
_udmap {
@@ -38,120 +38,120 @@
<0x0 0x2840 0x0 0x2000>;
[PATCH v5 2/2] arm: dts: j7200: dts sync with Linux 6.6-rc1
Sync j7200 dts with Linux 6.6-rc1
- k3-j7200-r5-common-proc-board.dts now inherits from
k3-j7200-common-proc-board.dts instead of k3-j7200-som-p0.dtsi. This
allows us to trim down the r5 file considerably by using existing
properties
- remove pimux nodes from r5 file
- remove duplicate nodes & node properties from r5/u-boot files
- mcu_timer0 now used instead of timer1
mcu_timer0 device id added to dev-data.c file in order to work
- remove cpsw node
This node is no longer required since the compatible is now fixed
- remove dummy_clock_19_2_mhz
This node wasn't being used anyhere, so it was removed
- remove dummy_clock_200mhz
main_sdhci0 & main_sdhci1 no longer need dummy clock for eMMC/SD
- fix secure proxy node
mcu_secproxy changed to used secure_prxy_mcu which is already
defined in k3-j7200-mcu-wakeup.dtsi
- removed _ringacc property override since they're present in
v6.6-rc1
Signed-off-by: Reid Tonking
---
.../k3-j7200-common-proc-board-u-boot.dtsi| 208 +++
arch/arm/dts/k3-j7200-common-proc-board.dts | 186 +++---
arch/arm/dts/k3-j7200-main.dtsi | 535 +-
arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 286 +-
.../arm/dts/k3-j7200-r5-common-proc-board.dts | 301 +-
arch/arm/dts/k3-j7200-som-p0.dtsi | 154 +++--
arch/arm/dts/k3-j7200-thermal.dtsi| 47 ++
arch/arm/dts/k3-j7200.dtsi| 30 +-
8 files changed, 1206 insertions(+), 541 deletions(-)
create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index f25c7136c9..60ca6d21ab 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -1,200 +1,210 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2023 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-j7200-binman.dtsi"
/ {
chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
- aliases {
- ethernet0 = _port1;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
+ tick-timer = _timer0;
};
};
_main {
- bootph-pre-ram;
+ bootph-all;
};
_navss {
- bootph-pre-ram;
+ bootph-all;
+};
+
+_esm {
+ bootph-all;
};
_mcu_wakeup {
- bootph-pre-ram;
-
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
- bootph-pre-ram;
- };
+ bootph-all;
chipid@4314 {
- bootph-pre-ram;
+ bootph-all;
};
+};
- mcu_navss: bus@2838 {
- bootph-pre-ram;
- #address-cells = <2>;
- #size-cells = <2>;
-
- ringacc@2b80 {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg",
"proxy_target", "cfg";
- bootph-pre-ram;
- };
-
- dma-controller@285c {
- reg = <0x0 0x285c 0x0 0x100>,
- <0x0 0x284c 0x0 0x4000>,
- <0x0 0x2a80 0x0 0x4>,
- <0x0 0x284a 0x0 0x4000>,
- <0x0 0x2aa0 0x0 0x4>,
- <0x0 0x2840 0x0 0x2000>;
- reg-names = "gcfg", "rchan", "rchanrt", "tchan",
- "tchanrt", "rflow";
- bootph-pre-ram;
- };
- };
+_navss {
+ bootph-all;
+};
+
+_ringacc {
+ bootph-all;
+};
+
+_udmap {
+ reg = <0x0 0x285c 0x0 0x100>,
+ <0x0 0x284c 0x0 0x4000>,
+ <0x0 0x2a80 0x0 0x4>,
+ <0x0 0x284a 0x0 0x4000>,
+ <0x0 0x2aa0 0x0 0x4>,
+ <0x0 0x2840 0x0 0x2000>;
+ reg-names = "gcfg", "rchan", "rchanrt", "tchan",
+ "tchanrt", "rflow";
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+
[PATCH v5 0/2] J7200 device tree sync from v6.6-rc1 to u-boot
This series tries to sync device tree files from Linux v6.6-rc1 while making changes to the u-boot.dtsi and r5-common-proc-board.dts files in order to remove duplicate nodes and achieve successful boot. DMA fixes [0] are currently being upstreamed to Linux. They'll be fixed in U-boot post their merge in Linux. Previous versions (v1-v3) of patch no longer boot in next branch due to a recent change with how bootph-pre-ram now works [1]. Changes have been in this version to avoid future issues with that. Boot log is included in [2] [0]: https://lore.kernel.org/all/20230810174356.3322583-1-vigne...@ti.com/ [1]: https://lore.kernel.org/u-boot/capnjgz3mgwx8t0a0sofpher_xd77pe3hte9dnye1rubveb9...@mail.gmail.com/ [2]: https://gist.github.com/reidt1/809bafbab561bb148513e2b55ba11a56 --- Changes in v5: - Replaced bootph-all's in r5.dts with bootph-pre-ram - Link to v4: https://lore.kernel.org/u-boot/20231004165629.506664-1-re...@ti.com/ Reid Tonking (2): arm: mach-k3: j7200: Add mcu_timer0 id to the dev list arm: dts: j7200: dts sync with Linux 6.6-rc1 .../k3-j7200-common-proc-board-u-boot.dtsi| 208 +++ arch/arm/dts/k3-j7200-common-proc-board.dts | 186 +++--- arch/arm/dts/k3-j7200-main.dtsi | 535 +- arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 286 +- .../arm/dts/k3-j7200-r5-common-proc-board.dts | 301 +- arch/arm/dts/k3-j7200-som-p0.dtsi | 154 +++-- arch/arm/dts/k3-j7200-thermal.dtsi| 47 ++ arch/arm/dts/k3-j7200.dtsi| 30 +- arch/arm/mach-k3/j7200/dev-data.c | 1 + 9 files changed, 1207 insertions(+), 541 deletions(-) create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi -- 2.34.1
[PATCH v5 1/2] arm: mach-k3: j7200: Add mcu_timer0 id to the dev list
mcu_timer0 is now used as the tick timer in u-boot, so this adds the
timer to the soc device list so it can be enabled via the k3 power
controller.
Reviewed-by: Nishanth Menon
Signed-off-by: Reid Tonking
---
arch/arm/mach-k3/j7200/dev-data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-k3/j7200/dev-data.c
b/arch/arm/mach-k3/j7200/dev-data.c
index 4ddc34210e..8ce6796fd0 100644
--- a/arch/arm/mach-k3/j7200/dev-data.c
+++ b/arch/arm/mach-k3/j7200/dev-data.c
@@ -46,6 +46,7 @@ static struct ti_lpsc soc_lpsc_list[] = {
static struct ti_dev soc_dev_list[] = {
PSC_DEV(30, _lpsc_list[0]),
+ PSC_DEV(35, _lpsc_list[0]),
PSC_DEV(61, _lpsc_list[1]),
PSC_DEV(90, _lpsc_list[2]),
PSC_DEV(8, _lpsc_list[3]),
--
2.34.1
Re: [PATCH v4 2/2] arm: dts: j7200: dts sync with Linux 6.6-rc1
On 12:04-20231005, Nishanth Menon wrote:
> On 09:04-20231005, reidt wrote:
> [...]
> > > > - clk_200mhz: dummy_clock_200mhz {
> > > > - compatible = "fixed-clock";
> > > > - #clock-cells = <0>;
> > > > - clock-frequency = <2>;
> > > > - bootph-pre-ram;
> > > > + bootph-all;
> > >
> > > Here and else where in the r5 file: why switch from pre-ram to bootph-all
> > > ? dont we need these prior to ddr initialization?
> > >
> >
> > Due to the change in how booth-pre-ram works [0], bootph-pre-ram alone no
> > longer works. U-boot docs Pre-Relocation Support section says some-ram
> > can be used for u-boot prior to reloc, but not spl. So like Massimo
> > mentioned in the linked discussion, some-ram + pre-ram can work, as well
> > as -all. Outside of affecting the TPL phase, I'm not sure I know of a
> > difference in regards to how it affects pre-ddr.
> >
> >
> > [0]:
> > https://lore.kernel.org/u-boot/capnjgz3mgwx8t0a0sofpher_xd77pe3hte9dnye1rubveb9...@mail.gmail.com/
> >
>
> Also see:
> https://github.com/u-boot/u-boot/commit/0cb6515cdab483ce8b30680803cbed0a63044cdc
> https://github.com/u-boot/u-boot/commit/7e5b6f1cff846218b824a4d906e2831c15864a53
> https://lore.kernel.org/all/3376a0eb-57f4-416a-b4b8-86cee769d...@siemens.com/
> etc..
>
> as a rule of thumb: u-boot.dtsi uses bootph-all; r5-xyz.dts uses booth-pre-ram
>
> Where this failed completely is when A53 started using booth-pre-ram in
> which case the u-boot stages failed on A53 side.
>
> The rule of thumb I explained works across silicon (bar other issues).
Ah, good to know! Appreciate the info, I'll have v5 up soon with that
change.
Thanks,
Reid
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
Re: [PULL] u-boot-riscv/master
On Thu, Oct 05, 2023 at 04:10:55PM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit 65b9b3462bec2966911658836983819ab4e4823e: > > Merge branch 'next_pinctrl_sync' of > https://source.denx.de/u-boot/custodians/u-boot-sh (2023-10-02 15:19:02 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to 7cfdacbe8020292845bd5eba63b576b8586c433c: > > configs: sifive: enable poweroff command on Unmatched (2023-10-04 18:23:59 > +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/18005 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
On 12:22-20231005, Andrew Davis wrote: > On 10/5/23 12:16 PM, Nishanth Menon wrote: > > On 12:10-20231005, Nishanth Menon wrote: > > > On 12:36-20231005, Tom Rini wrote: > > > > On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote: > > > > > On 10/4/23 8:54 AM, Nishanth Menon wrote: > > > > > > On 08:48-20231004, Andrew Davis wrote: > > > > > > > On 10/4/23 8:23 AM, Roger Quadros wrote: > > > > > > > > ti_mmc is not a valid boot_target for standard boot flow so > > > > > > > > > > > > > > Is there some way to make it into a valid boot_target? Otherwise > > > > > > > how do we use uEnv.txt files, or boot from FIT images with > > > > > > > overlays? > > > > > > > > > > > > envboot takes care of uEnv.txt file (see > > > > > > https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/) > > > > > > > > > > > > Early remote proc loading and FIT image is a question for stdboot > > > > > > itself. > > > > > > > > > > > > > > > > If stdboot is missing these features then we shouldn't switch until it > > > > > has them. I'm all for switching to this, but only if it is complete. > > > > > > > > Depends on what you mean? Did you mean an option to run scripts > > > > (exists) or an option to do what TI needs done, via > > > > boot/bootmeth_something.c ? If the latter, someone from TI needs to > > > > figure out what that should be and do (but plumbing-wise everything it > > > > needs should exist). > > > > > > Andrew is generalizing here (on the wrong patch though). > > > > > > On am62x platforms, there is nothing regressing with this series. The > > > challenge is early remote_proc loading which is done for J7* platforms. > > > > > > How that is initiated as part of bootmethods is something of a gap. > > > > > > The other gap has been support for uEnv.txt -> which we can workaround > > > at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan > > > -lb" in defconfig (This series from Roger already does that - hence I am > > > saying that Andrew is complaining on the wrong series). > > > > > > Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and > > > uEnv.txt remoteproc loads and the various standard bootmethods should > > > "just work". > > > > > > I forgot to add: FIT image authenticated boot flow. That is really what > > ti_mmc distroboot method was trying to solve. > > > > Right, FIT (and remote proc loading) are handled in ti_mmc, and this > is the patch removing that (so I do believe I am complaining on the right > patch here). I know that needs removed before we switch to stdboot, but > we cant remove it until someone has the the alternative in place. > > Simply dropping it and hoping someone else comes along later and re-adds > the features isn't a good idea. Even if, as said above, the plumbing we > need should already exist, it needs done first. As simon stated: https://lore.kernel.org/all/capnjgz1fnqgk5w_8-jkjl1kexgm4cfnk-jpnftqcfcv+y89...@mail.gmail.com/ FIT is already supported. remoteproc support was not yet added for am62.. so there is no real regression, that said, even then, it can still be handled by envboot till we solve that aspect. There is no real reason to hold back stdboot as the standardization is very valuable at this point. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
Hi Nishanth, On Thu, 5 Oct 2023 at 11:16, Nishanth Menon wrote: > > On 12:10-20231005, Nishanth Menon wrote: > > On 12:36-20231005, Tom Rini wrote: > > > On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote: > > > > On 10/4/23 8:54 AM, Nishanth Menon wrote: > > > > > On 08:48-20231004, Andrew Davis wrote: > > > > > > On 10/4/23 8:23 AM, Roger Quadros wrote: > > > > > > > ti_mmc is not a valid boot_target for standard boot flow so > > > > > > > > > > > > Is there some way to make it into a valid boot_target? Otherwise > > > > > > how do we use uEnv.txt files, or boot from FIT images with overlays? > > > > > > > > > > envboot takes care of uEnv.txt file (see > > > > > https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/) > > > > > > > > > > Early remote proc loading and FIT image is a question for stdboot > > > > > itself. > > > > > > > > > > > > > If stdboot is missing these features then we shouldn't switch until it > > > > has them. I'm all for switching to this, but only if it is complete. > > > > > > Depends on what you mean? Did you mean an option to run scripts > > > (exists) or an option to do what TI needs done, via > > > boot/bootmeth_something.c ? If the latter, someone from TI needs to > > > figure out what that should be and do (but plumbing-wise everything it > > > needs should exist). > > > > Andrew is generalizing here (on the wrong patch though). > > > > On am62x platforms, there is nothing regressing with this series. The > > challenge is early remote_proc loading which is done for J7* platforms. > > > > How that is initiated as part of bootmethods is something of a gap. > > > > The other gap has been support for uEnv.txt -> which we can workaround > > at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan > > -lb" in defconfig (This series from Roger already does that - hence I am > > saying that Andrew is complaining on the wrong series). > > > > Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and > > uEnv.txt remoteproc loads and the various standard bootmethods should > > "just work". > > > I forgot to add: FIT image authenticated boot flow. That is really what > ti_mmc distroboot method was trying to solve. > > Maybe Simon or someone know how the stdboot flow handles authenticated > kernel image and dtb boot flow with FIT image? Yes you can use FIT configuration verification and things should work as normal. Regards, Simon
Re: [PATCH v2 2/2] board: ti: am64x: Switch to standard boot flow
Hi Tom,
On Thu, 5 Oct 2023 at 10:31, Tom Rini wrote:
>
> On Thu, Oct 05, 2023 at 09:01:42AM -0600, Simon Glass wrote:
> > Hi Roger,
> >
> > On Thu, 5 Oct 2023 at 07:07, Roger Quadros wrote:
> > >
> > > Switch to using bootstd. Note with this change, we will stop using
> > > distro_bootcmd and instead depend entirely on bootflow method of
> > > starting the system up.
> > >
> > > Drop header files that are no longer needed in am64x_evm.h.
> > > k3_dfu.h is available via k3_dfu.env in am64x.env.
> > >
> > > Drop unused macro CFG_SYS_SDRAM_BASE1.
> > >
> > > Signed-off-by: Roger Quadros
> > > ---
> > > board/ti/am64x/am64x.env| 1 +
> > > configs/am64x_evm_a53_defconfig | 5 +++--
> > > include/configs/am64x_evm.h | 9 -
> > > 3 files changed, 4 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
> > > index 68e4b7..efd736b99b 100644
> > > --- a/board/ti/am64x/am64x.env
> > > +++ b/board/ti/am64x/am64x.env
> > > @@ -15,6 +15,7 @@ console=ttyS2,115200n8
> > > args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
> > > run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
> > >
> > > +boot_targets=mmc1 mmc0 usb pxe dhcp
> > > boot=mmc
> > > mmcdev=1
> > > bootpart=1:2
> > > diff --git a/configs/am64x_evm_a53_defconfig
> > > b/configs/am64x_evm_a53_defconfig
> > > index 718ad176cb..43bfcf957a 100644
> > > --- a/configs/am64x_evm_a53_defconfig
> > > +++ b/configs/am64x_evm_a53_defconfig
> > > @@ -31,8 +31,9 @@ CONFIG_SPL_SPI=y
> > > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > CONFIG_SPL_LOAD_FIT=y
> > > CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> > > -CONFIG_DISTRO_DEFAULTS=y
> > > -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
> > > +CONFIG_BOOTSTD_FULL=y
> > > +CONFIG_BOOTSTD_DEFAULTS=y
> > > +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
> > > CONFIG_BOARD_LATE_INIT=y
> > > CONFIG_SPL_MAX_SIZE=0x18
> > > CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> > > diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
> > > index 062102a610..f9f8c7bc2f 100644
> > > --- a/include/configs/am64x_evm.h
> > > +++ b/include/configs/am64x_evm.h
> > > @@ -9,15 +9,6 @@
> > > #ifndef __CONFIG_AM642_EVM_H
> > > #define __CONFIG_AM642_EVM_H
> > >
> > > -#include
> > > -#include
> > > -#include
> > > -#include
> > > -#include
> > > -
> > > -/* DDR Configuration */
> > > -#define CFG_SYS_SDRAM_BASE10x88000
> > > -
> > > /* Now for the remaining common defines */
> > > #include
> >
> > It looks like this file still includes distro_bootcmd and defines all
> > the BOOT_TARGET things. Can they be dropped? Perhaps for now they
> > could be put behind an #ifdef if other boards need them?
> >
> > I suspect that with your patch as is, the environment is still full of
> > scripts?
>
> There's a lot of TI platforms, so I'm not sure what "#if" you're
> thinking of might make it cleaner? We could / should move some of the
> still relevant content and comments from that file to
> include/env/ti/ti_armv7_common.env as I do think some of the K3
> platforms could just drop at this point.
OK so if they are using text env then the header-file stuff doesn't
matter since I believe it is ignored? I was thinking of something
like:
#ifdef CONFIG_DISTRO_DEFAULTS
do all the distro #defines
#endif
Regards,
Simon
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
On 10/5/23 12:16 PM, Nishanth Menon wrote: On 12:10-20231005, Nishanth Menon wrote: On 12:36-20231005, Tom Rini wrote: On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote: On 10/4/23 8:54 AM, Nishanth Menon wrote: On 08:48-20231004, Andrew Davis wrote: On 10/4/23 8:23 AM, Roger Quadros wrote: ti_mmc is not a valid boot_target for standard boot flow so Is there some way to make it into a valid boot_target? Otherwise how do we use uEnv.txt files, or boot from FIT images with overlays? envboot takes care of uEnv.txt file (see https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/) Early remote proc loading and FIT image is a question for stdboot itself. If stdboot is missing these features then we shouldn't switch until it has them. I'm all for switching to this, but only if it is complete. Depends on what you mean? Did you mean an option to run scripts (exists) or an option to do what TI needs done, via boot/bootmeth_something.c ? If the latter, someone from TI needs to figure out what that should be and do (but plumbing-wise everything it needs should exist). Andrew is generalizing here (on the wrong patch though). On am62x platforms, there is nothing regressing with this series. The challenge is early remote_proc loading which is done for J7* platforms. How that is initiated as part of bootmethods is something of a gap. The other gap has been support for uEnv.txt -> which we can workaround at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" in defconfig (This series from Roger already does that - hence I am saying that Andrew is complaining on the wrong series). Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and uEnv.txt remoteproc loads and the various standard bootmethods should "just work". I forgot to add: FIT image authenticated boot flow. That is really what ti_mmc distroboot method was trying to solve. Right, FIT (and remote proc loading) are handled in ti_mmc, and this is the patch removing that (so I do believe I am complaining on the right patch here). I know that needs removed before we switch to stdboot, but we cant remove it until someone has the the alternative in place. Simply dropping it and hoping someone else comes along later and re-adds the features isn't a good idea. Even if, as said above, the plumbing we need should already exist, it needs done first. Andrew Maybe Simon or someone know how the stdboot flow handles authenticated kernel image and dtb boot flow with FIT image?
Re: [PATCH v2 2/2] board: ti: am64x: Switch to standard boot flow
On Thu, Oct 05, 2023 at 12:14:07PM -0500, Nishanth Menon wrote: > On 12:31-20231005, Tom Rini wrote: > [...] > > > > > /* Now for the remaining common defines */ > > > > #include > > > > > > It looks like this file still includes distro_bootcmd and defines all > > > the BOOT_TARGET things. Can they be dropped? Perhaps for now they > > > could be put behind an #ifdef if other boards need them? > > > > > > I suspect that with your patch as is, the environment is still full of > > > scripts? > > > > There's a lot of TI platforms, so I'm not sure what "#if" you're > > thinking of might make it cleaner? We could / should move some of the > > still relevant content and comments from that file to > > include/env/ti/ti_armv7_common.env as I do think some of the K3 > > platforms could just drop at this point. > > Is'nt the header distro_bootcmd.h and related stuff under #ifdef > CONFIG_DISTRO_DEFAULTS already? That's true too. The file (and probably all of the other *common.h ones) likely need some cleaning out of dead comments, etc, from the Kconfig migration. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
On 12:10-20231005, Nishanth Menon wrote: > On 12:36-20231005, Tom Rini wrote: > > On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote: > > > On 10/4/23 8:54 AM, Nishanth Menon wrote: > > > > On 08:48-20231004, Andrew Davis wrote: > > > > > On 10/4/23 8:23 AM, Roger Quadros wrote: > > > > > > ti_mmc is not a valid boot_target for standard boot flow so > > > > > > > > > > Is there some way to make it into a valid boot_target? Otherwise > > > > > how do we use uEnv.txt files, or boot from FIT images with overlays? > > > > > > > > envboot takes care of uEnv.txt file (see > > > > https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/) > > > > > > > > Early remote proc loading and FIT image is a question for stdboot > > > > itself. > > > > > > > > > > If stdboot is missing these features then we shouldn't switch until it > > > has them. I'm all for switching to this, but only if it is complete. > > > > Depends on what you mean? Did you mean an option to run scripts > > (exists) or an option to do what TI needs done, via > > boot/bootmeth_something.c ? If the latter, someone from TI needs to > > figure out what that should be and do (but plumbing-wise everything it > > needs should exist). > > Andrew is generalizing here (on the wrong patch though). > > On am62x platforms, there is nothing regressing with this series. The > challenge is early remote_proc loading which is done for J7* platforms. > > How that is initiated as part of bootmethods is something of a gap. > > The other gap has been support for uEnv.txt -> which we can workaround > at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan > -lb" in defconfig (This series from Roger already does that - hence I am > saying that Andrew is complaining on the wrong series). > > Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and > uEnv.txt remoteproc loads and the various standard bootmethods should > "just work". I forgot to add: FIT image authenticated boot flow. That is really what ti_mmc distroboot method was trying to solve. Maybe Simon or someone know how the stdboot flow handles authenticated kernel image and dtb boot flow with FIT image? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 2/2] board: ti: am64x: Switch to standard boot flow
On 12:31-20231005, Tom Rini wrote: [...] > > > /* Now for the remaining common defines */ > > > #include > > > > It looks like this file still includes distro_bootcmd and defines all > > the BOOT_TARGET things. Can they be dropped? Perhaps for now they > > could be put behind an #ifdef if other boards need them? > > > > I suspect that with your patch as is, the environment is still full of > > scripts? > > There's a lot of TI platforms, so I'm not sure what "#if" you're > thinking of might make it cleaner? We could / should move some of the > still relevant content and comments from that file to > include/env/ti/ti_armv7_common.env as I do think some of the K3 > platforms could just drop at this point. Is'nt the header distro_bootcmd.h and related stuff under #ifdef CONFIG_DISTRO_DEFAULTS already? So, all we are picking up in effect is really CFG_SYS_SDRAM_BASE - which is consistent across platforms. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
On 12:36-20231005, Tom Rini wrote: > On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote: > > On 10/4/23 8:54 AM, Nishanth Menon wrote: > > > On 08:48-20231004, Andrew Davis wrote: > > > > On 10/4/23 8:23 AM, Roger Quadros wrote: > > > > > ti_mmc is not a valid boot_target for standard boot flow so > > > > > > > > Is there some way to make it into a valid boot_target? Otherwise > > > > how do we use uEnv.txt files, or boot from FIT images with overlays? > > > > > > envboot takes care of uEnv.txt file (see > > > https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/) > > > > > > Early remote proc loading and FIT image is a question for stdboot itself. > > > > > > > If stdboot is missing these features then we shouldn't switch until it > > has them. I'm all for switching to this, but only if it is complete. > > Depends on what you mean? Did you mean an option to run scripts > (exists) or an option to do what TI needs done, via > boot/bootmeth_something.c ? If the latter, someone from TI needs to > figure out what that should be and do (but plumbing-wise everything it > needs should exist). Andrew is generalizing here (on the wrong patch though). On am62x platforms, there is nothing regressing with this series. The challenge is early remote_proc loading which is done for J7* platforms. How that is initiated as part of bootmethods is something of a gap. The other gap has been support for uEnv.txt -> which we can workaround at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" in defconfig (This series from Roger already does that - hence I am saying that Andrew is complaining on the wrong series). Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and uEnv.txt remoteproc loads and the various standard bootmethods should "just work". -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH] doc: Migrate Renesas board docs to rst
Some of the information in README.rmobile is obsolete, references defconfigs which no longer exist in u-boot or has broken links. The information which is still relevant is moved into the reStructuredText documentation under `doc/board/renesas`, and `doc/README.rmobile` is dropped. The list of boards in `doc/board/renesas` is converted into a table so it's easier to see which defconfig to use. The list is expanded based on reviewing the current u-boot code and the contents of the eLinux wiki [1] [2]. [1]: https://elinux.org/R-Car [2]: https://elinux.org/RZ-G Signed-off-by: Paul Barker --- doc/README.rmobile| 99 - doc/board/renesas/renesas.rst | 255 +- doc/board/renesas/rzn1.rst| 2 + 3 files changed, 226 insertions(+), 130 deletions(-) delete mode 100644 doc/README.rmobile diff --git a/doc/README.rmobile b/doc/README.rmobile deleted file mode 100644 index 524d839558bb.. --- a/doc/README.rmobile +++ /dev/null @@ -1,99 +0,0 @@ -Summary -=== - -This README is about U-Boot support for Renesas's ARM Cortex-A9 based RMOBILE[1] -and Cortex-A9/A53/A57 based R-Car[2] family of SoCs. Renesas's RMOBILE/R-Car SoC -family contains an ARM Cortex-A9/A53/A57. - -Currently the following boards are supported: - -| SoC | Board | defconfig -|===++=== -| R8A73A0 | KMC KZM-A9-GT [3] | kzm9g_config -| R8A7734 | Atmark-Techno Armadillo-800-EVA [4]| armadillo-800eva_config -|===++=== -| R8A7790 H2 | Renesas Electronics Lager | lager_defconfig -| | Renesas Electronics Stout | stout_defconfig -|---++--- -| R8A7791 M2-W | Renesas Electronics Koelsch| koelsch_defconfig -| | Renesas Electronics Porter | porter_defconfig -|---++--- -| R8A7792 V2H | Renesas Electronics Blanche| blanche_defconfig -|---++--- -| R8A7793 M2-N | Renesas Electronics Gose | gose_defconfig -|---++--- -| R8A7794 E2 | Renesas Electronics Alt| alt_defconfig -| | Renesas Electronics Silk | silk_defconfig -|===++=== -| R8A7795 H3 | Renesas Electronics Salvator-XS ES2.0+ | r8a7795_salvator-x_defconfig -| R8A7795 H3 | Renesas Electronics ULCB ES2.0+| r8a7795_ulcb -|---++--- -| R8A7796 M3-W | Renesas Electronics Salvator-X | r8a7796_salvator-x_defconfig -| R8A7796 M3-W | Renesas Electronics ULCB | r8a7796_ulcb -|---++--- -| R8A77965 M3-N | Renesas Electronics Salvator-XS| r8a77965_salvator-x_defconfig -| R8A77965 M3-N | Renesas Electronics ULCB | r8a77965_ulcb -|---++--- -| R8A77970 V3M | Renesas Electronics Eagle | r8a77970_eagle_defconfig -| R8A77970 V3M | Renesas Electronics V3MSK | r8a77970_v3msk_defconfig -|---++--- -| R8A77995 D3 | Renesas Electronics Draak | r8a77995_draak_defconfig -'===++=== - -Toolchain -= - -Either ARMv7 toolchain for 32bit Cortex-A9 systems or ARMv8 (aarch64) -toolchain for 64bit Cortex-A53/A57 systems. Currently we compile the -32bit systems with -march=armv5 to allow more compilers to work. (For -U-Boot code this has no performance impact.) - -Currently, ELDK[5], Linaro[6], CodeSourcery[7] and Emdebian[8] supports -ARMv7. Modern distributions also contain ARMv7 and ARMv8 crosstoolchains -in their package feeds. - -Build -= - -Locate defconfig in the table above. Then apply standard build procedure: - - make _defconfig - make - - Note: Armadillo-800-EVA's U-Boot supports booting from SDcard only. -Please see "B.2 Appendix B Boot Specifications" in hardware manual. - -Links -= - -[1] Renesas RMOBILE: - -http://am.renesas.com/products/soc/assp/mobile/r_mobile/index.jsp - -[2] Renesas R-Car: - -http://am.renesas.com/products/soc/assp/automotive/index.jsp - -[3] KZM-A9-GT - -http://www.kmckk.co.jp/kzma9-gt/index.html - -[4] Armadillo-800-EVA - -http://armadillo.atmark-techno.com/armadillo-800-EVA - -[5] ELDK - -http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.6. - -[6] Linaro -
Re: [PATCH v4 2/2] arm: dts: j7200: dts sync with Linux 6.6-rc1
On 09:04-20231005, reidt wrote:
[...]
> > > - clk_200mhz: dummy_clock_200mhz {
> > > - compatible = "fixed-clock";
> > > - #clock-cells = <0>;
> > > - clock-frequency = <2>;
> > > - bootph-pre-ram;
> > > + bootph-all;
> >
> > Here and else where in the r5 file: why switch from pre-ram to bootph-all
> > ? dont we need these prior to ddr initialization?
> >
>
> Due to the change in how booth-pre-ram works [0], bootph-pre-ram alone no
> longer works. U-boot docs Pre-Relocation Support section says some-ram
> can be used for u-boot prior to reloc, but not spl. So like Massimo
> mentioned in the linked discussion, some-ram + pre-ram can work, as well
> as -all. Outside of affecting the TPL phase, I'm not sure I know of a
> difference in regards to how it affects pre-ddr.
>
>
> [0]:
> https://lore.kernel.org/u-boot/capnjgz3mgwx8t0a0sofpher_xd77pe3hte9dnye1rubveb9...@mail.gmail.com/
>
Also see:
https://github.com/u-boot/u-boot/commit/0cb6515cdab483ce8b30680803cbed0a63044cdc
https://github.com/u-boot/u-boot/commit/7e5b6f1cff846218b824a4d906e2831c15864a53
https://lore.kernel.org/all/3376a0eb-57f4-416a-b4b8-86cee769d...@siemens.com/
etc..
as a rule of thumb: u-boot.dtsi uses bootph-all; r5-xyz.dts uses booth-pre-ram
Where this failed completely is when A53 started using booth-pre-ram in
which case the u-boot stages failed on A53 side.
The rule of thumb I explained works across silicon (bar other issues).
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote: > On 10/4/23 8:54 AM, Nishanth Menon wrote: > > On 08:48-20231004, Andrew Davis wrote: > > > On 10/4/23 8:23 AM, Roger Quadros wrote: > > > > ti_mmc is not a valid boot_target for standard boot flow so > > > > > > Is there some way to make it into a valid boot_target? Otherwise > > > how do we use uEnv.txt files, or boot from FIT images with overlays? > > > > envboot takes care of uEnv.txt file (see > > https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/) > > > > Early remote proc loading and FIT image is a question for stdboot itself. > > > > If stdboot is missing these features then we shouldn't switch until it > has them. I'm all for switching to this, but only if it is complete. Depends on what you mean? Did you mean an option to run scripts (exists) or an option to do what TI needs done, via boot/bootmeth_something.c ? If the latter, someone from TI needs to figure out what that should be and do (but plumbing-wise everything it needs should exist). -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/16] mmc: renesas-sdhi: Initialize module on RZ/G2L
On 03/10/2023 14:25, Marek Vasut wrote:
> On 9/20/23 14:42, Paul Barker wrote:
>> On the Renesas RZ/G2L SoC family, we must ensure that the required clock
>> signals are enabled and the reset signal is de-asserted before we try to
>> communicate with the SDHI module.
>>
>> Signed-off-by: Paul Barker
>> Reviewed-by: Biju Das
>> Reviewed-by: Lad Prabhakar
>> ---
>> drivers/mmc/renesas-sdhi.c | 61 ++
>> 1 file changed, 61 insertions(+)
>>
>> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
>> index 8e716f74491f..170c5dcc2ebe 100644
>> --- a/drivers/mmc/renesas-sdhi.c
>> +++ b/drivers/mmc/renesas-sdhi.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include "tmio-common.h"
>>
>> @@ -964,6 +965,8 @@ static int renesas_sdhi_probe(struct udevice *dev)
>> u32 quirks = dev_get_driver_data(dev);
>> struct fdt_resource reg_res;
>> DECLARE_GLOBAL_DATA_PTR;
>> +struct clk imclk2, aclk;
>> +struct reset_ctl rst;
>> int ret;
>>
>> priv->clk_get_rate = renesas_sdhi_clk_get_rate;
>> @@ -1012,6 +1015,49 @@ static int renesas_sdhi_probe(struct udevice *dev)
>> goto err_clkh;
>> }
>>
>> +if (IS_ENABLED(CONFIG_RZG2L)) {
>> +/*
>> + * On members of the RZ/G2L SoC family, we need to enable
>> + * additional chip detect and bus clocks, then release the SDHI
>> + * module from reset.
>> + */
>
> This could use a separate function, and then, use bulk clock API via
> clk_get_bulk() and co .
There are 4 clocks defined in the dtb: "core", "clkh", "cd", "aclk".
During probe, we want to enable "core", "cd" (aka "imclk2" in the
datasheet) and "aclk" but not "clkh". The driver enables "clkh" later as
needed for high speed modes. So I don't think we want to bulk enable
everything here.
By "separate function", are you suggesting an entire separate probe
function for RZ/G2L SDHI? Or just moving what's inside the
if(IS_ENABLED(CONFIG_RZG2L)) into a new function which we can call from
renesas_sdhi_probe()?
Thanks,
Paul
OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 2/2] board: ti: am64x: Switch to standard boot flow
On Thu, Oct 05, 2023 at 09:01:42AM -0600, Simon Glass wrote:
> Hi Roger,
>
> On Thu, 5 Oct 2023 at 07:07, Roger Quadros wrote:
> >
> > Switch to using bootstd. Note with this change, we will stop using
> > distro_bootcmd and instead depend entirely on bootflow method of
> > starting the system up.
> >
> > Drop header files that are no longer needed in am64x_evm.h.
> > k3_dfu.h is available via k3_dfu.env in am64x.env.
> >
> > Drop unused macro CFG_SYS_SDRAM_BASE1.
> >
> > Signed-off-by: Roger Quadros
> > ---
> > board/ti/am64x/am64x.env| 1 +
> > configs/am64x_evm_a53_defconfig | 5 +++--
> > include/configs/am64x_evm.h | 9 -
> > 3 files changed, 4 insertions(+), 11 deletions(-)
> >
> > diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
> > index 68e4b7..efd736b99b 100644
> > --- a/board/ti/am64x/am64x.env
> > +++ b/board/ti/am64x/am64x.env
> > @@ -15,6 +15,7 @@ console=ttyS2,115200n8
> > args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
> > run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
> >
> > +boot_targets=mmc1 mmc0 usb pxe dhcp
> > boot=mmc
> > mmcdev=1
> > bootpart=1:2
> > diff --git a/configs/am64x_evm_a53_defconfig
> > b/configs/am64x_evm_a53_defconfig
> > index 718ad176cb..43bfcf957a 100644
> > --- a/configs/am64x_evm_a53_defconfig
> > +++ b/configs/am64x_evm_a53_defconfig
> > @@ -31,8 +31,9 @@ CONFIG_SPL_SPI=y
> > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > CONFIG_SPL_LOAD_FIT=y
> > CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> > -CONFIG_DISTRO_DEFAULTS=y
> > -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
> > +CONFIG_BOOTSTD_FULL=y
> > +CONFIG_BOOTSTD_DEFAULTS=y
> > +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
> > CONFIG_BOARD_LATE_INIT=y
> > CONFIG_SPL_MAX_SIZE=0x18
> > CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> > diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
> > index 062102a610..f9f8c7bc2f 100644
> > --- a/include/configs/am64x_evm.h
> > +++ b/include/configs/am64x_evm.h
> > @@ -9,15 +9,6 @@
> > #ifndef __CONFIG_AM642_EVM_H
> > #define __CONFIG_AM642_EVM_H
> >
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -
> > -/* DDR Configuration */
> > -#define CFG_SYS_SDRAM_BASE10x88000
> > -
> > /* Now for the remaining common defines */
> > #include
>
> It looks like this file still includes distro_bootcmd and defines all
> the BOOT_TARGET things. Can they be dropped? Perhaps for now they
> could be put behind an #ifdef if other boards need them?
>
> I suspect that with your patch as is, the environment is still full of
> scripts?
There's a lot of TI platforms, so I'm not sure what "#if" you're
thinking of might make it cleaner? We could / should move some of the
still relevant content and comments from that file to
include/env/ti/ti_armv7_common.env as I do think some of the K3
platforms could just drop at this point.
--
Tom
signature.asc
Description: PGP signature
[PATCH] sphinx: Bump urllib3 version
While not a direct issue for us, urllib3 before 1.26.17 is vulnerable to CVE-2023-43804 to bump our version up. Reported-by: GitHub dependabot Signed-off-by: Tom Rini --- Cc: Heinrich Schuchardt --- doc/sphinx/requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 6ccbe527ee79..23a296d3fca9 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -23,4 +23,4 @@ sphinxcontrib-htmlhelp==2.0.0 sphinxcontrib-jsmath==1.0.1 sphinxcontrib-qthelp==1.0.3 sphinxcontrib-serializinghtml==1.1.5 -urllib3==1.26.9 +urllib3==1.26.17 -- 2.34.1
Re: [PATCH 10/16] serial: sh: Add RZ/G2L SCIF support
On 04/10/2023 13:26, Marek Vasut wrote:
> On 10/4/23 10:48, Paul Barker wrote:
>> On 03/10/2023 14:23, Marek Vasut wrote:
>>> On 9/20/23 14:42, Paul Barker wrote:
+ if (IS_ENABLED(CONFIG_RZG2L)) {
+ struct reset_ctl rst;
+ int ret;
+
+ ret = reset_get_by_index(dev, 0, );
+ if (ret < 0) {
+ dev_err(dev, "failed to get reset line\n");
+ return ret;
+ }
+
+ ret = reset_deassert();
+ if (ret < 0) {
+ dev_err(dev, "failed to de-assert reset line\n");
+ return ret;
+ }
+ }
>>>
>>> devm_reset_control_get_optional() or something should do here too , right ?
>>>
>>> Note that R-Car does have SCIF reset too, so this can be generic code.
>>
>> For R-Car systems the current behaviour is working and well tested, we
>> concluded that we shouldn't change it so this reset de-assert was made
>> RZ/G2L specific.
>
> I can test on R-Car just fine, no worries.
>
> SH R2Dplus is even tested in CI nightly.
>
>> For RZ/G2L, de-asserting the reset is not optional.
>
> Let's avoid special-cases like that.
Looking at this again, I don't see how we can avoid a special case here,
de-asserting the reset is required for the RZ/G2L. It may be optional on
other SoCs (I don't know), but it's definitely not optional here, so I
don't think we should be using the devm_reset_control_get_optional()
function.
Thanks,
Paul
OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH RESEND v2 1/2] cmd: bind: Try to improve the (un)bind help
Hi Marek, ma...@denx.de wrote on Thu, 5 Oct 2023 15:01:51 +0200: > On 10/2/23 15:46, Miquel Raynal wrote: > > While it may sound totally obvious for the regular U-Boot developer to > > get the parameters of the bind/unbind commands from the output of 'dm > > tree', it did not felt straightforward to me until I was explicitly > > told to look there. And even when I knew the command, I did not make a > > direct link between the arguments of this command and the columns > > returned by 'dm tree'. > > > > Several of us lost a lot of time because of that, I would like to kindly > > help other users by slightly improving this textual line. Unfortunately, > > because of how this string is used (like within the 'help' command) I > > cannot detail much more, but at least the pointer is there. > > > > Signed-off-by: Miquel Raynal > > --- > > Resend: no change. > > > > Changes in v2: > > * Moved the details in the long text section as suggested by Heinrich. > > * Rephrased the help text as well, not fully following Heinrich > >suggestion, but taking inspiration from it. > > --- > > cmd/bind.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/cmd/bind.c b/cmd/bind.c > > index 4d1b7885e60..be0d4d2a711 100644 > > --- a/cmd/bind.c > > +++ b/cmd/bind.c > > @@ -246,6 +246,8 @@ U_BOOT_CMD( > > "Bind a device to a driver", > > " \n" > > "bind \n" > > + "Use 'dm tree' to list all devices registered in the driver model,\n" > > + "their path, class, index and current driver.\n" > > ); > > > U_BOOT_CMD( > > @@ -254,4 +256,6 @@ U_BOOT_CMD( > > "\n" > > "unbind \n" > > "unbind \n" > > + "Use 'dm tree' to list all devices registered in the driver model,\n" > > + "their path, class, index and current driver.\n" > > 'dm tree' depends on CMD_DM , you might need some if (IS_ENABLED()) here. Well, no, and that's my point actually. People need to know that this command exist and should be used for this purpose. If you only tell them "use 'dm tree'" conditionally, you loose part of the audience: people not aware of this command or its usefulness. Thanks, Miquèl
Re: [PATCH RESEND v2 2/2] usb: udc: Try to clarify an error message
Hi Marek,
ma...@denx.de wrote on Thu, 5 Oct 2023 15:04:25 +0200:
> On 10/2/23 15:46, Miquel Raynal wrote:
> > At some point when trying to use USB gadgets, two situations may arise
> > and lead to a failure. Either the UDC (USB Device Controller) is not
> > available at all (not described or not probed) or the UDC is already in
> > use. For instance, as the USB Ethernet gadget remains bound to the UDC,
> > the use of any other USB gadget (fastboot, dfu, etc) *after* will always
> > fail with the "couldn't find an available UDC" error.
> >
> > Let's give a more helpful message by making a difference between the two
> > cases. Let's also hint people who would get this error and grep it into
> > the sources a better explanation of what's wrong with their workflow.
> >
> > Signed-off-by: Miquel Raynal
> > ---
> > While doing this I really wanted to add "much more" error comments but I
> > faced another reality: often the messages are there but use
> > pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
> > I consider this unnecessary, as decreasing the loglevel will make these
> > messages appear. I would have expected errors to be displayed, but I
> > understand it makes the binaries even bigger.
> >
> > Resend: no change.
> >
> > Changes in v2:
> > * s/UDC/UDCs/. I kept the sentence as it was as the suggested form did
> >not sound well at all when there is only one UDC.
> > ---
> > drivers/usb/gadget/udc/udc-core.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/udc/udc-core.c
> > b/drivers/usb/gadget/udc/udc-core.c
> > index 7f73926cb3e..8405b03462e 100644
> > --- a/drivers/usb/gadget/udc/udc-core.c
> > +++ b/drivers/usb/gadget/udc/udc-core.c
> > @@ -323,6 +323,7 @@ err1:
> > int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
> > {
> > struct usb_udc *udc = NULL;
> > + unsigned intudc_count = 0;
> > int ret;
> > > if (!driver || !driver->bind || !driver->setup)
> > @@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
> > *driver)
> > > mutex_lock(_lock);
> > list_for_each_entry(udc, _list, list) {
> > + udc_count++;
> > +
> > /* For now we take the first one */
> > if (!udc->driver)
> > goto found;
> > }
> > > - printf("couldn't find an available UDC\n");
> > + if (!udc_count)
> > + printf("No UDC available in the system\n");
> > + else
> > + /* When this happens, users should 'unbind '
> > +* using the output of 'dm tree' and looking at the line right
> > +* after the USB peripheral/device controller.
> > +*/
> > + printf("All UDCs in use (%d available), use the unbind
> > command\n",
> > + udc_count);
>
> Users should really use 'bind' command in the first place, to avoid this
> guesswork to which UDC (on systems with multiple UDCs) a gadget gets bound
> to, and instead bind the gadget to specific UDC they want to bind it to. This
> code should then be removed entirely.
There are two cases when this can happen:
* a single UDC (common) but a function already bound, there is no
guessing here
* two (or more) UDC and there is some guessing
Before your cleanup, drivers would get automatically unbound from the
UDC to let the one being needed to bind. This is no longer the case,
so there is a change in the CLI and I want to help people facing
this new problem with a slightly more comprehensive message because
people don't fully understand what USB is all about. We cannot
ask all U-Boot USB users to be U-Boot experts and USB experts. This
is just a little help.
In an ideal world, we will have the possibility to create
composite gadgets and all this can go away once it is well
integrated, I guess?
Thanks,
Miquèl
Re: [PATCH v2 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible
Hi Michael,
On Thu, 5 Oct 2023 at 07:28, Simon Glass wrote:
>
> Hi Michael,
>
> On Thu, 5 Oct 2023 at 02:54, Michael Walle wrote:
> >
> > Hi,
> >
> > >> >> >> Add a compatible string for binman, so we can extend
> > >> >> >> fixed-partitions
> > >> >> >> in various ways.
> > >> >> >
> > >> >> > I've been thinking at the proper way to describe the binman
> > >> >> > partitions.
> > >> >> > I am wondering if we should really extend the fixed-partitions
> > >> >> > schema. This description is really basic and kind of supposed to
> > >> >> > remain
> > >> >> > like that. Instead, I wonder if we should not just keep the binman
> > >> >> > compatible alone, like many others already. This way it would be
> > >> >> > very clear
> > >> >> > what is expected and allowed in both cases. I am thinking about
> > >> >> > something like that:
> > >> >> >
> > >> >> >
> > >> >> > Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
> > >> >> >
> > >> >> > this file is also referenced there (but this patch does the same,
> > >> >> > which
> > >> >> > is what I'd expect):
> > >> >> >
> > >> >> >
> > >> >> > Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
> > >> >> >
> > >> >> > I'll let the binding maintainers judge whether they think it's
> > >> >> > relevant, it's not a strong opposition.
> > >> >>
> > >> >> What is the overall goal here? To replace the current binman node
> > >> >> which is
> > >> >> usually contained in the -u-boot.dtsi files? If one is using binman to
> > >> >> create an image, is it expected that one needs to adapt the DT in
> > >> >> linux?
> > >> >> Or will it still be a seperate -u-boot.dtsi? > Because in the latter
> > >> >> case
> > >> >> I see that there will be conflicts because you have to overwrite the
> > >> >> flash node. Or will it be a seperate node with all the information
> > >> >> duplicated?
> > >> >
> > >> > The goal is simply to have a full binding for firmware layout, such
> > >> > that firmware images can be created, examined and updated. The
> > >> > -u-boot.dtsi files are a stopgap while we sort out a real binding.
> > >> > They should eventually go away.
> > >>
> > >> You haven't answered whether this node should be a seperate binman
> > >> node - or if you'll reuse the existing flash (partitions) node(s) and
> > >> add any missing property there. If it's the latter, I don't think
> > >> compatible = "binman", "fixed-partitions"; is correct.
> > >
> > > My intent is to make it compatible, so wouldn't it make sense to have
> > > binman as the first compatible, then falling back to fixed-partitions
> > > as the second?
> >
> > As far as I know, the compatibles should get more specific with each
> > string.
>
> That's the opposite to what I understood.
>
> > But "binman" seems to be used as a kind of tag which could be
> > added to any compatible under the flash node. What if one wants to build
> > an image which isn't compatible = "fixed-partitions"? E.g.
> > "linksys,ns-partitions", will it then have
> > compatible = "binman", "linksys,ns-partitions"?
>
> I suppose so.
>
> >
> >
> > >> >> Maybe (a more complete) example would be helpful.
> > >> >
> > >> > Can you please be a bit more specific? What is missing from the
> > >> > example?
> > >>
> > >> Like a complete (stripped) DTS. Right now I just see how the
> > >> individual
> > >> node looks like. But with a complete example DTS, my question from
> > >> above
> > >> would have been answered.
> >
> > So to give an example myself, please correct it if it's wrong. From
> > our board (kontron-sl28):
> >
> > {
> > status = "okay";
> >
> > flash@0 {
> > compatible = "jedec,spi-nor";
> > m25p,fast-read;
> > spi-max-frequency = <13300>;
> > reg = <0>;
> > /* The following setting enables 1-1-2 (CMD-ADDR-DATA)
> > mode */
> > spi-rx-bus-width = <2>; /* 2 SPI Rx lines */
> > spi-tx-bus-width = <1>; /* 1 SPI Tx line */
> >
> > partitions {
> > compatible = "fixed-partitions";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > partition@0 {
> > reg = <0x00 0x01>;
> > label = "rcw";
> > read-only;
> > };
> >
> > partition@1 {
> > reg = <0x01 0x1d>;
> > label = "failsafe bootloader";
> > read-only;
> > };
> >
> > partition@20 {
> > reg = <0x20 0x01>;
> > label = "configuration store";
> > };
> >
> >
Re: [PATCH v2 2/2] board: ti: am64x: Switch to standard boot flow
Hi Roger,
On Thu, 5 Oct 2023 at 07:07, Roger Quadros wrote:
>
> Switch to using bootstd. Note with this change, we will stop using
> distro_bootcmd and instead depend entirely on bootflow method of
> starting the system up.
>
> Drop header files that are no longer needed in am64x_evm.h.
> k3_dfu.h is available via k3_dfu.env in am64x.env.
>
> Drop unused macro CFG_SYS_SDRAM_BASE1.
>
> Signed-off-by: Roger Quadros
> ---
> board/ti/am64x/am64x.env| 1 +
> configs/am64x_evm_a53_defconfig | 5 +++--
> include/configs/am64x_evm.h | 9 -
> 3 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
> index 68e4b7..efd736b99b 100644
> --- a/board/ti/am64x/am64x.env
> +++ b/board/ti/am64x/am64x.env
> @@ -15,6 +15,7 @@ console=ttyS2,115200n8
> args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
> run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
>
> +boot_targets=mmc1 mmc0 usb pxe dhcp
> boot=mmc
> mmcdev=1
> bootpart=1:2
> diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
> index 718ad176cb..43bfcf957a 100644
> --- a/configs/am64x_evm_a53_defconfig
> +++ b/configs/am64x_evm_a53_defconfig
> @@ -31,8 +31,9 @@ CONFIG_SPL_SPI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> CONFIG_SPL_LOAD_FIT=y
> CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> -CONFIG_DISTRO_DEFAULTS=y
> -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
> +CONFIG_BOOTSTD_FULL=y
> +CONFIG_BOOTSTD_DEFAULTS=y
> +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
> CONFIG_BOARD_LATE_INIT=y
> CONFIG_SPL_MAX_SIZE=0x18
> CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
> index 062102a610..f9f8c7bc2f 100644
> --- a/include/configs/am64x_evm.h
> +++ b/include/configs/am64x_evm.h
> @@ -9,15 +9,6 @@
> #ifndef __CONFIG_AM642_EVM_H
> #define __CONFIG_AM642_EVM_H
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -/* DDR Configuration */
> -#define CFG_SYS_SDRAM_BASE10x88000
> -
> /* Now for the remaining common defines */
> #include
It looks like this file still includes distro_bootcmd and defines all
the BOOT_TARGET things. Can they be dropped? Perhaps for now they
could be put behind an #ifdef if other boards need them?
I suspect that with your patch as is, the environment is still full of scripts?
>
> --
> 2.34.1
>
Regards,
Simon
Re: [PATCH 05/25] treewide: Correct use of long help
On Wed, Oct 04, 2023 at 07:23:47PM -0600, Simon Glass wrote: > Hi Tom, > > On Sun, 24 Sept 2023 at 17:27, Tom Rini wrote: > > > > On Sun, Sep 24, 2023 at 02:39:23PM -0600, Simon Glass wrote: > > > Some commands assume that CONFIG_SYS_LONGHELP is always defined. > > > Declaration of long help should be bracketed by an #ifdef to avoid an > > > 'unused variable' warning. > > > > > > Fix this treewide. > > > > > > Signed-off-by: Simon Glass > > [snip] > > > diff --git a/arch/arm/mach-imx/cmd_dek.c b/arch/arm/mach-imx/cmd_dek.c > > > index 6fa5b41fcd38..25ea7d3b37da 100644 > > > --- a/arch/arm/mach-imx/cmd_dek.c > > > +++ b/arch/arm/mach-imx/cmd_dek.c > > > @@ -393,11 +393,12 @@ static int do_dek_blob(struct cmd_tbl *cmdtp, int > > > flag, int argc, > > > return blob_encap_dek(src_addr, dst_addr, len); > > > } > > > > > > -/***/ > > > +#if IS_ENABLED(CONFIG_SYS_LONGHELP) > > > static char dek_blob_help_text[] = > > > "src dst len- Encapsulate and create blob of data\n" > > > " $len bits long at address $src and\n" > > > " store the result at address $dst.\n"; > > > +#endif > > > > > > U_BOOT_CMD( > > > dek_blob, 4, 1, do_dek_blob, > > > > This really doesn't read nicely. I would rather (globally and fix > > existing users) __maybe_unused this instead. I think there's just one > > example today that isn't "foo_help_text". > > Hmm, what do you think about adding a __longhelp symbol to cause the > linker to discard it when not needed? Well, I don't think we need linker list magic when __maybe_unused will just have them be discarded normally. -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: dts: k3-am625-beagleplay: Fix boot
On Thu, Oct 05, 2023 at 10:49:19AM -0400, Tom Rini wrote:
> On Thu, Oct 05, 2023 at 06:18:08AM +0200, Jan Kiszka wrote:
> > On 04.10.23 14:15, Nishanth Menon wrote:
> > > On 22:26-20231003, Jan Kiszka wrote:
> > >> From: Jan Kiszka
> > >>
> > >> Since commit [1] A53 u-boot proper is broken. This is because nodes
> > >> marked as 'bootph-pre-ram' are not available at u-boot proper before
> > >> relocation.
> > >>
> > >> To fix this we mark all nodes as 'bootph-all'.
> > >>
> > >> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as
> > >> pre-reloc after relocation")
> > >>
> > >> Signed-off-by: Jan Kiszka
> > >> ---
> > >>
> > >> This may overshoot, but at least the board boots again. Could it be that
> > >> [1] broke even more boards?
> > >
> > > Jan:
> > > https://lore.kernel.org/all/b1c62a7d-a90e-4212-8972-9b622e147...@kernel.org/
> > >
> > > I got boot without r5-beagleplay.dts modified. and it is in line with
> > > the changes in linux-next commit 944adefc7f88 ("arm64: dts: ti:
> > > k3-am625-beagleplay: Add boot phase tags marking")
> > >
> >
> > Yeah, no problem, missed that.
> >
> > Meanwhile, I can fix our IOT2050 because I was unfortunatenly right:
> > more havoc in sight. Did anyone tried to look at the fallouts
> > systematically already? Is it only affecting the TI family?
>
> Well, I'm pretty confused right now. The visible breakage has been
> traced back to a commit that was in -next and is fine on my J721E EVM
> and is fine on my AM65x EVM. I can't figure out where my Beagleplay
> ended up, so I can't check that one as easily. But given how the
> breakage is described, mine too should be failing. But they aren't. In
> both cases, I have the GP versions of the chips, and am booting the
> unsigned files.
OK, I think I might have solved my own unexpected success here in that
it seems like I had the wrong files being copied to the device and so
that somehow ended up working. I have replicated failure finally.
>
> --
> Tom
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] arm: dts: k3-am625-beagleplay: Fix Boot
On Mon, Oct 02, 2023 at 10:00:53AM -0500, Nishanth Menon wrote:
> Since commit [1] A53 u-boot proper is broken. This is because nodes
> marked as 'bootph-pre-ram' are not available at u-boot proper before
> relocation.
>
> To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.
>
> [1]
> 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after
> relocation")
>
> Reported-by: Roger Quadros
> Signed-off-by: Nishanth Menon
> Reviewed-by: Roger Quadros
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/6] arm: dts: k3-am64-evm: Fix boot
On Fri, Sep 29, 2023 at 04:46:41PM +0300, Roger Quadros wrote:
> Since commit [1] A53 u-boot proper is broken.
> This is because nodes marked as 'bootph-pre-ram' are
> not available at u-boot proper before relocation.
>
> To fix this we mark all nodes in sk-u-boot.dtsi as
> 'bootph-all'.
>
> Move vtt_supply and cbass_mcu node to -r5-evm.dts as
> it is only required for R5 SPL.
>
> [1]
> 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after
> relocation")
>
> Signed-off-by: Roger Quadros
> Reviewed-by: Nishanth Menon
For the series, applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4 1/6] arm: mach-k3: j721e: dev-data: Add mcu_timer0 ID
On Wed, Sep 27, 2023 at 06:39:51PM +0530, Neha Malcom Francis wrote: > U-Boot uses mcu_timer0 as the tick-timer, so add it to device list. > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Manorit Chawdhry > Reviewed-by: Nishanth Menon For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: dts: k3-am625-beagleplay: Fix boot
On Thu, Oct 05, 2023 at 06:18:08AM +0200, Jan Kiszka wrote:
> On 04.10.23 14:15, Nishanth Menon wrote:
> > On 22:26-20231003, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> Since commit [1] A53 u-boot proper is broken. This is because nodes
> >> marked as 'bootph-pre-ram' are not available at u-boot proper before
> >> relocation.
> >>
> >> To fix this we mark all nodes as 'bootph-all'.
> >>
> >> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
> >> after relocation")
> >>
> >> Signed-off-by: Jan Kiszka
> >> ---
> >>
> >> This may overshoot, but at least the board boots again. Could it be that
> >> [1] broke even more boards?
> >
> > Jan:
> > https://lore.kernel.org/all/b1c62a7d-a90e-4212-8972-9b622e147...@kernel.org/
> >
> > I got boot without r5-beagleplay.dts modified. and it is in line with
> > the changes in linux-next commit 944adefc7f88 ("arm64: dts: ti:
> > k3-am625-beagleplay: Add boot phase tags marking")
> >
>
> Yeah, no problem, missed that.
>
> Meanwhile, I can fix our IOT2050 because I was unfortunatenly right:
> more havoc in sight. Did anyone tried to look at the fallouts
> systematically already? Is it only affecting the TI family?
Well, I'm pretty confused right now. The visible breakage has been
traced back to a commit that was in -next and is fine on my J721E EVM
and is fine on my AM65x EVM. I can't figure out where my Beagleplay
ended up, so I can't check that one as easily. But given how the
breakage is described, mine too should be failing. But they aren't. In
both cases, I have the GP versions of the chips, and am booting the
unsigned files.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 03/25] autoboot: Correct dependencies on CMDLINE
On Tue, Oct 03, 2023 at 08:11:11PM -0600, Simon Glass wrote: > Hi Tom, > > On Sun, 24 Sept 2023 at 18:40, Tom Rini wrote: > > > > On Sun, Sep 24, 2023 at 02:39:21PM -0600, Simon Glass wrote: > > > > > Make AUTOBOOT depend on CMDLINE since it is mostly meaningless without it. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > boot/Kconfig | 23 ++- > > > 1 file changed, 14 insertions(+), 9 deletions(-) > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig > > > index f74ac7e9cc72..41ec2c34bf74 100644 > > > --- a/boot/Kconfig > > > +++ b/boot/Kconfig > > > @@ -1167,14 +1167,16 @@ menu "Autoboot options" > > > > > > config AUTOBOOT > > > bool "Autoboot" > > > + depends on CMDLINE > > > default y > > > help > > > This enables the autoboot. See doc/README.autoboot for detail. > > > > This is fine and correct. > > > > > +if AUTOBOOT > > > + > > > config BOOTDELAY > > > int "delay in seconds before automatically booting" > > > default 2 > > > - depends on AUTOBOOT > > [snip] > > > @@ -1322,6 +1324,9 @@ config AUTOBOOT_STOP_STR_SHA256 > > > includes a ":", the portion prior to the ":" will be treated > > > as a salt value. > > > > > > +endif # AUTOBOOT_KEYED > > > +endif # AUTOBOOT > > > > So it's ~200 lines, yes, hiding this under an if, or perhaps a menu > > makes sense, however... > > > > > config AUTOBOOT_USE_MENUKEY > > > bool "Allow a specify key to run a menu from the environment" > > > depends on !AUTOBOOT_KEYED > > > > It looks like there's more stuff to move under a menu/if here? > > Well this depends on !AUTOBOOT_KEYED so can't be in the 'if > AUTOBOOT_KEYED'. But yes I can create a new 'if !AUTOBOOT_KEYED' for > these two items. Normally we want 2-3 options to warrant an 'if', so I > don't see this as a strong case. Well, sometimes it seems like we abuse the "if" mechanic too. It's not short-hand for "avoid saying depends on" a few times, it's "hide these things until we turn on another feature". But right here it looks like AUTOBOOT_USE_MENUKEY still needs to be under "if AUTOBOOT" yes? -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-dm
On Wed, Oct 04, 2023 at 12:00:32PM -0600, Simon Glass wrote: > Hi Tom, > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/18014 > (usual azure branch but I cannot get the link) > > The following changes since commit 65b9b3462bec2966911658836983819ab4e4823e: > > Merge branch 'next_pinctrl_sync' of > https://source.denx.de/u-boot/custodians/u-boot-sh (2023-10-02 > 15:19:02 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-4oct23 > > for you to fetch changes up to 4840b71bb009711564e20f9695b92950c3f73e42: > > qconfig: Update the documentation (2023-10-04 09:25:22 -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/2] arm: dts: j7200: dts sync with Linux 6.6-rc1
On 06:33-20231005, Nishanth Menon wrote:
> On 11:56-20231004, Reid Tonking wrote:
> > Sync j7200 dts with Linux 6.6-rc1
> [..]
> > diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > index e62f9218e8..9469dca39f 100644
> > --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > @@ -1,13 +1,14 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
> > + * Copyright (C) 2020-2023 Texas Instruments Incorporated -
> > https://www.ti.com/
> > */
> >
> > /dts-v1/;
> >
> > -#include "k3-j7200-som-p0.dtsi"
> > +#include "k3-j7200-common-proc-board.dts"
> > #include "k3-j7200-ddr-evm-lp4-2666.dtsi"
> > #include "k3-j721e-ddr.dtsi"
> > +#include "k3-j7200-common-proc-board-u-boot.dtsi"
> >
> > / {
> > aliases {
> > @@ -15,17 +16,6 @@
> > remoteproc1 = _0;
> > };
> >
> > - chosen {
> > - stdout-path = _uart0;
> > - tick-timer =
> > - firmware-loader = _loader0;
> > - };
> > -
> > - fs_loader0: fs_loader@0 {
> > - bootph-all;
> > - compatible = "u-boot,fs-loader";
> > - };
> > -
> > a72_0: a72@0 {
> > compatible = "ti,am654-rproc";
> > reg = <0x0 0x00a9 0x0 0x10>;
> > @@ -39,21 +29,17 @@
> > ti,sci = <>;
> > ti,sci-proc-id = <32>;
> > ti,sci-host-id = <10>;
> > - bootph-pre-ram;
> > - };
> > -
> > - clk_200mhz: dummy_clock_200mhz {
> > - compatible = "fixed-clock";
> > - #clock-cells = <0>;
> > - clock-frequency = <2>;
> > - bootph-pre-ram;
> > + bootph-all;
>
> Here and else where in the r5 file: why switch from pre-ram to bootph-all
> ? dont we need these prior to ddr initialization?
>
Due to the change in how booth-pre-ram works [0], bootph-pre-ram alone no
longer works. U-boot docs Pre-Relocation Support section says some-ram
can be used for u-boot prior to reloc, but not spl. So like Massimo
mentioned in the linked discussion, some-ram + pre-ram can work, as well
as -all. Outside of affecting the TPL phase, I'm not sure I know of a
difference in regards to how it affects pre-ddr.
[0]:
https://lore.kernel.org/u-boot/capnjgz3mgwx8t0a0sofpher_xd77pe3hte9dnye1rubveb9...@mail.gmail.com/
> [...]
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
Re: [PATCH v1 0/1] virtio-blk support for xen board
Reviewed-by On Tue, Oct 3, 2023 at 10:58 AM Andrii Chepurnyi wrote: > Hello. > > This patch adds the ability to use virtio-blk in the guest domain > under Xen hypervisor. To do such you need to build U-boot > with xenguest_arm64_virtio_defconfig. > > The patch was tested on a specific build for rcar-gen3 hardware, > with multiple Linux domains running under Xen and QEMU > as a block backend. > > Andrii Chepurnyi (1): > board: xen: introduce virtio-blk support > > board/xen/xenguest_arm64/xenguest_arm64.c | 108 +- > configs/xenguest_arm64_virtio_defconfig | 63 + > doc/board/xen/xenguest_arm64.rst | 2 + > include/configs/xenguest_arm64.h | 10 +- > 4 files changed, 180 insertions(+), 3 deletions(-) > create mode 100644 configs/xenguest_arm64_virtio_defconfig > > -- > 2.25.1 >
[PATCH] arm: mach-k3: Remove secure device makefile
This is now done using binman but this file was leftover and is now unused, remove it. Signed-off-by: Andrew Davis --- MAINTAINERS | 1 - arch/arm/mach-k3/config_secure.mk | 44 --- 2 files changed, 45 deletions(-) delete mode 100644 arch/arm/mach-k3/config_secure.mk diff --git a/MAINTAINERS b/MAINTAINERS index 4df79254dfe..de4711721b2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1548,7 +1548,6 @@ F:arch/arm/mach-omap2/omap5/sec_entry_cpu1.S F: arch/arm/mach-omap2/sec-common.c F: arch/arm/mach-omap2/config_secure.mk F: arch/arm/mach-k3/security.c -F: arch/arm/mach-k3/config_secure.mk F: configs/am335x_hs_evm_defconfig F: configs/am335x_hs_evm_uart_defconfig F: configs/am43xx_hs_evm_defconfig diff --git a/arch/arm/mach-k3/config_secure.mk b/arch/arm/mach-k3/config_secure.mk deleted file mode 100644 index 9cc1f9eb24f..000 --- a/arch/arm/mach-k3/config_secure.mk +++ /dev/null @@ -1,44 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -# -# Copyright (C) 2018 Texas Instruments, Incorporated - http://www.ti.com/ -# Andrew F. Davis - -quiet_cmd_k3secureimg = SECURE $@ -ifneq ($(TI_SECURE_DEV_PKG),) -ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),) -cmd_k3secureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \ - $< $@ \ - $(if $(KBUILD_VERBOSE:1=), >/dev/null) -else -cmd_k3secureimg = echo "WARNING:" \ - "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \ - "$@ was NOT secured!"; cp $< $@ -endif -else -cmd_k3secureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \ - "variable must be defined for TI secure devices." \ - "$@ was NOT secured!"; cp $< $@ -endif - -%.dtb_HS: %.dtb FORCE - $(call if_changed,k3secureimg) - -$(obj)/u-boot-spl-nodtb.bin_HS: $(obj)/u-boot-spl-nodtb.bin FORCE - $(call if_changed,k3secureimg) - -tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst %,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) $(SPL_ITS) FORCE - $(call if_changed,mkfitimage) - -MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ - -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ - -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST))) - -OF_LIST_TARGETS = $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) -$(OF_LIST_TARGETS): dtbs - -u-boot-nodtb.bin_HS: u-boot-nodtb.bin FORCE - $(call if_changed,k3secureimg) - -u-boot.img_HS: u-boot-nodtb.bin_HS u-boot.img $(patsubst %.dtb,%.dtb_HS,$(OF_LIST_TARGETS)) FORCE - $(call if_changed,mkimage) -- 2.39.2
Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
On 10/4/23 8:54 AM, Nishanth Menon wrote:
On 08:48-20231004, Andrew Davis wrote:
On 10/4/23 8:23 AM, Roger Quadros wrote:
ti_mmc is not a valid boot_target for standard boot flow so
Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from FIT images with overlays?
envboot takes care of uEnv.txt file (see
https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/)
Early remote proc loading and FIT image is a question for stdboot itself.
If stdboot is missing these features then we shouldn't switch until it
has them. I'm all for switching to this, but only if it is complete.
Andrew
Andrew
remove it. Prefer mmc1 (sd-card) over mmc0 (emmc).
Signed-off-by: Roger Quadros
---
board/ti/am62x/am62x.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index 22a6c2c91b..e53a55c38f 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -8,7 +8,7 @@ args_all=setenv optargs ${optargs}
earlycon=ns16550a,mmio32,0x0280
${mtdparts}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
-boot_targets=ti_mmc mmc0 mmc1 usb pxe dhcp
+boot_targets=mmc1 mmc0 usb pxe dhcp
boot=mmc
mmcdev=1
bootpart=1:2
Re: [PATCH v2 2/2] board: ti: am64x: Switch to standard boot flow
On 16:06-20231005, Roger Quadros wrote:
> Switch to using bootstd. Note with this change, we will stop using
> distro_bootcmd and instead depend entirely on bootflow method of
> starting the system up.
>
> Drop header files that are no longer needed in am64x_evm.h.
> k3_dfu.h is available via k3_dfu.env in am64x.env.
>
> Drop unused macro CFG_SYS_SDRAM_BASE1.
>
> Signed-off-by: Roger Quadros
> ---
> board/ti/am64x/am64x.env| 1 +
> configs/am64x_evm_a53_defconfig | 5 +++--
> include/configs/am64x_evm.h | 9 -
> 3 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
> index 68e4b7..efd736b99b 100644
> --- a/board/ti/am64x/am64x.env
> +++ b/board/ti/am64x/am64x.env
> @@ -15,6 +15,7 @@ console=ttyS2,115200n8
> args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
> run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
>
> +boot_targets=mmc1 mmc0 usb pxe dhcp
> boot=mmc
> mmcdev=1
> bootpart=1:2
> diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
> index 718ad176cb..43bfcf957a 100644
> --- a/configs/am64x_evm_a53_defconfig
> +++ b/configs/am64x_evm_a53_defconfig
> @@ -31,8 +31,9 @@ CONFIG_SPL_SPI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> CONFIG_SPL_LOAD_FIT=y
> CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> -CONFIG_DISTRO_DEFAULTS=y
> -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
> +CONFIG_BOOTSTD_FULL=y
> +CONFIG_BOOTSTD_DEFAULTS=y
> +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
> CONFIG_BOARD_LATE_INIT=y
> CONFIG_SPL_MAX_SIZE=0x18
> CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
> index 062102a610..f9f8c7bc2f 100644
> --- a/include/configs/am64x_evm.h
> +++ b/include/configs/am64x_evm.h
> @@ -9,15 +9,6 @@
> #ifndef __CONFIG_AM642_EVM_H
> #define __CONFIG_AM642_EVM_H
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -/* DDR Configuration */
> -#define CFG_SYS_SDRAM_BASE1 0x88000
> -
> /* Now for the remaining common defines */
> #include
>
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v2 1/3] dt-bindings: mtd: fixed-partitions: Add binman compatible
Hi Michael,
On Thu, 5 Oct 2023 at 02:54, Michael Walle wrote:
>
> Hi,
>
> >> >> >> Add a compatible string for binman, so we can extend fixed-partitions
> >> >> >> in various ways.
> >> >> >
> >> >> > I've been thinking at the proper way to describe the binman
> >> >> > partitions.
> >> >> > I am wondering if we should really extend the fixed-partitions
> >> >> > schema. This description is really basic and kind of supposed to
> >> >> > remain
> >> >> > like that. Instead, I wonder if we should not just keep the binman
> >> >> > compatible alone, like many others already. This way it would be very
> >> >> > clear
> >> >> > what is expected and allowed in both cases. I am thinking about
> >> >> > something like that:
> >> >> >
> >> >> >
> >> >> > Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
> >> >> >
> >> >> > this file is also referenced there (but this patch does the same,
> >> >> > which
> >> >> > is what I'd expect):
> >> >> >
> >> >> > Documentation/devicetree/bindings/mtd/partitions/partitions.yaml
> >> >> >
> >> >> > I'll let the binding maintainers judge whether they think it's
> >> >> > relevant, it's not a strong opposition.
> >> >>
> >> >> What is the overall goal here? To replace the current binman node
> >> >> which is
> >> >> usually contained in the -u-boot.dtsi files? If one is using binman to
> >> >> create an image, is it expected that one needs to adapt the DT in
> >> >> linux?
> >> >> Or will it still be a seperate -u-boot.dtsi? > Because in the latter
> >> >> case
> >> >> I see that there will be conflicts because you have to overwrite the
> >> >> flash node. Or will it be a seperate node with all the information
> >> >> duplicated?
> >> >
> >> > The goal is simply to have a full binding for firmware layout, such
> >> > that firmware images can be created, examined and updated. The
> >> > -u-boot.dtsi files are a stopgap while we sort out a real binding.
> >> > They should eventually go away.
> >>
> >> You haven't answered whether this node should be a seperate binman
> >> node - or if you'll reuse the existing flash (partitions) node(s) and
> >> add any missing property there. If it's the latter, I don't think
> >> compatible = "binman", "fixed-partitions"; is correct.
> >
> > My intent is to make it compatible, so wouldn't it make sense to have
> > binman as the first compatible, then falling back to fixed-partitions
> > as the second?
>
> As far as I know, the compatibles should get more specific with each
> string.
That's the opposite to what I understood.
> But "binman" seems to be used as a kind of tag which could be
> added to any compatible under the flash node. What if one wants to build
> an image which isn't compatible = "fixed-partitions"? E.g.
> "linksys,ns-partitions", will it then have
> compatible = "binman", "linksys,ns-partitions"?
I suppose so.
>
>
> >> >> Maybe (a more complete) example would be helpful.
> >> >
> >> > Can you please be a bit more specific? What is missing from the
> >> > example?
> >>
> >> Like a complete (stripped) DTS. Right now I just see how the
> >> individual
> >> node looks like. But with a complete example DTS, my question from
> >> above
> >> would have been answered.
>
> So to give an example myself, please correct it if it's wrong. From
> our board (kontron-sl28):
>
> {
> status = "okay";
>
> flash@0 {
> compatible = "jedec,spi-nor";
> m25p,fast-read;
> spi-max-frequency = <13300>;
> reg = <0>;
> /* The following setting enables 1-1-2 (CMD-ADDR-DATA)
> mode */
> spi-rx-bus-width = <2>; /* 2 SPI Rx lines */
> spi-tx-bus-width = <1>; /* 1 SPI Tx line */
>
> partitions {
> compatible = "fixed-partitions";
> #address-cells = <1>;
> #size-cells = <1>;
>
> partition@0 {
> reg = <0x00 0x01>;
> label = "rcw";
> read-only;
> };
>
> partition@1 {
> reg = <0x01 0x1d>;
> label = "failsafe bootloader";
> read-only;
> };
>
> partition@20 {
> reg = <0x20 0x01>;
> label = "configuration store";
> };
>
> partition@21 {
> reg = <0x21 0x1d>;
> label = "bootloader";
> };
>
> partition@3e {
> reg = <0x3e 0x02>;
>
[PATCH v2 2/2] board: ti: am64x: Switch to standard boot flow
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Drop header files that are no longer needed in am64x_evm.h.
k3_dfu.h is available via k3_dfu.env in am64x.env.
Drop unused macro CFG_SYS_SDRAM_BASE1.
Signed-off-by: Roger Quadros
---
board/ti/am64x/am64x.env| 1 +
configs/am64x_evm_a53_defconfig | 5 +++--
include/configs/am64x_evm.h | 9 -
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index 68e4b7..efd736b99b 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -15,6 +15,7 @@ console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+boot_targets=mmc1 mmc0 usb pxe dhcp
boot=mmc
mmcdev=1
bootpart=1:2
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 718ad176cb..43bfcf957a 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -31,8 +31,9 @@ CONFIG_SPL_SPI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
-CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
+CONFIG_BOOTSTD_FULL=y
+CONFIG_BOOTSTD_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x18
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 062102a610..f9f8c7bc2f 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -9,15 +9,6 @@
#ifndef __CONFIG_AM642_EVM_H
#define __CONFIG_AM642_EVM_H
-#include
-#include
-#include
-#include
-#include
-
-/* DDR Configuration */
-#define CFG_SYS_SDRAM_BASE10x88000
-
/* Now for the remaining common defines */
#include
--
2.34.1
[PATCH v2 1/2] board: ti: am62x: am62x.env: Fix boot_targets
ti_mmc is not a valid boot_target for standard boot flow so
remove it. Prefer mmc1 (sd-card) over mmc0 (emmc).
Signed-off-by: Roger Quadros
Reviewed-by: Nishanth Menon
---
board/ti/am62x/am62x.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index 22a6c2c91b..e53a55c38f 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -8,7 +8,7 @@ args_all=setenv optargs ${optargs}
earlycon=ns16550a,mmio32,0x0280
${mtdparts}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
-boot_targets=ti_mmc mmc0 mmc1 usb pxe dhcp
+boot_targets=mmc1 mmc0 usb pxe dhcp
boot=mmc
mmcdev=1
bootpart=1:2
--
2.34.1
[PATCH v2 0/2] board: ti: am6x: Switch to standard boot
Hi,
This series switches am64x to standard boot flow.
Also minor fix to am62x boot targets.
NOTE:
Tested on AM64x GP EVM but I had to hand edit the grub.cfg
file provided with the TI release [1]
from,
menuentry 'boot'{
linux /Image root=PARTUUID=3a4a99a8-02 rootwait rootfstype=ext4
}
to,
menuentry 'boot'{
linux /Image console=ttyS2,115200n8 root=PARTUUID=3a4a99a8-02 rootwait
rootfstype=ext4
}
else there is no console output.
[1]
https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-yXgchBCk98/09.00.00.03/tisdk-default-image-am64xx-evm.wic.xz
cheers,
-roger
Changelog:
v2:
- Added Nishanth's Reviewed-by for patch 1
- Dropped unnecessary headers and macro from patch 2
Roger Quadros (2):
board: ti: am62x: am62x.env: Fix boot_targets
board: ti: am64x: Switch to standard boot flow
board/ti/am62x/am62x.env| 2 +-
board/ti/am64x/am64x.env| 1 +
configs/am64x_evm_a53_defconfig | 5 +++--
include/configs/am64x_evm.h | 9 -
4 files changed, 5 insertions(+), 12 deletions(-)
base-commit: e29b932aa07fa0226d325b35d96cd4eea0370129
prerequisite-patch-id: afb49f33f198747451687f83936f039049365924
prerequisite-patch-id: 1d8297eb0a3b44d8578cae785cc22f0fb6077239
prerequisite-patch-id: 4ae9fdc0b3737e55289a78a59d546a08c03d62e5
prerequisite-patch-id: 2be0e0caf153bec2c453b2f21342ba207c1ee13d
prerequisite-patch-id: 7710703ce9a41b72ff3fb89abf0823625a5b5454
prerequisite-patch-id: 60d61440bf0ab8c0bea8b971ef18aa6d0d26e113
prerequisite-patch-id: c974e6d80489cbb0ee8cc1f3e19bcc9cf47f25b6
--
2.34.1
[PATCH 2/2] MAINTAINERS: fastboot: add Mattijs
Fastboot has been marked as orphaned since 2021. Since I'm interested in maintaining this, assign myself. Signed-off-by: Mattijs Korpershoek --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 008c593f30ee..6790f4ddbd45 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1052,7 +1052,8 @@ F:test/common/event.c F: test/py/tests/test_event_dump.py FASTBOOT -S: Orphaned +M: Mattijs Korpershoek +S: Maintained F: cmd/fastboot.c F: doc/android/fastboot*.rst F: include/fastboot.h -- 2.41.0
[PATCH 1/2] MAINTAINERS: usb gadget: add Mattijs
It seems that Lukasz and Marek could get some help in maintaining the usb gadget drivers. Assign myself as maintainer. Signed-off-by: Mattijs Korpershoek --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4df79254dfe1..008c593f30ee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -945,6 +945,7 @@ F: include/cyclic.h DFU M: Lukasz Majewski +M: Mattijs Korpershoek S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git F: cmd/dfu.c -- 2.41.0
[PATCH 0/2] MAINTAINERS: Add Mattijs to USB/fastboot maintainers
>From discussions with Marek at Kernel Recipes, it seems that the USB subsystem in U-boot need some help. Since I've been asked and I'm willing to help, I've added myself to the maintainers entry. I have also added myself for fastboot since I'm interested in keeping that functional as well. Note that I have no previous (open-source) maintainer experience so I will do my best to learn. Signed-off-by: Mattijs Korpershoek --- Mattijs Korpershoek (2): MAINTAINERS: usb gadget: add Mattijs MAINTAINERS: fastboot: add Mattijs MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- base-commit: 65b9b3462bec2966911658836983819ab4e4823e change-id: 20231005-mattijs-usb-6b83dde256f0 Best regards, -- Mattijs Korpershoek
Re: [PATCH RESEND v2 2/2] usb: udc: Try to clarify an error message
On 10/2/23 15:46, Miquel Raynal wrote:
At some point when trying to use USB gadgets, two situations may arise
and lead to a failure. Either the UDC (USB Device Controller) is not
available at all (not described or not probed) or the UDC is already in
use. For instance, as the USB Ethernet gadget remains bound to the UDC,
the use of any other USB gadget (fastboot, dfu, etc) *after* will always
fail with the "couldn't find an available UDC" error.
Let's give a more helpful message by making a difference between the two
cases. Let's also hint people who would get this error and grep it into
the sources a better explanation of what's wrong with their workflow.
Signed-off-by: Miquel Raynal
---
While doing this I really wanted to add "much more" error comments but I
faced another reality: often the messages are there but use
pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
I consider this unnecessary, as decreasing the loglevel will make these
messages appear. I would have expected errors to be displayed, but I
understand it makes the binaries even bigger.
Resend: no change.
Changes in v2:
* s/UDC/UDCs/. I kept the sentence as it was as the suggested form did
not sound well at all when there is only one UDC.
---
drivers/usb/gadget/udc/udc-core.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 7f73926cb3e..8405b03462e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -323,6 +323,7 @@ err1:
int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
{
struct usb_udc *udc = NULL;
+ unsigned intudc_count = 0;
int ret;
if (!driver || !driver->bind || !driver->setup)
@@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver)
mutex_lock(_lock);
list_for_each_entry(udc, _list, list) {
+ udc_count++;
+
/* For now we take the first one */
if (!udc->driver)
goto found;
}
- printf("couldn't find an available UDC\n");
+ if (!udc_count)
+ printf("No UDC available in the system\n");
+ else
+ /* When this happens, users should 'unbind '
+* using the output of 'dm tree' and looking at the line right
+* after the USB peripheral/device controller.
+*/
+ printf("All UDCs in use (%d available), use the unbind
command\n",
+ udc_count);
Users should really use 'bind' command in the first place, to avoid this
guesswork to which UDC (on systems with multiple UDCs) a gadget gets
bound to, and instead bind the gadget to specific UDC they want to bind
it to. This code should then be removed entirely.
Re: [PATCH RESEND v2 1/2] cmd: bind: Try to improve the (un)bind help
On 10/2/23 15:46, Miquel Raynal wrote: While it may sound totally obvious for the regular U-Boot developer to get the parameters of the bind/unbind commands from the output of 'dm tree', it did not felt straightforward to me until I was explicitly told to look there. And even when I knew the command, I did not make a direct link between the arguments of this command and the columns returned by 'dm tree'. Several of us lost a lot of time because of that, I would like to kindly help other users by slightly improving this textual line. Unfortunately, because of how this string is used (like within the 'help' command) I cannot detail much more, but at least the pointer is there. Signed-off-by: Miquel Raynal --- Resend: no change. Changes in v2: * Moved the details in the long text section as suggested by Heinrich. * Rephrased the help text as well, not fully following Heinrich suggestion, but taking inspiration from it. --- cmd/bind.c | 4 1 file changed, 4 insertions(+) diff --git a/cmd/bind.c b/cmd/bind.c index 4d1b7885e60..be0d4d2a711 100644 --- a/cmd/bind.c +++ b/cmd/bind.c @@ -246,6 +246,8 @@ U_BOOT_CMD( "Bind a device to a driver", " \n" "bind \n" + "Use 'dm tree' to list all devices registered in the driver model,\n" + "their path, class, index and current driver.\n" ); U_BOOT_CMD( @@ -254,4 +256,6 @@ U_BOOT_CMD( "\n" "unbind \n" "unbind \n" + "Use 'dm tree' to list all devices registered in the driver model,\n" + "their path, class, index and current driver.\n" 'dm tree' depends on CMD_DM , you might need some if (IS_ENABLED()) here.
Re: [PATCH v3 0/8] Support USB for Meson A1
From: Neil Armstrong Hi, On Thu, 5 Oct 2023 11:54:21 +0300, Alexey Romanov wrote: > This patchset adds USB stack support for Amlogic A1 SoC's > series. Made reset / phy / dwc3 drivers more flexible and > added support for A1 board. > > V2: > > - Made power domain for PHY optional. > - Add missing CLKID_USB_PHY gate. > - Drop patch with USB stack initialization in board-a1.c. > Instead of, enable CONFIG_DM_USB_GADGET for AD401 board. > - Support A1 in g12a_child_pre_probe/post_remove functions > in dwc3 driver. > > [...] Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic (u-boot-amlogic) [1/8] dt-bindings: reset: add Meson A1 reset bindings https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/fccbc810551a7e1c821ac23d5e8fd27c12ded1b2 [2/8] reset: add support for Amlogic A1 family https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/29ad8b0401dc9a75a15077f2a38363659091580e [3/8] phy: get rid of raw hex values https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/11572764d44783870cc61ac2f0435bd555222ef6 [4/8] phy: move clk enable/disable in init/exit https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/ac7f5b2f768d298fe84ab36d363853748ae23243 [5/8] phy: support Amlogic A1 family https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/66defb628f658df97e426ab13dc620b9bf6277ab [6/8] a1: clk: Add missing USB_PHY_IN and USB_PHY gates https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/84b0d40f3adb03074a80a58e4e655b422bce40ce [7/8] dwc3: add support for Amlogic A1 family https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/8a4781ff2e51d5831b7d236a327c5fb13849b689 [8/8] ad401: enable USB stack https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/686a98392fc1beaf544c8cf65f48b781a56a5148 -- Neil
Re: [PATCH RESEND v2 2/2] usb: udc: Try to clarify an error message
On lun., oct. 02, 2023 at 15:46, Miquel Raynal
wrote:
> At some point when trying to use USB gadgets, two situations may arise
> and lead to a failure. Either the UDC (USB Device Controller) is not
> available at all (not described or not probed) or the UDC is already in
> use. For instance, as the USB Ethernet gadget remains bound to the UDC,
> the use of any other USB gadget (fastboot, dfu, etc) *after* will always
> fail with the "couldn't find an available UDC" error.
>
> Let's give a more helpful message by making a difference between the two
> cases. Let's also hint people who would get this error and grep it into
> the sources a better explanation of what's wrong with their workflow.
>
> Signed-off-by: Miquel Raynal
Reviewed-by: Mattijs Korpershoek
> ---
> While doing this I really wanted to add "much more" error comments but I
> faced another reality: often the messages are there but use
> pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
> I consider this unnecessary, as decreasing the loglevel will make these
> messages appear. I would have expected errors to be displayed, but I
> understand it makes the binaries even bigger.
>
> Resend: no change.
>
> Changes in v2:
> * s/UDC/UDCs/. I kept the sentence as it was as the suggested form did
> not sound well at all when there is only one UDC.
> ---
> drivers/usb/gadget/udc/udc-core.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/udc-core.c
> b/drivers/usb/gadget/udc/udc-core.c
> index 7f73926cb3e..8405b03462e 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
> @@ -323,6 +323,7 @@ err1:
> int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
> {
> struct usb_udc *udc = NULL;
> + unsigned intudc_count = 0;
> int ret;
>
> if (!driver || !driver->bind || !driver->setup)
> @@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
> *driver)
>
> mutex_lock(_lock);
> list_for_each_entry(udc, _list, list) {
> + udc_count++;
> +
> /* For now we take the first one */
> if (!udc->driver)
> goto found;
> }
>
> - printf("couldn't find an available UDC\n");
> + if (!udc_count)
> + printf("No UDC available in the system\n");
> + else
> + /* When this happens, users should 'unbind '
> + * using the output of 'dm tree' and looking at the line right
> + * after the USB peripheral/device controller.
> + */
> + printf("All UDCs in use (%d available), use the unbind
> command\n",
> +udc_count);
> mutex_unlock(_lock);
> return -ENODEV;
> found:
> --
> 2.34.1
Re: [PATCH RESEND v2 1/2] cmd: bind: Try to improve the (un)bind help
On lun., oct. 02, 2023 at 15:46, Miquel Raynal wrote: > While it may sound totally obvious for the regular U-Boot developer to > get the parameters of the bind/unbind commands from the output of 'dm > tree', it did not felt straightforward to me until I was explicitly > told to look there. And even when I knew the command, I did not make a > direct link between the arguments of this command and the columns > returned by 'dm tree'. > > Several of us lost a lot of time because of that, I would like to kindly > help other users by slightly improving this textual line. Unfortunately, > because of how this string is used (like within the 'help' command) I > cannot detail much more, but at least the pointer is there. > > Signed-off-by: Miquel Raynal Reviewed-by: Mattijs Korpershoek > --- > Resend: no change. > > Changes in v2: > * Moved the details in the long text section as suggested by Heinrich. > * Rephrased the help text as well, not fully following Heinrich > suggestion, but taking inspiration from it. > --- > cmd/bind.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/cmd/bind.c b/cmd/bind.c > index 4d1b7885e60..be0d4d2a711 100644 > --- a/cmd/bind.c > +++ b/cmd/bind.c > @@ -246,6 +246,8 @@ U_BOOT_CMD( > "Bind a device to a driver", > " \n" > "bind \n" > + "Use 'dm tree' to list all devices registered in the driver model,\n" > + "their path, class, index and current driver.\n" > ); > > U_BOOT_CMD( > @@ -254,4 +256,6 @@ U_BOOT_CMD( > "\n" > "unbind \n" > "unbind \n" > + "Use 'dm tree' to list all devices registered in the driver model,\n" > + "their path, class, index and current driver.\n" > ); > -- > 2.34.1
Re: [PATCH v1] drivers: sm: fix build warning
On 05/10/2023 10:19, Alexey Romanov wrote:
This fixes following warning during u-boot build:
WARNING: unmet direct dependencies detected for MESON_SM
Depends on [n]: SM [=n]
Selected by [y]:
- MESON64_COMMON [=y] && ARM [=y] && ARCH_MESON [=y]
Fixes: 9849712e7655 ("drivers: introduce Meson Secure Monitor driver")
Signed-off-by: Alexey Romanov
Signed-off-by: Igor Prusov
---
drivers/sm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/sm/Kconfig b/drivers/sm/Kconfig
index b4cc3f768e..f0987275d2 100644
--- a/drivers/sm/Kconfig
+++ b/drivers/sm/Kconfig
@@ -3,7 +3,7 @@ config SM
config MESON_SM
bool "Amlogic Secure Monitor driver"
- depends on SM
+ select SM
default n
help
Say y here to enable the Amlogic secure monitor driver.
Thanks,
Squashed into 9849712e7655 ("drivers: introduce Meson Secure Monitor driver")
Neil
Re: [PATCH 10/16] serial: sh: Add RZ/G2L SCIF support
On 04/10/2023 20:41, Marek Vasut wrote:
> On 10/4/23 18:38, Paul Barker wrote:
>> On Wed, Oct 04, 2023 at 05:17:55PM +0200, Marek Vasut wrote:
>>> On 10/4/23 15:43, Paul Barker wrote:
On Wed, Oct 04, 2023 at 02:26:49PM +0200, Marek Vasut wrote:
> On 10/4/23 10:48, Paul Barker wrote:
>> On 03/10/2023 14:23, Marek Vasut wrote:
>>> On 9/20/23 14:42, Paul Barker wrote:
Extend the existing driver to support the SCIF serial ports on the
Renesas RZ/G2L (R9A07G044) SoC. This also requires us to ensure that
the
relevant reset signal is de-asserted before we try to talk to the SCIF
module.
Signed-off-by: Paul Barker
Reviewed-by: Biju Das
Reviewed-by: Lad Prabhakar
---
arch/arm/mach-rmobile/Kconfig | 1 +
drivers/serial/serial_sh.c| 32
++--
drivers/serial/serial_sh.h| 19 ++-
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-rmobile/Kconfig
b/arch/arm/mach-rmobile/Kconfig
index 973e84fcf7ba..0ab22356aee5 100644
--- a/arch/arm/mach-rmobile/Kconfig
+++ b/arch/arm/mach-rmobile/Kconfig
@@ -77,6 +77,7 @@ config RZG2L
imply RENESAS_SDHI
imply CLK_RZG2L
imply PINCTRL_RZG2L
+ imply SCIF_CONSOLE
help
Enable support for the Renesas RZ/G2L family of SoCs,
including the
the RZ/G2L itself (based on the R9A07G044 SoC).
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 5e543dbf3d58..a2e9a57137a6 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include "serial_sh.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -79,8 +81,16 @@ sh_serial_setbrg_generic(struct uart_port *port,
int clk, int baudrate)
static void handle_error(struct uart_port *port)
{
- sci_in(port, SCxSR);
- sci_out(port, SCxSR, SCxSR_ERROR_CLEAR(port));
+ /* The RZ/G2L datasheet says that error conditions are cleared
by
+ * resetting the error bits in the FSR register to zero.
>>>
>>> Can you be more specific here ?
>>>
>>> It doesn't seem Linux sh-sci.c driver does anything special for G2L, so
>>> is this special case really needed ?
>>
>> On page 1268 of the datasheet (R01UH0914EJ0130 Rev.1.30):
>>
>> "DR is cleared to 0 when DR = 1 is read and then 0 is written to the DR
>> flag."
>>
>> On page 1270:
>>
>> "[Clearing condition]
>> ● When 0 is written to ER after it has been read as 1"
>>
>> So zeros must be written to clear these errors, not ones.
>>
>> We have an open task to investigate the issue in the Linux driver and
>> fix it.
>
> Is the G2L UART broken in Linux ?
Likely yes, but we need to reproduce the issue.
> Does it misbehave in U-Boot ?
Yes, before I changed this, if a framing error occurred it could never
be cleared and the serial port stopped sending/receiving data.
The framing error was triggered by accident by unnecessarily re-doing
pinmuxing for the serial port after TrustedFirmware had already set it
up correctly. Since SCIF0 is wired to an FTDI USB/serial adaptor chip on
the SMARC carrier board, it seems very difficult to trigger a framing
error in any other way, the FTDI chip is too well behaved.
>>>
>>> Is it possible to trigger this on RZ/G2 with SCIF on those platforms
>>> as well ?
>>
>> It's not been seen or reported to my knowledge, but it's on our list to
>> look into further.
>
> Can you give it a quick try ? I'd really like to avoid G2L specific
> behavior here if it can be avoided.
>
> Is there a testcase ?
The case we're interested in here is the Receive Error (ER) & Break
Detect (BRK) conditions. I've done some further datasheet digging...
RZ/G2L datasheet says these are cleared by writing zero to the
appropriate bits of the FSR register.
RZ/G2{H,M,N,E} datasheet says the same (pages 50-18 & 50-19 of
R01UH0808EJ0111 Rev.1.11).
The R-Car Gen3 Hardware Manual says the same (pages 55-18 & 55-19 of
R19UH0105EJ0230 Rev.2.30).
For R-Car S4, there is an Excel spreadsheet attached to page 105-5 of
the datasheet (R19UH0161EJ0100 Rev.1.00) which again says the same.
For R-Car V4H, the relevant info is on pages 105-16 & 105-18 of the
datasheet (R19UH0172EJ0081 Rev.0.81) and says the same.
On the RZ/G2L I was able to reproduce a break condition by changing
pinmux settings after the SCIF interface has been
ZFS support in custom u-boot build...
To all those of concern, I am in need of help regarding building u-boot with ZFS support for the Orange Pi 5 Plus. I have tried working out the following... https://github.com/u-boot/u-boot/blob/22ad69b7987eb4b10221330661db4427e40174fb/doc/README.zfs The URL link above specifies using the board specific config file, which for the Orange Pi 5 Plus is (so I believe) orangepi-build/userpatches/config-default.conf. I therefore edited this file in question with CONFIG_CMD_ZFS="yes" and uncommenting the line install_zfs="yes". However, it still does not allow me to boot with root ZFS on the NVMe SSD with the official Orange Pi Debian v12 (Bookwork) ARM image. ZFS does not seem to be referenced in the custom u-boot source code build output as well. I followed the build instructions located at the following URL link... http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus#Compile_u-boot ...but am I required to apply a patch to the u-boot source for ZFS support? If so, then that could be my problem. If a patch is required, then how would I go about applying this accordingly? Thank you in advance for help in this matter. Kindest regards, -Stacey Pellegrino
[PATCH v3 7/8] dwc3: add support for Amlogic A1 family
Now the driver supports also A1 phy layer.
Signed-off-by: Alexey Romanov
Reviewed-by: Neil Armstrong
---
drivers/usb/dwc3/dwc3-meson-g12a.c | 79 ++
1 file changed, 69 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c
b/drivers/usb/dwc3/dwc3-meson-g12a.c
index dc5a976f71..e0356e653f 100644
--- a/drivers/usb/dwc3/dwc3-meson-g12a.c
+++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
/* USB2 Ports Control Registers */
@@ -103,10 +104,22 @@ enum {
PHY_COUNT,
};
-static const char *phy_names[PHY_COUNT] = {
+static const char *const dwc3_meson_g12a_phy_names[] = {
"usb2-phy0", "usb2-phy1", "usb3-phy0",
};
+static const char *const dwc3_meson_a1_phy_names[] = {
+ "usb2-phy0", "usb2-phy1"
+};
+
+struct dwc3_meson_g12a;
+
+struct dwc3_meson_g12a_drvdata {
+ const char *const *phy_names;
+ unsigned int phy_cnt;
+ int (*clk_init)(struct dwc3_meson_g12a *priv);
+};
+
struct dwc3_meson_g12a {
struct udevice *dev;
struct regmap *regmap;
@@ -120,6 +133,7 @@ struct dwc3_meson_g12a {
#if CONFIG_IS_ENABLED(DM_REGULATOR)
struct udevice *vbus_supply;
#endif
+ struct dwc3_meson_g12a_drvdata *drvdata;
};
#define U2P_REG_SIZE 0x20
@@ -294,10 +308,11 @@ int dwc3_meson_g12a_force_mode(struct udevice *dev, enum
usb_dr_mode mode)
static int dwc3_meson_g12a_get_phys(struct dwc3_meson_g12a *priv)
{
+ struct dwc3_meson_g12a_drvdata *data = priv->drvdata;
int i, ret;
- for (i = 0 ; i < PHY_COUNT ; ++i) {
- ret = generic_phy_get_by_name(priv->dev, phy_names[i],
+ for (i = 0 ; i < data->phy_cnt; ++i) {
+ ret = generic_phy_get_by_name(priv->dev, data->phy_names[i],
>phys[i]);
if (ret == -ENOENT || ret == -ENODATA)
continue;
@@ -355,18 +370,36 @@ static int dwc3_meson_g12a_clk_init(struct
dwc3_meson_g12a *priv)
return 0;
}
+static int dwc3_meson_a1_clk_init(struct dwc3_meson_g12a *priv)
+{
+ int ret;
+
+ ret = clk_get_by_name(priv->dev, "usb_bus", >clk);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(>clk);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
static int dwc3_meson_g12a_probe(struct udevice *dev)
{
struct dwc3_meson_g12a *priv = dev_get_plat(dev);
+ struct dwc3_meson_g12a_drvdata *data =
+ (struct dwc3_meson_g12a_drvdata *)dev_get_driver_data(dev);
int ret, i;
+ priv->drvdata = data;
priv->dev = dev;
ret = regmap_init_mem(dev_ofnode(dev), >regmap);
if (ret)
return ret;
- ret = dwc3_meson_g12a_clk_init(priv);
+ ret = data->clk_init(priv);
if (ret)
return ret;
@@ -399,7 +432,7 @@ static int dwc3_meson_g12a_probe(struct udevice *dev)
if (ret)
return ret;
- for (i = 0 ; i < PHY_COUNT ; ++i) {
+ for (i = 0 ; i < data->phy_cnt; ++i) {
if (!priv->phys[i].dev)
continue;
@@ -408,7 +441,7 @@ static int dwc3_meson_g12a_probe(struct udevice *dev)
goto err_phy_init;
}
- for (i = 0; i < PHY_COUNT; ++i) {
+ for (i = 0; i < data->phy_cnt; ++i) {
if (!priv->phys[i].dev)
continue;
@@ -420,7 +453,7 @@ static int dwc3_meson_g12a_probe(struct udevice *dev)
return 0;
err_phy_init:
- for (i = 0 ; i < PHY_COUNT ; ++i) {
+ for (i = 0 ; i < data->phy_cnt ; ++i) {
if (!priv->phys[i].dev)
continue;
@@ -433,20 +466,21 @@ err_phy_init:
static int dwc3_meson_g12a_remove(struct udevice *dev)
{
struct dwc3_meson_g12a *priv = dev_get_plat(dev);
+ struct dwc3_meson_g12a_drvdata *data = priv->drvdata;
int i;
reset_release_all(>reset, 1);
clk_release_all(>clk, 1);
- for (i = 0; i < PHY_COUNT; ++i) {
+ for (i = 0; i < data->phy_cnt; ++i) {
if (!priv->phys[i].dev)
continue;
generic_phy_power_off(>phys[i]);
}
- for (i = 0 ; i < PHY_COUNT ; ++i) {
+ for (i = 0 ; i < data->phy_cnt; ++i) {
if (!priv->phys[i].dev)
continue;
@@ -456,11 +490,26 @@ static int dwc3_meson_g12a_remove(struct udevice *dev)
return dm_scan_fdt_dev(dev);
}
+static const struct dwc3_meson_g12a_drvdata meson_g12a_drvdata = {
+ .phy_names = dwc3_meson_g12a_phy_names,
+ .phy_cnt = ARRAY_SIZE(dwc3_meson_g12a_phy_names),
+ .clk_init = dwc3_meson_g12a_clk_init,
+};
+
+static const struct dwc3_meson_g12a_drvdata meson_a1_drvdata = {
+ .phy_names =
[PATCH v3 8/8] ad401: enable USB stack
Currently we have all drivers for use USB stack on A1-series SoC's. Let's enable USB options for the Amlogic AD401 reference A1 SoC board. Signed-off-by: Alexey Romanov Reviewed-by: Neil Armstrong --- configs/ad401_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/ad401_defconfig b/configs/ad401_defconfig index 31752cc7f5..b9aca3ab0d 100644 --- a/configs/ad401_defconfig +++ b/configs/ad401_defconfig @@ -51,4 +51,7 @@ CONFIG_DEBUG_UART_SKIP_INIT=y CONFIG_MESON_SERIAL=y CONFIG_SPI=y CONFIG_DM_SPI=y +CONFIG_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_GADGET=y CONFIG_WDT=y -- 2.25.1
[PATCH v3 5/8] phy: support Amlogic A1 family
Setting G12A and A1 is similar, so we can use G12A phy
driver with little changes.
Signed-off-by: Alexey Romanov
Reviewed-by: Neil Armstrong
---
drivers/phy/Kconfig | 2 +-
drivers/phy/meson-g12a-usb2.c | 79 ---
2 files changed, 66 insertions(+), 15 deletions(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 8ac5769ed9..60138beca4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -200,7 +200,7 @@ config MESON_GXL_USB_PHY
config MESON_G12A_USB_PHY
bool "Amlogic Meson G12A USB PHYs"
- depends on PHY && ARCH_MESON && MESON_G12A
+ depends on PHY && ARCH_MESON && (MESON_G12A || MESON_A1)
imply REGMAP
help
This is the generic phy driver for the Amlogic Meson G12A
diff --git a/drivers/phy/meson-g12a-usb2.c b/drivers/phy/meson-g12a-usb2.c
index 2ea0498f86..4ba3992bda 100644
--- a/drivers/phy/meson-g12a-usb2.c
+++ b/drivers/phy/meson-g12a-usb2.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -147,18 +148,28 @@
#define RESET_COMPLETE_TIME1000
#define PLL_RESET_COMPLETE_TIME100
+enum meson_soc_id {
+ MESON_SOC_A1,
+ MESON_SOC_G12A,
+};
+
struct phy_meson_g12a_usb2_priv {
struct regmap *regmap;
#if CONFIG_IS_ENABLED(CLK)
struct clk clk;
#endif
struct reset_ctlreset;
+#if CONFIG_IS_ENABLED(POWER_DOMAIN)
+ struct power_domain pwrdm;
+#endif
+ int soc_id;
};
static int phy_meson_g12a_usb2_init(struct phy *phy)
{
struct udevice *dev = phy->dev;
struct phy_meson_g12a_usb2_priv *priv = dev_get_priv(dev);
+ u32 value;
int ret;
#if CONFIG_IS_ENABLED(CLK)
@@ -197,8 +208,7 @@ static int phy_meson_g12a_usb2_init(struct phy *phy)
FIELD_PREP(PHY_CTRL_R17_MPLL_FILTER_PVT2, 2) |
FIELD_PREP(PHY_CTRL_R17_MPLL_FILTER_PVT1, 9));
- regmap_write(priv->regmap, PHY_CTRL_R18,
- FIELD_PREP(PHY_CTRL_R18_MPLL_LKW_SEL, 1) |
+ value = FIELD_PREP(PHY_CTRL_R18_MPLL_LKW_SEL, 1) |
FIELD_PREP(PHY_CTRL_R18_MPLL_LK_W, 9) |
FIELD_PREP(PHY_CTRL_R18_MPLL_LK_S, 0x27) |
FIELD_PREP(PHY_CTRL_R18_MPLL_PFD_GAIN, 1) |
@@ -210,6 +220,11 @@ static int phy_meson_g12a_usb2_init(struct phy *phy)
FIELD_PREP(PHY_CTRL_R18_MPLL_ADJ_LDO, 1) |
PHY_CTRL_R18_MPLL_ACG_RANGE;
+ if (priv->soc_id == MESON_SOC_A1)
+ value |= PHY_CTRL_R18_MPLL_DCO_CLK_SEL;
+
+ regmap_write(priv->regmap, PHY_CTRL_R18, value);
+
udelay(PLL_RESET_COMPLETE_TIME);
/* UnReset PLL */
@@ -232,13 +247,19 @@ static int phy_meson_g12a_usb2_init(struct phy *phy)
FIELD_PREP(PHY_CTRL_R20_USB2_BGR_VREF_4_0, 0) |
FIELD_PREP(PHY_CTRL_R20_USB2_BGR_DBG_1_0, 0));
- regmap_write(priv->regmap, PHY_CTRL_R4,
- FIELD_PREP(PHY_CTRL_R4_CALIB_CODE_7_0, 0xf) |
- FIELD_PREP(PHY_CTRL_R4_CALIB_CODE_15_8, 0xf) |
- FIELD_PREP(PHY_CTRL_R4_CALIB_CODE_23_16, 0xf) |
- PHY_CTRL_R4_TEST_BYPASS_MODE_EN |
- FIELD_PREP(PHY_CTRL_R4_I_C2L_BIAS_TRIM_1_0, 0) |
- FIELD_PREP(PHY_CTRL_R4_I_C2L_BIAS_TRIM_3_2, 0));
+ if (priv->soc_id == MESON_SOC_G12A)
+ regmap_write(priv->regmap, PHY_CTRL_R4,
+ FIELD_PREP(PHY_CTRL_R4_CALIB_CODE_7_0, 0xf) |
+ FIELD_PREP(PHY_CTRL_R4_CALIB_CODE_15_8, 0xf) |
+ FIELD_PREP(PHY_CTRL_R4_CALIB_CODE_23_16, 0xf) |
+ PHY_CTRL_R4_TEST_BYPASS_MODE_EN |
+ FIELD_PREP(PHY_CTRL_R4_I_C2L_BIAS_TRIM_1_0, 0) |
+ FIELD_PREP(PHY_CTRL_R4_I_C2L_BIAS_TRIM_3_2, 0));
+ else if (priv->soc_id == MESON_SOC_A1)
+ regmap_write(priv->regmap, PHY_CTRL_R21,
+ PHY_CTRL_R21_USB2_CAL_ACK_EN |
+ PHY_CTRL_R21_USB2_TX_STRG_PD |
+ FIELD_PREP(PHY_CTRL_R21_USB2_OTG_ACA_TRIM_1_0, 2));
/* Tuning Disconnect Threshold */
regmap_write(priv->regmap, PHY_CTRL_R3,
@@ -247,10 +268,15 @@ static int phy_meson_g12a_usb2_init(struct phy *phy)
FIELD_PREP(PHY_CTRL_R3_DISC_THRESH, 3));
/* Analog Settings */
- regmap_write(priv->regmap, PHY_CTRL_R14, 0);
- regmap_write(priv->regmap, PHY_CTRL_R13,
- PHY_CTRL_R13_UPDATE_PMA_SIGNALS |
- FIELD_PREP(PHY_CTRL_R13_MIN_COUNT_FOR_SYNC_DET, 7));
+ if (priv->soc_id == MESON_SOC_G12A) {
+ regmap_write(priv->regmap, PHY_CTRL_R14, 0);
+ regmap_write(priv->regmap, PHY_CTRL_R13,
+ PHY_CTRL_R13_UPDATE_PMA_SIGNALS |
+ FIELD_PREP(PHY_CTRL_R13_MIN_COUNT_FOR_SYNC_DET, 7));
+ } else if
[PATCH v3 6/8] a1: clk: Add missing USB_PHY_IN and USB_PHY gates
From: Igor Prusov
We use this clocks in dwc3 driver.
Signed-off-by: Igor Prusov
Signed-off-by: Alexey Romanov
Reviewed-by: Neil Armstrong
---
drivers/clk/meson/a1.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/meson/a1.c b/drivers/clk/meson/a1.c
index 3aec42f33b..1075ba7333 100644
--- a/drivers/clk/meson/a1.c
+++ b/drivers/clk/meson/a1.c
@@ -238,6 +238,12 @@ static const struct meson_clk_info *meson_clocks[] = {
[CLKID_FIXPLL_IN] = CLK_GATE("fixpll_in", A1_SYS_OSCIN_CTRL, 1,
EXTERNAL_XTAL
),
+ [CLKID_USB_PHY_IN] = CLK_GATE("usb_phy_in", A1_SYS_OSCIN_CTRL, 2,
+ EXTERNAL_XTAL
+ ),
+ [CLKID_USB_PHY] = CLK_GATE("usb_phy", A1_SYS_CLK_EN0, 27,
+ CLKID_SYS
+ ),
[CLKID_SARADC] = CLK_GATE("saradc", A1_SAR_ADC_CLK_CTR, 8,
-ENOENT
),
--
2.25.1
[PATCH v3 3/8] phy: get rid of raw hex values
It is better to use defines instead of write raw hex values in regmap. Signed-off-by: Alexey Romanov Reviewed-by: Neil Armstrong --- drivers/phy/meson-g12a-usb2.c | 161 -- 1 file changed, 153 insertions(+), 8 deletions(-) diff --git a/drivers/phy/meson-g12a-usb2.c b/drivers/phy/meson-g12a-usb2.c index 8b24322515..a803b6796c 100644 --- a/drivers/phy/meson-g12a-usb2.c +++ b/drivers/phy/meson-g12a-usb2.c @@ -24,12 +24,28 @@ #include #include +#include #define PHY_CTRL_R00x0 #define PHY_CTRL_R10x4 #define PHY_CTRL_R20x8 + #define PHY_CTRL_R30xc + #define PHY_CTRL_R3_SQUELCH_REF GENMASK(1, 0) + #define PHY_CTRL_R3_HSDIC_REF GENMASK(3, 2) + #define PHY_CTRL_R3_DISC_THRESH GENMASK(7, 4) + #define PHY_CTRL_R40x10 + #define PHY_CTRL_R4_CALIB_CODE_7_0 GENMASK(7, 0) + #define PHY_CTRL_R4_CALIB_CODE_15_8 GENMASK(15, 8) + #define PHY_CTRL_R4_CALIB_CODE_23_16GENMASK(23, 16) + #define PHY_CTRL_R4_I_C2L_CAL_ENBIT(24) + #define PHY_CTRL_R4_I_C2L_CAL_RESET_N BIT(25) + #define PHY_CTRL_R4_I_C2L_CAL_DONE BIT(26) + #define PHY_CTRL_R4_TEST_BYPASS_MODE_EN BIT(27) + #define PHY_CTRL_R4_I_C2L_BIAS_TRIM_1_0 GENMASK(29, 28) + #define PHY_CTRL_R4_I_C2L_BIAS_TRIM_3_2 GENMASK(31, 30) + #define PHY_CTRL_R50x14 #define PHY_CTRL_R60x18 #define PHY_CTRL_R70x1c @@ -38,15 +54,93 @@ #define PHY_CTRL_R10 0x28 #define PHY_CTRL_R11 0x2c #define PHY_CTRL_R12 0x30 + #define PHY_CTRL_R13 0x34 + #define PHY_CTRL_R13_CUSTOM_PATTERN_19 GENMASK(7, 0) + #define PHY_CTRL_R13_LOAD_STAT BIT(14) + #define PHY_CTRL_R13_UPDATE_PMA_SIGNALS BIT(15) + #define PHY_CTRL_R13_MIN_COUNT_FOR_SYNC_DET GENMASK(20, 16) + #define PHY_CTRL_R13_CLEAR_HOLD_HS_DISCONNECT BIT(21) + #define PHY_CTRL_R13_BYPASS_HOST_DISCONNECT_VAL BIT(22) + #define PHY_CTRL_R13_BYPASS_HOST_DISCONNECT_EN BIT(23) + #define PHY_CTRL_R13_I_C2L_HS_ENBIT(24) + #define PHY_CTRL_R13_I_C2L_FS_ENBIT(25) + #define PHY_CTRL_R13_I_C2L_LS_ENBIT(26) + #define PHY_CTRL_R13_I_C2L_HS_OEBIT(27) + #define PHY_CTRL_R13_I_C2L_FS_OEBIT(28) + #define PHY_CTRL_R13_I_C2L_HS_RX_EN BIT(29) + #define PHY_CTRL_R13_I_C2L_FSLS_RX_EN BIT(30) + #define PHY_CTRL_R14 0x38 #define PHY_CTRL_R15 0x3c + #define PHY_CTRL_R16 0x40 + #define PHY_CTRL_R16_MPLL_M GENMASK(8, 0) + #define PHY_CTRL_R16_MPLL_N GENMASK(14, 10) + #define PHY_CTRL_R16_MPLL_TDC_MODE BIT(20) + #define PHY_CTRL_R16_MPLL_SDM_ENBIT(21) + #define PHY_CTRL_R16_MPLL_LOAD BIT(22) + #define PHY_CTRL_R16_MPLL_DCO_SDM_ENBIT(23) + #define PHY_CTRL_R16_MPLL_LOCK_LONG GENMASK(25, 24) + #define PHY_CTRL_R16_MPLL_LOCK_FBIT(26) + #define PHY_CTRL_R16_MPLL_FAST_LOCK BIT(27) + #define PHY_CTRL_R16_MPLL_ENBIT(28) + #define PHY_CTRL_R16_MPLL_RESET BIT(29) + #define PHY_CTRL_R16_MPLL_LOCK BIT(30) + #define PHY_CTRL_R16_MPLL_LOCK_DIG BIT(31) + #define PHY_CTRL_R17 0x44 + #define PHY_CTRL_R17_MPLL_FRAC_IN GENMASK(13, 0) + #define PHY_CTRL_R17_MPLL_FIX_ENBIT(16) + #define PHY_CTRL_R17_MPLL_LAMBDA1 GENMASK(19, 17) + #define PHY_CTRL_R17_MPLL_LAMBDA0 GENMASK(22, 20) + #define PHY_CTRL_R17_MPLL_FILTER_MODE BIT(23) + #define PHY_CTRL_R17_MPLL_FILTER_PVT2 GENMASK(27, 24) +
[PATCH v3 4/8] phy: move clk enable/disable in init/exit
It is better to place clk_enable() in phy_meson_g12a_usb2_init()
and clk_disable() in phy_meson_g12a_usb2_exit().
For more detailed information, please see comments in the review of
a similar driver in the Linux Kernel:
https://lore.kernel.org/all/CAFBinCCEhobbyKHuKDWzTYCQWgNT1-e8=7hmhq1mvt6cueo...@mail.gmail.com/
Signed-off-by: Alexey Romanov
Reviewed-by: Neil Armstrong
---
drivers/phy/meson-g12a-usb2.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/meson-g12a-usb2.c b/drivers/phy/meson-g12a-usb2.c
index a803b6796c..2ea0498f86 100644
--- a/drivers/phy/meson-g12a-usb2.c
+++ b/drivers/phy/meson-g12a-usb2.c
@@ -161,6 +161,14 @@ static int phy_meson_g12a_usb2_init(struct phy *phy)
struct phy_meson_g12a_usb2_priv *priv = dev_get_priv(dev);
int ret;
+#if CONFIG_IS_ENABLED(CLK)
+ ret = clk_enable(>clk);
+ if (ret && ret != -ENOSYS && ret != -ENOTSUPP) {
+ pr_err("failed to enable PHY clock\n");
+ return ret;
+ }
+#endif
+
ret = reset_assert(>reset);
udelay(1);
ret |= reset_deassert(>reset);
@@ -253,6 +261,10 @@ static int phy_meson_g12a_usb2_exit(struct phy *phy)
struct phy_meson_g12a_usb2_priv *priv = dev_get_priv(dev);
int ret;
+#if CONFIG_IS_ENABLED(CLK)
+ clk_disable(>clk);
+#endif
+
ret = reset_assert(>reset);
if (ret)
return ret;
@@ -290,13 +302,6 @@ int meson_g12a_usb2_phy_probe(struct udevice *dev)
ret = clk_get_by_index(dev, 0, >clk);
if (ret < 0)
return ret;
-
- ret = clk_enable(>clk);
- if (ret && ret != -ENOSYS && ret != -ENOTSUPP) {
- pr_err("failed to enable PHY clock\n");
- clk_free(>clk);
- return ret;
- }
#endif
return 0;
--
2.25.1
[PATCH v3 2/8] reset: add support for Amlogic A1 family
This patch adds reset support for the Amlogic A1 family.
We add the structure meson_reset_drvdata, which in the future
will allow this driver to be used for other families by declaring
only the correct parameters reg_count and level_offset.
Signed-off-by: Alexey Romanov
Reviewed-by: Neil Armstrong
---
drivers/reset/reset-meson.c | 42 +++--
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
index 64bc696f13..9d0c8b354f 100644
--- a/drivers/reset/reset-meson.c
+++ b/drivers/reset/reset-meson.c
@@ -13,18 +13,26 @@
#include
#include
#include
+#include
-#define REG_COUNT 8
#define BITS_PER_REG 32
-#define LEVEL_OFFSET 0x7c
+
+struct meson_reset_drvdata {
+ unsigned int reg_count;
+ unsigned int level_offset;
+};
struct meson_reset_priv {
struct regmap *regmap;
+ struct meson_reset_drvdata *drvdata;
};
static int meson_reset_request(struct reset_ctl *reset_ctl)
{
- if (reset_ctl->id > (REG_COUNT * BITS_PER_REG))
+ struct meson_reset_priv *priv = dev_get_priv(reset_ctl->dev);
+ struct meson_reset_drvdata *data = priv->drvdata;
+
+ if (reset_ctl->id > (data->reg_count * BITS_PER_REG))
return -EINVAL;
return 0;
@@ -33,9 +41,10 @@ static int meson_reset_request(struct reset_ctl *reset_ctl)
static int meson_reset_level(struct reset_ctl *reset_ctl, bool assert)
{
struct meson_reset_priv *priv = dev_get_priv(reset_ctl->dev);
+ struct meson_reset_drvdata *data = priv->drvdata;
uint bank = reset_ctl->id / BITS_PER_REG;
uint offset = reset_ctl->id % BITS_PER_REG;
- uint reg_offset = LEVEL_OFFSET + (bank << 2);
+ uint reg_offset = data->level_offset + (bank << 2);
uint val;
regmap_read(priv->regmap, reg_offset, );
@@ -64,15 +73,36 @@ struct reset_ops meson_reset_ops = {
.rst_deassert = meson_reset_deassert,
};
+static const struct meson_reset_drvdata meson_gxbb_data = {
+ .reg_count = 8,
+ .level_offset = 0x7c,
+};
+
+static const struct meson_reset_drvdata meson_a1_data = {
+ .reg_count = 3,
+ .level_offset = 0x40,
+};
+
static const struct udevice_id meson_reset_ids[] = {
- { .compatible = "amlogic,meson-gxbb-reset" },
- { .compatible = "amlogic,meson-axg-reset" },
+ {
+ .compatible = "amlogic,meson-gxbb-reset",
+ .data = (ulong)_gxbb_data,
+ },
+ {
+ .compatible = "amlogic,meson-axg-reset",
+ .data = (ulong)_gxbb_data,
+ },
+ {
+ .compatible = "amlogic,meson-a1-reset",
+ .data = (ulong)_a1_data,
+ },
{ }
};
static int meson_reset_probe(struct udevice *dev)
{
struct meson_reset_priv *priv = dev_get_priv(dev);
+ priv->drvdata = (struct meson_reset_drvdata *)dev_get_driver_data(dev);
return regmap_init_mem(dev_ofnode(dev), >regmap);
}
--
2.25.1
[PATCH v3 1/8] dt-bindings: reset: add Meson A1 reset bindings
Get this from Linux 6.6-rc3. Signed-off-by: Alexey Romanov Reviewed-by: Neil Armstrong --- .../reset/amlogic,meson-a1-reset.h| 76 +++ 1 file changed, 76 insertions(+) create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-reset.h diff --git a/include/dt-bindings/reset/amlogic,meson-a1-reset.h b/include/dt-bindings/reset/amlogic,meson-a1-reset.h new file mode 100644 index 00..2c749c655e --- /dev/null +++ b/include/dt-bindings/reset/amlogic,meson-a1-reset.h @@ -0,0 +1,76 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (c) 2019 Amlogic, Inc. All rights reserved. + * Author: Xingyu Chen + * + * Copyright (c) 2023, SberDevices, Inc. + * Author: Alexey Romanov + */ + +#ifndef _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H +#define _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H + +/* RESET0 */ +/* 0 */ +#define RESET_AM2AXI_VAD 1 +/* 2-3 */ +#define RESET_PSRAM4 +#define RESET_PAD_CTRL 5 +/* 6 */ +#define RESET_TEMP_SENSOR 7 +#define RESET_AM2AXI_DEV 8 +/* 9 */ +#define RESET_SPICC_A 10 +#define RESET_MSR_CLK 11 +#define RESET_AUDIO12 +#define RESET_ANALOG_CTRL 13 +#define RESET_SAR_ADC 14 +#define RESET_AUDIO_VAD15 +#define RESET_CEC 16 +#define RESET_PWM_EF 17 +#define RESET_PWM_CD 18 +#define RESET_PWM_AB 19 +/* 20 */ +#define RESET_IR_CTRL 21 +#define RESET_I2C_S_A 22 +/* 23 */ +#define RESET_I2C_M_D 24 +#define RESET_I2C_M_C 25 +#define RESET_I2C_M_B 26 +#define RESET_I2C_M_A 27 +#define RESET_I2C_PROD_AHB 28 +#define RESET_I2C_PROD 29 +/* 30-31 */ + +/* RESET1 */ +#define RESET_ACODEC 32 +#define RESET_DMA 33 +#define RESET_SD_EMMC_A34 +/* 35 */ +#define RESET_USBCTRL 36 +/* 37 */ +#define RESET_USBPHY 38 +/* 39-41 */ +#define RESET_RSA 42 +#define RESET_DMC 43 +/* 44 */ +#define RESET_IRQ_CTRL 45 +/* 46 */ +#define RESET_NIC_VAD 47 +#define RESET_NIC_AXI 48 +#define RESET_RAMA 49 +#define RESET_RAMB 50 +/* 51-52 */ +#define RESET_ROM 53 +#define RESET_SPIFC54 +#define RESET_GIC 55 +#define RESET_UART_C 56 +#define RESET_UART_B 57 +#define RESET_UART_A 58 +#define RESET_OSC_RING 59 +/* 60-63 */ + +/* RESET2 */ +/* 64-95 */ + +#endif -- 2.25.1
[PATCH v3 0/8] Support USB for Meson A1
Hello! This patchset adds USB stack support for Amlogic A1 SoC's series. Made reset / phy / dwc3 drivers more flexible and added support for A1 board. V2: - Made power domain for PHY optional. - Add missing CLKID_USB_PHY gate. - Drop patch with USB stack initialization in board-a1.c. Instead of, enable CONFIG_DM_USB_GADGET for AD401 board. - Support A1 in g12a_child_pre_probe/post_remove functions in dwc3 driver. V3: - Rebased over latests Amlogic U-Boot branch. Alexey Romanov (7): dt-bindings: reset: add Meson A1 reset bindings reset: add support for Amlogic A1 family phy: get rid of raw hex values phy: move clk enable/disable in init/exit phy: support Amlogic A1 family dwc3: add support for Amlogic A1 family ad401: enable USB stack Igor Prusov (1): a1: clk: Add missing USB_PHY_IN and USB_PHY gates configs/ad401_defconfig | 3 + drivers/clk/meson/a1.c| 6 + drivers/phy/Kconfig | 2 +- drivers/phy/meson-g12a-usb2.c | 235 -- drivers/reset/reset-meson.c | 42 +++- drivers/usb/dwc3/dwc3-meson-g12a.c| 79 +- .../reset/amlogic,meson-a1-reset.h| 76 ++ 7 files changed, 409 insertions(+), 34 deletions(-) create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-reset.h -- 2.25.1
[PATCH v1] drivers: sm: fix build warning
This fixes following warning during u-boot build:
WARNING: unmet direct dependencies detected for MESON_SM
Depends on [n]: SM [=n]
Selected by [y]:
- MESON64_COMMON [=y] && ARM [=y] && ARCH_MESON [=y]
Fixes: 9849712e7655 ("drivers: introduce Meson Secure Monitor driver")
Signed-off-by: Alexey Romanov
Signed-off-by: Igor Prusov
---
drivers/sm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/sm/Kconfig b/drivers/sm/Kconfig
index b4cc3f768e..f0987275d2 100644
--- a/drivers/sm/Kconfig
+++ b/drivers/sm/Kconfig
@@ -3,7 +3,7 @@ config SM
config MESON_SM
bool "Amlogic Secure Monitor driver"
- depends on SM
+ select SM
default n
help
Say y here to enable the Amlogic secure monitor driver.
--
2.25.1
[RFC PATCH] clk: scmi: Provide channel information to every clock
When assigned-clocks/assigned-clock-rates is defined U-Boot DM core finds out leaf which is registered via clk_register(). But new clock doesn't have information about channel which is stored in private data. That's why copy parents private data (channel only now) to all childs. It will fix the issue when there is reference to clk child and operations with it. Signed-off-by: Michal Simek --- I am not really sure that this is the right way how to solve this problem. I had another patch which is pretty much written in a way if current device doesn't have private data it looks at parents private data. Anyway I am sending it as RFC to start to have discussion about it. --- drivers/clk/clk_scmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c index d172fed24c9d..98a779fdc81b 100644 --- a/drivers/clk/clk_scmi.c +++ b/drivers/clk/clk_scmi.c @@ -12,6 +12,7 @@ #include #include #include +#include /** * struct scmi_clk_priv - Private data for SCMI clocks @@ -186,6 +187,7 @@ static int scmi_clk_probe(struct udevice *dev) return ret; } + dev_set_priv(clk->dev, dev_get_priv(dev)); clk_dm(i, clk); } } -- 2.36.1
Re: [PATCH v4 2/2] arm: dts: j7200: dts sync with Linux 6.6-rc1
On 11:56-20231004, Reid Tonking wrote:
> Sync j7200 dts with Linux 6.6-rc1
[..]
> diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> index e62f9218e8..9469dca39f 100644
> --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> @@ -1,13 +1,14 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
> + * Copyright (C) 2020-2023 Texas Instruments Incorporated -
> https://www.ti.com/
> */
>
> /dts-v1/;
>
> -#include "k3-j7200-som-p0.dtsi"
> +#include "k3-j7200-common-proc-board.dts"
> #include "k3-j7200-ddr-evm-lp4-2666.dtsi"
> #include "k3-j721e-ddr.dtsi"
> +#include "k3-j7200-common-proc-board-u-boot.dtsi"
>
> / {
> aliases {
> @@ -15,17 +16,6 @@
> remoteproc1 = _0;
> };
>
> - chosen {
> - stdout-path = _uart0;
> - tick-timer =
> - firmware-loader = _loader0;
> - };
> -
> - fs_loader0: fs_loader@0 {
> - bootph-all;
> - compatible = "u-boot,fs-loader";
> - };
> -
> a72_0: a72@0 {
> compatible = "ti,am654-rproc";
> reg = <0x0 0x00a9 0x0 0x10>;
> @@ -39,21 +29,17 @@
> ti,sci = <>;
> ti,sci-proc-id = <32>;
> ti,sci-host-id = <10>;
> - bootph-pre-ram;
> - };
> -
> - clk_200mhz: dummy_clock_200mhz {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <2>;
> - bootph-pre-ram;
> + bootph-all;
Here and else where in the r5 file: why switch from pre-ram to bootph-all
? dont we need these prior to ddr initialization?
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] arm: dts: k3-am625-beagleplay: Fix boot
On 06:18-20231005, Jan Kiszka wrote:
> On 04.10.23 14:15, Nishanth Menon wrote:
> > On 22:26-20231003, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> Since commit [1] A53 u-boot proper is broken. This is because nodes
> >> marked as 'bootph-pre-ram' are not available at u-boot proper before
> >> relocation.
> >>
> >> To fix this we mark all nodes as 'bootph-all'.
> >>
> >> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
> >> after relocation")
> >>
> >> Signed-off-by: Jan Kiszka
> >> ---
> >>
> >> This may overshoot, but at least the board boots again. Could it be that
> >> [1] broke even more boards?
> >
> > Jan:
> > https://lore.kernel.org/all/b1c62a7d-a90e-4212-8972-9b622e147...@kernel.org/
> >
> > I got boot without r5-beagleplay.dts modified. and it is in line with
> > the changes in linux-next commit 944adefc7f88 ("arm64: dts: ti:
> > k3-am625-beagleplay: Add boot phase tags marking")
> >
>
> Yeah, no problem, missed that.
>
> Meanwhile, I can fix our IOT2050 because I was unfortunatenly right:
> more havoc in sight. Did anyone tried to look at the fallouts
> systematically already? Is it only affecting the TI family?
>
I know all of TI K3 platforms are broken, but I don't think (based on
discussions on the list so far), anyone actually went around non-TI
platforms to identify the ones that are broken.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 10:29-20231005, Manorit Chawdhry wrote: > Hi Nishanth, > > On 07:24-20231004, Nishanth Menon wrote: > > On 10:43-20231004, Manorit Chawdhry wrote: > > > > > These are required to remove the firewall configurations that are done > > > by ROM, those are not the ones that are being handled by OIDs. The > > > > I am not sure I understand this clearly. OIDs are setup to open up > > firewalls or close firewalls as the system requires and since it > > is authenticated, not compromiseable.- U-boot by itself (even if > > authenticated), is not a secure entity for it to dictate the firewall > > configuration (u-boot must be assumed to be compromised after > > authentication is complete). So, doing firewall configuration via APIs > > after boot, to me looks broken approach. > > > > I know U-boot ain't that secure given the most trusted entity is always > gonna be the software that starts up the system, we can't expect those > to be doing all the work and based on that we have the secure boot > designed to configure firewalls (that are not owned by anymore) and > U-boot R5 being one of the early bootloaders do come as a part of it. > > Regarding the OIDs thing, I don't think the OID in question is looked by > ROM and ROM always configures some firewalls for it's usecase that are > present in those arrays. > > The OID that we are using in the series that you had shared is looked by > TIFS instead of ROM and TIFS is the entity that is authenticating the > binary along with setting up the firewalls. > > > > current series that is being worked on is to add additional firewalling > > > support with OIDs that TIFS will be handling. > > > The above patch is > > > essentially added to have the same development experience on GP devices > > > similar to HS after the secure boot is done so that people don't end up > > > > huh? the code seems to blindly call the > > remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); > > where is the distinction of HS vs GP here? This implementation looks > > completely broken to me at least.. please correct what I missed here. > > Since this call is used across all SoCs there wasn't any point to make > the differentiation between GP and HS here, remove_fwl_configs > internally handles looking at the firewalls and disabling them if they > are enabled ( Which would be only in the case of HS devices ), for GP it > would automatically by a noop. Correct me if I understand the security chain here: ROM sets up firewalls that are needed by itself TIFS (in multicertificate will setup it's own firewalls) R5 SPL comes along and opens up other firewalls Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to set up firewalls to protect themselves (enforced by TIFS) A53 SPL and U-boot itself startups but has no ability to change the protection firewalls enforced by x509 OIDs. Further, firewalls have lockdown bit that enforces the setting (and cannot be over-ridden) till system restart is requested Is this correct? If so, needs to be clearly documented. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm: dts: k3-am65-iot2050: Fix boot
On 06:37-20231005, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Since commit [1] A53 u-boot proper is broken. This is because nodes
> marked as 'bootph-pre-ram' are not available at u-boot proper before
> relocation.
>
> To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.
>
> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
> after relocation")
>
> Signed-off-by: Jan Kiszka
Reviewed-by: Nishanth Menon
> ---
> .../dts/k3-am65-iot2050-common-u-boot.dtsi| 44 +--
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
> b/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
> index 9fd64809a63..30fc7a78d89 100644
> --- a/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
> @@ -37,18 +37,18 @@
> };
>
> leds {
> - bootph-pre-ram;
> + bootph-all;
> status-led-red {
> - bootph-pre-ram;
> + bootph-all;
> };
> status-led-green {
> - bootph-pre-ram;
> + bootph-all;
> };
> };
> };
>
> _mcu {
> - bootph-pre-ram;
> + bootph-all;
>
> mcu_navss: bus@2838 {
> ringacc@2b80 {
> @@ -75,70 +75,70 @@
> };
>
> _wakeup {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _main {
> - bootph-pre-ram;
> + bootph-all;
> main_navss: bus@3080 {
> - bootph-pre-ram;
> + bootph-all;
> };
> };
>
> _pmx0 {
> - bootph-pre-ram;
> + bootph-all;
> mcu-fss0-ospi0-pins-default {
> - bootph-pre-ram;
> + bootph-all;
> };
> };
>
> _pmx0 {
> - bootph-pre-ram;
> + bootph-all;
> main-uart1-pins-default {
> - bootph-pre-ram;
> + bootph-all;
> };
> };
>
> _uart1 {
> - bootph-pre-ram;
> + bootph-all;
> current-speed = <115200>;
> };
>
> _gpio0 {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> {
> - bootph-pre-ram;
> + bootph-all;
> flash@0 {
> - bootph-pre-ram;
> + bootph-all;
> };
> };
>
> _proxy_main {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> {
> - bootph-pre-ram;
> + bootph-all;
> k3_sysreset: sysreset-controller {
> compatible = "ti,sci-sysreset";
> - bootph-pre-ram;
> + bootph-all;
> };
> };
>
> _pds {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _clks {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> _reset {
> - bootph-pre-ram;
> + bootph-all;
> };
>
> {
> - bootph-pre-ram;
> + bootph-all;
> };
> --
> 2.35.3
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 09/16] pinctrl: renesas: Add RZ/G2L PFC driver
On 10/5/23 11:39, Paul Barker wrote:
On 05/10/2023 03:24, Marek Vasut wrote:
On 10/4/23 21:43, Paul Barker wrote:
[...]
+/*
+ * We need to ensure that the module clock is enabled and all resets are
+ * de-asserted before using either the gpio or pinctrl functionality. Error
+ * handling can be quite simple here as if the PFC cannot be enabled then we
+ * will not be able to progress with the boot anyway.
+ */
+static int rzg2l_pfc_enable(struct udevice *dev)
+{
+ struct rzg2l_pfc_data *data =
+ (struct rzg2l_pfc_data *)dev_get_driver_data(dev);
+ struct reset_ctl_bulk rsts;
+ struct clk clk;
+ int ret;
+
+ if (data->pfc_enabled)
When does this get triggered ?
This is initialised to false in rzg2l_pfc_bind(), then this function
rzg2l_pfc_enable() sets it to true before a successful return. The
effect is that the PFC is enabled just once, regardless of whether the
pinctrl or gpio driver is probed first.
Why would be call to rzg2l_pfc_enable() a problem in the first place ?
It just grabs and enables clock and ungates reset, the second time this is
called the impact on harware should be no-op , right ?
The hw impact is a no-op, but it wastes time unnecessarily re-reading
data from the fdt and repeating the setup, e.g. in rzg2l_cpg_clk_set()
we have to search the array of clocks each time to find the requested
entry.
Does getting clock and enabling them have noticable overhead on this
platform ? Look at CONFIG_OF_LIVE, that should mitigate the DT access
overhead at least.
I've not measured this. I was just assuming that it is sensible to only do the
setup once.
I think it's worth keeping the conditional here but can drop it if
you're really against it.
It feels like fixing a problem at the wrong place really.
I'll drop the pfc_enabled flag and re-test.
You can stick get_timer() before and after the code to get a rough idea
of how long it took, likely it will be 0 .
Thanks
Re: [PATCH v5 05/16] firmware: scmi: implement SCMI base protocol
Hi Etienne,
On Thu, Oct 05, 2023 at 07:06:47AM +, Etienne CARRIERE - foss wrote:
> Hello Akashi-san,
>
>
> > From: U-Boot on behalf of AKASHI Takahiro
> >
> > Sent: Tuesday, September 26, 2023 8:57 AM
> >
> > SCMI base protocol is mandatory according to the SCMI specification.
> >
> > With this patch, SCMI base protocol can be accessed via SCMI transport
> > layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported.
> > This is because U-Boot doesn't support interrupts and the current transport
> > layers are not able to handle asynchronous messages properly.
> >
> > Signed-off-by: AKASHI Takahiro
> > Reviewed-by: Simon Glass
> > ---
> > v3
> > * strncpy (TODO)
> > * remove a duplicated function prototype
> > * use newly-allocated memory when return vendor name or agent name
> > * revise function descriptions in a header
> > v2
> > * add helper functions, removing direct uses of ops
> > * add function descriptions for each of functions in ops
> > ---
>
> This patch v5 looks good to me. 2 suggestions.
>
> Reviewed-by: Etienne Carriere with comments
> addressed or not.
> I have successfully tested the whole PATCH v5 series on my platform.
Thank you for your review and testing.
>
> > drivers/firmware/scmi/Makefile | 1 +
> > drivers/firmware/scmi/base.c | 657 +
> > include/dm/uclass-id.h | 1 +
> > include/scmi_protocols.h | 351 ++
> > 4 files changed, 1010 insertions(+)
> > create mode 100644 drivers/firmware/scmi/base.c
> >
> > diff --git a/drivers/firmware/scmi/Makefile b/drivers/firmware/scmi/Makefile
> > index b2ff483c75a1..1a23d4981709 100644
> > --- a/drivers/firmware/scmi/Makefile
> > +++ b/drivers/firmware/scmi/Makefile
> > @@ -1,4 +1,5 @@
> > obj-y += scmi_agent-uclass.o
> > +obj-y += base.o
> > obj-y += smt.o
> > obj-$(CONFIG_SCMI_AGENT_SMCCC) += smccc_agent.o
> > obj-$(CONFIG_SCMI_AGENT_MAILBOX) += mailbox_agent.o
> > diff --git a/drivers/firmware/scmi/base.c b/drivers/firmware/scmi/base.c
> > new file mode 100644
> > index ..dba143e1ff5d
> > --- /dev/null
> > +++ b/drivers/firmware/scmi/base.c
> > @@ -0,0 +1,657 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * SCMI Base protocol as U-Boot device
> > + *
> > + * Copyright (C) 2023 Linaro Limited
> > + * author: AKASHI Takahiro
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/**
> > + * scmi_generic_protocol_version - get protocol version
> > + * @dev: SCMI device
> > + * @id:SCMI protocol ID
> > + * @version: Pointer to SCMI protocol version
> > + *
> > + * Obtain the protocol version number in @version.
> > + *
> > + * Return: 0 on success, error code on failure
> > + */
> > +int scmi_generic_protocol_version(struct udevice *dev,
> > + enum scmi_std_protocol id, u32 *version)
> > +{
> > + struct scmi_protocol_version_out out;
> > + struct scmi_msg msg = {
> > + .protocol_id = id,
> > + .message_id = SCMI_PROTOCOL_VERSION,
> > + .out_msg = (u8 *),
> > + .out_msg_sz = sizeof(out),
> > + };
> > + int ret;
> > +
> > + ret = devm_scmi_process_msg(dev, );
> > + if (ret)
> > + return ret;
> > + if (out.status)
> > + return scmi_to_linux_errno(out.status);
> > +
> > + *version = out.version;
> > +
> > + return 0;
> > +}
> > +
> > +/**
> > + * scmi_base_protocol_version_int - get Base protocol version
> > + * @dev: SCMI device
> > + * @version: Pointer to SCMI protocol version
> > + *
> > + * Obtain the protocol version number in @version for Base protocol.
> > + *
> > + * Return: 0 on success, error code on failure
> > + */
>
> I think these inline description comment for scmi_base_protocol_xxx_int()
> would better be placed as description for the exported functions
> scmi_base_protocol_xxx() and scmi_base_discover_xxx(). Either in the .c file
> or in the header file.
>
> Especially regarding the function
> scmi_base_discover_vendor()/_discover_sub_vendor()/_discover_agent() where
> caller is responsible for freeing the output string.
Yes, I will add comments.
>
> > +static int scmi_base_protocol_version_int(struct udevice *dev, u32
> > *version)
> > +{
> > + return scmi_generic_protocol_version(dev, SCMI_PROTOCOL_ID_BASE,
> > +version);
> > +}
> > +
> > +/**
> > + * scmi_protocol_attrs_int - get protocol attributes
> > + * @dev: SCMI device
> > + * @num_agents:Number of SCMI agents
> > + * @num_protocols: Number of SCMI protocols
> > + *
> > + * Obtain the protocol attributes, the number of agents and the number
> > + * of protocols, in @num_agents and @num_protocols respectively, that
>
Re: [PATCH 09/16] pinctrl: renesas: Add RZ/G2L PFC driver
On 05/10/2023 03:24, Marek Vasut wrote:
> On 10/4/23 21:43, Paul Barker wrote:
>
> [...]
>
>> +/*
>> + * We need to ensure that the module clock is enabled and all resets are
>> + * de-asserted before using either the gpio or pinctrl functionality.
>> Error
>> + * handling can be quite simple here as if the PFC cannot be enabled
>> then we
>> + * will not be able to progress with the boot anyway.
>> + */
>> +static int rzg2l_pfc_enable(struct udevice *dev)
>> +{
>> +struct rzg2l_pfc_data *data =
>> +(struct rzg2l_pfc_data *)dev_get_driver_data(dev);
>> +struct reset_ctl_bulk rsts;
>> +struct clk clk;
>> +int ret;
>> +
>> +if (data->pfc_enabled)
>
> When does this get triggered ?
This is initialised to false in rzg2l_pfc_bind(), then this function
rzg2l_pfc_enable() sets it to true before a successful return. The
effect is that the PFC is enabled just once, regardless of whether the
pinctrl or gpio driver is probed first.
>>>
>>> Why would be call to rzg2l_pfc_enable() a problem in the first place ?
>>> It just grabs and enables clock and ungates reset, the second time this is
>>> called the impact on harware should be no-op , right ?
>>
>> The hw impact is a no-op, but it wastes time unnecessarily re-reading
>> data from the fdt and repeating the setup, e.g. in rzg2l_cpg_clk_set()
>> we have to search the array of clocks each time to find the requested
>> entry.
>
> Does getting clock and enabling them have noticable overhead on this
> platform ? Look at CONFIG_OF_LIVE, that should mitigate the DT access
> overhead at least.
I've not measured this. I was just assuming that it is sensible to only do the
setup once.
>
>> I think it's worth keeping the conditional here but can drop it if
>> you're really against it.
>
> It feels like fixing a problem at the wrong place really.
I'll drop the pfc_enabled flag and re-test.
Thanks,
Paul
OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
