Re: [PATCH 14/14] doc: board: ti: Add J722S-EVM documentation
0x80478000 + + * - MALLOC + - 0x80478000 + - 0x8048 + + * - EMPTY + - 0x8048 + - 0x80a0 + + * - BSS + - 0x80a0 + - 0x80a8 + + * - BLOBS + - 0x80a8 + - 0x80d00400 + + * - EMPTY + - 0x80d00400 + - 0x8100 +.. j722s_evm_rst_include_end_ddr_mem_layout + +Switch Setting for Boot Mode + + +Boot Mode pins provide means to select the boot mode and options before the +device is powered up. After every POR, they are the main source to populate +the Boot Parameter Tables. + +The following table shows some common boot modes used on J722S-EVM +platform. More details can be found in the Technical Reference Manual: +https://www.ti.com/lit/zip/sprujb3 under the `Boot Mode Pins` section. + +.. note:: + + This device is very new. Currently only UART boot is available while + we continue to add support for the other bootmodes. + +.. list-table:: Boot Modes + :widths: 16 16 16 + :header-rows: 1 + + * - Switch Label + - SW3: 12345678 + - SW4: 12345678 + + * - SD + - 1110 + - 0100 + + * - OSPI + - 11001110 + - + + * - EMMC + - 11010010 + - + + * - UART + - 11011100 + - + + * - USB DFU + - 11001010 + - + +For SW2 and SW1, the switch state in the "ON" position = 1. + +Debugging U-Boot + + +See :ref:`Common Debugging environment - OpenOCD`: for +detailed setup information. + +.. warning:: + + **OpenOCD support after**: v0.12.0 + + While support for the entire K3 generation including the am62xxx + extended family was added before v0.12.0, the tcl scripts for the + am62px have been accepted and will be available in the next release of + OpenOCD. It may be necessary to build OpenOCD from source depending on + the version your distribution has packaged. + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_openocd_connect_XDS110 +:end-before: .. k3_rst_include_end_openocd_connect_XDS110 + +To start OpenOCD and connect to the board + +.. code-block:: bash + + openocd -f board/ti_j722sevm.cfg diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index a1c01d1cf0..eba0f0e3e4 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -42,6 +42,7 @@ K3 Based SoCs ../beagle/j721e_beagleboneai64 j721e_evm j721s2_evm + j722s_evm j784s4_evm Boot Flow Overview Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH 09/14] arch: mach-k3: Introduce basic files to support J722S SoC family
Hi Jayesh
On 29/05/24 18:54, Jayesh Choudhary wrote:
Introduce the basic functions and definitions needed to properly
initialize TI J722S family of SoCs.
Co-developed-by: Vaishnav Achath
Signed-off-by: Vaishnav Achath
Signed-off-by: Jayesh Choudhary
---
arch/arm/mach-k3/Kconfig | 7 +-
arch/arm/mach-k3/Makefile | 1 +
arch/arm/mach-k3/include/mach/hardware.h | 4 +
.../arm/mach-k3/include/mach/j722s_hardware.h | 83 ++
arch/arm/mach-k3/include/mach/j722s_spl.h | 49
arch/arm/mach-k3/include/mach/spl.h | 4 +
arch/arm/mach-k3/j722s/Kconfig| 32 ++
arch/arm/mach-k3/j722s/Makefile | 6 +
arch/arm/mach-k3/j722s/j722s_init.c | 277 ++
9 files changed, 462 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-k3/include/mach/j722s_hardware.h
create mode 100644 arch/arm/mach-k3/include/mach/j722s_spl.h
create mode 100644 arch/arm/mach-k3/j722s/Kconfig
create mode 100644 arch/arm/mach-k3/j722s/Makefile
create mode 100644 arch/arm/mach-k3/j722s/j722s_init.c
[...]
+
+void board_init_f(ulong dummy)
+{
J784S4 went through quite a bit of revisions and I personally would like to use
it as an example (for now) for our code layout for all future devices until we
cleanup further. See [1] where it was addressed to have board_init_f split up
into calling smaller logical functions instead.
[1] https://lore.kernel.org/u-boot/20240103162504.xgbx73pnmthtzthl@vengeful/
+ struct udevice *dev;
+ int ret;
+
+ if (IS_ENABLED(CONFIG_CPU_V7R))
+ setup_k3_mpu_regions();
+
+ /*
+* Cannot delay this further as there is a chance that
+* K3_BOOT_PARAM_TABLE_INDEX can be over written by SPL MALLOC section.
+*/
+ store_boot_info_from_rom();
+
+ ctrl_mmr_unlock();
+
+ /* Init DM early */
+ ret = spl_early_init();
+ if (ret)
+ panic("spl_early_init() failed: %d\n", ret);
+
+ /*
+* Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and continue
[...]
--
Thanking You
Neha Malcom Francis
Re: [PATCH 08/14] ram: k3-ddrss: Enable the am62ax's DDR controller for J722S
On 29/05/24 18:54, Jayesh Choudhary wrote: The J722S family of SoCs uses the same DDR controller as found on the AM62A family. Enable this option when building for the J722S family. Signed-off-by: Vaishnav Achath Signed-off-by: Jayesh Choudhary --- drivers/ram/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig index 9838a2798f..a64d2dff68 100644 --- a/drivers/ram/Kconfig +++ b/drivers/ram/Kconfig @@ -65,7 +65,7 @@ choice default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default K3_AM64_DDRSS if SOC_K3_AM642 default K3_AM64_DDRSS if SOC_K3_AM625 - default K3_AM62A_DDRSS if SOC_K3_AM62A7 || SOC_K3_AM62P5 + default K3_AM62A_DDRSS if SOC_K3_AM62A7 || SOC_K3_AM62P5 || SOC_K3_J722S config K3_J721E_DDRSS bool "Enable J721E DDRSS support" Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH 06/14] arm: mach-k3: r5: Makefile: Fix the order for entries
On 29/05/24 18:54, Jayesh Choudhary wrote: Add the entries in alphabetical order. Signed-off-by: Jayesh Choudhary --- arch/arm/mach-k3/r5/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-k3/r5/Makefile b/arch/arm/mach-k3/r5/Makefile index 1cfc8e3ade..f1e61c8548 100644 --- a/arch/arm/mach-k3/r5/Makefile +++ b/arch/arm/mach-k3/r5/Makefile @@ -3,13 +3,13 @@ # Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/ # Andrew Davis +obj-$(CONFIG_SOC_K3_AM625) += am62x/ +obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ +obj-$(CONFIG_SOC_K3_AM62P5) += am62px/ obj-$(CONFIG_SOC_K3_J721E) += j721e/ obj-$(CONFIG_SOC_K3_J721E) += j7200/ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/ -obj-$(CONFIG_SOC_K3_AM625) += am62x/ -obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ obj-$(CONFIG_SOC_K3_J784S4) += j784s4/ -obj-$(CONFIG_SOC_K3_AM62P5) += am62px/ obj-y += common.o obj-y += lowlevel_init.o Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH 05/14] power: domain: ti: Fix the order for platform data entries
On 29/05/24 18:54, Jayesh Choudhary wrote:
Add the power domain platform data entries in alphabetical order.
Signed-off-by: Jayesh Choudhary
---
drivers/power/domain/ti-power-domain.c | 36 +-
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/power/domain/ti-power-domain.c
b/drivers/power/domain/ti-power-domain.c
index b059dd3737..362fae86a2 100644
--- a/drivers/power/domain/ti-power-domain.c
+++ b/drivers/power/domain/ti-power-domain.c
@@ -71,6 +71,24 @@ static void lpsc_write(u32 val, struct ti_lpsc *lpsc, u32
reg)
}
static const struct soc_attr ti_k3_soc_pd_data[] = {
+#if IS_ENABLED(CONFIG_SOC_K3_AM625)
+ {
+ .family = "AM62X",
+ .data = _pd_platdata,
+ },
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62A7)
+ {
+ .family = "AM62AX",
+ .data = _pd_platdata,
+ },
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
+ {
+ .family = "AM62PX",
+ .data = _pd_platdata,
+ },
+#endif
#if IS_ENABLED(CONFIG_SOC_K3_J721E)
{
.family = "J721E",
@@ -87,29 +105,11 @@ static const struct soc_attr ti_k3_soc_pd_data[] = {
.data = _pd_platdata,
},
#endif
-#if IS_ENABLED(CONFIG_SOC_K3_AM625)
- {
- .family = "AM62X",
- .data = _pd_platdata,
- },
-#endif
-#if IS_ENABLED(CONFIG_SOC_K3_AM62A7)
- {
- .family = "AM62AX",
- .data = _pd_platdata,
- },
-#endif
#if IS_ENABLED(CONFIG_SOC_K3_J784S4)
{
.family = "J784S4",
.data = _pd_platdata,
},
-#endif
-#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
- {
- .family = "AM62PX",
- .data = _pd_platdata,
- },
#endif
{ /* sentinel */ }
};
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 02/14] soc: ti: k3-socinfo: Fix SOC JTAG entry order
On 29/05/24 18:54, Jayesh Choudhary wrote:
Add JTAG_ID_PARTNO_* in alphabetical order.
Signed-off-by: Jayesh Choudhary
---
drivers/soc/soc_ti_k3.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index b585e47d46..0838808515 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -23,33 +23,33 @@ static const char *get_family_string(u32 idreg)
soc = (idreg & JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
switch (soc) {
+ case JTAG_ID_PARTNO_AM62X:
+ family = "AM62X";
+ break;
+ case JTAG_ID_PARTNO_AM62AX:
+ family = "AM62AX";
+ break;
+ case JTAG_ID_PARTNO_AM62PX:
+ family = "AM62PX";
+ break;
+ case JTAG_ID_PARTNO_AM64X:
+ family = "AM64X";
+ break;
case JTAG_ID_PARTNO_AM65X:
family = "AM65X";
break;
- case JTAG_ID_PARTNO_J721E:
- family = "J721E";
- break;
case JTAG_ID_PARTNO_J7200:
family = "J7200";
break;
- case JTAG_ID_PARTNO_AM64X:
- family = "AM64X";
+ case JTAG_ID_PARTNO_J721E:
+ family = "J721E";
break;
case JTAG_ID_PARTNO_J721S2:
family = "J721S2";
break;
- case JTAG_ID_PARTNO_AM62X:
- family = "AM62X";
- break;
- case JTAG_ID_PARTNO_AM62AX:
- family = "AM62AX";
- break;
case JTAG_ID_PARTNO_J784S4:
family = "J784S4";
break;
- case JTAG_ID_PARTNO_AM62PX:
- family = "AM62PX";
- break;
default:
family = "Unknown Silicon";
};
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 01/14] arm: mach-k3: Sort CONFIG_SOC* and K3_SOC_ID entries
On 29/05/24 18:54, Jayesh Choudhary wrote: Sort CONFIG_SOC* and K3_SOC_ID alphabetically. Signed-off-by: Jayesh Choudhary --- arch/arm/mach-k3/include/mach/hardware.h | 37 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-k3/include/mach/hardware.h b/arch/arm/mach-k3/include/mach/hardware.h index c724450638..c3aaded8dc 100644 --- a/arch/arm/mach-k3/include/mach/hardware.h +++ b/arch/arm/mach-k3/include/mach/hardware.h @@ -8,37 +8,38 @@ #include -#ifdef CONFIG_SOC_K3_AM654 -#include "am6_hardware.h" +#ifdef CONFIG_SOC_K3_AM625 +#include "am62_hardware.h" #endif -#ifdef CONFIG_SOC_K3_J721E -#include "j721e_hardware.h" +#ifdef CONFIG_SOC_K3_AM62A7 +#include "am62a_hardware.h" #endif -#ifdef CONFIG_SOC_K3_J721S2 -#include "j721s2_hardware.h" +#ifdef CONFIG_SOC_K3_AM62P5 +#include "am62p_hardware.h" #endif #ifdef CONFIG_SOC_K3_AM642 #include "am64_hardware.h" #endif -#ifdef CONFIG_SOC_K3_AM625 -#include "am62_hardware.h" +#ifdef CONFIG_SOC_K3_AM654 +#include "am6_hardware.h" #endif -#ifdef CONFIG_SOC_K3_AM62A7 -#include "am62a_hardware.h" +#ifdef CONFIG_SOC_K3_J721E +#include "j721e_hardware.h" +#endif + +#ifdef CONFIG_SOC_K3_J721S2 +#include "j721s2_hardware.h" #endif #ifdef CONFIG_SOC_K3_J784S4 #include "j784s4_hardware.h" #endif -#ifdef CONFIG_SOC_K3_AM62P5 -#include "am62p_hardware.h" -#endif /* Assuming these addresses and definitions stay common across K3 devices */ #define CTRLMMR_WKUP_JTAG_ID (WKUP_CTRL_MMR0_BASE + 0x14) @@ -63,14 +64,14 @@ static inline bool soc_is_##id(void) \ JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT; \ return soc == JTAG_ID_PARTNO_##ID; \ } -K3_SOC_ID(am65x, AM65X) -K3_SOC_ID(j721e, J721E) -K3_SOC_ID(j7200, J7200) -K3_SOC_ID(am64x, AM64X) -K3_SOC_ID(j721s2, J721S2) K3_SOC_ID(am62x, AM62X) K3_SOC_ID(am62ax, AM62AX) K3_SOC_ID(am62px, AM62PX) +K3_SOC_ID(am64x, AM64X) +K3_SOC_ID(am65x, AM65X) +K3_SOC_ID(j7200, J7200) +K3_SOC_ID(j721e, J721E) +K3_SOC_ID(j721s2, J721S2) #define K3_SEC_MGR_SYS_STATUS 0x44234100 #define SYS_STATUS_DEV_TYPE_SHIFT 0 Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
[PATCH] arm: dts: k3-*-binman: Make default DM file optional
The default DM firmware path is non-optional as of now. Make it
optional so that users that choose to provide DM via TI_DM argument
instead of BINMAN_INDIRS can do so without build errors.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-am625-sk-binman.dtsi | 1 +
arch/arm/dts/k3-am62a-sk-binman.dtsi | 1 +
arch/arm/dts/k3-am62p-sk-binman.dtsi | 1 +
arch/arm/dts/k3-j7200-binman.dtsi| 1 +
arch/arm/dts/k3-j721e-binman.dtsi| 1 +
arch/arm/dts/k3-j721s2-binman.dtsi | 1 +
arch/arm/dts/k3-j784s4-binman.dtsi | 1 +
7 files changed, 7 insertions(+)
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index dfd38d64f63..eddf05594d5 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -149,6 +149,7 @@
filename = "ti-dm.bin";
blob-ext {
filename =
"ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+ optional;
};
};
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
index ec3bf7ce913..6f82f26bf85 100644
--- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -152,6 +152,7 @@
filename = "ti-dm.bin";
blob-ext {
filename =
"ti-dm/am62axx/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+ optional;
};
};
ti-spl {
diff --git a/arch/arm/dts/k3-am62p-sk-binman.dtsi
b/arch/arm/dts/k3-am62p-sk-binman.dtsi
index dea14945bf5..2233921d320 100644
--- a/arch/arm/dts/k3-am62p-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62p-sk-binman.dtsi
@@ -72,6 +72,7 @@
blob-ext {
filename =
"ti-dm/am62pxx/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+ optional;
};
};
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
index e8020fec2dc..a524b246187 100644
--- a/arch/arm/dts/k3-j7200-binman.dtsi
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -281,6 +281,7 @@
filename = "ti-dm.bin";
blob-ext {
filename =
"ti-dm/j7200/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+ optional;
};
};
ti-spl {
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 1514d897634..0483fc5dd3f 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -310,6 +310,7 @@
filename = "ti-dm.bin";
blob-ext {
filename =
"ti-dm/j721e/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+ optional;
};
};
ti-spl {
diff --git a/arch/arm/dts/k3-j721s2-binman.dtsi
b/arch/arm/dts/k3-j721s2-binman.dtsi
index 46297ebef9e..d121d8c0c54 100644
--- a/arch/arm/dts/k3-j721s2-binman.dtsi
+++ b/arch/arm/dts/k3-j721s2-binman.dtsi
@@ -149,6 +149,7 @@
filename = "ti-dm.bin";
blob-ext {
filename =
"ti-dm/j721s2/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+ optional;
};
};
ti-spl {
diff --git a/arch/arm/dts/k3-j784s4-binman.dtsi
b/arch/arm/dts/k3-j784s4-binman.dtsi
index e4dd6e14a66..146cd7652c9 100644
--- a/arch/arm/dts/k3-j784s4-binman.dtsi
+++ b/arch/arm/dts/k3-j784s4-binman.dtsi
@@ -170,6 +170,7 @@
blob-ext {
filename =
"ti-dm/j784s4/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+ optional;
};
};
--
2.34.1
[PATCH] env: ti: k3_dfu: Drup mmcpart for rootfs
According to [0], raw access to mmc should not have mmcpart in the
entry. This was fixed in k3_dfu_combined.env but k3_dfu.env had been
overlooked.
[0] doc/usage/dfu.rst
Fixes: 53b406369e9d ("DFU: Check the number of arguments and argument string
strictly")
Signed-off-by: Neha Malcom Francis
---
Boot Logs:
https://gist.github.com/nehamalcom/163122d2b9d63607cbb383475978364a
include/env/ti/k3_dfu.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/env/ti/k3_dfu.env b/include/env/ti/k3_dfu.env
index 201529636cc..b42cf21d986 100644
--- a/include/env/ti/k3_dfu.env
+++ b/include/env/ti/k3_dfu.env
@@ -9,7 +9,7 @@ dfu_alt_info_mmc=
dfu_alt_info_emmc=
rawemmc raw 0 0x80 mmcpart 1;
- rootfs part 0 1 mmcpart 0;
+ rootfs part 0 1;
tiboot3.bin.raw raw 0x0 0x400 mmcpart 1;
tispl.bin.raw raw 0x400 0x1000 mmcpart 1;
u-boot.img.raw raw 0x1400 0x2000 mmcpart 1;
--
2.34.1
[PATCH] arm: dts: k3-j721s2-r5: Change GTC clock parent
MAIN_PLL0 has a flag set in DM (Device Manager) that removes its capability to re-initialise clock frequencies. A72 CPU clock (GTC) and RGMII has MAIN_PLL3 as their parent which does not have this flag. While RGMII needs re-initialization to default frequency to be able to get 250MHz with its divider, GTC can not get its required 200MHz with its dividers. Thus move GTC clock parent on J721S2 from MAIN_PLL3_HSDIV1 to MAIN_PLL0_HSDIV6. This was already done on CPTS node in kernel which was similarly affected (linked). Link: https://lore.kernel.org/all/20230605110443.84568-1-n-fran...@ti.com/ Signed-off-by: Neha Malcom Francis --- Boot logs: https://gist.github.com/nehamalcom/70676857dc3816a415af9861c38c76eb arch/arm/dts/k3-j721s2-r5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/k3-j721s2-r5.dtsi b/arch/arm/dts/k3-j721s2-r5.dtsi index eb0df42583a..40272abfc7c 100644 --- a/arch/arm/dts/k3-j721s2-r5.dtsi +++ b/arch/arm/dts/k3-j721s2-r5.dtsi @@ -22,7 +22,7 @@ resets = <_reset 202 0>; clocks = <_clks 61 1>; assigned-clocks = <_clks 61 1>, <_clks 202 0>; - assigned-clock-parents = <_clks 61 2>; + assigned-clock-parents = <_clks 61 3>; assigned-clock-rates = <2>, <20>; ti,sci = <>; ti,sci-proc-id = <32>; -- 2.34.1
Re: [PATCH v2 1/7] power: pmic: tps65941: Add DM_PMIC dependency
Hi Manorit
On 28/05/24 13:43, Manorit Chawdhry wrote:
This Kconfig depends on DM_PMIC but hadn't be explicitly stated which
could cause config related issues.
Adds the dependency in Kconfig for tps65941.
Fixes: 6b86dd0c1ead ("power: pmic: tps65941: Add support for tps65941 family of
PMICs")
Signed-off-by: Manorit Chawdhry
---
drivers/power/pmic/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 562c1a3b122a..bbcbcee4c355 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -394,6 +394,7 @@ config SPL_PMIC_LP87565
config PMIC_TPS65941
bool "Enable driver for Texas Instruments TPS65941 PMIC"
+ depends on DM_PMIC
help
The TPS65941 is a PMIC containing a bunch of SMPS & LDOs.
This driver binds the pmic children.
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH] arm: dts: k3-j721e-r5-common-proc-board: Set parent clock for clock ID 342
Hi Manorit
On 28/05/24 13:14, Manorit Chawdhry wrote:
Hi Neha,
On 13:07-20240528, Neha Malcom Francis wrote:
From: Apurva Nandan
This virtual clock mux configuration enables the use of dynamic frequency
scaling on A72 clock ID 202 by setting up the required register.
Signed-off-by: Apurva Nandan
Signed-off-by: Neha Malcom Francis
---
Boot logs:
https://gist.github.com/nehamalcom/138d25fe32d4d80af3e0e4c19c1b18e0
arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 9655ca21d02..25e4b4c7663 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -28,7 +28,8 @@
<_pds 4 TI_SCI_PD_EXCLUSIVE>;
resets = <_reset 202 0>;
clocks = <_clks 61 1>;
- assigned-clocks = <_clks 202 2>, <_clks 61 1>;
+ assigned-clocks = <_clks 202 2>, <_clks 61 1>, <_clks 342
0>;
+ assigned-clock-parents= <0>, <0>, <_clks 342 2>;
I think it would be better to base this patch on top of your j721e
of_upstream series. There you have introduced k3-j721e-r5.dtsi [0] and I
feel it would be better to put this change on that file maybe.
[0]: https://lore.kernel.org/u-boot/20240520095916.1809962-2-n-fran...@ti.com/
I'll line this up after OF_UPSTREAM is taken in or requires a next version
whichever happens first. Thanks for the review!
Regards,
Manorit
assigned-clock-rates = <20>, <2>;
ti,sci = <>;
ti,sci-proc-id = <32>;
--
2.34.1
--
Thanking You
Neha Malcom Francis
[PATCH] arm: dts: k3-j721e-r5-common-proc-board: Set parent clock for clock ID 342
From: Apurva Nandan This virtual clock mux configuration enables the use of dynamic frequency scaling on A72 clock ID 202 by setting up the required register. Signed-off-by: Apurva Nandan Signed-off-by: Neha Malcom Francis --- Boot logs: https://gist.github.com/nehamalcom/138d25fe32d4d80af3e0e4c19c1b18e0 arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts index 9655ca21d02..25e4b4c7663 100644 --- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts +++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts @@ -28,7 +28,8 @@ <_pds 4 TI_SCI_PD_EXCLUSIVE>; resets = <_reset 202 0>; clocks = <_clks 61 1>; - assigned-clocks = <_clks 202 2>, <_clks 61 1>; + assigned-clocks = <_clks 202 2>, <_clks 61 1>, <_clks 342 0>; + assigned-clock-parents= <0>, <0>, <_clks 342 2>; assigned-clock-rates = <20>, <2>; ti,sci = <>; ti,sci-proc-id = <32>; -- 2.34.1
[PATCH 2/3] configs: j721e_sk: Move to separate defconfig for J721E SK board
Add defconfig for J721E SK R5 and A72 configuration.
This includes and modifies the J721E EVM defconfigs:
j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig
j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-j721e-binman.dtsi| 99 ++--
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 23 +++
board/ti/j721e/MAINTAINERS | 2 +
configs/j721e_evm_a72_defconfig | 2 +-
configs/j721e_evm_r5_defconfig | 2 +-
configs/j721e_sk_a72_defconfig | 9 +++
configs/j721e_sk_r5_defconfig| 10 +++
7 files changed, 52 insertions(+), 95 deletions(-)
create mode 100644 configs/j721e_sk_a72_defconfig
create mode 100644 configs/j721e_sk_r5_defconfig
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..2867d264664 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -212,10 +212,7 @@
#ifdef CONFIG_TARGET_J721E_A72_EVM
#define SPL_J721E_EVM_DTB "spl/dts/k3-j721e-common-proc-board.dtb"
-#define SPL_J721E_SK_DTB "spl/dts/k3-j721e-sk.dtb"
-
#define J721E_EVM_DTB "u-boot.dtb"
-#define J721E_SK_DTB "arch/arm/dts/k3-j721e-sk.dtb"
{
ti-dm {
@@ -361,28 +358,13 @@
arch = "arm";
compression = "none";
ti-secure {
- content = <_j721e_evm_dtb>;
+ content = <_j721e_dtb>;
keyfile = "custMpk.pem";
};
- spl_j721e_evm_dtb: blob-ext {
+ spl_j721e_dtb: blob-ext {
filename = SPL_J721E_EVM_DTB;
};
};
-
- fdt-1 {
- description = "k3-j721e-sk";
- type = "flat_dt";
- arch = "arm";
- compression = "none";
- ti-secure {
- content = <_j721e_sk_dtb>;
- keyfile = "custMpk.pem";
-
- };
- spl_j721e_sk_dtb: blob-ext {
- filename = SPL_J721E_SK_DTB;
- };
- };
};
configurations {
@@ -394,13 +376,6 @@
loadables = "tee", "dm", "spl";
fdt = "fdt-0";
};
-
- conf-1 {
- description = "k3-j721e-sk";
- firmware = "atf";
- loadables = "tee", "dm", "spl";
- fdt = "fdt-1";
- };
};
};
};
@@ -422,35 +397,17 @@
arch = "arm";
compression = "none";
ti-secure {
- content = <_evm_dtb>;
+ content = <_dtb>;
keyfile = "custMpk.pem";
};
- j721e_evm_dtb: blob-ext {
+ j721e_dtb: blob-ext {
filename = J721E_EVM_DTB;
};
hash {
algo = "crc32";
};
};
-
- fdt-1 {
- description = "k3-j721e-sk";
- type = "flat_dt";
- arch = "arm";
- compression = "none";
-
[PATCH 1/3] arm: dts: k3-j721e-r5*: Introduce k3-j721e-r5.dtsi
Introduce k3-j721e-r5.dtsi to be used by board R5 DTS files. This
helps sync SoC changes across boards.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 78 +-
.../arm/dts/k3-j721e-r5-common-proc-board.dts | 75 +
arch/arm/dts/k3-j721e-r5-sk.dts | 75 +
arch/arm/dts/k3-j721e-r5.dtsi | 80 +++
4 files changed, 83 insertions(+), 225 deletions(-)
create mode 100644 arch/arm/dts/k3-j721e-r5.dtsi
diff --git a/arch/arm/dts/k3-j721e-r5-beagleboneai64.dts
b/arch/arm/dts/k3-j721e-r5-beagleboneai64.dts
index 43da4dafba8..4f97af4fd94 100644
--- a/arch/arm/dts/k3-j721e-r5-beagleboneai64.dts
+++ b/arch/arm/dts/k3-j721e-r5-beagleboneai64.dts
@@ -12,84 +12,8 @@
#include "k3-j721e-ddr.dtsi"
#include "k3-j721e-beagleboneai64-u-boot.dtsi"
+#include "k3-j721e-r5.dtsi"
-/ {
- aliases {
- remoteproc0 =
- remoteproc1 = _0;
- };
-
- chosen {
- tick-timer = _timer0;
- };
-
- a72_0: a72@0 {
- compatible = "ti,am654-rproc";
- reg = <0x0 0x00a9 0x0 0x10>;
- power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
- <_pds 202 TI_SCI_PD_EXCLUSIVE>,
- <_pds 4 TI_SCI_PD_EXCLUSIVE>;
- resets = <_reset 202 0>;
- clocks = <_clks 61 1>;
- assigned-clocks = <_clks 202 2>, <_clks 61 1>;
- assigned-clock-rates = <20>, <2>;
- ti,sci = <>;
- ti,sci-proc-id = <32>;
- ti,sci-host-id = <10>;
- bootph-pre-ram;
- };
-
- dm_tifs: dm-tifs {
- compatible = "ti,j721e-dm-sci";
- ti,host-id = <3>;
- ti,secure-host;
- mbox-names = "rx", "tx";
- mboxes= <_proxy_mcu 21>,
- <_proxy_mcu 23>;
- bootph-pre-ram;
- };
-};
-
- {
- mboxes= <_proxy_mcu 6>,
- <_proxy_mcu 8>,
- <_proxy_mcu 5>;
- mbox-names = "rx", "tx", "notify";
- ti,host-id = <4>;
- ti,secure-host;
-};
-
-_timer0 {
- status = "okay";
- bootph-pre-ram;
-};
-
-_proxy_mcu {
- bootph-pre-ram;
- /* We require this for boot handshake */
- status = "okay";
-};
-
-_mcu_wakeup {
- sysctrler: sysctrler {
- compatible = "ti,am654-system-controller";
- mboxes= <_proxy_mcu 4>, <_proxy_mcu 5>;
- mbox-names = "tx", "rx";
- bootph-pre-ram;
- };
-};
-
-_ringacc {
- ti,sci = <_tifs>;
-};
-
-_udmap {
- ti,sci = <_tifs>;
-};
-
-_uart0_pins_default {
- bootph-pre-ram;
-};
_i2c0 {
bootph-pre-ram;
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 9655ca21d02..c7e344350c8 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -10,76 +10,7 @@
#include "k3-j721e-ddr.dtsi"
#include "k3-j721e-common-proc-board-u-boot.dtsi"
-/ {
- chosen {
- tick-timer = _timer0;
- };
-
- aliases {
- remoteproc0 =
- remoteproc1 = _0;
- };
-
- a72_0: a72@0 {
- compatible = "ti,am654-rproc";
- reg = <0x0 0x00a9 0x0 0x10>;
- power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
- <_pds 202 TI_SCI_PD_EXCLUSIVE>,
- <_pds 4 TI_SCI_PD_EXCLUSIVE>;
- resets = <_reset 202 0>;
- clocks = <_clks 61 1>;
- assigned-clocks = <_clks 202 2>, <_clks 61 1>;
- assigned-clock-rates = <20>, <2>;
- ti,sci = <>;
- ti,sci-proc-id = <32>;
- ti,sci-host-id = <10>;
- bootph-pre-ram;
- };
-
- dm_tifs: dm-tifs {
- compatible = "ti,j721e-dm-sci";
- ti,host-id = <3>;
- ti,secure-host;
- mbox-names = "rx", "tx";
- mboxes= <_proxy_mcu 21>,
- <_proxy_mcu 23>;
- bootph-pre-ram;
- };
-};
-
-_timer0 {
- status = "okay";
- bootph-pre-ram;
-};
-
- {
- mboxes= <_proxy_mcu 8>, <_proxy_mcu 6>,
<_proxy_mcu 5>;
- m
[PATCH 0/3] k3-j721e: Enable OF_UPSTREAM for J721E
This series was plucked out from the larger series [1] that did some templating reformatting and also enabled OF_UPSTREAM for J721E. The former has been kept aside till all the platforms affected have moved to using OF_UPSTREAM to have less conflicts while merging. Patches split J721E EVM and J721E SK to using separate builds, as well as enable OF_UPSTREAM for both the platforms. Boot logs: https://gist.github.com/nehamalcom/8f326376b6c6b1196084721405159bb9 [1] https://lore.kernel.org/all/20240322131011.1029620-1-n-fran...@ti.com/ Neha Malcom Francis (3): arm: dts: k3-j721e-r5*: Introduce k3-j721e-r5.dtsi configs: j721e_sk: Move to separate defconfig for J721E SK board arm: dts: k3-j721e: Move to OF_UPSTREAM arch/arm/dts/Makefile |4 +- arch/arm/dts/k3-j721e-binman.dtsi | 101 +- .../k3-j721e-common-proc-board-u-boot.dtsi| 14 +- arch/arm/dts/k3-j721e-common-proc-board.dts | 976 -- arch/arm/dts/k3-j721e-main.dtsi | 2741 - arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 681 arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 78 +- .../arm/dts/k3-j721e-r5-common-proc-board.dts | 75 +- arch/arm/dts/k3-j721e-r5-sk.dts | 75 +- arch/arm/dts/k3-j721e-r5.dtsi | 80 + arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 41 +- arch/arm/dts/k3-j721e-sk.dts | 1074 --- arch/arm/dts/k3-j721e-som-p0.dtsi | 446 --- arch/arm/dts/k3-j721e-thermal.dtsi| 75 - arch/arm/dts/k3-j721e.dtsi| 176 -- board/ti/j721e/MAINTAINERS|2 + configs/j721e_evm_a72_defconfig |5 +- configs/j721e_evm_r5_defconfig|2 +- configs/j721e_sk_a72_defconfig|9 + configs/j721e_sk_r5_defconfig | 10 + 20 files changed, 147 insertions(+), 6518 deletions(-) delete mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts delete mode 100644 arch/arm/dts/k3-j721e-main.dtsi delete mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi create mode 100644 arch/arm/dts/k3-j721e-r5.dtsi delete mode 100644 arch/arm/dts/k3-j721e-sk.dts delete mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi delete mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi delete mode 100644 arch/arm/dts/k3-j721e.dtsi create mode 100644 configs/j721e_sk_a72_defconfig create mode 100644 configs/j721e_sk_r5_defconfig -- 2.34.1
Re: [PATCH v2 5/8] drivers: ram: Kconfig: Add CONFIG_K3_INLINE_ECC
Hi Andrew On 15/05/24 21:37, Andrew Davis wrote: On 5/10/24 3:47 AM, Santhosh Kumar K wrote: From: Neha Malcom Francis Add CONFIG_K3_INLINE_ECC so that ECC functions can be compiled into R5 SPL only when the config has been enabled. Signed-off-by: Neha Malcom Francis --- drivers/ram/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig index 9838a2798f92..9d1eee1d5cad 100644 --- a/drivers/ram/Kconfig +++ b/drivers/ram/Kconfig @@ -107,6 +107,17 @@ config IMXRT_SDRAM to support external memories like sdram, psram & nand. This driver is for the sdram memory interface with the SEMC. +config K3_INLINE_ECC + bool "Enable TI Inline ECC support" + depends on K3_DDRSS + default n n is already the default, this line is never needed. Right thanks for catching that! Maybe we want this to be `default y` so that we do not change current behavior and platforms can opt-out as needed instead. Inline ECC should not be default behavior on our systems, rather those who need it opt to enable it; since it significantly impacts boot time on systems with large RAM. So I think we should keep it as default n. Andrew + help + Enable Inline ECC support on K3 platforms. 1/9th of the SDRAM space + is used for ECC storage and the rest 8/9th is available for system + use. Enabling ECC increases boot time as the ECC protected regions + need to be primed with a predefined value prior to enabling ECC + check. + source "drivers/ram/aspeed/Kconfig" source "drivers/ram/cadence/Kconfig" source "drivers/ram/octeon/Kconfig" -- Thanking You Neha Malcom Francis
Re: [PATCH v2 5/6] configs: am68_sk: Move to separate defconfig for AM68 SK board
index ..d477f9e4e988 --- /dev/null +++ b/configs/am68_sk_a72_defconfig @@ -0,0 +1,10 @@ +#include + +CONFIG_ARM=y +CONFIG_ARCH_K3=y +CONFIG_SOC_K3_J721S2=y +CONFIG_TARGET_J721S2_A72_EVM=y + +CONFIG_DEFAULT_DEVICE_TREE="k3-am68-sk-base-board" +CONFIG_SPL_OF_LIST="k3-am68-sk-base-board" +CONFIG_OF_LIST="k3-am68-sk-base-board" diff --git a/configs/am68_sk_r5_defconfig b/configs/am68_sk_r5_defconfig new file mode 100644 index ..e9b6882c1f68 --- /dev/null +++ b/configs/am68_sk_r5_defconfig @@ -0,0 +1,10 @@ +#include + +CONFIG_ARM=y +CONFIG_ARCH_K3=y +CONFIG_SOC_K3_J721S2=y +CONFIG_TARGET_J721S2_R5_EVM=y + +CONFIG_DEFAULT_DEVICE_TREE="k3-am68-sk-r5-base-board" +CONFIG_SPL_OF_LIST="k3-am68-sk-r5-base-board" +CONFIG_OF_LIST="k3-am68-sk-r5-base-board" diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig index 8b02d07a9f09..dd86b5c05092 100644 --- a/configs/j721s2_evm_a72_defconfig +++ b/configs/j721s2_evm_a72_defconfig @@ -84,7 +84,7 @@ CONFIG_CMD_UBI=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -CONFIG_OF_LIST="k3-j721s2-common-proc-board k3-am68-sk-base-board" +CONFIG_OF_LIST="k3-j721s2-common-proc-board" CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig index 5ef5247a3e00..3c958cafbe8f 100644 --- a/configs/j721s2_evm_r5_defconfig +++ b/configs/j721s2_evm_r5_defconfig @@ -82,7 +82,7 @@ CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="k3-j721s2-r5-common-proc-board k3-am68-sk-r5-base-board" +CONFIG_SPL_OF_LIST="k3-j721s2-r5-common-proc-board" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH v2 4/6] arch: arm: dts: k3-j721s2-r5: Introduce k3-j721s2-r5.dtsi
<_proxy_mcu 23>;
- bootph-pre-ram;
- };
-};
-
-_timer0 {
- clock-frequency = <25000>;
- bootph-pre-ram;
-};
-
-_proxy_sa3 {
- bootph-pre-ram;
- status = "okay";
-};
-
-_proxy_mcu {
- bootph-pre-ram;
- status = "okay";
-};
-
-_mcu_wakeup {
- sysctrler: sysctrler {
- compatible = "ti,am654-system-controller";
- mboxes= <_proxy_mcu 4>, <_proxy_mcu 5>,
<_proxy_sa3 5>;
- mbox-names = "tx", "rx", "boot_notify";
- bootph-pre-ram;
- };
-};
-
- {
- mboxes= <_proxy_mcu 8>, <_proxy_mcu 6>, <_proxy_mcu
5>;
- mbox-names = "tx", "rx", "notify";
- ti,host-id = <4>;
- ti,secure-host;
-};
-
-_ringacc {
- ti,sci = <_tifs>;
-};
-
-_udmap {
- ti,sci = <_tifs>;
-};
+#include "k3-j721s2-r5.dtsi"
diff --git a/arch/arm/dts/k3-j721s2-r5.dtsi b/arch/arm/dts/k3-j721s2-r5.dtsi
new file mode 100644
index ..eb0df42583a3
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-r5.dtsi
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+ chosen {
+ tick-timer = _timer0;
+ };
+
+ aliases {
+ remoteproc0 =
+ remoteproc1 = _0;
+ };
+
+ a72_0: a72@0 {
+ compatible = "ti,am654-rproc";
+ reg = <0x0 0x00a9 0x0 0x10>;
+ power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
+ <_pds 202 TI_SCI_PD_EXCLUSIVE>,
+ <_pds 4 TI_SCI_PD_EXCLUSIVE>;
+ resets = <_reset 202 0>;
+ clocks = <_clks 61 1>;
+ assigned-clocks = <_clks 61 1>, <_clks 202 0>;
+ assigned-clock-parents = <_clks 61 2>;
+ assigned-clock-rates = <2>, <20>;
+ ti,sci = <>;
+ ti,sci-proc-id = <32>;
+ ti,sci-host-id = <10>;
+ bootph-pre-ram;
+ };
+
+ dm_tifs: dm-tifs {
+ compatible = "ti,j721e-dm-sci";
+ ti,host-id = <3>;
+ ti,secure-host;
+ mbox-names = "rx", "tx";
+ mboxes= <_proxy_mcu 21>,
+ <_proxy_mcu 23>;
+ bootph-pre-ram;
+ };
+};
+
+_timer0 {
+ clock-frequency = <25000>;
+ bootph-pre-ram;
+};
+
+_proxy_sa3 {
+ bootph-pre-ram;
+ status = "okay";
+};
+
+_proxy_mcu {
+ bootph-pre-ram;
+ status = "okay";
+};
+
+_mcu_wakeup {
+ sysctrler: sysctrler {
+ compatible = "ti,am654-system-controller";
+ mboxes= <_proxy_mcu 4>, <_proxy_mcu 5>,
<_proxy_sa3 5>;
+ mbox-names = "tx", "rx", "boot_notify";
+ bootph-pre-ram;
+ };
+};
+
+ {
+ mboxes= <_proxy_mcu 8>, <_proxy_mcu 6>, <_proxy_mcu
5>;
+ mbox-names = "tx", "rx", "notify";
+ ti,host-id = <4>;
+ ti,secure-host;
+};
+
+_ringacc {
+ ti,sci = <_tifs>;
+};
+
+_udmap {
+ ti,sci = <_tifs>;
+};
diff --git a/board/ti/j721s2/MAINTAINERS b/board/ti/j721s2/MAINTAINERS
index 08c8d110ac0a..561c3dfff9bd 100644
--- a/board/ti/j721s2/MAINTAINERS
+++ b/board/ti/j721s2/MAINTAINERS
@@ -14,6 +14,7 @@ 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.dtsi
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
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH v2 3/6] arch: arm: dts: k3-am68-sk-r5: Sync with J721s2 R5 file
Hi Manorit
On 09/05/24 15:23, Manorit Chawdhry wrote:
Currently AM68 SK boots with J721s2 R5 DTS and then later changes to
AM68 SK DT during runtime.
To split the support of J721s2 and AM68, sync AM68 R5 DT with J721s2 R5
DT as that contains some essential node changes for booting up AM68
using AM68 R5 DT.
secure_proxy_mcu and secure_proxy_sa3 node changes are required for
establishing contact with TIFS running on M4 core, and the addition of
new power domain helps in holding A72 in reset for configuration of
firewalls.
Signed-off-by: Manorit Chawdhry
---
arch/arm/dts/k3-am68-sk-r5-base-board.dts | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am68-sk-r5-base-board.dts
b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
index 695aadc287bd..038b08dc3e01 100644
--- a/arch/arm/dts/k3-am68-sk-r5-base-board.dts
+++ b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
@@ -24,7 +24,8 @@
compatible = "ti,am654-rproc";
reg = <0x0 0x00a9 0x0 0x10>;
power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
- <_pds 202 TI_SCI_PD_EXCLUSIVE>;
+ <_pds 202 TI_SCI_PD_EXCLUSIVE>,
+ <_pds 4 TI_SCI_PD_EXCLUSIVE>;
resets = <_reset 202 0>;
clocks = <_clks 61 1>;
assigned-clocks = <_clks 61 1>, <_clks 202 0>;
@@ -54,10 +55,12 @@
_proxy_mcu {
bootph-pre-ram;
+ status = "okay";
};
_proxy_sa3 {
bootph-pre-ram;
+ status = "okay";
};
_mcu_wakeup {
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 4/6] arch: arm: dts: k3-am68-sk-r5: Sync with J721s2 R5 file
Hi Manorit
On 09/05/24 11:04, Manorit Chawdhry wrote:
Hi Neha,
On 10:37-20240509, Manorit Chawdhry wrote:
Hi Neha,
On 16:09-20240508, Neha Malcom Francis wrote:
Hi Manorit,
On 08/05/24 12:56, Manorit Chawdhry wrote:
Update the file with the required nodes from J721s2 R5 file to start
using k3-am68-sk-r5 file for AM68.
Signed-off-by: Manorit Chawdhry
---
What's the motivation behind this patch vs. squashing it into patch 5/6?
Could've squashed it ig, I think developed it in this order so this
remained. Would squash it. Also realised that I should be putting that
patch before the config split otherwise am68 boot would break again.
Would take that up as well in v2. Thanks for the review!
Though on second thoughts.. I think it's good as it tells that AM68 R5
DT had been missing some changes. If someone wants to track what changed
then ig it's better that they don't have to debug the merge commit which
ends up altering the contents of AM68 R5 DT ( in-case this patch ain't
there ) and people will have to manually check the diff as to what
altered. Do you think it's better to keep this patch with the following
reasoning?
Yes you can do that but I think this commit message is confusing. The "start
using k3-am68-sk-r5 file for AM68" threw me off, maybe modify it to say that
AM68 R5 DT is missing these changes and needs them why? After that grabbing the
common bits into an SoC R5 file in patch 5/6 makes sense.
Regards,
Manorit
Regards,
Manorit
arch/arm/dts/k3-am68-sk-r5-base-board.dts | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am68-sk-r5-base-board.dts
b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
index 695aadc287bd..038b08dc3e01 100644
--- a/arch/arm/dts/k3-am68-sk-r5-base-board.dts
+++ b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
@@ -24,7 +24,8 @@
compatible = "ti,am654-rproc";
reg = <0x0 0x00a9 0x0 0x10>;
power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
- <_pds 202 TI_SCI_PD_EXCLUSIVE>;
+ <_pds 202 TI_SCI_PD_EXCLUSIVE>,
+ <_pds 4 TI_SCI_PD_EXCLUSIVE>;
resets = <_reset 202 0>;
clocks = <_clks 61 1>;
assigned-clocks = <_clks 61 1>, <_clks 202 0>;
@@ -54,10 +55,12 @@
_proxy_mcu {
bootph-pre-ram;
+ status = "okay";
};
_proxy_sa3 {
bootph-pre-ram;
+ status = "okay";
};
_mcu_wakeup {
--
Thanking You
Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 4/6] arch: arm: dts: k3-am68-sk-r5: Sync with J721s2 R5 file
Hi Manorit,
On 08/05/24 12:56, Manorit Chawdhry wrote:
Update the file with the required nodes from J721s2 R5 file to start
using k3-am68-sk-r5 file for AM68.
Signed-off-by: Manorit Chawdhry
---
What's the motivation behind this patch vs. squashing it into patch 5/6?
arch/arm/dts/k3-am68-sk-r5-base-board.dts | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am68-sk-r5-base-board.dts
b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
index 695aadc287bd..038b08dc3e01 100644
--- a/arch/arm/dts/k3-am68-sk-r5-base-board.dts
+++ b/arch/arm/dts/k3-am68-sk-r5-base-board.dts
@@ -24,7 +24,8 @@
compatible = "ti,am654-rproc";
reg = <0x0 0x00a9 0x0 0x10>;
power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
- <_pds 202 TI_SCI_PD_EXCLUSIVE>;
+ <_pds 202 TI_SCI_PD_EXCLUSIVE>,
+ <_pds 4 TI_SCI_PD_EXCLUSIVE>;
resets = <_reset 202 0>;
clocks = <_clks 61 1>;
assigned-clocks = <_clks 61 1>, <_clks 202 0>;
@@ -54,10 +55,12 @@
_proxy_mcu {
bootph-pre-ram;
+ status = "okay";
};
_proxy_sa3 {
bootph-pre-ram;
+ status = "okay";
};
_mcu_wakeup {
--
Thanking You
Neha Malcom Francis
Re: [PATCH 3/6] configs: am68_sk: Move to separate defconfig for AM68 SK board
Hi Manorit On 08/05/24 12:56, Manorit Chawdhry wrote: Add defconfig for AM68 SK R5 and A72 configuration. This includes and modifies the AM68 EVM defconfigs: j721s2_evm_r5_defconfig -> am68_sk_r5_defconfig j721s2_evm_a72_defconfig -> am68_sk_a72_defconfig Signed-off-by: Manorit Chawdhry --- arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 23 +++ arch/arm/dts/k3-j721s2-binman.dtsi | 89 +- board/ti/j721s2/MAINTAINERS| 2 + configs/am68_sk_a72_defconfig | 10 +++ configs/am68_sk_r5_defconfig | 10 +++ configs/j721s2_evm_a72_defconfig | 2 +- configs/j721s2_evm_r5_defconfig| 2 +- 7 files changed, 49 insertions(+), 89 deletions(-) This looks good to me. Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
[PATCH v2 2/2] arm: dts: k3-j7200-binman: Add support for HSSE1.0 and HSFS1.0
J7200 has SR1.0 and SR2.0 having three variants of each GP, HS-FS and
HS-SE. Current build does not generate HS-SE SR1.0 and HS-FS SR1.0 so
add support for them.
Reported-by: Suman Anna
Reported-by: Aniket Limaye
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-j7200-binman.dtsi | 95 ++-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
index 06db8659876..e8020fec2dc 100644
--- a/arch/arm/dts/k3-j7200-binman.dtsi
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-binman.dtsi"
@@ -47,6 +47,52 @@
config = "pm-cfg_j7200.yaml";
};
+ {
+ tiboot3-j7200-hs-evm.bin {
+ filename = "tiboot3-j7200-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_sr1>, <_fs_enc_sr1>,
<_tifs_cfg_sr1>,
+ <_dm_cfg_sr1>, <_inner_cert_sr1>;
+ combined;
+ dm-data;
+ core-opts = <2>;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_sr1>;
+ content-sysfw = <_fs_enc_sr1>;
+ content-sysfw-data = <_tifs_cfg_sr1>;
+ content-sysfw-inner-cert = <_inner_cert_sr1>;
+ content-dm-data = <_dm_cfg_sr1>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x7f000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl_sr1: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_sr1: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j7200-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_sr1: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert_sr1: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-j7200-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg_sr1: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
{
tiboot3-j7200_sr2-hs-evm.bin {
filename = "tiboot3-j7200_sr2-hs-evm.bin";
@@ -92,6 +138,53 @@
};
};
+ {
+ tiboot3-j7200-hs-fs-evm.bin {
+ filename = "tiboot3-j7200-hs-fs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_fs_sr1>, <_fs_enc_fs_sr1>,
+ <_tifs_cfg_fs_sr1>,
<_dm_cfg_fs_sr1>,
+ <_inner_cert_fs_sr1>;
+ combined;
+ dm-data;
+ core-opts = <2>;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs_sr1>;
+ content-sysfw = <_fs_enc_fs_sr1>;
+ content-sysfw-data = <_tifs_cfg_fs_sr1>;
+ content-sysfw-inner-cert = <_inner_cert_fs_sr1>;
+ content-dm-data = <_dm_cfg_fs_sr1>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x7f000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl_fs_sr1: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs_sr1: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j7200-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_fs_sr1: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext&q
[PATCH v2 1/2] arm: dts: k3-j721e-binman: Add support for HSFS1.1
J721E has SR1.1 and SR2.0 having three variants of each GP, HS-FS and
HS-SE. Current build does not generate HS-FS SR1.1 so add support for
them.
Reported-by: Suman Anna
Signed-off-by: Neha Malcom Francis
---
Changes since v1:
- removed redundant HS-SE SR2.0 generation
arch/arm/dts/k3-j721e-binman.dtsi | 90 ++-
1 file changed, 89 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..1514d897634 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-binman.dtsi"
@@ -129,6 +129,94 @@
};
};
+ {
+ tiboot3-j721e_sr1_1-hs-fs-evm.bin {
+ filename = "tiboot3-j721e_sr1_1-hs-fs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_fs_sr1_1>;
+ core = "public";
+ core-opts = <2>;
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl_fs_sr1_1: u-boot-spl {
+ no-expanded;
+ };
+ };
+ sysfw_fs_sr1_1 {
+ filename = "sysfw.bin_fs_sr1_1";
+ ti-fs-cert-fs.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr1_1-hs-fs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-fs-firmware-j721e-hs-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr1_1-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+ itb_fs_sr1_1 {
+ filename = "sysfw-j721e_sr1_1-hs-fs-evm.itb";
+ fit {
+ description = "SYSFW and Config fragments";
+ #address-cells = <1>;
+ images {
+ sysfw.bin {
+ description = "sysfw";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ blob-ext {
+ filename = "sysfw.bin_fs_sr1_1";
+ };
+ };
+ board-cfg.bin {
+ description = "board-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ board-cfg {
+ filename = "board-cfg.bin";
+ type = "blob-ext";
+ };
+
+ };
+ pm-cfg.bin {
+ description = "pm-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ pm-cfg {
+ filename = "pm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+ rm-cfg.bin {
+ description = "rm-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ rm-cfg {
+ filename = "rm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+ sec-cfg.bin {
+ description = "sec-cfg";
+ type = "firmware";
+ arch = "arm";
+ c
[PATCH v2 0/2] Generate all SR boot binaries
Add support for missing HS SRs in the build for J721E and J7200. Boot logs (updated for v2): https://gist.github.com/nehamalcom/e652752623537aced8cf31308015d7c9 Changes since v2: - removed redundant HS-SE SR2.0 generation for J721E (Andrew) Neha Malcom Francis (2): arm: dts: k3-j721e-binman: Add support for HSFS1.1 arm: dts: k3-j7200-binman: Add support for HSSE1.0 and HSFS1.0 arch/arm/dts/k3-j7200-binman.dtsi | 95 ++- arch/arm/dts/k3-j721e-binman.dtsi | 90 - 2 files changed, 183 insertions(+), 2 deletions(-) -- 2.34.1
Re: [PATCH 1/2] arm: dts: k3-j721e-binman: Add support for HSSE2.0 and HSFS1.1
Hi Andrew,
On 22-Apr-24 3:37 AM, Andrew Davis wrote:
On 4/22/24 4:40 PM, Neha Malcom Francis wrote:
J721E has SR1.1 and SR2.0 having three variants of each GP, HS-FS and
HS-SE. Current build does not generate HS-SE SR2.0 and HS-FS SR1.1 so
add support for them.
Reported-by: Suman Anna
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-j721e-binman.dtsi | 201 +-
1 file changed, 200 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..90e4a31329e 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022-2023 Texas Instruments Incorporated -
https://www.ti.com/
+ * Copyright (C) 2022-2024 Texas Instruments Incorporated -
https://www.ti.com/
*/
#include "k3-binman.dtsi"
@@ -129,6 +129,205 @@
};
};
+ {
+ tiboot3-j721e_sr2-hs-evm.bin {
This already seems to exist in this file, it is hidden up in the
first binman{} GP node at the top. Might just need split out from that.
Andrew
Oh thanks for catching that!
+ filename = "tiboot3-j721e_sr2-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_sr2>;
+ core = "public";
+ core-opts = <2>;
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl_sr2: u-boot-spl {
+ no-expanded;
+ };
+ };
+ sysfw_sr2 {
+ filename = "sysfw.bin_sr2";
+ ti-secure-rom {
+ content = <_fs_cert_sr2>;
+ core = "secure";
+ load = <0x4>;
+ keyfile = "custMpk.pem";
+ countersign;
+ };
+ ti_fs_cert_sr2: ti-fs-cert.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j721e_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-fs-firmware-j721e_sr2-hs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j721e_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+ itb_sr2 {
+ filename = "sysfw-j721e_sr2-hs-evm.itb";
+ fit {
+ description = "SYSFW and Config fragments";
+ #address-cells = <1>;
+ images {
+ sysfw.bin {
+ description = "sysfw";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ blob-ext {
+ filename = "sysfw.bin_sr2";
+ };
+ };
+ board-cfg.bin {
+ description = "board-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <_cfg_sr2>;
+ keyfile = "custMpk.pem";
+ };
+ board_cfg_sr2: board-cfg {
+ filename = "board-cfg.bin";
+ type = "blob-ext";
+ };
+
+ };
+ pm-cfg.bin {
+ description = "pm-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <_cfg_sr2>;
+ keyfile = "custMpk.pem";
+ };
+ pm_cfg_sr2: pm-cfg {
+ filename = "pm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+ rm-cfg.bin {
+ description = "rm-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <_cfg_sr2>;
+ keyfile = "custMpk.pem";
+ };
+ rm_cfg_sr2: rm-cfg {
+ filename = "rm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+ sec-cfg.bin {
+ description = "sec-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = &l
[PATCH 2/2] arm: dts: k3-j7200-binman: Add support for HSSE1.0 and HSFS1.0
J7200 has SR1.0 and SR2.0 having three variants of each GP, HS-FS and
HS-SE. Current build does not generate HS-SE SR1.0 and HS-FS SR1.0 so
add support for them.
Reported-by: Suman Anna
Reported-by: Aniket Limaye
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-j7200-binman.dtsi | 95 ++-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
index 06db8659876..e8020fec2dc 100644
--- a/arch/arm/dts/k3-j7200-binman.dtsi
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-binman.dtsi"
@@ -47,6 +47,52 @@
config = "pm-cfg_j7200.yaml";
};
+ {
+ tiboot3-j7200-hs-evm.bin {
+ filename = "tiboot3-j7200-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_sr1>, <_fs_enc_sr1>,
<_tifs_cfg_sr1>,
+ <_dm_cfg_sr1>, <_inner_cert_sr1>;
+ combined;
+ dm-data;
+ core-opts = <2>;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_sr1>;
+ content-sysfw = <_fs_enc_sr1>;
+ content-sysfw-data = <_tifs_cfg_sr1>;
+ content-sysfw-inner-cert = <_inner_cert_sr1>;
+ content-dm-data = <_dm_cfg_sr1>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x7f000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl_sr1: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_sr1: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j7200-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_sr1: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert_sr1: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-j7200-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg_sr1: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
{
tiboot3-j7200_sr2-hs-evm.bin {
filename = "tiboot3-j7200_sr2-hs-evm.bin";
@@ -92,6 +138,53 @@
};
};
+ {
+ tiboot3-j7200-hs-fs-evm.bin {
+ filename = "tiboot3-j7200-hs-fs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_fs_sr1>, <_fs_enc_fs_sr1>,
+ <_tifs_cfg_fs_sr1>,
<_dm_cfg_fs_sr1>,
+ <_inner_cert_fs_sr1>;
+ combined;
+ dm-data;
+ core-opts = <2>;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs_sr1>;
+ content-sysfw = <_fs_enc_fs_sr1>;
+ content-sysfw-data = <_tifs_cfg_fs_sr1>;
+ content-sysfw-inner-cert = <_inner_cert_fs_sr1>;
+ content-dm-data = <_dm_cfg_fs_sr1>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x7f000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl_fs_sr1: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs_sr1: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j7200-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_fs_sr1: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext&q
[PATCH 0/2] Generate all SR boot binaries
Add support for missing HS SRs in the build for J721E and J7200. Boot logs: https://gist.github.com/nehamalcom/e652752623537aced8cf31308015d7c9 Neha Malcom Francis (2): arm: dts: k3-j721e-binman: Add support for HSSE2.0 and HSFS1.1 arm: dts: k3-j7200-binman: Add support for HSSE1.0 and HSFS1.0 arch/arm/dts/k3-j7200-binman.dtsi | 95 +- arch/arm/dts/k3-j721e-binman.dtsi | 201 +- 2 files changed, 294 insertions(+), 2 deletions(-) -- 2.34.1
[PATCH 1/2] arm: dts: k3-j721e-binman: Add support for HSSE2.0 and HSFS1.1
J721E has SR1.1 and SR2.0 having three variants of each GP, HS-FS and
HS-SE. Current build does not generate HS-SE SR2.0 and HS-FS SR1.1 so
add support for them.
Reported-by: Suman Anna
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-j721e-binman.dtsi | 201 +-
1 file changed, 200 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..90e4a31329e 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2024 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-binman.dtsi"
@@ -129,6 +129,205 @@
};
};
+ {
+ tiboot3-j721e_sr2-hs-evm.bin {
+ filename = "tiboot3-j721e_sr2-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_sr2>;
+ core = "public";
+ core-opts = <2>;
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl_sr2: u-boot-spl {
+ no-expanded;
+ };
+ };
+ sysfw_sr2 {
+ filename = "sysfw.bin_sr2";
+ ti-secure-rom {
+ content = <_fs_cert_sr2>;
+ core = "secure";
+ load = <0x4>;
+ keyfile = "custMpk.pem";
+ countersign;
+ };
+ ti_fs_cert_sr2: ti-fs-cert.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-fs-firmware-j721e_sr2-hs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+ itb_sr2 {
+ filename = "sysfw-j721e_sr2-hs-evm.itb";
+ fit {
+ description = "SYSFW and Config fragments";
+ #address-cells = <1>;
+ images {
+ sysfw.bin {
+ description = "sysfw";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ blob-ext {
+ filename = "sysfw.bin_sr2";
+ };
+ };
+ board-cfg.bin {
+ description = "board-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <_cfg_sr2>;
+ keyfile = "custMpk.pem";
+ };
+ board_cfg_sr2: board-cfg {
+ filename = "board-cfg.bin";
+ type = "blob-ext";
+ };
+
+ };
+ pm-cfg.bin {
+ description = "pm-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <_cfg_sr2>;
+ keyfile = "custMpk.pem";
+ };
+ pm_cfg_sr2: pm-cfg {
+ filename = "pm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+ rm-cfg.bin {
+ description = "rm-cfg&qu
Re: [PATCH 0/4] Cleanup K3 binman templating
Hi Tom, On 12-Apr-24 8:20 PM, Tom Rini wrote: On Fri, Mar 22, 2024 at 06:40:07PM +0530, Neha Malcom Francis wrote: This series does primarily three things: 1. Split out the common J721E defconfig for both EVM and SK 2. Cleanup k3-j721e-binman.dtsi to be SoC specific binman nodes and -u-boot.dtsi files of the respective boards can pick and edit according to their board. This is based on the discussion [1] and this is the primary goal of this series 3. Move J721E EVM and SK to using OF_UPSTREAM This series depends on series [2] and patch [3] which implement OF_UPSTREAM. Also received input from Nishanth to clean up the unnecessary artifacts in the final build directory (maybe populate them in another directory), working on that as well but didn't want to delay v1 further considering I'm modifying a bunch of board builds and would like some friendly build tests and boot tests for them. Please rebase this on top of current master, thanks. Will send out v2! -- Thanking You Neha Malcom Francis
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Michael On 05/04/24 13:12, Michael Walle wrote: Hi, On Thu Apr 4, 2024 at 11:10 AM CEST, Neha Malcom Francis wrote: But again in the interest of time... this would mean this cleaning up effort be kept on hold. If we can agree to move to using the generator later as the final solution, can we pick up this series for now? Agreed. I just saw the new RFC for the j722s support. It should also make use of this cleanup then, btw. Right, I'll sync with J722S efforts as well. So is this series good to go? -michael -- Thanking You Neha Malcom Francis
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
hen, I had seen your ping on IRC [1], putting it here for the others
as well.
As I see it, it's not like we are making the fdt-0 non overridable, you
can still override it in your configs to make it cleaner if you want for
your board template, I don't think that -
Though it is not overriding but rather merging, correct? So one
would need to first erase the node just to create it again. Which
looks more like a workaround.
tispl {
insert-template = <_spl>;
fit {
images {
fdt-0 {
...
};
fdt-1 {
...
};
};
configurations {
conf-0 {
...
};
conf-1 {
...
};
};
};
};
is not doable. It might be a bit duplicate but if I think about it but
we are not losing out on extending the templates for multiple DTBs even
with this design. I know it might not be what you want but I feel that
for single DTB it's really convenient with the macro stuff and we don't
have to override any of the other binman nodes.
I've raised my concern about stuffing board dependent stuff into the
now generic "k3--binman.dtsi". I get it that it will work for
90% of the boards and that it is very convenient. I'd have rather
seen a split of lets say
k3--binman.dtsi
and
k3-one-dtb-template-binman.dtsi
All the generic stuff goes into k3-soc-binman.dtsi whereas 90% of
the boards might still use the second dtsi with some define magic.
But it seems you've already made your mind up on that :)
-michael
My hope would be that we can get rid of board-specific binman configuration in
the common case
altogether for the K3 SoC families, using @fdt-SEQ etc. generator sections that
will just include
all FDTs configured in Kconfig.
A while ago [1], this was blocked on ti-secure signing not working with
generator sections, and
according to my experiments, this is still the case in U-Boot 2024.01 (and
looking at the Git log,
also 2024.04/master/next). Are there still plans to make this work? Are there
any other blockers?
Best regards,
Matthias
[1] https://lists.denx.de/pipermail/u-boot/2023-July/525095.html
Yeah! This was a series that I pushed away to the side when runtime multi-DTB
selection was removed. You're right, this seems like the only way we can come to
a common ground.
Let me see if I can bring it back up again, the last blocker was signing not
working with the generator as you mentioned.
But again in the interest of time... this would mean this cleaning up effort be
kept on hold. If we can agree to move to using the generator later as the final
solution, can we pick up this series for now?
--
Thanking You
Neha Malcom Francis
Re: [PATCH 2/2] arm: dts: k3: binman: am625: add support for signing TIFSSTUB Images
arm32";
+ compression = "none";
+ os = "tifsstub-gp";
+ load = <0x9dc0>;
+ entry = <0x9dc0>;
+ blob-ext {
+ filename = "tifsstub.bin_gp";
+ };
+ };
+
dm {
ti-secure {
content = <>;
@@ -189,7 +285,8 @@
conf-0 {
description = "k3-am625-sk";
firmware = "atf";
- loadables = "tee", "dm", "spl";
+ loadables = "tee", "tifsstub-hs",
"tifsstub-fs",
+ "tifsstub-gp", "dm", "spl";
fdt = "fdt-0";
};
};
@@ -247,6 +344,45 @@
fit {
images {
+tifsstub-hs {
+ description = "tifsstub";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-hs";
+ load = <0x9dc0>;
+ entry = <0x9dc0>;
+ blob-ext {
+ filename = "tifsstub.bin_hs";
+ };
+ };
+
+ tifsstub-fs {
+ description = "tifsstub";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-fs";
+ load = <0x9dc0>;
+ entry = <0x9dc0>;
+ blob-ext {
+ filename = "tifsstub.bin_fs";
+ };
+ };
+
+ tifsstub-gp {
+ description = "tifsstub";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-gp";
+ load = <0x9dc0>;
+ entry = <0x9dc0>;
+ blob-ext {
+ filename = "tifsstub.bin_gp";
+ };
+ };
+
dm {
ti-dm {
filename = "ti-dm.bin";
@@ -270,7 +406,8 @@
conf-0 {
description = "k3-am625-sk";
firmware = "atf";
- loadables = "tee", "dm", "spl";
+ loadables = "tee", "tifsstub-hs",
"tifsstub-fs",
+ "tifsstub-gp", "dm", "spl";
fdt = "fdt-0";
};
};
If there are multiple boards that will support TIFSSTUB in future, I would
prefer templating these out and putting them in k3-binman.dtsi. However
considering there's a lot of movement currently (cleanup and OF_STREAM) in that
file, you can maybe take this up when adding support for the next board.
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 1/2] arm: mach-k3: add support for detecting TIFSSTUB images
Hi Dhruva,
On 03/04/24 17:33, Dhruva Gole wrote:
From: Kamlesh Gurudasani
Add support for detecting and processing TIFSSTUB images for HS, HSFS
and GP devices.
TIFSSTUB image for related device type will be loaded, rest TIFSSTUB
images will be discarded.
Example, for GP device, tifsstub-gp will be loaded, tifsstub-hs and
tifsstub-fs will be discarded.
Signed-off-by: Kamlesh Gurudasani
Signed-off-by: Dhruva Gole
---
arch/arm/mach-k3/r5/common.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
index c02f8d330998..0f6c294f1eb2 100644
--- a/arch/arm/mach-k3/r5/common.c
+++ b/arch/arm/mach-k3/r5/common.c
@@ -24,6 +24,9 @@ enum {
IMAGE_ID_OPTEE,
IMAGE_ID_SPL,
IMAGE_ID_DM_FW,
+ IMAGE_ID_TIFSSTUB_HS,
+ IMAGE_ID_TIFSSTUB_FS,
+ IMAGE_ID_T,
IMAGE_AMT,
};
@@ -33,6 +36,9 @@ static const char *image_os_match[IMAGE_AMT] = {
"tee",
"U-Boot",
"DM",
+ "tifsstub-hs",
+ "tifsstub-fs",
+ "tifsstub-gp",
};
#endif
@@ -314,6 +320,24 @@ void board_fit_image_post_process(const void *fit, int node, void **p_image,
break;
}
}
+
+ if (i < IMAGE_AMT && i > IMAGE_ID_DM_FW) {
+ int device_type = get_device_type();
+
+ if ((device_type == K3_DEVICE_TYPE_HS_SE &&
+strcmp(os, "tifsstub-hs")) ||
+ (device_type == K3_DEVICE_TYPE_HS_FS &&
+strcmp(os, "tifsstub-fs")) ||
+ (device_type == K3_DEVICE_TYPE_GP &&
+strcmp(os, "tifsstub-gp"))) {
+ *p_size = 0;
+ } else {
+ debug("tifsstub-type: %s\n", os);
+ }
+
+ return;
+ }
+
/*
* Only DM and the DTBs are being authenticated here,
* rest will be authenticated when A72 cluster is up
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH v1] verdin-am62: move verdin am62 to OF_UPSTREAM
Hi Marcel, On 03/04/24 12:45, Marcel Ziswiler wrote: From: Marcel Ziswiler Move verdin-am62 to OF_UPSTREAM: - handle the fact that dtbs now have a 'ti/' prefix - imply OF_UPSTREAM - remove redundant files from arch/arm/dts leaving only the *-u-boot.dtsi files - update MAINTAINERS file Signed-off-by: Marcel Ziswiler --- arch/arm/dts/Makefile |1 - arch/arm/dts/k3-am62-verdin-dev.dtsi | 240 --- arch/arm/dts/k3-am62-verdin-wifi.dtsi | 45 - arch/arm/dts/k3-am62-verdin.dtsi | 1443 - .../dts/k3-am625-verdin-wifi-dev-binman.dtsi |2 +- arch/arm/dts/k3-am625-verdin-wifi-dev.dts | 22 - arch/arm/mach-k3/am62x/Kconfig|1 + board/toradex/verdin-am62/MAINTAINERS |4 - configs/verdin-am62_a53_defconfig |2 +- 9 files changed, 3 insertions(+), 1757 deletions(-) delete mode 100644 arch/arm/dts/k3-am62-verdin-dev.dtsi delete mode 100644 arch/arm/dts/k3-am62-verdin-wifi.dtsi delete mode 100644 arch/arm/dts/k3-am62-verdin.dtsi delete mode 100644 arch/arm/dts/k3-am625-verdin-wifi-dev.dts [...] Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH 2/2] arm: dts: k3: Remove unneeded ti, sci-sysreset binding and nodes
Hi Andrew, On 02/04/24 21:39, Andrew Davis wrote: This extra binding is non-standard and now unneeded as we bind the sysreset driver automatically. This matches what is done in Linux and allows us to more closely match the DTBs. Remove the binding and all users. Signed-off-by: Andrew Davis --- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 7 - .../k3-am625-phyboard-lyra-rdk-u-boot.dtsi| 7 - .../dts/k3-am625-verdin-wifi-dev-u-boot.dtsi | 7 - arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 4 --- arch/arm/dts/k3-am62p5-sk-u-boot.dtsi | 5 arch/arm/dts/k3-am642-evm-u-boot.dtsi | 7 - .../k3-am642-phyboard-electra-rdk-u-boot.dtsi | 4 --- arch/arm/dts/k3-am642-sk-u-boot.dtsi | 7 - .../dts/k3-am65-iot2050-common-u-boot.dtsi| 4 --- .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 4 --- arch/arm/dts/k3-am69-sk-u-boot.dtsi | 7 - .../k3-j7200-common-proc-board-u-boot.dtsi| 4 --- .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 4 --- .../k3-j721e-common-proc-board-u-boot.dtsi| 4 --- arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 4 --- .../k3-j721s2-common-proc-board-u-boot.dtsi | 4 --- arch/arm/dts/k3-j784s4-evm-u-boot.dtsi| 7 - .../sysreset/ti,sci-sysreset.txt | 29 --- 18 files changed, 119 deletions(-) delete mode 100644 doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt [...] Reviewed-by: Neha Malcom Francis Why not have Kconfig set this as default y if TI_SCI_PROTOCOL set using same argument? -- Thanking You Neha Malcom Francis
Re: [PATCH 1/2] firmware: ti_sci: Bind sysreset driver when enabled
Hi Andrew
On 02/04/24 21:39, Andrew Davis wrote:
The sysreset TI-SCI API is available with TI-SCI always, there is no need
for a DT node to describe the availability of this. If the sysreset driver
is available then bind it during ti-sci probe.
Remove the unneeded device tree matching.
Signed-off-by: Andrew Davis
---
drivers/firmware/ti_sci.c | 7 +++
drivers/sysreset/sysreset-ti-sci.c | 6 --
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index ee092185588..6c581b9df9c 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2840,6 +2841,12 @@ static int ti_sci_probe(struct udevice *dev)
INIT_LIST_HEAD(>dev_list);
+ if (IS_ENABLED(CONFIG_SYSRESET_TI_SCI)) {
+ ret = device_bind_driver(dev, "ti-sci-sysreset", "sysreset",
NULL);
+ if (ret)
+ dev_warn(dev, "cannot bind SYSRESET (ret = %d)\n", ret);
+ }
+
return 0;
}
diff --git a/drivers/sysreset/sysreset-ti-sci.c b/drivers/sysreset/sysreset-ti-sci.c
index 5fc05c46cb0..0de132633a8 100644
--- a/drivers/sysreset/sysreset-ti-sci.c
+++ b/drivers/sysreset/sysreset-ti-sci.c
@@ -60,15 +60,9 @@ static struct sysreset_ops ti_sci_sysreset_ops = {
.request = ti_sci_sysreset_request,
};
-static const struct udevice_id ti_sci_sysreset_of_match[] = {
- { .compatible = "ti,sci-sysreset", },
- { /* sentinel */ },
-};
-
U_BOOT_DRIVER(ti_sci_sysreset) = {
.name = "ti-sci-sysreset",
.id = UCLASS_SYSRESET,
- .of_match = ti_sci_sysreset_of_match,
.probe = ti_sci_sysreset_probe,
.priv_auto = sizeof(struct ti_sci_sysreset_data),
.ops = _sci_sysreset_ops,
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Michael Sorry for the late response. On 28/03/24 17:26, Michael Walle wrote: Hi, On Thu Mar 28, 2024 at 12:18 PM CET, Neha Malcom Francis wrote: On 27-Mar-24 8:03 PM, Michael Walle wrote: On Wed Mar 27, 2024 at 8:01 AM CET, Neha Malcom Francis wrote: On 26/03/24 19:18, Michael Walle wrote: On Fri Mar 22, 2024 at 2:10 PM CET, Neha Malcom Francis wrote: Clean up templatized boot binaries for all K3 boards. This includes modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse code. All k3--binman.dtsi will contain only templates. Only required boot binaries can be built from the templates in the boards' respective -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows clear distinction between the SoC common stuff vs. what is additionally needed to boot up a specific board. I appreciate the cleanup. But as far as I can see, a board might only have one device tree. How would that work if the uboot proper must support multiple device trees? From the discussions that took place in the mailing list [1] the consensus seems to be to not focus on multiple devicetree support as it leads to confusion for downstream users. What are users in this regard? I don't think you'd confuse developers. Anyway, I'm planning on upstreaming a TI board which will have different memory configurations and different variants of the board. I am assuming you are reusing an existing TI SoC? Not really yet. It's the j722s. And on top of that, it will just be a base board and there will likely be some carrier device trees (overlay? I'm not sure yet). As far as I can tell, you've put the memory configuration into the device tree, so I'll probably need to switch between them somehow. The "k3--ddr.dtsi" file will be present in your k3-r5.dts which makes sense, the memory configuration depends on the board. k3--ddr.dtsi* (e.g J721E EVM vs. SK boards consume different memory configurations. And one board might have multiple configuration depending on the variant of the board. Typically, one board is available with different memory options. i.e. 1GiB, 4GiB and so on. The actual RAM chips can come from different manufacturers. So all all, I presume there will be different RAM settings, i.e. different k3--ddr.dtsi. But I have to switch between the setting during runtime because there will be only one boot image for that board. This is a runtime dynamic DDR configuration support you are describing correct? This means you would be including all the supported memory option DTSIs in your k3--r5.dts correct and probably do some board magic code in the SPL DDR driver to choose the DTB. How is this affecting the packing of the final bootloader which will anyways pack the whole R5 DTB? Also, regarding the board variants, I'll probably need to choose between multiple device trees. That is invisible to the user, because u-boot will choose the correct DTB according a board strapping, which btw. works really fine, see for example (boards/kontron/sl28/spl.c:board_fit_config_name_match). Again, this is assuming that there is some HW blown register available for the board to use (or in our earlier K3 case, the EEPROM) but that is not necessarily true every time. No, that is of course board dependent. It is just an example that there are boards with more than one DTB. Let's step back a bit. Right now, there is k3---binman.dtsi which is fine. But it seems, that TI is heading towards a common k3--binman.dtsi which is intended to be used by all the boards that are using that particular SoC, correct me if I'm wrong here. Now the problem with that is that you hardcode the FIT configuations which are really board dependent and assume that there will be exactly one DTB per board, i.e. your "#define SPL_BOARD_DTB" etc. Correct, but as I mentioned in the earlier message, if your board supports more than 1 FIT configuration, you can easily extend the image and add more configurations. Thus, what I was trying to say is that you should split all the board independent configuration (dt fragments) from the board specific configuration. And again, of course I could just ignore the k3--binman.dtsi and just use a suitable copy "k3---binman.dtsi" for my board. But as I said, I'm not sure, this is the way to go and I have a slight feeling I will be asked to reuse the "k3--binman.dtsi" when I submit my board support. I don't think it makes much sense to hardcode your generic *-binman.dtsi to just one FIT configuration. I'd rather see a split between generic things which are shared across all boards and board specifics, like the FIT configuration. I mean I could just copy all Correct me if I'm wrong, but my understanding is that you would want to add more FDT blobs in the *-binman.dtsi correct? That is still possible, adding another "fdt-1" and "conf-1&qu
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Michael
On 27-Mar-24 8:03 PM, Michael Walle wrote:
Hi,
On Wed Mar 27, 2024 at 8:01 AM CET, Neha Malcom Francis wrote:
On 26/03/24 19:18, Michael Walle wrote:
On Fri Mar 22, 2024 at 2:10 PM CET, Neha Malcom Francis wrote:
Clean up templatized boot binaries for all K3 boards. This includes
modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
code.
All k3--binman.dtsi will contain only templates. Only required boot
binaries can be built from the templates in the boards' respective
-u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows
clear distinction between the SoC common stuff vs. what is additionally
needed to boot up a specific board.
I appreciate the cleanup. But as far as I can see, a board might
only have one device tree. How would that work if the uboot proper
must support multiple device trees?
From the discussions that took place in the mailing list [1] the consensus
seems to be to not focus on multiple devicetree support as it leads to confusion
for downstream users.
What are users in this regard? I don't think you'd confuse
developers.
Anyway, I'm planning on upstreaming a TI board which will have
different memory configurations and different variants of the board.
I am assuming you are reusing an existing TI SoC?
And on top of that, it will just be a base board and there will
likely be some carrier device trees (overlay? I'm not sure yet).
As far as I can tell, you've put the memory configuration into the
device tree, so I'll probably need to switch between them somehow.
The "k3--ddr.dtsi" file will be present in your k3-r5.dts
which makes sense, the memory configuration depends on the board.
Also, regarding the board variants, I'll probably need to choose
between multiple device trees. That is invisible to the user,
because u-boot will choose the correct DTB according a board
strapping, which btw. works really fine, see for example
(boards/kontron/sl28/spl.c:board_fit_config_name_match).
Again, this is assuming that there is some HW blown register available
for the board to use (or in our earlier K3 case, the EEPROM) but that is
not necessarily true every time.
I don't think it makes much sense to hardcode your generic
*-binman.dtsi to just one FIT configuration. I'd rather see a split
between generic things which are shared across all boards and board
specifics, like the FIT configuration. I mean I could just copy all
Correct me if I'm wrong, but my understanding is that you would want to
add more FDT blobs in the *-binman.dtsi correct? That is still possible,
adding another "fdt-1" and "conf-1" in the
Something like this in your -u-boot.dtsi,
tispl {
insert-template = <_spl>;
fit {
images {
fdt-1 {
...
};
};
configurations {
conf-1 {
...
};
};
};
};
provided you have the support to handle this multi-dtb FIT. But as far
as reusing the k3-binman.dtsi and k3--binman.dtsi goes; you should
be able to do it.
the binman and tiboot3.bin and tispl.bin magic and put it into my
own "-u-boot.dtsi". But I'm not sure that will make things any
better.
-michael
--
Thanking You
Neha Malcom Francis
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Michael On 26/03/24 19:18, Michael Walle wrote: Hi, On Fri Mar 22, 2024 at 2:10 PM CET, Neha Malcom Francis wrote: Clean up templatized boot binaries for all K3 boards. This includes modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse code. All k3--binman.dtsi will contain only templates. Only required boot binaries can be built from the templates in the boards' respective -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows clear distinction between the SoC common stuff vs. what is additionally needed to boot up a specific board. I appreciate the cleanup. But as far as I can see, a board might only have one device tree. How would that work if the uboot proper must support multiple device trees? From the discussions that took place in the mailing list [1] the consensus seems to be to not focus on multiple devicetree support as it leads to confusion for downstream users. Thanks, -michael [1] https://lore.kernel.org/all/20230908183124.27zctk6ishfd7ics@canopener/ -- Thanking You Neha Malcom Francis
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Nishanth On 26/03/24 17:57, Nishanth Menon wrote: On 18:40-20240322, Neha Malcom Francis wrote: Clean up templatized boot binaries for all K3 boards. This includes modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse code. All k3--binman.dtsi will contain only templates. Only required boot binaries can be built from the templates in the boards' respective -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows clear distinction between the SoC common stuff vs. what is additionally needed to boot up a specific board. Signed-off-by: Neha Malcom Francis --- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 161 +- arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 + arch/arm/dts/k3-am625-r5-beagleplay.dts | 39 --- arch/arm/dts/k3-am625-sk-binman.dtsi | 148 + arch/arm/dts/k3-am625-sk-u-boot.dtsi | 42 +++ .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 296 +- arch/arm/dts/k3-am62a-sk-binman.dtsi | 146 + arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am642-sk-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am64x-binman.dtsi | 239 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 49 +++ arch/arm/dts/k3-am65x-binman.dtsi | 144 + .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 26 ++ arch/arm/dts/k3-am69-sk-u-boot.dtsi | 31 +- arch/arm/dts/k3-binman.dtsi | 96 ++ arch/arm/dts/k3-j7200-binman.dtsi | 145 + .../k3-j7200-common-proc-board-u-boot.dtsi| 40 +++ .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 154 + arch/arm/dts/k3-j721e-binman.dtsi | 262 +++- .../k3-j721e-common-proc-board-u-boot.dtsi| 84 + arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 91 +- arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 84 + arch/arm/dts/k3-j721s2-binman.dtsi| 231 +- .../k3-j721s2-common-proc-board-u-boot.dtsi | 42 +++ arch/arm/dts/k3-j784s4-binman.dtsi| 154 + arch/arm/dts/k3-j784s4-evm-u-boot.dtsi| 42 +++ 27 files changed, 858 insertions(+), 2305 deletions(-) diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi index cca0f44b7d8..fc1898f1510 100644 --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi @@ -6,7 +6,11 @@ * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation */ -#include "k3-binman.dtsi" +#define SPL_BOARD_DTB "spl/dts/k3-am625-beagleplay.dtb" +#define BOARD_DESCRIPTION "k3-am625-beagleplay" +#define UBOOT_BOARD_DESCRIPTION "U-Boot for AM625 BeaglePlay" + +#include "k3-am625-sk-binman.dtsi" Drop the "sk" ? Yes Andrew had pointed it out earlier, will make the change in the next version. -- Thanking You Neha Malcom Francis
Re: [PATCH] tools: binman: ti_board_cfg: improve error message
Hi Michael,
On 26/03/24 15:09, Michael Walle wrote:
When there is a lint error the user gets the following cryptic message:
binman: Node '/path/to/some/node': Yamllint error: 18: comments
This isn't very helpful. Improve the message to tell the user that the
number is actually a line number and also tell the user in which file
they have to look.
Signed-off-by: Michael Walle
---
tools/binman/etype/ti_board_config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/etype/ti_board_config.py
b/tools/binman/etype/ti_board_config.py
index 2c3bb8f7b56..c10d66edcb1 100644
--- a/tools/binman/etype/ti_board_config.py
+++ b/tools/binman/etype/ti_board_config.py
@@ -248,7 +248,7 @@ class Entry_ti_board_config(Entry_section):
yaml_config = config.YamlLintConfig("extends: default")
for p in yamllint.linter.run(open(self._config_file, "r"),
yaml_config):
-self.Raise(f"Yamllint error: {p.line}: {p.rule}")
+self.Raise(f"Yamllint error: Line {p.line} in {self._config_file}:
{p.rule}")
try:
validate(self.file_yaml, self.schema_yaml)
except Exception as e:
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH] binman: ti-secure: Enable debug extension for combined boot
Hi Manorit
On 26/03/24 13:37, Manorit Chawdhry wrote:
To debug using jtag, ROM needs to unlock jtag debugging on HS devices
and it does that looking at this debug extension.
Add the debug extension and enable it by default.
Link:
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/sec_cert_format.html?highlight=debug#sysfw-debug-ext
Signed-off-by: Manorit Chawdhry
---
Keeping this enabled by default as this is enabled for non-combined boot
as well by default.
---
tools/binman/btool/openssl.py | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index fe81a1f51b1e..c6df64c5316d 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -283,6 +283,7 @@ emailAddress =
{req_dist_name_dict['emailAddress']}
basicConstraints = CA:true
1.3.6.1.4.1.294.1.3=ASN1:SEQUENCE:swrv
1.3.6.1.4.1.294.1.9=ASN1:SEQUENCE:ext_boot_info
+1.3.6.1.4.1.294.1.8=ASN1:SEQUENCE:debug
[swrv]
swrv=INTEGER:{sw_rev}
@@ -323,6 +324,12 @@ compSize = INTEGER:{imagesize_sysfw_data}
shaType = OID:{sha_type}
shaValue = FORMAT:HEX,OCT:{hashval_sysfw_data}
+[ debug ]
+debugUID =
FORMAT:HEX,OCT:
+debugType = INTEGER:4
+coreDbgEn = INTEGER:0
+coreDbgSecEn = INTEGER:0
+
{sysfw_inner_cert_ext_boot_block}
{dm_data_ext_boot_block}
---
base-commit: fb49d6c289d942ff7de309a5c5eaa37a7f4235db
change-id: 20240326-b4-upstream-jtag-debug-unlock-6fc21e344cfb
Best regards,
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Manorit
On 25/03/24 14:50, Manorit Chawdhry wrote:
Hi Neha,
On 18:40-20240322, Neha Malcom Francis wrote:
Clean up templatized boot binaries for all K3 boards. This includes
modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
code.
All k3--binman.dtsi will contain only templates. Only required boot
binaries can be built from the templates in the boards' respective
-u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows
clear distinction between the SoC common stuff vs. what is additionally
needed to boot up a specific board.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 161 +-
arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 +
arch/arm/dts/k3-am625-r5-beagleplay.dts | 39 ---
arch/arm/dts/k3-am625-sk-binman.dtsi | 148 +
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 42 +++
.../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 296 +-
arch/arm/dts/k3-am62a-sk-binman.dtsi | 146 +
arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 42 +++
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 +++
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 42 +++
arch/arm/dts/k3-am64x-binman.dtsi | 239 +-
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 49 +++
arch/arm/dts/k3-am65x-binman.dtsi | 144 +
.../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 26 ++
arch/arm/dts/k3-am69-sk-u-boot.dtsi | 31 +-
arch/arm/dts/k3-binman.dtsi | 96 ++
arch/arm/dts/k3-j7200-binman.dtsi | 145 +
.../k3-j7200-common-proc-board-u-boot.dtsi| 40 +++
.../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 154 +
arch/arm/dts/k3-j721e-binman.dtsi | 262 +++-
.../k3-j721e-common-proc-board-u-boot.dtsi| 84 +
arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 91 +-
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 84 +
arch/arm/dts/k3-j721s2-binman.dtsi| 231 +-
.../k3-j721s2-common-proc-board-u-boot.dtsi | 42 +++
arch/arm/dts/k3-j784s4-binman.dtsi| 154 +
arch/arm/dts/k3-j784s4-evm-u-boot.dtsi| 42 +++
27 files changed, 858 insertions(+), 2305 deletions(-)
[ snip ]
diff --git a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
index ed50bfeb031..14fc8468c56 100644
--- a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
+++ b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
@@ -6,309 +6,48 @@
* Author: Wadim Egorov
*/
-#include "k3-binman.dtsi"
+#define SPL_BOARD_DTB "spl/dts/k3-am625-phyboard-lyra-rdk.dtb"
+#define BOARD_DESCRIPTION "k3-am625-phyboard-lyra-rdk"
+#define UBOOT_BOARD_DESCRIPTION "U-Boot for phyCORE-AM62x"
+
+#include "k3-am625-sk-binman.dtsi"
#ifdef CONFIG_TARGET_PHYCORE_AM62X_R5
{
tiboot3-am62x-hs-phycore-som.bin {
filename = "tiboot3-am62x-hs-phycore-som.bin";
- ti-secure-rom {
- content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
- <_dm_cfg>, <_inner_cert>;
- combined;
- dm-data;
- sysfw-inner-cert;
- keyfile = "custMpk.pem";
- sw-rev = <1>;
- content-sbl = <_boot_spl>;
- content-sysfw = <_fs_enc>;
- content-sysfw-data = <_tifs_cfg>;
- content-sysfw-inner-cert = <_inner_cert>;
- content-dm-data = <_dm_cfg>;
I was looking between SoCs that we have and all this data seems common
to me on first glance, like there is only some delta in tiboot3
templates as well and maybe we can minimise those as well if am not
missing anything.
in k3-binman.dtsi:
tiboot3_combined_gp: template-x {
section {
ti-secure-rom {
content = <_boot_spl_unsigned>, <_fs_gp>,
<_tifs_cfg_gp>, <_dm_cfg_gp>;
combined;
dm-data;
content-sbl = <_boot_spl_unsigned>;
content-sysfw = <_fs_gp>;
content-sysfw-data = <_tifs_cfg_gp>;
content-dm-data = <_dm_cfg_gp>;
sw-rev = <1>;
keyfile = "ti-degenerate-key.pem";
};
u_boot_spl_unsigned: u-boot-spl {
no-expanded;
};
ti_fs_gp: ti-fs-gp.bin {
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Andrew On 23/03/24 21:37, Andrew Davis wrote: On 3/22/24 8:10 AM, Neha Malcom Francis wrote: Clean up templatized boot binaries for all K3 boards. This includes modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse code. All k3--binman.dtsi will contain only templates. Only required boot binaries can be built from the templates in the boards' respective -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows clear distinction between the SoC common stuff vs. what is additionally needed to boot up a specific board. Signed-off-by: Neha Malcom Francis --- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 161 +- arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 + arch/arm/dts/k3-am625-r5-beagleplay.dts | 39 --- arch/arm/dts/k3-am625-sk-binman.dtsi | 148 + arch/arm/dts/k3-am625-sk-u-boot.dtsi | 42 +++ .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 296 +- arch/arm/dts/k3-am62a-sk-binman.dtsi | 146 + arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am642-sk-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am64x-binman.dtsi | 239 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 49 +++ arch/arm/dts/k3-am65x-binman.dtsi | 144 + .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 26 ++ arch/arm/dts/k3-am69-sk-u-boot.dtsi | 31 +- arch/arm/dts/k3-binman.dtsi | 96 ++ arch/arm/dts/k3-j7200-binman.dtsi | 145 + .../k3-j7200-common-proc-board-u-boot.dtsi | 40 +++ .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 154 + arch/arm/dts/k3-j721e-binman.dtsi | 262 +++- .../k3-j721e-common-proc-board-u-boot.dtsi | 84 + arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 91 +- arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 84 + arch/arm/dts/k3-j721s2-binman.dtsi | 231 +- .../k3-j721s2-common-proc-board-u-boot.dtsi | 42 +++ arch/arm/dts/k3-j784s4-binman.dtsi | 154 + arch/arm/dts/k3-j784s4-evm-u-boot.dtsi | 42 +++ 27 files changed, 858 insertions(+), 2305 deletions(-) diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi index cca0f44b7d8..fc1898f1510 100644 --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi @@ -6,7 +6,11 @@ * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation */ -#include "k3-binman.dtsi" +#define SPL_BOARD_DTB "spl/dts/k3-am625-beagleplay.dtb" +#define BOARD_DESCRIPTION "k3-am625-beagleplay" +#define UBOOT_BOARD_DESCRIPTION "U-Boot for AM625 BeaglePlay" + +#include "k3-am625-sk-binman.dtsi" Why is the BeaglePlay board including the SK binman file? Looks like you made `k3-am625-sk-binman.dtsi` into the SoC general file, which is good, but you should probably also rename it here to match: `k3-am625-binman.dtsi`. Andrew Yes intention was that it's going to be the SoC file, didn't catch on the filename, will change it in v2. Thanks! -- Thanking You Neha Malcom Francis
[PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Clean up templatized boot binaries for all K3 boards. This includes
modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
code.
All k3--binman.dtsi will contain only templates. Only required boot
binaries can be built from the templates in the boards' respective
-u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows
clear distinction between the SoC common stuff vs. what is additionally
needed to boot up a specific board.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 161 +-
arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 +
arch/arm/dts/k3-am625-r5-beagleplay.dts | 39 ---
arch/arm/dts/k3-am625-sk-binman.dtsi | 148 +
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 42 +++
.../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 296 +-
arch/arm/dts/k3-am62a-sk-binman.dtsi | 146 +
arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 42 +++
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 +++
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 42 +++
arch/arm/dts/k3-am64x-binman.dtsi | 239 +-
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 49 +++
arch/arm/dts/k3-am65x-binman.dtsi | 144 +
.../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 26 ++
arch/arm/dts/k3-am69-sk-u-boot.dtsi | 31 +-
arch/arm/dts/k3-binman.dtsi | 96 ++
arch/arm/dts/k3-j7200-binman.dtsi | 145 +
.../k3-j7200-common-proc-board-u-boot.dtsi| 40 +++
.../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 154 +
arch/arm/dts/k3-j721e-binman.dtsi | 262 +++-
.../k3-j721e-common-proc-board-u-boot.dtsi| 84 +
arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 91 +-
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 84 +
arch/arm/dts/k3-j721s2-binman.dtsi| 231 +-
.../k3-j721s2-common-proc-board-u-boot.dtsi | 42 +++
arch/arm/dts/k3-j784s4-binman.dtsi| 154 +
arch/arm/dts/k3-j784s4-evm-u-boot.dtsi| 42 +++
27 files changed, 858 insertions(+), 2305 deletions(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index cca0f44b7d8..fc1898f1510 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -6,7 +6,11 @@
* Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
*/
-#include "k3-binman.dtsi"
+#define SPL_BOARD_DTB "spl/dts/k3-am625-beagleplay.dtb"
+#define BOARD_DESCRIPTION "k3-am625-beagleplay"
+#define UBOOT_BOARD_DESCRIPTION "U-Boot for AM625 BeaglePlay"
+
+#include "k3-am625-sk-binman.dtsi"
/ {
chosen {
@@ -61,155 +65,24 @@
>;
};
-#ifdef CONFIG_TARGET_AM625_A53_BEAGLEPLAY
-
-#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
-#define SPL_AM625_BEAGLEPLAY_DTB "spl/dts/k3-am625-beagleplay.dtb"
-#define UBOOT_NODTB "u-boot-nodtb.bin"
-#define AM625_BEAGLEPLAY_DTB "arch/arm/dts/k3-am625-beagleplay.dtb"
+#ifndef CONFIG_ARM64
{
- ti-dm {
- filename = "ti-dm.bin";
- blob-ext {
- filename =
"ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f";
- };
+ tiboot3-am62x-gp {
+ insert-template = <_am62x_gp>;
};
+};
- ti-spl_unsigned {
- filename = "tispl.bin_unsigned";
- pad-byte = <0xff>;
-
- fit {
- description = "Configuration to load ATF and SPL";
- #address-cells = <1>;
-
- images {
-
- atf {
- description = "ARM Trusted Firmware";
- type = "firmware";
- arch = "arm64";
- compression = "none";
- os = "arm-trusted-firmware";
- load = ;
- entry = ;
- atf-bl31 {
- filename = "bl31.bin";
- };
- };
-
- tee {
- description = "OP-TEE";
- type = "tee";
- arch = "arm64";
- compression = "none";
-
[PATCH 2/4] tools: binman: control.py: Delete template nodes after parsing
Dynamically going through the subnode array and deleting leads to
templates being skipped from deletion when templates are consecutive in
the subnode list. Prevent this from happening by first parsing the DT
and then deleting the nodes.
Signed-off-by: Neha Malcom Francis
---
tools/binman/control.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 2f00279232b..1c4e6a581f9 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -522,9 +522,13 @@ def _ProcessTemplates(parent):
def _RemoveTemplates(parent):
"""Remove any templates in the binman description
"""
+del_nodes = []
for node in parent.subnodes:
if node.name.startswith('template'):
-node.Delete()
+del_nodes.append(node)
+
+for node in del_nodes:
+node.Delete()
def PrepareImagesAndDtbs(dtb_fname, select_images, update_fdt, use_expanded):
"""Prepare the images to be processed and select the device tree
--
2.34.1
[PATCH 1/4] configs: j721e_sk: Move to separate defconfig for J721E SK board
Add defconfig for J721E SK R5 and A72 configuration. This includes and modifies the J721E EVM defconfigs: j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig Signed-off-by: Neha Malcom Francis --- board/ti/j721e/MAINTAINERS | 2 ++ configs/j721e_evm_a72_defconfig | 2 +- configs/j721e_evm_r5_defconfig | 2 +- configs/j721e_sk_a72_defconfig | 9 + configs/j721e_sk_r5_defconfig | 10 ++ 5 files changed, 23 insertions(+), 2 deletions(-) create mode 100644 configs/j721e_sk_a72_defconfig create mode 100644 configs/j721e_sk_r5_defconfig diff --git a/board/ti/j721e/MAINTAINERS b/board/ti/j721e/MAINTAINERS index f5ca7d06a34..06aba53d9b0 100644 --- a/board/ti/j721e/MAINTAINERS +++ b/board/ti/j721e/MAINTAINERS @@ -5,5 +5,7 @@ F: board/ti/j721e F: include/configs/j721e_evm.h F: configs/j721e_evm_r5_defconfig F: configs/j721e_evm_a72_defconfig +F: configs/j721e_sk_r5_defconfig +F: configs/j721e_sk_a72_defconfig F: configs/j7200_evm_r5_defconfig F: configs/j7200_evm_a72_defconfig diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 019ddcca7e8..34f7eeebbd5 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -85,7 +85,7 @@ CONFIG_MMC_SPEED_MODE_SET=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -CONFIG_OF_LIST="k3-j721e-common-proc-board k3-j721e-sk" +CONFIG_OF_LIST="k3-j721e-common-proc-board" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index 4d4b96dec6b..49da2550ead 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -81,7 +81,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board k3-j721e-r5-sk" +CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/j721e_sk_a72_defconfig b/configs/j721e_sk_a72_defconfig new file mode 100644 index 000..8907b8ae58f --- /dev/null +++ b/configs/j721e_sk_a72_defconfig @@ -0,0 +1,9 @@ +#include + +CONFIG_ARM=y +CONFIG_ARCH_K3=y +CONFIG_SOC_K3_J721E=y +CONFIG_TARGET_J721E_A72_EVM=y + +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk" +CONFIG_OF_LIST="k3-j721e-sk" diff --git a/configs/j721e_sk_r5_defconfig b/configs/j721e_sk_r5_defconfig new file mode 100644 index 000..b361c691747 --- /dev/null +++ b/configs/j721e_sk_r5_defconfig @@ -0,0 +1,10 @@ +#include + +CONFIG_ARM=y +CONFIG_ARCH_K3=y +CONFIG_SOC_K3_J721E=y +CONFIG_TARGET_J721E_R5_EVM=y + +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-sk" +CONFIG_SPL_OF_LIST="k3-j721e-r5-sk" +CONFIG_OF_LIST="k3-j721e-r5-sk" -- 2.34.1
[PATCH 0/4] Cleanup K3 binman templating
This series does primarily three things: 1. Split out the common J721E defconfig for both EVM and SK 2. Cleanup k3-j721e-binman.dtsi to be SoC specific binman nodes and -u-boot.dtsi files of the respective boards can pick and edit according to their board. This is based on the discussion [1] and this is the primary goal of this series 3. Move J721E EVM and SK to using OF_UPSTREAM This series depends on series [2] and patch [3] which implement OF_UPSTREAM. Also received input from Nishanth to clean up the unnecessary artifacts in the final build directory (maybe populate them in another directory), working on that as well but didn't want to delay v1 further considering I'm modifying a bunch of board builds and would like some friendly build tests and boot tests for them. [1] https://lore.kernel.org/u-boot/20240123205255.i7eynu6vdpoxwybf@irregular/ [2] https://lore.kernel.org/u-boot/20240222093607.3085545-1-sumit.g...@linaro.org/ [3] https://lore.kernel.org/u-boot/20240205-am62px-wip-rebasing-v3-11-04cbb42ea...@ti.com/ Changes since RFC: https://lore.kernel.org/all/20240228112042.3437691-1-n-fran...@ti.com/ - cleaned out FDT descriptions and blobs using macros (Manorit) - modified J721E defconfigs to include missed out configs (Andrew) Boot logs: https://gist.github.com/nehamalcom/07dc7f95173f0bb67a8a26a6b3ab2b00 Neha Malcom Francis (4): configs: j721e_sk: Move to separate defconfig for J721E SK board tools: binman: control.py: Delete template nodes after parsing arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries arm: dts: k3-j721e: Move to OF_UPSTREAM arch/arm/dts/Makefile |4 +- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 161 +- arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 +- arch/arm/dts/k3-am625-r5-beagleplay.dts | 39 - arch/arm/dts/k3-am625-sk-binman.dtsi | 148 +- arch/arm/dts/k3-am625-sk-u-boot.dtsi | 42 + .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 296 +- arch/arm/dts/k3-am62a-sk-binman.dtsi | 146 +- arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 42 + arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 + arch/arm/dts/k3-am642-sk-u-boot.dtsi | 42 + arch/arm/dts/k3-am64x-binman.dtsi | 239 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 49 + arch/arm/dts/k3-am65x-binman.dtsi | 144 +- .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 26 + arch/arm/dts/k3-am69-sk-u-boot.dtsi | 31 +- arch/arm/dts/k3-binman.dtsi | 96 + arch/arm/dts/k3-j7200-binman.dtsi | 145 +- .../k3-j7200-common-proc-board-u-boot.dtsi| 40 + .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 154 +- arch/arm/dts/k3-j721e-binman.dtsi | 262 +- .../k3-j721e-common-proc-board-u-boot.dtsi| 84 + arch/arm/dts/k3-j721e-common-proc-board.dts | 976 -- arch/arm/dts/k3-j721e-main.dtsi | 2741 - arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 681 arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 91 +- arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 84 + arch/arm/dts/k3-j721e-sk.dts | 1074 --- arch/arm/dts/k3-j721e-som-p0.dtsi | 446 --- arch/arm/dts/k3-j721e-thermal.dtsi| 75 - arch/arm/dts/k3-j721e.dtsi| 176 -- arch/arm/dts/k3-j721s2-binman.dtsi| 231 +- .../k3-j721s2-common-proc-board-u-boot.dtsi | 42 + arch/arm/dts/k3-j784s4-binman.dtsi| 154 +- arch/arm/dts/k3-j784s4-evm-u-boot.dtsi| 42 + board/ti/j721e/MAINTAINERS|2 + configs/j721e_evm_a72_defconfig |5 +- configs/j721e_evm_r5_defconfig|2 +- configs/j721e_sk_a72_defconfig|9 + configs/j721e_sk_r5_defconfig | 10 + tools/binman/control.py |6 +- 41 files changed, 889 insertions(+), 8481 deletions(-) delete mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts delete mode 100644 arch/arm/dts/k3-j721e-main.dtsi delete mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi delete mode 100644 arch/arm/dts/k3-j721e-sk.dts delete mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi delete mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi delete mode 100644 arch/arm/dts/k3-j721e.dtsi create mode 100644 configs/j721e_sk_a72_defconfig create mode 100644 configs/j721e_sk_r5_defconfig -- 2.34.1
Re: [PATCH v10 12/15] arm: dts: Introduce am69-sk u-boot dts files
+ <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;
+};
+
+ {
+ k3_sysreset: sysreset-controller {
+ compatible = "ti,sci-sysreset";
+ bootph-pre-ram;
+ };
+};
+
+#ifdef CONFIG_TARGET_J784S4_A72_EVM
+
+#define SPL_AM69_SK_DTB "spl/dts/ti/k3-am69-sk.dtb"
+#define AM69_SK_DTB "u-boot.dtb"
+
+_j784s4_evm_dtb {
+ filename = SPL_AM69_SK_DTB;
+};
+
+_evm_dtb {
+ filename = AM69_SK_DTB;
+};
+
+_j784s4_evm_dtb_unsigned {
+ filename = SPL_AM69_SK_DTB;
+};
+
+_evm_dtb_unsigned {
+ filename = AM69_SK_DTB;
+};
+
+#endif
diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index ff00cc60868..8b03a7adb1e 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -8,3 +8,9 @@ F: arch/arm/dts/k3-j784s4-evm-u-boot.dtsi
F:arch/arm/dts/k3-j784s4-r5-evm.dts
F:arch/arm/dts/k3-j784s4-ddr.dtsi
F:arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi
+
+AM69 SK BOARD
+M: Apurva Nandan
+S: Maintained
+F: arch/arm/dts/k3-am69-sk-u-boot.dtsi
+F: arch/arm/dts/k3-am69-r5-sk.dts
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH v10 15/15] doc: board: ti: k3: Add J784S4 EVM and AM69 SK documentation
3.bin, tispl.bin and u-boot.img. Each SoC +variant (GP, HS-FS, HS-SE) requires a different source for these files. + + - GP + +* tiboot3-j784s4-gp-evm.bin from :ref:`step 3.1 ` +* tispl.bin_unsigned, u-boot.img_unsigned from :ref:`step 3.2 ` + + - HS-FS + +* tiboot3-j784s4-hs-fs-evm.bin from :ref:`step 3.1 ` +* tispl.bin, u-boot.img from :ref:`step 3.2 ` + + - HS-SE + +* tiboot3-j784s4-hs-evm.bin from :ref:`step 3.1 ` +* tispl.bin, u-boot.img from :ref:`step 3.2 ` + +Image formats +- + +- tiboot3.bin + +.. image:: img/multi_cert_tiboot3.bin.svg +:alt: tiboot3.bin format + +- tispl.bin + +.. image:: img/dm_tispl.bin.svg +:alt: tispl.bin format + +R5 Memory Map +- + +.. list-table:: + :widths: 16 16 16 + :header-rows: 1 + + * - Region + - Start Address + - End Address + + * - SPL + - 0x41c0 + - 0x41c4 + + * - EMPTY + - 0x41c4 + - 0x41c61f20 + + * - STACK + - 0x41c65f20 + - 0x41c61f20 + + * - Global data + - 0x41c65f20 + - 0x41c66000 + + * - Heap + - 0x41c66000 + - 0x41c76000 + + * - BSS + - 0x41c76000 + - 0x41c8 + + * - DM DATA + - 0x41c8 + - 0x41c84130 + + * - EMPTY + - 0x41c84130 + - 0x41cff9fc + + * - MCU Scratchpad + - 0x41cff9fc + - 0x41cffbfc + + * - ROM DATA + - 0x41cffbfc + - 0x41cf + +Switch Setting for Boot Mode + + +Boot Mode pins provide means to select the boot mode and options before the +device is powered up. After every POR, they are the main source to populate +the Boot Parameter Tables. + +Boot Mode Pins for J784S4-EVM +^ + +The following tables show some common boot modes used on J784S4 EVM platform. +More details can be found in the Technical Reference Manual: +http://www.ti.com/lit/zip/spruj52 under the `Boot Mode Pins` section. + +.. list-table:: J784S4 EVM Boot Modes + :widths: 16 16 16 + :header-rows: 1 + + * - Switch Label + - SW11: 12345678 + - SW7: 12345678 + + * - SD + - 1010 + - + + * - EMMC + - 1000 + - 0100 + + * - OSPI + - 0110 + - 0100 + + * - UART + - + - 0111 + +For SW7 and SW11, the switch state in the "ON" position = 1. + +Boot Mode Pins for AM69-SK +^^ + +The following table show some common boot modes used on AM69-SK platform. +More details can be found in the User Guide for AM69-SK: +https://www.ti.com/lit/ug/spruj70/spruj70.pdf under the `Bootmode Settings` +section. + +.. list-table:: AM69 SK Boot Modes + :widths: 16 16 + :header-rows: 1 + + * - Switch Label + - SW2: 1234 + + * - SD + - + + * - EMMC + - 0110 + + * - UART + - 1010 + +For SW2, the switch state in the "ON" position = 1. + +Debugging U-Boot + + +See :ref:`Common Debugging environment - OpenOCD`: for +detailed setup information. + +.. warning:: + + **OpenOCD support since**: September 2023 (git master) + + Until the next stable release of OpenOCD is available in your development + environment's distribution, it might be necessary to build OpenOCD `from the + source <https://github.com/openocd-org/openocd>`_. + +Debugging U-Boot on J784S4-EVM and AM69-SK +^^ + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_openocd_connect_XDS110 +:end-before: .. k3_rst_include_end_openocd_connect_XDS110 + +To start OpenOCD and connect to J784S4-EVM or AM69-SK board, use the +following. + +.. code-block:: bash + + openocd -f board/ti_j784s4evm.cfg diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index 3c33efd2e38..15e1ed232bf 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -41,6 +41,7 @@ K3 Based SoCs ../beagle/j721e_beagleboneai64 j721e_evm j721s2_evm + j784s4_evm Boot Flow Overview ---------- Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [RFC PATCH 3/4] arm: dts: k3-j721e: Separate boot binary build
Hi Manorit
On 01/03/24 10:56, Manorit Chawdhry wrote:
Hi Neha,
On 16:50-20240228, Neha Malcom Francis wrote:
Separate out the boot binaries built for J721E boards; J721E EVM and
J721E SK by using the common templates in k3-j721e-binman.dtsi.
Only the required boot binaries can be built from the templates in the
boards' respective -u-boot.dtsi file. FDTs and configurations are also
moved to the -u-boot.dtsi file to allow clear distinction between the
SoC common stuff vs. what is needed to boot up a board.
Signed-off-by: Neha Malcom Francis
---
Note: I have added "dummy" sections so that node for a phandle is found
correctly. The node for a phandle is searched for among sub-nodes of a
section (check tools/binman/etype/section.py GetContentsByPhandle) and
having a template as the section instead, causes failure to find the
phandle despite it being present in the FDT. So the dummy section
bypasses this.
Avoided correct DTS alignment for the RFC at least so that it's clear
what is actually being changed.
arch/arm/dts/k3-j721e-binman.dtsi | 178 +-
.../k3-j721e-common-proc-board-u-boot.dtsi| 138 ++
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 104 ++
3 files changed, 284 insertions(+), 136 deletions(-)
[snip]
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 7ae7cf3d4c9..ff96bc3f724 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
@@ -187,3 +187,141 @@
_fss0_ospi1_pins_default {
bootph-all;
};
+
+#ifdef CONFIG_TARGET_J721E_R5_EVM
+
+ {
+ tiboot3-j721e-sr1-1-hs-evm {
+ insert-template = <_j721e_sr1_1_hs>;
+ };
+ sysfw-j721e-sr1-1-hs-evm {
+ insert-template = <>;
+ };
+ itb-j721e-sr1-1-hs-evm {
+ insert-template = <>;
+ };
+};
+
+ {
+ tiboot3-j721e-sr2-hs-evm {
+ insert-template = <_j721e_sr2_hs>;
+ };
+ sysfw-j721e-sr2-hs-evm {
+ insert-template = <_sr2>;
+ };
+ itb-j721e-sr2-hs-evm {
+ insert-template = <_sr2>;
+ };
+};
+
+ {
+ tiboot3-j721e-sr2-hs-fs-evm {
+ insert-template = <_j721e_sr2_hs_fs>;
+ };
+ sysfw-j721e-sr2-hs-fs-evm {
+ insert-template = <_fs>;
+ };
+ itb-j721e-sr2-hs-fs-evm {
+ insert-template = <_fs>;
+ };
+};
+
+ {
+ tiboot3-j721e-gp-evm {
+ insert-template = <_j721e_gp>;
+ };
+ sysfw-j721e-gp-evm {
+ insert-template = <_gp>;
+ };
+ itb-j721e-gp-evm {
+ insert-template = <_gp>;
+ };
+};
+
+#else
+
+#define SPL_J721E_EVM_DTB "spl/dts/k3-j721e-common-proc-board.dtb"
+
Trying to gauge the changes that are required for EVM to SK, I notice a
few only ( let me know if I missed ).
1. DTB
2. Description name.
Considering this, templating does seem good but I was thinking of a
different design as well. Let me know what you think about it.
I was thinking that the binman node can remain as is with some generic
macros like taking the fdt-0 node of tispl.bin
We can have something like this.
in arch/arm/dts/k3-j721e-binman.dtsi:
fit {
images {
fdt-0 {
description = BOARD_DESCRIPTION;
ti-secure {
content = <_j721e_dtb>;
keyfile = "custMpk.pem";
}
spl_j721e_dtb: blob-ext {
filename = BOARD_SPL_DTB;
}
}
}
}
And then in the board specific -u-boot overrides, we can have something
like this -
in arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
#define BOARD_DESCRIPTION "k3-j721e-common-proc-board";
#define BOARD_SPL_DTB "spl/dts/k3-j721e-common-proc-board.dtb";
#include
in arch/arm/dts/k3-j721e-sk-u-boot.dtsi
#define BOARD_DESCRIPTION "k3-j721e-sk";
#define BOARD_SPL_DTB "spl/dts/k3-j721e-sk.dtb"
#include
I think if we have a less enough diff only between these two then I am
hoping something like this can be better maybe. Let me know what your
thoughts would be on that.
Regards,
Manorit
Yes this can reduce the code size nicely and cleanly, I will take this into
account in the proper version, thanks!
+ {
+ tispl {
+ insert-template = <_spl>;
+ fit {
+ images {
+ fdt-0 {
+ description =
"k3-j721e-common-proc-board";
+
Re: [RFC PATCH 1/4] configs: j721e_sk: Move to separate defconfig for J721E SK board
Hi Andrew On 28/02/24 20:41, Andrew Davis wrote: On 2/28/24 5:20 AM, Neha Malcom Francis wrote: Add defconfig for J721E SK R5 and A72 configuration. This includes and modifies the J721E EVM defconfigs: j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig Signed-off-by: Neha Malcom Francis --- board/ti/j721e/MAINTAINERS | 2 ++ configs/j721e_evm_a72_defconfig | 2 +- configs/j721e_evm_r5_defconfig | 2 +- configs/j721e_sk_a72_defconfig | 4 configs/j721e_sk_r5_defconfig | 5 + 5 files changed, 13 insertions(+), 2 deletions(-) create mode 100644 configs/j721e_sk_a72_defconfig create mode 100644 configs/j721e_sk_r5_defconfig diff --git a/board/ti/j721e/MAINTAINERS b/board/ti/j721e/MAINTAINERS index f5ca7d06a34..06aba53d9b0 100644 --- a/board/ti/j721e/MAINTAINERS +++ b/board/ti/j721e/MAINTAINERS @@ -5,5 +5,7 @@ F: board/ti/j721e F: include/configs/j721e_evm.h F: configs/j721e_evm_r5_defconfig F: configs/j721e_evm_a72_defconfig +F: configs/j721e_sk_r5_defconfig +F: configs/j721e_sk_a72_defconfig F: configs/j7200_evm_r5_defconfig F: configs/j7200_evm_a72_defconfig diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 74af5bebb51..21081a2a684 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -86,7 +86,7 @@ CONFIG_MMC_SPEED_MODE_SET=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -CONFIG_OF_LIST="k3-j721e-common-proc-board k3-j721e-sk" +CONFIG_OF_LIST="k3-j721e-common-proc-board" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index bc4f35cce11..ce2b7df58cf 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -81,7 +81,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board k3-j721e-r5-sk" +CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/j721e_sk_a72_defconfig b/configs/j721e_sk_a72_defconfig new file mode 100644 index 000..c47ad4a7616 --- /dev/null +++ b/configs/j721e_sk_a72_defconfig @@ -0,0 +1,4 @@ +#include + +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk" +CONFIG_OF_LIST="k3-j721e-sk" These two overrides should be all that is needed, but currently the `buildman` tool parses the *_defconfigs directly to determine what arch to build every defconfig for when doing testing. So you also for now need to re-define the ARCH, even though it comes in from the include. See how it was done here[0]. Basically just add here: CONFIG_ARM=y CONFIG_ARCH_K3=y CONFIG_SOC_K3_J721E=y CONFIG_TARGET_J721E_A72_EVM=y Andrew [0] https://lore.kernel.org/u-boot/20240223202153.3756094-15-a-nan...@ti.com/ Ah didn't realise that thanks! diff --git a/configs/j721e_sk_r5_defconfig b/configs/j721e_sk_r5_defconfig new file mode 100644 index 000..077e8606d57 --- /dev/null +++ b/configs/j721e_sk_r5_defconfig @@ -0,0 +1,5 @@ +#include + +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-sk" +CONFIG_SPL_OF_LIST="k3-j721e-r5-sk" +CONFIG_OF_LIST="k3-j721e-r5-sk" -- Thanking You Neha Malcom Francis
[RFC PATCH 3/4] arm: dts: k3-j721e: Separate boot binary build
Separate out the boot binaries built for J721E boards; J721E EVM and
J721E SK by using the common templates in k3-j721e-binman.dtsi.
Only the required boot binaries can be built from the templates in the
boards' respective -u-boot.dtsi file. FDTs and configurations are also
moved to the -u-boot.dtsi file to allow clear distinction between the
SoC common stuff vs. what is needed to boot up a board.
Signed-off-by: Neha Malcom Francis
---
Note: I have added "dummy" sections so that node for a phandle is found
correctly. The node for a phandle is searched for among sub-nodes of a
section (check tools/binman/etype/section.py GetContentsByPhandle) and
having a template as the section instead, causes failure to find the
phandle despite it being present in the FDT. So the dummy section
bypasses this.
Avoided correct DTS alignment for the RFC at least so that it's clear
what is actually being changed.
arch/arm/dts/k3-j721e-binman.dtsi | 178 +-
.../k3-j721e-common-proc-board-u-boot.dtsi| 138 ++
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 104 ++
3 files changed, 284 insertions(+), 136 deletions(-)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..284613545ea 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -5,11 +5,12 @@
#include "k3-binman.dtsi"
-#ifdef CONFIG_TARGET_J721E_R5_EVM
+#ifdef CONFIG_CPU_V7R
{
- tiboot3-j721e_sr1_1-hs-evm.bin {
+ tiboot3_j721e_sr1_1_hs: template-9 {
filename = "tiboot3-j721e_sr1_1-hs-evm.bin";
+ section {
ti-secure-rom {
content = <_boot_spl>;
core = "public";
@@ -19,10 +20,12 @@
u_boot_spl: u-boot-spl {
no-expanded;
};
+ };
};
- tiboot3-j721e_sr2-hs-evm.bin {
+ tiboot3_j721e_sr2_hs: template-10 {
filename = "tiboot3-j721e_sr2-hs-evm.bin";
+ section {
ti-secure-rom {
content = <_boot_spl_sr2>;
core = "public";
@@ -32,10 +35,12 @@
u_boot_spl_sr2: u-boot-spl {
no-expanded;
};
+ };
};
- sysfw {
+ sysfw: template-11 {
filename = "sysfw.bin";
+ section {
ti-secure-rom {
content = <_fs_cert>;
core = "secure";
@@ -53,10 +58,12 @@
type = "blob-ext";
optional;
};
+ };
};
- sysfw_sr2 {
+ sysfw_sr2: template-12 {
filename = "sysfw.bin_sr2";
+ section {
ti-secure-rom {
content = <_fs_cert_sr2>;
core = "secure";
@@ -74,15 +81,17 @@
type = "blob-ext";
optional;
};
+ };
};
- itb {
+ itb: template-13 {
filename = "sysfw-j721e_sr1_1-hs-evm.itb";
insert-template = <_template>;
};
- itb_sr2 {
+ itb_sr2: template-14 {
filename = "sysfw-j721e_sr2-hs-evm.itb";
+ section {
insert-template = <_template>;
fit {
images {
@@ -127,11 +136,13 @@
};
};
};
+ };
};
{
- tiboot3-j721e_sr2-hs-fs-evm.bin {
+ tiboot3_j721e_sr2_hs_fs: template-15 {
filename = "tiboot3-j721e_sr2-hs-fs-evm.bin";
+ section {
ti-secure-rom {
content = <_boot_spl_fs>;
core = "public";
@@ -142,8 +153,10 @@
no-expanded;
};
};
- sysfw_fs {
+ };
+ sysfw_fs: template-16 {
filename = "sysfw.bin_fs";
+ section {
ti-fs-cert-fs.bin {
filename =
"ti-sysfw/ti-fs-firmware-j721e_sr2-hs-fs-cert.bin";
type = "blob-ext";
@@ -155,16 +168,18 @@
optional;
};
};
- itb_fs {
+ };
+ itb_fs: template-17 {
filename = "sysfw-j721e_sr2-hs-fs-evm.itb";
insert-template = <_unsigned_template>;
};
};
{
- tiboot3-j721e-gp-evm.bin {
+ tiboot3_j721e_gp: template-18 {
filename = "tiboot3-j721e-gp-evm.bin&q
[RFC PATCH 2/4] tools: binman: control.py: Delete template nodes after parsing
Dynamically going through the subnode array and deleting leads to
templates being skipped from deletion when templates are consecutive in
the subnode list. Prevent this from happening by first parsing the DT
and then deleting the nodes.
Signed-off-by: Neha Malcom Francis
---
tools/binman/control.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 2f00279232b..1c4e6a581f9 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -522,9 +522,13 @@ def _ProcessTemplates(parent):
def _RemoveTemplates(parent):
"""Remove any templates in the binman description
"""
+del_nodes = []
for node in parent.subnodes:
if node.name.startswith('template'):
-node.Delete()
+del_nodes.append(node)
+
+for node in del_nodes:
+node.Delete()
def PrepareImagesAndDtbs(dtb_fname, select_images, update_fdt, use_expanded):
"""Prepare the images to be processed and select the device tree
--
2.34.1
[RFC PATCH 1/4] configs: j721e_sk: Move to separate defconfig for J721E SK board
Add defconfig for J721E SK R5 and A72 configuration. This includes and modifies the J721E EVM defconfigs: j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig Signed-off-by: Neha Malcom Francis --- board/ti/j721e/MAINTAINERS | 2 ++ configs/j721e_evm_a72_defconfig | 2 +- configs/j721e_evm_r5_defconfig | 2 +- configs/j721e_sk_a72_defconfig | 4 configs/j721e_sk_r5_defconfig | 5 + 5 files changed, 13 insertions(+), 2 deletions(-) create mode 100644 configs/j721e_sk_a72_defconfig create mode 100644 configs/j721e_sk_r5_defconfig diff --git a/board/ti/j721e/MAINTAINERS b/board/ti/j721e/MAINTAINERS index f5ca7d06a34..06aba53d9b0 100644 --- a/board/ti/j721e/MAINTAINERS +++ b/board/ti/j721e/MAINTAINERS @@ -5,5 +5,7 @@ F: board/ti/j721e F: include/configs/j721e_evm.h F: configs/j721e_evm_r5_defconfig F: configs/j721e_evm_a72_defconfig +F: configs/j721e_sk_r5_defconfig +F: configs/j721e_sk_a72_defconfig F: configs/j7200_evm_r5_defconfig F: configs/j7200_evm_a72_defconfig diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 74af5bebb51..21081a2a684 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -86,7 +86,7 @@ CONFIG_MMC_SPEED_MODE_SET=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y -CONFIG_OF_LIST="k3-j721e-common-proc-board k3-j721e-sk" +CONFIG_OF_LIST="k3-j721e-common-proc-board" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index bc4f35cce11..ce2b7df58cf 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -81,7 +81,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board k3-j721e-r5-sk" +CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/j721e_sk_a72_defconfig b/configs/j721e_sk_a72_defconfig new file mode 100644 index 000..c47ad4a7616 --- /dev/null +++ b/configs/j721e_sk_a72_defconfig @@ -0,0 +1,4 @@ +#include + +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk" +CONFIG_OF_LIST="k3-j721e-sk" diff --git a/configs/j721e_sk_r5_defconfig b/configs/j721e_sk_r5_defconfig new file mode 100644 index 000..077e8606d57 --- /dev/null +++ b/configs/j721e_sk_r5_defconfig @@ -0,0 +1,5 @@ +#include + +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-sk" +CONFIG_SPL_OF_LIST="k3-j721e-r5-sk" +CONFIG_OF_LIST="k3-j721e-r5-sk" -- 2.34.1
[RFC PATCH 0/4] Cleanup J721E EVM and SK
This series does primarily three things: 1. Split out the common J721E defconfig for both EVM and SK 2. Cleanup k3-j721e-binman.dtsi to be SoC specific binman nodes and -u-boot.dtsi files of the respective boards can pick and edit according to their board. This is based on the discussion [1] 3. Move J721E EVM and SK to using OF_UPSTREAM This series depends on series [2] and patch [3] which implement OF_UPSTREAM. Hopefully we get an idea of whether this is what we want to see across all K3 SoCs by the next release. [1] https://lore.kernel.org/u-boot/20240123205255.i7eynu6vdpoxwybf@irregular/ [2] https://lore.kernel.org/u-boot/20240222093607.3085545-1-sumit.g...@linaro.org/ [3] https://lore.kernel.org/u-boot/20240205-am62px-wip-rebasing-v3-11-04cbb42ea...@ti.com/ Boot logs: https://gist.github.com/nehamalcom/3b578dfa1ef83b59f3c309557606ed63 Neha Malcom Francis (4): configs: j721e_sk: Move to separate defconfig for J721E SK board tools: binman: control.py: Delete template nodes after parsing arm: dts: k3-j721e: Separate boot binary build arm: dts: k3-j721e: Move to OF_UPSTREAM arch/arm/dts/Makefile |4 +- arch/arm/dts/k3-j721e-binman.dtsi | 178 +- .../k3-j721e-common-proc-board-u-boot.dtsi| 138 + arch/arm/dts/k3-j721e-common-proc-board.dts | 976 -- arch/arm/dts/k3-j721e-main.dtsi | 2741 - arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 681 arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 104 + arch/arm/dts/k3-j721e-sk.dts | 1074 --- arch/arm/dts/k3-j721e-som-p0.dtsi | 446 --- arch/arm/dts/k3-j721e-thermal.dtsi| 75 - arch/arm/dts/k3-j721e.dtsi| 176 -- board/ti/j721e/MAINTAINERS|2 + configs/j721e_evm_a72_defconfig |5 +- configs/j721e_evm_r5_defconfig|2 +- configs/j721e_sk_a72_defconfig|4 + configs/j721e_sk_r5_defconfig |5 + tools/binman/control.py |6 +- 17 files changed, 305 insertions(+), 6312 deletions(-) delete mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts delete mode 100644 arch/arm/dts/k3-j721e-main.dtsi delete mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi delete mode 100644 arch/arm/dts/k3-j721e-sk.dts delete mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi delete mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi delete mode 100644 arch/arm/dts/k3-j721e.dtsi create mode 100644 configs/j721e_sk_a72_defconfig create mode 100644 configs/j721e_sk_r5_defconfig -- 2.34.1
Re: [PATCH v3 11/13] Makefile: remove hardcoded device tree source directory
Hi Sumit On 27/02/24 14:29, Sumit Garg wrote: Hi Neha, On Tue, 27 Feb 2024 at 13:53, Neha Malcom Francis wrote: Hi Bryan On 27/02/24 02:49, Bryan Brattlof wrote: Some boards that choose to utilize the OF_UPSTREAM directory for their device tree files will need to specify that directory instead of the traditional arch/$(ARCH)/dts/* path. Include the correct path to the board's dtbs depending on if OF_UPSTREAM is selected or not. Reviewed-by: Sumit Garg Signed-off-by: Bryan Brattlof --- Makefile | 18 ++ scripts/Makefile.spl | 17 + 2 files changed, 27 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 0f0c7f30d2717..51b57d26857f1 100644 --- a/Makefile +++ b/Makefile @@ -1184,6 +1184,16 @@ dt_binding_check: scripts_dtc quiet_cmd_copy = COPY$@ cmd_copy = cp $< $@ +ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) This would fail in case of R5 builds, is there any reason why you choose not to use OF_UPSTREAM for R5 builds? Although I will let Bryan elaborate more here, the essence here is that OF_UPSTREAM=y means that the target DTS files come from dts/upstream/src//. I understand that R5 builds will require U-Boot DTS (from U-Boot code base) that (ideally) should inherit the kernel core DTS (from upstream), is this support not there at present? Let me know if I understand incorrectly. However, with OF_UPSTREAM=n you can have U-Boot DTS placed in arch/$(ARCH)/dts/ like the R5 case but you can include whatever common pieces required from dts/upstream/src//. Ah understood. That makes sense, thanks! -Sumit +dt_dir := dts/upstream/src/arm64 +else +dt_dir := dts/upstream/src/$(ARCH) +endif +else +dt_dir := arch/$(ARCH)/dts +endif + ifeq ($(CONFIG_MULTI_DTB_FIT),y) ifeq ($(CONFIG_MULTI_DTB_FIT_LZO),y) @@ -1209,7 +1219,7 @@ endif MKIMAGEFLAGS_fit-dtb.blob = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ -a 0 -e 0 -E \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) -d /dev/null + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) -d /dev/null MKIMAGEFLAGS_fit-dtb.blob += -B 0x8 @@ -1407,9 +1417,9 @@ MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -p $(CONFIG_FIT_EXTERNAL_OFFSET) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(DEVICE_TREE))) \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST))) + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(DEVICE_TREE))) \ + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) \ + $(patsubst %,-b $(dt_dir)/%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST))) else MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 407fc52376a50..d074ba2350065 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -559,9 +559,15 @@ FORCE: $(obj)/dts/dt-$(SPL_NAME).dtb: dts/dt.dtb $(Q)$(MAKE) $(build)=$(obj)/dts spl_dtbs -PHONY += dts_dir -dts_dir: - $(shell [ -d $(obj)/dts ] || mkdir -p $(obj)/dts) +ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +dt_dir := dts/upstream/src/arm64 +else +dt_dir := dts/upstream/src/$(ARCH) +endif +else +dt_dir := arch/$(ARCH)/dts +endif # Declare the contents of the .PHONY variable as phony. We keep that # information in a variable so we can use it in if_changed and friends. @@ -569,8 +575,11 @@ dts_dir: SPL_OF_LIST_TARGETS = $(patsubst %,dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) SHRUNK_ARCH_DTB = $(addprefix $(obj)/,$(SPL_OF_LIST_TARGETS)) +$(dir $(SHRUNK_ARCH_DTB)): + $(shell [ -d $@ ] || mkdir -p $@) + .SECONDEXPANSION: -$(SHRUNK_ARCH_DTB): $$(patsubst $(obj)/dts/%, arch/$(ARCH)/dts/%, $$@) dts_dir +$(SHRUNK_ARCH_DTB): $$(patsubst $(obj)/dts/%, $(dt_dir)/%, $$@) $(dir $(SHRUNK_ARCH_DTB)) $(call if_changed,fdtgrep) targets += $(SPL_OF_LIST_TARGETS) -- Thanking You Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH v3 11/13] Makefile: remove hardcoded device tree source directory
Hi Bryan On 27/02/24 02:49, Bryan Brattlof wrote: Some boards that choose to utilize the OF_UPSTREAM directory for their device tree files will need to specify that directory instead of the traditional arch/$(ARCH)/dts/* path. Include the correct path to the board's dtbs depending on if OF_UPSTREAM is selected or not. Reviewed-by: Sumit Garg Signed-off-by: Bryan Brattlof --- Makefile | 18 ++ scripts/Makefile.spl | 17 + 2 files changed, 27 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 0f0c7f30d2717..51b57d26857f1 100644 --- a/Makefile +++ b/Makefile @@ -1184,6 +1184,16 @@ dt_binding_check: scripts_dtc quiet_cmd_copy = COPY$@ cmd_copy = cp $< $@ +ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) This would fail in case of R5 builds, is there any reason why you choose not to use OF_UPSTREAM for R5 builds? I understand that R5 builds will require U-Boot DTS (from U-Boot code base) that (ideally) should inherit the kernel core DTS (from upstream), is this support not there at present? Let me know if I understand incorrectly. +dt_dir := dts/upstream/src/arm64 +else +dt_dir := dts/upstream/src/$(ARCH) +endif +else +dt_dir := arch/$(ARCH)/dts +endif + ifeq ($(CONFIG_MULTI_DTB_FIT),y) ifeq ($(CONFIG_MULTI_DTB_FIT_LZO),y) @@ -1209,7 +1219,7 @@ endif MKIMAGEFLAGS_fit-dtb.blob = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ -a 0 -e 0 -E \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) -d /dev/null + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) -d /dev/null MKIMAGEFLAGS_fit-dtb.blob += -B 0x8 @@ -1407,9 +1417,9 @@ MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -p $(CONFIG_FIT_EXTERNAL_OFFSET) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(DEVICE_TREE))) \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) \ - $(patsubst %,-b arch/$(ARCH)/dts/%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST))) + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(DEVICE_TREE))) \ + $(patsubst %,-b $(dt_dir)/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) \ + $(patsubst %,-b $(dt_dir)/%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST))) else MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 407fc52376a50..d074ba2350065 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -559,9 +559,15 @@ FORCE: $(obj)/dts/dt-$(SPL_NAME).dtb: dts/dt.dtb $(Q)$(MAKE) $(build)=$(obj)/dts spl_dtbs -PHONY += dts_dir -dts_dir: - $(shell [ -d $(obj)/dts ] || mkdir -p $(obj)/dts) +ifeq ($(CONFIG_OF_UPSTREAM),y) +ifeq ($(CONFIG_ARM64),y) +dt_dir := dts/upstream/src/arm64 +else +dt_dir := dts/upstream/src/$(ARCH) +endif +else +dt_dir := arch/$(ARCH)/dts +endif # Declare the contents of the .PHONY variable as phony. We keep that # information in a variable so we can use it in if_changed and friends. @@ -569,8 +575,11 @@ dts_dir: SPL_OF_LIST_TARGETS = $(patsubst %,dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) SHRUNK_ARCH_DTB = $(addprefix $(obj)/,$(SPL_OF_LIST_TARGETS)) +$(dir $(SHRUNK_ARCH_DTB)): + $(shell [ -d $@ ] || mkdir -p $@) + .SECONDEXPANSION: -$(SHRUNK_ARCH_DTB): $$(patsubst $(obj)/dts/%, arch/$(ARCH)/dts/%, $$@) dts_dir +$(SHRUNK_ARCH_DTB): $$(patsubst $(obj)/dts/%, $(dt_dir)/%, $$@) $(dir $(SHRUNK_ARCH_DTB)) $(call if_changed,fdtgrep) targets += $(SPL_OF_LIST_TARGETS) -- Thanking You Neha Malcom Francis
Re: [PATCH v3 05/13] arm: mach-k3: invert logic for split DM firmware config
On 27/02/24 02:49, Bryan Brattlof wrote: Currently, for the K3 generation of SoCs, there are more SoCs that utilize the split firmware approach than the combined DMSC firmware. Invert the logic to avoid adding more and more SoCs to this list. Acked-by: Andrew Davis Signed-off-by: Bryan Brattlof --- arch/arm/mach-k3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 03898424c9546..ffceb6428d42e 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -130,7 +130,7 @@ config K3_ATF_LOAD_ADDR config K3_DM_FW bool "Separate DM firmware image" - depends on CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN + depends on CPU_V7R && !SOC_K3_AM642 && !SOC_K3_AM654 && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN default y help Enabling this will indicate that the system has separate DM Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH v3 04/13] ram: k3-ddrss: enable the am62ax's DDR controller for am62px
On 27/02/24 02:49, Bryan Brattlof wrote: The am62px family of SoCs uses the same DDR controller as found on the am62ax family. Enable this option when building for the am62px family Signed-off-by: Bryan Brattlof --- drivers/ram/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig index 5b07e92030142..56391058567bb 100644 --- a/drivers/ram/Kconfig +++ b/drivers/ram/Kconfig @@ -65,7 +65,7 @@ choice default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2 default K3_AM64_DDRSS if SOC_K3_AM642 default K3_AM64_DDRSS if SOC_K3_AM625 - default K3_AM62A_DDRSS if SOC_K3_AM62A7 + default K3_AM62A_DDRSS if SOC_K3_AM62A7 || SOC_K3_AM62P5 config K3_J721E_DDRSS bool "Enable J721E DDRSS support" Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH v3 03/13] arm: mach-k3: am62px: introduce clock and device files for wkup spl
d_list[1],
_lpsc_list[8]),
+ [10] = PSC_LPSC(56, _psc_list[0], _pd_list[2],
_lpsc_list[9]),
+ [11] = PSC_LPSC(72, _psc_list[0], _pd_list[3],
_lpsc_list[8]),
+ [12] = PSC_LPSC(73, _psc_list[0], _pd_list[3],
_lpsc_list[11]),
+ [13] = PSC_LPSC(74, _psc_list[0], _pd_list[3],
_lpsc_list[12]),
+};
+
+static struct ti_dev soc_dev_list[] = {
+ PSC_DEV(16, _lpsc_list[0]),
+ PSC_DEV(77, _lpsc_list[0]),
+ PSC_DEV(61, _lpsc_list[0]),
+ PSC_DEV(178, _lpsc_list[1]),
+ PSC_DEV(179, _lpsc_list[2]),
+ PSC_DEV(57, _lpsc_list[3]),
+ PSC_DEV(58, _lpsc_list[4]),
+ PSC_DEV(161, _lpsc_list[5]),
+ PSC_DEV(162, _lpsc_list[6]),
+ PSC_DEV(75, _lpsc_list[7]),
+ PSC_DEV(36, _lpsc_list[8]),
+ PSC_DEV(102, _lpsc_list[8]),
+ PSC_DEV(146, _lpsc_list[8]),
+ PSC_DEV(166, _lpsc_list[9]),
+ PSC_DEV(135, _lpsc_list[10]),
+ PSC_DEV(170, _lpsc_list[11]),
+ PSC_DEV(177, _lpsc_list[12]),
+ PSC_DEV(55, _lpsc_list[13]),
+};
+
+const struct ti_k3_pd_platdata am62px_pd_platdata = {
+ .psc = soc_psc_list,
+ .pd = soc_pd_list,
+ .lpsc = soc_lpsc_list,
+ .devs = soc_dev_list,
+ .num_psc = ARRAY_SIZE(soc_psc_list),
+ .num_pd = ARRAY_SIZE(soc_pd_list),
+ .num_lpsc = ARRAY_SIZE(soc_lpsc_list),
+ .num_devs = ARRAY_SIZE(soc_dev_list),
+};
diff --git a/drivers/clk/ti/clk-k3.c b/drivers/clk/ti/clk-k3.c
index eb76195bd75da..ef7cac937f25f 100644
--- a/drivers/clk/ti/clk-k3.c
+++ b/drivers/clk/ti/clk-k3.c
@@ -86,6 +86,12 @@ static const struct soc_attr ti_k3_soc_clk_data[] = {
.family = "AM62AX",
.data = _clk_platdata,
},
+#endif
+#ifdef CONFIG_SOC_K3_AM62P5
+ {
+ .family = "AM62PX",
+ .data = _clk_platdata,
+ },
#endif
{ /* sentinel */ }
};
diff --git a/drivers/power/domain/ti-power-domain.c
b/drivers/power/domain/ti-power-domain.c
index dc5d74539edcf..c2f58c7af2131 100644
--- a/drivers/power/domain/ti-power-domain.c
+++ b/drivers/power/domain/ti-power-domain.c
@@ -99,6 +99,12 @@ static const struct soc_attr ti_k3_soc_pd_data[] = {
.family = "AM62AX",
.data = _pd_platdata,
},
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
+ {
+ .family = "AM62PX",
+ .data = _pd_platdata,
+ },
#endif
{ /* sentinel */ }
};
diff --git a/include/k3-clk.h b/include/k3-clk.h
index 1b6ab8fe65405..74d1741c9f24c 100644
--- a/include/k3-clk.h
+++ b/include/k3-clk.h
@@ -176,6 +176,7 @@ extern const struct ti_k3_clk_platdata j7200_clk_platdata;
extern const struct ti_k3_clk_platdata j721s2_clk_platdata;
extern const struct ti_k3_clk_platdata am62x_clk_platdata;
extern const struct ti_k3_clk_platdata am62ax_clk_platdata;
+extern const struct ti_k3_clk_platdata am62px_clk_platdata;
struct clk *clk_register_ti_pll(const char *name, const char *parent_name,
void __iomem *reg);
diff --git a/include/k3-dev.h b/include/k3-dev.h
index 072e10ba6321f..80797a9c3dac2 100644
--- a/include/k3-dev.h
+++ b/include/k3-dev.h
@@ -80,6 +80,7 @@ extern const struct ti_k3_pd_platdata j7200_pd_platdata;
extern const struct ti_k3_pd_platdata j721s2_pd_platdata;
extern const struct ti_k3_pd_platdata am62x_pd_platdata;
extern const struct ti_k3_pd_platdata am62ax_pd_platdata;
+extern const struct ti_k3_pd_platdata am62px_pd_platdata;
u8 ti_pd_state(struct ti_pd *pd);
u8 lpsc_get_state(struct ti_lpsc *lpsc);
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH v3 01/13] soc: add info to identify the am62p SoC family
Hi Bryan,
On 27/02/24 02:49, Bryan Brattlof wrote:
Include the part number for TI's am62px family of SoCs so we can
properly identify it during boot
Reviewed-by: Igor Opaniuk
Signed-off-by: Bryan Brattlof
---
arch/arm/mach-k3/include/mach/hardware.h | 2 ++
drivers/soc/soc_ti_k3.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-k3/include/mach/hardware.h
b/arch/arm/mach-k3/include/mach/hardware.h
index a1a9dfbde66c8..040288150b12f 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -46,6 +46,7 @@
#define JTAG_ID_PARTNO_J721S2 0xbb75
#define JTAG_ID_PARTNO_AM62X 0xbb7e
#define JTAG_ID_PARTNO_AM62AX 0xbb8d
+#define JTAG_ID_PARTNO_AM62PX 0xbb9d
#define K3_SOC_ID(id, ID) \
static inline bool soc_is_##id(void) \
@@ -61,6 +62,7 @@ K3_SOC_ID(am64x, AM64X)
K3_SOC_ID(j721s2, J721S2)
K3_SOC_ID(am62x, AM62X)
K3_SOC_ID(am62ax, AM62AX)
+K3_SOC_ID(am62px, AM62PX)
#define K3_SEC_MGR_SYS_STATUS 0x44234100
#define SYS_STATUS_DEV_TYPE_SHIFT 0
diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index 355a5368dd45a..d7d0152b115fa 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -45,6 +45,9 @@ static const char *get_family_string(u32 idreg)
case JTAG_ID_PARTNO_AM62AX:
family = "AM62AX";
break;
+ case JTAG_ID_PARTNO_AM62PX:
+ family = "AM62PX";
+ break;
default:
family = "Unknown Silicon";
};
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH] arm: dts: k3-binman: Make optee optional as requirement
Hi Michael
+ Vignesh
On 25/02/24 23:08, Michael Trimarchi wrote:
Boards can use the ti_spl_template but avoid to define a tee
node to be loaded. This is true form board with 512Mb or less
s/form board/for boards? I am guessing that is what was meant. I am not really
understanding the commit message... does <512MB memory always mean no using
OPTEE? (AM62 SIP would be an exception) The commit message is putting out a
misleading reason why we don't need OPTEE in some cases, I don't think memory is
the primary reason.
memory. We can limit this in configuation removing the tee
s/configuation/configuration
node
configurations {
default = "conf-0";
conf-0 {
description = "k3-am62_ccm_m3";
firmware = "atf";
loadables = "dm", "spl";
fdt = "fdt-0";
};
};
Signed-off-by: Michael Trimarchi
---
arch/arm/dts/k3-binman.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 758c8bf6ea..5ef5af315a 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -293,6 +293,7 @@
keyfile = "custMpk.pem";
};
tee: tee-os {
+ optional;
};
};
@@ -360,6 +361,7 @@
entry = <0x9e80>;
tee-os {
filename = "tee-raw.bin";
+ optional;
};
};
The patch excluding the commit message LGTM.
--
Thanking You
Neha Malcom Francis
Re: [PATCH] arch: mach-k3: fix mapping higher DDR addresses as device memory
Hi all,
Looks like this patch was already merged to u-boot/master
https://lore.kernel.org/all/20240109084551.21155-1-nsek...@ti.com/T/#md1fd66ff9f1cb93dfaa0dfb5f67d7452416e2cc2
Sorry for the spam!
On 22/02/24 12:15, Neha Malcom Francis wrote:
From: Sekhar Nori
An entry in memory map table for MMU configuration is spilling over and
inadvertently mapping DDR available at higher address (above 4GB address
space) as device memory (nGnRnE).
Fix this by adjusting entry size. Tested on AM62A SK by enabling
CONFIG_CMD_TIME. Before this patch:
=> time crc32 0x88100 0x2000
crc32 for 88100 ... 8a0ff ==> 5a7a5760
time: 1 minutes, 14.715 seconds
After patch:
=> time crc32 0x88100 0x2000
crc32 for 88100 ... 8a0ff ==> 3df1ce02
time: 2.711 seconds
Signed-off-by: Sekhar Nori
[n-fran...@ti.com: rebased on next, retested on all devices inc. commit]
Signed-off-by: Neha Malcom Francis
Cc: Andrew Davis
---
Boot logs:
https://gist.github.com/nehamalcom/7b101ea8b97f5a9433a553ef881166a1
arch/arm/mach-k3/arm64-mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index b4308205b2..0e07b1b7ce 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -41,7 +41,7 @@ struct mm_region k3_mem_map[] = {
}, {
.virt = 0x5UL,
.phys = 0x5UL,
- .size = 0x4UL,
+ .size = 0x38000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
--
Thanking You
Neha Malcom Francis
[PATCH] arch: mach-k3: fix mapping higher DDR addresses as device memory
From: Sekhar Nori
An entry in memory map table for MMU configuration is spilling over and
inadvertently mapping DDR available at higher address (above 4GB address
space) as device memory (nGnRnE).
Fix this by adjusting entry size. Tested on AM62A SK by enabling
CONFIG_CMD_TIME. Before this patch:
=> time crc32 0x88100 0x2000
crc32 for 88100 ... 8a0ff ==> 5a7a5760
time: 1 minutes, 14.715 seconds
After patch:
=> time crc32 0x88100 0x2000
crc32 for 88100 ... 8a0ff ==> 3df1ce02
time: 2.711 seconds
Signed-off-by: Sekhar Nori
[n-fran...@ti.com: rebased on next, retested on all devices inc. commit]
Signed-off-by: Neha Malcom Francis
Cc: Andrew Davis
---
Boot logs:
https://gist.github.com/nehamalcom/7b101ea8b97f5a9433a553ef881166a1
arch/arm/mach-k3/arm64-mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index b4308205b2..0e07b1b7ce 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -41,7 +41,7 @@ struct mm_region k3_mem_map[] = {
}, {
.virt = 0x5UL,
.phys = 0x5UL,
- .size = 0x4UL,
+ .size = 0x38000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
--
2.34.1
Re: [PATCH v4 1/2] imx: imxrt1050-evk: Add support for SPI flash booting
address of the register + * value value to be stored in the register + */ + +/* + * 0x400AC044 is used to configure the flexram. + * Unfortunately setting all to OCRAM only works for MMC + * and setting all to DTCM only works for FLEXSPI NOR. + * This configuration fortunately works for both SPI and MMC. +*/ +/* Set first two banks FlexRAM as OCRAM(01b) and the rest to DTCM(10b) */ +DATA 4 0x400AC044 0x55aa +/* Use FLEXRAM_BANK_CFG to config FlexRAM */ +SET_BIT 4 0x400AC040 0x4 + diff --git a/board/freescale/imxrt1050-evk/imximage.cfg b/board/freescale/imxrt1050-evk/imximage.cfg index f1f09fd7eb..b30d852194 100644 --- a/board/freescale/imxrt1050-evk/imximage.cfg +++ b/board/freescale/imxrt1050-evk/imximage.cfg @@ -29,7 +29,13 @@ BOOT_FROMsd *value value to be stored in the register */ As a future plan do you think of moving .cfg files to within binman; you can see 'ti-board-config' entry as an example (tools/binman/etype/ti_board_config.py) [...] -- Thanking You Neha Malcom Francis
Re: [PATCH v8 12/16] arm: dts: Introduce j784s4 u-boot dts files
Hi Nishanth On 16/02/24 21:28, Nishanth Menon wrote: On 14:33-20240215, Neha Malcom Francis wrote: [...] if the templates are abstract enough, the additional code will be so minimal that we wont need a board-binman.dtsi - just u-boot.dtsi and r5.dtsi can include the relevant templates. Hope this helps. So I took a stab at working on this for couple of days, a fix was needed within the tool to allow binman to handle multiple consecutive templates which is needed here etc. which is why it did not work as is; but the built binaries are still not stable for boot. I think this will need some additional work and debugging. As of now, templating is not widely used, so I'm guessing some more minor fixes would be needed to get it building as we intend. If you are okay, I think we can take this series as is for now, I will take action to start off a series cleaning up and using templating for all the devices. Sure, as long you can do this by the next window. Will do, thanks! -- Thanking You Neha Malcom Francis
Re: [PATCH 4/6] arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT
Hi Andrew
On 14/02/24 22:00, Andrew Davis wrote:
The address we load TF-A and OP-TEE to is configurable by Kconfig
CONFIG_K3_{ATF,OPTEE}_LOAD_ADDR, but the DT nodes reserving this memory
are often statically defined. As these binaries are dynamically loadable,
and in the case of OP-TEE may not even be loaded at all, hard-coding these
addresses is not a hardware description, but rather a configuration.
If the address that U-Boot loaded TF-A or OP-TEE does not match the
address in hard-coded in DT, then fix that node address. This also handles
the case when no reserved memory for these is provided by DT, which is
more correct as explained above.
Add this fixup function, and enable it for AM62.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/am625_fdt.c | 2 ++
arch/arm/mach-k3/common_fdt.c | 52 +++
arch/arm/mach-k3/common_fdt.h | 2 ++
3 files changed, 56 insertions(+)
diff --git a/arch/arm/mach-k3/am625_fdt.c b/arch/arm/mach-k3/am625_fdt.c
index 970dd3447de..b26186456f3 100644
--- a/arch/arm/mach-k3/am625_fdt.c
+++ b/arch/arm/mach-k3/am625_fdt.c
@@ -43,6 +43,8 @@ int ft_system_setup(void *blob, struct bd_info *bd)
fdt_fixup_cores_nodes_am625(blob, k3_get_core_nr());
fdt_fixup_gpu_nodes_am625(blob, k3_has_gpu());
fdt_fixup_pru_node_am625(blob, k3_has_pru());
+ fdt_fixup_reserved(blob, "tfa", CONFIG_K3_ATF_LOAD_ADDR, 0x8);
+ fdt_fixup_reserved(blob, "optee", CONFIG_K3_OPTEE_LOAD_ADDR, 0x180);
return 0;
}
diff --git a/arch/arm/mach-k3/common_fdt.c b/arch/arm/mach-k3/common_fdt.c
index 645c4de42f7..3bdedd7b509 100644
--- a/arch/arm/mach-k3/common_fdt.c
+++ b/arch/arm/mach-k3/common_fdt.c
@@ -112,3 +112,55 @@ int fdt_del_node_path(void *blob, const char *path)
return ret;
}
+
+int fdt_fixup_reserved(void *blob, const char *name,
+ unsigned int new_address, unsigned int new_size)
+{
+ int nodeoffset, subnode;
+ int ret;
+
+ /* Find reserved-memory */
+ nodeoffset = fdt_subnode_offset(blob, 0, "reserved-memory");
+ if (nodeoffset < 0) {
+ debug("Could not find reserved-memory node\n");
+ return 0;
+ }
+
+ /* Find existing matching subnode and remove it */
+ fdt_for_each_subnode(subnode, blob, nodeoffset) {
+ const char *node_name;
+ fdt_addr_t addr;
+ fdt_size_t size;
+
+ /* Name matching */
+ node_name = fdt_get_name(blob, subnode, NULL);
+ if (!name)
+ return -EINVAL;
+ if (!strncmp(node_name, name, strlen(name))) {
+ /* Read out old size first */
+ addr = fdtdec_get_addr_size(blob, subnode, "reg",
);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+ new_size = size;
+
+ /* Delete node */
+ ret = fdt_del_node(blob, subnode);
+ if (ret < 0)
+ return ret;
+
+ /* Only one matching node */
+ break;
+ }
+ }
+
+ struct fdt_memory carveout = {
+ .start = new_address,
+ .end = new_address + new_size - 1,
+ };
+ ret = fdtdec_add_reserved_memory(blob, name, , NULL, 0, NULL,
+FDTDEC_RESERVED_MEMORY_NO_MAP);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
diff --git a/arch/arm/mach-k3/common_fdt.h b/arch/arm/mach-k3/common_fdt.h
index 4d23ae638ca..52c07957483 100644
--- a/arch/arm/mach-k3/common_fdt.h
+++ b/arch/arm/mach-k3/common_fdt.h
@@ -8,5 +8,7 @@
int fdt_fixup_msmc_ram_k3(void *blob);
int fdt_del_node_path(void *blob, const char *path);
+int fdt_fixup_reserved(void *blob, const char *name,
+ unsigned int new_address, unsigned int new_size);
#endif /* _COMMON_FDT_H */
This looks pretty neat! Thanks!
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
Re: [PATCH 2/6] arm: mach-k3: Add config option for setting OP-TEE address
IT image header that places ATF in memory where it will run. +config K3_OPTEE_LOAD_ADDR + hex "Load address of OPTEE image" + default 0x9e80 + help + The load address for the OPTEE image. This value defaults to 0x9e80 + if not provided in the board defconfig file. + config K3_DM_FW bool "Separate DM firmware image" depends on CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH 1/6] arm: mach-k3: Add default ATF location for AM62/AM62a
Hi Andrew On 14/02/24 22:00, Andrew Davis wrote: There is a default ATF load address that is used for devices that have ATF running in SRAM. For AM62 and AM62a, ATF runs from DRAM. Instead of having to override the address in every defconfig, make add a default for these ATF in DRAM devices. Signed-off-by: Andrew Davis --- arch/arm/mach-k3/Kconfig | 5 +++-- configs/am62ax_evm_a53_defconfig | 1 - configs/am62x_beagleplay_a53_defconfig | 1 - configs/am62x_evm_a53_defconfig| 1 - configs/phycore_am62x_a53_defconfig| 1 - configs/verdin-am62_a53_defconfig | 1 - 6 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 03898424c95..0bd3f9fa12d 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -123,10 +123,11 @@ config SYS_K3_SPL_ATF config K3_ATF_LOAD_ADDR hex "Load address of ATF image" + default 0x9e78 if (SOC_K3_AM625 || SOC_K3_AM62A7) default 0x7000 help - The load address for the ATF image. This value defaults to 0x7000 - if not provided in the board defconfig file. + The load address for the ATF image. This value is used to build the + FIT image header that places ATF in memory where it will run. config K3_DM_FW bool "Separate DM firmware image" diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig index 38083586a3e..03b2dea7d51 100644 --- a/configs/am62ax_evm_a53_defconfig +++ b/configs/am62ax_evm_a53_defconfig @@ -5,7 +5,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM62A7=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_AM62A7_A53_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048 diff --git a/configs/am62x_beagleplay_a53_defconfig b/configs/am62x_beagleplay_a53_defconfig index 0be20045a97..122c1ba9299 100644 --- a/configs/am62x_beagleplay_a53_defconfig +++ b/configs/am62x_beagleplay_a53_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_AM625_A53_BEAGLEPLAY=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index 457931faf21..e29df6ec523 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -5,7 +5,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_AM625_A53_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 diff --git a/configs/phycore_am62x_a53_defconfig b/configs/phycore_am62x_a53_defconfig index 2d5d906a9d7..5ba08440268 100644 --- a/configs/phycore_am62x_a53_defconfig +++ b/configs/phycore_am62x_a53_defconfig @@ -5,7 +5,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_PHYCORE_AM62X_A53=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 diff --git a/configs/verdin-am62_a53_defconfig b/configs/verdin-am62_a53_defconfig index 956e3a1ad75..2003a530c7d 100644 --- a/configs/verdin-am62_a53_defconfig +++ b/configs/verdin-am62_a53_defconfig @@ -8,7 +8,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_VERDIN_AM62_A53=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH v8 12/16] arm: dts: Introduce j784s4 u-boot dts files
Hi Nishanth
On 24-Jan-24 2:22 AM, Nishanth Menon wrote:
On 20:28-20240123, Apurva Nandan wrote:
[...]
in j784s4-binman.dtsi:
{
j784s4_tiboot3_hs_fs_template: template-9 {
and then in sk.dtsi:
sk.dtsi means sk-uboot.dtsi or sk-binman.dtsi?
you wont need an sk-binman.dtsi with template. sk-u-boot.dtsi and
r5-sk.dts ofcourse will instantiate the required templates!
{
ti-j784s4-hs-evm.bin {
insert-template =<_tiboot3_hs_fs_template>;
};
};
This allows boards to readily include the template for the binaries of
choice and generate just relevant output. Wont it save much confusion?
[...]
It is still little unclear what is the full thing that you are recommending
to implement here.
From what I understood, is it as follows?
- Three binman files will be there: j784s4-binman.dtsi (soc binman),
j784s4-evm-binman.dtsi and am69-sk-binman.dtsi (board binman)
Nope. just j784s4-binman.dtsi with bin file templates for different kinds
of devices.
- j784s4-binman.dtsi will be a SoC binman, and will have only templates for
all tiboot3 gp, hs, hsfs, and tispl/uboot
tiboot3.bin is a an example, but you should do templates for other files
(tispl, u-boot.img... )as well on similar lines. So all a board file
ideally should instantiate is device types it wants and overrides of
dtbs it needs.
- The board binman files will include these templates and update the dtb
files in them.
Correct.
- Final board.dts will use the correct board-binman.dtsi files
if the templates are abstract enough, the additional code will be so
minimal that we wont need a board-binman.dtsi - just u-boot.dtsi and
r5.dtsi can include the relevant templates.
Hope this helps.
So I took a stab at working on this for couple of days, a fix was needed
within the tool to allow binman to handle multiple consecutive templates
which is needed here etc. which is why it did not work as is; but the
built binaries are still not stable for boot. I think this will need
some additional work and debugging. As of now, templating is not widely
used, so I'm guessing some more minor fixes would be needed to get it
building as we intend.
If you are okay, I think we can take this series as is for now, I will
take action to start off a series cleaning up and using templating for
all the devices.
--
Thanking You
Neha Malcom Francis
[RESEND PATCH v2] arm: mach-k3: j721s2_init: Support less than max DDR controllers
The number of DDR controllers to be initialised and used should depend
on the device tree with the constraint of the maximum number of
controllers the device supports. Since J721S2 has multiple (2)
controllers, instead of hardcoding the number of probes, move to
depending on the device tree UCLASS_RAM nodes present.
Signed-off-by: Neha Malcom Francis
---
Changes since v1:
https://lore.kernel.org/all/20240130074139.2627793-1-n-fran...@ti.com/
- Moved away from using loop since J721S2 has only two controllers
(Udit)
Boot logs:
https://gist.github.com/nehamalcom/740e3dcc1e94ca36250f0248d73f6b37
arch/arm/mach-k3/j721s2_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index fb0708bae1..3374889558 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -228,7 +228,7 @@ void k3_mem_init(void)
panic("DRAM 0 init failed: %d\n", ret);
ret = uclass_next_device_err();
- if (ret)
+ if (ret && ret != -ENODEV)
panic("DRAM 1 init failed: %d\n", ret);
}
spl_enable_cache();
--
2.34.1
Re: [PATCH v2] arm: mach-k3: j721s2_init: Support less than max DDR controllers
Hi all
On 30/01/24 15:12, Neha Malcom Francis wrote:
The number of DDR controllers to be initialised and used should depend
on the device tree with the constraint of the maximum number of
controllers the device supports. Since J721S2 has multiple (2)
controllers, instead of hardcoding the number of probes, move to
depending on the device tree UCLASS_RAM nodes present.
Signed-off-by: Neha Malcom Francis
---
Changes since v1:
https://lore.kernel.org/all/20240130074139.2627793-1-n-fran...@ti.com/
- Moved away from using loop since J721S2 has only two controllers
(Udit)
Boot logs:
https://gist.github.com/nehamalcom/740e3dcc1e94ca36250f0248d73f6b37
arch/arm/mach-k3/j721s2_init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index fb0708bae1..07f9221baf 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -228,8 +228,8 @@ void k3_mem_init(void)
panic("DRAM 0 init failed: %d\n", ret);
ret = uclass_next_device_err();
- if (ret)
- panic("DRAM 1 init failed: %d\n", ret);
+ if (ret && ret != -ENODEV)
+ panic("DRAM %d init failed: %d\n", ctr, ret);
}
spl_enable_cache();
}
Kindly ignore this patch, will resend v2.
--
Thanking You
Neha Malcom Francis
[PATCH v2] arm: mach-k3: j721s2_init: Support less than max DDR controllers
The number of DDR controllers to be initialised and used should depend
on the device tree with the constraint of the maximum number of
controllers the device supports. Since J721S2 has multiple (2)
controllers, instead of hardcoding the number of probes, move to
depending on the device tree UCLASS_RAM nodes present.
Signed-off-by: Neha Malcom Francis
---
Changes since v1:
https://lore.kernel.org/all/20240130074139.2627793-1-n-fran...@ti.com/
- Moved away from using loop since J721S2 has only two controllers
(Udit)
Boot logs:
https://gist.github.com/nehamalcom/740e3dcc1e94ca36250f0248d73f6b37
arch/arm/mach-k3/j721s2_init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index fb0708bae1..07f9221baf 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -228,8 +228,8 @@ void k3_mem_init(void)
panic("DRAM 0 init failed: %d\n", ret);
ret = uclass_next_device_err();
- if (ret)
- panic("DRAM 1 init failed: %d\n", ret);
+ if (ret && ret != -ENODEV)
+ panic("DRAM %d init failed: %d\n", ctr, ret);
}
spl_enable_cache();
}
--
2.34.1
Re: [PATCH] arm: mach-k3: j721s2_init: Support less than max DDR controllers
Hi Udit
On 30/01/24 13:53, Kumar, Udit wrote:
On 1/30/2024 1:11 PM, Neha Malcom Francis wrote:
The number of DDR controllers to be initialised and used should depend
on the device tree with the constraint of the maximum number of
controllers the device supports. Since J721S2 has multiple (2)
controllers, instead of hardcoding the number of probes, move to
depending on the device tree UCLASS_RAM nodes present.
Signed-off-by: Neha Malcom Francis
---
Boot logs:
https://gist.github.com/nehamalcom/07fedf4aa173590214b5cef6e1688fa1
This was also parallely proposed in [1] on the mailing-list for J784S4.
[1] https://lore.kernel.org/all/3a7c817b-de29-463a-b4b6-d62c0df66...@ti.com/
arch/arm/mach-k3/j721s2_init.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index fb0708bae1..ff21619506 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -213,10 +213,12 @@ bool check_rom_loaded_sysfw(void)
return is_rom_loaded_sysfw();
}
+#define J721S2_MAX_CONTROLLERS 2
+
void k3_mem_init(void)
{
struct udevice *dev;
- int ret;
+ int ret, ctr = 1;
if (IS_ENABLED(CONFIG_K3_J721E_DDRSS)) {
ret = uclass_get_device_by_name(UCLASS_MISC, "msmc", );
@@ -227,9 +229,14 @@ void k3_mem_init(void)
if (ret)
panic("DRAM 0 init failed: %d\n", ret);
- ret = uclass_next_device_err();
- if (ret)
- panic("DRAM 1 init failed: %d\n", ret);
Since there are two controllers only and you need to call uclass_get_device and
uclass_next_device_err
what about just checking error in above removed code, something like
ret = uclass_next_device_err();
if (ret!=ENODEV)
panic("DRAM 1 init failed: %d\n", ret);
Yes... since AEP has only 2 controllers, this will suffice.
+ while (ctr < J721S2_MAX_CONTROLLERS) {
+ ret = uclass_next_device_err();
+ if (ret == -ENODEV)
+ break;
+ if (ret)
+ panic("DRAM %d init failed: %d\n", ctr, ret);
+ ctr++;
+ }
}
spl_enable_cache();
}
--
Thanking You
Neha Malcom Francis
[PATCH] arm: mach-k3: j721s2_init: Support less than max DDR controllers
The number of DDR controllers to be initialised and used should depend
on the device tree with the constraint of the maximum number of
controllers the device supports. Since J721S2 has multiple (2)
controllers, instead of hardcoding the number of probes, move to
depending on the device tree UCLASS_RAM nodes present.
Signed-off-by: Neha Malcom Francis
---
Boot logs:
https://gist.github.com/nehamalcom/07fedf4aa173590214b5cef6e1688fa1
This was also parallely proposed in [1] on the mailing-list for J784S4.
[1] https://lore.kernel.org/all/3a7c817b-de29-463a-b4b6-d62c0df66...@ti.com/
arch/arm/mach-k3/j721s2_init.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index fb0708bae1..ff21619506 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -213,10 +213,12 @@ bool check_rom_loaded_sysfw(void)
return is_rom_loaded_sysfw();
}
+#define J721S2_MAX_CONTROLLERS 2
+
void k3_mem_init(void)
{
struct udevice *dev;
- int ret;
+ int ret, ctr = 1;
if (IS_ENABLED(CONFIG_K3_J721E_DDRSS)) {
ret = uclass_get_device_by_name(UCLASS_MISC, "msmc", );
@@ -227,9 +229,14 @@ void k3_mem_init(void)
if (ret)
panic("DRAM 0 init failed: %d\n", ret);
- ret = uclass_next_device_err();
- if (ret)
- panic("DRAM 1 init failed: %d\n", ret);
+ while (ctr < J721S2_MAX_CONTROLLERS) {
+ ret = uclass_next_device_err();
+ if (ret == -ENODEV)
+ break;
+ if (ret)
+ panic("DRAM %d init failed: %d\n", ctr, ret);
+ ctr++;
+ }
}
spl_enable_cache();
}
--
2.34.1
[PATCH v2 2/2] tools: binman: ti_board_cfg: Check for linting problems
Use yamllint for checking whether YAML configuration files are adhering
to default yamllint rules.
Signed-off-by: Neha Malcom Francis
Suggested-by: Nishanth Menon
---
Changes since v1:
- add yamllint to requirements.txt (Nishanth)
tools/binman/etype/ti_board_config.py| 5 +
tools/binman/ftest.py| 6 ++
tools/binman/test/323_ti_board_cfg_phony.dts | 14 ++
tools/binman/test/yaml/config.yaml | 4 ++--
tools/binman/test/yaml/config_phony.yaml | 18 ++
tools/buildman/requirements.txt | 1 +
6 files changed, 46 insertions(+), 2 deletions(-)
create mode 100644 tools/binman/test/323_ti_board_cfg_phony.dts
create mode 100644 tools/binman/test/yaml/config_phony.yaml
diff --git a/tools/binman/etype/ti_board_config.py
b/tools/binman/etype/ti_board_config.py
index 94f894c281..2c3bb8f7b5 100644
--- a/tools/binman/etype/ti_board_config.py
+++ b/tools/binman/etype/ti_board_config.py
@@ -9,6 +9,7 @@
import os
import struct
import yaml
+import yamllint
from collections import OrderedDict
from jsonschema import validate
@@ -18,6 +19,7 @@ from binman.entry import Entry
from binman.etype.section import Entry_section
from dtoc import fdt_util
from u_boot_pylib import tools
+from yamllint import config
BOARDCFG = 0xB
BOARDCFG_SEC = 0xD
@@ -244,6 +246,9 @@ class Entry_ti_board_config(Entry_section):
with open(self._schema_file, 'r') as sch:
self.schema_yaml = yaml.safe_load(sch)
+yaml_config = config.YamlLintConfig("extends: default")
+for p in yamllint.linter.run(open(self._config_file, "r"),
yaml_config):
+self.Raise(f"Yamllint error: {p.line}: {p.rule}")
try:
validate(self.file_yaml, self.schema_yaml)
except Exception as e:
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index a4ac520cbb..1fbb0fef1a 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -7030,6 +7030,12 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
data = self._DoReadFile('293_ti_board_cfg.dts')
self.assertEqual(TI_BOARD_CONFIG_DATA, data)
+def testTIBoardConfigLint(self):
+"""Test that an incorrectly linted config file would generate error"""
+with self.assertRaises(ValueError) as e:
+data = self._DoReadFile('323_ti_board_cfg_phony.dts')
+self.assertIn("Yamllint error", str(e.exception))
+
def testTIBoardConfigCombined(self):
"""Test that a schema validated combined board config file can be
generated"""
data = self._DoReadFile('294_ti_board_cfg_combined.dts')
diff --git a/tools/binman/test/323_ti_board_cfg_phony.dts
b/tools/binman/test/323_ti_board_cfg_phony.dts
new file mode 100644
index 00..441296de4f
--- /dev/null
+++ b/tools/binman/test/323_ti_board_cfg_phony.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ ti-board-config {
+ config = "yaml/config_phony.yaml";
+ schema = "yaml/schema.yaml";
+ };
+ };
+};
diff --git a/tools/binman/test/yaml/config.yaml
b/tools/binman/test/yaml/config.yaml
index 5f799a6e3a..c2be32128b 100644
--- a/tools/binman/test/yaml/config.yaml
+++ b/tools/binman/test/yaml/config.yaml
@@ -10,9 +10,9 @@ main-branch:
b: 0
arr: [0, 0, 0, 0]
another-arr:
-- #1
+- # 1
c: 0
d: 0
-- #2
+- # 2
c: 0
d: 0
diff --git a/tools/binman/test/yaml/config_phony.yaml
b/tools/binman/test/yaml/config_phony.yaml
new file mode 100644
index 00..d76fcb3b82
--- /dev/null
+++ b/tools/binman/test/yaml/config_phony.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Test config
+#
+---
+
+main-branch :
+ obj :
+a : 0x0
+b: 0
+ arr: [0, 0, 0, 0]
+ another-arr:
+- # 1
+ c: 0
+ d: 0
+- # 2
+ c: 0
+ d: 0
diff --git a/tools/buildman/requirements.txt b/tools/buildman/requirements.txt
index a1efcb9d4b..4a31e69e4c 100644
--- a/tools/buildman/requirements.txt
+++ b/tools/buildman/requirements.txt
@@ -1,2 +1,3 @@
jsonschema==4.17.3
pyyaml==6.0
+yamllint==1.26.3
--
2.34.1
[PATCH v2 0/2] binman: ti_board_cfg: Add yamllint support
This series adds support for checking and raising an error if a configuration file does not adhere to the default yamllint rules. This is based on the mailing-list suggestion [1]. Boot logs: https://gist.github.com/nehamalcom/9f98d7d17dd19b61a0ad27fdea3bc18e [1]: https://lore.kernel.org/all/20240103173637.fdhfwgmsmqrfpzdp@manmade/ Changes since v1: https://patchwork.ozlabs.org/project/uboot/cover/20240104075357.638983-1-n-fran...@ti.com/ - add yamllint to requirements.txt (Nishanth) - boot logs unchanged since no affecting change Neha Malcom Francis (2): board: ti: *-cfg.yaml: Adhere to yamllint rules tools: binman: ti_board_cfg: Check for linting problems board/ti/am62ax/board-cfg.yaml | 20 +- board/ti/am62ax/pm-cfg.yaml |4 +- board/ti/am62ax/rm-cfg.yaml | 1664 +++ board/ti/am62ax/sec-cfg.yaml | 212 +- board/ti/am62ax/tifs-rm-cfg.yaml | 1484 +++ board/ti/am62x/board-cfg.yaml| 20 +- board/ti/am62x/pm-cfg.yaml |4 +- board/ti/am62x/rm-cfg.yaml | 1532 +++ board/ti/am62x/sec-cfg.yaml | 212 +- board/ti/am64x/board-cfg.yaml| 20 +- board/ti/am64x/pm-cfg.yaml |4 +- board/ti/am64x/rm-cfg.yaml | 2386 +- board/ti/am64x/sec-cfg.yaml | 216 +- board/ti/am65x/board-cfg.yaml| 20 +- board/ti/am65x/pm-cfg.yaml |4 +- board/ti/am65x/rm-cfg.yaml | 2994 ++--- board/ti/am65x/sec-cfg.yaml | 212 +- board/ti/j721e/board-cfg_j7200.yaml | 20 +- board/ti/j721e/pm-cfg_j7200.yaml |4 +- board/ti/j721e/rm-cfg.yaml | 64 +- board/ti/j721e/rm-cfg_j7200.yaml | 134 +- board/ti/j721e/sec-cfg.yaml | 192 +- board/ti/j721e/sec-cfg_j7200.yaml| 216 +- board/ti/j721s2/board-cfg.yaml | 20 +- board/ti/j721s2/pm-cfg.yaml |4 +- board/ti/j721s2/rm-cfg.yaml | 4184 +- board/ti/j721s2/sec-cfg.yaml | 212 +- tools/binman/etype/ti_board_config.py|5 + tools/binman/ftest.py|6 + tools/binman/test/323_ti_board_cfg_phony.dts | 14 + tools/binman/test/yaml/config.yaml |4 +- tools/binman/test/yaml/config_phony.yaml | 18 + tools/buildman/requirements.txt |1 + 33 files changed, 8075 insertions(+), 8031 deletions(-) create mode 100644 tools/binman/test/323_ti_board_cfg_phony.dts create mode 100644 tools/binman/test/yaml/config_phony.yaml -- 2.34.1
Re: [PATCH 2/2] tools: binman: ti_board_cfg: Check for linting problems
Hi Nishanth
On 04/01/24 20:51, Nishanth Menon wrote:
On 13:23-20240104, Neha Malcom Francis wrote:
Use yamllint for checking whether YAML configuration files are adhering
to default yamllint rules.
Signed-off-by: Neha Malcom Francis
Suggested-by: Nishanth Menon
---
tools/binman/etype/ti_board_config.py| 5 +
tools/binman/ftest.py| 6 ++
tools/binman/test/323_ti_board_cfg_phony.dts | 14 ++
tools/binman/test/yaml/config.yaml | 4 ++--
tools/binman/test/yaml/config_phony.yaml | 18 ++
5 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 tools/binman/test/323_ti_board_cfg_phony.dts
create mode 100644 tools/binman/test/yaml/config_phony.yaml
diff --git a/tools/binman/etype/ti_board_config.py
b/tools/binman/etype/ti_board_config.py
index 94f894c281..2c3bb8f7b5 100644
--- a/tools/binman/etype/ti_board_config.py
+++ b/tools/binman/etype/ti_board_config.py
@@ -9,6 +9,7 @@
import os
import struct
import yaml
+import yamllint
Don't you need to add this to requirements.txt?
Yes I do... thanks for catching that!
from collections import OrderedDict
from jsonschema import validate
@@ -18,6 +19,7 @@ from binman.entry import Entry
from binman.etype.section import Entry_section
from dtoc import fdt_util
from u_boot_pylib import tools
+from yamllint import config
BOARDCFG = 0xB
BOARDCFG_SEC = 0xD
@@ -244,6 +246,9 @@ class Entry_ti_board_config(Entry_section):
with open(self._schema_file, 'r') as sch:
self.schema_yaml = yaml.safe_load(sch)
+yaml_config = config.YamlLintConfig("extends: default")
+for p in yamllint.linter.run(open(self._config_file, "r"),
yaml_config):
+self.Raise(f"Yamllint error: {p.line}: {p.rule}")
try:
validate(self.file_yaml, self.schema_yaml)
except Exception as e:
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index a4ac520cbb..1fbb0fef1a 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -7030,6 +7030,12 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
data = self._DoReadFile('293_ti_board_cfg.dts')
self.assertEqual(TI_BOARD_CONFIG_DATA, data)
+def testTIBoardConfigLint(self):
+"""Test that an incorrectly linted config file would generate error"""
+with self.assertRaises(ValueError) as e:
+data = self._DoReadFile('323_ti_board_cfg_phony.dts')
+self.assertIn("Yamllint error", str(e.exception))
+
def testTIBoardConfigCombined(self):
"""Test that a schema validated combined board config file can be
generated"""
data = self._DoReadFile('294_ti_board_cfg_combined.dts')
diff --git a/tools/binman/test/323_ti_board_cfg_phony.dts
b/tools/binman/test/323_ti_board_cfg_phony.dts
new file mode 100644
index 00..441296de4f
--- /dev/null
+++ b/tools/binman/test/323_ti_board_cfg_phony.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ ti-board-config {
+ config = "yaml/config_phony.yaml";
+ schema = "yaml/schema.yaml";
+ };
+ };
+};
diff --git a/tools/binman/test/yaml/config.yaml
b/tools/binman/test/yaml/config.yaml
index 5f799a6e3a..c2be32128b 100644
--- a/tools/binman/test/yaml/config.yaml
+++ b/tools/binman/test/yaml/config.yaml
@@ -10,9 +10,9 @@ main-branch:
b: 0
arr: [0, 0, 0, 0]
another-arr:
-- #1
+- # 1
c: 0
d: 0
-- #2
+- # 2
c: 0
d: 0
diff --git a/tools/binman/test/yaml/config_phony.yaml
b/tools/binman/test/yaml/config_phony.yaml
new file mode 100644
index 00..d76fcb3b82
--- /dev/null
+++ b/tools/binman/test/yaml/config_phony.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Test config
+#
+---
+
+main-branch :
+ obj :
+a : 0x0
+b: 0
+ arr: [0, 0, 0, 0]
+ another-arr:
+- # 1
+ c: 0
+ d: 0
+- # 2
+ c: 0
+ d: 0
--
2.34.1
--
Thanking You
Neha Malcom Francis
[PATCH 2/2] tools: binman: ti_board_cfg: Check for linting problems
Use yamllint for checking whether YAML configuration files are adhering
to default yamllint rules.
Signed-off-by: Neha Malcom Francis
Suggested-by: Nishanth Menon
---
tools/binman/etype/ti_board_config.py| 5 +
tools/binman/ftest.py| 6 ++
tools/binman/test/323_ti_board_cfg_phony.dts | 14 ++
tools/binman/test/yaml/config.yaml | 4 ++--
tools/binman/test/yaml/config_phony.yaml | 18 ++
5 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 tools/binman/test/323_ti_board_cfg_phony.dts
create mode 100644 tools/binman/test/yaml/config_phony.yaml
diff --git a/tools/binman/etype/ti_board_config.py
b/tools/binman/etype/ti_board_config.py
index 94f894c281..2c3bb8f7b5 100644
--- a/tools/binman/etype/ti_board_config.py
+++ b/tools/binman/etype/ti_board_config.py
@@ -9,6 +9,7 @@
import os
import struct
import yaml
+import yamllint
from collections import OrderedDict
from jsonschema import validate
@@ -18,6 +19,7 @@ from binman.entry import Entry
from binman.etype.section import Entry_section
from dtoc import fdt_util
from u_boot_pylib import tools
+from yamllint import config
BOARDCFG = 0xB
BOARDCFG_SEC = 0xD
@@ -244,6 +246,9 @@ class Entry_ti_board_config(Entry_section):
with open(self._schema_file, 'r') as sch:
self.schema_yaml = yaml.safe_load(sch)
+yaml_config = config.YamlLintConfig("extends: default")
+for p in yamllint.linter.run(open(self._config_file, "r"),
yaml_config):
+self.Raise(f"Yamllint error: {p.line}: {p.rule}")
try:
validate(self.file_yaml, self.schema_yaml)
except Exception as e:
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index a4ac520cbb..1fbb0fef1a 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -7030,6 +7030,12 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
data = self._DoReadFile('293_ti_board_cfg.dts')
self.assertEqual(TI_BOARD_CONFIG_DATA, data)
+def testTIBoardConfigLint(self):
+"""Test that an incorrectly linted config file would generate error"""
+with self.assertRaises(ValueError) as e:
+data = self._DoReadFile('323_ti_board_cfg_phony.dts')
+self.assertIn("Yamllint error", str(e.exception))
+
def testTIBoardConfigCombined(self):
"""Test that a schema validated combined board config file can be
generated"""
data = self._DoReadFile('294_ti_board_cfg_combined.dts')
diff --git a/tools/binman/test/323_ti_board_cfg_phony.dts
b/tools/binman/test/323_ti_board_cfg_phony.dts
new file mode 100644
index 00..441296de4f
--- /dev/null
+++ b/tools/binman/test/323_ti_board_cfg_phony.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ ti-board-config {
+ config = "yaml/config_phony.yaml";
+ schema = "yaml/schema.yaml";
+ };
+ };
+};
diff --git a/tools/binman/test/yaml/config.yaml
b/tools/binman/test/yaml/config.yaml
index 5f799a6e3a..c2be32128b 100644
--- a/tools/binman/test/yaml/config.yaml
+++ b/tools/binman/test/yaml/config.yaml
@@ -10,9 +10,9 @@ main-branch:
b: 0
arr: [0, 0, 0, 0]
another-arr:
-- #1
+- # 1
c: 0
d: 0
-- #2
+- # 2
c: 0
d: 0
diff --git a/tools/binman/test/yaml/config_phony.yaml
b/tools/binman/test/yaml/config_phony.yaml
new file mode 100644
index 00..d76fcb3b82
--- /dev/null
+++ b/tools/binman/test/yaml/config_phony.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Test config
+#
+---
+
+main-branch :
+ obj :
+a : 0x0
+b: 0
+ arr: [0, 0, 0, 0]
+ another-arr:
+- # 1
+ c: 0
+ d: 0
+- # 2
+ c: 0
+ d: 0
--
2.34.1
[PATCH 0/2] binman: ti_board_cfg: Add yamllint support
This series adds support for checking and raising an error if a configuration file does not adhere to the default yamllint rules. This is based on the mailing-list suggestion [1]. Boot logs: https://gist.github.com/nehamalcom/9f98d7d17dd19b61a0ad27fdea3bc18e [1]: https://lore.kernel.org/all/20240103173637.fdhfwgmsmqrfpzdp@manmade/ Neha Malcom Francis (2): board: ti: *-cfg.yaml: Adhere to yamllint rules tools: binman: ti_board_cfg: Check for linting problems board/ti/am62ax/board-cfg.yaml | 20 +- board/ti/am62ax/pm-cfg.yaml |4 +- board/ti/am62ax/rm-cfg.yaml | 1664 +++ board/ti/am62ax/sec-cfg.yaml | 212 +- board/ti/am62ax/tifs-rm-cfg.yaml | 1484 +++ board/ti/am62x/board-cfg.yaml| 20 +- board/ti/am62x/pm-cfg.yaml |4 +- board/ti/am62x/rm-cfg.yaml | 1532 +++ board/ti/am62x/sec-cfg.yaml | 212 +- board/ti/am64x/board-cfg.yaml| 20 +- board/ti/am64x/pm-cfg.yaml |4 +- board/ti/am64x/rm-cfg.yaml | 2386 +- board/ti/am64x/sec-cfg.yaml | 216 +- board/ti/am65x/board-cfg.yaml| 20 +- board/ti/am65x/pm-cfg.yaml |4 +- board/ti/am65x/rm-cfg.yaml | 2994 ++--- board/ti/am65x/sec-cfg.yaml | 212 +- board/ti/j721e/board-cfg_j7200.yaml | 20 +- board/ti/j721e/pm-cfg_j7200.yaml |4 +- board/ti/j721e/rm-cfg.yaml | 64 +- board/ti/j721e/rm-cfg_j7200.yaml | 134 +- board/ti/j721e/sec-cfg.yaml | 192 +- board/ti/j721e/sec-cfg_j7200.yaml| 216 +- board/ti/j721s2/board-cfg.yaml | 20 +- board/ti/j721s2/pm-cfg.yaml |4 +- board/ti/j721s2/rm-cfg.yaml | 4184 +- board/ti/j721s2/sec-cfg.yaml | 212 +- tools/binman/etype/ti_board_config.py|5 + tools/binman/ftest.py|6 + tools/binman/test/323_ti_board_cfg_phony.dts | 14 + tools/binman/test/yaml/config.yaml |4 +- tools/binman/test/yaml/config_phony.yaml | 18 + 32 files changed, 8074 insertions(+), 8031 deletions(-) create mode 100644 tools/binman/test/323_ti_board_cfg_phony.dts create mode 100644 tools/binman/test/yaml/config_phony.yaml -- 2.34.1
Re: [PATCH v7 09/17] board: ti: j748s4: Add board config yaml files
Hi Nishanth On 03/01/24 23:06, Nishanth Menon wrote: On 00:45-20231220, Apurva Nandan wrote: Add board-cfg, rm-cfg, pm-cfg, sec-cfg, tifs-rm-cfg yaml for buidling u-boot sysfw data. Signed-off-by: Apurva Nandan --- board/ti/j784s4/board-cfg.yaml | 37 + board/ti/j784s4/pm-cfg.yaml | 13 + board/ti/j784s4/rm-cfg.yaml | 3058 ++ board/ti/j784s4/sec-cfg.yaml | 380 board/ti/j784s4/tifs-rm-cfg.yaml | 2656 ++ 5 files changed, 6144 insertions(+) create mode 100644 board/ti/j784s4/board-cfg.yaml create mode 100644 board/ti/j784s4/pm-cfg.yaml create mode 100644 board/ti/j784s4/rm-cfg.yaml create mode 100644 board/ti/j784s4/sec-cfg.yaml create mode 100644 board/ti/j784s4/tifs-rm-cfg.yaml Cursory review.. but btw, when I run: $ yamllint board/ti/j784s4/rm-cfg.yaml it throws a bunch of warnings, but it does the same for other yamls as well. Not sure it was supposed to be yamlinted - Neha? Might be good idea than manual review to ensure some basic checks are done? Either way, Reviewed-by: Nishanth Menon Yeah I didn't have any other checks in place for the YAML files, thanks for noticing this, will target a quick clean up patch. Ref - I used yamllint 1.26.3 -- Thanking You Neha Malcom Francis
[PATCH] arm: dts: k3-j721e-binman: Add support for HS-SE 2.0
Add support for J721E HS-SE 2.0 device. Make use of the existing
templates and override the phandles for sysfw.itb so that builds do not
fail.
Signed-off-by: Neha Malcom Francis
---
Boot log:
https://gist.github.com/nehamalcom/44082b0c94059737e8d5d1ab16b2f55f
arch/arm/dts/k3-j721e-binman.dtsi | 83 +++
1 file changed, 83 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index dbc385a852..9707ea3085 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -20,6 +20,20 @@
no-expanded;
};
};
+
+ tiboot3-j721e_sr2-hs-evm.bin {
+ filename = "tiboot3-j721e_sr2-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_sr2>;
+ core = "public";
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl_sr2: u-boot-spl {
+ no-expanded;
+ };
+ };
+
sysfw {
filename = "sysfw.bin";
ti-secure-rom {
@@ -40,10 +54,79 @@
optional;
};
};
+
+ sysfw_sr2 {
+ filename = "sysfw.bin_sr2";
+ ti-secure-rom {
+ content = <_fs_cert_sr2>;
+ core = "secure";
+ load = <0x4>;
+ keyfile = "custMpk.pem";
+ countersign;
+ };
+ ti_fs_cert_sr2: ti-fs-cert.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-fs-firmware-j721e_sr2-hs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+
itb {
filename = "sysfw-j721e_sr1_1-hs-evm.itb";
insert-template = <_template>;
};
+
+ itb_sr2 {
+ filename = "sysfw-j721e_sr2-hs-evm.itb";
+ insert-template = <_template>;
+ fit {
+ images {
+ sysfw.bin {
+ blob-ext {
+ filename = "sysfw.bin_sr2";
+ };
+ };
+ board-cfg.bin {
+ ti-secure {
+ content = <_cfg_sr2>;
+ };
+ board_cfg_sr2: board-cfg {
+ filename = "board-cfg.bin";
+ };
+ };
+ pm-cfg.bin {
+ ti-secure {
+ content = <_cfg_sr2>;
+ };
+ pm_cfg_sr2: pm-cfg {
+ filename = "pm-cfg.bin";
+ };
+ };
+ rm-cfg.bin {
+ ti-secure {
+ content = <_cfg_sr2>;
+ };
+ rm_cfg_sr2: rm-cfg {
+ filename = "rm-cfg.bin";
+ };
+ };
+ sec-cfg.bin {
+ ti-secure {
+ content = <_cfg_sr2>;
+ };
+ sec_cfg_sr2: sec-cfg {
+ filename = "sec-cfg.bin";
+ };
+ };
+
+ };
+ };
+ };
};
{
--
2.34.1
Re: [PATCH v6 03/17] arm: mach-k3: Add basic support for J784S4 SoC definition
ensure basic
default clock
+* configuration is always done for enabling PM
services.
+*/
+ ret = uclass_get_device_by_driver(UCLASS_CLK,
+ DM_DRIVER_GET(ti_clk),
+ );
+ if (ret)
+ panic("Failed to initialize clk-k3!\n");
+ }
+
+ remove_fwl_configs(cbass_hc_cfg0_fwls,
ARRAY_SIZE(cbass_hc_cfg0_fwls));
+ remove_fwl_configs(cbass_hc2_fwls, ARRAY_SIZE(cbass_hc2_fwls));
+ remove_fwl_configs(cbass_rc_cfg0_fwls,
ARRAY_SIZE(cbass_rc_cfg0_fwls));
+ remove_fwl_configs(infra_cbass0_fwls,
ARRAY_SIZE(infra_cbass0_fwls));
+ remove_fwl_configs(mcu_cbass0_fwls,
ARRAY_SIZE(mcu_cbass0_fwls));
+ remove_fwl_configs(wkup_cbass0_fwls,
ARRAY_SIZE(wkup_cbass0_fwls));
+ remove_fwl_configs(navss_cbass0_fwls,
ARRAY_SIZE(navss_cbass0_fwls));
+ }
+
+ /* Output System Firmware version info */
+ k3_sysfw_print_ver();
+
+ if (IS_ENABLED(CONFIG_TARGET_J784S4_R5_EVM)) {
+ ret = uclass_get_device_by_name(UCLASS_MISC, "msmc", );
+ if (ret)
+ panic("Probe of msmc failed: %d\n", ret);
+
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret)
+ panic("DRAM 0 init failed: %d\n", ret);
+
+ while (dev) {
+ ret = uclass_next_device_err();
+ if (ret) {
+ printf("Initialized %d DRAM controllers\n",
ctr);
+ break;
+ }
+ ctr++;
+ }
+ }
+
This looks fine. With the above comment addressed or not:
Reviewed-by: Neha Malcom Francis
+ spl_enable_cache();
+}
+
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
+{
+ switch (boot_device) {
+ case BOOT_DEVICE_MMC1:
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) {
+ if (spl_mmc_emmc_boot_partition(mmc))
+ return MMCSD_MODE_EMMCBOOT;
+ return MMCSD_MODE_FS;
+ }
+ if (IS_ENABLED(CONFIG_SPL_FS_FAT) ||
IS_ENABLED(CONFIG_SPL_FS_EXT4))
+ return MMCSD_MODE_FS;
+ return MMCSD_MODE_EMMCBOOT;
+ case BOOT_DEVICE_MMC2:
+ return MMCSD_MODE_FS;
+ default:
+ return MMCSD_MODE_RAW;
+ }
+}
+
+static u32 __get_backup_bootmedia(u32 main_devstat)
+{
+ u32 bkup_boot = (main_devstat & MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >>
+ MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT;
+
+ switch (bkup_boot) {
+ case BACKUP_BOOT_DEVICE_USB:
+ return BOOT_DEVICE_DFU;
+ case BACKUP_BOOT_DEVICE_UART:
+ return BOOT_DEVICE_UART;
+ case BACKUP_BOOT_DEVICE_ETHERNET:
+ return BOOT_DEVICE_ETHERNET;
+ case BACKUP_BOOT_DEVICE_MMC2:
+ {
+ u32 port = (main_devstat & MAIN_DEVSTAT_BKUP_MMC_PORT_MASK) >>
+ MAIN_DEVSTAT_BKUP_MMC_PORT_SHIFT;
+ if (port == 0x0)
+ return BOOT_DEVICE_MMC1;
+ return BOOT_DEVICE_MMC2;
+ }
+ case BACKUP_BOOT_DEVICE_SPI:
+ return BOOT_DEVICE_SPI;
+ case BACKUP_BOOT_DEVICE_I2C:
+ return BOOT_DEVICE_I2C;
+ }
+
+ return BOOT_DEVICE_RAM;
+}
+
+static u32 __get_primary_bootmedia(u32 main_devstat, u32 wkup_devstat)
+{
+ u32 bootmode = (wkup_devstat & WKUP_DEVSTAT_PRIMARY_BOOTMODE_MASK) >>
+ WKUP_DEVSTAT_PRIMARY_BOOTMODE_SHIFT;
+
+ bootmode |= (main_devstat & MAIN_DEVSTAT_BOOT_MODE_B_MASK) <<
+ BOOT_MODE_B_SHIFT;
+
+ if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI ||
+ bootmode == BOOT_DEVICE_XSPI)
+ bootmode = BOOT_DEVICE_SPI;
+
+ if (bootmode == BOOT_DEVICE_MMC2) {
+ u32 port = (main_devstat &
+ MAIN_DEVSTAT_PRIM_BOOTMODE_MMC_PORT_MASK) >>
+ MAIN_DEVSTAT_PRIM_BOOTMODE_PORT_SHIFT;
+ if (port == 0x0)
+ bootmode = BOOT_DEVICE_MMC1;
+ }
+
+ return bootmode;
+}
+
+u32 spl_spi_boot_bus(void)
+{
+ u32 wkup_devstat = readl(CTRLMMR_WKUP_DEVSTAT);
+ u32 main_devstat = readl(CTRLMMR_MAIN_DEVSTAT);
+ u32 bootmode = ((wkup_devstat & WKUP_DEVSTAT_PRIMARY_BOOTMODE_MASK) >>
+ WKUP_DEVSTAT_PRIMARY_BOOTMODE_SHIFT) |
+ ((main_devstat & MAIN_DEVSTAT_BOOT_MODE_B_MASK) <<
BO
Re: [PATCH v2 1/3] binman: etype: dm: Add entry type for TI DM
Hi Simon, On 06/12/23 09:24, Simon Glass wrote: On Tue, 5 Dec 2023 at 02:42, Neha Malcom Francis wrote: K3 devices introduces the concept of centralized power, resource and security management to System Firmware. This is to overcome challenges by the traditional approach that implements system control functions on each of the processing units. The software interface for System Firmware is split into TIFS and DM. DM (Device Manager) is responsible for resource and power management from secure and non-secure hosts. This additional binary is necessary for specific platforms' ROM boot images and is to be packaged into tispl.bin Add an entry for DM. The entry can be used for the packaging of tispl.bin by binman along with ATF and TEE. Signed-off-by: Neha Malcom Francis Reviewed-by: Andrew Davis --- Makefile| 1 + tools/binman/entries.rst| 14 ++ tools/binman/etype/ti_dm.py | 22 ++ tools/binman/ftest.py | 7 +++ tools/binman/test/225_ti_dm.dts | 13 + 5 files changed, 57 insertions(+) create mode 100644 tools/binman/etype/ti_dm.py create mode 100644 tools/binman/test/225_ti_dm.dts Reviewed-by: Simon Glass Is there a doc/ update somewhere about TI_DM ? Yes, it's patch 3/3 in this series. Regards, Simon -- Thanking You Neha Malcom Francis
[PATCH v2 3/3] doc: board: ti: k3: Mention TI_DM argument
Mention TI_DM argument can be used to fetch a custom DM binary in the A72 build instructions for K3 devices. Signed-off-by: Neha Malcom Francis Reviewed-by: Andrew Davis --- doc/board/ti/k3.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index a127215ce5..f19ee56f29 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -320,6 +320,13 @@ use the `lite` option. make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \ BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \ TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin + +.. note:: + It is also possible to pick up a custom DM binary by adding TI_DM argument + pointing to the file. If not provided, it defaults to picking up the DM + binary from BINMAN_INDIRS. This is only applicable to devices that utilize + split firmware. + .. k3_rst_include_end_build_steps_uboot At this point you should have every binary needed initialize both the -- 2.34.1
[PATCH v2 2/3] arm: dts: k3-*-binman: Move to using ti-dm entry type
Move the DM entry in tispl.bin FIT image from default fetching an
external blob entry to fetching using ti-dm entry type. This way, the
DM entry will be populated by the TI_DM pathname if provided. Else it
will resort to the ti-dm.bin file.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Andrew Davis
---
arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++--
arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++--
arch/arm/dts/k3-am62a-sk-binman.dtsi | 4 ++--
arch/arm/dts/k3-j7200-binman.dtsi | 4 ++--
arch/arm/dts/k3-j721e-binman.dtsi | 4 ++--
arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index b7b5368886..5b058bd03a 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -161,7 +161,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -248,7 +248,7 @@
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
index ed2c4482ef..78c371529a 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
@@ -227,7 +227,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -310,7 +310,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
index c5e027d44d..ec3bf7ce91 100644
--- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -164,7 +164,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -250,7 +250,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
index 10c9d6cba7..38cccabaa7 100644
--- a/arch/arm/dts/k3-j7200-binman.dtsi
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -200,7 +200,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -285,7 +285,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
[PATCH v2 1/3] binman: etype: dm: Add entry type for TI DM
K3 devices introduces the concept of centralized power, resource and
security management to System Firmware. This is to overcome challenges
by the traditional approach that implements system control functions on
each of the processing units.
The software interface for System Firmware is split into TIFS and DM. DM
(Device Manager) is responsible for resource and power management from
secure and non-secure hosts. This additional binary is necessary for
specific platforms' ROM boot images and is to be packaged into tispl.bin
Add an entry for DM. The entry can be used for the packaging of
tispl.bin by binman along with ATF and TEE.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Andrew Davis
---
Makefile| 1 +
tools/binman/entries.rst| 14 ++
tools/binman/etype/ti_dm.py | 22 ++
tools/binman/ftest.py | 7 +++
tools/binman/test/225_ti_dm.dts | 13 +
5 files changed, 57 insertions(+)
create mode 100644 tools/binman/etype/ti_dm.py
create mode 100644 tools/binman/test/225_ti_dm.dts
diff --git a/Makefile b/Makefile
index 43998da6c0..243494f464 100644
--- a/Makefile
+++ b/Makefile
@@ -1349,6 +1349,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
+ -a ti-dm-path=${TI_DM} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 61de7f1f4a..254afe7607 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1906,6 +1906,20 @@ the included board config binaries. Example::
+.. _etype_ti_dm:
+
+Entry: ti-dm: TI Device Manager (DM) blob
+-
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically ti-dm.bin
+
+This entry holds the device manager responsible for resource and power
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more
information
+about TI DM.
+
+
+
.. _etype_ti_secure:
Entry: ti-secure: Entry containing a TI x509 certificate binary
diff --git a/tools/binman/etype/ti_dm.py b/tools/binman/etype/ti_dm.py
new file mode 100644
index 00..0faa0bf0ca
--- /dev/null
+++ b/tools/binman/etype/ti_dm.py
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+# Written by Neha Malcom Francis
+#
+# Entry-type module for TI Device Manager (DM)
+#
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+class Entry_ti_dm(Entry_blob_named_by_arg):
+"""TI Device Manager (DM) blob
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically
ti-dm.bin
+
+This entry holds the device manager responsible for resource and power
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more
information
+about TI DM.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'ti-dm')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 5ace2a825d..a273120d9f 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -88,6 +88,7 @@ FSP_S_DATA= b'fsp_s'
FSP_T_DATA= b'fsp_t'
ATF_BL31_DATA = b'bl31'
TEE_OS_DATA = b'this is some tee OS data'
+TI_DM_DATA= b'tidmtidm'
ATF_BL2U_DATA = b'bl2u'
OPENSBI_DATA = b'opensbi'
SCP_DATA = b'scp'
@@ -221,6 +222,7 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
+TestFunctional._MakeInputFile('dm.bin', TI_DM_DATA)
TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
@@ -5455,6 +5457,11 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
data = self._DoReadFile('222_tee_os.dts')
self.assertEqual(TEE_OS_DATA, data[:len(TEE_OS_DATA)])
+def testPackTiDm(self):
+"""Test that an image with a TI DM binary can be created"""
+data = self._DoReadFile('225_ti_dm.dts')
+self.assertEqual(TI_DM_DATA, data[:len(TI_DM_DATA)])
+
def testFitFdtOper(self):
"""Check handling of a specified FIT operation"""
entry_args = {
diff --git a/tools/binman/
[PATCH v2 0/3] binman: Add support for TI_DM entry
This series adds support for the TI_DM entry and moves all K3 platforms to using the same. With this feature introduced, if TI_DM argument is provided binman picks the pathname it provides; else, it defaults to picking up the ti-dm.bin file. This makes it flexible for users to build tispl.bin with custom DM binaries. Boot logs: https://gist.github.com/nehamalcom/37ce8a32e37ddf3e1afcc4c8bd941159 --- Changes from v1: https://lore.kernel.org/all/20231204112141.2036907-1-n-fran...@ti.com/ - s/ti-linux-firmware/BINMAN_INDIRS in documentation (Andrew) - No change to boot logs since only doc change Neha Malcom Francis (3): binman: etype: dm: Add entry type for TI DM arm: dts: k3-*-binman: Move to using ti-dm entry type doc: board: ti: k3: Mention TI_DM argument Makefile | 1 + arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++-- .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++-- arch/arm/dts/k3-am62a-sk-binman.dtsi | 4 ++-- arch/arm/dts/k3-j7200-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721e-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++-- doc/board/ti/k3.rst | 7 ++ tools/binman/entries.rst | 14 tools/binman/etype/ti_dm.py | 22 +++ tools/binman/ftest.py | 7 ++ tools/binman/test/225_ti_dm.dts | 13 +++ 12 files changed, 76 insertions(+), 12 deletions(-) create mode 100644 tools/binman/etype/ti_dm.py create mode 100644 tools/binman/test/225_ti_dm.dts -- 2.34.1
Re: [PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument
Hi Andrew On 04/12/23 20:36, Andrew Davis wrote: On 12/4/23 5:21 AM, Neha Malcom Francis wrote: Mention TI_DM argument can be used to fetch a custom DM binary in the A72 build instructions for K3 devices. Signed-off-by: Neha Malcom Francis --- doc/board/ti/k3.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index a127215ce5..15916b088f 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -320,6 +320,13 @@ use the `lite` option. make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \ BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \ TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin + +.. note:: + It is also possible to pick up a custom DM binary by adding TI_DM argument + pointing to the file. If not provided, it defaults to picking up the DM + binary from ti-linux-firmware. This is only applicable to devices that It would only be "ti-linux-firmware" if that is what you had set as BINMAN_INDIRS. s/ti-linux-firmware/BINMAN_INDIRS Thanks for catching that, will make the change. Otherwise whole series LGTM, Reviewed-by: Andrew Davis + utilize split firmware. + .. k3_rst_include_end_build_steps_uboot At this point you should have every binary needed initialize both the -- Thanking You Neha Malcom Francis
[PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument
Mention TI_DM argument can be used to fetch a custom DM binary in the A72 build instructions for K3 devices. Signed-off-by: Neha Malcom Francis --- doc/board/ti/k3.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index a127215ce5..15916b088f 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -320,6 +320,13 @@ use the `lite` option. make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \ BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \ TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin + +.. note:: + It is also possible to pick up a custom DM binary by adding TI_DM argument + pointing to the file. If not provided, it defaults to picking up the DM + binary from ti-linux-firmware. This is only applicable to devices that + utilize split firmware. + .. k3_rst_include_end_build_steps_uboot At this point you should have every binary needed initialize both the -- 2.34.1
[PATCH 2/3] arm: dts: k3-*-binman: Move to using ti-dm entry type
Move the DM entry in tispl.bin FIT image from default fetching an
external blob entry to fetching using ti-dm entry type. This way, the
DM entry will be populated by the TI_DM pathname if provided. Else it
will resort to the ti-dm.bin file.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++--
arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++--
arch/arm/dts/k3-am62a-sk-binman.dtsi | 4 ++--
arch/arm/dts/k3-j7200-binman.dtsi | 4 ++--
arch/arm/dts/k3-j721e-binman.dtsi | 4 ++--
arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index b7b5368886..5b058bd03a 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -161,7 +161,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -248,7 +248,7 @@
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
index ed2c4482ef..78c371529a 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
@@ -227,7 +227,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -310,7 +310,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
index c5e027d44d..ec3bf7ce91 100644
--- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -164,7 +164,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -250,7 +250,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
index 10c9d6cba7..38cccabaa7 100644
--- a/arch/arm/dts/k3-j7200-binman.dtsi
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -200,7 +200,7 @@
content = <>;
keyfile = "custMpk.pem";
};
- dm: blob-ext {
+ dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -285,7 +285,7 @@
fit {
images {
dm {
- blob-ext {
+ ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/
[PATCH 1/3] binman: etype: dm: Add entry type for TI DM
K3 devices introduces the concept of centralized power, resource and
security management to System Firmware. This is to overcome challenges
by the traditional approach that implements system control functions on
each of the processing units.
The software interface for System Firmware is split into TIFS and DM. DM
(Device Manager) is responsible for resource and power management from
secure and non-secure hosts. This additional binary is necessary for
specific platforms' ROM boot images and is to be packaged into tispl.bin
Add an entry for DM. The entry can be used for the packaging of
tispl.bin by binman along with ATF and TEE.
Signed-off-by: Neha Malcom Francis
---
Makefile| 1 +
tools/binman/entries.rst| 14 ++
tools/binman/etype/ti_dm.py | 22 ++
tools/binman/ftest.py | 7 +++
tools/binman/test/225_ti_dm.dts | 13 +
5 files changed, 57 insertions(+)
create mode 100644 tools/binman/etype/ti_dm.py
create mode 100644 tools/binman/test/225_ti_dm.dts
diff --git a/Makefile b/Makefile
index 1b347f4dfd..7b599ca130 100644
--- a/Makefile
+++ b/Makefile
@@ -1349,6 +1349,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
+ -a ti-dm-path=${TI_DM} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 61de7f1f4a..254afe7607 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1906,6 +1906,20 @@ the included board config binaries. Example::
+.. _etype_ti_dm:
+
+Entry: ti-dm: TI Device Manager (DM) blob
+-
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically ti-dm.bin
+
+This entry holds the device manager responsible for resource and power
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more
information
+about TI DM.
+
+
+
.. _etype_ti_secure:
Entry: ti-secure: Entry containing a TI x509 certificate binary
diff --git a/tools/binman/etype/ti_dm.py b/tools/binman/etype/ti_dm.py
new file mode 100644
index 00..0faa0bf0ca
--- /dev/null
+++ b/tools/binman/etype/ti_dm.py
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+# Written by Neha Malcom Francis
+#
+# Entry-type module for TI Device Manager (DM)
+#
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+class Entry_ti_dm(Entry_blob_named_by_arg):
+"""TI Device Manager (DM) blob
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically
ti-dm.bin
+
+This entry holds the device manager responsible for resource and power
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more
information
+about TI DM.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'ti-dm')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 5ace2a825d..a273120d9f 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -88,6 +88,7 @@ FSP_S_DATA= b'fsp_s'
FSP_T_DATA= b'fsp_t'
ATF_BL31_DATA = b'bl31'
TEE_OS_DATA = b'this is some tee OS data'
+TI_DM_DATA= b'tidmtidm'
ATF_BL2U_DATA = b'bl2u'
OPENSBI_DATA = b'opensbi'
SCP_DATA = b'scp'
@@ -221,6 +222,7 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
+TestFunctional._MakeInputFile('dm.bin', TI_DM_DATA)
TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
@@ -5455,6 +5457,11 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
data = self._DoReadFile('222_tee_os.dts')
self.assertEqual(TEE_OS_DATA, data[:len(TEE_OS_DATA)])
+def testPackTiDm(self):
+"""Test that an image with a TI DM binary can be created"""
+data = self._DoReadFile('225_ti_dm.dts')
+self.assertEqual(TI_DM_DATA, data[:len(TI_DM_DATA)])
+
def testFitFdtOper(self):
"""Check handling of a specified FIT operation"""
entry_args = {
diff --git a/tools/binman/test/225_ti_dm.dts b/tools/binman/test
[PATCH 0/3] binman: Add support for TI_DM entry
This series adds support for the TI_DM entry and moves all K3 platforms to using the same. With this feature introduced, if TI_DM argument is provided binman picks the pathname it provides; else, it defaults to picking up the ti-dm.bin file. This makes it flexible for users to build tispl.bin with custom DM binaries. Boot logs: https://gist.github.com/nehamalcom/37ce8a32e37ddf3e1afcc4c8bd941159 Neha Malcom Francis (3): binman: etype: dm: Add entry type for TI DM arm: dts: k3-*-binman: Move to using ti-dm entry type doc: board: ti: k3: Mention TI_DM argument Makefile | 1 + arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++-- .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++-- arch/arm/dts/k3-am62a-sk-binman.dtsi | 4 ++-- arch/arm/dts/k3-j7200-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721e-binman.dtsi | 4 ++-- arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++-- doc/board/ti/k3.rst | 7 ++ tools/binman/entries.rst | 14 tools/binman/etype/ti_dm.py | 22 +++ tools/binman/ftest.py | 7 ++ tools/binman/test/225_ti_dm.dts | 13 +++ 12 files changed, 76 insertions(+), 12 deletions(-) create mode 100644 tools/binman/etype/ti_dm.py create mode 100644 tools/binman/test/225_ti_dm.dts -- 2.34.1
Re: [PATCH v5 04/17] arm: mach-k3: Add basic support for J784S4 SoC definition
Hi Apurva
On 01-Dec-23 10:38 PM, Francesco Dolcini wrote:
On Fri, Dec 01, 2023 at 10:37:55AM -0600, Bryan Brattlof wrote:
On November 30, 2023 thus sayeth Apurva Nandan:
Add J784S4 initialization files for initial SPL boot.
Signed-off-by: Hari Nagalla
[ add firewall configurations and change the R5 MCU scratchpad ]
Signed-off-by: Manorit Chawdhry
Signed-off-by: Dasnavis Sabiya
Signed-off-by: Apurva Nandan
---
arch/arm/mach-k3/Kconfig | 16 +-
arch/arm/mach-k3/Makefile | 2 +
arch/arm/mach-k3/arm64-mmu.c | 52 +++
arch/arm/mach-k3/include/mach/hardware.h | 4 +
.../mach-k3/include/mach/j784s4_hardware.h| 60
arch/arm/mach-k3/include/mach/j784s4_spl.h| 47 +++
arch/arm/mach-k3/include/mach/spl.h | 4 +
arch/arm/mach-k3/j784s4_fdt.c | 15 +
arch/arm/mach-k3/j784s4_init.c| 338 ++
arch/arm/mach-k3/r5/Makefile | 1 +
10 files changed, 532 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h
create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h
create mode 100644 arch/arm/mach-k3/j784s4_fdt.c
create mode 100644 arch/arm/mach-k3/j784s4_init.c
...
+ if (IS_ENABLED(CONFIG_TARGET_J784S4_R5_EVM)) {
+ ret = uclass_get_device_by_name(UCLASS_MISC, "msmc", );
+ if (ret)
+ panic("Probe of msmc failed: %d\n", ret);
+
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret)
+ panic("DRAM 0 init failed: %d\n", ret);
+
+ ret = uclass_next_device_err();
+ if (ret)
+ panic("DRAM 1 init failed: %d\n", ret);
+
+ ret = uclass_next_device_err();
+ if (ret)
+ panic("DRAM 2 init failed: %d\n", ret);
+
+ ret = uclass_next_device_err();
+ if (ret)
+ panic("DRAM 3 init failed: %d\n", ret);
+ }
I don't know if this is is the right approach. I can see situations
where people will not have all these controllers utilized or would want
to artificially remove them for some reason.
Not sure on the exact implication, but yes, you should expect customers
(like myself/my company) integrating the SoC into some board to not
necessarily use all the functionalities, memory controller included.
Francesco
I think you can make use of uclass_next_device_err() and a while loop to
handle this according to the device tree.
--
Thanking You
Neha Malcom Francis
[PATCH 2/2] configs: j721e_evm_a72_defconfig: Switch to bootstd
Switch to using bootstd. Note that with this change, we will stop using distro_bootcmd and instead depend entirely on bootflow method of starting the system up. Also config_distro_bootcmd.h header file that is no longer needed in j721s2_evm.h. Signed-off-by: Neha Malcom Francis --- configs/j721s2_evm_a72_defconfig | 5 +++-- include/configs/j721s2_evm.h | 1 - 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig index a7adb9282b..04bc6a4449 100644 --- a/configs/j721s2_evm_a72_defconfig +++ b/configs/j721s2_evm_a72_defconfig @@ -29,9 +29,10 @@ 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_OF_SYSTEM_SETUP=y -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;" +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" CONFIG_LOGLEVEL=7 CONFIG_SPL_MAX_SIZE=0xc CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h index 692c6bb5e4..02673ae798 100644 --- a/include/configs/j721s2_evm.h +++ b/include/configs/j721s2_evm.h @@ -10,7 +10,6 @@ #define __CONFIG_J721S2_EVM_H #include -#include /* DDR Configuration */ #define CFG_SYS_SDRAM_BASE10x88000 -- 2.34.1
[PATCH 1/2] board: ti: j721s2: j721s2.env: Add explicit boot_targets
Add explicit boot_targets to indicate the specific boot sequence to
follow.
Signed-off-by: Neha Malcom Francis
---
board/ti/j721s2/j721s2.env | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 64e3d9da85..e76cafe9ae 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -21,6 +21,7 @@ args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288
${mtdparts}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+boot_targets=mmc1 mmc0 usb pxe dhcp
boot=mmc
mmcdev=1
bootpart=1:2
--
2.34.1
[PATCH 0/2] board: ti: j721s2: Switch to standard boot
This series switches J721S2 to standard boot flow. Boot logs: https://gist.github.com/nehamalcom/127019254d49057b5d342f66841bfd3c Neha Malcom Francis (2): board: ti: j721s2: j721s2.env: Add explicit boot_targets configs: j721e_evm_a72_defconfig: Switch to bootstd board/ti/j721s2/j721s2.env | 1 + configs/j721s2_evm_a72_defconfig | 5 +++-- include/configs/j721s2_evm.h | 1 - 3 files changed, 4 insertions(+), 3 deletions(-) -- 2.34.1
