[PATCH v2] sandbox: Fix LTO to work with STACKPROTECTOR

[Andrew Goodbody]

Add the STACKPROTECTOR symbols to the script that generates the
symbols that should not be removed by the use of LTO when linking
a shared object. This prevents a fail to build due to link errors.

https://source.denx.de/u-boot/u-boot/-/issues/35

Signed-off-by: Andrew Goodbody 
---

Changes in v2:
- Made the new match more specific and added it to the grep run rather
  than run grep twice

 scripts/gen_ll_addressable_symbols.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/gen_ll_addressable_symbols.sh 
b/scripts/gen_ll_addressable_symbols.sh
index 13f670ae0e..fc5ee0e9c0 100755
--- a/scripts/gen_ll_addressable_symbols.sh
+++ b/scripts/gen_ll_addressable_symbols.sh
@@ -11,5 +11,6 @@
 set -e
 
 echo '#include '
-$@ 2>/dev/null | grep -oe '_u_boot_list_2_[a-zA-Z0-9_]*_2_[a-zA-Z0-9_]*' | \
-   sort -u | sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/'
+$@ 2>/dev/null | grep -oe '_u_boot_list_2_[a-zA-Z0-9_]*_2_[a-zA-Z0-9_]*' \
+   -e '__stack_chk_guard' | sort -u | \
+   sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/'
-- 
2.39.2

Re: [PATCH] sandbox: Fix LTO to work with STACKPROTECTOR

[Andrew Goodbody]

On 01/07/2024 14:57, Simon Glass wrote:

Hi Andrew,

On Mon, 24 Jun 2024 at 10:29, Andrew Goodbody
 wrote:


Add the STACKPROTECTOR symbols to the script that generates the
symbols that should not be removed by the use of LTO when linking
a shared object. This prevents a fail to build due to link errors.

https://source.denx.de/u-boot/u-boot/-/issues/35

Signed-off-by: Andrew Goodbody 
---

  scripts/gen_ll_addressable_symbols.sh | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/scripts/gen_ll_addressable_symbols.sh 
b/scripts/gen_ll_addressable_symbols.sh
index d0864804aa..ebf89b04bf 100755
--- a/scripts/gen_ll_addressable_symbols.sh
+++ b/scripts/gen_ll_addressable_symbols.sh
@@ -13,3 +13,5 @@ set -e
  echo '#include '
  $@ 2>/dev/null | grep -oe '_u_boot_list_2_[a-zA-Z0-9_]*_2_[a-zA-Z0-9_]*' | \
 sort -u | sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/'
+$@ 2>/dev/null | grep -oe '__stack_chk_.*' | \
+   sort -u | sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/'
--


It is OK to add these new ones, but here you seem to be adding lots of
other things also. So far we are only allowing linker lists. So can
you update this to allow just linker lists and stack_chk? Perhaps
egrep (_u_boot_list_2_|__stack_chk_) or similar?

Regards,
Simon


I am sorry but I do not follow you here. I am not sure what you mean by 
'linker lists'. The script is matching on symbols from object files as 
output by nm. I have not changed that original match expression.


My addition only adds the following 3 symbols to the output of 
gen_ll_addressable_symbols.sh


__stack_chk_guard
__stack_chk_fail
__stack_chk_fail_local

These all come from the same file, common/stackprot.c

I can reduce the match to just search for '__stack_chk_guard' and that 
still works and I can put that as another expression in the grep instead 
of doing the whole nm | grep | sort | sed thing a second time. Would 
that address your concerns?


Thanks,
Andrew

[PATCH] sandbox: Fix LTO to work with STACKPROTECTOR

[Andrew Goodbody]

Add the STACKPROTECTOR symbols to the script that generates the
symbols that should not be removed by the use of LTO when linking
a shared object. This prevents a fail to build due to link errors.

https://source.denx.de/u-boot/u-boot/-/issues/35

Signed-off-by: Andrew Goodbody 
---

 scripts/gen_ll_addressable_symbols.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/gen_ll_addressable_symbols.sh 
b/scripts/gen_ll_addressable_symbols.sh
index d0864804aa..ebf89b04bf 100755
--- a/scripts/gen_ll_addressable_symbols.sh
+++ b/scripts/gen_ll_addressable_symbols.sh
@@ -13,3 +13,5 @@ set -e
 echo '#include '
 $@ 2>/dev/null | grep -oe '_u_boot_list_2_[a-zA-Z0-9_]*_2_[a-zA-Z0-9_]*' | \
sort -u | sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/'
+$@ 2>/dev/null | grep -oe '__stack_chk_.*' | \
+   sort -u | sed -e 's/^\(.*\)/extern char \1[];\n__ADDRESSABLE(\1);/'
-- 
2.39.2

Re: [PATCH] board: beagle: beagleplay: enable OF_SYSTEM_SETUP

[Andrew Davis]

On 6/19/24 2:12 PM, Bryan Brattlof wrote:

Unfortunately when enabling FDT fixups for the AM62x family of SoCs and
moving TF-A to the bottom of RAM we missed the BeaglePlay. This is
causing Linux's memory allocator to clobber TF-A and break its boot.

Enable OF_SYSTEM_SETUP to fixup the kernel's FDT to inform it of the
actual location of the firmware

CC: Andrew Davis 
CC: Nishanth Menon 
CC: Robert Nelson 
Reported-by: Dhruva Gole 
Signed-off-by: Bryan Brattlof 
---


Acked-by: Andrew Davis 


Hello everyone,

Fair warning, this may turn into a philosophical discussion about the
role of device-tree with SystemReady and U-Boot's role in enabling true
distribution to be completely agnostic of the board it's running on.

However substantively this is simply fixing a boot regression Dhruva
found while testing out the beagleplay.

Happy reviewing
~Bryan
---
  board/beagle/beagleplay/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/board/beagle/beagleplay/Kconfig b/board/beagle/beagleplay/Kconfig
index 7dbd833acb4cc..896a1c1be3010 100644
--- a/board/beagle/beagleplay/Kconfig
+++ b/board/beagle/beagleplay/Kconfig
@@ -12,6 +12,7 @@ config TARGET_AM625_A53_BEAGLEPLAY
bool "BeagleBoard.org AM625 BeaglePlay running on A53"
select ARM64
select BINMAN
+   select OF_SYSTEM_SETUP
  
  config TARGET_AM625_R5_BEAGLEPLAY

bool "BeagleBoard.org AM625 BeaglePlay running on R5"

---
base-commit: fe2ce09a0753634543c32cafe85eb87a625f76ca
change-id: 20240619-play-fdt-fixup-a92e1ab872fc

Best regards,

Re: [PATCH 1/6] arm: mach-k3: Add default ATF location for AM62/AM62a

[Andrew Davis]

On 6/19/24 1:20 PM, Nishanth Menon wrote:

On 17:19-20240619, Dhruva Gole wrote:

Hi,

On Feb 14, 2024 at 10:30:04 -0600, 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(-)



Beagleplay stops booting completely with latest U-boot so I did a little
bisect and it seems like reverting this patch helps.

I am not sure what other implications there are of reverting this so I
don't suggest immediately dropping it, however some hints around what's
missing on beagleplay vs other platforms would be helpful.

Because other platforms based off the same SoC don't seem to be
affected.


Grumble... I had to rediscover this in parallel as well - Thanks Dhruva.
mkimage -l tispl.bin and comparing with kernel log of reserved mem
had me completely confused.

a) Memory maps are already notorious to manage on complex heterogenous
   systems. From beagle perspective, we have no need to go and monkey
   with DT defined memory map and DT should be the default and modifying


Your DT source file is wrong, ATF is at 0x8000_ (or any address one
wants to put in K3_ATF_LOAD_ADDR). DT doesn't "define" hardware, it "describes"
it. ATF's location is dynamic and configurable, it doesn't belong in DT.

You have two options, either go update your DT, then update it again every
time ATF moves. *OR* simply turn on OF_SYSTEM_SETUP and let U-Boot add the
correct location reserved memory node for you.

Then you can also drop out the reserved-node from the DT template file.
Only U-Boot knows where ATF is really placed in RAM, so U-Boot must add
this info to DT.


   DT should be explicitly called out with a log (instead of done
   "transparently") - so instead of CONFIG_K3_OPTEE_LOAD_ADDR default
   being forced from u-boot, it should be made optional, where when
   defined, it can overide the dt definition or some variant of that.

b) Looks like
https://lore.kernel.org/u-boot/20240214163009.983034-4-...@ti.com/
missed beagleplay? and we were in for a surprise there - i dont want


This was the only miss, OF_SYSTEM_SETUP didn't get added to the beagleplay
config. Bryan just sent the fix for that now. I'll go look for a way to
make this common across the whole SoC family so we don't again miss any
new boards.

Andrew


to switch from default dts for beagleplay to something different just
because of simplicity for users to know exactly the carveouts and
with other s/w starting up on uC, dts is our "canonical truth".

Re: [PATCH v2 3/8] arm: mach-k3: j721e: Enable QoS for DSS

[Andrew Davis]

On 6/14/24 7:44 AM, Jayesh Choudhary wrote:

Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by
servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is
done by setting the DSS DMA orderID to greater than 7.

Before setting up the QoS, the ORDERID needs to be mapped to VBUSM sources
using setup_navss_nb() function call that sets the threadmap for NBSS
registers. (Section 10.2.10.1.2 "NB Parameters" in TRM[0])

Section 3.3.2 "Quality of Service (QoS)" in the TRM[0] provide more
details.

[0]: https://www.ti.com/lit/zip/spruil1

Signed-off-by: Jayesh Choudhary 
---
  arch/arm/mach-k3/j721e/j721e_init.c |  28 +
  arch/arm/mach-k3/r5/j721e/Makefile  |   1 +
  arch/arm/mach-k3/r5/j721e/j721e_qos.h   |  96 +++
  arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c | 126 
  4 files changed, 251 insertions(+)
  create mode 100644 arch/arm/mach-k3/r5/j721e/j721e_qos.h
  create mode 100644 arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c

diff --git a/arch/arm/mach-k3/j721e/j721e_init.c 
b/arch/arm/mach-k3/j721e/j721e_init.c
index c2024f2500..e9ed8cb267 100644
--- a/arch/arm/mach-k3/j721e/j721e_init.c
+++ b/arch/arm/mach-k3/j721e/j721e_init.c
@@ -23,6 +23,22 @@
  #include "../sysfw-loader.h"
  #include "../common.h"
  
+/* NAVSS North Bridge (NB) registers */

+#define NAVSS0_NBSS_NB0_CFG_MMRS   0x03802000
+#define NAVSS0_NBSS_NB1_CFG_MMRS   0x03803000
+#define NAVSS0_NBSS_NB0_CFG_NB_THREADMAP   (NAVSS0_NBSS_NB0_CFG_MMRS + 
0x10)
+#define NAVSS0_NBSS_NB1_CFG_NB_THREADMAP   (NAVSS0_NBSS_NB1_CFG_MMRS + 
0x10)
+/*
+ * Thread Map for North Bridge Configuration
+ * Each bit is for each VBUSM source.
+ * Bit[0] maps orderID 0-7 to VBUSM.C thread number
+ * Bit[1] maps orderID 8-15 to VBUSM.C thread number
+ * When bit has value 0: VBUSM.C thread 0 (non-real time traffic)
+ * When bit has value 1: VBUSM.C thread 2 (real time traffic)
+ */
+#define NB_THREADMAP_BIT0  BIT(0)
+#define NB_THREADMAP_BIT1  BIT(1)
+
  #ifdef CONFIG_K3_LOAD_SYSFW
  struct fwl_data cbass_hc_cfg0_fwls[] = {
  #if defined(CONFIG_TARGET_J721E_R5_EVM)
@@ -124,6 +140,13 @@ void k3_mmc_restart_clock(void)
  }
  #endif
  
+/* Setup North Bridge registers to map ORDERID 8-15 to RT traffic */

+static void setup_navss_nb(void)
+{
+   writel(NB_THREADMAP_BIT1, (uintptr_t)NAVSS0_NBSS_NB0_CFG_NB_THREADMAP);
+   writel(NB_THREADMAP_BIT1, (uintptr_t)NAVSS0_NBSS_NB1_CFG_NB_THREADMAP);
+}
+
  /*
   * This uninitialized global variable would normal end up in the .bss section,
   * but the .bss is cleared between writing and reading this variable, so move
@@ -288,6 +311,11 @@ void board_init_f(ulong dummy)
panic("DRAM init failed: %d\n", ret);
  #endif
spl_enable_cache();
+
+   if (IS_ENABLED(CONFIG_CPU_V7R))
+   setup_navss_nb();
+
+   setup_qos();
  }
  
  u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)

diff --git a/arch/arm/mach-k3/r5/j721e/Makefile 
b/arch/arm/mach-k3/r5/j721e/Makefile
index 78325db402..07bfb0dd93 100644
--- a/arch/arm/mach-k3/r5/j721e/Makefile
+++ b/arch/arm/mach-k3/r5/j721e/Makefile
@@ -3,3 +3,4 @@
  # Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
  obj-y += clk-data.o
  obj-y += dev-data.o
+obj-y += j721e_qos_uboot.o
diff --git a/arch/arm/mach-k3/r5/j721e/j721e_qos.h 
b/arch/arm/mach-k3/r5/j721e/j721e_qos.h
new file mode 100644
index 00..9ec0b7c630
--- /dev/null
+++ b/arch/arm/mach-k3/r5/j721e/j721e_qos.h
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Keystone3 Quality of service endpoint definitions


Our marketing folks claim it is "K3" not "Keystone3" :),
otherwise lgtm,

Reviewed-by: Andrew Davis 


+ * Auto generated by K3 Resource Partitioning Tool
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#define PULSAR_SL_MCU_0_MEMBDG_RMST0   0x45D1
+#define PULSAR_SL_MCU_0_MEMBDG_WMST0   0x45D10400
+#define PULSAR_SL_MCU_0_CPU0_PMST  0x45D10800
+#define PULSAR_SL_MCU_0_MEMBDG_RMST1   0x45D11000
+#define PULSAR_SL_MCU_0_MEMBDG_WMST1   0x45D11400
+#define PULSAR_SL_MCU_0_CPU1_PMST  0x45D11800
+#define SA2_UL_MCU_0_CTXCACH_EXT_DMA   0x45D13000
+#define ICSS_G_MAIN_0_PR1_EXT_VBUSM0x45D8
+#define ICSS_G_MAIN_1_PR1_EXT_VBUSM0x45D80400
+#define K3_C66_COREPAC_MAIN_0_C66_MDMA 0x45D81000
+#define K3_C66_COREPAC_MAIN_1_C66_MDMA 0x45D81400
+#define EMMCSD4SS_MAIN_0_EMMCSDSS_RD   0x45D82000
+#define EMMCSD4SS_MAIN_0_EMMCSDSS_WR   0x45D82400
+#define EMMCSD4SS_MAIN_1_EMMCSDSS_RD   0x45D82800
+#define EMMCSD4SS_MAIN_1_EMMCSDSS_WR   0x45D82C00
+#define PULSAR_SL_MAIN_0_MEMBDG_RMST0  0x45D84000
+#define PULSAR_SL_MAIN_0_MEMBDG_RMST1  0x45D84400
+#define PULSAR_SL_MAIN_0_MEMBDG_WMST0  0x45D84800
+#define PULSAR_SL_MAIN_0_MEMBDG_WMST1  

Re: [PATCH v2 2/8] arm: mach-k3: am62a: Simplify the logic for QOS reg and val propagation

[Andrew Davis]

On 6/14/24 7:44 AM, Jayesh Choudhary wrote:

For the QOS registers, instead of using the raw values for calculation
for each reg field, use a defined macro which takes in argument for all
the reg fields to get the desired value.
Do the similar simplification for QOS register and group registers and
make the corresponding changes for am62a_qos_uboot file.

Suggested-by: Andrew Davis 
Signed-off-by: Jayesh Choudhary 
---


Looks a bit better IMHO,

Acked-by: Andrew Davis 


  arch/arm/mach-k3/include/mach/k3-qos.h   | 86 
  arch/arm/mach-k3/r5/am62ax/am62a_qos_uboot.c | 24 +++---
  2 files changed, 28 insertions(+), 82 deletions(-)

diff --git a/arch/arm/mach-k3/include/mach/k3-qos.h 
b/arch/arm/mach-k3/include/mach/k3-qos.h
index 6ed5704803..eb0f2a0448 100644
--- a/arch/arm/mach-k3/include/mach/k3-qos.h
+++ b/arch/arm/mach-k3/include/mach/k3-qos.h
@@ -9,80 +9,26 @@
  
  #include 
  
-#define QOS_0	(0 << 0)

-#define QOS_1  (1 << 0)
-#define QOS_2  (2 << 0)
-#define QOS_3  (3 << 0)
-#define QOS_4  (4 << 0)
-#define QOS_5  (5 << 0)
-#define QOS_6  (6 << 0)
-#define QOS_7  (7 << 0)
+/* K3_QOS_REG: Registers to configure the channel for a given endpoint */
  
-#define ORDERID_0	(0 << 4)

-#define ORDERID_1  (1 << 4)
-#define ORDERID_2  (2 << 4)
-#define ORDERID_3  (3 << 4)
-#define ORDERID_4  (4 << 4)
-#define ORDERID_5  (5 << 4)
-#define ORDERID_6  (6 << 4)
-#define ORDERID_7  (7 << 4)
-#define ORDERID_8  (8 << 4)
-#define ORDERID_9  (9 << 4)
-#define ORDERID_10 (10 << 4)
-#define ORDERID_11 (11 << 4)
-#define ORDERID_12 (12 << 4)
-#define ORDERID_13 (13 << 4)
-#define ORDERID_14 (14 << 4)
-#define ORDERID_15 (15 << 4)
+#define K3_QOS_REG(base_reg, i)(base_reg + 0x100 + (i) * 4)
  
-#define ASEL_0	(0 << 8)

-#define ASEL_1 (1 << 8)
-#define ASEL_2 (2 << 8)
-#define ASEL_3 (3 << 8)
-#define ASEL_4 (4 << 8)
-#define ASEL_5 (5 << 8)
-#define ASEL_6 (6 << 8)
-#define ASEL_7 (7 << 8)
-#define ASEL_8 (8 << 8)
-#define ASEL_9 (9 << 8)
-#define ASEL_10(10 << 8)
-#define ASEL_11(11 << 8)
-#define ASEL_12(12 << 8)
-#define ASEL_13(13 << 8)
-#define ASEL_14(14 << 8)
-#define ASEL_15(15 << 8)
+#define K3_QOS_VAL(qos, orderid, asel, epriority, virtid, atype) \
+   (qos<< 0  | \
+orderid<< 4  | \
+asel   << 8  | \
+epriority  << 12 | \
+virtid << 16 | \
+atype  << 28)
  
-#define EPRIORITY_0	(0 << 12)

-#define EPRIORITY_1(1 << 12)
-#define EPRIORITY_2(2 << 12)
-#define EPRIORITY_3(3 << 12)
-#define EPRIORITY_4(4 << 12)
-#define EPRIORITY_5(5 << 12)
-#define EPRIORITY_6(6 << 12)
-#define EPRIORITY_7(7 << 12)
-
-#define VIRTID_0   (0 << 16)
-#define VIRTID_1   (1 << 16)
-#define VIRTID_2   (2 << 16)
-#define VIRTID_3   (3 << 16)
-#define VIRTID_4   (4 << 16)
-#define VIRTID_5   (5 << 16)
-#define VIRTID_6   (6 << 16)
-#define VIRTID_7   (7 << 16)
-#define VIRTID_8   (8 << 16)
-#define VIRTID_9   (9 << 16)
-#define VIRTID_10  (10 << 16)
-#define VIRTID_11  (11 << 16)
-#define VIRTID_12  (12 << 16)
-#define VIRTID_13  (13 << 16)
-#define VIRTID_14  (14 << 16)
-#define VIRTID_15  (15 << 16)
-
-#define ATYPE_0(0 << 28)
-#define ATYPE_1(1 << 28)
-#define ATYPE_2(2 << 28)
-#define ATYPE_3(3 << 28)
+/*
+ * K3_QOS_GROUP_REG: Registers to set 1:1 mapping for orderID MAP1/MAP2
+ * remap registers.
+ */
+#define K3_QOS_GROUP_REG(base_reg, i)  (base_reg + (i) * 4)
  
+#define K3_QOS_GROUP_DEFAULT_VAL_LOW	0x76543210

+#define K3_QOS_GROUP_DEFAULT_VAL_HIGH  0xfedcba98
  struct k3_qos_data {
u32 reg;
u32 val;
diff --git a/arch/arm/mach-k3/r5/am62ax/am62a_qos_uboot.c 
b/arch/arm/mach-k3/r5/am62ax/am62a_qos_uboot.c
index 9a82944d5f..1d588acea4 100644
--- a/arch/arm/mach-k3/r5/am62ax/am62a_qos_uboot.c
+++ b/arch/arm/mach-k3/r5/am62ax/am62a_qos_uboot.c
@@ -12,20 +12,20 @@
  struct k3_qos_data qos_data[] = {
/* modules_qosConfig0 - 1 endpoints, 4 channels */
{
-   .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 0x100 + 0x4 * 0,
-   .val = ORDERID_8,
+   .reg = K3_QOS_REG(K3_DSS_UL_MAIN_0_VBUSM_DMA, 0),
+   .val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
},
{
-   .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 0x100 + 0x4 * 1,
-   .val = ORDERID_8,
+ 

Re: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores

[Andrew Davis]

On 5/23/24 1:33 AM, Anwar, Md Danish wrote:

Hi Andrew,

On 5/22/2024 9:38 PM, Andrew Davis wrote:

On 5/22/24 1:36 AM, MD Danish Anwar wrote:

Add remoteproc-name property for PRU cores.

Signed-off-by: MD Danish Anwar 
---
   arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++
   1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 705b3baa81..25ddace74e 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -11,6 +11,50 @@
   };
   };
   +_0 {
+    remoteproc-name = "pru0_0";


Why do we need all these? Looks like we fallback to using `dev->name` if
these are not set, does that not work for us here?



Yes we will fallback to `dev->name` if `remoteproc-name` is not set but
in our case two different PRU cores will have same `dev->name`. As a
result the API rproc_name_is_unique() will return false and as a result
the probe will fail for the PRU cores.



If `dev->name` is not unique, then combine it with something that is, or
remove the requirement for the name to be unique. Right now this looks
like just a hack around a framework requirement and a driver problem.

If you really think this is something that should be solved in DT then
go convince the DT maintainers and get it into the kernel DT. We should
be reducing the deltas we carry in -u-boot.dtsi files, not adding more
workarounds.

Andrew


Example: In k3-am64-main.dtsi, both pru0_0 [1] and pru1_0 [2] will have
dev->name as "pru@34000" same goes for rtu and txpru as well.

pru0_0: pru@34000 {
compatible = "ti,am642-pru";
reg = <0x34000 0x3000>,
  <0x22000 0x100>,
  <0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am64x-pru0_0-fw";
};

pru1_0: pru@34000 {
compatible = "ti,am642-pru";
reg = <0x34000 0x4000>,
  <0x22000 0x100>,
  <0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am64x-pru1_0-fw";
};

To avoid this, we are setting the "remoteproc-name" property in
-u-boot.dtsi. Same is done for AM65x as well [3].

[1]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1276
[2]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1417
[3]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/arch/arm/dts/k3-am654-base-board-u-boot.dtsi#L168


Andrew


+};
+
+_0 {
+    remoteproc-name = "rtu0_0";
+};
+
+_pru0_0 {
+    remoteproc-name = "tx_pru0_0";
+};
+
+_1 {
+    remoteproc-name = "pru0_1";
+};
+
+_1 {
+    remoteproc-name = "rtu0_1";
+};
+
+_pru0_1 {
+    remoteproc-name = "tx_pru0_1";
+};
+
+_0 {
+    remoteproc-name = "pru1_0";
+};
+
+_0 {
+    remoteproc-name = "rtu1_0";
+};
+
+_pru1_0 {
+    remoteproc-name = "tx_pru1_0";
+};
+
+_1 {
+    remoteproc-name = "pru1_1";
+};
+
+_1 {
+    remoteproc-name = "rtu1_1";
+};
+
   _timer0 {
   clock-frequency = <2>;
   };

Re: [PATCH 09/14] arch: mach-k3: Introduce basic files to support J722S SoC family

[Andrew Davis]

On 5/29/24 8:24 AM, 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

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 2bb970c2d4..f3f42b3921 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -25,6 +25,9 @@ config SOC_K3_J721E
  config SOC_K3_J721S2
bool "TI's K3 based J721S2 SoC Family Support"
  
+config SOC_K3_J722S

+   bool "TI's K3 based J722S SoC Family Support"
+
  config SOC_K3_J784S4
bool "TI's K3 based J784S4 SoC Family Support"
  
@@ -84,6 +87,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX

default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R
default 0x7000f290 if SOC_K3_AM62A7 && ARM64
default 0x43c4f290 if SOC_K3_AM62P5
+   default 0x43c7f290 if SOC_K3_J722S
help
  Address at which ROM stores the value which determines if SPL
  is booted up by primary boot media or secondary boot media.
@@ -122,7 +126,7 @@ config K3_EARLY_CONS_IDX
  
  config K3_ATF_LOAD_ADDR

hex "Load address of ATF image"
-   default 0x8000 if (SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_AM62P5)
+   default 0x8000 if (SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_AM62P5 
|| SOC_K3_J722S)


You may need to fixup the DT if it uses the old address. You'll
need to do the same as done for AM62p here:

https://patchwork.ozlabs.org/project/uboot/patch/20240520-am62p-fdt-fix-v1-1-49845dcb3...@ti.com/

Andrew


default 0x7000
help
  The load address for the ATF image. This value is used to build the
@@ -163,6 +167,7 @@ source "arch/arm/mach-k3/am62ax/Kconfig"
  source "arch/arm/mach-k3/am62px/Kconfig"
  source "arch/arm/mach-k3/j721e/Kconfig"
  source "arch/arm/mach-k3/j721s2/Kconfig"
+source "arch/arm/mach-k3/j722s/Kconfig"
  source "arch/arm/mach-k3/j784s4/Kconfig"
  
  endif

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 2b3ebd5c53..8c4f6786a5 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -14,4 +14,5 @@ obj-$(CONFIG_SOC_K3_AM642) += am64x/
  obj-$(CONFIG_SOC_K3_AM654) += am65x/
  obj-$(CONFIG_SOC_K3_J721E) += j721e/
  obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
+obj-$(CONFIG_SOC_K3_J722S) += j722s/
  obj-$(CONFIG_SOC_K3_J784S4) += j784s4/
diff --git a/arch/arm/mach-k3/include/mach/hardware.h 
b/arch/arm/mach-k3/include/mach/hardware.h
index 26c5bfcf76..86e3e6b355 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -36,6 +36,10 @@
  #include "j721s2_hardware.h"
  #endif
  
+#ifdef CONFIG_SOC_K3_J722S

+#include "j722s_hardware.h"
+#endif
+
  #ifdef CONFIG_SOC_K3_J784S4
  #include "j784s4_hardware.h"
  #endif
diff --git a/arch/arm/mach-k3/include/mach/j722s_hardware.h 
b/arch/arm/mach-k3/include/mach/j722s_hardware.h
new file mode 100644
index 00..8d0bec2206
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/j722s_hardware.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * K3: J722S SoC definitions, structures etc.
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef __ASM_ARCH_J722S_HARDWARE_H
+#define __ASM_ARCH_J722S_HARDWARE_H
+
+#include 
+#ifndef __ASSEMBLY__
+#include 
+#endif
+
+#define PADCFG_MMR0_BASE   0x0408
+#define PADCFG_MMR1_BASE   0x000f
+#define CTRL_MMR0_BASE 0x0010
+#define MCU_CTRL_MMR0_BASE 0x0450
+#define WKUP_CTRL_MMR0_BASE0x4300
+
+#define CTRLMMR_MAIN_DEVSTAT   (WKUP_CTRL_MMR0_BASE + 0x30)
+#define MAIN_DEVSTAT_PRIMARY_BOOTMODE_MASK GENMASK(6, 3)
+#define MAIN_DEVSTAT_PRIMARY_BOOTMODE_SHIFT3
+#define MAIN_DEVSTAT_PRIMARY_BOOTMODE_CFG_MAS

Re: [PATCH 03/14] soc: add info to identify the J722S SoC family

[Andrew Davis]

On 5/29/24 8:24 AM, Jayesh Choudhary wrote:

Include the part number for TI's j722s family of SoC
to identify it during boot.

Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
  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 c3aaded8dc..26c5bfcf76 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -55,6 +55,7 @@
  #define JTAG_ID_PARTNO_J7200  0xbb6d
  #define JTAG_ID_PARTNO_J721E  0xbb64
  #define JTAG_ID_PARTNO_J721S2 0xbb75
+#define JTAG_ID_PARTNO_J722S0xbba0


All the others use tab, you used spaces here. Personally I like spaces
for alignment, but unless you fix all the others, stick with tab for now.


  #define JTAG_ID_PARTNO_J784S4 0xbb80
  
  #define K3_SOC_ID(id, ID) \

@@ -72,6 +73,7 @@ K3_SOC_ID(am65x, AM65X)
  K3_SOC_ID(j7200, J7200)
  K3_SOC_ID(j721e, J721E)
  K3_SOC_ID(j721s2, J721S2)
+K3_SOC_ID(j722s, J722S)
  
  #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 0838808515..f948914d21 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -47,6 +47,9 @@ static const char *get_family_string(u32 idreg)
case JTAG_ID_PARTNO_J721S2:
family = "J721S2";
break;
+   case JTAG_ID_PARTNO_J722S:
+   family = "J722S";
+   break;
case JTAG_ID_PARTNO_J784S4:
family = "J784S4";
break;

Re: [PATCH 01/14] arm: mach-k3: Sort CONFIG_SOC* and K3_SOC_ID entries

[Andrew Davis]

On 5/29/24 8:24 AM, Jayesh Choudhary wrote:

Sort CONFIG_SOC* and K3_SOC_ID alphabetically.


Why? I kinda like the chronological order we have today, helps me remember
what are the newer/older parts. Which then helps in seeing where the line
is between when features are added, all parts after have it, etc..

No issue with alphabetical either, just looking for a "why" in the
commit message, otherwise,

Reviewed-by: Andrew Davis 



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

Re: [PATCH] arm: mach-k3: am62p: Fixup TF-A/OP-TEE reserved-memory node in FDT

[Andrew Davis]

On 5/23/24 11:43 AM, Bryan Brattlof wrote:

The address we load TFA and OPTEE is configurable by the
CONFIG_K3_{ATF,OPTEE)_LOAD_ADDR, but the DT node reservations remain
static which can cause some confusion about where exactly these firmware
are exactly. Fix this by updating the reserved-memory{} nodes when the
loaded address does not match the address in DT.

Reported-by: Andrew Davis 
Signed-off-by: Bryan Brattlof 
---
Hello everyone,

This is a little fixup to avoid any confusion once we're in the kernel.
Because TF-A can be configured in U-Boot to be anywhere we want, we need
up update the reserved-memory{} node with this change.

Thanks for reviewing
~Bryan
---
  arch/arm/mach-k3/Makefile   |  1 +
  arch/arm/mach-k3/am62p5_fdt.c   | 16 


You'll want to rebase this on -next, these _fdt.c files all got moved
into directories for each SoC.

Andrew


  arch/arm/mach-k3/am62px/Kconfig |  1 +
  3 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 1bd523329a4f8..4e9d0925f13f5 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
  obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
  obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_fdt.o
  obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o
+obj-$(CONFIG_SOC_K3_AM62P5) += am62p5_fdt.o
  endif
  ifeq ($(CONFIG_SPL_BUILD),y)
  obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
diff --git a/arch/arm/mach-k3/am62p5_fdt.c b/arch/arm/mach-k3/am62p5_fdt.c
new file mode 100644
index 0..d67f012a5dcc4
--- /dev/null
+++ b/arch/arm/mach-k3/am62p5_fdt.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include "common_fdt.h"
+#include 
+
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+   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/am62px/Kconfig b/arch/arm/mach-k3/am62px/Kconfig
index 38a9e6811b119..76ae86b66222f 100644
--- a/arch/arm/mach-k3/am62px/Kconfig
+++ b/arch/arm/mach-k3/am62px/Kconfig
@@ -13,6 +13,7 @@ config TARGET_AM62P5_A53_EVM
bool "TI K3 based AM62P5 EVM running on A53"
select ARM64
select BINMAN
+   select OF_SYSTEM_SETUP
  
  config TARGET_AM62P5_R5_EVM

bool "TI K3 based AM62P5 EVM running on R5"

---
base-commit: a7f0154c412859323396111dd0c09dbafbc153cb
change-id: 20240520-am62p-fdt-fix-7c51e1a1cd54

Best regards,

Re: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores

[Andrew Davis]

On 5/22/24 1:36 AM, MD Danish Anwar wrote:

Add remoteproc-name property for PRU cores.

Signed-off-by: MD Danish Anwar 
---
  arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++
  1 file changed, 44 insertions(+)

diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi 
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 705b3baa81..25ddace74e 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -11,6 +11,50 @@
};
  };
  
+_0 {

+   remoteproc-name = "pru0_0";


Why do we need all these? Looks like we fallback to using `dev->name` if
these are not set, does that not work for us here?

Andrew


+};
+
+_0 {
+   remoteproc-name = "rtu0_0";
+};
+
+_pru0_0 {
+   remoteproc-name = "tx_pru0_0";
+};
+
+_1 {
+   remoteproc-name = "pru0_1";
+};
+
+_1 {
+   remoteproc-name = "rtu0_1";
+};
+
+_pru0_1 {
+   remoteproc-name = "tx_pru0_1";
+};
+
+_0 {
+   remoteproc-name = "pru1_0";
+};
+
+_0 {
+   remoteproc-name = "rtu1_0";
+};
+
+_pru1_0 {
+   remoteproc-name = "tx_pru1_0";
+};
+
+_1 {
+   remoteproc-name = "pru1_1";
+};
+
+_1 {
+   remoteproc-name = "rtu1_1";
+};
+
  _timer0 {
clock-frequency = <2>;
  };

Re: [PATCH 2/7] arm: mach-k3: j721e: Enable QoS for DSS

[Andrew Davis]

EMMCSD4SS_MAIN_1_EMMCSDSS_RD   0x45D82800
+#define EMMCSD4SS_MAIN_1_EMMCSDSS_WR   0x45D82C00
+#define PULSAR_SL_MAIN_0_MEMBDG_RMST0  0x45D84000
+#define PULSAR_SL_MAIN_0_MEMBDG_RMST1  0x45D84400
+#define PULSAR_SL_MAIN_0_MEMBDG_WMST0  0x45D84800
+#define PULSAR_SL_MAIN_0_MEMBDG_WMST1  0x45D84C00
+#define PULSAR_SL_MAIN_1_MEMBDG_RMST0  0x45D85000
+#define PULSAR_SL_MAIN_1_MEMBDG_RMST1  0x45D85400
+#define PULSAR_SL_MAIN_1_MEMBDG_WMST0  0x45D85800
+#define PULSAR_SL_MAIN_1_MEMBDG_WMST1  0x45D85C00
+#define COMPUTE_CLUSTER_J7ES_TB_VDC_MAIN_0_GIC_MEM_RD_VBUSM0x45D86000
+#define COMPUTE_CLUSTER_J7ES_TB_VDC_MAIN_0_GIC_MEM_WR_VBUSM0x45D86400
+#define K3_C66_COREPAC_MAIN_0_C66_CFG  0x45D87000
+#define K3_C66_COREPAC_MAIN_1_C66_CFG  0x45D87400
+#define SA2_UL_MAIN_0_CTXCACH_EXT_DMA  0x45D88800
+#define PULSAR_SL_MAIN_0_PBDG_RMST00x45D89800
+#define PULSAR_SL_MAIN_0_PBDG_RMST10x45D89C00
+#define PULSAR_SL_MAIN_0_PBDG_WMST00x45D8A000
+#define PULSAR_SL_MAIN_0_PBDG_WMST10x45D8A400
+#define PULSAR_SL_MAIN_1_PBDG_RMST00x45D8A800
+#define PULSAR_SL_MAIN_1_PBDG_RMST10x45D8AC00
+#define PULSAR_SL_MAIN_1_PBDG_WMST00x45D8B000
+#define PULSAR_SL_MAIN_1_PBDG_WMST10x45D8B400
+#define VPFE_MAIN_0_VBUSM_DMA  0x45D8C000
+#define VPE_MAIN_0_VPDMA_MST0  0x45D8C400
+#define VPE_MAIN_0_VPDMA_MST1  0x45D8C800
+#define PCIE_G4X2_MAIN_0_PCIE_MST_RD_HP0x45D9
+#define PCIE_G4X2_MAIN_0_PCIE_MST_RD_LP0x45D90400
+#define PCIE_G4X2_MAIN_0_PCIE_MST_WR_HP0x45D90800
+#define PCIE_G4X2_MAIN_0_PCIE_MST_WR_LP0x45D90C00
+#define PCIE_G4X2_MAIN_1_PCIE_MST_RD_HP0x45D91000
+#define PCIE_G4X2_MAIN_1_PCIE_MST_RD_LP0x45D91400
+#define PCIE_G4X2_MAIN_1_PCIE_MST_WR_HP0x45D91800
+#define PCIE_G4X2_MAIN_1_PCIE_MST_WR_LP0x45D91C00
+#define PCIE_G4X2_MAIN_2_PCIE_MST_RD_HP0x45D92000
+#define PCIE_G4X2_MAIN_2_PCIE_MST_RD_LP0x45D92400
+#define PCIE_G4X2_MAIN_2_PCIE_MST_WR_HP0x45D92800
+#define PCIE_G4X2_MAIN_2_PCIE_MST_WR_LP0x45D92C00
+#define PCIE_G4X2_MAIN_3_PCIE_MST_RD_HP0x45D93000
+#define PCIE_G4X2_MAIN_3_PCIE_MST_RD_LP0x45D93400
+#define PCIE_G4X2_MAIN_3_PCIE_MST_WR_HP0x45D93800
+#define PCIE_G4X2_MAIN_3_PCIE_MST_WR_LP0x45D93C00
+#define USB3P0SS_16FFC_MAIN_0_MSTR00x45D98000
+#define USB3P0SS_16FFC_MAIN_0_MSTW00x45D98400
+#define USB3P0SS_16FFC_MAIN_1_MSTR00x45D98800
+#define USB3P0SS_16FFC_MAIN_1_MSTW00x45D98C00
+#define USB3P0SS_16FFC_MAIN_2_MSTR00x45D99000
+#define USB3P0SS_16FFC_MAIN_2_MSTW00x45D99400
+#define MLBSS2P0_MAIN_0_MLBSS_DMA_VBUSP0x45D99C00
+#define EMMC8SS_16FFC_MAIN_0_EMMCSS_RD 0x45D9A000
+#define EMMC8SS_16FFC_MAIN_0_EMMCSS_WR 0x45D9A400
+#define UFSHCI2P1SS_16FFC_MAIN_0_UFSHCI_VBM_MST_RD 0x45D9B000
+#define UFSHCI2P1SS_16FFC_MAIN_0_UFSHCI_VBM_MST_WR 0x45D9B400
+#define UFSHCI2P1SS_16FFC_MAIN_1_UFSHCI_VBM_MST_RD 0x45D9B800
+#define UFSHCI2P1SS_16FFC_MAIN_1_UFSHCI_VBM_MST_WR 0x45D9BC00
+#define DEBUGSS_K3_WRAP_CV0_MAIN_0_VBUSMR  0x45DA
+#define DEBUGSS_K3_WRAP_CV0_MAIN_0_VBUSMW  0x45DA0400
+#define PULSAR_SL_MAIN_0_CPU0_PMST 0x45DA4000
+#define PULSAR_SL_MAIN_0_CPU1_PMST 0x45DA4400
+#define PULSAR_SL_MAIN_1_CPU0_PMST 0x45DA4800
+#define PULSAR_SL_MAIN_1_CPU1_PMST 0x45DA4C00
+#define DMPAC_TOP_MAIN_0_DATA_MST  0x45DC
+#define K3_D5520MP2_MAIN_0_M_VBUSM_R   0x45DC0400
+#define K3_D5520MP2_MAIN_0_M_VBUSM_W   0x45DC0800
+#define K3_VXE384MP2_MAIN_0_M_VBUSM_R  0x45DC0C00
+#define K3_VXE384MP2_MAIN_0_M_VBUSM_W  0x45DC1000
+#define VPAC_TOP_MAIN_0_DATA_MST_0 0x45DC1400
+#define VPAC_TOP_MAIN_0_DATA_MST_1 0x45DC1800
+#define VPAC_TOP_MAIN_0_LDC0_M_MST 0x45DC1C00
+#define K3_DSS_MAIN_0_DSS_INST0_VBUSM_DMA  0x45DC2000
+#define K3_DSS_MAIN_0_DSS_INST0_VBUSM_FBDC 0x45DC2400
+#define J7_LASCAR_GPU_WRAP_MAIN_0_M0_VBUSM_R_ASYNC 0x45DC5000
+#define J7_LASCAR_GPU_WRAP_MAIN_0_M0_VBUSM_W_ASYNC 0x45DC5800
+#define J7_LASCAR_GPU_WRAP_MAIN_0_M1_VBUSM_R_ASYNC 0x45DC6000
+#define J7_LASCAR_GPU_WRAP_MAIN_0_M1_VBUSM_W_ASYNC 0x45DC6800
diff --git a/arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c 
b/arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c
new file mode 100644
index 00..c829057200
--- /dev/null
+++ b/arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * j721e Quality of Service (QoS) Configuration Data
+ * Auto generated from K3 Resource Partitioning tool
+ */
+
+#include 
+#include "j721e_qos.h"
+
+struct k3_qos_data qos_data[] = {
+   /* DSS_PIPE_VID1 - 2 endpoints, 2 channels */
+   {
+   .reg = K3_DSS_MAIN_0_DSS_INST0_VBUSM_DMA + 0x100 + 0x4 * 0,


0x100 being the instance, and 0x4 * x being the specific device register right?
That could be encoded in a macro (the "Resource Partitioning tool" would
be updated to generate that too).

Andrew


+   .val = ATYPE_3 | ORDERID_15,
+   },
+   

Re: [PATCH 1/7] arm: mach-k3: am62a_qos: Move common bit MACROS to k3_qos header file

[Andrew Davis]

On 5/22/24 6:37 AM, Jayesh Choudhary wrote:

QoS bit mapping are common across all K3 SoCs so move those defines
to common header file (k3_qos.h).
This ensures that we do not define these for each SoC.

Signed-off-by: Jayesh Choudhary 
---
  arch/arm/mach-k3/include/mach/k3-qos.h | 74 ++
  arch/arm/mach-k3/r5/am62ax/am62a_qos.h | 74 --
  2 files changed, 74 insertions(+), 74 deletions(-)

diff --git a/arch/arm/mach-k3/include/mach/k3-qos.h 
b/arch/arm/mach-k3/include/mach/k3-qos.h
index e00e1de5b9..6ed5704803 100644
--- a/arch/arm/mach-k3/include/mach/k3-qos.h
+++ b/arch/arm/mach-k3/include/mach/k3-qos.h
@@ -9,6 +9,80 @@
  
  #include 
  
+#define QOS_0	(0 << 0)

+#define QOS_1  (1 << 0)
+#define QOS_2  (2 << 0)
+#define QOS_3  (3 << 0)
+#define QOS_4  (4 << 0)
+#define QOS_5  (5 << 0)
+#define QOS_6  (6 << 0)
+#define QOS_7  (7 << 0)
+
+#define ORDERID_0  (0 << 4)
+#define ORDERID_1  (1 << 4)
+#define ORDERID_2  (2 << 4)
+#define ORDERID_3  (3 << 4)
+#define ORDERID_4  (4 << 4)
+#define ORDERID_5  (5 << 4)
+#define ORDERID_6  (6 << 4)
+#define ORDERID_7  (7 << 4)
+#define ORDERID_8  (8 << 4)
+#define ORDERID_9  (9 << 4)
+#define ORDERID_10 (10 << 4)
+#define ORDERID_11 (11 << 4)
+#define ORDERID_12 (12 << 4)
+#define ORDERID_13 (13 << 4)
+#define ORDERID_14 (14 << 4)
+#define ORDERID_15 (15 << 4)
+
+#define ASEL_0 (0 << 8)
+#define ASEL_1 (1 << 8)
+#define ASEL_2 (2 << 8)
+#define ASEL_3 (3 << 8)
+#define ASEL_4 (4 << 8)
+#define ASEL_5 (5 << 8)
+#define ASEL_6 (6 << 8)
+#define ASEL_7 (7 << 8)
+#define ASEL_8 (8 << 8)
+#define ASEL_9 (9 << 8)
+#define ASEL_10(10 << 8)
+#define ASEL_11(11 << 8)
+#define ASEL_12(12 << 8)
+#define ASEL_13(13 << 8)
+#define ASEL_14(14 << 8)
+#define ASEL_15(15 << 8)
+
+#define EPRIORITY_0(0 << 12)
+#define EPRIORITY_1(1 << 12)
+#define EPRIORITY_2(2 << 12)
+#define EPRIORITY_3(3 << 12)
+#define EPRIORITY_4(4 << 12)
+#define EPRIORITY_5(5 << 12)
+#define EPRIORITY_6(6 << 12)
+#define EPRIORITY_7(7 << 12)
+
+#define VIRTID_0   (0 << 16)
+#define VIRTID_1   (1 << 16)
+#define VIRTID_2   (2 << 16)
+#define VIRTID_3   (3 << 16)
+#define VIRTID_4   (4 << 16)
+#define VIRTID_5   (5 << 16)
+#define VIRTID_6   (6 << 16)
+#define VIRTID_7   (7 << 16)
+#define VIRTID_8   (8 << 16)
+#define VIRTID_9   (9 << 16)
+#define VIRTID_10  (10 << 16)
+#define VIRTID_11  (11 << 16)
+#define VIRTID_12  (12 << 16)
+#define VIRTID_13  (13 << 16)
+#define VIRTID_14  (14 << 16)
+#define VIRTID_15  (15 << 16)



This all seem like it could be made into some macro, something like

#define K3_QOS(qos, orderid, asel, epriority, virtid, atype) \
(qos << 0 | \
 orderid << 4 | \
 asel<< 8 | \
etc..

Then use that instead of raw values. That might also make it more clear
we are setting the other values to 0 when we are setting these registers:

.val = K3_QOS(0, 15, 0, 0, 0, 3),

Andrew



+
+#define ATYPE_0(0 << 28)
+#define ATYPE_1(1 << 28)
+#define ATYPE_2(2 << 28)
+#define ATYPE_3(3 << 28)
+
  struct k3_qos_data {
u32 reg;
u32 val;
diff --git a/arch/arm/mach-k3/r5/am62ax/am62a_qos.h 
b/arch/arm/mach-k3/r5/am62ax/am62a_qos.h
index c74d69a28f..84a6dc7240 100644
--- a/arch/arm/mach-k3/r5/am62ax/am62a_qos.h
+++ b/arch/arm/mach-k3/r5/am62ax/am62a_qos.h
@@ -6,80 +6,6 @@
   * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
   */
  
-#define QOS_0	(0 << 0)

-#define QOS_1  (1 << 0)
-#define QOS_2  (2 << 0)
-#define QOS_3  (3 << 0)
-#define QOS_4  (4 << 0)
-#define QOS_5  (5 << 0)
-#define QOS_6  (6 << 0)
-#define QOS_7  (7 << 0)
-
-#define ORDERID_0  (0 << 4)
-#define ORDERID_1  (1 << 4)
-#define ORDERID_2  (2 << 4)
-#define ORDERID_3  (3 << 4)
-#define ORDERID_4  (4 << 4)
-#define ORDERID_5  (5 << 4)
-#define ORDERID_6  (6 << 4)
-#define ORDERID_7  (7 << 4)
-#define ORDERID_8  (8 << 4)
-#define ORDERID_9  (9 << 4)
-#define ORDERID_10 (10 << 4)
-#define ORDERID_11 (11 << 4)
-#define ORDERID_12 (12 << 4)
-#define ORDERID_13 (13 << 4)
-#define ORDERID_14 (14 << 4)
-#define ORDERID_15 (15 << 4)
-
-#define ASEL_0 (0 << 8)
-#define AS

Re: [PATCH v3 2/2] configs: add defconfigs for the am625-lp-sk

[Andrew Davis]

On 5/15/24 1:21 PM, Tom Rini wrote:

On Fri, May 03, 2024 at 11:44:29AM -0500, Bryan Brattlof wrote:


The am62x-lp-sk is a package and reference board spin of the am62x-sk to
showcase the low-power features of the am62x SoC family. Because it so
closely resembles the am62x-sk board, use the preprocessor to inherit
its configuration making the needed changes for this board where
necessary.

Reviewed-by: Dhruva Gole 
Signed-off-by: Bryan Brattlof 
---
  configs/am62x_lp_sk_a53_defconfig | 3 +++
  configs/am62x_lp_sk_r5_defconfig  | 2 ++
  2 files changed, 5 insertions(+)

diff --git a/configs/am62x_lp_sk_a53_defconfig 
b/configs/am62x_lp_sk_a53_defconfig
new file mode 100644
index 0..904b2142b2f53
--- /dev/null
+++ b/configs/am62x_lp_sk_a53_defconfig
@@ -0,0 +1,3 @@
+#include 
+CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62-lp-sk"
+CONFIG_OF_UPSTREAM=y


So, there's a problem here. The #include trick for defconfig files isn't
working as intended, exactly. The example here doesn't work right.
First, it shows up as a variant of "sandbox" (as buildman will show and
leads to https://source.denx.de/u-boot/u-boot/-/jobs/835067#L119)

And this becomes clearer if you look at configs/am69_sk_r5_defconfig
which has to set some symbols already found in
configs/j784s4_evm_r5_defconfig in order to work. This is seemingly very
not equivalent to invoking "make foo_defconfig bar.config" to combine
things.



This is equivalent when running make. The issue is with buildman which
manually checks the content of the defconfig to find what ARCH it should
run the defconfig with. buildman doesn't understand the #include yet.
Until buildman can be fixed, you'll need to do what we did with
am69_sk_r5_defconfig and redefine the ARCH/SOC/TARGET info in the
defconfig file so buildman can find it without following the #include.

Andrew

Re: [PATCH v2 5/8] drivers: ram: Kconfig: Add CONFIG_K3_INLINE_ECC

[Andrew Davis]

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.

Maybe we want this to be `default y` so that we do not change
current behavior and platforms can opt-out as needed instead.

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"

[PATCH v2] arm: mach-k3: Move code specific to a SoC into that SoC's directory

[Andrew Davis]

Each SoC now has a directory in mach-k3, let's move the SoC specific
files into their respective directories.

Signed-off-by: Andrew Davis 
---

Changes for v2:
 - Rebased on latest -next

 arch/arm/mach-k3/Makefile   | 24 ++---
 arch/arm/mach-k3/am62ax/Makefile|  7 ++
 arch/arm/mach-k3/{ => am62ax}/am62a7_fdt.c  |  3 ++-
 arch/arm/mach-k3/{ => am62ax}/am62a7_init.c |  5 +++--
 arch/arm/mach-k3/am62px/Makefile|  6 ++
 arch/arm/mach-k3/{ => am62px}/am62p5_init.c |  5 +++--
 arch/arm/mach-k3/am62x/Makefile |  3 +++
 arch/arm/mach-k3/{ => am62x}/am625_fdt.c|  3 ++-
 arch/arm/mach-k3/{ => am62x}/am625_init.c   |  5 +++--
 arch/arm/mach-k3/am64x/Makefile |  2 ++
 arch/arm/mach-k3/{ => am64x}/am642_init.c   |  5 +++--
 arch/arm/mach-k3/am65x/Makefile |  7 ++
 arch/arm/mach-k3/{ => am65x}/am654_fdt.c|  3 ++-
 arch/arm/mach-k3/{ => am65x}/am654_init.c   |  5 +++--
 arch/arm/mach-k3/j721e/Makefile |  7 ++
 arch/arm/mach-k3/{ => j721e}/j721e_fdt.c|  3 ++-
 arch/arm/mach-k3/{ => j721e}/j721e_init.c   |  5 +++--
 arch/arm/mach-k3/j721s2/Makefile|  7 ++
 arch/arm/mach-k3/{ => j721s2}/j721s2_fdt.c  |  3 ++-
 arch/arm/mach-k3/{ => j721s2}/j721s2_init.c |  5 +++--
 arch/arm/mach-k3/j784s4/Makefile|  7 ++
 arch/arm/mach-k3/{ => j784s4}/j784s4_fdt.c  |  3 ++-
 arch/arm/mach-k3/{ => j784s4}/j784s4_init.c |  5 +++--
 23 files changed, 88 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/mach-k3/am62ax/Makefile
 rename arch/arm/mach-k3/{ => am62ax}/am62a7_fdt.c (93%)
 rename arch/arm/mach-k3/{ => am62ax}/am62a7_init.c (99%)
 create mode 100644 arch/arm/mach-k3/am62px/Makefile
 rename arch/arm/mach-k3/{ => am62px}/am62p5_init.c (99%)
 rename arch/arm/mach-k3/{ => am62x}/am625_fdt.c (98%)
 rename arch/arm/mach-k3/{ => am62x}/am625_init.c (99%)
 rename arch/arm/mach-k3/{ => am64x}/am642_init.c (99%)
 create mode 100644 arch/arm/mach-k3/am65x/Makefile
 rename arch/arm/mach-k3/{ => am65x}/am654_fdt.c (88%)
 rename arch/arm/mach-k3/{ => am65x}/am654_init.c (99%)
 create mode 100644 arch/arm/mach-k3/j721e/Makefile
 rename arch/arm/mach-k3/{ => j721e}/j721e_fdt.c (88%)
 rename arch/arm/mach-k3/{ => j721e}/j721e_init.c (99%)
 create mode 100644 arch/arm/mach-k3/j721s2/Makefile
 rename arch/arm/mach-k3/{ => j721s2}/j721s2_fdt.c (88%)
 rename arch/arm/mach-k3/{ => j721s2}/j721s2_init.c (99%)
 create mode 100644 arch/arm/mach-k3/j784s4/Makefile
 rename arch/arm/mach-k3/{ => j784s4}/j784s4_fdt.c (92%)
 rename arch/arm/mach-k3/{ => j784s4}/j784s4_init.c (99%)

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 3101f57d324..2b3ebd5c535 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -6,24 +6,12 @@
 obj-$(CONFIG_ARM64) += arm64/
 obj-$(CONFIG_CPU_V7R) += r5/
 obj-$(CONFIG_OF_LIBFDT) += common_fdt.o
-ifeq ($(CONFIG_OF_LIBFDT)$(CONFIG_OF_SYSTEM_SETUP),yy)
-obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
-obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o
-obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
-obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
-obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_fdt.o
-obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o
-endif
-ifeq ($(CONFIG_SPL_BUILD),y)
-obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
-obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o
-obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o
-obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
-obj-$(CONFIG_SOC_K3_AM625) += am625_init.o
-obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o
-obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o
-obj-$(CONFIG_SOC_K3_AM62P5) += am62p5_init.o
-endif
 obj-y += common.o security.o
+obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
+obj-$(CONFIG_SOC_K3_AM62P5) += am62px/
 obj-$(CONFIG_SOC_K3_AM625) += am62x/
 obj-$(CONFIG_SOC_K3_AM642) += am64x/
+obj-$(CONFIG_SOC_K3_AM654) += am65x/
+obj-$(CONFIG_SOC_K3_J721E) += j721e/
+obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
+obj-$(CONFIG_SOC_K3_J784S4) += j784s4/
diff --git a/arch/arm/mach-k3/am62ax/Makefile b/arch/arm/mach-k3/am62ax/Makefile
new file mode 100644
index 000..1717ca343d6
--- /dev/null
+++ b/arch/arm/mach-k3/am62ax/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+#  Andrew Davis 
+
+obj-$(CONFIG_OF_SYSTEM_SETUP) += am62a7_fdt.o
+obj-$(CONFIG_SPL_BUILD) += am62a7_init.o
diff --git a/arch/arm/mach-k3/am62a7_fdt.c 
b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
similarity index 93%
rename from arch/arm/mach-k3/am62a7_fdt.c
rename to arch/arm/mach-k3/am62ax/am62a7_fdt.c
index d67f012a5dc..7f764ab36b5 100644
--- a/arch/arm/mach-k3/am62a7_fdt.c
+++ b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
@@ -4,9 +4,10 @@
  */
 
 #include 
-#include "common_fdt.h"
 #include 
 
+#include "../common_fdt.h"
+
 int ft_system_setup(void *blob, struct bd_info 

Re: [PATCH v2 2/2] arm: dts: k3-j7200-binman: Add support for HSSE1.0 and HSFS1.0

[Andrew Davis]

On 4/25/24 5:06 PM, Neha Malcom Francis wrote:

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.



SR1.0 silicon for J7200 is rare as it was replaced by SR2.0 before
broad-market release (IIRC), but for completeness this is fine to
have supported,

Reviewed-by: Andrew Davis 


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";
+

Re: [PATCH v2 1/2] arm: dts: k3-j721e-binman: Add support for HSFS1.1

[Andrew Davis]

On 4/25/24 5:06 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-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



Looks good to me now,

Reviewed-by: Andrew Davis 


  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&qu

[PATCH] arm: mach-k3: am62ax: Fix typo in ROM data macro name

[Andrew Davis]

s/ENTENDED/EXTENDED

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/am62a7_init.c | 2 +-
 arch/arm/mach-k3/include/mach/am62a_hardware.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
index 2a0221a3718..658828cf75f 100644
--- a/arch/arm/mach-k3/am62a7_init.c
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -31,7 +31,7 @@ static void store_boot_info_from_rom(void)
bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
 
if (IS_ENABLED(CONFIG_CPU_V7R)) {
-   memcpy(, (uintptr_t *)ROM_ENTENDED_BOOT_DATA_INFO,
+   memcpy(, (uintptr_t *)ROM_EXTENDED_BOOT_DATA_INFO,
   sizeof(struct rom_extended_boot_data));
}
 }
diff --git a/arch/arm/mach-k3/include/mach/am62a_hardware.h 
b/arch/arm/mach-k3/include/mach/am62a_hardware.h
index 11080801c4c..cd61abe0185 100644
--- a/arch/arm/mach-k3/include/mach/am62a_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am62a_hardware.h
@@ -66,7 +66,7 @@
 #define MCU_CTRL_DEVICE_CLKOUT_32K_CTRL(MCU_CTRL_MMR0_BASE + 
0x8058)
 #define MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL(0x3)
 
-#define ROM_ENTENDED_BOOT_DATA_INFO0x43c3f1e0
+#define ROM_EXTENDED_BOOT_DATA_INFO0x43c3f1e0
 
 #define K3_BOOT_PARAM_TABLE_INDEX_OCRAM 0x7000F290
 
-- 
2.39.2

[PATCH] arm: mach-k3: Move code specific to a SoC into that SoC's directory

[Andrew Davis]

Each SoC now has a directory in mach-k3, let's move the SoC specific
files into their respective directories.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/Makefile   | 27 ++---
 arch/arm/mach-k3/am62ax/Makefile|  7 ++
 arch/arm/mach-k3/{ => am62ax}/am62a7_fdt.c  |  3 ++-
 arch/arm/mach-k3/{ => am62ax}/am62a7_init.c |  5 ++--
 arch/arm/mach-k3/am62px/Makefile|  6 +
 arch/arm/mach-k3/{ => am62px}/am62p5_init.c |  5 ++--
 arch/arm/mach-k3/am62x/Makefile |  3 +++
 arch/arm/mach-k3/{ => am62x}/am625_fdt.c|  3 ++-
 arch/arm/mach-k3/{ => am62x}/am625_init.c   |  5 ++--
 arch/arm/mach-k3/am64x/Makefile |  6 +
 arch/arm/mach-k3/{ => am64x}/am642_init.c   |  5 ++--
 arch/arm/mach-k3/am65x/Makefile |  7 ++
 arch/arm/mach-k3/{ => am65x}/am654_fdt.c|  3 ++-
 arch/arm/mach-k3/{ => am65x}/am654_init.c   |  5 ++--
 arch/arm/mach-k3/j721e/Makefile |  7 ++
 arch/arm/mach-k3/{ => j721e}/j721e_fdt.c|  3 ++-
 arch/arm/mach-k3/{ => j721e}/j721e_init.c   |  5 ++--
 arch/arm/mach-k3/j721s2/Makefile|  7 ++
 arch/arm/mach-k3/{ => j721s2}/j721s2_fdt.c  |  3 ++-
 arch/arm/mach-k3/{ => j721s2}/j721s2_init.c |  5 ++--
 arch/arm/mach-k3/j784s4/Makefile|  7 ++
 arch/arm/mach-k3/{ => j784s4}/j784s4_fdt.c  |  3 ++-
 arch/arm/mach-k3/{ => j784s4}/j784s4_init.c |  5 ++--
 23 files changed, 94 insertions(+), 41 deletions(-)
 create mode 100644 arch/arm/mach-k3/am62ax/Makefile
 rename arch/arm/mach-k3/{ => am62ax}/am62a7_fdt.c (93%)
 rename arch/arm/mach-k3/{ => am62ax}/am62a7_init.c (99%)
 create mode 100644 arch/arm/mach-k3/am62px/Makefile
 rename arch/arm/mach-k3/{ => am62px}/am62p5_init.c (99%)
 rename arch/arm/mach-k3/{ => am62x}/am625_fdt.c (98%)
 rename arch/arm/mach-k3/{ => am62x}/am625_init.c (99%)
 create mode 100644 arch/arm/mach-k3/am64x/Makefile
 rename arch/arm/mach-k3/{ => am64x}/am642_init.c (99%)
 create mode 100644 arch/arm/mach-k3/am65x/Makefile
 rename arch/arm/mach-k3/{ => am65x}/am654_fdt.c (88%)
 rename arch/arm/mach-k3/{ => am65x}/am654_init.c (99%)
 create mode 100644 arch/arm/mach-k3/j721e/Makefile
 rename arch/arm/mach-k3/{ => j721e}/j721e_fdt.c (88%)
 rename arch/arm/mach-k3/{ => j721e}/j721e_init.c (99%)
 create mode 100644 arch/arm/mach-k3/j721s2/Makefile
 rename arch/arm/mach-k3/{ => j721s2}/j721s2_fdt.c (88%)
 rename arch/arm/mach-k3/{ => j721s2}/j721s2_init.c (99%)
 create mode 100644 arch/arm/mach-k3/j784s4/Makefile
 rename arch/arm/mach-k3/{ => j784s4}/j784s4_fdt.c (92%)
 rename arch/arm/mach-k3/{ => j784s4}/j784s4_init.c (99%)

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 1bd523329a4..10e73463471 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -6,23 +6,12 @@
 obj-$(CONFIG_ARM64) += arm64/
 obj-$(CONFIG_CPU_V7R) += r5/
 obj-$(CONFIG_OF_LIBFDT) += common_fdt.o
-ifeq ($(CONFIG_OF_LIBFDT)$(CONFIG_OF_SYSTEM_SETUP),yy)
-obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
-obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o
-obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
-obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
-obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_fdt.o
-obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o
-endif
-ifeq ($(CONFIG_SPL_BUILD),y)
-obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
-obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o
-obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o
-obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
-obj-$(CONFIG_SOC_K3_AM625) += am625_init.o
-obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o
-obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o
-obj-$(CONFIG_SOC_K3_AM62P5) += am62p5_init.o
-endif
-obj-y += common.o security.o
+obj-$(CONFIG_SOC_K3_AM654) += am65x/
+obj-$(CONFIG_SOC_K3_J721E) += j721e/
+obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
+obj-$(CONFIG_SOC_K3_AM642) += am64x/
 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 security.o
diff --git a/arch/arm/mach-k3/am62ax/Makefile b/arch/arm/mach-k3/am62ax/Makefile
new file mode 100644
index 000..1717ca343d6
--- /dev/null
+++ b/arch/arm/mach-k3/am62ax/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+#  Andrew Davis 
+
+obj-$(CONFIG_OF_SYSTEM_SETUP) += am62a7_fdt.o
+obj-$(CONFIG_SPL_BUILD) += am62a7_init.o
diff --git a/arch/arm/mach-k3/am62a7_fdt.c 
b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
similarity index 93%
rename from arch/arm/mach-k3/am62a7_fdt.c
rename to arch/arm/mach-k3/am62ax/am62a7_fdt.c
index d67f012a5dc..7f764ab36b5 100644
--- a/arch/arm/mach-k3/am62a7_fdt.c
+++ b/arch/arm/mach-k3/am62ax/am62a7_fdt.c
@@ -4,9 +4,10 @@
  */
 
 #include 
-#include "common_fdt.h"
 #include 
 
+#include "../common_fdt.h"
+
 int ft_system_

Re: [PATCH 1/2] arm: dts: k3-j721e-binman: Add support for HSSE2.0 and HSFS1.1

[Andrew Davis]

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


+   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"

[PATCH] arm: mach-k3: am642: Fix reset for workaround errata ID i2331

[Andrew Davis]

To workaround an issue in AM642 we reset the SoC in early boot. For that
we first probed the sysreset driver by calling uclass_get_device(). The
ti-sci sysreset driver is now probed during the ti-sci firmware probe.
Update this call to probe the firmware driver which will then probe
the sysreset driver allowing do_reset() to again function as expected.

Reported-by: Jonathan Humphreys 
Fixes: fc5d40283483 ("firmware: ti_sci: Bind sysreset driver when enabled")
Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/am642_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index ddf47ef0a9b..80c3cb3479f 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -226,7 +226,7 @@ void board_init_f(ulong dummy)
 * The warm reset realigns internal clocks and prevents the lockup from
 * happening.
 */
-   ret = uclass_first_device_err(UCLASS_SYSRESET, );
+   ret = uclass_get_device_by_driver(UCLASS_FIRMWARE, 
DM_DRIVER_GET(ti_sci), );
if (ret)
printf("\n%s:uclass device error [%d]\n",__func__,ret);
 
-- 
2.39.2

[PATCH] arm: mach-k3: security: Lower verbosity of cert message for GP

[Andrew Davis]

When we find a certificate on an image to be booted on a GP device we
print out a message explaining that the certificate is being skipped.
This message is rather long and is printed for every image. Shorten
the message and make the long version into a debug message.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/security.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c
index 22697a263a8..7c46914d9dd 100644
--- a/arch/arm/mach-k3/security.c
+++ b/arch/arm/mach-k3/security.c
@@ -50,7 +50,7 @@ void ti_secure_image_check_binary(void **p_image, size_t 
*p_size)
 
if (get_device_type() == K3_DEVICE_TYPE_GP) {
if (ti_secure_cert_detected(*p_image)) {
-   printf("Warning: Detected image signing certificate on 
GP device. "
+   debug("Warning: Detected image signing certificate on 
GP device. "
   "Skipping certificate to prevent boot failure. "
   "This will fail if the image was also 
encrypted\n");
 
@@ -60,6 +60,7 @@ void ti_secure_image_check_binary(void **p_image, size_t 
*p_size)
return;
}
 
+   printf("Skipping authentication on GP device\n");
*p_image += cert_length;
*p_size -= cert_length;
}
-- 
2.39.2

Re: [PATCH 3/7] dts: j721e: binman: Include firmware capsules binman nodes

[Andrew Davis]

On 4/10/24 1:24 PM, Jon Humphreys wrote:

Andrew Davis  writes:


On 4/8/24 5:17 PM, Jonathan Humphreys wrote:

Signed-off-by: Jonathan Humphreys 
---
   arch/arm/dts/k3-j721e-binman.dtsi | 32 +++
   1 file changed, 32 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-binman.dtsi 
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..9169551c422 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -207,6 +207,29 @@
};
};
   };
+
+#include "k3-binman-capsule-r5.dtsi"
+
+// Capsue update GUIDs.  See ti_armv7_common.h.
+#define K3_SYSFW_IMAGE_UUID_STR "6fd10680-361b-431f-80aa-899455819e11"
+
+ {
+   capsule-sysfw {
+   filename = "sysfw-capsule.bin";
+   efi-capsule {
+   image-index = <0x4>;
+   image-guid = K3_SYSFW_IMAGE_UUID_STR;
+   private-key = "arch/arm/mach-k3/keys/custMpk.pem";
+   public-key-cert = "arch/arm/mach-k3/keys/custMpk.crt";
+   monotonic-count = <0x1>;
+
+   blob {
+   filename = "sysfw.itb";
+   };
+   };
+   };
+};
+
   #endif
   
   #ifdef CONFIG_TARGET_J721E_A72_EVM

@@ -585,4 +608,13 @@
};
};
   };
+
+#include "k3-binman-capsule.dtsi"
+_name {
+   filename = "tispl.bin_unsigned";


Why use the _unsigned images here? HS devices cannot boot unsigned GP images,
but both GP and HS devices *can* boot the normal signed images (GP just strips
the signatures off). So no need to use the _unsigned images anymore (I'm
planning to just remove them at some point to prevent this confusion).


I can do that.

Note that you will then see warnings on GP devices during boot:

   Warning: Detected image signing certificate on GP device. Skipping 
certificate to prevent boot failure. This will fail if the image was also 
encrypted



True, I'll send a fix for that.

Andrew


Jon


Andrew


+};
+_name {
+   filename = "u-boot.img_unsigned";
+};
+
   #endif

Re: [PATCH 01/13] ti:keys Add EFI signature list

[Andrew Davis]

On 4/10/24 4:38 AM, Ilias Apalodimas wrote:

On Tue, 9 Apr 2024 at 23:14, Andrew Davis  wrote:


On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:

On 4/9/24 14:14, Andrew Davis wrote:

On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:

On 4/8/24 23:33, Jonathan Humphreys wrote:

EFI signature list using TI dummy keys.


Adding vendor public keys into the code base to lock down generated
binaries to the vendors unpublished private key does not match well with
the intent of the GNU public license.



The matching private keys are already published in this same
repo/directory (arch/arm/mach-k3/keys).

Andrew


Why should we create signed capsules which are already compromised by
publishing the private key?



If you buy these devices you have two options, you can burn real
keys, or you can burn these dummy keys. If you burn dummy keys
then these images will boot and so will any image you or anyone
else wants to boot on the device. (since the keys are published
anyone can make images for them, that is how we do GP (general
purpose) devices these days)

If you burn your own keys, then you switch out these keys here
and your device will only boot images that you permit by signing
with your keys.


I am not sure I am following you here.  We don't burn anything in the
case of EFI keys. They are placed in an elf section and we assume the
device will have a chain of trust enabled, naturally verifying those
keys along with the u-boot binary.



Right, you can (and probably should) use different keys stored in the
boot stages to verify the next stages. I was more giving the background
to why we publish our "private" keys at all here. Using the same keys
for every stage (including burning it in as the HW root of trust key)
is to make the examples here easier, but I think I see what you
are saying. It could be better to generate a key-pair as part of
this build for the EFI keys.



You'll find plenty of open source projects do the same and
give out example keys to show how to use real keys, even
official GNU projects.


Yes, but the keys defined here are useless unless you have a default
defconfig that uses them and embeds them in the binary. I am not cc'ed
in all the patches of the series, is that added somewhere? And if you
unconditionally enable secure boot It would be far more interesting to
embed the MS SHIM key along with that special key you are trying to
define, so that firmware can boot COTS distros as well



Using MS SHIM keys here does sound interesting, I'll let Jon comment
on if we want to add that to this series or save for later.

Thanks,
Andrew


Thanks
/Ilias




https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys

Andrew


Best regards

Heinrich




Best regards

Heinrich



Signed-off-by: Jonathan Humphreys 
---
   arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 arch/arm/mach-k3/keys/custMpk.esl

diff --git a/arch/arm/mach-k3/keys/custMpk.esl
b/arch/arm/mach-k3/keys/custMpk.esl
new file mode 100644
index
..2feb704e0a5fd126410de451d3c0fa4d3edccc52
GIT binary patch
literal 1523
zcmZ1^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
z&78AJODc2mtxpELY@Awc9)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
zQpnB26;PC)oLXF*UsMbeWai-t@l*_blshP#N9QH-w`BJNO+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)+#e3fJowDZO)JR83lIcbw(hMu}}Y
z2ZZwYAI-LVx@^G;HdkgxaX_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
z{LIBUzm_CMw_SIFfPdcT#zmg6g{#b(Lp`M3Uj
zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
z8dh8T-~Dmrp2?yk3O6Gqbz7O@W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
zKlQ}fzw*izXI|}|r!O*nb#VhHRn;B`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~+5t
z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
z_N{pmM}uCi3UWO3=hMciTPl?N16Xv@buq_d@TU`uX0_s{?
zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
z>fTMIw2!Me3{Dw*WZotC<4@h

Re: [PATCH 3/7] dts: j721e: binman: Include firmware capsules binman nodes

[Andrew Davis]

On 4/8/24 5:17 PM, Jonathan Humphreys wrote:

Signed-off-by: Jonathan Humphreys 
---
  arch/arm/dts/k3-j721e-binman.dtsi | 32 +++
  1 file changed, 32 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-binman.dtsi 
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..9169551c422 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -207,6 +207,29 @@
};
};
  };
+
+#include "k3-binman-capsule-r5.dtsi"
+
+// Capsue update GUIDs.  See ti_armv7_common.h.
+#define K3_SYSFW_IMAGE_UUID_STR "6fd10680-361b-431f-80aa-899455819e11"
+
+ {
+   capsule-sysfw {
+   filename = "sysfw-capsule.bin";
+   efi-capsule {
+   image-index = <0x4>;
+   image-guid = K3_SYSFW_IMAGE_UUID_STR;
+   private-key = "arch/arm/mach-k3/keys/custMpk.pem";
+   public-key-cert = "arch/arm/mach-k3/keys/custMpk.crt";
+   monotonic-count = <0x1>;
+
+   blob {
+   filename = "sysfw.itb";
+   };
+   };
+   };
+};
+
  #endif
  
  #ifdef CONFIG_TARGET_J721E_A72_EVM

@@ -585,4 +608,13 @@
};
};
  };
+
+#include "k3-binman-capsule.dtsi"
+_name {
+   filename = "tispl.bin_unsigned";


Why use the _unsigned images here? HS devices cannot boot unsigned GP images,
but both GP and HS devices *can* boot the normal signed images (GP just strips
the signatures off). So no need to use the _unsigned images anymore (I'm
planning to just remove them at some point to prevent this confusion).

Andrew


+};
+_name {
+   filename = "u-boot.img_unsigned";
+};
+
  #endif

Re: [PATCH 01/13] ti:keys Add EFI signature list

[Andrew Davis]

On 4/9/24 2:26 PM, Heinrich Schuchardt wrote:

On 4/9/24 14:14, Andrew Davis wrote:

On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:

On 4/8/24 23:33, Jonathan Humphreys wrote:

EFI signature list using TI dummy keys.


Adding vendor public keys into the code base to lock down generated
binaries to the vendors unpublished private key does not match well with
the intent of the GNU public license.



The matching private keys are already published in this same
repo/directory (arch/arm/mach-k3/keys).

Andrew


Why should we create signed capsules which are already compromised by
publishing the private key?



If you buy these devices you have two options, you can burn real
keys, or you can burn these dummy keys. If you burn dummy keys
then these images will boot and so will any image you or anyone
else wants to boot on the device. (since the keys are published
anyone can make images for them, that is how we do GP (general
purpose) devices these days)

If you burn your own keys, then you switch out these keys here
and your device will only boot images that you permit by signing
with your keys.

You'll find plenty of open source projects do the same and
give out example keys to show how to use real keys, even
official GNU projects.

https://github.com/gpg/gnupg/tree/master/tests/openpgp/samplekeys

Andrew


Best regards

Heinrich




Best regards

Heinrich



Signed-off-by: Jonathan Humphreys 
---
  arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
  1 file changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-k3/keys/custMpk.esl

diff --git a/arch/arm/mach-k3/keys/custMpk.esl
b/arch/arm/mach-k3/keys/custMpk.esl
new file mode 100644
index
..2feb704e0a5fd126410de451d3c0fa4d3edccc52
GIT binary patch
literal 1523
zcmZ1^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
z&78AJODc2mtxpELY@Awc9)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
zQpnB26;PC)oLXF*UsMbeWai-t@l*_blshP#N9QH-w`BJNO+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)+#e3fJowDZO)JR83lIcbw(hMu}}Y
z2ZZwYAI-LVx@^G;HdkgxaX_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
z{LIBUzm_CMw_SIFfPdcT#zmg6g{#b(Lp`M3Uj
zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
z8dh8T-~Dmrp2?yk3O6Gqbz7O@W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
zKlQ}fzw*izXI|}|r!O*nb#VhHRn;B`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~+5t
z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
z_N{pmM}uCi3UWO3=hMciTPl?N16Xv@buq_d@TU`uX0_s{?
zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
z>fTMIw2!Me3{Dw*WZotC<4@h

Re: [PATCH 01/13] ti:keys Add EFI signature list

[Andrew Davis]

On 4/8/24 10:34 PM, Heinrich Schuchardt wrote:

On 4/8/24 23:33, Jonathan Humphreys wrote:

EFI signature list using TI dummy keys.


Adding vendor public keys into the code base to lock down generated
binaries to the vendors unpublished private key does not match well with
the intent of the GNU public license.



The matching private keys are already published in this same
repo/directory (arch/arm/mach-k3/keys).

Andrew


Best regards

Heinrich



Signed-off-by: Jonathan Humphreys 
---
  arch/arm/mach-k3/keys/custMpk.esl | Bin 0 -> 1523 bytes
  1 file changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-k3/keys/custMpk.esl

diff --git a/arch/arm/mach-k3/keys/custMpk.esl 
b/arch/arm/mach-k3/keys/custMpk.esl
new file mode 100644
index 
..2feb704e0a5fd126410de451d3c0fa4d3edccc52
GIT binary patch
literal 1523
zcmZ1^?2Da*aux2_hA(f&~MnUw(yu0v@E4?-F=u^u*PVqVQ8QZ((-^A*$m*Kg7c
z&78AJODc2mtxpELY@Awc9)w85y}*84Mcd8gd(OvN4CUun9AT2E#ZUJWL@GhWtR)
zKpA!(HkZVloWx>7bput902hy3NNPo5v4Uq_aY<2WZfaf$h@G5YRFGekSdyAzC~P1I
zQpnB26;PC)oLXF*UsMbeWai-t@l*_blshP#N9QH-w`BJNO+QS$x7=il`0?bc6sZ`Vxxl^6N{>i2E;SY*4-T$+0G;)5dxe+2CR
z@4+)sDPWdQb@%6KTpDVdm)v}?GSpG(w_UV)+#e3fJowDZO)JR83lIcbw(hMu}}Y
z2ZZwYAI-LVx@^G;HdkgxaX_l3&{H|3l7uX@Vl5di{>fQQ{pDynFlySp2(z~g)
z{LIBUzm_CMw_SIFfPdcT#zmg6g{#b(Lp`M3Uj
zGOKycyEe+n{G(Rmg}jB!)0ySk-!kkj_R7#OT+}pcG0VXh?f+ftRvnyw#hUea^Iyfn
ze|zgKPKrqe@jYWU?v<50X(n^lZ*G%j$JyCh`*Px|H*K=2WXP)hx>jng+}Q}N^KoDN
z8dh8T-~Dmrp2?yk3O6Gqbz7O@W=dcRVPvS;*B%(4`P|iK>Vg$XDgN9sr}Df{
z7X0es=RPHr8RB+*)}q}h%gn?x9PO4y*Qog};x<t%rn8xi;KBE9A!Dppb9yru|>RCb9PcXWpE>
zKlQ}fzw*izXI|}|r!O*nb#VhHRn;B`1LC^xvIctvLCYhRA_6yCS~2&!0SH1xwv(O~+5t
z^|E$S{MM^8j9J5`sQ6pud{2Lz?k`zncbjvHj%eutjusUol}8;%cbPLCO|e;ZJ^tXe
z_N{pmM}uCi3UWO3=hMciTPl?N16Xv@buq_d@TU`uX0_s{?
zt`1&)Tk-yb?sKMPI~!}xt*d*!tMat!r1`}jul#i@lDB8rnu>ba_-^4!iQ5{|tb3TX
z>fTMIw2!Me3{Dw*WZotC<4@h

Re: [RFC PATCH 13/15] arm: dts: Introduce J722S U-Boot dts files

[Andrew Davis]

On 4/5/24 2:18 AM, Jayesh Choudhary wrote:

Hi,

On 04/04/24 20:59, Andrew Davis wrote:

On 4/4/24 4:00 AM, Jayesh Choudhary wrote:

Include the uboot device tree files needed to boot the board.

Co-developed-by: Vaishnav Achath 
Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
  arch/arm/dts/Makefile  |    2 +
  arch/arm/dts/k3-j722s-binman.dtsi  |  171 ++
  arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi | 2795 
  arch/arm/dts/k3-j722s-evm-u-boot.dtsi  |   36 +
  arch/arm/dts/k3-j722s-r5-evm.dts   |   82 +
  5 files changed, 3086 insertions(+)
  create mode 100644 arch/arm/dts/k3-j722s-binman.dtsi
  create mode 100644 arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi
  create mode 100644 arch/arm/dts/k3-j722s-evm-u-boot.dtsi
  create mode 100644 arch/arm/dts/k3-j722s-r5-evm.dts



[...]


diff --git a/arch/arm/dts/k3-j722s-evm-u-boot.dtsi 
b/arch/arm/dts/k3-j722s-evm-u-boot.dtsi
new file mode 100644
index 00..056ef08455
--- /dev/null
+++ b/arch/arm/dts/k3-j722s-evm-u-boot.dtsi
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Common J722S EVM dts file for SPLs
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-j722s-binman.dtsi"
+
+/ {
+    chosen {
+    stdout-path = "serial2:115200n8";
+    tick-timer = _timer0;
+    };
+};
+
+_pktdma {
+    reg = <0x00 0x485c 0x00 0x000100>,
+  <0x00 0x4a80 0x00 0x02>,
+  <0x00 0x4aa0 0x00 0x04>,
+  <0x00 0x4b80 0x00 0x40>,
+  <0x00 0x485e 0x00 0x02>,
+  <0x00 0x484a 0x00 0x004000>,
+  <0x00 0x484c 0x00 0x002000>,
+  <0x00 0x4843 0x00 0x004000>;
+    reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+    "cfg", "tchan", "rchan", "rflow";


Is this needed? Do we still not have the correct regs in
upstream kernel?


I missed this change when I was going through j722s dts changes.

u-boot dts currently does not have this fixed.
Tag v6.9-rc1-dts from devicetree-rebasing would have this fix.

Will keep this in mind.

Also from TRM memory map, the range is off for 'tchanrt'
Will send a fix patch for that after checking for all platforms
to linux upstream if required.




+};
+
+ {
+    bootph-pre-ram;
+
+    k3_sysreset: sysreset-controller {
+    compatible = "ti,sci-sysreset";
+    bootph-pre-ram;


This node won't be needed soon either[0]. Should mean an
almost empty -u-boot.dtsi file, which should be the goal.



Okay. I will remove the node.

Should I mark [0] as dependency or is it okay without it.
Impact would only be on U-Boot RESET I think. Base support
would still be functional.



That is correct, if this goes in before [0] without this node
the only thing that wouldn't work is reset, and it would start
working again when [0] goes in. So no real dependency.

Andrew


Thanks,
Jayesh


Andrew

[0] https://lore.kernel.org/all/20240402160908.508974-1-...@ti.com/


+    };


[...]

Re: [PATCH 1/1] net: nfs: fix file handle length in NFSv3

[Andrew Davis]

On 3/26/24 4:34 AM, Sébastien Szymanski wrote:

The NFS protocol uses file handles to refer to file or directory.
In NFSv2 file handles have a fixed size of 32 bytes.
In NFSv3 file handles have a variable length up to 64 bytes. This is
also true for the MOUNT protocol. [1]
When the NFSv3 server replies with a file handle length > 32 bytes, U-Boot
only copies 32 bytes of that file handle and the next LOOKUP Call fails:

BIOS> nfs ${loadaddr} 192.168.1.51:/nfsroot/opos93dev-br/boot/Image
Using ethernet@428a device
File transfer via NFS from server 192.168.1.51; our IP address is 192.168.1.133
Filename '/nfsroot/opos93dev-br/boot/Image'.
Load address: 0x8040
Loading: *** ERROR: File lookup fail

done
BIOS>

Looking at this transfer in Wireshark, we can see that the server
replies with the following file handle:

 length: 36
 [hash (CRC-32): 0x230ac67b]
 FileHandle: 
0100070101005e0091763911f87c449fa73c298552db19ba0c9f60002980cfd2

and U-Boot sends the following file handle in the next LOOKUP Call:

 length: 32
 [hash (CRC-32): 0x6314131b]
 FileHandle: 
00240100070101005e0091763911f87c449fa73c298552db19ba

Fix this by using a variable length file handle for dirfh.

[1] https://www.rfc-editor.org/rfc/rfc1813.html#page-106

Fixes: b0baca982048 ("net: NFS: Add NFSv3 support")
Signed-off-by: Sébastien Szymanski 
---


Fixes NFS boot for me, thanks!

Tested-by: Andrew Davis 


  net/nfs.c | 18 +-
  1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/net/nfs.c b/net/nfs.c
index 7a8887ef2368..c18282448ccd 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -57,7 +57,8 @@ static int nfs_offset = -1;
  static int nfs_len;
  static const ulong nfs_timeout = CONFIG_NFS_TIMEOUT;
  
-static char dirfh[NFS_FHSIZE];	/* NFSv2 / NFSv3 file handle of directory */

+static char dirfh[NFS3_FHSIZE]; /* NFSv2 / NFSv3 file handle of directory */
+static unsigned int dirfh3_length; /* (variable) length of dirfh when NFSv3 */
  static char filefh[NFS3_FHSIZE]; /* NFSv2 / NFSv3 file handle */
  static unsigned int filefh3_length;   /* (variable) length of filefh when 
NFSv3 */
  
@@ -377,9 +378,9 @@ static void nfs_lookup_req(char *fname)
  
  		rpc_req(PROG_NFS, NFS_LOOKUP, data, len);

} else {  /* NFS_V3 */
-   *p++ = htonl(NFS_FHSIZE);   /* Dir handle length */
-   memcpy(p, dirfh, NFS_FHSIZE);
-   p += (NFS_FHSIZE / 4);
+   *p++ = htonl(dirfh3_length);/* Dir handle length */
+   memcpy(p, dirfh, dirfh3_length);
+   p += (dirfh3_length / 4);
*p++ = htonl(fnamelen);
if (fnamelen & 3)
*(p + fnamelen / 4) = 0;
@@ -565,7 +566,14 @@ static int nfs_mount_reply(uchar *pkt, unsigned len)
  
  	fs_mounted = 1;

/*  NFSv2 and NFSv3 use same structure */
-   memcpy(dirfh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
+   if (choosen_nfs_version != NFS_V3) {
+   memcpy(dirfh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
+   } else {
+   dirfh3_length = ntohl(rpc_pkt.u.reply.data[1]);
+   if (dirfh3_length > NFS3_FHSIZE)
+   dirfh3_length  = NFS3_FHSIZE;
+   memcpy(dirfh, rpc_pkt.u.reply.data + 2, dirfh3_length);
+   }
  
  	return 0;

  }

Re: [RFC PATCH 15/15] doc: board: ti: Add J722S-EVM documentation

[Andrew Davis]

On 4/4/24 4:00 AM, Jayesh Choudhary wrote:

Introduce basic documentation for the J722S-EVM.

Signed-off-by: Jayesh Choudhary 
---
  doc/board/ti/j722s_evm.rst | 262 +
  doc/board/ti/k3.rst|   1 +
  2 files changed, 263 insertions(+)
  create mode 100644 doc/board/ti/j722s_evm.rst

diff --git a/doc/board/ti/j722s_evm.rst b/doc/board/ti/j722s_evm.rst
new file mode 100644
index 00..150330f637
--- /dev/null
+++ b/doc/board/ti/j722s_evm.rst
@@ -0,0 +1,262 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Jayesh Choudhary 
+
+J722S-EVM Platform
+==
+
+The J722S is a family of  application processors built for Automotive and
+Linux Application development. J722S family of SoCs is a superset of the
+AM62P SoC family and shares similar memory map, thus the nodes are being
+reused from AM62P includes instead of duplicating the definitions.
+
+Some highlights of J722S SoC (in addition to AM62P SoC features) are:
+
+* Two Cortex-R5F for Functional Safety or general-purpose usage and
+  two C7x floating point vector DSP with Matrix Multiply Accelerator
+  for deep learning.
+
+* Vision Processing Accelerator (VPAC) with image signal processor
+  and Depth and Motion Processing Accelerator (DMPAC).
+
+* 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
+  NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
+  4xCSI-RX for Camera, 1 PCIe Gen3 controller, USB3.0 eCAP/eQEP,
+  ePWM, among other peripherals.
+
+For those interested, more details about this SoC can be found in the
+Technical Reference Manual here: https://www.ti.com/lit/zip/sprujb3
+
+Boot Flow:
+--
+
+The bootflow is exactly the same as all SoCs in the am62xxx extended SoC
+family. Below is the pictorial representation:
+
+.. image:: img/boot_diagram_k3_current.svg
+  :alt: Boot flow diagram
+
+- Here TIFS acts as master and provides all the critical services. R5/A53
+  requests TIFS to get these services done as shown in the above diagram.
+
+Sources:
+
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_boot_sources
+:end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure:
+
+
+0. Setup the environment variables:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_desc
+:end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_board_env_vars_desc
+:end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_defn
+:end-before: .. k3_rst_include_end_common_env_vars_defn
+
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR=j722s_evm_r5_defconfig
+ $ export UBOOT_CFG_CORTEXA=j722s_evm_a53_defconfig
+ $ export TFA_BOARD=lite
+ $ # we dont use any extra TFA parameters
+ $ unset TFA_EXTRA_ARGS


Why unset, who is setting in the first place?


+ $ export OPTEE_PLATFORM=k3-am62x


None of the addresses OPTEE cares about changed from AM62?


+ $ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"


Do you still need this, the HW RNG should work now.

Andrew


+
+.. j722s_evm_rst_include_start_build_steps
+
+1. Trusted Firmware-A:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_tfa
+:end-before: .. k3_rst_include_end_build_steps_tfa
+
+
+2. OP-TEE:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_optee
+:end-before: .. k3_rst_include_end_build_steps_optee
+
+3. U-Boot:
+
+* 3.1 R5:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_spl_r5
+:end-before: .. k3_rst_include_end_build_steps_spl_r5
+
+* 3.2 A53:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_uboot
+:end-before: .. k3_rst_include_end_build_steps_uboot
+.. j722s_evm_rst_include_end_build_steps
+
+Target Images
+--
+
+In order to boot we need tiboot3.bin, tispl.bin and u-boot.img.  Each SoC
+variant (HS-FS, HS-SE) requires a different source for these files.
+
+ - HS-FS
+
+* tiboot3-j722s-hs-fs-evm.bin from step 3.1
+* tispl.bin, u-boot.img from step 3.2
+
+ - HS-SE
+
+* tiboot3-j722s-hs-evm.bin from step 3.1
+* tispl.bin, u-boot.img from step 3.2
+
+Image formats:
+--
+
+- tiboot3.bin
+
+.. image:: img/multi_cert_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
+
+- tispl.bin
+
+.. image:: img/dm_tispl.bin.svg
+  :alt: tispl.bin image format
+
+A53 SPL DDR Memory Layout
+-
+
+.. j722s_evm_rst_include_start_ddr_mem_layout
+
+This provides an overview memory usage in A53 SPL stage.
+
+.. list-table::
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - Region
+ - Start Address
+ - End Address
+
+  

Re: [RFC PATCH 13/15] arm: dts: Introduce J722S U-Boot dts files

[Andrew Davis]

On 4/4/24 4:00 AM, Jayesh Choudhary wrote:

Include the uboot device tree files needed to boot the board.

Co-developed-by: Vaishnav Achath 
Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
  arch/arm/dts/Makefile  |2 +
  arch/arm/dts/k3-j722s-binman.dtsi  |  171 ++
  arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi | 2795 
  arch/arm/dts/k3-j722s-evm-u-boot.dtsi  |   36 +
  arch/arm/dts/k3-j722s-r5-evm.dts   |   82 +
  5 files changed, 3086 insertions(+)
  create mode 100644 arch/arm/dts/k3-j722s-binman.dtsi
  create mode 100644 arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi
  create mode 100644 arch/arm/dts/k3-j722s-evm-u-boot.dtsi
  create mode 100644 arch/arm/dts/k3-j722s-r5-evm.dts



[...]


diff --git a/arch/arm/dts/k3-j722s-evm-u-boot.dtsi 
b/arch/arm/dts/k3-j722s-evm-u-boot.dtsi
new file mode 100644
index 00..056ef08455
--- /dev/null
+++ b/arch/arm/dts/k3-j722s-evm-u-boot.dtsi
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Common J722S EVM dts file for SPLs
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-j722s-binman.dtsi"
+
+/ {
+   chosen {
+   stdout-path = "serial2:115200n8";
+   tick-timer = _timer0;
+   };
+};
+
+_pktdma {
+   reg = <0x00 0x485c 0x00 0x000100>,
+ <0x00 0x4a80 0x00 0x02>,
+ <0x00 0x4aa0 0x00 0x04>,
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x02>,
+ <0x00 0x484a 0x00 0x004000>,
+ <0x00 0x484c 0x00 0x002000>,
+ <0x00 0x4843 0x00 0x004000>;
+   reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+   "cfg", "tchan", "rchan", "rflow";


Is this needed? Do we still not have the correct regs in
upstream kernel?


+};
+
+ {
+   bootph-pre-ram;
+
+   k3_sysreset: sysreset-controller {
+   compatible = "ti,sci-sysreset";
+   bootph-pre-ram;


This node won't be needed soon either[0]. Should mean an
almost empty -u-boot.dtsi file, which should be the goal.

Andrew

[0] https://lore.kernel.org/all/20240402160908.508974-1-...@ti.com/


+   };
+};
diff --git a/arch/arm/dts/k3-j722s-r5-evm.dts b/arch/arm/dts/k3-j722s-r5-evm.dts
new file mode 100644
index 00..aff83cd5d9
--- /dev/null
+++ b/arch/arm/dts/k3-j722s-r5-evm.dts
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * J722S EVM dts file for R5 SPL
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-j722s-evm.dts"
+#include "k3-j722s-evm-u-boot.dtsi"
+
+#include "k3-j722s-ddr-lp4-50-3733.dtsi"
+#include "k3-am62a-ddr.dtsi"
+
+/ {
+   aliases {
+   remoteproc0 = 
+   remoteproc1 = _0;
+   serial0 = _uart0;
+   serial2 = _uart0;
+   };
+
+   a53_0: a53@0 {
+   compatible = "ti,am654-rproc";
+   reg = <0x00 0x00a9 0x00 0x10>;
+   power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
+   <_pds 135 TI_SCI_PD_EXCLUSIVE>,
+   <_pds 166 TI_SCI_PD_EXCLUSIVE>;
+   resets = <_reset 135 0>;
+   clocks = <_clks 61 0>;
+   assigned-clocks = <_clks 61 0>, <_clks 135 0>;
+   assigned-clock-parents = <_clks 61 2>;
+   assigned-clock-rates = <2>, <12>;
+   ti,sci = <>;
+   ti,sci-proc-id = <32>;
+   ti,sci-host-id = <10>;
+   bootph-all;
+   };
+
+   dm_tifs: dm-tifs {
+   compatible = "ti,j721e-dm-sci";
+   ti,host-id = <36>;
+   ti,secure-host;
+   mbox-names = "rx", "tx";
+   mboxes= <_proxy_main 22>,
+   <_proxy_main 23>;
+   bootph-all;
+   };
+};
+
+ {
+   mboxes= <_proxy_main 0>,
+   <_proxy_main 1>,
+   <_proxy_main 0>;
+   mbox-names = "rx", "tx", "notify";
+   ti,host-id = <35>;
+   ti,secure-host;
+};
+
+_main {
+   sa3_secproxy: secproxy@4488 {
+   compatible = "ti,am654-secure-proxy";
+   #mbox-cells = <1>;
+   reg = <0x00 0x4488 0x00 0x2>,
+ <0x00 0x4486 0x00 0x2>,
+ <0x00 0x4360 0x00 0x1>;
+   reg-names = "rt", "scfg", "target_data";
+   bootph-all;
+   };
+
+   sysctrler: sysctrler {
+   compatible = "ti,am654-system-controller";
+   mboxes= <_proxy_main 1>,
+   <_proxy_main 0>,
+   <_secproxy 0>;
+   mbox-names = "tx", "rx", "boot_notify";
+   bootph-all;
+   };
+};
+
+/* WKUP UART0 is used for DM firmware logs */
+_uart0 {
+   status = "okay";
+};

Re: [PATCH 2/2] arm: dts: k3: Remove unneeded ti, sci-sysreset binding and nodes

[Andrew Davis]

On 4/3/24 1:37 AM, Neha Malcom Francis wrote:

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?



Good idea, and the same could probably be said for most TI-SCI based drivers.

We might also look into adding more of these as "imply" under config ARCH_K3,
all K3 boards will want/need these. Should help simplify our defconfig.

Andrew

[PATCH 1/2] firmware: ti_sci: Bind sysreset driver when enabled

[Andrew Davis]

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,
-- 
2.39.2

[PATCH 2/2] arm: dts: k3: Remove unneeded ti, sci-sysreset binding and nodes

[Andrew Davis]

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

diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi 
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index cca0f44b7d8..fb2032068d1 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -41,13 +41,6 @@
clock-frequency = <2500>;
 };
 
- {
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-all;
-   };
-};
-
 _pins_default {
/* Force to use SDCD card detect pin */
pinctrl-single,pins = <
diff --git a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi 
b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
index f6138f3058f..94162282068 100644
--- a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
@@ -42,13 +42,6 @@
bootph-all;
 };
 
- {
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-all;
-   };
-};
-
  {
bootph-all;
 };
diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi 
b/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi
index 28b697b67ae..7fe7ae41543 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-u-boot.dtsi
@@ -85,13 +85,6 @@
bootph-all;
 };
 
- {
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-all;
-   };
-};
-
  {
bootph-all;
 };
diff --git a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
index 31b89b41748..c42dec16194 100644
--- a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
@@ -119,10 +119,6 @@
 
  {
bootph-all;
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-all;
-   };
 };
 
 _mmc1 {
diff --git a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi
index c166d655390..cf087c6e343 100644
--- a/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am62p5-sk-u-boot.dtsi
@@ -15,9 +15,4 @@
 
  {
bootph-pre-ram;
-
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-pre-ram;
-   };
 };
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi 
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index ee6656774d6..705b3baa81c 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -23,13 +23,6 @@
bootph-all;
 };
 
- {
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-all;
-   };
-};
-
  {
bootph-all;
 };
diff --git a/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi 
b/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
index 5dfc40a843b..4677c35e2d9 100644
--- a/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
@@ -29,10 +29,6 @@
 
  {
bootph-all;
-   k3_sysreset: sysreset-controller {
-   compatible = "ti,sci-sysreset";
-   bootph-all;
-   };
 };
 
  {
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 7e6b2981346..6fcb11bd04d 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -15,13 +15,6 @@
clock-frequency = <2>;
 };
 
- {
-  

[PATCH 0/2] Remove ti,sci-sysreset

[Andrew Davis]

Hello all,

Idea here is to remove one more delta between the U-Boot and Linux
DTB files: ti,sci-sysreset. We currently have to add this to every
board's -u-boot.dtsi file as this is not a standard node. Instead do
what we are moving the kernel towards[0] and remove this node.

Thanks,
Andrew

[0] https://lore.kernel.org/lkml/20240326223730.54639-1-...@ti.com/

Andrew Davis (2):
  firmware: ti_sci: Bind sysreset driver when enabled
  arm: dts: k3: Remove unneeded ti,sci-sysreset binding and nodes

 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 ---
 drivers/firmware/ti_sci.c |  7 +
 drivers/sysreset/sysreset-ti-sci.c|  6 
 20 files changed, 7 insertions(+), 125 deletions(-)
 delete mode 100644 doc/device-tree-bindings/sysreset/ti,sci-sysreset.txt

-- 
2.39.2

Re: [PATCH] am625x_evm_a53: Tweak boot command to set fdt

[Andrew Davis]

On 3/26/24 9:26 AM, Martyn Welch wrote:

With the current config for tha SK-AM62, fdtfile isn't set in the U-Boot
environment. When using bootflow to boot from a block device, where the
extlinux.conf file specifies `fdtdir`, a fallback device tree is being
constructed from the `soc` (`k3`) and `board` (`am62x`) environment
variables, resulting in u-Boot trying to retrieve
`/dtbs/6.8.1+/k3-am62x.dtb`. This file doesn't exist.

The environment variables `default_device_tree` and
`default_device_tree_arch` are set in the config, the `findfdt` script
can be called to construct `fdtfile` from the environment variables set
by these config options, however this script currently isn't being run.



I think this patch will be unneeded after this series goes in:

https://lore.kernel.org/u-boot/20240109191506.3820908-1...@ti.com/

Andrew


Calling this script results in the correct device tree being retrieved:

Retrieving file: /dtbs/6.8.1+/ti/k3-am625-sk.dtb

Many boards are calling this script as part of their boot command. The
am62x currently isn't. Rectify this so that booting works correctly.

Signed-off-by: Martyn Welch 
---
  configs/am62x_evm_a53_defconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 78287ec18a..e373e44a93 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -30,7 +30,7 @@ CONFIG_SPL_LOAD_FIT=y
  CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
  CONFIG_BOOTSTD_FULL=y
  CONFIG_SYS_BOOTM_LEN=0x80
-CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; bootflow scan -lb"
  CONFIG_BOARD_LATE_INIT=y
  CONFIG_SPL_MAX_SIZE=0x58000
  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y

Re: [PATCH u-boot v2019.04-aspeed-openbmc] ARM: dts: aspeed: Add Ampere's BMC platform (AST2600)

[Andrew Jeffery]

Hi Chanh,

On Tue, 2024-03-19 at 14:21 +0700, Chanh Nguyen wrote:
> Add the initial version of the device tree for the Ampere BMC
> platform, which is equipped with the Aspeed AST2600 BMC SoC.
> 
> Signed-off-by: Chanh Nguyen 
> ---
>  arch/arm/dts/Makefile   |   1 +
>  arch/arm/dts/ast2600-ampere.dts | 113 
>  2 files changed, 114 insertions(+)
>  create mode 100644 arch/arm/dts/ast2600-ampere.dts
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 37675a3277..3642d59c89 100755
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -691,6 +691,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>   ast2600-greatlakes.dtb \
>   ast2600-intel.dtb \
>   ast2600-ncsi.dtb \
> + ast2600-ampere.dtb \
>   ast2600-p10bmc.dtb \
>   ast2600-pfr.dtb \
>   ast2600-qcom-dc-scm-v1.dtb \

Given this hunk and the tags in the `[PATCH]` prefix of the mail
subject you've based this change on OpenBMC's fork of u-boot, which is
heavily (out of date, and) inspired by Aspeed's SDK tree. I've applied
this to OpenBMC's fork for now.

However, you've sent this to the upstream list. You will need to rework
your patch on top of mainline u-boot if you want it accepted there, and
follow all the usual documentation on how to submit patches to the u-
boot project (e.g. you should not be including `u-boot v2019.04-aspeed-
openbmc` in the patch subject prefix in upstream submissions).

Andrew

Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries

[Andrew Davis]

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

Re: [PATCH] Makefile: Improve generated_defconfig file handling

[Andrew Davis]

On 3/7/24 9:38 PM, Sam Protsenko wrote:

Commit 2027e99e61aa ("Makefile: Run defconfig files through the C
preprocessor") adds `generated_defconfig' file, but fails to clean that
up. It might be useful to have that file around after `make' is done,
but it's better to clean that up on `make clean'. Also we probably want
to hide it in `git status' list. This patch makes the described changes,
and also adds `-P' parameter to the CPP command that produces the
`generated_defconfig' to avoid generating linemarkers.



All look like sensible improvements to me,

Acked-by: Andrew Davis 


Signed-off-by: Sam Protsenko 
Fixes: 2027e99e61aa ("Makefile: Run defconfig files through the C preprocessor")
---
  .gitignore   | 1 +
  Makefile | 1 +
  scripts/kconfig/Makefile | 2 +-
  3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 330148119264..d9a64d742fd7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -63,6 +63,7 @@ fit-dtb.blob*
  /spl/
  /tpl/
  /defconfig
+/generated_defconfig
  
  #

  # Generated include files
diff --git a/Makefile b/Makefile
index a2bc9d590329..6fd0e92c7d5a 100644
--- a/Makefile
+++ b/Makefile
@@ -2205,6 +2205,7 @@ clean: $(clean-dirs)
-o -name modules.builtin -o -name '.tmp_*.o.*' \
-o -name 'dsdt_generated.aml' -o -name 'dsdt_generated.asl.tmp' 
\
-o -name 'dsdt_generated.c' \
+   -o -name 'generated_defconfig' \
-o -name '*.efi' -o -name '*.gcno' -o -name '*.so' \) \
-type f -print | xargs rm -f
  
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile

index 5ce5845e8247..079add4d5dab 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -93,7 +93,7 @@ endif
  endif
  
  %_defconfig: $(obj)/conf

-   $(Q)$(CPP) -nostdinc -I $(srctree) -undef -x assembler-with-cpp 
$(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
+   $(Q)$(CPP) -nostdinc -P -I $(srctree) -undef -x assembler-with-cpp 
$(srctree)/arch/$(SRCARCH)/configs/$@ -o generated_defconfig
$(Q)$< $(silent) --defconfig=generated_defconfig $(Kconfig)
  
  # Added for U-Boot (backward compatibility)

Re: [PATCH 4/6] arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT

[Andrew Davis]

On 3/6/24 7:35 AM, Bryan Brattlof wrote:

On February 14, 2024 thus sayeth Andrew Davis:

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 


Acked-by: Bryan Brattlof 

Does this mean we need to no-map these regions in the MMU as well? Right
now it's just statically defined. I was looking into trying to read the
reserved-memory{} node to see if we could dynamically build the MMU
config but that would have to happen after this step right?



Good question. So TF-A/OP-TEE are loaded by R5 SPL, which means by
the time A53 SPL starts they are already in place and firewalled,
which means yes we should no-map them in MMU to prevent some
speculative fetch (A53 doesn't do that, but A72 on other K3 device
might) or similar from causing a firewall exception.

The fixup in this patch is done to the Linux DT file right before
it is handed off to Linux, which as you point out happens after
we setup the U-Boot MMU.

This is more a problem in theory, but not really one in practice.
I know, I don't like that answer either, but I can't think of a
better solution outside of doing this fixup in R5 SPL to the
U-Boot DTB also. (Which might work, but seems overkill)..

Andrew


~Bryan

Re: [PATCH 4/6] arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT

[Andrew Davis]

On 2/28/24 12:24 AM, Manorit Chawdhry wrote:

Hi Andrew,

On 10:30-20240214, 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.


Why are we doing it only for AM62? Assuming that this can help in other
devices as well as all the DTs ideally should have these reserved nodes
in DT?


Only AM62(a) have TF-A in DRAM, the rest of K3 put it in SRAM which
means it wont need to be moved currently. If we ever do move TF-A to
DRAM for other devices then they could make use of this helper function
just the same.

Andrew



Regards,
Manorit


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 */

--
2.39.2

Re: [PATCH 2/6] arm: mach-k3: Add config option for setting OP-TEE address

[Andrew Davis]

On 2/28/24 12:21 AM, Manorit Chawdhry wrote:

Hi Andrew,

On 10:30-20240214, Andrew Davis wrote:

Much like we have for ATF, OP-TEE has a standard address that we load
it too and run it from. Add a Kconfig item for this to remove some
hard-coding and allow this address to be more easily changed.

Signed-off-by: Andrew Davis 
---
  arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 4 ++--
  arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 4 ++--
  arch/arm/dts/k3-binman.dtsi  | 8 
  arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 4 ++--
  arch/arm/mach-k3/Kconfig | 7 +++
  5 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi 
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index a723caa5805..cca0f44b7d8 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -105,8 +105,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi 
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 64318d09cf0..3a6db91e132 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -51,8 +51,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
};
};
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 758c8bf6ea1..621653e9471 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -286,8 +286,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
ti-secure {
content = <>;
keyfile = "custMpk.pem";
@@ -356,8 +356,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
index 017a5a722e0..ca99fa0e690 100644
--- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
@@ -250,8 +250,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 0bd3f9fa12d..55bb874d9aa 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -129,6 +129,13 @@ config K3_ATF_LOAD_ADDR
  The load address for th

[PATCH v2] arm: dts: k3-am64: Move to OF_UPSTREAM

[Andrew Davis]

Enable OF_UPSTREAM for AM64-EVM and SK-AM64 boards. Remove DT files that
are now available in dts/upstream. Update the appended files based on
version of latest OF_UPSTREAM sync point (v6.7-rc7).

Signed-off-by: Andrew Davis 
---

Changes for v2:
 - Rebased on latest -next to fix merge conflict

As suggested here[0].

[0] https://lore.kernel.org/all/20240304170814.GP1523872@bill-the-cat/

 arch/arm/dts/Makefile |4 +-
 arch/arm/dts/k3-am64-main.dtsi| 1546 -
 arch/arm/dts/k3-am64-mcu.dtsi |  161 ---
 arch/arm/dts/k3-am64-thermal.dtsi |   33 -
 arch/arm/dts/k3-am64.dtsi |  100 --
 arch/arm/dts/k3-am642-evm-u-boot.dtsi |  110 --
 arch/arm/dts/k3-am642-evm.dts |  690 ---
 arch/arm/dts/k3-am642-r5-evm.dts  |   24 -
 arch/arm/dts/k3-am642-r5-sk.dts   |   12 -
 arch/arm/dts/k3-am642-sk-u-boot.dtsi  |   94 --
 arch/arm/dts/k3-am642-sk.dts  |  642 --
 arch/arm/dts/k3-am642.dtsi|   66 --
 arch/arm/dts/k3-am64x-binman.dtsi |6 +-
 configs/am64x_evm_a53_defconfig   |5 +-
 14 files changed, 7 insertions(+), 3486 deletions(-)
 delete mode 100644 arch/arm/dts/k3-am64-main.dtsi
 delete mode 100644 arch/arm/dts/k3-am64-mcu.dtsi
 delete mode 100644 arch/arm/dts/k3-am64-thermal.dtsi
 delete mode 100644 arch/arm/dts/k3-am64.dtsi
 delete mode 100644 arch/arm/dts/k3-am642-evm.dts
 delete mode 100644 arch/arm/dts/k3-am642-sk.dts
 delete mode 100644 arch/arm/dts/k3-am642.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 971a4065faf..b97ff3b07ea 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1417,9 +1417,7 @@ dtb-$(CONFIG_SOC_K3_J721S2) += k3-am68-sk-base-board.dtb\
 dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-r5-sk.dtb \
   k3-j784s4-r5-evm.dtb
 
-dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
- k3-am642-r5-evm.dtb \
- k3-am642-sk.dtb \
+dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-r5-evm.dtb \
  k3-am642-r5-sk.dtb
 
 dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
deleted file mode 100644
index 0df54a74182..000
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ /dev/null
@@ -1,1546 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Device Tree Source for AM642 SoC Family Main Domain peripherals
- *
- * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-#include 
-#include 
-
-/ {
-   serdes_refclk: clock-cmnrefclk {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <0>;
-   };
-};
-
-_main {
-   oc_sram: sram@7000 {
-   compatible = "mmio-sram";
-   reg = <0x00 0x7000 0x00 0x20>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x0 0x00 0x7000 0x20>;
-
-   tfa-sram@1c {
-   reg = <0x1c 0x2>;
-   };
-
-   dmsc-sram@1e {
-   reg = <0x1e 0x1c000>;
-   };
-
-   sproxy-sram@1fc000 {
-   reg = <0x1fc000 0x4000>;
-   };
-   };
-
-   main_conf: syscon@4300 {
-   compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
-   reg = <0x0 0x4300 0x0 0x2>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x0 0x0 0x4300 0x2>;
-
-   chipid@14 {
-   compatible = "ti,am654-chipid";
-   reg = <0x0014 0x4>;
-   };
-
-   serdes_ln_ctrl: mux-controller {
-   compatible = "mmio-mux";
-   #mux-control-cells = <1>;
-   mux-reg-masks = <0x4080 0x3>; /* SERDES0 lane0 select */
-   };
-
-   phy_gmii_sel: phy@4044 {
-   compatible = "ti,am654-phy-gmii-sel";
-   reg = <0x4044 0x8>;
-   #phy-cells = <1>;
-   };
-
-   epwm_tbclk: clock-controller@4140 {
-   compatible = "ti,am64-epwm-tbclk";
-   reg = <0x4130 0x4>;
-   #clock-cells = <1>;
-   };
-   };
-
-   gic500: interrupt-controller@180 {
-   compatible = "arm,gic-v3";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
-   #interrupt-cells = <3>

[PATCH] arm: dts: k3-am64: Move to OF_UPSTREAM

[Andrew Davis]

Enable OF_UPSTREAM for AM64-EVM and SK-AM64 boards. Remove DT files that
are now available in dts/upstream. Update the appended files based on
version of latest OF_UPSTREAM sync point (v6.7-rc7).

Signed-off-by: Andrew Davis 
---

As suggested here[0].

Based on Mar 4 -next.

[0] https://lore.kernel.org/all/20240304170814.GP1523872@bill-the-cat/

 arch/arm/dts/Makefile |4 +-
 arch/arm/dts/k3-am64-main.dtsi| 1546 -
 arch/arm/dts/k3-am64-mcu.dtsi |  161 ---
 arch/arm/dts/k3-am64-thermal.dtsi |   33 -
 arch/arm/dts/k3-am64.dtsi |  100 --
 arch/arm/dts/k3-am642-evm-u-boot.dtsi |  110 --
 arch/arm/dts/k3-am642-evm.dts |  690 ---
 arch/arm/dts/k3-am642-r5-evm.dts  |   24 -
 arch/arm/dts/k3-am642-r5-sk.dts   |   12 -
 arch/arm/dts/k3-am642-sk-u-boot.dtsi  |   94 --
 arch/arm/dts/k3-am642-sk.dts  |  642 --
 arch/arm/dts/k3-am642.dtsi|   66 --
 arch/arm/dts/k3-am64x-binman.dtsi |6 +-
 configs/am64x_evm_a53_defconfig   |5 +-
 14 files changed, 7 insertions(+), 3486 deletions(-)
 delete mode 100644 arch/arm/dts/k3-am64-main.dtsi
 delete mode 100644 arch/arm/dts/k3-am64-mcu.dtsi
 delete mode 100644 arch/arm/dts/k3-am64-thermal.dtsi
 delete mode 100644 arch/arm/dts/k3-am64.dtsi
 delete mode 100644 arch/arm/dts/k3-am642-evm.dts
 delete mode 100644 arch/arm/dts/k3-am642-sk.dts
 delete mode 100644 arch/arm/dts/k3-am642.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dc80b3bc6f0..3c9ab63b943 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1413,9 +1413,7 @@ dtb-$(CONFIG_SOC_K3_J721S2) += k3-am68-sk-base-board.dtb\
   k3-am68-sk-r5-base-board.dtb\
   k3-j721s2-common-proc-board.dtb\
   k3-j721s2-r5-common-proc-board.dtb
-dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
- k3-am642-r5-evm.dtb \
- k3-am642-sk.dtb \
+dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-r5-evm.dtb \
  k3-am642-r5-sk.dtb
 
 dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
deleted file mode 100644
index 0df54a74182..000
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ /dev/null
@@ -1,1546 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Device Tree Source for AM642 SoC Family Main Domain peripherals
- *
- * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
- */
-
-#include 
-#include 
-
-/ {
-   serdes_refclk: clock-cmnrefclk {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <0>;
-   };
-};
-
-_main {
-   oc_sram: sram@7000 {
-   compatible = "mmio-sram";
-   reg = <0x00 0x7000 0x00 0x20>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x0 0x00 0x7000 0x20>;
-
-   tfa-sram@1c {
-   reg = <0x1c 0x2>;
-   };
-
-   dmsc-sram@1e {
-   reg = <0x1e 0x1c000>;
-   };
-
-   sproxy-sram@1fc000 {
-   reg = <0x1fc000 0x4000>;
-   };
-   };
-
-   main_conf: syscon@4300 {
-   compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
-   reg = <0x0 0x4300 0x0 0x2>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x0 0x0 0x4300 0x2>;
-
-   chipid@14 {
-   compatible = "ti,am654-chipid";
-   reg = <0x0014 0x4>;
-   };
-
-   serdes_ln_ctrl: mux-controller {
-   compatible = "mmio-mux";
-   #mux-control-cells = <1>;
-   mux-reg-masks = <0x4080 0x3>; /* SERDES0 lane0 select */
-   };
-
-   phy_gmii_sel: phy@4044 {
-   compatible = "ti,am654-phy-gmii-sel";
-   reg = <0x4044 0x8>;
-   #phy-cells = <1>;
-   };
-
-   epwm_tbclk: clock-controller@4140 {
-   compatible = "ti,am64-epwm-tbclk";
-   reg = <0x4130 0x4>;
-   #clock-cells = <1>;
-   };
-   };
-
-   gic500: interrupt-controller@180 {
-   compatible = "arm,gic-v3";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
-   #i

Re: [PATCH v10 14/15] configs: am69_sk: Add defconfig for AM69 SK board

[Andrew Davis]

On 2/23/24 2:21 PM, Apurva Nandan wrote:

From: Dasnavis Sabiya 

Add defconfig for AM69 SK A72 and R5 configuration.

This inlcudes and modifies the J784S4 EVM defconfigs:
j784s4_evm_a72_defconfig -> am69_sk_a72_defconfig
j784s4_evm_r5_defconfig -> am69_sk_r5_defconfig

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---


Reviewed-by: Andrew Davis 


  board/ti/j784s4/MAINTAINERS   |  2 ++
  configs/am69_sk_a72_defconfig |  9 +
  configs/am69_sk_r5_defconfig  | 10 ++
  3 files changed, 21 insertions(+)
  create mode 100644 configs/am69_sk_a72_defconfig
  create mode 100644 configs/am69_sk_r5_defconfig

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 2b6bff2f5be..46f4ba5da96 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -16,3 +16,5 @@ M:Apurva Nandan 
  S:Maintained
  F:arch/arm/dts/k3-am69-sk-u-boot.dtsi
  F:arch/arm/dts/k3-am69-r5-sk.dts
+F: configs/am69_sk_r5_defconfig
+F: configs/am69_sk_a72_defconfig
diff --git a/configs/am69_sk_a72_defconfig b/configs/am69_sk_a72_defconfig
new file mode 100644
index 000..452de887258
--- /dev/null
+++ b/configs/am69_sk_a72_defconfig
@@ -0,0 +1,9 @@
+#include 
+
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SOC_K3_J784S4=y
+CONFIG_TARGET_J784S4_A72_EVM=y
+
+CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am69-sk"
+CONFIG_OF_LIST="ti/k3-am69-sk"
diff --git a/configs/am69_sk_r5_defconfig b/configs/am69_sk_r5_defconfig
new file mode 100644
index 000..2186b9a0490
--- /dev/null
+++ b/configs/am69_sk_r5_defconfig
@@ -0,0 +1,10 @@
+#include 
+
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SOC_K3_J784S4=y
+CONFIG_TARGET_J784S4_R5_EVM=y
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-r5-sk"
+CONFIG_SPL_OF_LIST="k3-am69-r5-sk"
+CONFIG_OF_LIST="k3-am69-r5-sk"

Re: [RFC PATCH 1/4] configs: j721e_sk: Move to separate defconfig for J721E SK board

[Andrew Davis]

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/


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"

Re: [PATCH v8 16/16] doc: board: ti: k3: Add J784S4 EVM and AM69 SK documentation

[Andrew Halaney]

On Fri, Jan 19, 2024 at 11:20:43PM +0530, Apurva Nandan wrote:
> TI K3 J784S4 and AM69 are new additions to the K3 SoC family.
> Add documentation about the J784S4 EVM and AM69 SK.
> 
> Signed-off-by: Dasnavis Sabiya 
> Signed-off-by: Apurva Nandan 
> ---
>  board/ti/j784s4/MAINTAINERS |   1 +
>  doc/board/ti/j784s4_evm.rst | 299 
>  doc/board/ti/k3.rst |   1 +
>  3 files changed, 301 insertions(+)
>  create mode 100644 doc/board/ti/j784s4_evm.rst
> 



> +
> +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
> + - SW9: 12345678
> + - SW8: 12345678

According to spruj62 I think SW9 and SW8 are supposed to be
SW7 and SW11 respectively?

> +
> +   * - SD
> + - 
> + - 1010
> +
> +   * - EMMC
> + - 0100
> + - 1000
> +
> +   * - OSPI
> + - 0100
> + - 0110
> +
> +   * - UART
> + - 0111
> + - 
> +
> +For SW8 and SW9, the switch state in the "ON" position = 1.

Referencing more from spruj62...

SW8 is a push button for a user defined interrupt for wake up (I think),
and SW9 is the main domain warm reset push button.

I'm not sure either of those are what you're trying to highlight here.

Love the TI documentation by the way, it is very nice.

Thanks,
Andrew

Re: [PATCH 6/6] arm: mach-k3: Move DRAM address of ATF for AM62/AM62a

[Andrew Davis]

On 2/15/24 2:06 AM, Francesco Dolcini wrote:

Hello Andrew,
thanks for this series.

On Wed, Feb 14, 2024 at 10:30:09AM -0600, Andrew Davis wrote:

The current address of TF-A in DRAM is just below the 512MB address line.
This means if the DRAM in a system is 512MB then TF-A is right at the
end of memory which is often reused, for instance U-Boot relocates itself
here. If a system has less than 512MB then that system wouldn't work at
all as TF-A would fail to load.


Do you expect issue with system with exactly 512MB of RAM? We have such
a board available and this is something that was not on our radar.


The issues with exactly 512MB are much less than the systems with less.
Mostly small software issues like the one you work around below with
U-Boot relocation.



The way we handle this is with `verdin-am62.c:board_get_usable_ram_top()`



The point of this patch is to avoid the need for workarounds like that in
the first place.


There is also some other reserved memory just before the 512MB limit,
not just the TF-A.


This series prepares for also moving OP-TEE at some point (which will be
a bit more involved as it still needs to be made position independent).
The other reserved memory is mostly for remoteproc firmware which should
be made dynamic instead of hard-coding memory carve-outs for their use.

Andrew



Francesco

[PATCH 5/6] arm: mach-k3: am62a: Fixup TF-A/OP-TEE reserved-memory node in FDT

[Andrew Davis]

The address we load TFA and OP-TEE to is configurable by
CONFIG_K3_{ATF,OPTEE}_LOAD_ADDR, but the DT nodes reserving this memory
are static. Fix that by updating this node when the loaded address
does not match the address in DT.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/Makefile   |  1 +
 arch/arm/mach-k3/am62a7_fdt.c   | 16 
 arch/arm/mach-k3/am62ax/Kconfig |  1 +
 3 files changed, 18 insertions(+)
 create mode 100644 arch/arm/mach-k3/am62a7_fdt.c

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 42161376469..fdb442773e3 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
 obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o
 obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
 obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
+obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_fdt.o
 endif
 ifeq ($(CONFIG_SPL_BUILD),y)
 obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
diff --git a/arch/arm/mach-k3/am62a7_fdt.c b/arch/arm/mach-k3/am62a7_fdt.c
new file mode 100644
index 000..d67f012a5dc
--- /dev/null
+++ b/arch/arm/mach-k3/am62a7_fdt.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include "common_fdt.h"
+#include 
+
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+   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/am62ax/Kconfig b/arch/arm/mach-k3/am62ax/Kconfig
index c5f1ef87126..bbd5497f2ae 100644
--- a/arch/arm/mach-k3/am62ax/Kconfig
+++ b/arch/arm/mach-k3/am62ax/Kconfig
@@ -13,6 +13,7 @@ config TARGET_AM62A7_A53_EVM
bool "TI K3 based AM62A7 EVM running on A53"
select ARM64
select BINMAN
+   select OF_SYSTEM_SETUP
imply BOARD
imply SPL_BOARD
imply TI_I2C_BOARD_DETECT
-- 
2.39.2

[PATCH 3/6] arm: mach-k3: am62: Enable OF_SYSTEM_SETUP for all boards

[Andrew Davis]

The fixups provided by ft_system_setup() are applicable for all AM62 based
boards. Select this at the target selection level for all AM62 boards and
remove it from any specific defconfig.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/am62x/Kconfig| 3 +++
 configs/verdin-am62_a53_defconfig | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/am62x/Kconfig b/arch/arm/mach-k3/am62x/Kconfig
index 935d596c879..7c9bac2ece8 100644
--- a/arch/arm/mach-k3/am62x/Kconfig
+++ b/arch/arm/mach-k3/am62x/Kconfig
@@ -13,6 +13,7 @@ config TARGET_AM625_A53_EVM
bool "TI K3 based AM625 EVM running on A53"
select ARM64
select BINMAN
+   select OF_SYSTEM_SETUP
 
 config TARGET_AM625_R5_EVM
bool "TI K3 based AM625 EVM running on R5"
@@ -29,6 +30,7 @@ config TARGET_PHYCORE_AM62X_A53
bool "PHYTEC phyCORE-AM62x running on A53"
select ARM64
select BINMAN
+   select OF_SYSTEM_SETUP
 
 config TARGET_PHYCORE_AM62X_R5
bool "PHYTEC phyCORE-AM62x running on R5"
@@ -45,6 +47,7 @@ config TARGET_VERDIN_AM62_A53
bool "Toradex Verdin AM62 running on A53"
select ARM64
select BINMAN
+   select OF_SYSTEM_SETUP
 
 config TARGET_VERDIN_AM62_R5
bool "Toradex Verdin AM62 running on R5"
diff --git a/configs/verdin-am62_a53_defconfig 
b/configs/verdin-am62_a53_defconfig
index 2003a530c7d..902c437d734 100644
--- a/configs/verdin-am62_a53_defconfig
+++ b/configs/verdin-am62_a53_defconfig
@@ -37,7 +37,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_SYS_BOOTM_LEN=0x4000
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_BOOTDELAY=1
-CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_USE_PREBOOT=y
 CONFIG_PREBOOT="test -n ${fdtfile} || setenv fdtfile 
k3-am625-verdin-${variant}-${fdt_board}.dtb"
 CONFIG_LOG=y
-- 
2.39.2

[PATCH 6/6] arm: mach-k3: Move DRAM address of ATF for AM62/AM62a

[Andrew Davis]

The current address of TF-A in DRAM is just below the 512MB address line.
This means if the DRAM in a system is 512MB then TF-A is right at the
end of memory which is often reused, for instance U-Boot relocates itself
here. If a system has less than 512MB then that system wouldn't work at
all as TF-A would fail to load.

To avoid the issues above, move TF-A to the start of DRAM, which doesn't
change from system to system.

As TF-A is position independent, this has no dependency on TF-A. We
also fixup DT as needed when TF-A address is moved, so this change also
has no dependency on Linux and is fully forward/backward compatible.

Signed-off-by: Andrew Davis 
---
 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 55bb874d9aa..33f20f61f83 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -123,7 +123,7 @@ 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 0x8000 if (SOC_K3_AM625 || SOC_K3_AM62A7)
default 0x7000
help
  The load address for the ATF image. This value is used to build the
-- 
2.39.2

[PATCH 1/6] arm: mach-k3: Add default ATF location for AM62/AM62a

[Andrew Davis]

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
-- 
2.39.2

[PATCH 0/6] Move DRAM address of ATF

[Andrew Davis]

Hello all,

Explanation for this series is mostly in [4/6]. First 3
patches should be safe to take independent of the last 3.

Thanks,
Andrew

Andrew Davis (6):
  arm: mach-k3: Add default ATF location for AM62/AM62a
  arm: mach-k3: Add config option for setting OP-TEE address
  arm: mach-k3: am62: Enable OF_SYSTEM_SETUP for all boards
  arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT
  arm: mach-k3: am62a: Fixup TF-A/OP-TEE reserved-memory node in FDT
  arm: mach-k3: Move DRAM address of ATF for AM62/AM62a

 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi  |  4 +-
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  |  4 +-
 arch/arm/dts/k3-binman.dtsi   |  8 +--
 .../dts/k3-j721e-beagleboneai64-u-boot.dtsi   |  4 +-
 arch/arm/mach-k3/Kconfig  | 10 +++-
 arch/arm/mach-k3/Makefile |  1 +
 arch/arm/mach-k3/am625_fdt.c  |  2 +
 arch/arm/mach-k3/am62a7_fdt.c | 16 ++
 arch/arm/mach-k3/am62ax/Kconfig   |  1 +
 arch/arm/mach-k3/am62x/Kconfig|  3 ++
 arch/arm/mach-k3/common_fdt.c | 52 +++
 arch/arm/mach-k3/common_fdt.h |  2 +
 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 |  2 -
 17 files changed, 96 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/mach-k3/am62a7_fdt.c

-- 
2.39.2

[PATCH 4/6] arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT

[Andrew Davis]

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 */
-- 
2.39.2

[PATCH 2/6] arm: mach-k3: Add config option for setting OP-TEE address

[Andrew Davis]

Much like we have for ATF, OP-TEE has a standard address that we load
it too and run it from. Add a Kconfig item for this to remove some
hard-coding and allow this address to be more easily changed.

Signed-off-by: Andrew Davis 
---
 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 4 ++--
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 4 ++--
 arch/arm/dts/k3-binman.dtsi  | 8 
 arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 4 ++--
 arch/arm/mach-k3/Kconfig | 7 +++
 5 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi 
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index a723caa5805..cca0f44b7d8 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -105,8 +105,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi 
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 64318d09cf0..3a6db91e132 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -51,8 +51,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
};
};
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 758c8bf6ea1..621653e9471 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -286,8 +286,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
ti-secure {
content = <>;
keyfile = "custMpk.pem";
@@ -356,8 +356,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
index 017a5a722e0..ca99fa0e690 100644
--- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
@@ -250,8 +250,8 @@
arch = "arm64";
compression = "none";
os = "tee";
-   load = <0x9e80>;
-   entry = <0x9e80>;
+   load = ;
+   entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 0bd3f9fa12d..55bb874d9aa 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -129,6 +129,13 @@ config K3_ATF_LOAD_ADDR
  The load address for the ATF image. This value is used to build the
  FIT image header that places ATF in memory where it w

Re: [PATCH 2/2] ti: keystone2: Move common Kconfig selections to under ARCH_KEYSTONE

[Andrew Davis]

On 7/25/23 12:41 PM, Tom Rini wrote:

On Tue, Jul 25, 2023 at 10:54:16AM -0500, Andrew Davis wrote:


These select/imply settings are common to the whole architecture not just
these boards, move these settings to the architecture config.

Signed-off-by: Andrew Davis 


Reviewed-by: Tom Rini 



ping

Re: [PATCH 02/10] arm: dts: k3-am68*: Sync with 6.8-rc1

[Andrew Davis]

On 2/6/24 6:21 AM, Manorit Chawdhry wrote:

Syncs the DT from Linux v6.8-rc1.

Remove udmap overrides and handle location change of chipid node.


Message doesn't match the patch. This patch should just be squashed
into the previous one anyway.

Andrew



Signed-off-by: Manorit Chawdhry 
---
  arch/arm/dts/k3-am68-sk-base-board.dts | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/k3-am68-sk-base-board.dts 
b/arch/arm/dts/k3-am68-sk-base-board.dts
index 1e1a82f9d2b8..d0cfdeac21fb 100644
--- a/arch/arm/dts/k3-am68-sk-base-board.dts
+++ b/arch/arm/dts/k3-am68-sk-base-board.dts
@@ -31,6 +31,7 @@
can1 = _mcan1;
can2 = _mcan6;
can3 = _mcan7;
+   ethernet0 = _port1;
};
  
  	vusb_main: regulator-vusb-main5v0 {

Re: [PATCH] arm: mach-k3: Refactor QoS settings

[Andrew Davis]

On 2/6/24 2:56 AM, Aradhya Bhatia wrote:

Refactor common QoS code into a new common header file, and the soc
specific setup_qos functions into a common API.

Rename $(soc)_qos_count and $(soc)_qos_data variables to qos_count and
qos_data. When QoS settings of more SoCs are added, only one pair will
be defined at a time, based on the config SOC_K3_$(soc).

This refactoring has been done for 2 major purposes.

- The auto-generated $(soc)_qos_data.c and $(soc)_qos.h files cannot
   have any code that is specific to any bootloader. Those files have to
   remain agnostic of different bootloader implementations and their
   header files.

- The existing implementation was less than ideal and would have enabled
   multiple $(soc)_qos_count and $(soc)_qos_data variables for all SoC
   variants.

Signed-off-by: Aradhya Bhatia 
---
  arch/arm/mach-k3/Kconfig  |  8 +++
  arch/arm/mach-k3/am62a7_init.c| 14 
  arch/arm/mach-k3/common.c | 12 ++
  arch/arm/mach-k3/common.h |  8 +++
  arch/arm/mach-k3/include/mach/hardware.h  |  9 
  arch/arm/mach-k3/include/mach/k3-qos.h| 22 +++
  arch/arm/mach-k3/r5/am62ax/Makefile   |  2 +-
  .../{include/mach => r5/am62ax}/am62a_qos.h   |  0
  .../{am62a_qos_data.c => am62a_qos_uboot.c}   |  9 
  9 files changed, 56 insertions(+), 28 deletions(-)
  create mode 100644 arch/arm/mach-k3/include/mach/k3-qos.h
  rename arch/arm/mach-k3/{include/mach => r5/am62ax}/am62a_qos.h (100%)
  rename arch/arm/mach-k3/r5/am62ax/{am62a_qos_data.c => am62a_qos_uboot.c} 
(85%)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 03898424c954..ffc4a9c29029 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -139,6 +139,14 @@ config K3_DM_FW
  bootloader, it makes RM and PM services not being available
  during R5 SPL execution time.
  
+config K3_QOS

+   bool "Enable Quality of Service (QoS) Settings for TI K3 SoCs"
+   default y if CPU_V7R && SOC_K3_AM62A7


If this is R5 only, then put it in the arch/arm/mach-k3/r5 Kconfig
and you can drop the CPU_V7R check.

Andrew


+   help
+ This option enables the R5 SPL to apply QoS settings for various
+ HW controllers inside the TI K3 SoCs. The files for QoS settings are
+ generated from Sysconfig and k3-resource-partitioning tools.
+
  config K3_X509_SWRV
int "SWRV for X509 certificate used for boot images"
default 1
diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
index d72e19936b9b..080274e3af58 100644
--- a/arch/arm/mach-k3/am62a7_init.c
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -69,20 +69,6 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(PADCFG_MMR1_BASE, 1);
  }
  
-#if (IS_ENABLED(CONFIG_CPU_V7R))

-static void setup_qos(void)
-{
-   u32 i;
-
-   for (i = 0; i < am62a_qos_count; i++)
-   writel(am62a_qos_data[i].val, (uintptr_t)am62a_qos_data[i].reg);
-}
-#else
-static void setup_qos(void)
-{
-}
-#endif
-
  void board_init_f(ulong dummy)
  {
struct udevice *dev;
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index f411366778f0..b54f2ddc4729 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -28,6 +28,8 @@
  #include 
  #include 
  
+#include 

+
  #if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF)
  enum {
IMAGE_ID_ATF,
@@ -595,3 +597,13 @@ int misc_init_r(void)
  void __weak do_board_detect(void)
  {
  }
+
+#if (IS_ENABLED(CONFIG_K3_QOS))
+void setup_qos(void)
+{
+   u32 i;
+
+   for (i = 0; i < qos_count; i++)
+   writel(qos_data[i].val, (uintptr_t)qos_data[i].reg);
+}
+#endif
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index e9db9fbfb63d..53aa186b31a4 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -45,3 +45,11 @@ void ti_secure_image_post_process(void **p_image, size_t 
*p_size);
  struct ti_sci_handle *get_ti_sci_handle(void);
  void do_board_detect(void);
  void ti_secure_image_check_binary(void **p_image, size_t *p_size);
+
+#if (IS_ENABLED(CONFIG_K3_QOS))
+void setup_qos(void);
+#else
+static inline void setup_qos(void)
+{
+}
+#endif
diff --git a/arch/arm/mach-k3/include/mach/hardware.h 
b/arch/arm/mach-k3/include/mach/hardware.h
index a1a9dfbde66c..52ef82e70b07 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -30,7 +30,6 @@
  
  #ifdef CONFIG_SOC_K3_AM62A7

  #include "am62a_hardware.h"
-#include "am62a_qos.h"
  #endif
  
  /* Assuming these addresses and definitions stay common across K3 devices */

@@ -97,12 +96,4 @@ struct rom_extended_boot_data {
u32 num_components;
  };
  
-struct k3_qos_data {

-   u32 reg;
-   u32 val;
-};
-
-extern struct k3_qos_data am62a_qos_data[];
-exter

Re: [PATCH v2 05/13] arm: mach-k3: invert logic for split DM firmware config

[Andrew Davis]

On 1/31/24 9:06 PM, 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.

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..0574e81075e6d 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 && ARCH_K3 && !SOC_K3_AM642 && !SOC_K3_AM654 && !CLK_TI_SCI 
&& !TI_SCI_POWER_DOMAIN


Always amusing to see how many SoCs get added to these lists before someone
realizes there is only one or two SoCs that are not on the list :)

BTW, this whole file is inside an "if ARCH_K3" block, so all symbols
depend on ARCH_K3 automatically. You can drop that check.

Otherwise,

Acked-by: Andrew Davis 


default y
help
  Enabling this will indicate that the system has separate DM

Re: [PATCH v2 10/13] arm: dts: introduce am62p5 uboot dts files

[Andrew Davis]

On 2/2/24 10:28 AM, Bryan Brattlof wrote:

Hi Andrew!

On February  2, 2024 thus sayeth Andrew Davis:

On 1/31/24 9:06 PM, Bryan Brattlof wrote:

Include the uboot device tree files needed to boot the board.

Signed-off-by: Bryan Brattlof 
---
   arch/arm/dts/Makefile  |2 +
   arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi | 2800 
   arch/arm/dts/k3-am62p-sk-binman.dtsi   |  173 ++
   arch/arm/dts/k3-am62p5-r5-sk.dts   |  101 +
   arch/arm/dts/k3-am62p5-sk-u-boot.dtsi  |   49 +
   arch/arm/mach-k3/Makefile  |1 +
   arch/arm/mach-k3/am62p5_init.c |4 +-
   dts/arch/arm64/ti  |1 +
   8 files changed, 3129 insertions(+), 2 deletions(-)
   create mode 100644 arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi
   create mode 100644 arch/arm/dts/k3-am62p-sk-binman.dtsi
   create mode 100644 arch/arm/dts/k3-am62p5-r5-sk.dts
   create mode 100644 arch/arm/dts/k3-am62p5-sk-u-boot.dtsi
   create mode 12 dts/arch/arm64/ti



...


diff --git a/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi
b/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi
new file mode 100644
index 0..f66435201530f
--- /dev/null
+++ b/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi
@@ -0,0 +1,2800 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This file was generated with the
+ * AM62Px SysConfig DDR Subsystem Register Configuration Tool v0.10.02
+ * Thu Jan 25 2024 10:43:46 GMT-0600 (Central Standard Time)
+ * DDR Type: LPDDR4
+ * F0 = 50MHzF1 = NA F2 = 1600MHz
+ * Density (per channel): 16Gb
+ * Number of Ranks: 2
+ */
+
+#define DDRSS_PLL_FHS_CNT 5
+#define DDRSS_PLL_FREQUENCY_1 8
+#define DDRSS_PLL_FREQUENCY_2 8
+#define DDRSS_SDRAM_IDX 17
+#define DDRSS_REGION_IDX 17
+
+#define DDRSS_CTL_0_DATA 0x0B00
+#define DDRSS_CTL_1_DATA 0x
+#define DDRSS_CTL_2_DATA 0x
+#define DDRSS_CTL_3_DATA 0x
+#define DDRSS_CTL_4_DATA 0x
+#define DDRSS_CTL_5_DATA 0x


I wonder if it would be better to generate this file
during build..



Yeah we can save a lot of space by removing tons of these registers
writing 0x0 to the reserved ranges... The section for the different PHYs
is particularly aggravating.



Might be a silly question, what happens if you don't write these 0x0
at all, is there a sane default of 0x0, or is it random on powerup?


I told Simon and Marex last year I'd get to it once I find some free
cycles and then I went and had a son ;) but it's still in the backlog



Know the feeling :)

Andrew




+_bcdma {
+   reg = <0x00 0x485c0100 0x00 0x100>,
+ <0x00 0x4c00 0x00 0x2>,
+ <0x00 0x4a82 0x00 0x2>,
+ <0x00 0x4aa4 0x00 0x2>,
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>;
+   reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
+   "ringrt", "cfg", "tchan", "rchan";
+};
+


Do we still need these? Thought they got fixed kernel side already.


Ah you're right I missed that i'll remove this in v2




+_pktdma {
+   reg = <0x00 0x485c 0x00 0x100>,
+ <0x00 0x4a80 0x00 0x2>,
+ <0x00 0x4aa0 0x00 0x4>,
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+   reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+   "cfg", "tchan", "rchan", "rflow";
+};
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 42161376469e2..820b313a83c23 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -20,5 +20,6 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o
   obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
   obj-$(CONFIG_SOC_K3_AM625) += am625_init.o
   obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o
+obj-$(CONFIG_SOC_K3_AM62P5) += am62p5_init.o
   endif
   obj-y += common.o security.o
diff --git a/arch/arm/mach-k3/am62p5_init.c b/arch/arm/mach-k3/am62p5_init.c
index 5b6795cc7d246..9ff877d5d26e8 100644
--- a/arch/arm/mach-k3/am62p5_init.c
+++ b/arch/arm/mach-k3/am62p5_init.c
@@ -110,7 +110,7 @@ void board_init_f(ulong dummy)
 * through a SYSFW PM-init step and will need a re-init in some way
 * due to changing module clock frequencies.
 */
-   if (IS_ENABLED(CONFIG_K3_EARLY_CONS))
+   if (IS_ENABLED(CONFIG_K3_EARLY_CONS)) {


Looks like fixes for a previous patch that didn't get squashed.



haha Oops good catch.. I'll fixup this properly


Thanks for the review Andrew
~Bryan

Re: [PATCH v2 10/13] arm: dts: introduce am62p5 uboot dts files

[Andrew Davis]

On 1/31/24 9:06 PM, Bryan Brattlof wrote:

Include the uboot device tree files needed to boot the board.

Signed-off-by: Bryan Brattlof 
---
  arch/arm/dts/Makefile  |2 +
  arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi | 2800 
  arch/arm/dts/k3-am62p-sk-binman.dtsi   |  173 ++
  arch/arm/dts/k3-am62p5-r5-sk.dts   |  101 +
  arch/arm/dts/k3-am62p5-sk-u-boot.dtsi  |   49 +
  arch/arm/mach-k3/Makefile  |1 +
  arch/arm/mach-k3/am62p5_init.c |4 +-
  dts/arch/arm64/ti  |1 +
  8 files changed, 3129 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi
  create mode 100644 arch/arm/dts/k3-am62p-sk-binman.dtsi
  create mode 100644 arch/arm/dts/k3-am62p5-r5-sk.dts
  create mode 100644 arch/arm/dts/k3-am62p5-sk-u-boot.dtsi
  create mode 12 dts/arch/arm64/ti

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 34ebf2b58417d..36de84287d4c2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1424,6 +1424,8 @@ dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
  dtb-$(CONFIG_SOC_K3_AM62A7) += k3-am62a7-sk.dtb \
  k3-am62a7-r5-sk.dtb
  
+dtb-$(CONFIG_SOC_K3_AM62P5) += k3-am62p5-r5-sk.dtb

+
  dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7622-rfb.dtb \
mt7623a-unielec-u7623-02-emmc.dtb \
diff --git a/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi 
b/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi
new file mode 100644
index 0..f66435201530f
--- /dev/null
+++ b/arch/arm/dts/k3-am62p-ddr-lp4-50-1600.dtsi
@@ -0,0 +1,2800 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This file was generated with the
+ * AM62Px SysConfig DDR Subsystem Register Configuration Tool v0.10.02
+ * Thu Jan 25 2024 10:43:46 GMT-0600 (Central Standard Time)
+ * DDR Type: LPDDR4
+ * F0 = 50MHzF1 = NA F2 = 1600MHz
+ * Density (per channel): 16Gb
+ * Number of Ranks: 2
+ */
+
+#define DDRSS_PLL_FHS_CNT 5
+#define DDRSS_PLL_FREQUENCY_1 8
+#define DDRSS_PLL_FREQUENCY_2 8
+#define DDRSS_SDRAM_IDX 17
+#define DDRSS_REGION_IDX 17
+
+#define DDRSS_CTL_0_DATA 0x0B00
+#define DDRSS_CTL_1_DATA 0x
+#define DDRSS_CTL_2_DATA 0x
+#define DDRSS_CTL_3_DATA 0x
+#define DDRSS_CTL_4_DATA 0x
+#define DDRSS_CTL_5_DATA 0x


I wonder if it would be better to generate this file
during build..

[...]


+_bcdma {
+   reg = <0x00 0x485c0100 0x00 0x100>,
+ <0x00 0x4c00 0x00 0x2>,
+ <0x00 0x4a82 0x00 0x2>,
+ <0x00 0x4aa4 0x00 0x2>,
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>;
+   reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
+   "ringrt", "cfg", "tchan", "rchan";
+};
+


Do we still need these? Thought they got fixed kernel side already.


+_pktdma {
+   reg = <0x00 0x485c 0x00 0x100>,
+ <0x00 0x4a80 0x00 0x2>,
+ <0x00 0x4aa0 0x00 0x4>,
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+   reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+   "cfg", "tchan", "rchan", "rflow";
+};
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 42161376469e2..820b313a83c23 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -20,5 +20,6 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o
  obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
  obj-$(CONFIG_SOC_K3_AM625) += am625_init.o
  obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o
+obj-$(CONFIG_SOC_K3_AM62P5) += am62p5_init.o
  endif
  obj-y += common.o security.o
diff --git a/arch/arm/mach-k3/am62p5_init.c b/arch/arm/mach-k3/am62p5_init.c
index 5b6795cc7d246..9ff877d5d26e8 100644
--- a/arch/arm/mach-k3/am62p5_init.c
+++ b/arch/arm/mach-k3/am62p5_init.c
@@ -110,7 +110,7 @@ void board_init_f(ulong dummy)
 * through a SYSFW PM-init step and will need a re-init in some way
 * due to changing module clock frequencies.
 */
-   if (IS_ENABLED(CONFIG_K3_EARLY_CONS))
+   if (IS_ENABLED(CONFIG_K3_EARLY_CONS)) {


Looks like fixes for a previous patch that didn't get squashed.

Andrew


ret = early_console_init();
if (ret)
panic("early_console_init() failed: %d\n", ret);
@@ -122,7 +122,7 @@ void 

[PATCH 3/6] arm: mach-k3: Move tispl.bin loading into R5 directory

[Andrew Davis]

ATF, OPTEE, DM (tispl.bin) loading is only ever done by the R5 core,
move the code into the R5 directory.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/common.c| 248 +-
 arch/arm/mach-k3/r5/common.c | 249 +++
 2 files changed, 252 insertions(+), 245 deletions(-)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 5d53efed85b..8db7ca0725e 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -28,27 +28,6 @@
 #include 
 #include 
 
-#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF)
-enum {
-   IMAGE_ID_ATF,
-   IMAGE_ID_OPTEE,
-   IMAGE_ID_SPL,
-   IMAGE_ID_DM_FW,
-   IMAGE_AMT,
-};
-
-#if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS)
-static const char *image_os_match[IMAGE_AMT] = {
-   "arm-trusted-firmware",
-   "tee",
-   "U-Boot",
-   "DM",
-};
-#endif
-
-static struct image_info fit_image_info[IMAGE_AMT];
-#endif
-
 struct ti_sci_handle *get_ti_sci_handle(void)
 {
struct udevice *dev;
@@ -128,233 +107,12 @@ int early_console_init(void)
 }
 #endif
 
-#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF)
-
-void init_env(void)
-{
-#ifdef CONFIG_SPL_ENV_SUPPORT
-   char *part;
-
-   env_init();
-   env_relocate();
-   switch (spl_boot_device()) {
-   case BOOT_DEVICE_MMC2:
-   part = env_get("bootpart");
-   env_set("storage_interface", "mmc");
-   env_set("fw_dev_part", part);
-   break;
-   case BOOT_DEVICE_SPI:
-   env_set("storage_interface", "ubi");
-   env_set("fw_ubi_mtdpart", "UBI");
-   env_set("fw_ubi_volume", "UBI0");
-   break;
-   default:
-   printf("%s from device %u not supported!\n",
-  __func__, spl_boot_device());
-   return;
-   }
-#endif
-}
-
-int load_firmware(char *name_fw, char *name_loadaddr, u32 *loadaddr)
-{
-   struct udevice *fsdev;
-   char *name = NULL;
-   int size = 0;
-
-   if (!IS_ENABLED(CONFIG_FS_LOADER))
-   return 0;
-
-   *loadaddr = 0;
-#ifdef CONFIG_SPL_ENV_SUPPORT
-   switch (spl_boot_device()) {
-   case BOOT_DEVICE_MMC2:
-   name = env_get(name_fw);
-   *loadaddr = env_get_hex(name_loadaddr, *loadaddr);
-   break;
-   default:
-   printf("Loading rproc fw image from device %u not supported!\n",
-  spl_boot_device());
-   return 0;
-   }
-#endif
-   if (!*loadaddr)
-   return 0;
-
-   if (!get_fs_loader()) {
-   size = request_firmware_into_buf(fsdev, name, (void *)*loadaddr,
-0, 0);
-   }
-
-   return size;
-}
-
-void release_resources_for_core_shutdown(void)
-{
-   struct ti_sci_handle *ti_sci = get_ti_sci_handle();
-   struct ti_sci_dev_ops *dev_ops = _sci->ops.dev_ops;
-   struct ti_sci_proc_ops *proc_ops = _sci->ops.proc_ops;
-   int ret;
-   u32 i;
-
-   /* Iterate through list of devices to put (shutdown) */
-   for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
-   u32 id = put_device_ids[i];
-
-   ret = dev_ops->put_device(ti_sci, id);
-   if (ret)
-   panic("Failed to put device %u (%d)\n", id, ret);
-   }
-
-   /* Iterate through list of cores to put (shutdown) */
-   for (i = 0; i < ARRAY_SIZE(put_core_ids); i++) {
-   u32 id = put_core_ids[i];
-
-   /*
-* Queue up the core shutdown request. Note that this call
-* needs to be followed up by an actual invocation of an WFE
-* or WFI CPU instruction.
-*/
-   ret = proc_ops->proc_shutdown_no_wait(ti_sci, id);
-   if (ret)
-   panic("Failed sending core %u shutdown message (%d)\n",
- id, ret);
-   }
-}
-
-void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
-{
-   typedef void __noreturn (*image_entry_noargs_t)(void);
-   struct ti_sci_handle *ti_sci = get_ti_sci_handle();
-   u32 loadaddr = 0;
-   int ret, size = 0, shut_cpu = 0;
-
-   /* Release all the exclusive devices held by SPL before starting ATF */
-   ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
-
-   ret = rproc_init();
-   if (ret)
-   panic("rproc failed to be initialized (%d)\n", ret);
-
-   init_env();
-
-   if (!fit_image_info[IMAGE_ID_DM_FW].image_start) {
-   size = load_firmware("name_mcur5f0_0fw", "addr_mcur5f0_0load",
-   

[PATCH 2/6] arm: mach-k3: Move disable_linefill_optimization() into R5 directory

[Andrew Davis]

The disable_linefill_optimization() function is only ever loaded by the
R5 core, move the code into the R5 directory.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/common.c| 25 -
 arch/arm/mach-k3/r5/Makefile |  1 +
 arch/arm/mach-k3/r5/common.c | 35 +++
 3 files changed, 36 insertions(+), 25 deletions(-)
 create mode 100644 arch/arm/mach-k3/r5/common.c

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index f411366778f..5d53efed85b 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -453,31 +453,6 @@ void board_prep_linux(struct bootm_headers *images)
 }
 #endif
 
-#ifdef CONFIG_CPU_V7R
-void disable_linefill_optimization(void)
-{
-   u32 actlr;
-
-   /*
-* On K3 devices there are 2 conditions where R5F can deadlock:
-* 1.When software is performing series of store operations to
-*   cacheable write back/write allocate memory region and later
-*   on software execute barrier operation (DSB or DMB). R5F may
-*   hang at the barrier instruction.
-* 2.When software is performing a mix of load and store operations
-*   within a tight loop and store operations are all writing to
-*   cacheable write back/write allocates memory regions, R5F may
-*   hang at one of the load instruction.
-*
-* To avoid the above two conditions disable linefill optimization
-* inside Cortex R5F.
-*/
-   asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
-   actlr |= (1 << 13); /* Set DLFO bit  */
-   asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
-}
-#endif
-
 static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
   enum k3_firewall_region_type fwl_type)
 {
diff --git a/arch/arm/mach-k3/r5/Makefile b/arch/arm/mach-k3/r5/Makefile
index b99199d3374..8ad86eb2798 100644
--- a/arch/arm/mach-k3/r5/Makefile
+++ b/arch/arm/mach-k3/r5/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
 obj-$(CONFIG_SOC_K3_AM625) += am62x/
 obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
 
+obj-y += common.o
 obj-y += lowlevel_init.o
 obj-y += r5_mpu.o
 
diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
new file mode 100644
index 000..ef81f50c6c7
--- /dev/null
+++ b/arch/arm/mach-k3/r5/common.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * K3: R5 Common Architecture initialization
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include 
+#include 
+
+#include "../common.h"
+
+void disable_linefill_optimization(void)
+{
+   u32 actlr;
+
+   /*
+* On K3 devices there are 2 conditions where R5F can deadlock:
+* 1.When software is performing series of store operations to
+*   cacheable write back/write allocate memory region and later
+*   on software execute barrier operation (DSB or DMB). R5F may
+*   hang at the barrier instruction.
+* 2.When software is performing a mix of load and store operations
+*   within a tight loop and store operations are all writing to
+*   cacheable write back/write allocates memory regions, R5F may
+*   hang at one of the load instruction.
+*
+* To avoid the above two conditions disable linefill optimization
+* inside Cortex R5F.
+*/
+   asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
+   actlr |= (1 << 13); /* Set DLFO bit  */
+   asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
+}
-- 
2.39.2

[PATCH 6/6] arm: mach-k3: Move ARM64 specific code into new arm64 directory

[Andrew Davis]

Like we did with R5, move ARM64 code into a specific directory to make
it clear what code is only meant to run on each core type.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/Makefile| 3 +--
 arch/arm/mach-k3/arm64/Makefile  | 6 ++
 arch/arm/mach-k3/{ => arm64}/arm64-mmu.c | 0
 arch/arm/mach-k3/{ => arm64}/cache.S | 0
 4 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-k3/arm64/Makefile
 rename arch/arm/mach-k3/{ => arm64}/arm64-mmu.c (100%)
 rename arch/arm/mach-k3/{ => arm64}/cache.S (100%)

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 42161376469..55c36161b63 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -3,9 +3,8 @@
 # Copyright (C) 2017-2018 Texas Instruments Incorporated - https://www.ti.com/
 #  Lokesh Vutla 
 
+obj-$(CONFIG_ARM64) += arm64/
 obj-$(CONFIG_CPU_V7R) += r5/
-obj-$(CONFIG_ARM64) += arm64-mmu.o
-obj-$(CONFIG_ARM64) += cache.o
 obj-$(CONFIG_OF_LIBFDT) += common_fdt.o
 ifeq ($(CONFIG_OF_LIBFDT)$(CONFIG_OF_SYSTEM_SETUP),yy)
 obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
diff --git a/arch/arm/mach-k3/arm64/Makefile b/arch/arm/mach-k3/arm64/Makefile
new file mode 100644
index 000..f3d322e17f8
--- /dev/null
+++ b/arch/arm/mach-k3/arm64/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+
+obj-y += arm64-mmu.o
+obj-y += cache.o
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
similarity index 100%
rename from arch/arm/mach-k3/arm64-mmu.c
rename to arch/arm/mach-k3/arm64/arm64-mmu.c
diff --git a/arch/arm/mach-k3/cache.S b/arch/arm/mach-k3/arm64/cache.S
similarity index 100%
rename from arch/arm/mach-k3/cache.S
rename to arch/arm/mach-k3/arm64/cache.S
-- 
2.39.2

[PATCH 5/6] arm: mach-k3: Move firewall removal into R5 directory

[Andrew Davis]

Firewalls are only ever removed by the R5 core, move this code into
the R5 directory.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/common.c| 44 
 arch/arm/mach-k3/r5/common.c | 44 
 2 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 8db7ca0725e..ed8aec360c9 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -211,50 +211,6 @@ void board_prep_linux(struct bootm_headers *images)
 }
 #endif
 
-static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
-  enum k3_firewall_region_type fwl_type)
-{
-   struct ti_sci_fwl_ops *fwl_ops;
-   struct ti_sci_handle *ti_sci;
-   struct ti_sci_msg_fwl_region region;
-   size_t j;
-
-   ti_sci = get_ti_sci_handle();
-   fwl_ops = _sci->ops.fwl_ops;
-
-   for (j = 0; j < fwl_data.regions; j++) {
-   region.fwl_id = fwl_data.fwl_id;
-   region.region = j;
-   region.n_permission_regs = 3;
-
-   fwl_ops->get_fwl_region(ti_sci, );
-
-   /* Don't disable the background regions */
-   if (region.control != 0 &&
-   ((region.control >> K3_FIREWALL_BACKGROUND_BIT) & 1) == 
fwl_type) {
-   pr_debug("Attempting to disable firewall %5d (%25s)\n",
-region.fwl_id, fwl_data.name);
-   region.control = 0;
-
-   if (fwl_ops->set_fwl_region(ti_sci, ))
-   pr_err("Could not disable firewall %5d 
(%25s)\n",
-  region.fwl_id, fwl_data.name);
-   }
-   }
-}
-
-void remove_fwl_configs(struct fwl_data *fwl_data, size_t fwl_data_size)
-{
-   size_t i;
-
-   for (i = 0; i < fwl_data_size; i++) {
-   remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
-  K3_FIREWALL_REGION_FOREGROUND);
-   remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
-  K3_FIREWALL_REGION_BACKGROUND);
-   }
-}
-
 void spl_enable_cache(void)
 {
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
index 87d4712efd4..7309573a3fa 100644
--- a/arch/arm/mach-k3/r5/common.c
+++ b/arch/arm/mach-k3/r5/common.c
@@ -247,6 +247,50 @@ void disable_linefill_optimization(void)
asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
 }
 
+static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
+  enum k3_firewall_region_type fwl_type)
+{
+   struct ti_sci_fwl_ops *fwl_ops;
+   struct ti_sci_handle *ti_sci;
+   struct ti_sci_msg_fwl_region region;
+   size_t j;
+
+   ti_sci = get_ti_sci_handle();
+   fwl_ops = _sci->ops.fwl_ops;
+
+   for (j = 0; j < fwl_data.regions; j++) {
+   region.fwl_id = fwl_data.fwl_id;
+   region.region = j;
+   region.n_permission_regs = 3;
+
+   fwl_ops->get_fwl_region(ti_sci, );
+
+   /* Don't disable the background regions */
+   if (region.control != 0 &&
+   ((region.control >> K3_FIREWALL_BACKGROUND_BIT) & 1) == 
fwl_type) {
+   pr_debug("Attempting to disable firewall %5d (%25s)\n",
+region.fwl_id, fwl_data.name);
+   region.control = 0;
+
+   if (fwl_ops->set_fwl_region(ti_sci, ))
+   pr_err("Could not disable firewall %5d 
(%25s)\n",
+  region.fwl_id, fwl_data.name);
+   }
+   }
+}
+
+void remove_fwl_configs(struct fwl_data *fwl_data, size_t fwl_data_size)
+{
+   size_t i;
+
+   for (i = 0; i < fwl_data_size; i++) {
+   remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
+  K3_FIREWALL_REGION_FOREGROUND);
+   remove_fwl_regions(fwl_data[i], fwl_data[i].regions,
+  K3_FIREWALL_REGION_BACKGROUND);
+   }
+}
+
 #if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS)
 void board_fit_image_post_process(const void *fit, int node, void **p_image,
  size_t *p_size)
-- 
2.39.2

[PATCH 4/6] arm: mach-k3: am62a7: Disable firewalls only after loading SYSFW

[Andrew Davis]

Currently we do this multiple times, instead just do it once after loading
SYSFW in R5 SPL.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/am62a7_init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
index d72e19936b9..ccbde5bdd85 100644
--- a/arch/arm/mach-k3/am62a7_init.c
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -142,6 +142,9 @@ void board_init_f(ulong dummy)
panic("ROM has not loaded TIFS firmware\n");
 
k3_sysfw_loader(true, NULL, NULL);
+
+   /* Disable ROM configured firewalls right after loading sysfw */
+   remove_fwl_configs(cbass_main_fwls, ARRAY_SIZE(cbass_main_fwls));
 #endif
 
 #if defined(CONFIG_CPU_V7R)
@@ -170,9 +173,6 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
 
-   /* Disable ROM configured firewalls right after loading sysfw */
-   remove_fwl_configs(cbass_main_fwls, ARRAY_SIZE(cbass_main_fwls));
-
 #if defined(CONFIG_K3_AM62A_DDRSS)
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret)
-- 
2.39.2

[PATCH 1/6] arm: mach-k3: Move SYS_K3_SPL_ATF definition into R5 Kconfig

[Andrew Davis]

Loading ATF is only supported from the R5, move the Kconfig symbol
definition to match.

Signed-off-by: Andrew Davis 
---
 arch/arm/mach-k3/Kconfig| 7 ---
 arch/arm/mach-k3/r5/Kconfig | 6 ++
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 03898424c95..45cf740bb1f 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -114,13 +114,6 @@ config K3_EARLY_CONS_IDX
  Use this option to set the index of the serial device to be used
  for the early console during SPL execution.
 
-config SYS_K3_SPL_ATF
-   bool "Start Cortex-A from SPL"
-   depends on CPU_V7R
-   help
- Enabling this will try to start Cortex-A (typically with ATF)
- after SPL from R5.
-
 config K3_ATF_LOAD_ADDR
hex "Load address of ATF image"
default 0x7000
diff --git a/arch/arm/mach-k3/r5/Kconfig b/arch/arm/mach-k3/r5/Kconfig
index ae79f8ff6cd..317a6c4b67e 100644
--- a/arch/arm/mach-k3/r5/Kconfig
+++ b/arch/arm/mach-k3/r5/Kconfig
@@ -43,3 +43,9 @@ config K3_SYSFW_IMAGE_SPI_OFFS
help
  Offset of the combined System Firmware and configuration image tree
  blob to be loaded when booting from a SPI flash memory.
+
+config SYS_K3_SPL_ATF
+   bool "Start Cortex-A from SPL"
+   help
+ Enabling this will try to start Cortex-A (typically with ATF)
+ after SPL from R5.
-- 
2.39.2

[PATCH 1/2] arm: dts: k3-am64: Sync with kernel v6.7-rc1

[Andrew Davis]

From: Nishanth Menon 

Sync with kernel v6.7-rc1 and sync up the u-boot dts files accordingly.

Signed-off-by: Nishanth Menon 
Signed-off-by: Andrew Davis 
---
 arch/arm/dts/k3-am64-main.dtsi|  37 ++---
 arch/arm/dts/k3-am64-mcu.dtsi |   2 +
 arch/arm/dts/k3-am64.dtsi |   2 +
 arch/arm/dts/k3-am642-evm-u-boot.dtsi | 110 --
 arch/arm/dts/k3-am642-evm.dts |  37 +
 arch/arm/dts/k3-am642-r5-evm.dts  |  24 --
 arch/arm/dts/k3-am642-r5-sk.dts   |  12 ---
 arch/arm/dts/k3-am642-sk-u-boot.dtsi  |  98 ---
 arch/arm/dts/k3-am642-sk.dts  |  29 +++
 9 files changed, 94 insertions(+), 257 deletions(-)

diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 0df54a74182..0be642bc1b8 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -38,6 +38,7 @@
};
 
main_conf: syscon@4300 {
+   bootph-all;
compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
reg = <0x0 0x4300 0x0 0x2>;
#address-cells = <1>;
@@ -45,6 +46,7 @@
ranges = <0x0 0x0 0x4300 0x2>;
 
chipid@14 {
+   bootph-all;
compatible = "ti,am654-chipid";
reg = <0x0014 0x4>;
};
@@ -96,7 +98,8 @@
};
 
dmss: bus@4800 {
-   compatible = "simple-mfd";
+   bootph-all;
+   compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
dma-ranges;
@@ -105,6 +108,7 @@
ti,sci-dev-id = <25>;
 
secure_proxy_main: mailbox@4d00 {
+   bootph-all;
compatible = "ti,am654-secure-proxy";
#mbox-cells = <1>;
reg-names = "target_data", "rt", "scfg";
@@ -188,6 +192,7 @@
};
 
dmsc: system-controller@44043000 {
+   bootph-all;
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
@@ -197,22 +202,26 @@
reg = <0x00 0x44043000 0x00 0xfe0>;
 
k3_pds: power-controller {
+   bootph-all;
compatible = "ti,sci-pm-domain";
#power-domain-cells = <2>;
};
 
k3_clks: clock-controller {
+   bootph-all;
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
 
k3_reset: reset-controller {
+   bootph-all;
compatible = "ti,sci-reset";
#reset-cells = <2>;
};
};
 
main_pmx0: pinctrl@f4000 {
+   bootph-all;
compatible = "pinctrl-single";
reg = <0x00 0xf4000 0x00 0x2d0>;
#pinctrl-cells = <1>;
@@ -221,6 +230,7 @@
};
 
main_timer0: timer@240 {
+   bootph-all;
compatible = "ti,am654-timer";
reg = <0x00 0x240 0x00 0x400>;
interrupts = ;
@@ -365,6 +375,7 @@
};
 
main_esm: esm@42 {
+   bootph-pre-ram;
compatible = "ti,j721e-esm";
reg = <0x00 0x42 0x00 0x1000>;
ti,esm-pins = <160>, <161>;
@@ -1158,21 +1169,21 @@
};
 
main_rti0: watchdog@e00 {
-   compatible = "ti,j7-rti-wdt";
-   reg = <0x00 0xe00 0x00 0x100>;
-   clocks = <_clks 125 0>;
-   power-domains = <_pds 125 TI_SCI_PD_EXCLUSIVE>;
-   assigned-clocks = <_clks 125 0>;
-   assigned-clock-parents = <_clks 125 2>;
+   compatible = "ti,j7-rti-wdt";
+   reg = <0x00 0xe00 0x00 0x100>;
+   clocks = <_clks 125 0>;
+   power-domains = <_pds 125 TI_SCI_PD_EXCLUSIVE>;
+   assigned-clocks = <_clks 125 0>;
+   assigned-clock-parents = <_clks 125 2>;
};
 
main_rti1: watchdog@e01 {
-   compatible = "ti,j7-rti-wdt";
-   reg = <0x00 0xe01 0x00 0x100>;
-   clocks = <_clks 126 0>;
-   power-doma

[PATCH 2/2] arm: dts: k3-am64: Sync with kernel v6.8-rc1

[Andrew Davis]

Sync with kernel v6.8-rc1 and sync up the u-boot dts files accordingly.

Signed-off-by: Andrew Davis 
---
 arch/arm/dts/k3-am64-main.dtsi| 22 +-
 arch/arm/dts/k3-am642-evm-u-boot.dtsi | 21 +
 arch/arm/dts/k3-am642-evm.dts | 12 +---
 arch/arm/dts/k3-am642-sk-u-boot.dtsi  | 20 
 arch/arm/dts/k3-am642-sk.dts  | 10 --
 5 files changed, 35 insertions(+), 50 deletions(-)

diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 0be642bc1b8..e348114f42e 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -63,7 +63,7 @@
#phy-cells = <1>;
};
 
-   epwm_tbclk: clock-controller@4140 {
+   epwm_tbclk: clock-controller@4130 {
compatible = "ti,am64-epwm-tbclk";
reg = <0x4130 0x4>;
#clock-cells = <1>;
@@ -138,8 +138,13 @@
  <0x00 0x4c00 0x00 0x2>,
  <0x00 0x4a82 0x00 0x2>,
  <0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>;
-   reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", 
"ringrt";
+ <0x00 0x4bc0 0x00 0x10>,
+ <0x00 0x4860 0x00 0x8000>,
+ <0x00 0x484a4000 0x00 0x2000>,
+ <0x00 0x484c2000 0x00 0x2000>,
+ <0x00 0x4842 0x00 0x2000>;
+   reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", 
"ringrt",
+   "ring", "tchan", "rchan", "bchan";
msi-parent = <_main_dmss>;
#dma-cells = <3>;
 
@@ -155,8 +160,13 @@
reg = <0x00 0x485c 0x00 0x100>,
  <0x00 0x4a80 0x00 0x2>,
  <0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>;
-   reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ <0x00 0x4b80 0x00 0x40>,
+ <0x00 0x485e 0x00 0x2>,
+ <0x00 0x484a 0x00 0x4000>,
+ <0x00 0x484c 0x00 0x2000>,
+ <0x00 0x4843 0x00 0x4000>;
+   reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
+   "ring", "tchan", "rchan", "rflow";
msi-parent = <_main_dmss>;
#dma-cells = <2>;
 
@@ -623,6 +633,7 @@
ti,otap-del-sel-mmc-hs = <0x0>;
ti,otap-del-sel-ddr52 = <0x6>;
ti,otap-del-sel-hs200 = <0x7>;
+   status = "disabled";
};
 
sdhci1: mmc@fa0 {
@@ -641,6 +652,7 @@
ti,otap-del-sel-sdr104 = <0x6>;
ti,otap-del-sel-ddr50 = <0x9>;
ti,clkbuf-sel = <0x7>;
+   status = "disabled";
};
 
cpsw3g: ethernet@800 {
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi 
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index a052941e235..c98adc65e89 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -43,29 +43,10 @@
 };
 
 _bcdma {
-   reg = <0x00 0x485c0100 0x00 0x100>,
- <0x00 0x4c00 0x00 0x2>,
- <0x00 0x4a82 0x00 0x2>,
- <0x00 0x4aa4 0x00 0x2>,
- <0x00 0x4bc0 0x00 0x10>,
- <0x00 0x4860 0x00 0x8000>,
- <0x00 0x484a4000 0x00 0x2000>,
- <0x00 0x484c2000 0x00 0x2000>;
-   reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
-   "cfg", "tchan", "rchan";
+   bootph-all;
 };
 
 _pktdma {
-   reg = <0x00 0x485c 0x00 0x100>,
- <0x00 0x4a80 0x00 0x2>,
- <0x00 0x4aa0 0x00 0x4>,
- <0x00 0x4b80 0x00 0x40>,
- <0x00 0x485e 0x00 0x2>,
- <0x00 0x484a 0x00 0x4000>,
- <0

Re: [PATCH v8 15/16] configs: Add am69_sk_* defconfig fragments

[Andrew Davis]

On 1/29/24 12:26 PM, Apurva Nandan wrote:


On 23/01/24 20:31, Andrew Davis wrote:

On 1/23/24 8:39 AM, Apurva Nandan wrote:

Hi Andrew,

On 20/01/24 00:43, Andrew Davis wrote:

On 1/19/24 11:50 AM, Apurva Nandan wrote:

From: Dasnavis Sabiya 

Add config fragments for am69_sk A72 and R5 configuration.

This applies on to:
j784s4_evm_a72_defconfig -> am69_sk_a72.config
j784s4_evm_r5_defconfig -> am69_sk_r5.config

The usage model (with the fragment) would be:
make j784s4_evm_a72_defconfig am69_sk_a72.config
make

OR

make j784s4_evm_r5_defconfig am69_sk_r5.config
make

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
  board/ti/j784s4/MAINTAINERS | 2 ++
  configs/am69_sk_a72.config  | 5 +
  configs/am69_sk_r5.config   | 5 +
  3 files changed, 12 insertions(+)
  create mode 100644 configs/am69_sk_a72.config
  create mode 100644 configs/am69_sk_r5.config

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 4433ead66b..69be13f533 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -20,3 +20,5 @@ AM69 SK BOARD
  F:    arch/arm/dts/k3-am69-sk.dts
  F:    arch/arm/dts/k3-am69-sk-u-boot.dtsi
  F:    arch/arm/dts/k3-am69-r5-sk.dts
+F:    configs/am69_sk_r5.config
+F:    configs/am69_sk_a72.config
diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config
new file mode 100644
index 00..03e74a8a56
--- /dev/null
+++ b/configs/am69_sk_a72.config


Just going to ignore the comments on v7 about putting this
in board/ti/..?



Sorry, somehow this got missed. Thanks for bringing up.



Anyway, we can now do includes in defconfigs, so no config
fragments needed, you can just add `configs/am69_evm_a72_defconfig`
with the content:

```
#include 

CONFIG_ARM=y
CONFIG_ARCH_K3=y
CONFIG_SOC_K3_J784S4=y
CONFIG_TARGET_J784S4_A72_EVM=y

CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
CONFIG_SPL_OF_LIST="k3-am69-sk"
CONFIG_OF_LIST="k3-am69-sk"
```

(note we need to duplicate the _ARM/_TARGET currently to
not confuse buildman which seems to directly parse the configs
for arch detection).



I tried it, but I don't think this works as '#' signifies a comment in 
defconfig, isn't that true?



The ability to do this was just added recently, try it again :)

Andrew


Actually, I tried on the latest uboot next, but I still don't see things being 
included from j784s4_evm_a72_defconfig

Can you point to the commit where this was introduced?



https://source.denx.de/u-boot/u-boot/-/commit/2027e99e61aab6fd8b06e2d752e0e538cff26eb6

Andrew






Andrew


@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-sk"
+CONFIG_OF_LIST="k3-am69-sk"
diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config
new file mode 100644
index 00..c42b6f3380
--- /dev/null
+++ b/configs/am69_sk_r5.config
@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-r5-sk"
+CONFIG_OF_LIST="k3-am69-r5-sk"

Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer

[Andrew Davis]

On 1/24/24 11:43 PM, Dhruva Gole wrote:

On Jan 24, 2024 at 12:08:13 -0600, Nishanth Menon wrote:

On 23:07-20240124, Dhruva Gole wrote:

On Jan 24, 2024 at 10:39:10 -0600, Nishanth Menon wrote:

On 18:38-20240124, Dhruva Gole wrote:

On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:

Dhruva Gole  writes:


The secure_hdr needs to be 0 init-ed however this was never being put
into the secure_buf, leading to possibility of the first 4 bytes of
secure_buf being possibly garbage.

Fix this by initialising the secure_hdr itself to the secure_buf
location, thus when we make it 0, it automatically ensures the first 4
bytes are 0.

Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control Interface 
(TI SCI)")
Signed-off-by: Dhruva Gole 
---

Boot tested for sanity on AM62x SK
https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074

Cc: Nishanth Menon 
Cc: Tom Rini 

  drivers/firmware/ti_sci.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index f5f659c11274..83ee8401a731 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
  {
struct k3_sec_proxy_msg *msg = >tx_message;
u8 secure_buf[info->desc->max_msg_size];
-   struct ti_sci_secure_msg_hdr secure_hdr;
+   struct ti_sci_secure_msg_hdr *secure_hdr = (struct 
ti_sci_secure_msg_hdr *)secure_buf;
int ret;
  
  	if (info->is_secure) {

/* ToDo: get checksum of the entire message */
-   secure_hdr.checksum = 0;
-   secure_hdr.reserved = 0;
+   secure_hdr->checksum = 0;
+   secure_hdr->reserved = 0;
memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,

secure_hdr is pointer now, the value may be same but (struct
ti_sci_secure_msg_hdr) would make more sense


Good catch Kamlesh! I have sent a new revision addressing this.



Makes no sense why we have secure API support in U-Boot. what is using
this?


In my understanding of generic K3 boot flow, things like proc_boot and
even applying or removing of firewalls will need a secure channel to
talk to TIFS right? From my understanding secure host can only talk to
TIFS and make such requests hence secure API.


U-boot runs in NS world, you cant even talk to the Trustzone Sec proxy
without triggering a firewall violation.


I am not going to debate on whether U-Boot is or isn't a secure entity.
The original code base was making secure_hdr.checksum = 0;

But this wasn't really being used anywhere. I am just making sure what the
original code base intended to do is being actually done.




https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/TISCI_header.html?highlight=header#secure-messaging-header
"The Secure Messaging Header is only required when sending messages over
secure transport. Messages sent over non-secure transport must not
contain the secure messaging header."


Yes, understood. I do not have the context behind the commit
32cd25128bd849 ("firmware: Add basic support for TI System Control
Interface (TI SCI)") but perhaps you do. So please help me understand
why there's this code:


A little background, this checksum was envisioned to help protect
messages from glitches in-flight for security/safety reasons. For
whatever reason it was only ever added for messages sent over
"secure" channels. Which means the message sent changes based
on what channel you use to send the message (which is a bit of a
layering violation IMHO but anyway..).

In TFA/OP-TEE which *can* send messages over secure channels we
append this header in the transport layer (secure proxy driver),
not here in the message protocol driver. If we decide to keep this
secure header code then it should be moved into the transport driver
(mailbox/k3-sec-proxy.c) as only it would know what channel the
message will be sent on (and so if it should have the header).

I'd say since U-Boot today cannot send over secure channels anyway,
lets just drop this code and if we ever need it then we add it back
over in the right spot at that time.

Andrew


memcpy(_buf[sizeof(secure_hdr)], xfer->tx_message.buf, 
xfer->tx_message.len);

which is basically trying to create a 4 byte offset (trying to abide by the 
secure
msg format?)
If UBoot as you say is non secure let's just send regular TISCI messages. Are 
you
suggesting that we trim all of if (info->is_secure) and related "secure"
code from uboot? Then that's a separate cleanup we need to have.




btw, that checksum field should be renamed integ_check, but anyways..

So, I do not see a reason to even have that if condition in the first
place and what real bug was getting fixed in this patch.


"Real" bug or "potential" bug, the code did not seem to be doing what it should 
have

Re: [PATCH v8 15/16] configs: Add am69_sk_* defconfig fragments

[Andrew Davis]

On 1/23/24 8:39 AM, Apurva Nandan wrote:

Hi Andrew,

On 20/01/24 00:43, Andrew Davis wrote:

On 1/19/24 11:50 AM, Apurva Nandan wrote:

From: Dasnavis Sabiya 

Add config fragments for am69_sk A72 and R5 configuration.

This applies on to:
j784s4_evm_a72_defconfig -> am69_sk_a72.config
j784s4_evm_r5_defconfig -> am69_sk_r5.config

The usage model (with the fragment) would be:
make j784s4_evm_a72_defconfig am69_sk_a72.config
make

OR

make j784s4_evm_r5_defconfig am69_sk_r5.config
make

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
  board/ti/j784s4/MAINTAINERS | 2 ++
  configs/am69_sk_a72.config  | 5 +
  configs/am69_sk_r5.config   | 5 +
  3 files changed, 12 insertions(+)
  create mode 100644 configs/am69_sk_a72.config
  create mode 100644 configs/am69_sk_r5.config

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 4433ead66b..69be13f533 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -20,3 +20,5 @@ AM69 SK BOARD
  F:    arch/arm/dts/k3-am69-sk.dts
  F:    arch/arm/dts/k3-am69-sk-u-boot.dtsi
  F:    arch/arm/dts/k3-am69-r5-sk.dts
+F:    configs/am69_sk_r5.config
+F:    configs/am69_sk_a72.config
diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config
new file mode 100644
index 00..03e74a8a56
--- /dev/null
+++ b/configs/am69_sk_a72.config


Just going to ignore the comments on v7 about putting this
in board/ti/..?



Sorry, somehow this got missed. Thanks for bringing up.



Anyway, we can now do includes in defconfigs, so no config
fragments needed, you can just add `configs/am69_evm_a72_defconfig`
with the content:

```
#include 

CONFIG_ARM=y
CONFIG_ARCH_K3=y
CONFIG_SOC_K3_J784S4=y
CONFIG_TARGET_J784S4_A72_EVM=y

CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
CONFIG_SPL_OF_LIST="k3-am69-sk"
CONFIG_OF_LIST="k3-am69-sk"
```

(note we need to duplicate the _ARM/_TARGET currently to
not confuse buildman which seems to directly parse the configs
for arch detection).



I tried it, but I don't think this works as '#' signifies a comment in 
defconfig, isn't that true?



The ability to do this was just added recently, try it again :)

Andrew




Andrew


@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-sk"
+CONFIG_OF_LIST="k3-am69-sk"
diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config
new file mode 100644
index 00..c42b6f3380
--- /dev/null
+++ b/configs/am69_sk_r5.config
@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-r5-sk"
+CONFIG_OF_LIST="k3-am69-r5-sk"

Re: [PATCH v8 15/16] configs: Add am69_sk_* defconfig fragments

[Andrew Davis]

On 1/19/24 11:50 AM, Apurva Nandan wrote:

From: Dasnavis Sabiya 

Add config fragments for am69_sk A72 and R5 configuration.

This applies on to:
j784s4_evm_a72_defconfig -> am69_sk_a72.config
j784s4_evm_r5_defconfig -> am69_sk_r5.config

The usage model (with the fragment) would be:
make j784s4_evm_a72_defconfig am69_sk_a72.config
make

OR

make j784s4_evm_r5_defconfig am69_sk_r5.config
make

Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
  board/ti/j784s4/MAINTAINERS | 2 ++
  configs/am69_sk_a72.config  | 5 +
  configs/am69_sk_r5.config   | 5 +
  3 files changed, 12 insertions(+)
  create mode 100644 configs/am69_sk_a72.config
  create mode 100644 configs/am69_sk_r5.config

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
index 4433ead66b..69be13f533 100644
--- a/board/ti/j784s4/MAINTAINERS
+++ b/board/ti/j784s4/MAINTAINERS
@@ -20,3 +20,5 @@ AM69 SK BOARD
  F:arch/arm/dts/k3-am69-sk.dts
  F:arch/arm/dts/k3-am69-sk-u-boot.dtsi
  F:arch/arm/dts/k3-am69-r5-sk.dts
+F: configs/am69_sk_r5.config
+F: configs/am69_sk_a72.config
diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config
new file mode 100644
index 00..03e74a8a56
--- /dev/null
+++ b/configs/am69_sk_a72.config


Just going to ignore the comments on v7 about putting this
in board/ti/..?

Anyway, we can now do includes in defconfigs, so no config
fragments needed, you can just add `configs/am69_evm_a72_defconfig`
with the content:

```
#include 

CONFIG_ARM=y
CONFIG_ARCH_K3=y
CONFIG_SOC_K3_J784S4=y
CONFIG_TARGET_J784S4_A72_EVM=y

CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
CONFIG_SPL_OF_LIST="k3-am69-sk"
CONFIG_OF_LIST="k3-am69-sk"
```

(note we need to duplicate the _ARM/_TARGET currently to
not confuse buildman which seems to directly parse the configs
for arch detection).

Andrew


@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-sk"
+CONFIG_OF_LIST="k3-am69-sk"
diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config
new file mode 100644
index 00..c42b6f3380
--- /dev/null
+++ b/configs/am69_sk_r5.config
@@ -0,0 +1,5 @@
+# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk"
+CONFIG_SPL_OF_LIST="k3-am69-r5-sk"
+CONFIG_OF_LIST="k3-am69-r5-sk"

Re: [PATCH RFC] Kconfig: Add support for FIT image signature enforcing

[Andrew Davis]

On 1/11/24 4:34 AM, Manorit Chawdhry wrote:

FIT_SIGNATURE doesn't enforce the U-boot setup to be correct for booting
the FIT images, the DTB might not have all the proper nodes and it just
boots up without any warning. This makes it difficult to get the correct
setup working.

Adds an enforcement flag that doesn't allow the setup to have problems
and enforces the environment to only pick the signature node from DTB
and don't rely on anything else.

Signed-off-by: Manorit Chawdhry 
---
A very crude implementation of [0], not exactly sure if the Kconfig
should just protect the getting key part of if we can make it more
generic and handle this as some lockdown where we can disable boot for
any other method and just allow FIT Images to bootup.



Disabling other boot modes could be a different Kconfig, then we would
have a generic "lockdown/secure" Kconfig that goes and selects the
various smaller Kconfigs (like this one) that together would prevent
bypassing security checks.


[0]: 
https://lore.kernel.org/u-boot/CAPnjgZ3B9hWTNAMr2QjSN8P1AsOme4XfSAYUKSg=trrij9d...@mail.gmail.com/
---
  boot/Kconfig | 11 +++
  boot/image-fit-sig.c | 31 +--
  2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/boot/Kconfig b/boot/Kconfig
index fbc49c5bca47..ed85fd3dc3c5 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -78,6 +78,17 @@ config FIT_SIGNATURE
  format support in this case, enable it using
  CONFIG_LEGACY_IMAGE_FORMAT.
  
+config FIT_SIGNATURE_ENFORCE

+   bool "Enforce the signature in FIT Images"
+   default y if TI_SECURE_DEVICE
+   depends on FIT_SIGNATURE
+   help
+ Enabling FIT_SIGNATURE by default doesn't enforce the U-boot DTB to be
+ having keys and allows booting the images without having proper setup.


s/be having/have

Andrew


+ This option enforces the FIT signature mechanism to contain the keys 
in
+ the DTB and enforce the nodes to be authenticated without relying on
+ the "required" node in the DTB.
+
  config FIT_SIGNATURE_MAX_SIZE
hex "Max size of signed FIT structures"
depends on FIT_SIGNATURE
diff --git a/boot/image-fit-sig.c b/boot/image-fit-sig.c
index 12369896fe3f..8a324733e7e4 100644
--- a/boot/image-fit-sig.c
+++ b/boot/image-fit-sig.c
@@ -490,15 +490,24 @@ static int fit_config_verify_required_keys(const void 
*fit, int conf_noffset,
/* Work out what we need to verify */
key_node = fdt_subnode_offset(key_blob, 0, FIT_SIG_NODENAME);
if (key_node < 0) {
-   debug("%s: No signature node found: %s\n", __func__,
- fdt_strerror(key_node));
-   return 0;
+   if (IS_ENABLED(CONFIG_FIT_SIGNATURE_ENFORCE)) {
+   printf("%s: No signature node found: %s\n", __func__,
+  fdt_strerror(key_node));
+   return -EPERM;
+   } else {
+   debug("%s: No signature node found: %s\n", __func__,
+ fdt_strerror(key_node));
+   return 0;
+   }
}
  
  	/* Get required-mode policy property from DTB */

-   reqd_mode = fdt_getprop(key_blob, key_node, "required-mode", NULL);
-   if (reqd_mode && !strcmp(reqd_mode, "any"))
-   reqd_policy_all = false;
+   if (!IS_ENABLED(CONFIG_FIT_SIGNATURE_ENFORCE)) {
+   reqd_mode =
+   fdt_getprop(key_blob, key_node, "required-mode", NULL);
+   if (reqd_mode && !strcmp(reqd_mode, "any"))
+   reqd_policy_all = false;
+   }
  
  	debug("%s: required-mode policy set to '%s'\n", __func__,

  reqd_policy_all ? "all" : "any");
@@ -514,10 +523,12 @@ static int fit_config_verify_required_keys(const void 
*fit, int conf_noffset,
const char *required;
int ret;
  
-		required = fdt_getprop(key_blob, noffset, FIT_KEY_REQUIRED,

-  NULL);
-   if (!required || strcmp(required, "conf"))
-   continue;
+   if (!IS_ENABLED(CONFIG_FIT_SIGNATURE_ENFORCE)) {
+   required = fdt_getprop(key_blob, noffset,
+  FIT_KEY_REQUIRED, NULL);
+   if (!required || strcmp(required, "conf"))
+   continue;
+   }
  
  		reqd_sigs++;
  


---
base-commit: a803f87202aa48974bdff4d8100464a8288931e4
change-id: 20231107-b4-upstream-fit-signature-enforce-185a0db88b7f

Best regards,

Re: [PATCH v3 0/8] Suspend to RAM support for K3 J7200

[Andrew Davis]

On 1/10/24 3:34 AM, Thomas Richard wrote:

On 1/9/24 18:32, Andrew Davis wrote:

On 1/8/24 10:56 AM, Thomas Richard wrote:

This series is the U-Boot part of the work to add the suspend to RAM
support for the K3 J7200 EVM board.

During the boot R5 SPL makes a copy of DM-Firmware and TF-A in memory.
Resume detection is done by reading a magic value in a pmic register
(set by DM-Firmware).

If a resume is detected, R5 SPL run the exit retention sequence of the
DDR. Then it load TF-A and DM-Firmware using the copies done during
the boot
(fit image processing is skipped).
Before to start TF-A, R5 SPL writes a magic value in scratchpad ram. This
will be used by TF-A to detect that the board is resuming.

The copy of TF-A/DM-Firmware, the SPL stack and malloc are located in a
reserved memory region (for the kernel point of view) to avoid any
memory corruption.

This version is mostly to test the firewall protection with the suspend
to ram.


Seems to show the opposite, if you are able to access and load TF-A
back to its spot after resume from un-trusted SPL then the firewall
did not survive suspend to RAM. That is a huge security gap if TIFS
is forgetting to put back the firewalls on resume.. What is the
point of firewalls on these systems if I can just knock them all
out by doing a simple suspend/resume cycle?


Hello Andrew,

Why are you talking about un-trusted SPL, how R5 SPL can be un-trusted ?


Very easily, when was the last time it had a proper security audit,
was it written from the ground up with security in mind, what secure
software development standards does it follow, etc.. No offense to
SPL, it is very good at what it was designed for, but it was not
designed for security like OP-TEE or TF-A.


Our resume sequence starts like a power-on: ROM code is started, it
loads TIFS and R5 SPL.
As defined in the chain of trust [1], ROM authenticates TIFS and R5 SPL.
So I don't understand how R5 SPL can be un-trusted.



You are making a common mistake here, just because some code was
authenticated before it started, doesn't mean it is invulnerable to
attack and cannot be compromised. Authentication only protects
against modification on the boot media.


Then R5 SPL detects that the board is resuming (and does some specific
operations on the DDR).
But even if the board is resuming, TF-A is authenticated (using
ti_secure_image_post_process) like during the boot.


Right, and this is the only thing that saves us here. TF-A being
authenticated by a higher trust entity like TIFS. My comment
was more about the context in DDR as you point out below. I'm
assuming TF-A will gain some way to authenticate that while
loading it in. Right now R5 SPL could read it out or modify
it (and as above, we don't trust R5 SPL), so having that in
plantext and un-firewalled at that point is a problem that
needs fixed for this solution to be complete.

To be fair that is a TF-A problem, but both need to be in place.

Andrew



So once TF-A is loaded, firewall is active.
TF-A restores its context, then jump to its warm entrypoint.

I guess a weak point could be TF-A context (stored in DDR).

[1] https://docs.u-boot.org/en/latest/board/ti/k3.html#chain-of-trust




Some comments (for the v2) were not fixed in this version.


Why not?


This series has been tested with the series [1] to enable the firewall.
At the end of the resume sequence, TF-A is well protected by the
firewall, but OP-TEE remains unprotected.



Then why post this? If it is just to get some eyes on it, then label
it as an "RFC" so our silence isn't considered acceptance, otherwise we
have to manually NAK these each time.


Yes sorry, I totally forgot to label it as RFC.

Regards,

Thomas

Re: [PATCH v3 0/8] Suspend to RAM support for K3 J7200

[Andrew Davis]

On 1/8/24 10:56 AM, Thomas Richard wrote:

This series is the U-Boot part of the work to add the suspend to RAM
support for the K3 J7200 EVM board.

During the boot R5 SPL makes a copy of DM-Firmware and TF-A in memory.
Resume detection is done by reading a magic value in a pmic register
(set by DM-Firmware).

If a resume is detected, R5 SPL run the exit retention sequence of the
DDR. Then it load TF-A and DM-Firmware using the copies done during the boot
(fit image processing is skipped).
Before to start TF-A, R5 SPL writes a magic value in scratchpad ram. This
will be used by TF-A to detect that the board is resuming.

The copy of TF-A/DM-Firmware, the SPL stack and malloc are located in a
reserved memory region (for the kernel point of view) to avoid any
memory corruption.

This version is mostly to test the firewall protection with the suspend
to ram.


Seems to show the opposite, if you are able to access and load TF-A
back to its spot after resume from un-trusted SPL then the firewall
did not survive suspend to RAM. That is a huge security gap if TIFS
is forgetting to put back the firewalls on resume.. What is the
point of firewalls on these systems if I can just knock them all
out by doing a simple suspend/resume cycle?


Some comments (for the v2) were not fixed in this version.


Why not?


This series has been tested with the series [1] to enable the firewall.
At the end of the resume sequence, TF-A is well protected by the
firewall, but OP-TEE remains unprotected.



Then why post this? If it is just to get some eyes on it, then label
it as an "RFC" so our silence isn't considered acceptance, otherwise we
have to manually NAK these each time.

Andrew


[1] 
https://lore.kernel.org/all/20231229-binman-firewalling-v7-0-47ed4af30...@ti.com/


Changes in v3:
- At resume, R5 SPL doesn't restore TF-A anymore.
   TF-A is started like during a cold boot. R5 SPL will notify that the board is
   resuming using a magic value written in the scratchpad ram.
   TF-A will restore itself.
- Link to v2:
   
https://lore.kernel.org/u-boot/20231107161802.855154-1-thomas.rich...@bootlin.com/

Changes in v2:
- Set exit retention code for DDR behind CONFIG_K3_J721E_DDRSS
- Check if TF-A is running in DRAM, if yes no need to restore it
- Remove BL31_START macro, and get TF-A start address from the fit image
- Remove the test_enter_suspend command
- Link to v1:
   
https://lore.kernel.org/u-boot/20231016141135.325698-1-thomas.rich...@bootlin.com/

Gowtham Tammana (1):
   DO NOT MERGE: arm: dts: k3-j7200-r5-common: Add pmic node for esm

Gregory CLEMENT (2):
   configs: j7200_evm_r5: Used reserved memory in DDR for stack
   configs: j7200_evm_r5: Move address used for allocation in the
 reserved space

Thomas Richard (5):
   board: ti: j721e: Add resume detection for J7200
   ram: k3-ddrss: Add exit retention support
   board: ti: j721e: Add the missing part of exit retention for k3-ddrss
 (J7200)
   board: ti: j721e: During resume spl notify tf-a that the board is
 resuming
   arm: mach-k3: j7200: Skip fit processing when resuming

  .../arm/dts/k3-j7200-r5-common-proc-board.dts |  17 +-
  arch/arm/mach-k3/common.c |  65 +++-
  .../arm/mach-k3/include/mach/j721e_hardware.h |   1 +
  arch/arm/mach-k3/include/mach/j721e_spl.h |  30 ++
  arch/arm/mach-k3/sysfw-loader.c   |  16 +-
  board/ti/j721e/evm.c  |  77 +
  configs/j7200_evm_r5_defconfig|   4 +-
  drivers/ram/k3-ddrss/k3-ddrss.c   | 307 ++
  8 files changed, 507 insertions(+), 10 deletions(-)

Re: [PATCH 08/10] board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script

[Andrew Davis]

On 1/8/24 11:32 AM, Nishanth Menon wrote:

Stop using the findfdt script and switch to setting the fdtfile from C
code.

While at this, replace findfdt in environment with a warning as it is
no longer needed

Signed-off-by: Nishanth Menon 
---
  board/beagle/beagleboneai64/beagleboneai64.c   | 14 ++
  board/beagle/beagleboneai64/beagleboneai64.env |  1 -
  configs/j721e_beagleboneai64_a72_defconfig |  3 ++-
  3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/board/beagle/beagleboneai64/beagleboneai64.c 
b/board/beagle/beagleboneai64/beagleboneai64.c
index c8c1c78ae5a2..1982f738b04e 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.c
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -28,3 +28,17 @@ int dram_init_banksize(void)
  {
return fdtdec_setup_memory_banksize();
  }
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   char fdtfile[50];
+
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_EVM_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+


Why not use your new ti_set_fdt_env() helper? It makes this board
consistent with TI boards (sets "name_fdt" and adds warning for
"findfdt" like your commit message says you do..).

Andrew


+   env_set("fdtfile", fdtfile);
+
+   return 0;
+}
+#endif
diff --git a/board/beagle/beagleboneai64/beagleboneai64.env 
b/board/beagle/beagleboneai64/beagleboneai64.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.env
+++ b/board/beagle/beagleboneai64/beagleboneai64.env
@@ -1,5 +1,4 @@
  #include 
-#include 
  #include 
  
  name_kern=Image

diff --git a/configs/j721e_beagleboneai64_a72_defconfig 
b/configs/j721e_beagleboneai64_a72_defconfig
index 959f86844d32..9e53658eacb9 100644
--- a/configs/j721e_beagleboneai64_a72_defconfig
+++ b/configs/j721e_beagleboneai64_a72_defconfig
@@ -34,7 +34,8 @@ CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d 
seconds\n"
  CONFIG_AUTOBOOT_DELAY_STR="d"
  CONFIG_AUTOBOOT_STOP_STR=" "
  CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot; bootflow 
scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan 
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
  CONFIG_LOGLEVEL=7
  CONFIG_SPL_MAX_SIZE=0xc
  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y

Re: [PATCH 01/10] board: ti: common: Introduce a common fdt ops library

[Andrew Davis]

On 1/8/24 11:32 AM, Nishanth Menon wrote:

Introduce a common fdt operations library for basic device tree
operations that are common between various boards.

The first library to introduce here is the capability to set up
fdtfile as a standard variable as part of board identification rather
than depend on scripted ifdeffery.

Signed-off-by: Nishanth Menon 
---
  board/ti/common/Kconfig   | 12 
  board/ti/common/Makefile  |  1 +
  board/ti/common/fdt_ops.c | 65 +++
  board/ti/common/fdt_ops.h | 41 
  4 files changed, 119 insertions(+)
  create mode 100644 board/ti/common/fdt_ops.c
  create mode 100644 board/ti/common/fdt_ops.h

diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014ab..06a8a36aa1cd 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
imply CMD_SPI
imply CMD_TIME
imply CMD_USB if USB
+
+config TI_EVM_FDT_FOLDER_PATH
+   string "Location of Folder path where dtb is present"
+   default "ti/davinci" if ARCH_DAVINCI
+   default "ti/keystone" if ARCH_KEYSTONE
+   default "ti/omap" if ARCH_OMAP2PLUS
+   default "ti" if ARCH_K3
+   depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
+   help
+  Folder path for kernel device tree default.
+  This is used along with fdtfile path to locate the kernel
+  device tree blob.
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index 26bf12e2e6d5..5ac361ba7fcf 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -3,3 +3,4 @@
  
  obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o

  obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
+obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
new file mode 100644
index ..f8770cae4a54
--- /dev/null
+++ b/board/ti/common/fdt_ops.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Library to support FDT file operations which are common
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include 
+#include "fdt_ops.h"
+
+void ti_set_fdt_env(const char *name_fdt, struct ti_fdt_map *fdt_map)
+{
+   char *fdt_file_name = NULL;
+   char fdtfile[TI_FDT_FILE_MAX];
+
+   if (name_fdt) {
+   while (fdt_map) {
+   /* Check for NULL terminator in the list */
+   if (!fdt_map->name_fdt)
+   break;
+   if (!strncmp(fdt_map->name_fdt, name_fdt, 
TI_NAME_FDT_MAX)) {
+   fdt_file_name = fdt_map->fdt_file_name;
+   break;
+   }
+   fdt_map++;
+   }
+   }
+
+   /* match not found OR null name_fdt */
+   if (!fdt_file_name) {
+   /*
+* Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
+* or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
+*/
+#ifdef CONFIG_DEFAULT_FDT_FILE
+   if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
+CONFIG_TI_EVM_FDT_FOLDER_PATH, 
CONFIG_DEFAULT_FDT_FILE);
+   } else
+#endif
+   {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_EVM_FDT_FOLDER_PATH,
+CONFIG_DEFAULT_DEVICE_TREE);
+   }
+   } else {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s", 
CONFIG_TI_EVM_FDT_FOLDER_PATH,
+fdt_file_name);
+   }
+
+   env_set("fdtfile", fdtfile);
+
+   /*
+* XXX: DEPRECATION WARNING: 2 u-boot versions.
+*
+* Maintain compatibility with downstream scripts that may be using
+* name_fdt
+*/
+   if (name_fdt)
+   env_set("name_fdt", name_fdt);


"name_fdt" should match "fdtfile", you should have just:

env_set("name_fdt", fdtfile);

are you mixing this up with "board_name"?

Andrew


+   /* Also set the findfdt legacy script to warn users to stop using this 
*/
+   env_set("findfdt",
+   "echo WARN: fdtfile already set. Stop using findfdt in script");
+}
diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
new file mode 100644
index ..c01697bed28f
--- /dev/null
+++ b/board/ti/common/fdt_ops.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Library to support common device tree manipulation for TI EVMs
+ *
+ * Copyright (C) 2024 Texas Inst

Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets

[Andrew Davis]

On 1/4/24 1:52 AM, Manorit Chawdhry wrote:

Hi Andrew, Simon,

On 08:58-20240102, Andrew Davis wrote:

On 12/31/23 6:48 AM, Simon Glass wrote:

Hi,

On Wed, Nov 29, 2023 at 7:48 PM Simon Glass  wrote:


Hi Andrew,

On Mon, 6 Nov 2023 at 11:05, Andrew Davis  wrote:


On 11/6/23 11:47 AM, Simon Glass wrote:

Hi Andrew,

On Mon, 6 Nov 2023 at 10:27, Andrew Davis  wrote:


On 11/6/23 9:31 AM, Tom Rini wrote:

On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:

Hi Simon,

On 11:22-20231005, Simon Glass wrote:

Hi Nishanth,

On Thu, 5 Oct 2023 at 11:16, Nishanth Menon  wrote:


On 12:10-20231005, Nishanth Menon wrote:

On 12:36-20231005, Tom Rini wrote:

On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:

On 10/4/23 8:54 AM, Nishanth Menon wrote:

On 08:48-20231004, Andrew Davis wrote:

On 10/4/23 8:23 AM, Roger Quadros wrote:

ti_mmc is not a valid boot_target for standard boot flow so


Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from FIT images with overlays?


envboot takes care of uEnv.txt file (see
https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/)

Early remote proc loading and FIT image is a question for stdboot itself.



If stdboot is missing these features then we shouldn't switch until it
has them. I'm all for switching to this, but only if it is complete.


Depends on what you mean?  Did you mean an option to run scripts
(exists) or an option to do what TI needs done, via
boot/bootmeth_something.c ?  If the latter, someone from TI needs to
figure out what that should be and do (but plumbing-wise everything it
needs should exist).


Andrew is generalizing here (on the wrong patch though).

On am62x platforms, there is nothing regressing with this series. The
challenge is early remote_proc loading which is done for J7* platforms.

How that is initiated as part of bootmethods is something of a gap.

The other gap has been support for uEnv.txt -> which we can workaround
at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan
-lb" in defconfig (This series from Roger already does that - hence I am
saying that Andrew is complaining on the wrong series).

Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan-lb" and
uEnv.txt remoteproc loads and the various standard bootmethods should
"just work".



I forgot to add: FIT image authenticated boot flow. That is really what
ti_mmc distroboot method was trying to solve.

Maybe Simon or someone know how the stdboot flow handles authenticated
kernel image and dtb boot flow with FIT image?


Yes you can use FIT configuration verification and things should work as normal.



Could you give any reference documentation for this?


I suspect you should start with doc/usage/fit/beaglebone_vboot.rst



From that doc:

```
Boot the board using the commands below::

setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro 
rootfstype=ext4 rootwait
ext2load mmc 0:2 8200 /boot/image.fit
bootm 8200
```

This is very much not stdboot :( This doc has some good and current info on 
building
a secure FIT image, but much of it is showing its age. Stdboot is still missing

 * ability to limit boot mode search to only one image (FIT)


What does this mean? Can you please be more specific or give an example?



Sure, for instance with secure boot we only want to search for FIT images
and if for each media this fails we do not want to fall back to other
image types or boot modes (like UART boot or net boot which would bypass
the signature checks).


We could have something like:

bootstd {
 image-types = "fit", "uimage";
}

to limit the supported types.



Something similar is needed for searching for EFI compatible boot across
each enabled boot media first, before trying other methods on each media.
Basically breadth-first search on each media type not depth-first.


How about:

bootstd {
 scan-order = "bootmeth,bootdev";   // instead of default 
"bootdev,bootmeth";
};



This along with the image-types above seem reasonable. Might also help with
our EFI search order issue (we need to search all boot media for EFI parts
first before trying all the other types of boot on each media, basically
breadth-first search vs depth for EFI). We should be able to describe that
pattern here if we think this through.



This seems okay and will solve the problem of the FIT Image issues and
fallback that we were having with stdboot.






 * fetching and applying FIT overlay/config strings


Re overlays, is this the 'extension' command? What are config strings?



When we have DT overlays in our FIT image, we build a string to pass to
bootm to apply all the selected overlays[0]. If there is now another
mechanism for this please let me know (building this string today is messy).

https://source.denx.de/u-boot/u-boot/-/

Re: [PATCH v7 4/9] arm: dts: k3-binman: Add k3-security.h and include it in k3-binman.dtsi

[Andrew Davis]

On 12/29/23 4:46 AM, Manorit Chawdhry wrote:

For readability during configuring firewalls, adding k3-security.h file
and including it in k3-binman.dtsi to be accessible across K3 SoCs

Reviewed-by: Simon Glass 
Signed-off-by: Manorit Chawdhry 
---
  arch/arm/dts/k3-binman.dtsi | 49 ++
  arch/arm/dts/k3-security.h  | 58 +
  2 files changed, 107 insertions(+)

diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index cd9926a01696..758c8bf6ea16 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -3,6 +3,8 @@
   * Copyright (C) 2022-2023 Texas Instruments Incorporated - 
https://www.ti.com/
   */
  
+#include "k3-security.h"

+
  / {
binman: binman {
multiple-images;
@@ -437,6 +439,53 @@
};
};
};
+   firewall_bg_1: template-5 {
+   control = <(FWCTRL_EN | FWCTRL_LOCK |
+   FWCTRL_BG | FWCTRL_CACHE)>;
+   permissions = <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>;
+   start_address = <0x0 0x0>;
+   end_address = <0xff 0x>;
+   };
+   firewall_bg_3: template-6 {
+   insert-template = <_bg_1>;
+   permissions = <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>,
+ <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>,
+ <((FWPRIVID_ALL << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD |
+   FWPERM_NON_SECURE_PRIV_RWCD |
+   FWPERM_NON_SECURE_USER_RWCD)>;
+   };
+   firewall_armv8_atf_fg: template-7 {
+   control = <(FWCTRL_EN | FWCTRL_LOCK |
+   FWCTRL_CACHE)>;
+   permissions = <((FWPRIVID_ARMV8 << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD)>;
+   start_address = <0x0 0x7000>;


Still don't like hardcoding the ATF firewall location here, especially
since it is dynamic and we have a var for this: CONFIG_K3_ATF_LOAD_ADDR.

Not a blocker, for now..,

Reviewed-by: Andrew Davis 


+   end_address = <0x0 0x7001>;
+   };
+   firewall_armv8_optee_fg: template-8 {
+   control = <(FWCTRL_EN | FWCTRL_LOCK |
+   FWCTRL_CACHE)>;
+   permissions = <((FWPRIVID_ARMV8 << FWPRIVID_SHIFT) |
+   FWPERM_SECURE_PRIV_RWCD |
+   FWPERM_SECURE_USER_RWCD)>;
+   start_address = <0x0 0x9e80>;
+   end_address = <0x0 0x9fff>;
+   };
  
  };
  
diff --git a/arch/arm/dts/k3-security.h b/arch/arm/dts/k3-security.h

new file mode 100644
index ..33609caa8fb5
--- /dev/null
+++ b/arch/arm/dts/k3-security.h
@@ -0,0 +1,58 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef DTS_ARM64_TI_K3_FIREWALL_H
+#define DTS_ARM64_TI_K3_FIREWALL_H
+
+#define FWPRIVID_ALL0xc3
+#define FWPRIVID_ARMV8  1
+#define FWPRIVID_SHIFT  16
+
+#define FWCTRL_EN 0xA
+#define FWCTRL_LOCK   (1 << 4)
+#define FWCTRL_BG (1 << 8)
+#define FWCTRL_CACHE  (1 << 9)
+
+#define FWPERM_SECURE_PRIV_WRITE  (1 << 0)
+#define FWPERM_SECURE_PRIV_READ   (1 << 1)
+#define FWPERM_SECURE_PRIV_CACHEABLE  (1 << 2)
+#define FWPERM_SECURE_PRIV_DEBUG  (

Re: [PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets

[Andrew Davis]

On 12/31/23 6:48 AM, Simon Glass wrote:

Hi,

On Wed, Nov 29, 2023 at 7:48 PM Simon Glass  wrote:


Hi Andrew,

On Mon, 6 Nov 2023 at 11:05, Andrew Davis  wrote:


On 11/6/23 11:47 AM, Simon Glass wrote:

Hi Andrew,

On Mon, 6 Nov 2023 at 10:27, Andrew Davis  wrote:


On 11/6/23 9:31 AM, Tom Rini wrote:

On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:

Hi Simon,

On 11:22-20231005, Simon Glass wrote:

Hi Nishanth,

On Thu, 5 Oct 2023 at 11:16, Nishanth Menon  wrote:


On 12:10-20231005, Nishanth Menon wrote:

On 12:36-20231005, Tom Rini wrote:

On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:

On 10/4/23 8:54 AM, Nishanth Menon wrote:

On 08:48-20231004, Andrew Davis wrote:

On 10/4/23 8:23 AM, Roger Quadros wrote:

ti_mmc is not a valid boot_target for standard boot flow so


Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from FIT images with overlays?


envboot takes care of uEnv.txt file (see
https://lore.kernel.org/all/20231004132324.44198-3-rog...@kernel.org/)

Early remote proc loading and FIT image is a question for stdboot itself.



If stdboot is missing these features then we shouldn't switch until it
has them. I'm all for switching to this, but only if it is complete.


Depends on what you mean?  Did you mean an option to run scripts
(exists) or an option to do what TI needs done, via
boot/bootmeth_something.c ?  If the latter, someone from TI needs to
figure out what that should be and do (but plumbing-wise everything it
needs should exist).


Andrew is generalizing here (on the wrong patch though).

On am62x platforms, there is nothing regressing with this series. The
challenge is early remote_proc loading which is done for J7* platforms.

How that is initiated as part of bootmethods is something of a gap.

The other gap has been support for uEnv.txt -> which we can workaround
at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan
-lb" in defconfig (This series from Roger already does that - hence I am
saying that Andrew is complaining on the wrong series).

Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan-lb" and
uEnv.txt remoteproc loads and the various standard bootmethods should
"just work".



I forgot to add: FIT image authenticated boot flow. That is really what
ti_mmc distroboot method was trying to solve.

Maybe Simon or someone know how the stdboot flow handles authenticated
kernel image and dtb boot flow with FIT image?


Yes you can use FIT configuration verification and things should work as normal.



Could you give any reference documentation for this?


I suspect you should start with doc/usage/fit/beaglebone_vboot.rst



   From that doc:

```
Boot the board using the commands below::

   setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro 
rootfstype=ext4 rootwait
   ext2load mmc 0:2 8200 /boot/image.fit
   bootm 8200
```

This is very much not stdboot :( This doc has some good and current info on 
building
a secure FIT image, but much of it is showing its age. Stdboot is still missing

* ability to limit boot mode search to only one image (FIT)


What does this mean? Can you please be more specific or give an example?



Sure, for instance with secure boot we only want to search for FIT images
and if for each media this fails we do not want to fall back to other
image types or boot modes (like UART boot or net boot which would bypass
the signature checks).


We could have something like:

bootstd {
image-types = "fit", "uimage";
}

to limit the supported types.



Something similar is needed for searching for EFI compatible boot across
each enabled boot media first, before trying other methods on each media.
Basically breadth-first search on each media type not depth-first.


How about:

bootstd {
scan-order = "bootmeth,bootdev";   // instead of default "bootdev,bootmeth";
};



This along with the image-types above seem reasonable. Might also help with
our EFI search order issue (we need to search all boot media for EFI parts
first before trying all the other types of boot on each media, basically
breadth-first search vs depth for EFI). We should be able to describe that
pattern here if we think this through.






* fetching and applying FIT overlay/config strings


Re overlays, is this the 'extension' command? What are config strings?



When we have DT overlays in our FIT image, we build a string to pass to
bootm to apply all the selected overlays[0]. If there is now another
mechanism for this please let me know (building this string today is messy).

https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/ti_common.env?ref_type=heads#L18


My proposal for this is to implement extensions in FIT. This would
have a new extensions nodes, so you can specify what extensions are
available for each FIT configuration.

config

Re: [RFC PATCH 00/16] Introduce ICSSG Ethernet driver

[Andrew Davis]

54-base-board.dts
b/arch/arm/dts/k3-am654-base-board.dts
index cfbcebfa37..c8da72e49c 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -16,6 +16,13 @@
chosen {
stdout-path = "serial2:115200n8";
bootargs = "earlycon=ns16550a,mmio32,0x0280";
+   firmware-loader = <_loader0>;
+   };
+
+   fs_loader0: fs-loader {
+   bootph-all;
+   compatible = "u-boot,fs-loader";
+   phandlepart = < 2>;
};


This is has 2 issues
1) It will not be accepted in Kernel DT. Maybe it could be done in -u-boot.dtsi 
file.


Sure. I'll move this to k3-am654-base-board-u-boot.dtsi


2) You cannot assume boot medium is always sdhci1 2



Yes. It's upto user to provide the boot medium and boot partition for
loading firmware. By default the firmware is loacated in root partion of
shdci1 on am65x so I am adding this as default. But user can easily
modify this to any other medium / partition needed.



Users should not have to modify DT to pick a boot medium/partition.
What would you do for complex cases or non block devices like eth/uart
booting? This is one reason kernel moved firmware loading to
userspace. The equivalant in U-Boot is the shell and scripts. Your
original command based loading was the correct solution IMHO.

If we want to try to hide some of that then we need a way to
run a user provided script from the environement to handle
the general cases for firmware loading.

Andrew



memory@8000 {
diff --git a/configs/am65x_evm_a53_defconfig
b/configs/am65x_evm_a53_defconfig
index 2755d7082f..c53e938abb 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -112,6 +112,7 @@ CONFIG_DM_I2C_GPIO=y
  CONFIG_SYS_I2C_OMAP24XX=y
  CONFIG_DM_MAILBOX=y
  CONFIG_K3_SEC_PROXY=y
+CONFIG_FS_LOADER=y
  CONFIG_SUPPORT_EMMC_BOOT=y
  CONFIG_MMC_IO_VOLTAGE=y
  CONFIG_MMC_UHS_SUPPORT=y
diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index b2f1e721b3..2d19935a41 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -98,6 +98,7 @@ CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
  CONFIG_SYS_I2C_OMAP24XX=y
  CONFIG_DM_MAILBOX=y
  CONFIG_K3_SEC_PROXY=y
+CONFIG_FS_LOADER=y
  CONFIG_K3_AVS0=y
  CONFIG_SUPPORT_EMMC_BOOT=y
  CONFIG_MMC_HS200_SUPPORT=y
diff --git a/drivers/net/ti/icssg_prueth.c b/drivers/net/ti/icssg_prueth.c
index 40ad827e49..1c4edeb7b7 100644
--- a/drivers/net/ti/icssg_prueth.c
+++ b/drivers/net/ti/icssg_prueth.c
@@ -227,6 +227,10 @@ static int prueth_start(struct udevice *dev)
void *config;
int ret, i;

+   ret = icssg_start_pru_cores(dev);
+   if (ret)
+   return ret;
+
/* To differentiate channels for SLICE0 vs SLICE1 */
snprintf(chn_name, sizeof(chn_name), "tx%d-0", priv->slice);

@@ -355,9 +359,11 @@ static void prueth_stop(struct udevice *dev)
phy_shutdown(priv->phydev);

dma_disable(>dma_tx);
-   dma_free(>dma_tx);
-
dma_disable(>dma_rx);
+
+   icssg_stop_pru_cores(dev);
+
+   dma_free(>dma_tx);
dma_free(>dma_rx);
  }

@@ -434,6 +440,181 @@ static const struct soc_attr k3_mdio_soc_data[] = {
{ /* sentinel */ },
  };

+struct icssg_firmware_load_address {
+   u32 pru;
+   u32 rtu;
+   u32 txpru;
+};
+
+struct icssg_firmwares {
+   char *pru;
+   char *rtu;
+   char *txpru;
+};
+
+static struct icssg_firmwares icssg_emac_firmwares[] = {
+   {
+   .pru = "/lib/firmware/ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
+   .rtu = "/lib/firmware/ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
+   .txpru = 
"/lib/firmware/ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
+   },
+   {
+   .pru = "/lib/firmware/ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
+   .rtu = "/lib/firmware/ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
+   .txpru = 
"/lib/firmware/ti-pruss/am65x-sr2-txpru1-prueth-fw.elf",
+   }
+};


This information is contained in the DT.

firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
"ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
"ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
"ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
"ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
"ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";



Yes it is. But the linux driver uses the firmware strcuture inside
driver only. The firmware-name property is not being used. The firmware
names for all applicable SoCs (AM65x and AM64x) is same so instead of
reading it from DT, the driver hardcodes the fir

Re: [PATCH v6 00/17] Introduce initial TI's J784S4 and AM69 support

[Andrew Davis]

On 12/15/23 2:51 AM, Marcel Ziswiler wrote:

On Thu, 2023-12-14 at 14:28 -0600, Andrew Davis wrote:

On 12/14/23 2:10 PM, b...@ti.com wrote:

On December 14, 2023 thus sayeth Marcel Ziswiler:

Hi Apurva

Thanks!

On Wed, 2023-12-06 at 18:07 +0530, Apurva Nandan wrote:

Hello Everyone!

This series will introduce basic support (SD and UART) support for Texas
Instruments J784S4 EVM.


For the whole series:

Tested-by: Marcel Ziswiler 

However, one thing I noticed is that with upstream TF-A I do get the following 
errors:

NOTICE:  BL31: v2.10.0  (release):v2.10.0-76-g02091541d
NOTICE:  BL31: Built : 18:13:08, Dec 14 2023
ERROR:   Failed to get response (-19)
ERROR:   Transfer send failed (-19)
ERROR:   Unable to query firmware capabilities (-19)

While with latest TF-A from downstream TI BSP (both 9.0 and 9.1 use the same 
versin) I do not get any
errors:

NOTICE:  BL31: v2.9(release):v2.9.0-614-gd7a7135d3
NOTICE:  BL31: Built : 18:40:38, Dec 14 2023



What version of TIFS are you running? Not getting a response usually
means firmware is dead or we're not using the right thread to talk.



In this case the early versions of TIFS/DM for J784S4/AM69 had
a bug where the "query firmware capabilities" API was left disabled.
This is fixed in the next version of firmware, this error message
is harmless today anyway (no LPM yet).


No, I was always running the latest from the ti-linux-firmware branch:

SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.2--v09.01.02 (Kool Koala)')

So, it is really TF-A which seems to cause the issue here.



When I said "fixed in the next version" I meant the next to
be released, as in not yet out (I'd guess out in a week or so).
Sorry for any confusion here.

I added support for this new API to TF-A only recently,
which is why the old TF-A versions don't print this error.
Nishanth gives more details in the other thread, but as
said this error is harmless and will go away in with
the next firmware update.

Andrew


Andrew


Cheers

Marcel

Re: [PATCH v6 00/17] Introduce initial TI's J784S4 and AM69 support

[Andrew Davis]

On 12/14/23 2:10 PM, b...@ti.com wrote:

On December 14, 2023 thus sayeth Marcel Ziswiler:

Hi Apurva

Thanks!

On Wed, 2023-12-06 at 18:07 +0530, Apurva Nandan wrote:

Hello Everyone!

This series will introduce basic support (SD and UART) support for Texas
Instruments J784S4 EVM.


For the whole series:

Tested-by: Marcel Ziswiler 

However, one thing I noticed is that with upstream TF-A I do get the following 
errors:

NOTICE:  BL31: v2.10.0  (release):v2.10.0-76-g02091541d
NOTICE:  BL31: Built : 18:13:08, Dec 14 2023
ERROR:   Failed to get response (-19)
ERROR:   Transfer send failed (-19)
ERROR:   Unable to query firmware capabilities (-19)

While with latest TF-A from downstream TI BSP (both 9.0 and 9.1 use the same 
versin) I do not get any errors:

NOTICE:  BL31: v2.9(release):v2.9.0-614-gd7a7135d3
NOTICE:  BL31: Built : 18:40:38, Dec 14 2023



What version of TIFS are you running? Not getting a response usually
means firmware is dead or we're not using the right thread to talk.



In this case the early versions of TIFS/DM for J784S4/AM69 had
a bug where the "query firmware capabilities" API was left disabled.
This is fixed in the next version of firmware, this error message
is harmless today anyway (no LPM yet).

Andrew

Re: Proposal: FIT support for extension boards / overlays

[Andrew Davis]

On 12/12/23 8:05 AM, Simon Glass wrote:

Hi,

The devicetree files for a board can be quite large, perhaps around
60KB. To boot on any supported board, many of them need to be
provided, typically hundreds.

All boards for a particular SoC share common parts.  It would be
helpful to use overlays for common pieces, to reduce the overall size.



For this to save much size we would need to have the SoC split
from each board that uses it. We don't have that in DT today.
There are some efforts in progress to help on this but until
then we will not get much here.


Some boards have extension add-ons which have their own devicetree
overlays. It would be helpful to know which ones should be applied for
a particular extension.

I propose implementing extensions in FIT. This has a new '/extensions'
node, so you can specify what extensions are available for each FIT
configuration.

For example:

/ {
   images {
 kernel {
   // common kernel
 };

 fdt-1 {
   // FDT for board1
 };

 fdto-1 {
   // FDT overlay
 };

 fdto-2 {
   // FDT overlay
 };

 fdto-3 {
   // FDT overlay
 };
   };

   configurations {
 conf-1 {
 compatible = ...
 fdt = "fdt-1";
 extensions = "ext1", "ext-2";
 };
   };

   extensions {
 ext-1 {
 fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
 kernel = "kernel-1";
 compatible = "vendor,combined-device1";
 extensions = "ext-3";
 };

 ext-2 {
 fdto = "fdto-2";   // fdt overlay for this 'cape'
 compatible = "vendor,device2";
 };

 ext-3 {
 fdto = "fdto-3";
 compatible = "vendor,device3";
 };
   };
};

So FIT configurations have a list of supported extensions. The
extensions are hierarchical so that you can have ext-1 which can
optionally have ext-2 as well. This allows boards to share a common
SoC to add in overlays as needed by their board. It also allows common
'capes' or 'hats' to be specified only once and used by a group of
boards which share the same interface.



Are you suggesting an 'extension' that lists every 'cape', then for each
board that has a 'cape' header we list that 'hierarchical extension'
to suggest support?

Seems reasonable, but we don't have universal DTB overlays today. Each
overlay needs to be built for a specific board due to several reasons
(I have some plans to help solve this but the upstream kernel path might
be a ways out).


Within U-Boot, extensions actually present are declared by a sysinfo
driver for the board, with new methods:

get_compat() - determine the compatible strings for the current platform
get_ext() - get a list of compatible strings for extensions which are
actually present

The extension compatible-strings are used to select the correct things
from the FIT, apply the overlays and produce the final DT.



These extension compatible-strings, could they just be the name of
the overlay file? That is what we do today with our name_overlays[0].
The benefit is these names can be used to load and apply overlays in
the non-FIT case just the same.

If we name the configuration nodes after the DTBO that they contain
then I'm not sure what this 'extensions' list gains us over having
a list of overlays to apply like we do today.

Andrew

[0] https://github.com/trini/u-boot/blob/master/board/ti/am65x/evm.c#L189


To make this simpler for the common case (without extensions), we can
allow multiple FDT images for a configuration, with the first one
being the base SoC .dtb and the others being the .dtbo overlay(s) for
the board:

confi-1 {
 compatible = ...
 fdt = "fdt-1", "fdto-1";
};

Comments welcome.

Regards,
Simon

Re: [PATCH v6 8/8] docs: k3: Add secure booting documentation

[Andrew Davis]

On 12/6/23 3:51 AM, Manorit Chawdhry wrote:

This commit adds a general flow to explain the usage of firewalls and
the chain of trust in K3 devices.

Signed-off-by: Manorit Chawdhry 
---
  doc/board/ti/k3.rst | 45 +
  1 file changed, 45 insertions(+)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index 947b86ba8292..60d04c5708be 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -104,6 +104,51 @@ firmware can be loaded on the now free core in the wakeup 
domain.
  For more information on the bootup process of your SoC, consult the
  device specific boot flow documentation.
  
+Secure Boot

+^^^
+
+K3 HS-SE devices are used for authenticated boot flow with secure boot.


How about:

K3 HS-SE devices enforce an authenticated boot flow for secure boot.


+HS-FS devices have optional authentication in the flow and doesn't "require"
+authentication unless converted to HS-SE devices.


HS-FS is the state of a K3 device before it has been eFused with
customer security keys. In the HS-FS state the authentication still
can function as in HS-SE but as there are no customer keys to verify
the signatures against the authentication will pass for certificates
signed with any key.


+
+Chain of trust
+""""""""""""""
+
+1) SMS starts up and loads the authenticated ROM code in Wakeup Domain
+2) ROM code starts up and loads the authenticated tiboot3.bin in Wakeup
+   Domain
+3) Wakeup SPL (tiboot3.bin) would authenticate the next set of binaries
+   (ATF,OP-TEE,DM,SPL,etc.)
+4) After ATF and OP-TEE load, ARMV8 U-boot authenticates the next set of
+   binaries (Linux and DTBs) if using FIT Image authentication and having a
+   signature node in U-boot.



This might be better said like this:

1) Public ROM loads the tiboot3.bin (R5 SPL, TIFS)
2) R5 SPL loads tispl.bin (ATF, OP-TEE, DM, SPL)
3) SPL loads u-boot.img (U-Boot)
4) U-Boot loads fitImage (Linux and DTBs)

Each stage authenticating (and optionally decrypting) while loading is
implied by the following sentences below, no need to repeat each time.

Plus the use of "ROM" is confusing, we have two ROMs in K3 (Secure ROM
and Public ROM), you should always be specific.


+
+Steps 1-3 are all authenticated by either the ROM code or TIFS as the


s/ROM code/Secure ROM


+authenticating entity and step 4 uses U-boot standard mechanism for
+authenticating.
+
+All the authentication that are done for ROM/TIFS are done through x509
+certificates that are signed.
+
+Firewalls
+"""""""""
+
+1) ROM comes up and sets up firewalls that are needed by itself


Secure ROM


+2) TIFS (in multicertificate will setup it's own firewalls)


TIFS sets up it's own firewalls in either case.


+3) R5 SPL comes along and opens up other firewalls ( that are not owned by
+   anyone - essentially firewalls that were setup by ROM but are not needed
+   anymore)


How about:

3) R5 SPL will remove any firewalls that are leftover from the Secure ROM stage
that are no longer required.


+4) Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to
+   set up firewalls to protect themselves (enforced by TIFS)
+5) TFA/OP-TEE can configure other firewalls at runtime if required as they
+   are already authenticated and firewalled off from illegal access.
+6) A53 SPL and U-boot itself startups but has no ability to change the
+   protection firewalls enforced by x509 OIDs or any other firewalls
+   configured by ROM/TIFS in the beginning.


6) All later stages can setup or remove firewalls that have not been already
configured by previous stages, such as those created by TIFS, TFA, and OP-TEE.


+
+Futhur, firewalls have a lockdown bit in hardware that enforces the setting
+(and cannot be over-ridden) till the full system is resetted.


s/till/until
s/resetted/reset

Andrew


+
  Software Sources
  
  

Re: [PATCH v6 4/8] binman: j721e: Add firewall configurations

[Andrew Davis]

On 12/6/23 3:51 AM, Manorit Chawdhry wrote:

The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.

Signed-off-by: Manorit Chawdhry 
---
  arch/arm/dts/k3-j721e-binman.dtsi | 196 ++
  1 file changed, 196 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-binman.dtsi 
b/arch/arm/dts/k3-j721e-binman.dtsi
index 5ddb474e3a41..f428aa81a6c1 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -146,6 +146,202 @@
  
  		fit {

images {
+   atf {
+   ti-secure {
+   auth-in-place = <0xa02>;
+
+   firewall-257-0 {
+   /* cpu_0_cpu_0_msmc 
Background Firewall */
+   id = <257>;
+   region = <0>;
+   control = <(FWCTRL_EN | 
FWCTRL_LOCK |
+   
FWCTRL_BG | FWCTRL_CACHE)>;
+   permissions = <((FWPRIVID_ALL 
<< FWPRIVID_SHIFT) |
+   
FWPERM_SECURE_PRIV_RWCD |
+   
FWPERM_SECURE_USER_RWCD |
+   
FWPERM_NON_SECURE_PRIV_RWCD |
+  
 FWPERM_NON_SECURE_USER_RWCD)>;
+   start_address = <0x0 
0x0>;
+   end_address = <0xff 
0x>;
+   };
+
+   firewall-257-1 {
+   /* cpu_0_cpu_0_msmc 
Foreground Firewall */
+   id = <257>;
+   region = <1>;
+   control = <(FWCTRL_EN | 
FWCTRL_LOCK |
+   
FWCTRL_CACHE)>;
+   permissions = 
<((FWPRIVID_ARMV8 << FWPRIVID_SHIFT) |
+   
FWPERM_SECURE_PRIV_RWCD |
+  
 FWPERM_SECURE_USER_RWCD)>;
+   start_address = <0x0 
0x7000>;


7 levels of indentation, impressive :)

This start address should always match CONFIG_K3_ATF_LOAD_ADDR, any way
you can just use that here?

Also this seems like a lot to add for each SoC, and much of it looks similar
(at least for Jacinto class devices), could be an opportunity for templating.

Andrew


+   end_address = <0x0 
0x7001>;
+   };

Re: [PATCH 1/2] doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE

[Andrew Davis]

On 12/5/23 9:22 AM, Nishanth Menon wrote:

On 08:46-20231205, Andrew Davis wrote:

On 12/4/23 1:29 PM, Nishanth Menon wrote:

On 15:59-20231201, Dhruva Gole wrote:

Delete the flag CFG_WITH_SOFTWARE_PRNG as it's not necessary/ boot
requirement for this SoC

Signed-off-by: Dhruva Gole 
---
   doc/board/beagle/am62x_beagleplay.rst | 1 -
   1 file changed, 1 deletion(-)

diff --git a/doc/board/beagle/am62x_beagleplay.rst 
b/doc/board/beagle/am62x_beagleplay.rst
index 7784e62b0b71..50d7d3c620d7 100644
--- a/doc/board/beagle/am62x_beagleplay.rst
+++ b/doc/board/beagle/am62x_beagleplay.rst
@@ -63,7 +63,6 @@ Set the variables corresponding to this platform:
 # we dont use any extra TFA parameters
 unset TFA_EXTRA_ARGS
 export OPTEE_PLATFORM=k3-am62x
-  export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
   .. include::  ../ti/am62x_sk.rst
   :start-after: .. am62x_evm_rst_include_start_build_steps
--
2.34.1


NAK. RNG is needed to seed standard distros.


You have this backwards, setting WITH_SOFTWARE_PRNG=y forces the SW
RNG, disabling the HW RNG. Without this line the HW RNG is the default.



That is not the rationale with which the series was posted. I would
prefer we use HW RNG by default. but as I understand there are a bunch
of f/w bugs preventing us from doing so. if they are resolved, then the
commit message argument should be that the bugs are fixed, so we can
easily use then with f/w version x.y.z onwards.


There was a single FW bug that caused suspend/resume to fail when OP-TEE
was using the HW RNG. The HW RNG always worked, disabling it was a hack
that allowed us to still demo suspend/resume, not sure how that ended up
in this documentation.

The fact we disabled a security feature to workaround a non-security bug
shows a lack of good judgement on our part IMHO. Product security is our
top priority.

Andrew

Re: [PATCH 1/2] doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE

[Andrew Davis]

On 12/4/23 1:29 PM, Nishanth Menon wrote:

On 15:59-20231201, Dhruva Gole wrote:

Delete the flag CFG_WITH_SOFTWARE_PRNG as it's not necessary/ boot
requirement for this SoC

Signed-off-by: Dhruva Gole 
---
  doc/board/beagle/am62x_beagleplay.rst | 1 -
  1 file changed, 1 deletion(-)

diff --git a/doc/board/beagle/am62x_beagleplay.rst 
b/doc/board/beagle/am62x_beagleplay.rst
index 7784e62b0b71..50d7d3c620d7 100644
--- a/doc/board/beagle/am62x_beagleplay.rst
+++ b/doc/board/beagle/am62x_beagleplay.rst
@@ -63,7 +63,6 @@ Set the variables corresponding to this platform:
# we dont use any extra TFA parameters
unset TFA_EXTRA_ARGS
export OPTEE_PLATFORM=k3-am62x
-  export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
  
  .. include::  ../ti/am62x_sk.rst

  :start-after: .. am62x_evm_rst_include_start_build_steps
--
2.34.1


NAK. RNG is needed to seed standard distros.


You have this backwards, setting WITH_SOFTWARE_PRNG=y forces the SW
RNG, disabling the HW RNG. Without this line the HW RNG is the default.

Andrew

Re: [PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument

[Andrew Davis]

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

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

Re: [PATCH v5 17/17] board: ti: j784s4: Add MAINTAINERS file

[Andrew Davis]

On 11/30/23 5:55 AM, Apurva Nandan wrote:

Add maintainership for new J784S4 files added.

Signed-off-by: Apurva Nandan 
---
  board/ti/j784s4/MAINTAINERS | 25 +
  1 file changed, 25 insertions(+)
  create mode 100644 board/ti/j784s4/MAINTAINERS

diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS
new file mode 100644
index 00..d3f0e50391
--- /dev/null
+++ b/board/ti/j784s4/MAINTAINERS
@@ -0,0 +1,25 @@
+J784S4 BOARD
+M: Apurva Nandan 
+S: Maintained
+F: board/ti/j784s4
+F: arch/arm/mach-k3/j784s4


The arch/arm/mach-k3/j784s4 files are not related to the board, other
boards and board vendors can have different maintainers, and the SoC
maintainer doesn't need to be a maintainer of any set of boards.

I wonder if we should move the SoC level maintainer lines up into the
main MAINTAINERS file, or add arch/arm/mach-k3/MAINTAINERS. Leaving only
the board specific files in the board/**/MAINTAINERS file.

Andrew


+F: include/configs/j784s4_evm.h
+F: configs/j784s4_evm_r5_defconfig
+F: configs/j784s4_evm_a72_defconfig
+F: arch/arm/dts/k3-j784s4.dtsi
+F: arch/arm/dts/k3-j784s4-main.dtsi
+F: arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
+F: arch/arm/dts/k3-j784s4-thermal.dtsi
+F: arch/arm/dts/k3-j784s4-evm.dts
+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
+F: doc/board/ti/j784s4_evm.rst
+
+AM69 BOARD
+F: arch/arm/dts/k3-am69-sk.dts
+F: arch/arm/dts/k3-am69-sk-u-boot.dtsi
+F: arch/arm/dts/k3-am69-r5-sk.dts
+F: configs/am69_sk_r5.config
+F: configs/am69_sk_a72.config

Re: [PATCH v5 12/17] arm: dts: Introduce j784s4 u-boot dts files

[Andrew Davis]

nt-sysfw-data = <_tifs_cfg_fs>;
+   content-sysfw-inner-cert = <_inner_cert_fs>;
+   content-dm-data = <_dm_cfg_fs>;
+   load = <0x41c0>;
+   load-sysfw = <0x4>;
+   load-sysfw-data = <0x66800>;
+   load-dm-data = <0x41c8>;
+   };
+
+   u_boot_spl_fs: u-boot-spl {
+   no-expanded;
+   };
+
+   ti_fs_enc_fs: ti-fs-enc.bin {
+   filename = 
"ti-sysfw/ti-fs-firmware-j784s4-hs-fs-enc.bin";
+   type = "blob-ext";
+   optional;
+   };
+
+   combined_tifs_cfg_fs: combined-tifs-cfg.bin {
+   filename = "combined-tifs-cfg.bin";
+   type = "blob-ext";
+   };
+
+   sysfw_inner_cert_fs: sysfw-inner-cert {
+   filename = 
"ti-sysfw/ti-fs-firmware-j784s4-hs-fs-cert.bin";
+   type = "blob-ext";
+   optional;
+   };
+
+   combined_dm_cfg_fs: combined-dm-cfg.bin {
+   filename = "combined-dm-cfg.bin";
+   type = "blob-ext";
+   };
+   };
+};
+
+ {
+   tiboot3-j784s4-gp-evm.bin {
+   filename = "tiboot3-j784s4-gp-evm.bin";
+   symlink = "tiboot3.bin";
+
+   ti-secure-rom {
+   content = <_boot_spl_unsigned>, <_fs_gp>,
+   <_tifs_cfg_gp>, <_dm_cfg_gp>;
+   combined;
+   dm-data;
+   content-sbl = <_boot_spl_unsigned>;
+   load = <0x41c0>;
+   content-sysfw = <_fs_gp>;
+   load-sysfw = <0x4>;
+   content-sysfw-data = <_tifs_cfg_gp>;
+   load-sysfw-data = < 0x66800>;
+   content-dm-data = <_dm_cfg_gp>;
+   load-dm-data = <0x41c8>;
+   sw-rev = <1>;
+   keyfile = "ti-degenerate-key.pem";
+   };
+
+   u_boot_spl_unsigned: u-boot-spl {
+   no-expanded;
+   };
+
+   ti_fs_gp: ti-fs-gp.bin {
+   filename = "ti-sysfw/ti-fs-firmware-j784s4-gp.bin";
+   type = "blob-ext";
+   optional;
+   };
+
+   combined_tifs_cfg_gp: combined-tifs-cfg-gp.bin {
+   filename = "combined-tifs-cfg.bin";
+   type = "blob-ext";
+   };
+
+   combined_dm_cfg_gp: combined-dm-cfg-gp.bin {
+   filename = "combined-dm-cfg.bin";
+   type = "blob-ext";
+   };
+
+   };
+};
+#endif
+
+#ifdef CONFIG_TARGET_J784S4_A72_EVM
+
+#define SPL_J784S4_EVM_DTB "spl/dts/k3-j784s4-evm.dtb"
+
+#define J784S4_EVM_DTB "u-boot.dtb"
+


Why not define this as "arch/arm/dts/k3-j784s4-evm.dtb"? Seems we use this
as a hacky way to change this item based on CONFIG_DEFAULT_DEVICE_TREE as
that DT will be renamed "u-boot.dtb". But I'm not sure what that gains us.
And why only do it for U-Boot and not SPL_? If runtime selection is not
working then we still have the wrong DTB for SPL just the same.

It also means we have in some builds we have a node named "j784s4_evm_dtb"
that contains the SK DTB, and the node called "am69_sk_dtb" *also* contains
the SK DTB..

Andrew

Re: [PATCH v5 10/17] board: ti: j748s4: Add board config yaml files

[Andrew Davis]

On 11/30/23 5:55 AM, 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

diff --git a/board/ti/j784s4/board-cfg.yaml b/board/ti/j784s4/board-cfg.yaml
new file mode 100644
index 00..049105062c
--- /dev/null
+++ b/board/ti/j784s4/board-cfg.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+#
+# Board configuration for J784S4
+#
+
+---
+
+board-cfg:
+rev:
+boardcfg_abi_maj: 0x0
+boardcfg_abi_min: 0x1
+control:
+subhdr:
+magic: 0xC1D3
+size: 7
+main_isolation_enable: 0x5A
+main_isolation_hostid: 0x2
+secproxy:
+subhdr:
+magic: 0x1207
+size: 7
+scaling_factor: 0x1
+scaling_profile: 0x1
+disable_main_nav_secure_proxy: 0
+msmc:
+subhdr:
+magic: 0xA5C3
+size: 5
+msmc_cache_size: 0x8
+debug_cfg:
+subhdr:
+magic: 0x020C
+size: 8
+trace_dst_enables: 0x00
+trace_src_enables: 0x00
\ No newline at end of file


Does checkpatch not complain about this no newline?

Andrew

Re: [PATCH v5 09/17] board: ti: j784s4: Add board support for J784S4 EVM

[Andrew Davis]

On 11/30/23 5:55 AM, Apurva Nandan wrote:

Add board files for J784S4 EVM.

Signed-off-by: Hari Nagalla 
[ add env and board specific yaml files for binman ]
Signed-off-by: Neha Malcom Francis 
[ cleaned up the env files ]
Signed-off-by: Manorit Chawdhry 
Signed-off-by: Dasnavis Sabiya 
Signed-off-by: Apurva Nandan 
---
  arch/arm/mach-k3/Kconfig|  1 +
  arch/arm/mach-k3/j784s4/Kconfig | 35 ++
  board/ti/j784s4/Makefile|  7 ++
  board/ti/j784s4/evm.c   | 38 +
  include/configs/j784s4_evm.h| 20 +
  5 files changed, 101 insertions(+)
  create mode 100644 arch/arm/mach-k3/j784s4/Kconfig
  create mode 100644 board/ti/j784s4/Makefile
  create mode 100644 board/ti/j784s4/evm.c
  create mode 100644 include/configs/j784s4_evm.h

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 150d0bfa14..445b49e245 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -157,5 +157,6 @@ source "arch/arm/mach-k3/am62x/Kconfig"
  source "arch/arm/mach-k3/am62ax/Kconfig"
  source "arch/arm/mach-k3/j721e/Kconfig"
  source "arch/arm/mach-k3/j721s2/Kconfig"
+source "arch/arm/mach-k3/j784s4/Kconfig"
  
  endif

diff --git a/arch/arm/mach-k3/j784s4/Kconfig b/arch/arm/mach-k3/j784s4/Kconfig
new file mode 100644
index 00..03d3f91371
--- /dev/null
+++ b/arch/arm/mach-k3/j784s4/Kconfig
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+#  Hari Nagalla 
+
+if SOC_K3_J784S4
+
+choice
+   prompt "K3 J784S4 board"
+   optional
+
+config TARGET_J784S4_A72_EVM
+   bool "TI K3 based J784S4 EVM running on A72"
+   select ARM64
+   select BOARD_LATE_INIT
+   select SYS_DISABLE_DCACHE_OPS
+   select BINMAN
+
+config TARGET_J784S4_R5_EVM
+   bool "TI K3 based J784S4 EVM running on R5"
+   select CPU_V7R
+   select SYS_THUMB_BUILD
+   select K3_LOAD_SYSFW
+   select RAM
+   select SPL_RAM
+   select K3_DDRSS
+   select BINMAN
+   imply SYS_K3_SPL_ATF
+
+endchoice
+
+source "board/ti/j784s4/Kconfig"
+
+endif
+
diff --git a/board/ti/j784s4/Makefile b/board/ti/j784s4/Makefile
new file mode 100644
index 00..3fc70eb8fb
--- /dev/null
+++ b/board/ti/j784s4/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+#  Hari Nagalla 
+#
+
+obj-y += evm.o
diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
new file mode 100644
index 00..4857c9d2f6
--- /dev/null
+++ b/board/ti/j784s4/evm.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Board specific initialization for J784S4 EVM
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla 
+ *
+ */
+
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   return fdtdec_setup_mem_size_base();
+}
+
+int dram_init_banksize(void)
+{
+   return fdtdec_setup_memory_banksize();
+}
+
+int board_late_init(void)
+{
+   return 0;
+}
+
+void spl_board_init(void)
+{
+}
diff --git a/include/configs/j784s4_evm.h b/include/configs/j784s4_evm.h
new file mode 100644
index 00..1b780134ca
--- /dev/null
+++ b/include/configs/j784s4_evm.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Configuration header file for K3 J784S4 EVM
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla 
+ */
+
+#ifndef __CONFIG_J784S4_EVM_H
+#define __CONFIG_J784S4_EVM_H
+
+#include 


Is this include needed?


+
+/* DDR Configuration */
+#define CFG_SYS_SDRAM_BASE10x88000


Do you need this? It should always be the same, no need to
make a per-SoC definition for it. I just sent out a patch
fixing the same for other K3[0].

Andrew

[0] https://lists.denx.de/pipermail/u-boot/2023-November/539024.html


+
+/* Now for the remaining common defines */
+#include 
+
+#endif /* __CONFIG_J784S4_EVM_H */

[PATCH] board: ti: k3: Remove need for CFG_SYS_SDRAM_BASE

[Andrew Davis]

The base address of extended DDR does not change across the K3 family.
Setting this per SoC is not needed. Remove this definition to help
remove the last bits from K3 include/configs/*.h files.

Signed-off-by: Andrew Davis 
---
 board/ti/am65x/evm.c | 4 ++--
 board/ti/j721e/evm.c | 4 ++--
 board/ti/j721s2/evm.c| 4 ++--
 include/configs/am62ax_evm.h | 4 
 include/configs/am65x_evm.h  | 3 ---
 include/configs/j721e_evm.h  | 2 --
 include/configs/j721s2_evm.h | 3 ---
 7 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 975eb17946f..df209021c1b 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -73,13 +73,13 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
 int dram_init_banksize(void)
 {
/* Bank 0 declares the memory available in the DDR low region */
-   gd->bd->bi_dram[0].start = CFG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].start = 0x8000;
gd->bd->bi_dram[0].size = 0x8000;
gd->ram_size = 0x8000;
 
 #ifdef CONFIG_PHYS_64BIT
/* Bank 1 declares the memory available in the DDR high region */
-   gd->bd->bi_dram[1].start = CFG_SYS_SDRAM_BASE1;
+   gd->bd->bi_dram[1].start = 0x88000;
gd->bd->bi_dram[1].size = 0x8000;
gd->ram_size = 0x1;
 #endif
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 0768385f40c..c541880107e 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -61,13 +61,13 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
 int dram_init_banksize(void)
 {
/* Bank 0 declares the memory available in the DDR low region */
-   gd->bd->bi_dram[0].start = CFG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].start = 0x8000;
gd->bd->bi_dram[0].size = 0x8000;
gd->ram_size = 0x8000;
 
 #ifdef CONFIG_PHYS_64BIT
/* Bank 1 declares the memory available in the DDR high region */
-   gd->bd->bi_dram[1].start = CFG_SYS_SDRAM_BASE1;
+   gd->bd->bi_dram[1].start = 0x88000;
gd->bd->bi_dram[1].size = 0x8000;
gd->ram_size = 0x1;
 #endif
diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index db717390771..1220cd84519 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -56,13 +56,13 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
 int dram_init_banksize(void)
 {
/* Bank 0 declares the memory available in the DDR low region */
-   gd->bd->bi_dram[0].start = CFG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].start = 0x8000;
gd->bd->bi_dram[0].size = 0x7fff;
gd->ram_size = 0x8000;
 
 #ifdef CONFIG_PHYS_64BIT
/* Bank 1 declares the memory available in the DDR high region */
-   gd->bd->bi_dram[1].start = CFG_SYS_SDRAM_BASE1;
+   gd->bd->bi_dram[1].start = 0x88000;
gd->bd->bi_dram[1].size = 0x37fff;
gd->ram_size = 0x4;
 #endif
diff --git a/include/configs/am62ax_evm.h b/include/configs/am62ax_evm.h
index 57003f120f9..496d1c2348f 100644
--- a/include/configs/am62ax_evm.h
+++ b/include/configs/am62ax_evm.h
@@ -12,10 +12,6 @@
 #include 
 #include 
 
-/* DDR Configuration */
-#define CFG_SYS_SDRAM_BASE10x88000
-
-
 /* Now for the remaining common defines */
 #include 
 
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 811dc0ff1a8..64458ebb4b8 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -14,9 +14,6 @@
 #include 
 #include 
 
-/* DDR Configuration */
-#define CFG_SYS_SDRAM_BASE10x88000
-
 /* Now for the remaining common defines */
 #include 
 
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index ea39d1bf824..c26438c8684 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -11,8 +11,6 @@
 
 #include 
 
-/* DDR Configuration */
-#define CFG_SYS_SDRAM_BASE10x88000
 /* FLASH Configuration */
 #define CFG_SYS_FLASH_BASE 0x0
 
diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h
index 692c6bb5e42..846cfa7531c 100644
--- a/include/configs/j721s2_evm.h
+++ b/include/configs/j721s2_evm.h
@@ -12,9 +12,6 @@
 #include 
 #include 
 
-/* DDR Configuration */
-#define CFG_SYS_SDRAM_BASE10x88000
-
 /* SPL Loader Configuration */
 #if defined(CONFIG_TARGET_J721S2_A72_EVM)
 #define CFG_SYS_UBOOT_BASE 0x5028
-- 
2.39.2

Re: [PATCH v2 2/4] arm: mach-k3: Do not map ATF and OPTEE regions in MMU

[Andrew Davis]

On 11/29/23 2:00 AM, Manorit Chawdhry wrote:

Hi Andrew,

On 28/11/23 22:35, Andrew Davis wrote:

ATF and OPTEE regions may be firewalled from non-secure entities. To
prevent access to this area we leave a hole there in the MMU map. This
is the same idea as [0] but we complete that patch by adding the same
for AM65, J721e, J7200, and J721s2 here.

[0] commit 0688ff3ae23c ("arm: mach-k3: arm64-mmu: do not map ATF and OPTEE regions 
in A53 MMU")

Signed-off-by: Andrew Davis 
---
  arch/arm/mach-k3/arm64-mmu.c | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index d872ed714c4..5c858ae0f84 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -24,7 +24,7 @@ struct mm_region am654_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
-   .size = 0x2000UL,
+   .size = 0x1e78UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -75,7 +75,7 @@ struct mm_region j7200_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
-   .size = 0x2000UL,
+   .size = 0x1e78UL,


ATF lies 0x7000 for j7 devices.

For reference.

configs/am62ax_evm_a53_defconfig:8:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e78
  
configs/verdin-am62_a53_defconfig:11:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e78
  
configs/am64x_evm_a53_defconfig:11:8:CONFIG_K3_ATF_LOAD_ADDR=0x701c  -> This

is also different



configs/am62x_beagleplay_a53_defconfig:9:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e78
configs/am62x_evm_a53_defconfig:8:8:CONFIG_K3_ATF_LOAD_ADDR=0x9e78

and rest all devices use 0x7000

OP-TEE is consistent across all SoCs and lies at 9e80 and I can see that
removing the map after 9e78 does
handle that but am not sure if I see the ATF being unified with all this flow.



We don't need to carve out ATF in our MMU map when it lives in SRAM as
SRAM is already marked non-caching/device memory and so shouldn't be
touched by U-Boot. Only when in DRAM do we do this carveout, and for all
platforms that have ATF in DRAM it lies at 0x9e78. So we make the
MMU gap start at this location.

But as you have noticed, for platforms that keep ATF in SRAM this hole in
DRAM is slightly larger than it needs to be (but that doesn't hurt anything,
the OP-TEE hole is ~24MB and this just makes it just 128KB larger. This is
DRAM so no one will care about 128KB).

The benefit of unconditionally leaving the MMU gap in DRAM cover where ATF
would have been, even on SRAM platforms, is it makes the memory map unified
across all platforms allowing us to combine them as in patch [4/4].

Andrew


Regards,
Manorit


.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -123,7 +123,7 @@ struct mm_region j721e_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
-   .size = 0x2000UL,
+   .size = 0x1e78UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -180,7 +180,13 @@ struct mm_region j721s2_mem_map[] = {
}, {
.virt = 0x8000UL,
.phys = 0x8000UL,
-   .size = 0x8000UL,
+   .size = 0x1e78UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0xa000UL,
+   .phys = 0xa000UL,
+   .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {

[PATCH v2 3/4] arm: mach-k3: Remove non-cached memory map areas

[Andrew Davis]

All normal memory areas should be mapped as such.

We added these un-cached holes in our memory map to hack around the
remoteproc driver missing the proper cache maintenance operations.

The problem is having these non-cached memory map areas causes stability
issues later in system operation due to the nature of the K3 coherency
architecture. Plus these are board specific carveouts and instead
should have been added at the board level, not here in the SoC common
code area.

Remove these non-cached memory map areas.

Signed-off-by: Andrew Davis 
Reviewed-by: Nishanth Menon 
Tested-by: Nishanth Menon 
---
 arch/arm/mach-k3/arm64-mmu.c | 30 +++---
 1 file changed, 3 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index 5c858ae0f84..2c2d75d3f41 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@ -30,13 +30,7 @@ struct mm_region am654_mem_map[] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
-   .size = 0x0210UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_INNER_SHARE
-   }, {
-   .virt = 0xa210UL,
-   .phys = 0xa210UL,
-   .size = 0x5df0UL,
+   .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -81,13 +75,7 @@ struct mm_region j7200_mem_map[] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
-   .size = 0x0480UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_NON_SHARE
-   }, {
-   .virt = 0xa480UL,
-   .phys = 0xa480UL,
-   .size = 0x5b80UL,
+   .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -129,13 +117,7 @@ struct mm_region j721e_mem_map[] = {
}, {
.virt = 0xa000UL,
.phys = 0xa000UL,
-   .size = 0x1bc0UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_NON_SHARE
-   }, {
-   .virt = 0xbbc0UL,
-   .phys = 0xbbc0UL,
-   .size = 0x4440UL,
+   .size = 0x6000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
@@ -151,12 +133,6 @@ struct mm_region j721e_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   }, {
-   .virt = 0x4d8000UL,
-   .phys = 0x4d8000UL,
-   .size = 0x000200UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
-PTE_BLOCK_INNER_SHARE
}, {
/* List terminator */
0,
-- 
2.39.2