Re: [PATCH] arm: dts: k3-j722s-r5-evm: Add LPDDR4 4000 MT/s configs
On 10/17/2024 2:01 AM, Bryan Brattlof wrote: Hi Vaishnav! On October 16, 2024 thus sayeth Vaishnav Achath: Add the latest 4000 MT/s DDR config generated by Jacinto7_DDRSS_RegConfigTool Rev 0.11 for J722S , make it the default config and update A53 default clock to 1.4 GHz matching the default speed grade (K). Signed-off-by: Vaishnav Achath --- memtester logs on J722S EVM: https://gist.github.com/vaishnavachath/4174d02e0338e53594015dfdd321a8ef The max frequency was not bumped up to 4000 MT/s initially since the characterization results were not available. All the devices populated on J722S EVM and Beagle Y AI is speed grade K. arch/arm/dts/k3-j722s-ddr-lp4-50-4000.dtsi | 2797 arch/arm/dts/k3-j722s-r5-evm.dts |4 +- 2 files changed, 2799 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/k3-j722s-ddr-lp4-50-4000.dtsi ... diff --git a/arch/arm/dts/k3-j722s-r5-evm.dts b/arch/arm/dts/k3-j722s-r5-evm.dts index aff83cd5d9..46f420d510 100644 --- a/arch/arm/dts/k3-j722s-r5-evm.dts +++ b/arch/arm/dts/k3-j722s-r5-evm.dts @@ -7,7 +7,7 @@ #include "k3-j722s-evm.dts" #include "k3-j722s-evm-u-boot.dtsi" -#include "k3-j722s-ddr-lp4-50-3733.dtsi" +#include "k3-j722s-ddr-lp4-50-4000.dtsi" Do we need to keep the 3733MT/s config around anymore? I suggest to keep this, in case someone want to use lower grade SOC then they can just change #include instead of doing regeneration of whole config ~Bryan
Re: [PATCH] boardf: Modify DRAM message
On 10/10/2024 12:39 PM, Neha Malcom Francis wrote:
The message "DRAM: 2 GiB (effective 32 GiB)" can be a little confusing,
modify the message to show exactly what is meant:
"DRAM: 2 GiB (available for U-Boot out of total 32 GiB)"
Still confusing for me atleast :) can this be
"DRAM: 2 GiB available for U-Boot, out of total 32 GiB"
Signed-off-by: Neha Malcom Francis
---
common/board_f.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 154675d0e40..b7add8f7d3d 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -254,7 +254,7 @@ static int show_dram_config(void)
print_size(gd->ram_size, "");
if (!sizes_near(gd->ram_size, size)) {
- printf(" (effective ");
+ printf(" (available for U-Boot out of total ");
print_size(size, ")");
}
board_add_ram_info(0);
Re: [PATCH 1/4] mach-k3: common.c: Add dma device remove in spl exit
Hi Prasanth,
On 10/6/2024 2:26 PM, Prasanth Mantena wrote:
On 20:09-20241004, Kumar, Udit wrote:
Hi Udit,
Hi Prasant,
Thanks for series,
Could we update the subject of patch something like
Remove dma device in spl exit, Sorry but
Add dma device remove in spl exit looks little confusing , are we adding or
removing ?
Understood. Should've been more simpler like "Remove dma device in spl
exit". Will update in next version.
On 10/4/2024 6:50 PM, Prasanth Babu Mantena wrote:
[..]
Are you thinking to have DMA device optional ?
Not really. Sorry, but didn't understand the question completely here.
+ rc = uclass_find_device(UCLASS_DMA, 0, &dev);
+ if (!rc && dev) {
I meant , here if there is some return code or device is not found then
at user level there is no notification.
May be adding some error print in case either some return code or device is NULL
will help to user know, that DMA was not cleaned properly.
Second question, if we enabled multiple DMAs in u-boot, then would you like
to remove all ?
Considering this function is specific to k3, here we have channel
allocation done in probe and there is a need to clean that channel
resources which has been done in remove function in this series, call
that remove function here. If there are such allocations done for other
dma devices as well and have their remove functions implemented, then
they should consider adding those as well here. I don't think there is
any such case with other dmas.
Understood this is k3 specific , But here i meant multiple dma devices
like udma, pdma etc.
+ if (!rc && dev) {
+ rc = device_remove(dev, DM_REMOVE_NORMAL);
+ if (rc)
+ pr_warn("Cannot remove dma device '%s' (err=%d)\n",
+ dev->name, rc);
+ }
+}
+
void spl_board_prepare_for_boot(void)
{
+#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
dcache_disable();
+#endif
Please suggest , why we are protecting dcache_disable with flags ?
This is carry forward which was already present. This patch removes
the protection from whole spl_board_prepare_for_boot() function to
dcache_disable() only. This alone looks like it has been added in this
patch, but if we see the whole snippet, it can be understood well.
Thanks
Thanks,
Prasanth
+#if IS_ENABLED(CONFIG_SPL_DMA) && IS_ENABLED(CONFIG_SPL_DM_DEVICE_REMOVE)
+ k3_dma_remove();
+#endif
}
+#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
void spl_board_prepare_for_linux(void)
{
dcache_disable();
Re: [PATCH 4/4] dma: ti: k3-udma: Move DMA channel[0] allocation to probe and add udma_remove()
On 10/4/2024 6:50 PM, Prasanth Babu Mantena wrote:
From: Santhosh Kumar K
Currently, the allocation of DMA channel[0] for memcpy is happening
in udma_transfer() for every transfer, which leads to a huge overhead
for each transfer, especially in case of nand page reads. So, move this
[..]
@@ -2590,6 +2565,7 @@ static int udma_probe(struct udevice *dev)
struct udevice *tmp;
struct udevice *tisci_dev = NULL;
struct udma_tisci_rm *tisci_rm = &ud->tisci_rm;
+ struct udma_chan *uc;
ofnode navss_ofnode = ofnode_get_parent(dev_ofnode(dev));
ud->match_data = (void *)dev_get_driver_data(dev);
@@ -2714,6 +2690,42 @@ static int udma_probe(struct udevice *dev)
uc_priv->supported = DMA_SUPPORTS_MEM_TO_MEM | DMA_SUPPORTS_MEM_TO_DEV;
+ uc = &ud->channels[0];
+ switch (ud->match_data->type) {
+ case DMA_TYPE_UDMA:
+ ret = udma_alloc_chan_resources(uc);
+ break;
+ case DMA_TYPE_BCDMA:
+ ret = bcdma_alloc_chan_resources(uc);
+ break;
+ default:
+ return -EINVAL;
shouldn't we treat this default case as error and do some dev_err prints ?
+ };
+
+ if (ret) {
+ dev_err(dev, " Channel 0 allocation failure %d\n", ret);
+ return ret;
No need of this ret
+ }
+
+ return 0;
do 'return ret' here
+}
+
+static int udma_remove(struct udevice *dev)
+{
+ struct udma_dev *ud = dev_get_priv(dev);
+ struct udma_chan *uc = &ud->channels[0];
+
+ switch (ud->match_data->type) {
+ case DMA_TYPE_UDMA:
+ udma_free_chan_resources(uc);
+ break;
+ case DMA_TYPE_BCDMA:
+ bcdma_free_bchan_resources(uc);
+ break;
+ default:
+ return -EINVAL;
shouldn't we treat this default case as error and do some dev_err prints ?
+ };
+
return 0;
}
@@ -2855,5 +2867,7 @@ U_BOOT_DRIVER(ti_edma3) = {
.of_match = udma_ids,
.ops= &udma_ops,
.probe = udma_probe,
+ .remove = udma_remove,
.priv_auto = sizeof(struct udma_dev),
+ .flags = DM_FLAG_OS_PREPARE,
};
Re: [PATCH 1/4] mach-k3: common.c: Add dma device remove in spl exit
Hi Prasant,
Thanks for series,
Could we update the subject of patch something like
Remove dma device in spl exit, Sorry but
Add dma device remove in spl exit looks little confusing , are we adding
or removing ?
On 10/4/2024 6:50 PM, Prasanth Babu Mantena wrote:
While exiting from spl, remove any dma device active through
spl_board_prepare_for_boot(). This is required for cleaning up
any dma channels being used in spl and avoid issues with overlapping
channel allocation in the next stage bootloaders.
Signed-off-by: Prasanth Babu Mantena
---
arch/arm/mach-k3/common.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index df48ec8d47..982dc76b00 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -28,6 +28,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -246,12 +248,31 @@ void spl_enable_cache(void)
#endif
}
-#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
+static __maybe_unused void k3_dma_remove(void)
+{
+ struct udevice *dev;
+ int rc;
+
+ rc = uclass_find_device(UCLASS_DMA, 0, &dev);
Are you thinking to have DMA device optional ?
Second question, if we enabled multiple DMAs in u-boot, then would you
like to remove all ?
+ if (!rc && dev) {
+ rc = device_remove(dev, DM_REMOVE_NORMAL);
+ if (rc)
+ pr_warn("Cannot remove dma device '%s' (err=%d)\n",
+ dev->name, rc);
+ }
+}
+
void spl_board_prepare_for_boot(void)
{
+#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
dcache_disable();
+#endif
Please suggest , why we are protecting dcache_disable with flags ?
+#if IS_ENABLED(CONFIG_SPL_DMA) && IS_ENABLED(CONFIG_SPL_DM_DEVICE_REMOVE)
+ k3_dma_remove();
+#endif
}
+#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
void spl_board_prepare_for_linux(void)
{
dcache_disable();
Re: [PATCH v3 5/7] arm: mach-k3: j721s2_init: Initialize AVS Class 0
On 10/1/2024 2:18 PM, Manorit Chawdhry wrote:
Hi Udit,
On 08:46-20240815, Kumar, Udit wrote:
On 8/13/2024 11:40 AM, Manorit Chawdhry wrote:
Initialize AVS Class 0.
Signed-off-by: Manorit Chawdhry
---
arch/arm/mach-k3/j721s2/j721s2_init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-k3/j721s2/j721s2_init.c
b/arch/arm/mach-k3/j721s2/j721s2_init.c
index 05453fcad41a..5f5961a2c17a 100644
--- a/arch/arm/mach-k3/j721s2/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2/j721s2_init.c
@@ -315,6 +315,9 @@ void do_dt_magic(void)
#ifdef CONFIG_SPL_BUILD
void board_init_f(ulong dummy)
{
+ struct udevice *dev;
+ int ret;
+
k3_spl_init();
#if defined(CONFIG_SPL_OF_LIST) && defined(CONFIG_TI_I2C_BOARD_DETECT)
do_dt_magic();
@@ -325,6 +328,13 @@ void board_init_f(ulong dummy)
setup_navss_nb();
setup_qos();
+
+ if (IS_ENABLED(CONFIG_CPU_V7R) && IS_ENABLED(CONFIG_K3_AVS0)) {
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(k3_avs),
+ &dev);
Can we remove this ret, Something like
I would say we can let this remain, general convention of this file is
to have ret itself, I know it's only used in one place as of now but I
feel keeping it consistent is better IMO.
I still suggest to remove non needed variable .
To make it consistent , please think to change at other places :)
Regards,
Manorit
Re: [PATCH v3 6/7] arm: dts: j721s2: Add VTM node in R5
On 10/1/2024 4:27 PM, Manorit Chawdhry wrote:
Hi Udit,
On 08:47-20240815, Kumar, Udit wrote:
On 8/13/2024 11:40 AM, Manorit Chawdhry wrote:
Add bootph-pre-ram property to VTM node and the pmic node.
Signed-off-by: Manorit Chawdhry
---
arch/arm/dts/k3-j721s2-r5-common-proc-board.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
index e92b1917df4e..506ad9b7910d 100644
--- a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
@@ -10,3 +10,12 @@
#include "k3-j721s2-ddr.dtsi"
#include "k3-j721s2-common-proc-board-u-boot.dtsi"
#include "k3-j721s2-r5.dtsi"
+
+&tps659411 {
+ bootph-pre-ram;
+};
Ok for now. but do you plan to add this bootph-pre-ram in Linux DT too ?
Yes, it's taken as a part of the series that's being run parallely in
Linux [0]
[0]:
https://lore.kernel.org/linux-arm-kernel/20240814-b4-upstream-bootph-all-v4-0-f2b462000...@ti.com/
Thanks for confirmation,
For this patch, Please use
Reviewed-by: Udit Kumar
Regards,
Manorit
Re: [PATCH v3 3/7] arm: dts: k3-j7*-r5: Add MPU clock in clocks property
On 10/1/2024 2:15 PM, Manorit Chawdhry wrote: Hi Udit, On 08:32-20240815, Kumar, Udit wrote: On 8/13/2024 11:40 AM, Manorit Chawdhry wrote: MPU clock had been missing. Distinguish multiple clocks with clock-names and add MPU clock as well. Signed-off-by: Manorit Chawdhry --- arch/arm/dts/k3-am69-r5-sk.dts | 3 ++- arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 3 ++- arch/arm/dts/k3-j721e-r5.dtsi | 3 ++- arch/arm/dts/k3-j721s2-r5.dtsi | 3 ++- arch/arm/dts/k3-j784s4-r5-evm.dts | 3 ++- 5 files changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/arm/dts/k3-am69-r5-sk.dts b/arch/arm/dts/k3-am69-r5-sk.dts index f177f563527f..9bbf76d8bf35 100644 --- a/arch/arm/dts/k3-am69-r5-sk.dts +++ b/arch/arm/dts/k3-am69-r5-sk.dts @@ -26,7 +26,8 @@ power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>, <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; - clocks = <&k3_clks 61 0>; + clocks = <&k3_clks 61 0>, <&k3_clks 202 0>; Thanks for catching this Could we think of having SOC specific R5 dt , So that we don't need to update such SOC information at each board level Similar to what is done (k3-j721e-r5.dtsi) Seems like a good idea but I believe that it could be a separate activity regardless of this series, it can be taken up later. Current series is putting it in the respective files so should be a non blocker. another series is ok for this change Regards, Manorit
Re: [PATCH] dts: beagleboneai64: Add boothph in chipid node
On 9/17/2024 10:24 PM, Tom Rini wrote:
On Tue, Sep 17, 2024 at 01:43:29PM +0530, Udit Kumar wrote:
beagleboneai64 boot was broken after OF_UPSTREAM support for
J721E SOC.
So add bootph in chipid node similar to other boards of
this SOC.
Fixes: 46bb1405b461 ("arm: dts: k3-j721e: Move to OF_UPSTREAM")
Reported-by: Robert Nelson
Signed-off-by: Udit Kumar
---
Boot logs
https://gist.github.com/uditkumarti/32604960dec65401cde8979e51160ba7
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
index 884f44239e..27851b7d08 100644
--- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
@@ -64,6 +64,10 @@
bootph-all;
};
+&chipid {
+ bootph-all;
+};
+
Someone is upstreaming both of these, right?
Yes, patch posted for kernel by Manorit,
Please see
https://lore.kernel.org/all/20240814-b4-upstream-bootph-all-v4-4-f2b462000...@ti.com/
But as of now, this node is defined as bootph-all for other J721E boards
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi:&chipid {
arch/arm/dts/k3-j721e-sk-u-boot.dtsi:&chipid {
Re: [PATCH RFC/RFT v2 0/4] k3-j784s4-r5-evm: Enable ESMs and related PMIC
Andrew Thanks, On 9/11/2024 11:09 PM, Andrew Halaney wrote: NOTE: this relies on the linked devicetree changes to land in Linux first and get synced here, otherwise the board will fail to boot! I'm leaving this as a RFC/RFT at this time for that reason until things get merged and synced over (if there's a faster way to get that done please let me know, otherwise I'll be patient. Maybe the cherry-picking described over at https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing would be appropriate to do *in* this series after that is merged in Linux?). This enables the ESMs and the associated PMIC. Programming these bits is a requirement to make the watchdog actually reset the board. I've tested this series (with the linked change) on the k3-j784s4-evm, but not its sibling the k3-am69-sk. I'd appreciate at a minimum someone to test on that platform to ensure this doesn't break boot. Link: https://lore.kernel.org/lkml/20240911-j784s4-tps6594-bootph-v2-0-a83526264...@redhat.com/ Signed-off-by: Andrew Halaney --- Changes in v2: - Loop over ESMs, only configure if prior was successful as without all of them they're not useful (Udit) - Add am69-sk PMIC ESM node (Udit) - Link to v1: https://lore.kernel.org/r/20240906-j784s4-esm-enable-v1-0-b83b17d5a...@redhat.com LGTM For AM69, please use Tested-by: Udit Kumar Test logs (WDT working as expected) after locally applying patch https://lore.kernel.org/lkml/20240911-j784s4-tps6594-bootph-v2-0-a83526264...@redhat.com/ into u-boot DTS. https://gist.github.com/uditkumarti/3ec9afac94c081d09515b66b7ae6c0e5 --- Andrew Halaney (2): arm: dts: k3-am69-r5-evm: Add the PMIC ESM node configs: j784s4_evm_r5: Enable ESM related configs Keerthy (1): board: ti: j784s4: Initialize the ESM & PMIC ESM Neha Malcom Francis (1): arm: dts: k3-j784s4-r5-evm: Add the PMIC ESM node arch/arm/dts/k3-am69-r5-sk.dts| 7 +++ arch/arm/dts/k3-j784s4-r5-evm.dts | 7 +++ board/ti/j784s4/evm.c | 24 configs/j784s4_evm_r5_defconfig | 7 +++ 4 files changed, 45 insertions(+) --- base-commit: 1630ff26cc960439b5949b80cfc604a2c8aa47dd change-id: 20240906-j784s4-esm-enable-4c4f698fe7c4 Best regards,
Re: [PATCH RFC/RFT 2/3] board: ti: j784s4: Initialize the ESM & PMIC ESM
On 9/10/2024 10:52 PM, Andrew Halaney wrote:
On Sat, Sep 07, 2024 at 11:12:05AM GMT, Kumar, Udit wrote:
Hi Andrew,
On 9/7/2024 2:54 AM, Andrew Halaney wrote:
From: Keerthy
Initialize the ESM & PMIC ESM. This allows things like
the watchdog to reset the board when tripped.
Signed-off-by: Keerthy
Signed-off-by: Neha Malcom Francis
Link:
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/board/ti/j784s4/evm.c?h=ti-u-boot-2024.04&id=9d8b40958ce792808bc571d828197dbc2e7978d6
[halaney: add a line to the commit message, include header]
Signed-off-by: Andrew Halaney
---
board/ti/j784s4/evm.c | 28
1 file changed, 28 insertions(+)
diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
index 548dbd5925d..a0ef3a44536 100644
--- a/board/ti/j784s4/evm.c
+++ b/board/ti/j784s4/evm.c
@@ -7,6 +7,7 @@
*
*/
+#include
#include
#include
#include
@@ -72,4 +73,31 @@ int board_late_init(void)
void spl_board_init(void)
{
+ struct udevice *dev;
+ int ret;
+
+ if (IS_ENABLED(CONFIG_ESM_K3)) {
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@70",
+ &dev);
+ if (ret)
+ printf("MISC init for esm@70 failed: %d\n", ret);
+
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@4080",
+ &dev);
+ if (ret)
+ printf("MISC init for esm@4080 failed: %d\n", ret);
+
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@4208",
+ &dev);
+ if (ret)
+ printf("MISC init for esm@4208 failed: %d\n", ret);
+ }
Thanks for patch ,
IMO, if one of esm is failing then we can skip other esm probe,
+
+ if (IS_ENABLED(CONFIG_ESM_PMIC)) {
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_DRIVER_GET(pmic_esm),
+ &dev);
Same here if esm probe is successful then only we should probe pmic_esm.
Reason is , if any of probe is failing functionality will not work and
there is no point to probe devices, if function is not working.
Any preference on how this is handled? I was going to do something like:
if (IS_ENABLED(CONFIG_ESM_K3)) {
ret = uclass_get_device_by_name(UCLASS_MISC, "esm@70",
&dev);
if (ret) {
printf("MISC init for esm@70 failed: %d\n", ret);
return;
}
What I have in mind kind of having string array with name , as
esm@70, esm@4080 and esm@4208
if (IS_ENABLED(CONFIG_ESM_K3)) {
for(i = 0 ; i< 2; i++) {
ret = uclass_get_device_by_name(UCLASS_MISC, STRING[i],
&dev);
if(ret) {
printf("MISC init for %s failed: %d\n", ret, STRING[i]);
break;
}
}
}
if (IS_ENABLED(CONFIG_ESM_PMIC) && ret == 0) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(pmic_esm),
&dev);
}
...
ret = uclass_get_device_by_name(UCLASS_MISC, "esm@4080",
&dev);
...
if (IS_ENABLED(CONFIG_ESM_PMIC)) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(pmic_esm),
&dev);
if (ret) {
printf("ESM PMIC init failed: %d\n", ret);
return;
}
}
}
but wasn't sure if a err_esm label and goto would be more in line with
what you imagined? Let me know otherwise I'll just submit this version
tomorrow or so.
Thanks,
Andrew
Re: [PATCH RFC/RFT 0/3] k3-j784s4-r5-evm: Enable ESMs and related PMIC
Hi Andrew On 9/7/2024 2:54 AM, Andrew Halaney wrote: This enables the ESMs and the associated PMIC. Programming these bits is a requirement to make the watchdog actually reset the board. Note, this relies on the linked devicetree changes to land in Linux first and get synced here, otherwise the board will fail to boot! I've tested this series (with the linked change) on the k3-j784s4-evm, but not its sibling the k3-am69-sk. I'd appreciate at a minimum someone to test on that platform to ensure this doesn't break boot. For am69-sk, I need to add esm node on top of your patches Also, as commented in Linux patch series, boothph is enough in one child node with these two changes , tested on AM69 for watchdog reset. https://gist.github.com/uditkumarti/e5666b5623c3a78e23548fbfcbe813c8 upto line https://gist.github.com/uditkumarti/e5666b5623c3a78e23548fbfcbe813c8#file-gistfile1-txt-L28, Patch added for test Line https://gist.github.com/uditkumarti/e5666b5623c3a78e23548fbfcbe813c8#file-gistfile1-txt-L1385 to see watchdog reset action Link: https://lore.kernel.org/all/20240906-j784s4-tps6594-bootph-v1-0-c5b58d43b...@redhat.com/ Signed-off-by: Andrew Halaney --- Andrew Halaney (1): configs: j784s4_evm_r5: Enable ESM related configs Keerthy (1): board: ti: j784s4: Initialize the ESM & PMIC ESM Neha Malcom Francis (1): arm: dts: k3-j784s4-r5-evm: Add the PMIC ESM node arch/arm/dts/k3-j784s4-r5-evm.dts | 7 +++ board/ti/j784s4/evm.c | 28 configs/j784s4_evm_r5_defconfig | 7 +++ 3 files changed, 42 insertions(+) --- base-commit: 1630ff26cc960439b5949b80cfc604a2c8aa47dd change-id: 20240906-j784s4-esm-enable-4c4f698fe7c4 Best regards,
Re: [PATCH RFC/RFT 2/3] board: ti: j784s4: Initialize the ESM & PMIC ESM
Hi Andrew,
On 9/7/2024 2:54 AM, Andrew Halaney wrote:
From: Keerthy
Initialize the ESM & PMIC ESM. This allows things like
the watchdog to reset the board when tripped.
Signed-off-by: Keerthy
Signed-off-by: Neha Malcom Francis
Link:
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/board/ti/j784s4/evm.c?h=ti-u-boot-2024.04&id=9d8b40958ce792808bc571d828197dbc2e7978d6
[halaney: add a line to the commit message, include header]
Signed-off-by: Andrew Halaney
---
board/ti/j784s4/evm.c | 28
1 file changed, 28 insertions(+)
diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c
index 548dbd5925d..a0ef3a44536 100644
--- a/board/ti/j784s4/evm.c
+++ b/board/ti/j784s4/evm.c
@@ -7,6 +7,7 @@
*
*/
+#include
#include
#include
#include
@@ -72,4 +73,31 @@ int board_late_init(void)
void spl_board_init(void)
{
+ struct udevice *dev;
+ int ret;
+
+ if (IS_ENABLED(CONFIG_ESM_K3)) {
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@70",
+ &dev);
+ if (ret)
+ printf("MISC init for esm@70 failed: %d\n", ret);
+
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@4080",
+ &dev);
+ if (ret)
+ printf("MISC init for esm@4080 failed: %d\n", ret);
+
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@4208",
+ &dev);
+ if (ret)
+ printf("MISC init for esm@4208 failed: %d\n", ret);
+ }
Thanks for patch ,
IMO, if one of esm is failing then we can skip other esm probe,
+
+ if (IS_ENABLED(CONFIG_ESM_PMIC)) {
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_DRIVER_GET(pmic_esm),
+ &dev);
Same here if esm probe is successful then only we should probe pmic_esm.
Reason is , if any of probe is failing functionality will not work and
there is no point to probe devices, if function is not working.
+ if (ret)
+ printf("ESM PMIC init failed: %d\n", ret);
+ }
}
Re: [RFC PATCH 4/6] drivers: misc: k3_bist: Add K3 BIST driver
On 9/5/2024 3:11 PM, Neha Malcom Francis wrote:
On 04/09/24 10:35, Kumar, Udit wrote:
On 9/3/2024 5:14 PM, Neha Malcom Francis wrote:
Add a driver for the BIST module which currently includes support for
BIST IPs that trigger PBIST (Memory BIST).
Signed-off-by: Neha Malcom Francis
---
drivers/misc/Kconfig | 8 +
drivers/misc/Makefile | 1 +
drivers/misc/k3_bist.c | 507 ++
drivers/misc/k3_bist_static_data.h | 551
+
4 files changed, 1067 insertions(+)
create mode 100644 drivers/misc/k3_bist.c
create mode 100644 drivers/misc/k3_bist_static_data.h
[...]
+
In general, few macro's name are too long
many places hard-coded values are used, please consider to move to macro
driver looks to be j784s4 specific including header files ,
please see, if we can make this generic driver.
I've put SoC specific (J784S4 right now) data protected with SoC
specific configs in k3_bist_static_data.h; the hardcoded values are a
sequence for triggering a specific test, whatever is generic and known
I have put as a macro, however I'll try to better understand the
sequence if I can put them as macros.
+#include "k3_bist_static_data.h"
+
[...]
Please consider to rename function name as per description above
something like
check_pbist_results_of_mcu_domain,, if you agree
Also give more context, I believe, ROM runs BIST on MCU domain,
Please consider to mention, if you want
Yes will do!
+{
+ bool is_done, timed_out;
+ u32 mask;
+ u32 post_reg_val, shift;
+
+ /* Read HW POST status register */
+ post_reg_val = readl(WKUP_CTRL_MMR0_BASE +
WKUP_CTRL_MMR_CFG0_WKUP_POST_STAT);
+
+ /* Check if HW POST PBIST was performed */
+ shift =
WKUP_CTRL_MMR_CFG0_WKUP_POST_STAT_POST_MCU_PBIST_DONE_SHIFT;
+ is_done = (((post_reg_val >> shift) & 0x1u) == 0x1u) ?
(bool)true : (bool)false;
+
+ if (!is_done) {
+ /* HW POST: PBIST not completed, check if it timed out */
+ shift =
WKUP_CTRL_MMR_CFG0_WKUP_POST_STAT_POST_MCU_PBIST_TIMEOUT_SHIFT;
Too long macro name
+ timed_out = (((post_reg_val >> shift) & 0x1u) == 0x1u) ?
(bool)true : (bool)false;
+
+ if (!timed_out) {
+ debug("%s: PBIST was not performed at all on this
device for this core\n",
+ __func__);
+ return -EINVAL;
This is error no ? , move to dev_err instead of debug
The return in k3_bist_probe throws a dev_err saying HW POST failed to
run successfully. So these were added as debugs in case the end user
wants to know exact cause of failure, I can move it as a dev_err as well.
ok, thanks
+ } else {
+ debug("%s: PBIST was attempted but timed out for this
section\n", __func__);
+ return -ETIMEDOUT;
This is error no ? , move to dev_err instead of debug .
What next, reboot SOC or just continue booting in case of error
This is also something I wanted this RFC to address, I prefer
rebooting SoC if HW POST fails. HW POST is performed by ROM based on
certain switch settings, which implies that an end-user wants this
check done if selected. And if it fails on the MCU domain itself, I do
not think we should continue.
Ok, if you are saying BIST in MCU domain in done based upon some switch
settings, then please put that switch logic here .
Reading code above looks, BIST run always
if (!is_done) {
+ /* HW POST: PBIST not completed, check if it timed out */
+ } else {
+ /* HW POST: PBIST was completed on this device, check the
result */
So now have three conditions,
1) BIST not attempted
2) BIST ran and passed
3) BIST ran and failed
For 1) condition, please see if you can read some register or switch
settings or so.
For 3) , as default we should hang.. In case users wants to continue on
failure they can modify u-boot source to do so :)
[..]
isn't some tisci call are ok to turn off the CPUs.
DM (Device Manager) firmware, responsible for power management is not
up at this point in the boot flow (R5 SPL). Thus TISCI calls that turn
on/turn off clocks and power domains are not available and we rely on
the primitive clk-k3.c and ti-power-domain.c drivers to do this for
us. As seen below, using the uclass functions which internally calls
these primitive drivers would be the way to go.
But DM is kind implemented by dev-data and dev-clk logic ?
For few calls DM just talk to TIFS, which are available at this point.
I request to check once, if possible
I could have used the remoteproc framework to do this but currently
the rproc driver uses TISCI firmware calls from DM and as mentioned
above that's not possible.
We should probably target modifying our remoteproc driver to use these
generic uclass APIs instead of direct TISCI calls.
Ok,
[...]
+ udelay(1000);
+
Re: [RFC PATCH 4/6] drivers: misc: k3_bist: Add K3 BIST driver
On 9/3/2024 5:14 PM, Neha Malcom Francis wrote:
Add a driver for the BIST module which currently includes support for
BIST IPs that trigger PBIST (Memory BIST).
Signed-off-by: Neha Malcom Francis
---
drivers/misc/Kconfig | 8 +
drivers/misc/Makefile | 1 +
drivers/misc/k3_bist.c | 507 ++
drivers/misc/k3_bist_static_data.h | 551 +
4 files changed, 1067 insertions(+)
create mode 100644 drivers/misc/k3_bist.c
create mode 100644 drivers/misc/k3_bist_static_data.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..8e28a93d74c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -664,6 +664,14 @@ config ESM_K3
help
Support ESM (Error Signaling Module) on TI K3 SoCs.
+config K3_BIST
+ bool "Enable K3 BIST driver"
+ depends on ARCH_K3
+ help
+ Support BIST (Built-In Self Test) module on TI K3 SoCs. This driver
+ supports running both PBIST (Memory BIST) and LBIST (Logic BIST) on
+ a region or IP in the SoC.
+
config MICROCHIP_FLEXCOM
bool "Enable Microchip Flexcom driver"
depends on MISC
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..15c5c4810dd 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_JZ4780_EFUSE) += jz4780_efuse.o
obj-$(CONFIG_MICROCHIP_FLEXCOM) += microchip_flexcom.o
obj-$(CONFIG_K3_AVS0) += k3_avs.o
obj-$(CONFIG_ESM_K3) += k3_esm.o
+obj-$(CONFIG_K3_BIST) += k3_bist.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
diff --git a/drivers/misc/k3_bist.c b/drivers/misc/k3_bist.c
new file mode 100644
index 000..a4728376b73
--- /dev/null
+++ b/drivers/misc/k3_bist.c
@@ -0,0 +1,507 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments' BIST (Built-In Self-Test) driver
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Neha Malcom Francis
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
In general, few macro's name are too long
many places hard-coded values are used, please consider to move to macro
driver looks to be j784s4 specific including header files ,
please see, if we can make this generic driver.
+#include "k3_bist_static_data.h"
+
+/* PBIST Timeout Value */
+#define PBIST_MAX_TIMEOUT_VALUE1
+
+/**
+ * struct k3_bist_privdata - K3 BIST structure
+ * @dev: device pointer
+ * @base: base of register set
+ * @instance: PBIST instance number
+ * @intr_num: corresponding interrupt ID of the PBIST instance
+ */
+struct k3_bist_privdata {
+ struct udevice *dev;
+ void *base;
+ u32 instance;
+ u32 intr_num;
+};
+
+static struct k3_bist_privdata *k3_bist_priv;
+
+/**
+ * pbist_run_post_pbist_check() - Check POST results
+ *
+ * Function to check whether HW Power-On Self Test, i.e. POST has run
+ * successfully on the MCU domain.
+ *
+ * Return: 0 if all went fine, else corresponding error.
+ */
+int pbist_run_post_pbist_check(void)
Please consider to rename function name as per description above
something like
check_pbist_results_of_mcu_domain,, if you agree
Also give more context, I believe, ROM runs BIST on MCU domain, Please
consider to mention, if you want
+{
+ bool is_done, timed_out;
+ u32 mask;
+ u32 post_reg_val, shift;
+
+ /* Read HW POST status register */
+ post_reg_val = readl(WKUP_CTRL_MMR0_BASE +
WKUP_CTRL_MMR_CFG0_WKUP_POST_STAT);
+
+ /* Check if HW POST PBIST was performed */
+ shift = WKUP_CTRL_MMR_CFG0_WKUP_POST_STAT_POST_MCU_PBIST_DONE_SHIFT;
+ is_done = (((post_reg_val >> shift) & 0x1u) == 0x1u) ? (bool)true :
(bool)false;
+
+ if (!is_done) {
+ /* HW POST: PBIST not completed, check if it timed out */
+ shift =
WKUP_CTRL_MMR_CFG0_WKUP_POST_STAT_POST_MCU_PBIST_TIMEOUT_SHIFT;
Too long macro name
+ timed_out = (((post_reg_val >> shift) & 0x1u) == 0x1u) ?
(bool)true : (bool)false;
+
+ if (!timed_out) {
+ debug("%s: PBIST was not performed at all on this device for
this core\n",
+ __func__);
+ return -EINVAL;
This is error no ? , move to dev_err instead of debug
+ } else {
+ debug("%s: PBIST was attempted but timed out for this
section\n", __func__);
+ return -ETIMEDOUT;
This is error no ? , move to dev_err instead of debug .
What next, reboot SOC or just continue booting in case of error
+ }
+ } else {
+ /* HW POST: PBIST was completed on this device, check the
result */
+ mask =
WKUP_CTRL_MM
Re: [RFC PATCH 3/6] arm: dts: k3-j784s4-main: Add clock and power domains for MAIN_R5_2_x
On 9/3/2024 5:13 PM, Neha Malcom Francis wrote:
Add bootph-pre-ram as well as the clocks and power-domains for
MAIN_R5_2_x. This ensures that LPSC sets the appropriate power and clock
and allows for BIST to turn the cores on and off for running the
self-test at R5 SPL stage.
Signed-off-by: Neha Malcom Francis
---
dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
b/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
index 5d9b0b6b59d..42dbf3083e1 100644
--- a/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
+++ b/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
@@ -1897,6 +1897,7 @@
ranges = <0x590 0x00 0x590 0x2>,
<0x5a0 0x00 0x5a0 0x2>;
power-domains = <&k3_pds 338 TI_SCI_PD_EXCLUSIVE>;
+ bootph-pre-ram;
main_r5fss2_core0: r5f@590 {
compatible = "ti,j721s2-r5f";
@@ -1911,6 +1912,10 @@
ti,atcm-enable = <1>;
ti,btcm-enable = <1>;
ti,loczrama = <1>;
+ clocks = <&k3_clks 343 0>;
+ power-domains = <&k3_pds 343 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 343 0>;
+ bootph-pre-ram;
};
main_r5fss2_core1: r5f@5a0 {
@@ -1926,6 +1931,10 @@
ti,atcm-enable = <1>;
ti,btcm-enable = <1>;
ti,loczrama = <1>;
+ clocks = <&k3_clks 344 0>;
+ power-domains = <&k3_pds 344 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 344 0>;
+ bootph-pre-ram;
Only leaf nodes should be ok with bootph-pre-ram
};
};
Re: [RFC PATCH 2/6] arm: dts: k3-j784s4-main: Add PBIST_14 node
On 9/3/2024 5:13 PM, Neha Malcom Francis wrote:
Add DT node for PBIST_14 that is responsible for triggering the BIST
self-tests for the MAIN_R5_2_x cores.
Signed-off-by: Neha Malcom Francis
---
dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
b/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
index 6a4554c6c9c..5d9b0b6b59d 100644
--- a/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
+++ b/dts/upstream/src/arm64/ti/k3-j784s4-main.dtsi
@@ -2255,4 +2255,14 @@
*/
};
};
+
+ bist_mcu14: bist@33c {
Name shouldn't be mcu, if this is included in main .
Also consider to put this is kernel as well.
+ compatible = "ti,j784s4-bist";
+ reg = <0x00 0x033c 0x00 0x400>;
+ clocks = <&k3_clks 237 7>;
+ power-domains = <&k3_pds 237 TI_SCI_PD_EXCLUSIVE>;
+ bootph-pre-ram;
+ ti,bist-instance = <14>;
+ cores-under-test = <&main_r5fss2_core0>, <&main_r5fss2_core1>;
+ };
};
Re: [RFC PATCH 1/6] arm: mach-k3: j784s4: Add clk and power support for MAIN_R5_2_x PBIST
On 9/3/2024 5:13 PM, Neha Malcom Francis wrote: Add clock and power domains for MAIN_R5_2_0, MAIN_R5_2_1 and PBIST_14. Please keep provision for other R core as well, BIST may be needed in future on those Signed-off-by: Neha Malcom Francis --- arch/arm/mach-k3/r5/j784s4/clk-data.c | 13 + arch/arm/mach-k3/r5/j784s4/dev-data.c | 7 +++ 2 files changed, 20 insertions(+) [..]
Re: [PATCH v3 7/7] configs: j721s2_evm_r5_defconfig: Add AVS Configs
On 8/13/2024 11:40 AM, Manorit Chawdhry wrote: Add AVS and PMIC regulator configs Signed-off-by: Manorit Chawdhry --- configs/am68_sk_r5_defconfig| 4 configs/j721s2_evm_r5_defconfig | 6 ++ 2 files changed, 10 insertions(+) diff --git a/configs/am68_sk_r5_defconfig b/configs/am68_sk_r5_defconfig index e9b6882c1f68..f4800ef1b8ac 100644 --- a/configs/am68_sk_r5_defconfig +++ b/configs/am68_sk_r5_defconfig @@ -5,6 +5,10 @@ CONFIG_ARCH_K3=y CONFIG_SOC_K3_J721S2=y CONFIG_TARGET_J721S2_R5_EVM=y +CONFIG_K3_AVS0=n +CONFIG_DM_REGULATOR_TPS65941=n +CONFIG_PMIC_TPS65941=n + you are having additional changes (am68 and j721s2) wrt subject of patch(j721s2) . Let other reviewer suggest on that, For Changes LGTM. CONFIG_DEFAULT_DEVICE_TREE="k3-am68-sk-r5-base-board" CONFIG_SPL_OF_LIST="k3-am68-sk-r5-base-board" CONFIG_OF_LIST="k3-am68-sk-r5-base-board" diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig index 6404b1cc3037..288379797432 100644 --- a/configs/j721s2_evm_r5_defconfig +++ b/configs/j721s2_evm_r5_defconfig @@ -112,6 +112,7 @@ CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_FS_LOADER=y CONFIG_SPL_FS_LOADER=y +CONFIG_K3_AVS0=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_SPL_MMC_HS400_SUPPORT=y CONFIG_MMC_SDHCI=y @@ -141,6 +142,11 @@ CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y CONFIG_TI_POWER_DOMAIN=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_TPS65941=y +CONFIG_DM_REGULATOR=y +CONFIG_SPL_DM_REGULATOR=y +CONFIG_DM_REGULATOR_TPS65941=y CONFIG_K3_SYSTEM_CONTROLLER=y CONFIG_REMOTEPROC_TI_K3_ARM64=y CONFIG_RESET_TI_SCI=y
Re: [PATCH v3 6/7] arm: dts: j721s2: Add VTM node in R5
On 8/13/2024 11:40 AM, Manorit Chawdhry wrote:
Add bootph-pre-ram property to VTM node and the pmic node.
Signed-off-by: Manorit Chawdhry
---
arch/arm/dts/k3-j721s2-r5-common-proc-board.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
index e92b1917df4e..506ad9b7910d 100644
--- a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts
@@ -10,3 +10,12 @@
#include "k3-j721s2-ddr.dtsi"
#include "k3-j721s2-common-proc-board-u-boot.dtsi"
#include "k3-j721s2-r5.dtsi"
+
+&tps659411 {
+ bootph-pre-ram;
+};
Ok for now. but do you plan to add this bootph-pre-ram in Linux DT too ?
+
+&wkup_vtm0 {
+ bootph-pre-ram;
+ vdd-supply-2 = <&bucka1234>;
+};
Re: [PATCH v3 5/7] arm: mach-k3: j721s2_init: Initialize AVS Class 0
On 8/13/2024 11:40 AM, Manorit Chawdhry wrote:
Initialize AVS Class 0.
Signed-off-by: Manorit Chawdhry
---
arch/arm/mach-k3/j721s2/j721s2_init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mach-k3/j721s2/j721s2_init.c
b/arch/arm/mach-k3/j721s2/j721s2_init.c
index 05453fcad41a..5f5961a2c17a 100644
--- a/arch/arm/mach-k3/j721s2/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2/j721s2_init.c
@@ -315,6 +315,9 @@ void do_dt_magic(void)
#ifdef CONFIG_SPL_BUILD
void board_init_f(ulong dummy)
{
+ struct udevice *dev;
+ int ret;
+
k3_spl_init();
#if defined(CONFIG_SPL_OF_LIST) && defined(CONFIG_TI_I2C_BOARD_DETECT)
do_dt_magic();
@@ -325,6 +328,13 @@ void board_init_f(ulong dummy)
setup_navss_nb();
setup_qos();
+
+ if (IS_ENABLED(CONFIG_CPU_V7R) && IS_ENABLED(CONFIG_K3_AVS0)) {
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(k3_avs),
+ &dev);
Can we remove this ret, Something like
if (uclass_get_device_by_driver)
printf();
if you think, ok to change
+ if (ret)
+ printf("AVS init failed: %d\n", ret);
+ }
}
#endif
Re: [PATCH v3 4/7] drivers: misc: k3_avs: Extract MPU clk and dev ID from DT
On 8/13/2024 11:40 AM, Manorit Chawdhry wrote:
Different devices have different MPU clk and dev ID. Currently it had
been hardcoded. Move it to DT based extraction.
Signed-off-by: Manorit Chawdhry
---
drivers/misc/k3_avs.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
index 568cf5b20d51..f94eee5b1c64 100644
--- a/drivers/misc/k3_avs.c
+++ b/drivers/misc/k3_avs.c
@@ -352,6 +352,9 @@ static int k3_avs_probe(struct udevice *dev)
struct k3_avs_privdata *priv;
struct vd_data *vd;
int ret;
+ ofnode node;
+ struct ofnode_phandle_args phandle_args;
+ int i = 0;
priv = dev_get_priv(dev);
priv->dev = dev;
@@ -367,6 +370,34 @@ static int k3_avs_probe(struct udevice *dev)
return -ENODEV;
for (vd = priv->vd_config->vds; vd->id >= 0; vd++) {
+ /* Get the clock and dev id for Jacinto platforms */
+ if (vd->id == J721E_VDD_MPU) {
+ node = ofnode_get_aliases_node("remoteproc1");
My suggestion will be to search node based upon compatible name am654-rproc
+ if (!ofnode_valid(node))
+ return -ENODEV;
+
+ i = ofnode_stringlist_search(node, "clock-names",
"core");
+ if (i < 0)
+ return -ENODEV;
+
+ debug("%s: i: %d\n", __func__, i);
I assume this was for your debug only, Please see if you can remove this
+
+ ret = ofnode_parse_phandle_with_args(node, "clocks",
+"#clock-cells",
+0, i,
+&phandle_args);
+ if (ret) {
+ printf("Couldn't get the clock node\n");
+ return ret;
+ }
+
+ vd->dev_id = phandle_args.args[0];
+ vd->clk_id = phandle_args.args[1];
+
+ debug("%s: MPU dev_id: %d, clk_id: %d", __func__,
+ vd->dev_id, vd->clk_id);
+ }
+
if (!(readl(AM6_VTM_DEVINFO(vd->id)) &
AM6_VTM_AVS0_SUPPORTED)) {
dev_warn(dev, "AVS-class 0 not supported for VD%d\n",
@@ -463,6 +494,12 @@ static struct vd_data j721e_vd_data[] = {
{
.id = J721E_VDD_MPU,
.opp = AM6_OPP_NOM,
+ /*
+* XXX: DEPRECATION WARNING: Around 2 u-boot versions
+*
+* These values will be picked up from DT, kept for backward
+* compatibility
+*/
.dev_id = 202, /* J721E_DEV_A72SS0_CORE0 */
.clk_id = 2, /* ARM clock */
.opps = {
Re: [PATCH v3 3/7] arm: dts: k3-j7*-r5: Add MPU clock in clocks property
On 8/13/2024 11:40 AM, Manorit Chawdhry wrote: MPU clock had been missing. Distinguish multiple clocks with clock-names and add MPU clock as well. Signed-off-by: Manorit Chawdhry --- arch/arm/dts/k3-am69-r5-sk.dts | 3 ++- arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 3 ++- arch/arm/dts/k3-j721e-r5.dtsi | 3 ++- arch/arm/dts/k3-j721s2-r5.dtsi | 3 ++- arch/arm/dts/k3-j784s4-r5-evm.dts | 3 ++- 5 files changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/arm/dts/k3-am69-r5-sk.dts b/arch/arm/dts/k3-am69-r5-sk.dts index f177f563527f..9bbf76d8bf35 100644 --- a/arch/arm/dts/k3-am69-r5-sk.dts +++ b/arch/arm/dts/k3-am69-r5-sk.dts @@ -26,7 +26,8 @@ power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>, <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; - clocks = <&k3_clks 61 0>; + clocks = <&k3_clks 61 0>, <&k3_clks 202 0>; Thanks for catching this Could we think of having SOC specific R5 dt , So that we don't need to update such SOC information at each board level Similar to what is done (k3-j721e-r5.dtsi) + clock-names = "gtc", "core"; assigned-clocks = <&k3_clks 61 0>, <&k3_clks 202 0>; assigned-clock-parents = <&k3_clks 61 2>; assigned-clock-rates = <2>, <20>; diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts index fb7e2e502392..e6da86f3cd10 100644 --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts @@ -23,7 +23,8 @@ <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>, <&k3_pds 4 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; - clocks = <&k3_clks 61 1>; + clocks = <&k3_clks 61 1>, <&k3_clks 202 2>; + clock-names = "gtc", "core"; assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>, <&k3_clks 323 0>; assigned-clock-parents= <0>, <0>, <&k3_clks 323 2>; assigned-clock-rates = <20>, <2>; diff --git a/arch/arm/dts/k3-j721e-r5.dtsi b/arch/arm/dts/k3-j721e-r5.dtsi index fd0d921272c5..688a6cf40892 100644 --- a/arch/arm/dts/k3-j721e-r5.dtsi +++ b/arch/arm/dts/k3-j721e-r5.dtsi @@ -20,7 +20,8 @@ <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>, <&k3_pds 4 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; - clocks = <&k3_clks 61 1>; + clocks = <&k3_clks 61 1>, <&k3_clks 202 2>; + clock-names = "gtc", "core"; assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>; assigned-clock-rates = <20>, <2>; ti,sci = <&dmsc>; diff --git a/arch/arm/dts/k3-j721s2-r5.dtsi b/arch/arm/dts/k3-j721s2-r5.dtsi index caf696c2d960..634676c8491e 100644 --- a/arch/arm/dts/k3-j721s2-r5.dtsi +++ b/arch/arm/dts/k3-j721s2-r5.dtsi @@ -20,7 +20,8 @@ <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>, <&k3_pds 4 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; - clocks = <&k3_clks 61 1>; + clocks = <&k3_clks 61 1>, <&k3_clks 202 0>; + clock-names = "gtc", "core"; assigned-clocks = <&k3_clks 61 1>, <&k3_clks 202 0>; assigned-clock-parents = <&k3_clks 61 3>; assigned-clock-rates = <2>, <20>; diff --git a/arch/arm/dts/k3-j784s4-r5-evm.dts b/arch/arm/dts/k3-j784s4-r5-evm.dts index bef4573d3d20..306d2007f89e 100644 --- a/arch/arm/dts/k3-j784s4-r5-evm.dts +++ b/arch/arm/dts/k3-j784s4-r5-evm.dts @@ -26,7 +26,8 @@ power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>, <&k3_pds 202 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; - clocks = <&k3_clks 61 0>; + clocks = <&k3_clks 61 0>, <&k3_clks 202 0>; + clock-names = "gtc", "core"; assigned-clocks = <&k3_clks 61 0>, <&k3_clks 202 0>; assigned-clock-parents = <&k3_clks 61 2>; assigned-clock-rates = <2>, <20>;
Re: [PATCH] configs: j784s4_evm : Increase Dynamic memory allocation size
Hi Francesco On 7/17/2024 1:35 AM, Francesco Dolcini wrote: Hello, On Mon, Jul 15, 2024 at 11:13:01PM +0530, Udit Kumar wrote: Increase malloc size to 32 MB to align with other J7 family devices. Is this needed for any specific reason? I am asking to understand if other boards using the same SOC should be updated to prevent $random_issue. In our downstream version, we are seeing an issue , while using DFU to MMC Please see https://gist.github.com/uditkumarti/b8209f61eff3154f6eb288ba63715263#file-gistfile1-txt-L82 Since DFU is not supported yet in mainline u-boot, so I avoided to mention that failure. Also this change is generic, so i thought of pushing it now instead of waiting for DFU series. Francesco
Re: [PATCH 3/6] arm: dts: k3-j7200-r5-common: Hook buckb1 to vtm supply
On 5/31/2024 6:38 PM, Aniket Limaye wrote:
From: Gowtham Tammana
Hook buckb1 to vtm avs supply.
Signed-off-by: Gowtham Tammana
Signed-off-by: Aniket Limaye
---
arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index c7086791ef8..176cc0a0fbb 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -81,6 +81,7 @@
};
&wkup_vtm0 {
+ vdd-supply-2 = <&buckb1>;
Reviewed-by: Udit Kumar
bootph-pre-ram;
};
Re: [PATCH 2/6] arm: dts: k3-j7200-r5: Fix indentation to use tabs
On 5/31/2024 6:38 PM, Aniket Limaye wrote:
To avoid whitespace diff, use tabs throughout the file for indent
Signed-off-by: Aniket Limaye
---
arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index 78d07ff4e70..c7086791ef8 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -85,16 +85,16 @@
};
&ospi0 {
-reg = <0x0 0x4704 0x0 0x100>,
- <0x0 0x5000 0x0 0x800>;
+ reg = <0x0 0x4704 0x0 0x100>,
+ <0x0 0x5000 0x0 0x800>;
};
&mcu_ringacc {
-ti,sci = <&dm_tifs>;
+ ti,sci = <&dm_tifs>;
};
&mcu_udmap {
-ti,sci = <&dm_tifs>;
+ ti,sci = <&dm_tifs>;
};
I think this is unrelated to this series ,
my suggestion will be post these changes in different patch
&tps659414 {
Re: [PATCH 1/6] arm: dts: k3-j7200-r5: Add the pmic node in R5 dt
On 5/31/2024 6:38 PM, Aniket Limaye wrote:
Add bootph-pre-ram property to the buck node in the pmic needed for
ESM error event handling.
Signed-off-by: Aniket Limaye
---
arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index fb7e2e50239..78d07ff4e70 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -96,3 +96,12 @@
&mcu_udmap {
ti,sci = <&dm_tifs>;
};
+
+&tps659414 {
+ regulators {
+ bucka1: buck1 {
+ bootph-pre-ram;
+ };
why not to add this in kernel DT
+ };
+};
+
Re: [PATCH v2 7/7] configs: j721s2_evm_r5_defconfig: Add AVS Configs
On 5/28/2024 1:43 PM, Manorit Chawdhry wrote: Add AVS and PMIC regulator configs Signed-off-by: Manorit Chawdhry --- configs/am68_sk_r5_defconfig| 4 configs/j721s2_evm_r5_defconfig | 6 ++ 2 files changed, 10 insertions(+) diff --git a/configs/am68_sk_r5_defconfig b/configs/am68_sk_r5_defconfig index e9b6882c1f68..f4800ef1b8ac 100644 --- a/configs/am68_sk_r5_defconfig +++ b/configs/am68_sk_r5_defconfig @@ -5,6 +5,10 @@ CONFIG_ARCH_K3=y CONFIG_SOC_K3_J721S2=y CONFIG_TARGET_J721S2_R5_EVM=y +CONFIG_K3_AVS0=n +CONFIG_DM_REGULATOR_TPS65941=n +CONFIG_PMIC_TPS65941=n + Extra line CONFIG_DEFAULT_DEVICE_TREE="k3-am68-sk-r5-base-board" CONFIG_SPL_OF_LIST="k3-am68-sk-r5-base-board" CONFIG_OF_LIST="k3-am68-sk-r5-base-board" diff --git a/configs/j721s2_evm_r5_defconfig b/configs/j721s2_evm_r5_defconfig index 3c958cafbe8f..f8a42a9a2ef6 100644 --- a/configs/j721s2_evm_r5_defconfig +++ b/configs/j721s2_evm_r5_defconfig @@ -111,6 +111,7 @@ CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_FS_LOADER=y CONFIG_SPL_FS_LOADER=y +CONFIG_K3_AVS0=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_SPL_MMC_HS400_SUPPORT=y CONFIG_MMC_SDHCI=y @@ -140,6 +141,11 @@ CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y CONFIG_TI_POWER_DOMAIN=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_TPS65941=y +CONFIG_DM_REGULATOR=y +CONFIG_SPL_DM_REGULATOR=y +CONFIG_DM_REGULATOR_TPS65941=y CONFIG_K3_SYSTEM_CONTROLLER=y CONFIG_REMOTEPROC_TI_K3_ARM64=y CONFIG_RESET_TI_SCI=y
Re: [PATCH v2 3/7] drivers: misc: k3_avs: Check return code while programming AVS
On 5/28/2024 1:43 PM, Manorit Chawdhry wrote: Check if AVS could not be programmed and print a warning. Signed-off-by: Manorit Chawdhry --- drivers/misc/k3_avs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c index a0d7bb7595b3..d9037b4512c6 100644 --- a/drivers/misc/k3_avs.c +++ b/drivers/misc/k3_avs.c @@ -489,7 +489,10 @@ static int k3_avs_probe(struct udevice *dev) if (vd->flags & VD_FLAG_INIT_DONE) continue; - k3_avs_program_voltage(priv, vd, vd->opp); + ret = k3_avs_program_voltage(priv, vd, vd->opp); + if (ret) + dev_warn(dev, "Could not program AVS voltage for VD%d\n", +vd->id); Could you extend print with vd->opp as well. With this change Reviewed-by: Udit Kumar } if (!device_is_compatible(priv->dev, "ti,am654-avs"))
Re: [PATCH v2 2/7] drivers: misc: k3_avs: Use soc_match_device instead of compatible.
Hi Manorit
On 5/28/2024 1:43 PM, Manorit Chawdhry wrote:
vd_data remains the same for most of the SoCs but there are some
differences in power domains and clocks that don't need a change to
compatible and can be handled at SoC level.
Change the data population logic from compatible to soc_match_device to
add support for newer devices.
Signed-off-by: Manorit Chawdhry
---
drivers/misc/k3_avs.c | 189 +++---
1 file changed, 103 insertions(+), 86 deletions(-)
diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
index 87471cc3b16a..a0d7bb7595b3 100644
--- a/drivers/misc/k3_avs.c
+++ b/drivers/misc/k3_avs.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -111,6 +112,95 @@ static u32 am6_efuse_xlate(struct k3_avs_privdata *priv,
int idx, int opp)
return 30 + 2 * val;
}
[..]
+const struct soc_attr vtm_soc_list[] = {
+ { .family = "AM65X", .data = (void *)&am654_vd_config },
+ { .family = "J721E", .data = (void *)&j721e_vd_config },
+ { .family = "J7200", .data = (void *)&j721e_vd_config },
+ {}
+};
We may end up updating this driver for each SOC family,
Even if VTM IP remain same in two SOC family.
In my view, driver should be specific to IP not specific to SOC or SOC
family.
[..]
Re: [PATCH 0/4] Adding support to load secure firmware for HS devices
On 5/21/2024 7:59 PM, Andy Shevchenko wrote: On Tue, May 21, 2024 at 04:26:44PM +0530, Udit Kumar wrote: Some use case needs rproc firmware to be loaded at u-boot stage, using following commands at u-boot shell, firmware could be loaded => setenv dorprocboot 1 => run boot_rprocs For Secure devices, secure version of rproc firmware should be loaded, which is appended by sec keyword[0]. but currently non-secure firmware is loaded even for secure devices. So adding support for loading secure firmware on Secured devices. Are you Cc'ing random people with this? Please don't do it. I used names names popped up while running get_maintainer.pl script of u-boot your email id was there for patch-3 of this series ./scripts/get_maintainer.pl 0003-include-env-ti-Add-support-for-secure-firmwares.patch Joe Hershberger (maintainer:ENVIRONMENT) Tom Rini (maintainer:THE REST) Udit Kumar (commit_signer:1/2=50%,authored:1/2=50%,commit_signer:1/7=14%,authored:1/7=14%) Simon Glass (commit_signer:1/2=50%,authored:1/2=50%,authored:1/7=14%) Andy Shevchenko (commit_signer:1/2=50%) Bin Meng (commit_signer:1/2=50%) Manorit Chawdhry (commit_signer:1/2=50%,commit_signer:5/7=71%,authored:4/7=57%) Mattijs Korpershoek (commit_signer:4/7=57%) Nishanth Menon (commit_signer:1/7=14%,authored:1/7=14%) Siddharth Vadapalli (commit_signer:1/7=14%) u-boot@lists.denx.de (open list)
Re: [PATCH v2 2/2] lmb: Fix adjacent region merge in lmb_add_region_flags()
Hello Patrice
On 4/15/2024 12:33 PM, Patrice CHOTARD wrote:
On 4/14/24 13:10, Kumar, Udit wrote:
Hello Patrice,
On 4/13/2024 1:54 PM, Patrice CHOTARD wrote:
On 4/12/24 17:53, Patrice Chotard wrote:
In case a new region is adjacent to a previous region with
similar flag, this region is merged with its predecessor, but no
check are done if this new added region is overlapping another region
present in lmb (see reserved[3] which overlaps reserved[4]).
[..]
phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align)
{
return lmb_alloc_base(lmb, size, align, LMB_ALLOC_ANYWHERE);
I think this series (v2) is not correct even if now the CI tests are OK.
After re-reading carefully the lib_test_lmb_overlapping_reserve() test
it appears to me there is a contradiction.
It's indicating that "check that calling lmb_reserve with overlapping regions
fails"
but the very last test of lib_test_lmb_overlapping_reserve() has this comment :
/* allocate 3rd region, coalesce with first and overlap with second */
and this test allows this overlap case.
It's not clear if LMB region can overlap each other or not ?
I would say partial overlap and coalescing with before one
May be Below can help
/* allocate 2nd region , This should coalesced all region into one
you will get one region as
Address --- Size
0x4001 --- 0x3
Next after this /* allocate 2nd region, which should be added as first region
*/
we will have two region like
Address --- Size
(0x4000 -- 0x8000)
(0x4001 --- 0x3)
Now third request comes in
/* allocate 3rd region, coalesce with first and overlap with second */
which is address of 0x40008000 and size of 0x1, Now this region to be
added
is coalescing with first (0x4000 -- 0x8000) and part of this overlap with
(0x4001 --- 0x3).
So, what this patch does , merge all these into one region
as (0x4000 -- 0x4)
Hi Udit
Ok, but why the second test done in test/lib/lmb.c test should be considered as
failed ?
ret = lmb_reserve(&lmb, 0x4001, 0x1);
ut_asserteq(ret, 0);
ASSERT_LMB(&lmb, ram, ram_size, 1, 0x4001, 0x1,
0, 0, 0, 0);
/* allocate overlapping region should fail */
ret = lmb_reserve(&lmb, 0x40011000, 0x1);
ut_asserteq(ret, -1);
The 2 area 0x4001 -- 0x1 and 0x40011000 -- 0x1 area overlaps each
other and
should be merged in one 0x4001 -- 11000 ?
What is the criteria to merge or not 2 overlapping areas ?
For me overlapping shouldn't be authorized.
There are two areas
1) Overlapping : Which are not authorized
2) Overlapping and coalescing , Which is authorized to merge
I am ok if you say 'coalescing and overlapping' should be treated as
overlapping .
as long as new region is not getting created, for above.
What we see on our J784S4 EVM
without patch bdinfo says , reserved[1] and reserved[2] are overlapping
and should not be created.
reserved.cnt = 0x4 reserved[0] [0x9e80-0xabff], 0x0d80 bytes
flags: 4 reserved[1] [0xfce92000-0x], 0x0316e000 bytes flags: 0
reserved[2] [0xfde91ec0-0xfffe], 0x0216e13f bytes flags: 0
reserved[3] [0x88000-0xfefff], 0x77000 bytes flags: 0
Patrice
Udit, your patch edb5824be17f ("lmb: remove overlapping region with next range")
is authorizing LMB overlapping right ?
As said before this is checking overlap and coalescing and acting accordingly.
Patrice
Re: [PATCH v2 2/2] lmb: Fix adjacent region merge in lmb_add_region_flags()
Hello Patrice,
On 4/13/2024 1:54 PM, Patrice CHOTARD wrote:
On 4/12/24 17:53, Patrice Chotard wrote:
In case a new region is adjacent to a previous region with
similar flag, this region is merged with its predecessor, but no
check are done if this new added region is overlapping another region
present in lmb (see reserved[3] which overlaps reserved[4]).
[..]
phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align)
{
return lmb_alloc_base(lmb, size, align, LMB_ALLOC_ANYWHERE);
I think this series (v2) is not correct even if now the CI tests are OK.
After re-reading carefully the lib_test_lmb_overlapping_reserve() test
it appears to me there is a contradiction.
It's indicating that "check that calling lmb_reserve with overlapping regions
fails"
but the very last test of lib_test_lmb_overlapping_reserve() has this comment :
/* allocate 3rd region, coalesce with first and overlap with second */
and this test allows this overlap case.
It's not clear if LMB region can overlap each other or not ?
I would say partial overlap and coalescing with before one
May be Below can help
/* allocate 2nd region , This should coalesced all region into one
you will get one region as
Address --- Size
0x4001 --- 0x3
Next after this /* allocate 2nd region, which should be added as first
region */
we will have two region like
Address --- Size
(0x4000 -- 0x8000)
(0x4001 --- 0x3)
Now third request comes in
/* allocate 3rd region, coalesce with first and overlap with second */
which is address of 0x40008000 and size of 0x1, Now this region to
be added
is coalescing with first (0x4000 -- 0x8000) and part of this overlap
with (0x4001 --- 0x3).
So, what this patch does , merge all these into one region
as (0x4000 -- 0x4)
Udit, your patch edb5824be17f ("lmb: remove overlapping region with next range")
is authorizing LMB overlapping right ?
As said before this is checking overlap and coalescing and acting
accordingly.
Patrice
Re: [PATCH 1/2] lmb: Avoid to add identical region in lmb_add_region_flags()
On 3/11/2024 8:09 PM, Patrice Chotard wrote:
In case lmb_add_region_flags() is called with the same parameter than
an already existing lmb and this lmb is adjacent to its previous lmb with
different flag, this lmb is added again.
Same parameter means , addr and size and different flags correct ?
Instead breaking the loop, continue, at the next iteration, we are able
to detect that this region already exist.
Once region already exist detected, then you can think of returning
error , no ?
Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output
shows:
Before this patch, the last LMB [0xde00-0xdfff] is duplicated:
...
lmb_dump_all:nnn
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x6 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
reserved[5][0xde00-0xdfff], 0x0200 bytes flags: 4
...
After this patch:
...
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x5 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xdaadf000-0xdfff], 0x05521000 bytes flags: 0
reserved[4][0xde00-0xdfff], 0x0200 bytes flags: 4
...
Fixes: 59c0ea5df33f ("lmb: Add support of flags for no-map properties")
Signed-off-by: Patrice Chotard
---
lib/lmb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 44f98205310..b6afb731440 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -285,14 +285,14 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize);
if (adjacent > 0) {
if (flags != rgnflags)
- break;
+ continue;
rgn->region[i].base -= size;
rgn->region[i].size += size;
coalesced++;
break;
} else if (adjacent < 0) {
if (flags != rgnflags)
- break;
+ continue;
rgn->region[i].size += size;
coalesced++;
break;
Re: [PATCH 3/4] arm: dts: k3-j7200-r5-common: fix the mcu_timer0 clock frequency
On 3/6/2024 12:07 PM, Aniket Limaye wrote:
Correcting the clock-frequency property of the mcu_timer0 node
Fixes: df73e791ce09 ("arm: dts: j7200: dts sync with Linux 6.6-rc1")
Signed-off-by: Aniket Limaye
---
arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index 195637a836..c4ca09b1e0 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -52,7 +52,7 @@
};
&mcu_timer0 {
- clock-frequency = <2500>;
+ clock-frequency = <25000>;
bootph-pre-ram;
Reviewed-by: Udit Kumar
};
Re: [PATCH 2/4] arm: dts: k3-j7200: Fix support for OSPI flash
On 3/6/2024 12:07 PM, Aniket Limaye wrote:
- Add the missing bootph-all property in the flash subnode for ospi
- Add the missing overrides for the ospi node in the r5 devicetree
Please see , if you can add more on this why we are adding this
also, if this patch fixes some previous commit
Signed-off-by: Aniket Limaye
---
arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 4
arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 5 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index 60ca6d21ab..c9fee0ea99 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -195,6 +195,10 @@
&ospi0 {
bootph-all;
+
+ flash@0 {
+ bootph-all;
+ };
};
Ideally this should come from kernel DT sync or with OF_UPSTREAM,
whatever is applicable
As you are fixing broken OSPI boot.
Tom can suggest, if he is ok to pull in this fix for 2024.04 or we need
to wait to get this change into kernel first.
&serdes_ln_ctrl {
diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index 018faaa13b..195637a836 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -83,3 +83,8 @@
&wkup_vtm0 {
bootph-pre-ram;
};
+
+&ospi0 {
+reg = <0x0 0x4704 0x0 0x100>,
+ <0x0 0x5000 0x0 0x800>;
+};
With change in commit message,
Reviewed-by: Udit Kumar
Re: [PATCH 1/4] configs: j7200_evm_*_defconfig: Enable OSPI configs
On 3/6/2024 12:07 PM, Aniket Limaye wrote: Add the necessary configs required for OSPI functionality. Also update the ospi flash partition offsets as per the devicetree. Signed-off-by: Aniket Limaye --- configs/j7200_evm_a72_defconfig | 10 -- configs/j7200_evm_r5_defconfig | 9 +++-- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig index 2863472794..9ded9b2707 100644 --- a/configs/j7200_evm_a72_defconfig +++ b/configs/j7200_evm_a72_defconfig @@ -10,6 +10,8 @@ CONFIG_SOC_K3_J721E=y CONFIG_TARGET_J7200_A72_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048 +CONFIG_SF_DEFAULT_SPEED=2500 +CONFIG_SF_DEFAULT_MODE=0 CONFIG_ENV_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y @@ -61,7 +63,7 @@ CONFIG_SPL_RAM_DEVICE=y # CONFIG_SPL_SPI_FLASH_TINY is not set CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPL_SPI_LOAD=y -CONFIG_SYS_SPI_U_BOOT_OFFS=0x28 +CONFIG_SYS_SPI_U_BOOT_OFFS=0x30 CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_SYS_MAXARGS=64 CONFIG_CMD_ASKENV=y @@ -141,7 +143,11 @@ CONFIG_FLASH_CFI_MTD=y CONFIG_SYS_FLASH_CFI=y CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y CONFIG_DM_SPI_FLASH=y -CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y CONFIG_MULTIPLEXER=y diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig index 05eea55cfe..de5aaaece8 100644 --- a/configs/j7200_evm_r5_defconfig +++ b/configs/j7200_evm_r5_defconfig @@ -10,6 +10,8 @@ CONFIG_K3_EARLY_CONS=y CONFIG_TARGET_J7200_R5_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x41cf5bfc +CONFIG_SF_DEFAULT_SPEED=2500 +CONFIG_SF_DEFAULT_MODE=0 CONFIG_ENV_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y @@ -60,7 +62,7 @@ CONFIG_SPL_REMOTEPROC=y # CONFIG_SPL_SPI_FLASH_TINY is not set CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPL_SPI_LOAD=y -CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 +CONFIG_SYS_SPI_U_BOOT_OFFS=0x10 CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_HUSH_PARSER=y CONFIG_SYS_MAXARGS=64 @@ -117,7 +119,10 @@ CONFIG_SYS_FLASH_CFI=y CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_SFDP_SUPPORT=y -CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y Reviewed-by: Udit Kumar
Re: [PATCH 0/4] Fix OSPI bootmode for j7200-evm
On 3/6/2024 12:07 PM, Aniket Limaye wrote: Support for OSPI probe and also read/write is broken and/or missing in current master branch. Its broken :) - sf probe failure from u-boot prompt & OSPI boot failure [0] This series adds necessary configs, as well as fixes some bugs in the existing u-boot devicetree, to add OSPI boot support for the j7200-evm device. - sf probe and update in u-boot prompt & successful OSPI boot logs [1] [0]: https://gist.github.com/aniket-l/f487472baa47e819defc82e5f57b7860 [1]: https://gist.github.com/aniket-l/e5353c4511009d2ebf5f1743ebaab61a Aniket Limaye (4): configs: j7200_evm_*_defconfig: Enable OSPI configs arm: dts: k3-j7200: Fix support for OSPI flash arm: dts: k3-j7200-r5-common: fix the mcu_timer0 clock frequency arm: dts: k3-j7200-r5-common: Add missing overrides for ringacc and udmap Please copy Nishanth in your posting .../dts/k3-j7200-common-proc-board-u-boot.dtsi| 4 arch/arm/dts/k3-j7200-r5-common-proc-board.dts| 15 ++- configs/j7200_evm_a72_defconfig | 10 -- configs/j7200_evm_r5_defconfig| 9 +++-- 4 files changed, 33 insertions(+), 5 deletions(-)
Re: [PATCH v2 2/3] arm: mach-k3: j721e: Enable OSPI boot
Thanks For fixing this
On 2/24/2024 5:53 AM, Jonathan Humphreys wrote:
Add boot ROM XSPI bootmode, and set to BOOT_DEVICE_SPI if detected.
Signed-off-by: Jonathan Humphreys
---
arch/arm/mach-k3/include/mach/j721e_spl.h | 5 +++--
arch/arm/mach-k3/j721e_init.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-k3/include/mach/j721e_spl.h
b/arch/arm/mach-k3/include/mach/j721e_spl.h
index ed3d7333bd..aaee653537 100644
--- a/arch/arm/mach-k3/include/mach/j721e_spl.h
+++ b/arch/arm/mach-k3/include/mach/j721e_spl.h
@@ -24,8 +24,9 @@
#define BOOT_DEVICE_UFS 0x13
#define BOOT_DEVIE_GPMC 0x14
#define BOOT_DEVICE_PCIE 0x15
-#define BOOT_DEVICE_MMC2_2 0x16
-#define BOOT_DEVICE_RAM0x17
+#define BOOT_DEVICE_XSPI 0x16
+#define BOOT_DEVICE_RAM0x17
+#define BOOT_DEVICE_MMC2_2 0xFF /* Invalid value */
/* Backup boot modes with MCU Only = 0 */
#define BACKUP_BOOT_DEVICE_RAM0x0
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index c2976c4ea0..7ee9b75de4 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -346,7 +346,8 @@ static u32 __get_primary_bootmedia(u32 main_devstat, u32
wkup_devstat)
bootmode |= (main_devstat & MAIN_DEVSTAT_BOOT_MODE_B_MASK) <<
BOOT_MODE_B_SHIFT;
- if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI)
+ if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI ||
+ bootmode == BOOT_DEVICE_XSPI)
bootmode = BOOT_DEVICE_SPI;
Reviewed-by: Udit Kumar
if (bootmode == BOOT_DEVICE_MMC2) {
Re: [PATCH v2 1/3] configs: j721e: Enable OSPI memory
On 2/24/2024 5:53 AM, Jonathan Humphreys wrote: Set config values to enable OSPI functionality. Signed-off-by: Jonathan Humphreys --- configs/j721e_evm_a72_defconfig | 7 +++ configs/j721e_evm_r5_defconfig | 6 ++ 2 files changed, 13 insertions(+) diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 74af5bebb5..1b39dd7c86 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -10,6 +10,7 @@ CONFIG_SOC_K3_J721E=y CONFIG_TARGET_J721E_A72_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048 +CONFIG_SF_DEFAULT_SPEED=2500 CONFIG_ENV_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y @@ -142,7 +143,13 @@ CONFIG_FLASH_CFI_MTD=y CONFIG_SYS_FLASH_CFI=y CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MT35XU=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y CONFIG_MULTIPLEXER=y diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index bc4f35cce1..59c0c4135c 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -10,6 +10,7 @@ CONFIG_K3_EARLY_CONS=y CONFIG_TARGET_J721E_R5_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x41cf59f0 +CONFIG_SF_DEFAULT_SPEED=2500 CONFIG_ENV_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y @@ -128,7 +129,12 @@ CONFIG_FLASH_CFI_MTD=y CONFIG_SYS_FLASH_CFI=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MT35XU=y Reviewed-by: Udit Kumar CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y
Re: [PATCH v2 3/3] arm: dts: k3-j721e-sk: Remove OSPI phypattern partition
Thanks Jon
On 2/24/2024 5:53 AM, Jonathan Humphreys wrote:
The phy calibration pattern partition isn't needed as the Cadence driver isn't
calibrating the phys.
Please do mention Fixes tag here
58d61fb5a77e ("arm: dts: k3-j721e-sk: Add initial A72 specific dts support")
Signed-off-by: Jonathan Humphreys
---
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
index 479b7bcd6f..20b76a84ff 100644
--- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
@@ -157,9 +157,5 @@
flash@0 {
bootph-all;
-
- partition@3fc {
- bootph-all;
- };
};
This Patch LTGM,
+ Neha
For further cleanup, we should not have these ospi nodes in u-boot dts file.
should be in board dts (k3-j721e-sk.dts) with right bootph properties ,
and comes via kernel DT.
};
Re: [PATCH 09/10] DONOTMERGE: arm: dts: j721s2: Fix Power domain for VTM node.
On 2/6/2024 5:51 PM, Manorit Chawdhry wrote: Patch is sent to upstream linux [0]. [0]: https://lore.kernel.org/all/20240201-b4-upstream-j721s2-fix-vtm-devid-v2-0-85fd568b7...@ti.com/ Signed-off-by: Manorit Chawdhry --- arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi b/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi index 80aa33c58a45..a47cb557dd95 100644 --- a/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi +++ b/arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi @@ -663,7 +663,7 @@ compatible = "ti,j7200-vtm"; reg = <0x00 0x4204 0x0 0x350>, <0x00 0x4205 0x0 0x350>; - power-domains = <&k3_pds 154 TI_SCI_PD_SHARED>; + power-domains = <&k3_pds 180 TI_SCI_PD_SHARED>; I kind of disagree with this patch as Do not Merge, I understand you want to do this change as part of next sync. But we got already node in u-boot for VTM with incorrect power-domain. I am not sure, with incorrect power-domain, how AVS will be behave. Here are my 2 cents Either mark this patch part of series or Hold AVS till next sync #thermal-sensor-cells = <1>; };
Re: [PATCH] arm: mach-k3: j721s2_init: Support less than max DDR controllers
On 1/30/2024 1:11 PM, Neha Malcom Francis wrote:
The number of DDR controllers to be initialised and used should depend
on the device tree with the constraint of the maximum number of
controllers the device supports. Since J721S2 has multiple (2)
controllers, instead of hardcoding the number of probes, move to
depending on the device tree UCLASS_RAM nodes present.
Signed-off-by: Neha Malcom Francis
---
Boot logs:
https://gist.github.com/nehamalcom/07fedf4aa173590214b5cef6e1688fa1
This was also parallely proposed in [1] on the mailing-list for J784S4.
[1] https://lore.kernel.org/all/3a7c817b-de29-463a-b4b6-d62c0df66...@ti.com/
arch/arm/mach-k3/j721s2_init.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index fb0708bae1..ff21619506 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -213,10 +213,12 @@ bool check_rom_loaded_sysfw(void)
return is_rom_loaded_sysfw(&bootdata);
}
+#define J721S2_MAX_CONTROLLERS 2
+
void k3_mem_init(void)
{
struct udevice *dev;
- int ret;
+ int ret, ctr = 1;
if (IS_ENABLED(CONFIG_K3_J721E_DDRSS)) {
ret = uclass_get_device_by_name(UCLASS_MISC, "msmc", &dev);
@@ -227,9 +229,14 @@ void k3_mem_init(void)
if (ret)
panic("DRAM 0 init failed: %d\n", ret);
- ret = uclass_next_device_err(&dev);
- if (ret)
- panic("DRAM 1 init failed: %d\n", ret);
Since there are two controllers only and you need to call
uclass_get_device and uclass_next_device_err
what about just checking error in above removed code, something like
ret = uclass_next_device_err(&dev);
if (ret!=ENODEV)
panic("DRAM 1 init failed: %d\n", ret);
+ while (ctr < J721S2_MAX_CONTROLLERS) {
+ ret = uclass_next_device_err(&dev);
+ if (ret == -ENODEV)
+ break;
+ if (ret)
+ panic("DRAM %d init failed: %d\n", ctr, ret);
+ ctr++;
+ }
}
spl_enable_cache();
}
Re: [PATCH v3 1/2] arm: mach-k3: j72xx: add new 'virtual' mux
Thanks Reid
On 12/7/2023 10:22 PM, Reid Tonking wrote:
From: Bryan Brattlof
In order for the Cortex-A72s to operate at different frequencies other
than the default 2GHz, add in a new 'virtual' mux (a mux that does not
physically exist in the clock tree) that can be selected.
CC: Vishal Mahaveer
Signed-off-by: Bryan Brattlof
Signed-off-by: Apurva Nandan
Signed-off-by: Reid Tonking
---
arch/arm/mach-k3/j7200/clk-data.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j7200/clk-data.c
b/arch/arm/mach-k3/j7200/clk-data.c
index 9b45786a2d4..eb8436decbd 100644
--- a/arch/arm/mach-k3/j7200/clk-data.c
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -141,6 +141,11 @@ static const char * const
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = {
"hsdiv4_16fft_main_0_hsdivout0_clk",
};
+static const char * const main_pll8_sel_extwave_out0_parents[] = {
+ "pllfracf_ssmod_16fft_main_8_foutvcop_clk",
+ "hsdiv0_16fft_main_8_hsdivout0_clk",
+};
+
static const char * const mcu_obsclk_outmux_out0_parents[] = {
"mcu_obsclk_div_out0",
"gluelogic_hfosc0_clkout",
@@ -396,6 +401,7 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_main_3_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_3_foutvcop_clk", 0x683088, 0, 7, 0, 0),
CLK_MUX_PLLCTRL("k3_pll_ctrl_wrap_main_0_sysclkout_clk",
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents, 2, 0x41, 0),
CLK_DIV("k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
"k3_pll_ctrl_wrap_main_0_sysclkout_clk", 0x410118, 0, 5, 0, 0),
+ CLK_MUX("main_pll8_sel_extwave_out0",
main_pll8_sel_extwave_out0_parents, 2, 0x688040, 0, 1, 0),
CLK_DIV("mcu_obsclk_div_out0", "wkup_obsclk_mux_out0", 0x43008000, 8,
4, 0, 0),
CLK_MUX("mcu_obsclk_outmux_out0", mcu_obsclk_outmux_out0_parents, 2,
0x43008000, 24, 1, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_4_foutvcop_clk",
"main_pll4_xref_sel_out0", 0x684000, 0),
@@ -545,11 +551,14 @@ static const struct dev_clk soc_dev_clk_data[] = {
DEV_CLK(288, 14, "board_0_hfosc1_clk_out"),
DEV_CLK(288, 15, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(288, 17, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
+ DEV_CLK(323, 0, "main_pll8_sel_extwave_out0"),
+ DEV_CLK(323, 1, "pllfracf_ssmod_16fft_main_8_foutvcop_clk"),
+ DEV_CLK(323, 2, "hsdiv0_16fft_main_8_hsdivout0_clk"),
};
const struct ti_k3_clk_platdata j7200_clk_platdata = {
.clk_list = clk_list,
- .clk_list_cnt = 109,
+ .clk_list_cnt = ARRAY_SIZE(clk_list),
.soc_dev_clk_data = soc_dev_clk_data,
- .soc_dev_clk_data_cnt = 129,
+ .soc_dev_clk_data_cnt = ARRAY_SIZE(soc_dev_clk_data),
};
Reviewed-by: Udit Kumar
Re: [PATCH v2 2/2] arm: dts: k3-j7200-r5-common-proc-board: Set parent clock for clock ID 323
On 12/7/2023 2:47 AM, Reid Tonking wrote: Previously, dynamic frequency scaling supported rates only through fixed divison. This virtual clock mux configuration enables more varied rates on A72 clock ID 202 by setting up the required register. Signed-off-by: Apurva Nandan Signed-off-by: Reid Tonking --- arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts index f0a73605020..018faaa13b6 100644 --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts @@ -24,7 +24,8 @@ <&k3_pds 4 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; clocks = <&k3_clks 61 1>; - assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>; + assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>, <&k3_clks 323 0>; + assigned-clock-parents= <0>, <0>, <&k3_clks 323 2>; For this patch Reviewed-by: Udit Kumar assigned-clock-rates = <20>, <2>; ti,sci = <&dmsc>; ti,sci-proc-id = <32>;
Re: [PATCH v2 1/2] arm: mach-k3: j72xx: add new 'virtual' mux
On 12/7/2023 2:47 AM, Reid Tonking wrote:
From: Bryan Brattlof
In order for the Cortex-A72s to operate at different frequencies other
than the default 2GHz, add in a new 'virtual' mux (a mux that does not
physically exist in the clock tree) that can be selected.
CC: Vishal Mahaveer
Signed-off-by: Bryan Brattlof
Signed-off-by: Apurva Nandan
Signed-off-by: Reid Tonking
---
arch/arm/mach-k3/j7200/clk-data.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j7200/clk-data.c
b/arch/arm/mach-k3/j7200/clk-data.c
index 9b45786a2d4..126627fff47 100644
--- a/arch/arm/mach-k3/j7200/clk-data.c
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -141,6 +141,11 @@ static const char * const
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = {
"hsdiv4_16fft_main_0_hsdivout0_clk",
};
+static const char * const main_pll8_sel_extwave_out0_parents[] = {
+ "pllfracf_ssmod_16fft_main_8_foutvcop_clk",
+ "hsdiv0_16fft_main_8_hsdivout0_clk",
+};
+
static const char * const mcu_obsclk_outmux_out0_parents[] = {
"mcu_obsclk_div_out0",
"gluelogic_hfosc0_clkout",
@@ -396,6 +401,7 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_main_3_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_3_foutvcop_clk", 0x683088, 0, 7, 0, 0),
CLK_MUX_PLLCTRL("k3_pll_ctrl_wrap_main_0_sysclkout_clk",
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents, 2, 0x41, 0),
CLK_DIV("k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
"k3_pll_ctrl_wrap_main_0_sysclkout_clk", 0x410118, 0, 5, 0, 0),
+ CLK_MUX("main_pll8_sel_extwave_out0",
main_pll8_sel_extwave_out0_parents, 2, 0x688040, 0, 1, 0),
CLK_DIV("mcu_obsclk_div_out0", "wkup_obsclk_mux_out0", 0x43008000, 8,
4, 0, 0),
CLK_MUX("mcu_obsclk_outmux_out0", mcu_obsclk_outmux_out0_parents, 2,
0x43008000, 24, 1, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_4_foutvcop_clk",
"main_pll4_xref_sel_out0", 0x684000, 0),
@@ -545,11 +551,14 @@ static const struct dev_clk soc_dev_clk_data[] = {
DEV_CLK(288, 14, "board_0_hfosc1_clk_out"),
DEV_CLK(288, 15, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(288, 17, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
+ DEV_CLK(323, 0, "main_pll8_sel_extwave_out0"),
+ DEV_CLK(323, 1, "pllfracf_ssmod_16fft_main_8_foutvcop_clk"),
+ DEV_CLK(323, 2, "hsdiv0_16fft_main_8_hsdivout0_clk"),
};
const struct ti_k3_clk_platdata j7200_clk_platdata = {
.clk_list = clk_list,
- .clk_list_cnt = 109,
+ .clk_list_cnt = 110,
.soc_dev_clk_data = soc_dev_clk_data,
- .soc_dev_clk_data_cnt = 129,
+ .soc_dev_clk_data_cnt = 132,
Looks you missed to update this with ARRAY_SIZE
};
Re: [PATCH 2/2] arm: dts: k3-j7200-r5-common-proc-board: Set parent clock for clock ID 323
On 12/2/2023 3:03 AM, Reid Tonking wrote: From: Apurva Nandan This virtual clock mux configuration enables the use of dynamic frequency scaling on A72 clock ID 202 by setting up the required register. IMO, dynamic frequency scaling should be supported without this patch. But this patch allows to set freq at different rates other than fixed division. I request to update commit message. Rest LGTM Signed-off-by: Apurva Nandan Signed-off-by: Reid Tonking --- arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts index f0a73605020..018faaa13b6 100644 --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts @@ -24,7 +24,8 @@ <&k3_pds 4 TI_SCI_PD_EXCLUSIVE>; resets = <&k3_reset 202 0>; clocks = <&k3_clks 61 1>; - assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>; + assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>, <&k3_clks 323 0>; + assigned-clock-parents= <0>, <0>, <&k3_clks 323 2>; assigned-clock-rates = <20>, <2>; ti,sci = <&dmsc>; ti,sci-proc-id = <32>;
Re: [PATCH 1/2] arm: mach-k3: j72xx: add new 'virtual' mux
On 12/2/2023 3:03 AM, Reid Tonking wrote:
From: Bryan Brattlof
In order for the Cortex-A72s to operate at different frequencies other
than the default 2GHz, add in a new 'virtual' mux (a mux that does not
physically exist in the clock tree) that can be selected.
CC: Vishal Mahaveer
Signed-off-by: Bryan Brattlof
Signed-off-by: Apurva Nandan
Signed-off-by: Reid Tonking
---
arch/arm/mach-k3/j7200/clk-data.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j7200/clk-data.c
b/arch/arm/mach-k3/j7200/clk-data.c
index 9b45786a2d4..126627fff47 100644
--- a/arch/arm/mach-k3/j7200/clk-data.c
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -141,6 +141,11 @@ static const char * const
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = {
"hsdiv4_16fft_main_0_hsdivout0_clk",
};
+static const char * const main_pll8_sel_extwave_out0_parents[] = {
+ "pllfracf_ssmod_16fft_main_8_foutvcop_clk",
+ "hsdiv0_16fft_main_8_hsdivout0_clk",
+};
+
static const char * const mcu_obsclk_outmux_out0_parents[] = {
"mcu_obsclk_div_out0",
"gluelogic_hfosc0_clkout",
@@ -396,6 +401,7 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_main_3_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_3_foutvcop_clk", 0x683088, 0, 7, 0, 0),
CLK_MUX_PLLCTRL("k3_pll_ctrl_wrap_main_0_sysclkout_clk",
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents, 2, 0x41, 0),
CLK_DIV("k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
"k3_pll_ctrl_wrap_main_0_sysclkout_clk", 0x410118, 0, 5, 0, 0),
+ CLK_MUX("main_pll8_sel_extwave_out0",
main_pll8_sel_extwave_out0_parents, 2, 0x688040, 0, 1, 0),
CLK_DIV("mcu_obsclk_div_out0", "wkup_obsclk_mux_out0", 0x43008000, 8,
4, 0, 0),
CLK_MUX("mcu_obsclk_outmux_out0", mcu_obsclk_outmux_out0_parents, 2,
0x43008000, 24, 1, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_4_foutvcop_clk",
"main_pll4_xref_sel_out0", 0x684000, 0),
@@ -545,11 +551,14 @@ static const struct dev_clk soc_dev_clk_data[] = {
DEV_CLK(288, 14, "board_0_hfosc1_clk_out"),
DEV_CLK(288, 15, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(288, 17, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
+ DEV_CLK(323, 0, "main_pll8_sel_extwave_out0"),
+ DEV_CLK(323, 1, "pllfracf_ssmod_16fft_main_8_foutvcop_clk"),
+ DEV_CLK(323, 2, "hsdiv0_16fft_main_8_hsdivout0_clk"),
};
const struct ti_k3_clk_platdata j7200_clk_platdata = {
.clk_list = clk_list,
- .clk_list_cnt = 109,
+ .clk_list_cnt = 110,
.soc_dev_clk_data = soc_dev_clk_data,
- .soc_dev_clk_data_cnt = 129,
+ .soc_dev_clk_data_cnt = 132,
Can we think of using ARRAY_SIZE for these number clk_list_cnt and
soc_dev_clk_data_cnt
};
Re: [PATCH v4 00/16] Introduce initial TI's J784S4 and AM69 support
On 11/17/2023 4:26 AM, Enric Balletbo i Serra wrote: Hi Maxime On Wed, Nov 15, 2023 at 2:54 PM Maxime Ripard wrote: Hi, On Sun, Oct 01, 2023 at 10:25:29PM +0530, Apurva Nandan wrote: This series will introduce basic support (SD and UART) support for Texas Instruments J784S4 EVM. The J784S4 SoC device tree patches are taken from kernel patch submissions and will be updated as they are accepted and merged to the kernel tree. All other patches are specific to SPL and u-boot and do not have dependency on other trees. Appreciate a review for acceptance to u-boot tree. Here are some of the salient features of the J784S4 automotive grade application processor: The J784S4 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive, ADAS and industrial applications requiring AI at the network edge. This SoC extends the K3 Jacinto 7 family of SoCs with focus on raising performance and integration while providing interfaces, memory architecture and compute performance for multi-sensor, high concurrency applications. Some highlights of this SoC are: * Up to 8 Cortex-A72s, four clusters of lockstep capable dual Cortex-R5F MCUs, 4 C7x floating point vector DSPs with Matrix Multiply Accelerator(MMA) for deep learning and CNN. * 3D GPU: Automotive grade IMG BXS-4-64 MC1 * Vision Processing Accelerator (VPAC) with image signal processor and Depth and Motion Processing Accelerator (DMPAC) * Three CSI2.0 4L RX plus two CSI2.0 4L TX, two DSI Tx, one eDP/DP and one DPI interface. * Integrated gigabit ethernet switch, up to 8 ports (TDA4VH), two ports support 10Gb USXGMII; Two 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems, Up to 20 MCANs, among other peripherals. See J784S4 Technical Reference Manual (SPRUJ52 - JUNE 2022) for further details: http://www.ti.com/lit/zip/spruj52 In addtion, the J784S4 EVM board is designed for TI J784S4 SoC. It supports the following interfaces: * 32 GB DDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode * x1 Input Audio Jack, x1 Output Audio Jack * x1 USB2.0 Hub with two Type A host and x1 USB 3.1 Type-C Port * x2 4L PCIe connector * x1 UHS-1 capable micro-SD card slot * 512 Mbit OSPI flash, 1 Gbit Octal NAND flash, 512 Mbit QSPI flash, UFS flash. * x6 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin User Expansion Connector * x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector * x1 15-pin CSI header * x6 MCAN instances I've tested this series on top of 2024.01-rc2, and while it worked fine before, the (external) MMC is now broken: U-Boot SPL 2024.01-rc2-00021-g8e3ced8fbad8 (Nov 15 2023 - 12:07:18 +0100) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.2--v09.01.02 (Kool Koala)') SPL initial stack usage: 13416 bytes Trying to boot from MMC2 Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices Loading Environment from nowhere... OK Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):v2.9.0 NOTICE: BL31: Built : 12:07:09, Nov 15 2023 I/TC: I/TC: OP-TEE version: 4.0.0 (gcc version 13.2.1 20230728 (Red Hat Cross 13.2.1-1) (GCC)) #1 Wed Nov 15 11:07:14 UTC 2023 aarch64 I/TC: WARNING: This OP-TEE configuration might be insecure! I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html I/TC: Primary CPU initializing I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.2--v09.01.02 (Kool Koala)') I/TC: HUK Initialized I/TC: Activated SA2UL device I/TC: Enabled firewalls for SA2UL TRNG device I/TC: SA2UL TRNG initialized I/TC: SA2UL Drivers initialized I/TC: Primary CPU switching to normal world boot U-Boot SPL 2024.01-rc2-00021-g8e3ced8fbad8 (Nov 15 2023 - 12:07:30 +0100) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.2--v09.01.02 (Kool Koala)') Trying to boot from MMC2 Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices U-Boot 2024.01-rc2-00021-g8e3ced8fbad8 (Nov 15 2023 - 12:07:30
Re: [PATCH] arm: dts: k3-j7200: Sync with Linux 6.7-rc1
On 11/16/2023 1:40 PM, Neha Malcom Francis wrote:
Hi Udit
On 14/11/23 11:07, Kumar, Udit wrote:
Thanks Reid for sync.
On 11/14/2023 2:13 AM, Reid Tonking wrote:
Sync u-boot device tree with Linux kernel 6.7-rc1
Signed-off-by: Reid Tonking
---
Boot-log:
https://gist.github.com/reidt1/db5426f2a778369db8c3699cf293b94f
arch/arm/dts/k3-j7200-main.dtsi | 2 +-
arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 9 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-j7200-main.dtsi
b/arch/arm/dts/k3-j7200-main.dtsi
index cdb1d6b2a9..264913f832 100644
--- a/arch/arm/dts/k3-j7200-main.dtsi
+++ b/arch/arm/dts/k3-j7200-main.dtsi
@@ -91,7 +91,7 @@
};
main_navss: bus@3000 {
- compatible = "simple-mfd";
+ compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x3000 0x00 0x3000 0x00 0x0c40>;
diff --git a/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
b/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
index 6ffaf85fa6..3fc588b848 100644
--- a/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
@@ -318,7 +318,7 @@
};
mcu_navss: bus@2838 {
- compatible = "simple-mfd";
+ compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x2838 0x00 0x2838 0x00 0x0388>;
@@ -637,4 +637,11 @@
power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
#thermal-sensor-cells = <1>;
};
+
+ mcu_esm: esm@4080 {
+ compatible = "ti,j721e-esm";
+ reg = <0x00 0x4080 0x00 0x1000>;
+ ti,esm-pins = <95>;
+ bootph-pre-ram;
+ };
};
Please take care of actual usage of this node
This need not be taken up within the sync itself right? I am planning
on reviving Keerthy's patches once the J7 syncs are in.
Its up-to you , how you want to take care of probing of this driver in
this or other series.
Thanks
Udit
https://lore.kernel.org/all/20231003081038.24299-10-j-keer...@ti.com/
https://lore.kernel.org/all/20231003081038.24299-11-j-keer...@ti.com/
https://lore.kernel.org/all/838b07a0-8490-c05b-b08f-3ab6d3e17...@ti.com/
Re: [PATCH] arm: dts: k3-j7200: Sync with Linux 6.7-rc1
Thanks Reid for sync.
On 11/14/2023 2:13 AM, Reid Tonking wrote:
Sync u-boot device tree with Linux kernel 6.7-rc1
Signed-off-by: Reid Tonking
---
Boot-log: https://gist.github.com/reidt1/db5426f2a778369db8c3699cf293b94f
arch/arm/dts/k3-j7200-main.dtsi | 2 +-
arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 9 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-j7200-main.dtsi b/arch/arm/dts/k3-j7200-main.dtsi
index cdb1d6b2a9..264913f832 100644
--- a/arch/arm/dts/k3-j7200-main.dtsi
+++ b/arch/arm/dts/k3-j7200-main.dtsi
@@ -91,7 +91,7 @@
};
main_navss: bus@3000 {
- compatible = "simple-mfd";
+ compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x3000 0x00 0x3000 0x00 0x0c40>;
diff --git a/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
b/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
index 6ffaf85fa6..3fc588b848 100644
--- a/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
@@ -318,7 +318,7 @@
};
mcu_navss: bus@2838 {
- compatible = "simple-mfd";
+ compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x2838 0x00 0x2838 0x00 0x0388>;
@@ -637,4 +637,11 @@
power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
#thermal-sensor-cells = <1>;
};
+
+ mcu_esm: esm@4080 {
+ compatible = "ti,j721e-esm";
+ reg = <0x00 0x4080 0x00 0x1000>;
+ ti,esm-pins = <95>;
+ bootph-pre-ram;
+ };
};
Please take care of actual usage of this node
https://lore.kernel.org/all/20231003081038.24299-10-j-keer...@ti.com/
https://lore.kernel.org/all/20231003081038.24299-11-j-keer...@ti.com/
https://lore.kernel.org/all/838b07a0-8490-c05b-b08f-3ab6d3e17...@ti.com/
Re: [PATCH 01/15] arm: mach-k3: j721e: Improve support for UDA FS
On 11/6/2023 5:48 PM, Nishanth Menon wrote:
On 15:54-20231104, Kumar, Udit wrote:
On 11/3/2023 6:07 AM, Nishanth Menon wrote:
Commit 5019170970ad ("arch: arm: mach-k3: j721e: add support for UDA
FS") introduced basic UDA FS support, however, we can Take approach
similar to commit 0f1c1e8b368b ("arm: mach-k3: am625: Add support for
UDA FS"). While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
I am thinking, in which case we have EMMC_BOOT disabled,
Case here I am considering, updating u-boot to eMMC from u-boot shell, If
EMMC_BOOT
is not set then , we can not set CSD information
Yes, but we cannot use boot0 mode of operation for Beagle family. the
size of u-boot and optee vary over time and SK's boot0 partition
strategy does'nt work for Beagle platforms.
Thanks, I was not aware of this limitation of Beagle family.
Let each board chose needed config with that
Reviewed-by: Udit Kumar
Signed-off-by: Nishanth Menon
---
arch/arm/mach-k3/j721e_init.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index b1f7e25ed092..bcdfbfc79c4a 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -294,7 +294,14 @@ u32 spl_mmc_boot_mode(struct mmc *mmc, const u32
boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
- return (spl_mmc_emmc_boot_partition(mmc) ? MMCSD_MODE_EMMCBOOT
: MMCSD_MODE_FS);
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) {
+ if (spl_mmc_emmc_boot_partition(mmc))
+ return MMCSD_MODE_EMMCBOOT;
+ return MMCSD_MODE_FS;
+ }
I had a view EMMC_BOOT should be needed config.
+ if (IS_ENABLED(CONFIG_SPL_FS_FAT) ||
IS_ENABLED(CONFIG_SPL_FS_EXT4))
+ return MMCSD_MODE_FS;
+ return MMCSD_MODE_EMMCBOOT;
If you consider, to make EMMC_BOOT as needed config, then this is not needed
EMMC_BOOT is not a mandatory config.
case BOOT_DEVICE_MMC2:
return MMCSD_MODE_FS;
default:
Re: [PATCH 03/15] board: ti: j721e: evm: Drop board check for ESM
On 11/6/2023 5:49 PM, Nishanth Menon wrote:
On 16:03-20231104, Kumar, Udit wrote:
On 11/3/2023 6:07 AM, Nishanth Menon wrote:
When config is enabled, the esm dt probe makes sense. Simplify by
dropping board specific checks.
Signed-off-by: Nishanth Menon
---
board/ti/j721e/evm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index d4f7c1d9f938..75d51a0552c4 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -531,10 +531,8 @@ err_free_gpio:
void spl_board_init(void)
{
-#if defined(CONFIG_ESM_K3) || defined(CONFIG_ESM_PMIC)
struct udevice *dev;
int ret;
-#endif
if ((IS_ENABLED(CONFIG_TARGET_J721E_A72_EVM) ||
IS_ENABLED(CONFIG_TARGET_J7200_A72_EVM)) &&
@@ -543,24 +541,20 @@ void spl_board_init(void)
probe_daughtercards();
}
-#ifdef CONFIG_ESM_K3
- if (board_ti_k3_is("J721EX-PM2-SOM")) {
+ if (IS_ENABLED(CONFIG_ESM_K3)) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(k3_esm), &dev);
if (ret)
printf("ESM init failed: %d\n", ret);
}
Nothing related to this patch, but to get esm completely functional
Second k3_esm probing needs to be added in this file.
Also, DT changes are needed, in next sync
https://lore.kernel.org/all/20231013102941.548209-1-n-fran...@ti.com/
Understood. no action on the current series, I assume.
yes, no action on current series.
Reviewed-by: Udit Kumar
Re: [PATCH 06/15] board: ti: j721e: evm: Drop board based serdes initialization
On 11/4/2023 4:05 PM, Kumar, Udit wrote: On 11/3/2023 6:07 AM, Nishanth Menon wrote: Serdes initialization should be compile flag based instead of being eeprom based. Signed-off-by: Nishanth Menon --- board/ti/j721e/evm.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c index 17640ae79665..d49993fffe39 100644 --- a/board/ti/j721e/evm.c +++ b/board/ti/j721e/evm.c @@ -359,9 +359,6 @@ void configure_serdes_torrent(void) struct phy serdes; int ret; - if (!IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT)) - return; - ret = uclass_get_device_by_driver(UCLASS_PHY, DM_DRIVER_GET(torrent_phy_provider), &dev); @@ -393,9 +390,6 @@ void configure_serdes_sierra(void) int ret, count, i; int link_count = 0; - if (!IS_ENABLED(CONFIG_PHY_CADENCE_SIERRA)) - return; - ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(sierra_phy_provider), &dev); @@ -477,10 +471,10 @@ int board_late_init(void) probe_daughtercards(); } - if (board_is_j7200_som()) + if (IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT)) configure_serdes_torrent(); - if (board_is_j721e_som()) + if (IS_ENABLED(CONFIG_PHY_CADENCE_SIERRA)) configure_serdes_sierra(); Could be merged into one if condition Please ignore above comments with that Reviewed-by: Udit Kumar return 0;
Re: [PATCH 06/15] board: ti: j721e: evm: Drop board based serdes initialization
On 11/3/2023 6:07 AM, Nishanth Menon wrote: Serdes initialization should be compile flag based instead of being eeprom based. Signed-off-by: Nishanth Menon --- board/ti/j721e/evm.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c index 17640ae79665..d49993fffe39 100644 --- a/board/ti/j721e/evm.c +++ b/board/ti/j721e/evm.c @@ -359,9 +359,6 @@ void configure_serdes_torrent(void) struct phy serdes; int ret; - if (!IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT)) - return; - ret = uclass_get_device_by_driver(UCLASS_PHY, DM_DRIVER_GET(torrent_phy_provider), &dev); @@ -393,9 +390,6 @@ void configure_serdes_sierra(void) int ret, count, i; int link_count = 0; - if (!IS_ENABLED(CONFIG_PHY_CADENCE_SIERRA)) - return; - ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(sierra_phy_provider), &dev); @@ -477,10 +471,10 @@ int board_late_init(void) probe_daughtercards(); } - if (board_is_j7200_som()) + if (IS_ENABLED(CONFIG_PHY_CADENCE_TORRENT)) configure_serdes_torrent(); - if (board_is_j721e_som()) + if (IS_ENABLED(CONFIG_PHY_CADENCE_SIERRA)) configure_serdes_sierra(); Could be merged into one if condition return 0;
Re: [PATCH 03/15] board: ti: j721e: evm: Drop board check for ESM
On 11/3/2023 6:07 AM, Nishanth Menon wrote:
When config is enabled, the esm dt probe makes sense. Simplify by
dropping board specific checks.
Signed-off-by: Nishanth Menon
---
board/ti/j721e/evm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index d4f7c1d9f938..75d51a0552c4 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -531,10 +531,8 @@ err_free_gpio:
void spl_board_init(void)
{
-#if defined(CONFIG_ESM_K3) || defined(CONFIG_ESM_PMIC)
struct udevice *dev;
int ret;
-#endif
if ((IS_ENABLED(CONFIG_TARGET_J721E_A72_EVM) ||
IS_ENABLED(CONFIG_TARGET_J7200_A72_EVM)) &&
@@ -543,24 +541,20 @@ void spl_board_init(void)
probe_daughtercards();
}
-#ifdef CONFIG_ESM_K3
- if (board_ti_k3_is("J721EX-PM2-SOM")) {
+ if (IS_ENABLED(CONFIG_ESM_K3)) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(k3_esm), &dev);
if (ret)
printf("ESM init failed: %d\n", ret);
}
Nothing related to this patch, but to get esm completely functional
Second k3_esm probing needs to be added in this file.
Also, DT changes are needed, in next sync
https://lore.kernel.org/all/20231013102941.548209-1-n-fran...@ti.com/
-#endif
-#ifdef CONFIG_ESM_PMIC
- if (board_ti_k3_is("J721EX-PM2-SOM")) {
+ if (IS_ENABLED(CONFIG_ESM_PMIC)) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(pmic_esm),
&dev);
if (ret)
printf("ESM PMIC init failed: %d\n", ret);
}
-#endif
if ((IS_ENABLED(CONFIG_TARGET_J7200_A72_EVM) ||
IS_ENABLED(CONFIG_TARGET_J721E_A72_EVM)) &&
IS_ENABLED(CONFIG_HBMC_AM654)) {
struct udevice *dev;
Re: [PATCH 01/15] arm: mach-k3: j721e: Improve support for UDA FS
On 11/3/2023 6:07 AM, Nishanth Menon wrote:
Commit 5019170970ad ("arch: arm: mach-k3: j721e: add support for UDA
FS") introduced basic UDA FS support, however, we can Take approach
similar to commit 0f1c1e8b368b ("arm: mach-k3: am625: Add support for
UDA FS"). While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
I am thinking, in which case we have EMMC_BOOT disabled,
Case here I am considering, updating u-boot to eMMC from u-boot shell,
If EMMC_BOOT
is not set then , we can not set CSD information
Signed-off-by: Nishanth Menon
---
arch/arm/mach-k3/j721e_init.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index b1f7e25ed092..bcdfbfc79c4a 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -294,7 +294,14 @@ u32 spl_mmc_boot_mode(struct mmc *mmc, const u32
boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
- return (spl_mmc_emmc_boot_partition(mmc) ? MMCSD_MODE_EMMCBOOT
: MMCSD_MODE_FS);
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) {
+ if (spl_mmc_emmc_boot_partition(mmc))
+ return MMCSD_MODE_EMMCBOOT;
+ return MMCSD_MODE_FS;
+ }
I had a view EMMC_BOOT should be needed config.
+ if (IS_ENABLED(CONFIG_SPL_FS_FAT) ||
IS_ENABLED(CONFIG_SPL_FS_EXT4))
+ return MMCSD_MODE_FS;
+ return MMCSD_MODE_EMMCBOOT;
If you consider, to make EMMC_BOOT as needed config, then this is not needed
case BOOT_DEVICE_MMC2:
return MMCSD_MODE_FS;
default:
Re: [RESEND PATCH] board: ti: common: board_detect: Fix EEPROM offset read for 1-byte
Thanks Prasanth
On 10/20/2023 12:31 PM, Prasanth Babu Mantena wrote:
EEPROM detection logic in ti_i2c_eeprom_get() involves reading the total
size followed by reading 1-byte size with an offset 1. This commit fixes
the header matching issue in commit 9f393a2d7af8 ("board: ti: common:
board_detect: Fix EEPROM read quirk for 2-byte").
You can fixes below as well. I think you can avoid this in commit message
In the previous commit, the value with one offset is being read into
offset_test, but the pointer used to match was still ep. After reading
with an offset 1, the second byte of the header is compared with the 1-byte
data read from EEPROM. This is taken care by comparing proper first byte
value from the header.
Nice catch
Signed-off-by: Prasanth Babu Mantena
Fixes: 9f393a2d7af8 (board: ti: common: board_detect: Fix EEPROM read quirk for
2-byte)
Please consider Fixes line, first than Signed-off-by
Please copy Nishanth in patch as well .
---
Resending due to incorrect patch tag last time.
board/ti/common/board_detect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index 9a53884c98..17fe8f8069 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -128,7 +128,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
rc = dm_i2c_read(dev, 0x1, &offset_test, sizeof(offset_test));
- if (*((u32 *)ep) != (header & 0xFF))
+ if (offset_test != ((header >> 8) & 0xFF))
one_byte_addressing = false;
/* Corrupted data??? */
Re: [PATCH] arm: dts: k3-j721e-mcu-wakeup: Add MCU domain ESM instance
On 10/13/2023 3:59 PM, Neha Malcom Francis wrote:
Currently J721E defines only the main_esm in DTS. Add node for mcu_esm
as well.
According to J721E TRM (12.11.2.2 ESM Environment) [1], we see that the
interrupt line from ESMi (main_esm) is routed to MCU_ESM (mcu_esm). This
is MCU_ESM0_LVL_IN_95 with interrupt ID 95. Configure mcu_esm
accordingly so that errors from main_esm are routed to mcu_esm and
handled.
[1] https://www.ti.com/lit/zip/spruil1
Signed-off-by: Neha Malcom Francis
---
Upstream kernel effort:
https://lore.kernel.org/lkml/20230926142810.602384-1-n-fran...@ti.com/
should part of next u-boot, kernel sync, no?
arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
index 05d6ef127b..fa8af20c78 100644
--- a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
@@ -671,4 +671,11 @@
power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
#thermal-sensor-cells = <1>;
};
+
+ mcu_esm: esm@4080 {
+ compatible = "ti,j721e-esm";
+ reg = <0x00 0x4080 0x00 0x1000>;
+ ti,esm-pins = <95>;
+ bootph-pre-ram;
+ };
};
Re: [PATCH RFC 10/10] board: ti: j721e: Enable ESM initialization for J7200
On 10/3/2023 1:40 PM, Keerthy wrote:
Enable ESM initialization for J7200
Signed-off-by: Keerthy
---
board/ti/j721e/evm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 42fa94b7a5..070b28326f 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -543,7 +543,8 @@ void spl_board_init(void)
}
#ifdef CONFIG_ESM_K3
- if (board_ti_k3_is("J721EX-PM2-SOM")) {
+ if ((board_ti_k3_is("J721EX-PM2-SOM")) ||
+ IS_ENABLED(CONFIG_TARGET_J7200_R5_EVM)) {
Could we align on one kind of check, For J721E check is done against
board-id, whereas for J7200 checking
for config option.
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(k3_esm), &dev);
if (ret)
@@ -557,7 +558,8 @@ void spl_board_init(void)
#endif
#ifdef CONFIG_ESM_PMIC
- if (board_ti_k3_is("J721EX-PM2-SOM")) {
+ if ((board_ti_k3_is("J721EX-PM2-SOM")) ||
+ IS_ENABLED(CONFIG_TARGET_J7200_R5_EVM)) {
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(pmic_esm),
&dev);
Re: [RFC PATCH v2 0/3] thermal: Integrate VTM and AVS driver
Dear All, On 9/8/2023 10:59 PM, Udit Kumar wrote: VTM (Voltage and Thermal Manager) IP is used for following purpose 1) AVS class 0 2) Thermal management (setting thermal shutdown TSHUT) temperature. 3) SoC temperature reporting. In origin boot flow, R5/SPL sets the AVS voltage using by AVS driver, residing under UCLASS_MISC. In this series At top level, following changes are done - Moved avs driver to Thermal class - Ported kernel driver (drivers/thermal/k3_j72xx_bandgap.c) which supports TSHUT and temperature reporting - Merged these two driver as one under UCLASS_THERMAL. This series aims to - set avs and thermal shutdown at R5/SPL stage - At main u-boot stage, support thermal shutdown and temperature reporting Also, j72xx_bandgap does complex math to get ADC value to temperature conversion, This table is pretty static. So at R5 SPL stage, instead of calculation, fixed values is used for TSHUT values. and #ifdef is used skip non needed code for SPL/R5 to reduce code size. Kindly review and provide feedback, if this approach looks ok. Thanks Udit Change log Changes in v2: v1 : https://lore.kernel.org/all/20230901061500.2342452-1-u-kum...@ti.com/ - Trying to merge AVS and kernel driver into 1 - Mark as RFC Udit Kumar (3): thermal: k3: Add support for thermal in vtm arm: mach-k3: update board file to use thermal device arm: dts: k3: update device tree for vtm node arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 9 + .../arm/dts/k3-j7200-r5-common-proc-board.dts | 6 - arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 10 + .../arm/dts/k3-j721e-r5-common-proc-board.dts | 7 - arch/arm/dts/k3-j721e-r5-sk.dts | 7 - arch/arm/mach-k3/am654_init.c | 2 +- arch/arm/mach-k3/j721e_init.c | 2 +- configs/am65x_evm_r5_defconfig| 3 + configs/am65x_evm_r5_usbdfu_defconfig | 3 + configs/am65x_evm_r5_usbmsc_defconfig | 3 + configs/am65x_hs_evm_r5_defconfig | 3 + configs/j7200_evm_a72_defconfig | 3 + configs/j7200_evm_r5_defconfig| 3 + configs/j721e_evm_a72_defconfig | 3 + configs/j721e_evm_r5_defconfig| 3 + drivers/misc/Makefile | 1 - drivers/misc/k3_avs.c | 394 drivers/thermal/Kconfig | 7 + drivers/thermal/Makefile | 1 + drivers/thermal/k3_thermal.c | 928 ++ 20 files changed, 981 insertions(+), 417 deletions(-) delete mode 100644 drivers/misc/k3_avs.c create mode 100644 drivers/thermal/k3_thermal.c
Re: [PATCH 0/2] arm64: ti: k3-j7: Add the ESM nodes
Hi Keerthy On 9/25/2023 7:12 PM, Nishanth Menon wrote: On 18:56-20230925, Keerthy wrote: Hi Tom, https://lore.kernel.org/linux-arm-kernel/5187c590-ee9a-4c46-b326-655f4c371...@linaro.org/T/#me178708007a6b3b9695ae0ff84475fa4f49f283c I have posted the ESM patches to the linux kernel device tree mailing list. These are neeeded in R5 SPL to enable watchdog support. Keerthy (2): arm64: dts: ti: k3-j721s2: Add ESM instances arm64: dts: ti: k3-j7200: Add MCU domain ESM instance arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 7 +++ arch/arm/dts/k3-j721s2-main.dtsi | 7 +++ arch/arm/dts/k3-j721s2-mcu-wakeup.dtsi | 14 ++ 3 files changed, 28 insertions(+) Get this as part of kernel dt sync. Meanwhile, can i request you to post changes needed in u-boot source, May as RFC or so. Thanks
Re: [PATCH] lmb: remove overlapping region with next range
Thanks Simon On 9/25/2023 9:39 PM, Simon Glass wrote: Hi Udit, On Sun, 24 Sept 2023 at 22:10, Kumar, Udit wrote: On 9/24/2023 7:21 PM, Heinrich Schuchardt wrote: Am 24. September 2023 13:18:32 MESZ schrieb Udit Kumar : [..] Assumption Thanks Heinrich will fix this typo in v2. Let me wait for other review feedback as well before proceeding for v2. Regards Heinrich [..] Can you please add a test to test/lib which fails before your change and passes after? Sure, will add test case. Regards, Simon
Re: [PATCH] lmb: remove overlapping region with next range
Hi Mark/Tom On 9/25/2023 9:01 PM, Tom Rini wrote: On Mon, Sep 25, 2023 at 05:27:26PM +0200, Mark Kettenis wrote: Date: Mon, 25 Sep 2023 11:21:26 -0400 From: Tom Rini On Sun, Sep 24, 2023 at 04:48:32PM +0530, Udit Kumar wrote: In case of new memory range to be added is coalesced with any already added non last lmb region. And there is possibility that, then region in which new memory range added is not adjacent to next region. But have some sections are overlapping. So along with adjacency check with next lmb region, check for overlap should be done. In case overlap is found, adjust and merge these two lmb region into one. Reported-by: Suman Anna Signed-off-by: Udit Kumar This is good! I wonder if this addresses the issue that has caused other platforms to need to set CONFIG_LMB_MAX_REGIONS=64 and I'm wondering if any of the other maintainers I've cc'd here can drop back to the default number of regions and then re-test their failure case? Thanks! Hi Tom, For the Apple M1 systems I don't think it makes sense to reduce the number of regions. These systems don't have TPL or SPL, have plenty of memory (at least 8GB) and are really fast. And we anticipate that the number of memory regions will only grow in the future. This partly gets at what I see as part of the problem. It's been unclear to me if it's reasonable to just bump the default to 64 for aarch64 (and riscv?) because the problem is that 16 is truly too small, or given what we're doing we still don't need a ton of LMB regions as at the end of the day things should be coalesced in to just a few and it's been an underlying bug in an area everyone assumed wasn't buggy. Did we observed overlapped memory regions added in lmb region ? which leads to increase in default number of regions.
Re: [PATCH v3 0/3] enable power and clock Kconfig conditionally
Hi Tom, On 9/13/2023 10:09 AM, Udit Kumar wrote: This series, updates enabling mutually exclusive power and clock configs for TI SOCs. Sorry to push clock and power changes in one series, managed by two maintainers. But In my quick grep, I am not able to active PR raise from both trees. So copying maintainers of clock and power for review. Change log Changes in v3: - Patch 1 and 2: Added reviewed by - Patch 3: Corrected Fixes in commit message link to v2: https://lore.kernel.org/all/20230912130645.1202325-1-u-kum...@ti.com/ Changes in v2: - Patch 1 and 2) Added conditional support to enable Kconfig - Patch 3 No change link to v1: https://lore.kernel.org/all/2023091946.749270-1-u-kum...@ti.com/ Udit Kumar (3): power: domain: ti: Enable single config for power domain clk: ti: Add support to enable configs conditionally config: j7200: remove not needed power config NAK, One of boot mode (OSPI) is not working with this series on J7200, Please don't merge this series, Let me fix OSPI boot and re-roll this series Thanks Udit configs/j7200_evm_r5_defconfig | 1 - drivers/clk/ti/Kconfig | 8 drivers/power/domain/Kconfig | 2 +- 3 files changed, 5 insertions(+), 6 deletions(-)
Re: [PATCH] binman: openssl: x509: ti_secure_rom: Add support for bootcore_opts
On 9/22/2023 2:45 PM, Neha Malcom Francis wrote:
According to the TRMs of K3 platform of devices, the ROM boot image
Below tear line, giving some link of TRM, with section information
where this format is mentioned will be helpful for reviewers.
format specifies a "Core Options Field" that provides the capability to
set the Dual MCU present to lockstep when set to 0 or to split mode when
'Dual MCU present to' or 'Boot core in' or 'Boot MCU in'
set to 2. Add support for providing the same from the binman DTS. Also
modify existing test case for ensuring future coverage.
Signed-off-by: Neha Malcom Francis
---
tools/binman/btool/openssl.py | 6 --
tools/binman/etype/ti_secure_rom.py | 12 ++--
tools/binman/etype/x509_cert.py | 3 ++-
tools/binman/test/297_ti_secure_rom.dts | 1 +
4 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index aad3b61ae2..86cc56fbd7 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -155,6 +155,7 @@ authInPlace = INTEGER:2
C, ST, L, O, OU, CN and emailAddress
cert_type (int): Certification type
bootcore (int): Booting core
+bootcore_opts(int): Booting core option (split/lockstep mode)
load_addr (int): Load address of image
sha (int): Hash function
@@ -225,7 +226,7 @@ emailAddress = {req_dist_name_dict['emailAddress']}
imagesize_sbl, hashval_sbl, load_addr_sysfw,
imagesize_sysfw,
hashval_sysfw, load_addr_sysfw_data, imagesize_sysfw_data,
hashval_sysfw_data, sysfw_inner_cert_ext_boot_block,
- dm_data_ext_boot_block):
+ dm_data_ext_boot_block, bootcore_opts):
"""Create a certificate
Args:
@@ -241,6 +242,7 @@ emailAddress =
{req_dist_name_dict['emailAddress']}
bootcore (int): Booting core
load_addr (int): Load address of image
sha (int): Hash function
+bootcore_opts (int): Boot core option (split/lockstep mode)
Returns:
str: Tool output
@@ -285,7 +287,7 @@ sysfw_data=SEQUENCE:sysfw_data
[sbl]
compType = INTEGER:1
bootCore = INTEGER:16
-compOpts = INTEGER:0
+compOpts = INTEGER:{bootcore_opts}
destAddr = FORMAT:HEX,OCT:{load_addr:08x}
compSize = INTEGER:{imagesize_sbl}
shaType = OID:{sha_type}
diff --git a/tools/binman/etype/ti_secure_rom.py
b/tools/binman/etype/ti_secure_rom.py
index 9a7ac9e9e0..780f132ea5 100644
--- a/tools/binman/etype/ti_secure_rom.py
+++ b/tools/binman/etype/ti_secure_rom.py
@@ -32,6 +32,7 @@ class Entry_ti_secure_rom(Entry_x509_cert):
- core: core on which bootloader runs, valid cores are 'secure' and
'public'
- content: phandle of SPL in case of legacy bootflow or phandles of
component binaries
in case of combined bootflow
+- bootcore_opts (optional): split-mode (0) or lockstep mode (1) set to
0 by default
The following properties are only for generating a combined bootflow binary:
- sysfw-inner-cert: boolean if binary contains sysfw inner certificate
@@ -69,6 +70,7 @@ class Entry_ti_secure_rom(Entry_x509_cert):
self.sw_rev = fdt_util.GetInt(self._node, 'sw-rev', 1)
self.sha = fdt_util.GetInt(self._node, 'sha', 512)
self.core = fdt_util.GetString(self._node, 'core', 'secure')
+self.bootcore_opts = fdt_util.GetInt(self._node, 'core-opts')
self.key_fname = self.GetEntryArgsOrProps([
EntryArg('keyfile', str)], required=True)[0]
if self.combined:
@@ -103,11 +105,14 @@ class Entry_ti_secure_rom(Entry_x509_cert):
else:
self.cert_type = 2
self.bootcore = 0
-self.bootcore_opts = 32
+if self.bootcore_opts is None:
+self.bootcore_opts = 32
else:
self.cert_type = 1
self.bootcore = 16
-self.bootcore_opts = 0
+if self.bootcore_opts is None:
+self.bootcore_opts = 0
+
return super().GetCertificate(required=required, type='rom')
def CombinedGetCertificate(self, required):
@@ -126,6 +131,9 @@ class Entry_ti_secure_rom(Entry_x509_cert):
self.num_comps = 3
self.sha_type = SHA_OIDS[self.sha]
+if self.bootcore_opts is None:
+self.bootcore_opts = 0
+
# sbl
self.content = fdt_util.GetPhandleList(self._node, 'content-sbl')
input_data_sbl = self.GetContents(required)
diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
index d028cfe38c..fc0bb12278 100644
--- a/tools/binman/etype/x509_cert.py
+++ b/tools/binman/etype/x509_cert.py
@@ -136,7 +136,8 @@ class Entry_x509_cert(Entry_collection):
Re: [PATCH] lmb: remove overlapping region with next range
On 9/24/2023 7:21 PM, Heinrich Schuchardt wrote:
Am 24. September 2023 13:18:32 MESZ schrieb Udit Kumar :
In case of new memory range to be added is coalesced
with any already added non last lmb region.
And there is possibility that, then region in which new memory
range added is not adjacent to next region. But have some
sections are overlapping.
So along with adjacency check with next lmb region,
check for overlap should be done.
In case overlap is found, adjust and merge these two lmb
region into one.
Reported-by: Suman Anna
Signed-off-by: Udit Kumar
---
logs
https://gist.github.com/uditkumarti/5d08c34442235ad270cfa863792ebcdc
seqeunce : line 1 to 13
without fix : line 96-100
with fix : line 199-202
lib/lmb.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index b2c233edb6..2580d01d90 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -74,6 +74,16 @@ static long lmb_addrs_adjacent(phys_addr_t base1,
phys_size_t size1,
return 0;
}
+static long lmb_regions_overlap(struct lmb_region *rgn, unsigned long r1,
+ unsigned long r2)
+{
+ phys_addr_t base1 = rgn->region[r1].base;
+ phys_size_t size1 = rgn->region[r1].size;
+ phys_addr_t base2 = rgn->region[r2].base;
+ phys_size_t size2 = rgn->region[r2].size;
+
+ return lmb_addrs_overlap(base1, size1, base2, size2);
+}
static long lmb_regions_adjacent(struct lmb_region *rgn, unsigned long r1,
unsigned long r2)
{
@@ -81,7 +91,6 @@ static long lmb_regions_adjacent(struct lmb_region *rgn,
unsigned long r1,
phys_size_t size1 = rgn->region[r1].size;
phys_addr_t base2 = rgn->region[r2].base;
phys_size_t size2 = rgn->region[r2].size;
-
return lmb_addrs_adjacent(base1, size1, base2, size2);
}
@@ -105,6 +114,23 @@ static void lmb_coalesce_regions(struct lmb_region *rgn,
unsigned long r1,
lmb_remove_region(rgn, r2);
}
+/*Assmptuon : base addr of region 1 < base addr of region 2*/
Assumption
Thanks Heinrich will fix this typo in v2.
Let me wait for other review feedback as well before proceeding for v2.
Regards Heinrich
+static void lmb_fix_over_lap_regions(struct lmb_region *rgn, unsigned long r1,
+unsigned long r2)
+{
+ phys_addr_t base1 = rgn->region[r1].base;
+ phys_size_t size1 = rgn->region[r1].size;
+ phys_addr_t base2 = rgn->region[r2].base;
+ phys_size_t size2 = rgn->region[r2].size;
+
+ if (base1 + size1 > base2 + size2) {
+ printf("This will not be a case any time\n");
+ return;
+ }
+ rgn->region[r1].size = base2 + size2 - base1;
+ lmb_remove_region(rgn, r2);
+}
+
void lmb_init(struct lmb *lmb)
{
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
@@ -249,7 +275,6 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
phys_size_t rgnflags = rgn->region[i].flags;
phys_addr_t end = base + size - 1;
phys_addr_t rgnend = rgnbase + rgnsize - 1;
-
if (rgnbase <= base && end <= rgnend) {
if (flags == rgnflags)
/* Already have this region, so we're done */
@@ -278,10 +303,14 @@ static long lmb_add_region_flags(struct lmb_region *rgn,
phys_addr_t base,
}
}
- if ((i < rgn->cnt - 1) && lmb_regions_adjacent(rgn, i, i + 1)) {
- if (rgn->region[i].flags == rgn->region[i + 1].flags) {
+ if (i < rgn->cnt - 1 && rgn->region[i].flags == rgn->region[i +
1].flags) {
+ if (lmb_regions_adjacent(rgn, i, i + 1)) {
lmb_coalesce_regions(rgn, i, i + 1);
coalesced++;
+ } else if (lmb_regions_overlap(rgn, i, i + 1)) {
+ /* fix overlapping area */
+ lmb_fix_over_lap_regions(rgn, i, i + 1);
+ coalesced++;
}
}
Looking for suggestion on using above 4G memory on ARM64
Dear Experts, I am looking for suggestion/guidance, how to use above 4G memory on in u-boot for ARM 64-bit based architecture. On our system, we have low memory from 0x8000_ to 0x_ and above 4G 0x8_8000_ to 0x8__ As per my understanding, we have following pointers in u-boot ram_base, ram_top , ram_size If I keep, above this variables within low memory ie. ram_base = 0x8000_, ram_top = 0x1__, ram_size = 0x1__ boot is successful, but when I am moving to high memory like ram_base = 0x8000_, ram_top = 0x9__, ram_size = 0x2__ boot is failing while reallocation for obvious reasons, Question, I have for which I am looking for advise . If memory is divided in into two zones, then how we can fit memory using above three variables. Or is there some other config, which I am missing. Many Thanks Udit P.S. :I noticed few other ARM64 arch restrict gd->ram_top to 0x1__
Re: [PATCH v3] clk: ti: Notify AVS driver upon setting clock rate
Thanks Nishanth On 9/20/2023 5:50 PM, Nishanth Menon wrote: On 17:32-20230920, Udit Kumar wrote: AVS is enabled at R5 SPL stage, on few platforms like J721E and J7200 clk-k3 is used instead if clk-sci driver. [...] I think it is better to put IS_ENABLED() as the first check. See other usage: $ git grep IS_ENABLED . |grep if|grep '&&' will address in next version [..] First look - it looks fine, but note: these are two different patches. the clk-sci.c is a fix for an existing implementation and clk-k3.c is a new feature addition. please don't mix the two. Sure, Let me send two patches then, One for new implementation clk-k3.c version v4. and another for clk-sci.c with Fixes tag.
Re: [PATCH v2] clk: ti: Notify AVS driver upon setting clock rate
Hi Nishanth, On 9/19/2023 9:07 PM, Nishanth Menon wrote: On 19:34-20230919, Udit Kumar wrote: AVS is enabled at R5 SPL stage, on few platforms like J721E and J7200 clk-k3 is used instead if clk-sci driver. Add support in clk-k3 driver as well to notify AVS driver upon setting clock rate so that voltage is changed accordingly. Cc: Keerthy Signed-off-by: Udit Kumar --- Change log: Changes in v2: - Kept clk-sci.c as is because this is used by AM64 and AM65 platforms - v1 link https://lore.kernel.org/all/20230919060649.2518147-1-u-kum...@ti.com/ drivers/clk/ti/clk-k3.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/clk/ti/clk-k3.c b/drivers/clk/ti/clk-k3.c index ba925fa3c4..8016c3784a 100644 --- a/drivers/clk/ti/clk-k3.c +++ b/drivers/clk/ti/clk-k3.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "k3-clk.h" #define PLL_MIN_FREQ 8 @@ -339,6 +340,10 @@ static ulong ti_clk_set_rate(struct clk *clk, ulong rate) } } + if (IS_ENABLED(CONFIG_K3_AVS0)) + k3_avs_notify_freq(data->map[clk->id].dev_id, + data->map[clk->id].clk_id, rate); + Don't you want to do this prior to actual clock change? Not really, As i see new freq to be less than current one. F1, V1 -> F2, V2 Seq 1: F1, V1 F2, V1 F2, V2 Seq 2: F1, V1 F1, V2 F2, V2 If V2 < V1 (implying F2 < F1), then Seq 1 is valid. But if V2 > V1 (F2 > F1) Seq 2 is valid. We seem to ignore this constraint. Can you explain this in the commit message? Sure, will do , Below is reasoning, Please see if make sense On J7 devices, In default device tree, A72 freq is set to 2Ghz, few SOCs can operate at lower freq. So while setting OPP freq (which is less than default one), First freq needs to set before changing voltage. On other hand, I am thinking to fix properly for both cases, irrespective of seq 1 is valid for current use case. clk-sci.c seems to use Seq 2, vs this patch seems to take Seq 1. I think, something to be fixed for clk-sci.c as well. As I see three freq point https://elixir.bootlin.com/u-boot/latest/source/drivers/misc/k3_avs.c#L339 So we can choose either way new-freq > current-freq or new-freq < current-freq, Based upon new-freq , voltage to be set before/after clock change. return new_rate; } -- 2.34.1
Re: [PATCH] clk: ti: Notify AVS driver upon setting clock rate
On 9/19/2023 4:44 PM, Nishanth Menon wrote:
On 11:36-20230919, Udit Kumar wrote:
AVS is enabled at R5 SPL stage, where clk-k3 is used
instead if clk-sci driver.
[..]
Why drop from here? we do have am64 and am65 that use ti-sci, correct?
Thanks,
am64/am65 slipped out of my mind while creating this patch.
will fix in v2.
ret = cops->set_freq(sci, clk->id, clk->data, 0, rate, ULONG_MAX);
if (ret) {
dev_err(clk->dev, "%s: set_freq failed (%d)\n", __func__, ret);
--
2.34.1
RE: [PATCH v3 06/16] remoteproc: k3-r5: Extend support for R5F clusters on J784S4 SoCs
Hi Roger
>
>
>On 08/09/2023 14:05, Apurva Nandan wrote:
>> From: Hari Nagalla
>>
>> The K3 J784S4 SoCs have four dual-core R5F subsystems, one in MCU
>> voltage domain and the other three in MAIN voltage domain. These R5F
>> clusters are similar to the R5F clusters in J7200 and J721S2 SoCs.
>>
>> Extend support to the R5F clusters for J784S4 with J721S2 compatible
>> string.
>>
>> Signed-off-by: Hari Nagalla
>> Signed-off-by: Apurva Nandan
>> ---
>> drivers/remoteproc/ti_k3_r5f_rproc.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c
>> b/drivers/remoteproc/ti_k3_r5f_rproc.c
>> index 6f3e12d915..631e548dcc 100644
>> --- a/drivers/remoteproc/ti_k3_r5f_rproc.c
>> +++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
>> @@ -855,7 +855,7 @@ static const struct k3_r5f_ip_data k3_data = {
>> .tcm_ecc_autoinit = false,
>> };
>>
>> -static const struct k3_r5f_ip_data j7200_data = {
>> +static const struct k3_r5f_ip_data j7200_j721s2_data = {
>
>No need to rename this.
>
>> .tcm_is_double = true,
>> .tcm_ecc_autoinit = true,
>> };
>> @@ -863,7 +863,8 @@ static const struct k3_r5f_ip_data j7200_data = {
>> static const struct udevice_id k3_r5f_rproc_ids[] = {
>> { .compatible = "ti,am654-r5f", .data = (ulong)&k3_data, },
>> { .compatible = "ti,j721e-r5f", .data = (ulong)&k3_data, },
>> -{ .compatible = "ti,j7200-r5f", .data = (ulong)&j7200_data, },
>> +{ .compatible = "ti,j7200-r5f", .data = (ulong)&j7200_j721s2_data, },
>> +{ .compatible = "ti,j721s2-r5f", .data = (ulong)&j7200_j721s2_data,
>> +},
>
>Where is DT binding documentation for this?
Please see
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml#L45
>Don't you need compatible for ti,j728s4-r5f?
If IP is same then we should use available compatible,
In long term, we should dis-associate name of IP with name of silicon
Thanks
>> {}
>> };
>>
>> @@ -901,6 +902,7 @@ static const struct udevice_id k3_r5fss_ids[] = {
>> { .compatible = "ti,am654-r5fss"},
>> { .compatible = "ti,j721e-r5fss"},
>> { .compatible = "ti,j7200-r5fss"},
>> +{ .compatible = "ti,j721s2-r5fss"},
>> {}
>> };
>>
>
>--
>cheers,
>-roger
Re: [PATCH] config: j7200: removed not needed power config
Thank you for suggestion Nishanth On 9/11/2023 6:51 PM, Nishanth Menon wrote: On 16:49-20230911, Udit Kumar wrote: [..] And maybe expand this patch so that it contains something like the following to prevent this from coming back again elsewhere? diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig index fbcdefd889ae..aff1ba5ab43b 100644 --- a/drivers/clk/ti/Kconfig +++ b/drivers/clk/ti/Kconfig @@ -36,7 +36,7 @@ config CLK_TI_MUX config CLK_TI_SCI bool "TI System Control Interface (TI SCI) clock driver" - depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL + depends on CLK && TI_SCI_PROTOCOL && OF_CONTROL && !CLK_K3 help This enables the clock driver support over TI System Control Interface available on some new TI's SoCs. If you wish to use clock resources @@ -44,24 +44,24 @@ config CLK_TI_SCI [..] config CLK_K3 bool "Clock support for K3 SoC family of devices" - depends on CLK + depends on CLK && !CLK_TI_SCI help Enables the clock translation layer from DT to device clocks. I think these may end up recursive dependency diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig index 411c210756a3..9625764b304b 100644 --- a/drivers/power/domain/Kconfig +++ b/drivers/power/domain/Kconfig @@ -92,14 +92,14 @@ config TEGRA186_POWER_DOMAIN config TI_SCI_POWER_DOMAIN bool "Enable the TI SCI-based power domain driver" - depends on POWER_DOMAIN && TI_SCI_PROTOCOL + depends on POWER_DOMAIN && TI_SCI_PROTOCOL && !TI_POWER_DOMAIN help Generic power domain implementation for TI devices implementing the TI SCI protocol. config TI_POWER_DOMAIN bool "Enable the TI K3 Power domain driver" - depends on POWER_DOMAIN && ARCH_K3 + depends on POWER_DOMAIN && ARCH_K3 && !TI_SCI_POWER_DOMAIN help Generic power domain implementation for TI K3 devices. and these too.
Re: [PATCH 1/3] drivers: misc: k3_avs: Add Linux compatible to enable avs in u-boot
On 9/7/2023 12:58 AM, reidt wrote:
On 13:06-20230906, Nishanth Menon wrote:
On 13:13-20230905, Reid Tonking wrote:
The ti,j7200-vtm compatible is used for voltage and thermal monitoring
(VTM) by (drivers/thermal/k3_j72xx_bandgap.c) in Linux, but the same
hardware is used for adaptive voltage scaling (AVS) in u-boot, This brings
both drivers in line with the same compatible. Since the j7200 uses the
config as the j721e, the data is inherited from j721e vs creating a
duplicate in all but name.
Signed-off-by: Reid Tonking
---
drivers/misc/k3_avs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
index 840148d090..f7936017ba 100644
--- a/drivers/misc/k3_avs.c
+++ b/drivers/misc/k3_avs.c
@@ -382,7 +382,7 @@ static struct vd_config am654_vd_config = {
static const struct udevice_id k3_avs_ids[] = {
{ .compatible = "ti,am654-avs", .data = (ulong)&am654_vd_config },
{ .compatible = "ti,j721e-avs", .data = (ulong)&j721e_vd_config },
- {}
+ { .compatible = "ti,j7200-vtm", .data = (ulong)&j721e_vd_config }
you don't need the null terminator?
Ah, I wasn't aware of its purpose until now, but searched it up.
I'll add it back in for v3.
};
U_BOOT_DRIVER(k3_avs) = {
--
2.34.1
https://lore.kernel.org/all/1fed9388-dfc4-0b9c-4502-b5020b2ae...@ti.com/
Will let Udit and you sort this out.
Udit and I talked a bit about this yesterday. It's something to explore
implementing down the road, after this sync - nothing immediate
Integration of TSHUT or porting of bandgap driver into this driver is
incremental work.
So change of name is compatible for this series is ok.
Thanks
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Thanks,
Reid Tonking
Re: [PATCH 1/2] thermal: k3-j72xx-bandgap: Add support for vtm
Hi Nishanth,
On 9/2/2023 12:40 AM, Nishanth Menon wrote:
On 23:43-20230901, Kumar, Udit wrote:
On 9/1/2023 11:03 PM, Nishanth Menon wrote:
On 22:54-20230901, Kumar, Udit wrote:
+static const struct udevice_id of_k3_j72xx_bandgap_match[] = {
+ {
+ .compatible = "ti,j721e-vtm",
+ .data = (ulong)&k3_j72xx_bandgap_j721e_data,
So what happens to drivers/misc/k3_avs.c ?
Could you help me to understand this comment.
Do you mean, why we can not add this support in AVS driver or
need of this porting ?
How I see, AVS driver to run at SPL/R5 time and this driver
to be probed in Main/A72 u-boot when needed.
you are saying the drivers are mutually exclusive - how about detecting
over-temp scenario at R5 boot? switching on A53 will be a mistake at
that point, no?
Yes these are mutually exclusive.
Let me see, how I can add TSHUT value programming in avs driver to avoid
above.
But in case, temperature reading is needed from u-boot shell, we still need
this code.
One approach might be to merge the two.
I think merging of these two feature could be done in one file, as one
driver or two.
But on execution/feature side, from R5/SPL we need to set voltage for
A72 (OPP or AVS) before
releasing A72 core. Also can program TSHUT value for thermal overrun
protection.
For A72/Main u-boot, provide function of temperature reporting from shell.
Re: [PATCH 1/2] thermal: k3-j72xx-bandgap: Add support for vtm
On 9/1/2023 11:03 PM, Nishanth Menon wrote:
On 22:54-20230901, Kumar, Udit wrote:
+static const struct udevice_id of_k3_j72xx_bandgap_match[] = {
+ {
+ .compatible = "ti,j721e-vtm",
+ .data = (ulong)&k3_j72xx_bandgap_j721e_data,
So what happens to drivers/misc/k3_avs.c ?
Could you help me to understand this comment.
Do you mean, why we can not add this support in AVS driver or
need of this porting ?
How I see, AVS driver to run at SPL/R5 time and this driver
to be probed in Main/A72 u-boot when needed.
you are saying the drivers are mutually exclusive - how about detecting
over-temp scenario at R5 boot? switching on A53 will be a mistake at
that point, no?
Yes these are mutually exclusive.
Let me see, how I can add TSHUT value programming in avs driver to avoid
above.
But in case, temperature reading is needed from u-boot shell, we still
need this code.
Re: [PATCH 1/2] thermal: k3-j72xx-bandgap: Add support for vtm
Hi Nishanth
On 9/1/2023 8:36 PM, Nishanth Menon wrote:
On 11:44-20230901, Udit Kumar wrote:
Add support for VTM (Voltage and Thermal Manager), which
is part of TI's K3 series SOC.
Signed-off-by: Udit Kumar
---
drivers/thermal/Kconfig| 6 +
drivers/thermal/Makefile | 1 +
drivers/thermal/k3_j72xx_bandgap.c | 539 +
3 files changed, 546 insertions(+)
create mode 100644 drivers/thermal/k3_j72xx_bandgap.c
[..]
+
+static const struct udevice_id of_k3_j72xx_bandgap_match[] = {
+ {
+ .compatible = "ti,j721e-vtm",
+ .data = (ulong)&k3_j72xx_bandgap_j721e_data,
So what happens to drivers/misc/k3_avs.c ?
Could you help me to understand this comment.
Do you mean, why we can not add this support in AVS driver or
need of this porting ?
How I see, AVS driver to run at SPL/R5 time and this driver
to be probed in Main/A72 u-boot when needed.
+ },
+ {
+ .compatible = "ti,j7200-vtm",
+ .data = (ulong)&k3_j72xx_bandgap_j7200_data,
+ },
+ { /* sentinel */ },
+};
+
+U_BOOT_DRIVER(ti_bandgap_thermal) = {
+ .name = "ti_bandgap_thermal",
+ .id = UCLASS_THERMAL,
+ .ops= &k3_of_thermal_ops,
+ .probe = k3_j72xx_bandgap_probe,
+ .of_match = of_k3_j72xx_bandgap_match,
+ .priv_auto = sizeof(struct k3_j72xx_bandgap),
+};
--
2.34.1
Re: [PATCH 1/3] k3-j721s2: Sync from linux-next tag next-20230815
On 8/17/2023 5:06 PM, Nishanth Menon wrote:
On 09:45-20230817, Kumar, Udit wrote:
On 8/16/2023 5:14 PM, Nishanth Menon wrote:
On 14:53-20230816, Manorit Chawdhry wrote:
The following commit syncs the device tree from Linux tag
next-20230815 to U-boot and fixes the following to be compatible with
the future syncs -
[..]
+&mcu_timer0 {
+ /delete-property/ power-domains;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
NAK - this should come in from R5 data.
Having clock data for R5 will not help atleast for timer.
As timer is getting probed before the clk frame work comes up ,
Well, u-boot framework is no different in AM625, is'nt it?
https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/k3-am625-sk-u-boot.dtsi#L28
it does work. tells me there is some thing we are'nt pinpointing here.
This is what I am wondering, how AM625 works.
I don't see clock-data for main_timer0 in clk-data.c file.
Also if clock-frame is being used, I see no need of below
clock-frequency = <2500>;
Re: [PATCH 1/3] k3-j721s2: Sync from linux-next tag next-20230815
On 8/16/2023 5:14 PM, Nishanth Menon wrote:
On 14:53-20230816, Manorit Chawdhry wrote:
The following commit syncs the device tree from Linux tag
next-20230815 to U-boot and fixes the following to be compatible with
the future syncs -
[..]
+&mcu_timer0 {
+ /delete-property/ power-domains;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
NAK - this should come in from R5 data.
Having clock data for R5 will not help atleast for timer.
As timer is getting probed before the clk frame work comes up ,
you should just have:
&mcu_timer0 {
clock-frequency = <25000>;
bootph-pre-ram;
};
Introduce the required data into the power / clock data for R5.
A72 side should just work fine with this since DM should be up and
running by this time.
This timer is not included in A72 ,
so i suggest to keep any append/delete property in R5 specific files only
[...]
RE: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
>On 07.07.23 15:30, Jerome Forissier wrote: >> >> >> On 7/7/23 14:34, Neha Malcom Francis wrote: >>> Earlier documentation specified builds for generating bootloader >>> images using an external TI repository k3-image-gen and >>> core-secdev-k3. Modify this to using the binman flow so that user >>> understands how to build the final boot images. >>> >>> Signed-off-by: Neha Malcom Francis >>> Reviewed-by: Simon Glass >>> --- >>> doc/board/ti/am62x_sk.rst | 42 - >>> doc/board/ti/j721e_evm.rst | 50 +--- >>> doc/board/ti/k3.rst| 95 +- >>> 3 files changed, 73 insertions(+), 114 deletions(-) >>> >>> diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst >>> index 27d7b527c6..e4d58b4958 100644 >>> --- a/doc/board/ti/am62x_sk.rst >>> +++ b/doc/board/ti/am62x_sk.rst >> [...] >>> @@ -139,35 +135,37 @@ Build procedure: >>> >>> 1. ATF: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 >PLAT=k3 >>> TARGET_BOARD=lite SPD=opteed >>> + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 >PLAT=k3 \ >>> +TARGET_BOARD=lite SPD=opteed >>> >>> 2. OPTEE: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make PLATFORM=k3 CFG_ARM64_core=y >>> CROSS_COMPILE=arm-none-linux-gnueabihf- >>> CROSS_COMPILE64=aarch64-none-linux-gnu- >>> + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none- >linux-gnueabihf- \ >>> +CROSS_COMPILE64=aarch64-none-linux-gnu- >>> >>> 3. U-Boot: >>> >>> * 3.1 R5: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >>> am62x_evm_r5_defconfig O=/tmp/r5 >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >O=/tmp/r5 >>> - $ cd >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >SOC=am62x >>> SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=>> ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin >>> - >>> -Use the tiboot3.bin generated from last command >>> + $ make ARCH=arm am62x_evm_r5_defconfig $ make ARCH=arm >>> + CROSS_COMPILE=arm-none-linux-gnueabihf- \ >>> +BINMAN_INDIRS= >>> >>> * 3.2 A53: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- >>> am62x_evm_a53_defconfig O=/tmp/a53 >>> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=to >>> ATF dir>/build/k3/lite/release/bl31.bin TEE=>> dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM=>> ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.x >>> er5f O=/tmp/a53 >>> + $ make ARCH=arm am62x_evm_a53_defconfig $ make ARCH=arm >>> + CROSS_COMPILE=aarch64-none-linux-gnu- \ >>> +BL31=/build/k3/lite/release/bl31.bin \ >>> +TEE=>> + dir>/out/arm-plat-k3/core/tee-pager_v2.bin \ >> >> Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used >> instead of tee-pager_v2.bin. Indeed when the "pager" feature is not >> enabled, the two binaries are identical, and the newer name is hopefully >less confusing. >> > >Ah, interesting. That will affect doc/board/siemens/iot2050.rst as well (and >our integration recipes). And J7200 docs as well, however this doc is on next https://github.com/u-boot/u-boot/blob/next/doc/board/ti/j7200_evm.rst > >Jan > >-- >Siemens AG, Technology >Competence Center Embedded Linux
Re: [PATCH 1/1] arm64: dts: ti: k3-j721s2: Add reserved status in msmc
On 5/3/2023 8:21 PM, Nishanth Menon wrote: On 20:17-20230503, Udit Kumar wrote: Mark atf, l3-cache and tifs node as reserved. why? (I am not reading the cover-letter for a 1 patch) My bad , I should have description in patch itself. Thanks [...] 2.34.1
Re: [PATCH] configs: j7200: correct mmc offset
On 5/3/2023 8:15 PM, Nishanth Menon wrote:
On 10:58-20230503, Udit Kumar wrote:
This patch corrects the MMC raw mode sector offset as
per documentation.
https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/08_06_00_11/exports/docs/j7200/linux/Foundational_Components/U-Boot/UG-Memory.html
Section: eMMC layout
Please drop these TI specific documentation. Instead ADD documentation
into u-boot source explaining these eMMC layout.
Sure,
will arch/arm/mach-k3/j7200/ place will be good to hold such documentation ?
NOTE: emmc raw mode for boot partition is one way of using SPL. it is
also very restrictive. u-boot and TIFS, OPTEE all packed into EMMC boot
partition has limits to which it can scale.
On beagle family for example, we choose this is tooo constraining and
chose to go down a different path where the uda partition in fs mode is
used for u-boot, tfa, optee etc.. allowing more maintainable system
instead of having to constantly refactoring the image offsets and sizes
involved.
Without this correct offset eMMC boot with UDA partition will fail.
Where this fails is looking for the next segment of u-boot image in boot
partition, not UDA.
Since size of tiboot3 is more than 512 Kb,
If we write whole tiboot3, then it will over write next image offset at
0x400.
So boot will stuck for looking for tispl.bin
Restricting writing of tiboot3 to 0x400 blocks will leads to corrupt
image of tiboot3, so nothing will start.
Fixes: f8c1e893c82 (configs: j7200_evm_a72: Add Initial suppot)
Fixes: 02dff65efe7 (configs: j7200_evm_r5: Add initial support)
Fixes: 360c7f46f39 (configs: Add configs for J7200 High Security EVM)
Way to test with eMMC UDA partition
=> mmc dev 0 0
=> fatload mmc 1 ${loadaddr} tiboot3.bin
=> mmc write ${loadaddr} 0x0 0x800
=> fatload mmc 1 ${loadaddr} tispl.bin
=> mmc write ${loadaddr} 0x800 0x1000
=> fatload mmc 1 ${loadaddr} u-boot.img
=> mmc write ${loadaddr} 0x1800 0x2000
=> mmc partconf 0 1 7 1
=> mmc bootbus 0 2 0 0
Cc: Bhavya Kapoor
Cc: Diwakar Dhyani
Cc: KEERTHY
Signed-off-by: Udit Kumar
---
configs/j7200_evm_a72_defconfig| 2 +-
configs/j7200_evm_r5_defconfig | 2 +-
configs/j7200_hs_evm_a72_defconfig | 2 +-
configs/j7200_hs_evm_r5_defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index fa5ea2aecd..8a810f8f48 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -46,7 +46,7 @@ CONFIG_SPL_STACK_R=y
CONFIG_SYS_SPL_MALLOC=y
CONFIG_SYS_SPL_MALLOC_SIZE=0x80
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1800
CONFIG_SPL_DMA=y
CONFIG_SPL_ENV_SUPPORT=y
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig
index 00ec48b83b..908cfaf402 100644
--- a/configs/j7200_evm_r5_defconfig
+++ b/configs/j7200_evm_r5_defconfig
@@ -43,7 +43,7 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8400
CONFIG_SYS_SPL_MALLOC_SIZE=0x100
CONFIG_SPL_EARLY_BSS=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800
CONFIG_SPL_DMA=y
CONFIG_SPL_ENV_SUPPORT=y
CONFIG_SPL_FS_EXT4=y
diff --git a/configs/j7200_hs_evm_a72_defconfig
b/configs/j7200_hs_evm_a72_defconfig
index d9560727ed..c234a58a7a 100644
--- a/configs/j7200_hs_evm_a72_defconfig
+++ b/configs/j7200_hs_evm_a72_defconfig
@@ -47,7 +47,7 @@ CONFIG_SPL_STACK_R=y
CONFIG_SYS_SPL_MALLOC=y
CONFIG_SYS_SPL_MALLOC_SIZE=0x80
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1800
CONFIG_SPL_DMA=y
CONFIG_SPL_ENV_SUPPORT=y
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
diff --git a/configs/j7200_hs_evm_r5_defconfig
b/configs/j7200_hs_evm_r5_defconfig
index 94a6523f06..74015db1af 100644
--- a/configs/j7200_hs_evm_r5_defconfig
+++ b/configs/j7200_hs_evm_r5_defconfig
@@ -43,7 +43,7 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8400
CONFIG_SYS_SPL_MALLOC_SIZE=0x100
CONFIG_SPL_EARLY_BSS=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800
CONFIG_SPL_DMA=y
CONFIG_SPL_ENV_SUPPORT=y
CONFIG_SPL_FS_EXT4=y
--
2.34.1
Re: [PATCH 05/14] arch: arm: dts: k3-j7200: Configure pinctrl for timer IO pad
Thanks Nishanth On 5/3/2023 8:01 PM, Nishanth Menon wrote: On 09:43-20230503, Udit Kumar wrote: [..] Needs to get to k.org master. Noted for whole series
Re: [PATCH 02/14] arch: arm: dts: k3-j7200: Fix physical address of pin
Thanks Nishanth On 5/3/2023 7:46 PM, Nishanth Menon wrote: On 09:43-20230503, Udit Kumar wrote: [..] Not in upstream k.org. NAK. i will hold this series till updated in k.org
Re: [PATCH 01/14] arm: dts: k3-j7200: Update devicetree to sync with v6.3-rc6
On 5/3/2023 7:45 PM, Nishanth Menon wrote: On 09:43-20230503, Udit Kumar wrote: From: Nishanth Menon Sync with Kernel.org v6.3-rc6 tag. we are few days away from rc1 tag. I'd rather we refresh. Thanks [..]
Re: [PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup
Hi Nishanth, On 5/3/2023 4:30 AM, Nishanth Menon wrote: On 12:57-20230502, Kumar, Udit wrote: On 5/1/2023 8:16 PM, Andrew Davis wrote: On 4/26/23 9:13 AM, Kumar, Udit wrote: Hi Neha, On 4/26/2023 5:31 PM, Neha Malcom Francis wrote: Hi Udit On 26/04/23 16:09, Kumar, Udit wrote: Hi Neha, Hi Udit, [..] [..] What I mean to ask is, why aren't there tifs or l3cache subnodes in j721e, j7200 and am65? I think, above platform is doing in right way, AFAIK, if we have to provide then we can provide size of this. l3-cache can not be addressable. So the history here is we used to have the SRAM node in DT sized to the actual size in hardware. L3 cache size can be set at boot time (in SYSFW board-config file), and that uses up some of the SRAM, so the end address moves in. We could represent this as a reserved node inside the full SRAM node, or by shrinking the SRAM node and hiding this. Same story for TIFS and ATF, they use some variable amount of the end of SRAM. Ah, I have other view. We shrunk SRAM size already, having reserved node on top of SRAM is good as removing this. How about we do this: a) Start by discussing in k.org with a patch as to how we think it should be and what the rationale is. ok b) SRAM size fixup is a consequence of firmware being flexible.. Since, the tifs reserved sram etc, base description exists even after "hardware reconfiguration", u-boot may adjust, but not delete such nodes. "reserved" is part of complete description and indication that this specific OS is not supposed to use this region. That region is protected by firewall and mechanisms to make such access fail, but that is the point of "reserved" nodes. you mean , keep full view of SRAM and update size of reserved node. BTW, L3-cache and tifs will be reserved by default. c) Standardize this across the SoCs that use MSMC (WITHOUT BREAKING FORWARD AND BACKWARD COMPATIBILITY of u-boot vs dtb).
Re: [PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup
On 5/1/2023 8:16 PM, Andrew Davis wrote: On 4/26/23 9:13 AM, Kumar, Udit wrote: Hi Neha, On 4/26/2023 5:31 PM, Neha Malcom Francis wrote: Hi Udit On 26/04/23 16:09, Kumar, Udit wrote: Hi Neha, Hi Udit, [..] I do have a general doubt; why do we have only atf-sram sub-node in msmc_sram in all other devices (j721e, j7200 and am65) except j721s2? let me know, which source code you are referring to In U-Boot, for j721e, j7200 and am65; they *only* contain atf-sram? For u-boot please see https://elixir.bootlin.com/u-boot/latest/source/arch/arm/dts/k3-j721s2-main.dtsi#L16 I could see for j721s2 as well, in uboot[0] and Linux[1] [..] What I mean to ask is, why aren't there tifs or l3cache subnodes in j721e, j7200 and am65? I think, above platform is doing in right way, AFAIK, if we have to provide then we can provide size of this. l3-cache can not be addressable. So the history here is we used to have the SRAM node in DT sized to the actual size in hardware. L3 cache size can be set at boot time (in SYSFW board-config file), and that uses up some of the SRAM, so the end address moves in. We could represent this as a reserved node inside the full SRAM node, or by shrinking the SRAM node and hiding this. Same story for TIFS and ATF, they use some variable amount of the end of SRAM. Ah, I have other view. We shrunk SRAM size already, having reserved node on top of SRAM is good as removing this. I'd prefer being explicit and keep these nodes. Andrew But in any case, u-boot removes this code before passing to OS. https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-k3/common.c#L354 Thanking You Neha Malcom Francis
Re: [PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup
Hi Neha, On 4/26/2023 5:31 PM, Neha Malcom Francis wrote: Hi Udit On 26/04/23 16:09, Kumar, Udit wrote: Hi Neha, Hi Udit, [..] I do have a general doubt; why do we have only atf-sram sub-node in msmc_sram in all other devices (j721e, j7200 and am65) except j721s2? let me know, which source code you are referring to In U-Boot, for j721e, j7200 and am65; they *only* contain atf-sram? For u-boot please see https://elixir.bootlin.com/u-boot/latest/source/arch/arm/dts/k3-j721s2-main.dtsi#L16 I could see for j721s2 as well, in uboot[0] and Linux[1] [..] What I mean to ask is, why aren't there tifs or l3cache subnodes in j721e, j7200 and am65? I think, above platform is doing in right way, AFAIK, if we have to provide then we can provide size of this. l3-cache can not be addressable. But in any case, u-boot removes this code before passing to OS. https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-k3/common.c#L354 Thanking You Neha Malcom Francis
RE: [PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup
Hi Neha, > Hi Udit, [..] >>> >>> I do have a general doubt; why do we have only atf-sram sub-node in >>> msmc_sram in all other devices (j721e, j7200 and am65) except j721s2? >> >> let me know, which source code you are referring to >> > >In U-Boot, for j721e, j7200 and am65; they *only* contain atf-sram? For u-boot please see https://elixir.bootlin.com/u-boot/latest/source/arch/arm/dts/k3-j721s2-main.dtsi#L16 >> I could see for j721s2 as well, in uboot[0] and Linux[1] [..] >Thanking You >Neha Malcom Francis
Re: [PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup
Hi Neha
On 4/26/2023 2:56 PM, Neha Malcom Francis wrote:
Hi Udit
On 20/04/23 13:41, Udit Kumar wrote:
This patch deletes tifs DT node as part of fixup.
TISCI API reported msmc_size, does not include
64KB reserved size for tifs aka MSMC comms memory.
As part of fixup, original code uses TISCI API
reported msmc_size as size for sram DT node.
tifs node is similar to l3-cache, which should
hold address above msms_size, and should be deleted
before passing control to OS.
Documentation
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html?highlight=msmc#tisci-msg-query-msmc
Signed-off-by: Udit Kumar
---
Changes since v1:
https://lore.kernel.org/all/20230419061352.3156023-1-u-kum...@ti.com/
- moved tifs check above l3 as
arch/arm/mach-k3/common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index a2adb791f6..33b1f10d58 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -351,6 +351,7 @@ int fdt_fixup_msmc_ram(void *blob, char
*parent_path, char *node_name)
subnode, addr, size);
if (addr + size > msmc_size ||
!strncmp(fdt_get_name(blob, subnode, &len), "sysfw", 5) ||
+ !strncmp(fdt_get_name(blob, subnode, &len), "tifs", 4) ||
!strncmp(fdt_get_name(blob, subnode, &len), "l3cache",
7)) {
fdt_del_node(blob, subnode);
debug("%s: deleting subnode %d\n", __func__, subnode);
Reviewed-by: Neha Malcom Francis
I do have a general doubt; why do we have only atf-sram sub-node in
msmc_sram in all other devices (j721e, j7200 and am65) except j721s2?
let me know, which source code you are referring to
I could see for j721s2 as well, in uboot[0] and Linux[1]
[0]
https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi#L16
[1]
https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi#L16
Re: [PATCH] arch: arm: mach-k3: Delete tifs node in DT fixup
Thanks for review
On 4/19/2023 9:22 PM, Nishanth Menon wrote:
On 11:43-20230419, Udit Kumar wrote:
This patch deletes tifs DT node as part of fixup.
TISCI API reported msmc_size, does not include
64KB reserved size for tifs aka MSMC comms memory.
As part of fixup, original code uses TISCI API
reported msmc_size as size for sram DT node.
tifs node is similar to l3-cache, which should
hold address above msms_size, and should be deleted
before passing control to OS.
Documentation
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html?highlight=msmc#tisci-msg-query-msmc
Signed-off-by: Udit Kumar
---
arch/arm/mach-k3/common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index a2adb791f6..4651744821 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -349,9 +349,11 @@ int fdt_fixup_msmc_ram(void *blob, char *parent_path, char
*node_name)
size = fdt_read_number(sub_reg, 1);
debug("%s: subnode = %d, addr = 0x%x. size = 0x%x\n", __func__,
subnode, addr, size);
+
if (addr + size > msmc_size ||
!strncmp(fdt_get_name(blob, subnode, &len), "sysfw", 5) ||
- !strncmp(fdt_get_name(blob, subnode, &len), "l3cache", 7)) {
+ !strncmp(fdt_get_name(blob, subnode, &len), "l3cache", 7) ||
+ !strncmp(fdt_get_name(blob, subnode, &len), "tifs", 4)) {
I would probably move the tifs check above the l3cache check.
I will move this in v2.
you want to stay close to DT nodes order. or there is some other reason ?
fdt_del_node(blob, subnode);
debug("%s: deleting subnode %d\n", __func__, subnode);
if (!prev_node)
--
2.34.1
