| Message ID | 20240730-b4-upstream-j742s2-v2-2-6aedf892156c@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Introduce J742S2 SoC and EVM | expand |
On 12:43-20240730, Manorit Chawdhry wrote: > This device is a subset of J784S4 and shares the same memory map and > thus the nodes are being reused from J784S4 to avoid duplication. > > Here are some of the salient features of the J742S2 automotive grade > application processor: > > The J742S2 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 changes that this devices has from J784S4 are: > * 4x Cortex-A72 vs 8x Cortex-A72 > * 3x C7x DSP vs 4x C7x DSP > * 4 port ethernet switch vs 8 port ethernet switch > > ( Refer Table 2-1 for Device comparison with J7AHP ) > Link: https://www.ti.com/lit/pdf/spruje3 (TRM) > Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> > --- > arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi | 44 ++++++++++++++++++++++++++++++ > arch/arm64/boot/dts/ti/k3-j742s2.dtsi | 26 ++++++++++++++++++ > 2 files changed, 70 insertions(+) > > diff --git a/arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi > new file mode 100644 > index 000000000000..13b83560d5a2 > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi > @@ -0,0 +1,44 @@ > +// SPDX-License-Identifier: GPL-2.0 and MIT please. > +/* > + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ > + * > + * EVM Board Schematics: https://www.ti.com/lit/zip/SPAC001 Point to SoC trm here. > + */ > + > +/delete-node/ &c71_3; here and below: > + > +&c71_0 { > + firmware-name = "j742s2-c71_0-fw"; > +}; > + > +&c71_1 { > + firmware-name = "j742s2-c71_1-fw"; > +}; > + > +&c71_2 { > + firmware-name = "j742s2-c71_2-fw"; > +}; > + > +&main_r5fss0_core0 { > + firmware-name = "j742s2-main-r5f0_0-fw"; > +}; > + > +&main_r5fss0_core1 { > + firmware-name = "j742s2-main-r5f0_1-fw"; > +}; > + > +&main_r5fss1_core0 { > + firmware-name = "j742s2-main-r5f1_0-fw"; > +}; > + > +&main_r5fss1_core1 { > + firmware-name = "j742s2-main-r5f1_1-fw"; > +}; > + > +&main_r5fss2_core0 { > + firmware-name = "j742s2-main-r5f2_0-fw"; > +}; > + > +&main_r5fss2_core1 { > + firmware-name = "j742s2-main-r5f2_1-fw"; > +}; > diff --git a/arch/arm64/boot/dts/ti/k3-j742s2.dtsi b/arch/arm64/boot/dts/ti/k3-j742s2.dtsi > new file mode 100644 > index 000000000000..0b20c992d664 > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-j742s2.dtsi > @@ -0,0 +1,26 @@ > +// SPDX-License-Identifier: GPL-2.0 Same - and fix anywhere else as required. > +/* > + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ > + * > + * EVM Board Schematics: https://www.ti.com/lit/zip/SPAC001 Same > + */ > + > +#include "k3-j784s4.dtsi" > + > +/ { > + model = "Texas Instruments K3 J742S2 SoC"; > + compatible = "ti,j742s2"; > + > + cpus { > + cpu-map { > + /delete-node/ cluster1; > + }; > + }; > + > + /delete-node/ cpu4; > + /delete-node/ cpu5; > + /delete-node/ cpu6; > + /delete-node/ cpu7; I suggest refactoring by renaming the dtsi files as common and split out j784s4 similar to j722s/am62p rather than using /delete-node/ > +}; > + > +#include "k3-j742s2-main.dtsi" > > -- > 2.45.1 >
Hi Nishanth, On 07:33-20240730, Nishanth Menon wrote: > On 12:43-20240730, Manorit Chawdhry wrote: > > This device is a subset of J784S4 and shares the same memory map and > > thus the nodes are being reused from J784S4 to avoid duplication. > > > > Here are some of the salient features of the J742S2 automotive grade > > application processor: > > > > The J742S2 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 changes that this devices has from J784S4 are: > > * 4x Cortex-A72 vs 8x Cortex-A72 > > * 3x C7x DSP vs 4x C7x DSP > > * 4 port ethernet switch vs 8 port ethernet switch > > > > ( Refer Table 2-1 for Device comparison with J7AHP ) > > Link: https://www.ti.com/lit/pdf/spruje3 (TRM) > > Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> > > --- > > arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi | 44 ++++++++++++++++++++++++++++++ > > arch/arm64/boot/dts/ti/k3-j742s2.dtsi | 26 ++++++++++++++++++ > > 2 files changed, 70 insertions(+) > > [...] > > + */ > > + > > +#include "k3-j784s4.dtsi" > > + > > +/ { > > + model = "Texas Instruments K3 J742S2 SoC"; > > + compatible = "ti,j742s2"; > > + > > + cpus { > > + cpu-map { > > + /delete-node/ cluster1; > > + }; > > + }; > > + > > + /delete-node/ cpu4; > > + /delete-node/ cpu5; > > + /delete-node/ cpu6; > > + /delete-node/ cpu7; > > I suggest refactoring by renaming the dtsi files as common and split out > j784s4 similar to j722s/am62p rather than using /delete-node/ > I don't mind the suggestion Nishanth if there is a reason behind it. Could you tell why we should not be using /delete-node/? Regards, Manorit > > > +}; > > + > > +#include "k3-j742s2-main.dtsi" > > > > -- > > 2.45.1 > > > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 09:49-20240731, Manorit Chawdhry wrote: > > > + */ > > > + > > > +#include "k3-j784s4.dtsi" > > > + > > > +/ { > > > + model = "Texas Instruments K3 J742S2 SoC"; > > > + compatible = "ti,j742s2"; > > > + > > > + cpus { > > > + cpu-map { > > > + /delete-node/ cluster1; > > > + }; > > > + }; > > > + > > > + /delete-node/ cpu4; > > > + /delete-node/ cpu5; > > > + /delete-node/ cpu6; > > > + /delete-node/ cpu7; > > > > I suggest refactoring by renaming the dtsi files as common and split out > > j784s4 similar to j722s/am62p rather than using /delete-node/ > > > > I don't mind the suggestion Nishanth if there is a reason behind it. > Could you tell why we should not be using /delete-node/? > Maintenance, readability and sustenance are the reasons. This is a optimized die. It will end up having it's own changes in property and integration details. While reuse is necessary, modifying the properties with overrides and /delete-nodes/ creates maintenance challenges down the road. We already went down this road with am62p reuse with j722s, and eventually determined split and reuse is the best option. See [1] for additional guidance. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n189
Hi Nishanth, On 06:06-20240731, Nishanth Menon wrote: > On 09:49-20240731, Manorit Chawdhry wrote: > > > > + */ > > > > + > > > > +#include "k3-j784s4.dtsi" > > > > + > > > > +/ { > > > > + model = "Texas Instruments K3 J742S2 SoC"; > > > > + compatible = "ti,j742s2"; > > > > + > > > > + cpus { > > > > + cpu-map { > > > > + /delete-node/ cluster1; > > > > + }; > > > > + }; > > > > + > > > > + /delete-node/ cpu4; > > > > + /delete-node/ cpu5; > > > > + /delete-node/ cpu6; > > > > + /delete-node/ cpu7; > > > > > > I suggest refactoring by renaming the dtsi files as common and split out > > > j784s4 similar to j722s/am62p rather than using /delete-node/ > > > > > > > I don't mind the suggestion Nishanth if there is a reason behind it. > > Could you tell why we should not be using /delete-node/? > > > > Maintenance, readability and sustenance are the reasons. This is a > optimized die. It will end up having it's own changes in property > and integration details. While reuse is necessary, modifying the > properties with overrides and /delete-nodes/ creates maintenance > challenges down the road. We already went down this road with am62p > reuse with j722s, and eventually determined split and reuse is the > best option. See [1] for additional guidance. > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n189 Thank you for giving some reasoning, would do the needful! Regards, Manorit > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 7/31/24 8:57 AM, Manorit Chawdhry wrote: > Hi Nishanth, > > On 06:06-20240731, Nishanth Menon wrote: >> On 09:49-20240731, Manorit Chawdhry wrote: >>>>> + */ >>>>> + >>>>> +#include "k3-j784s4.dtsi" >>>>> + >>>>> +/ { >>>>> + model = "Texas Instruments K3 J742S2 SoC"; >>>>> + compatible = "ti,j742s2"; >>>>> + >>>>> + cpus { >>>>> + cpu-map { >>>>> + /delete-node/ cluster1; >>>>> + }; >>>>> + }; >>>>> + >>>>> + /delete-node/ cpu4; >>>>> + /delete-node/ cpu5; >>>>> + /delete-node/ cpu6; >>>>> + /delete-node/ cpu7; >>>> >>>> I suggest refactoring by renaming the dtsi files as common and split out >>>> j784s4 similar to j722s/am62p rather than using /delete-node/ >>>> >>> >>> I don't mind the suggestion Nishanth if there is a reason behind it. >>> Could you tell why we should not be using /delete-node/? >>> >> >> Maintenance, readability and sustenance are the reasons. This is a >> optimized die. It will end up having it's own changes in property >> and integration details. While reuse is necessary, modifying the >> properties with overrides and /delete-nodes/ creates maintenance >> challenges down the road. We already went down this road with am62p >> reuse with j722s, and eventually determined split and reuse is the >> best option. See [1] for additional guidance. >> >> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n189 > > Thank you for giving some reasoning, would do the needful! > This refactor will require some interesting naming for the common SoC files. Based on your name for the EVM, I'm guessing you will go with k3-j784s4-common.dtsi included from the real k3-j784s4.dtsi and the new k3-j742s2.dtsi? Too bad the Jacinto SoC names don't use a hierarchical naming. :( J7<family><part><spin><etc>.. Andrew > Regards, > Manorit > >> >> -- >> Regards, >> Nishanth Menon >> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D >
Hi Andrew, On 09:37-20240731, Andrew Davis wrote: > On 7/31/24 8:57 AM, Manorit Chawdhry wrote: > > Hi Nishanth, > > > > On 06:06-20240731, Nishanth Menon wrote: > > > On 09:49-20240731, Manorit Chawdhry wrote: > > > > > > + */ > > > > > > + > > > > > > +#include "k3-j784s4.dtsi" > > > > > > + > > > > > > +/ { > > > > > > + model = "Texas Instruments K3 J742S2 SoC"; > > > > > > + compatible = "ti,j742s2"; > > > > > > + > > > > > > + cpus { > > > > > > + cpu-map { > > > > > > + /delete-node/ cluster1; > > > > > > + }; > > > > > > + }; > > > > > > + > > > > > > + /delete-node/ cpu4; > > > > > > + /delete-node/ cpu5; > > > > > > + /delete-node/ cpu6; > > > > > > + /delete-node/ cpu7; > > > > > > > > > > I suggest refactoring by renaming the dtsi files as common and split out > > > > > j784s4 similar to j722s/am62p rather than using /delete-node/ > > > > > > > > > > > > > I don't mind the suggestion Nishanth if there is a reason behind it. > > > > Could you tell why we should not be using /delete-node/? > > > > > > > > > > Maintenance, readability and sustenance are the reasons. This is a > > > optimized die. It will end up having it's own changes in property > > > and integration details. While reuse is necessary, modifying the > > > properties with overrides and /delete-nodes/ creates maintenance > > > challenges down the road. We already went down this road with am62p > > > reuse with j722s, and eventually determined split and reuse is the > > > best option. See [1] for additional guidance. > > > > > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n189 > > > > Thank you for giving some reasoning, would do the needful! > > > > This refactor will require some interesting naming for the > common SoC files. Based on your name for the EVM, I'm guessing > you will go with One other reason I was trying to avoid that and going with /delete-node/. For such a small delta change tbh, this churn doesn't feel worth the effort to me and is just gonna create confusion. EVM one was required as Rob did raise an interesting point and we did require a soc file that wasn't existing with the previous patchset but now for deleting just 4 cpus and 1 dsp, am gonna have to rename all the files, change the hierarchical structure, add all the cpus again with some weird naming for the file as don't know if some other soc is gonna come up in future so don't wanna clutter the file names as well with j784s4-j742s2-j7xxx.dtsi which is just gonna create another set of mess in future. Regards, Manorit > > k3-j784s4-common.dtsi > > included from the real k3-j784s4.dtsi and the new k3-j742s2.dtsi? > > Too bad the Jacinto SoC names don't use a hierarchical naming. :( > > J7<family><part><spin><etc>.. > > Andrew > > > Regards, > > Manorit > > > > > > > > -- > > > Regards, > > > Nishanth Menon > > > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D > >
On 7/31/24 9:58 AM, Manorit Chawdhry wrote: > Hi Andrew, > > On 09:37-20240731, Andrew Davis wrote: >> On 7/31/24 8:57 AM, Manorit Chawdhry wrote: >>> Hi Nishanth, >>> >>> On 06:06-20240731, Nishanth Menon wrote: >>>> On 09:49-20240731, Manorit Chawdhry wrote: >>>>>>> + */ >>>>>>> + >>>>>>> +#include "k3-j784s4.dtsi" >>>>>>> + >>>>>>> +/ { >>>>>>> + model = "Texas Instruments K3 J742S2 SoC"; >>>>>>> + compatible = "ti,j742s2"; >>>>>>> + >>>>>>> + cpus { >>>>>>> + cpu-map { >>>>>>> + /delete-node/ cluster1; >>>>>>> + }; >>>>>>> + }; >>>>>>> + >>>>>>> + /delete-node/ cpu4; >>>>>>> + /delete-node/ cpu5; >>>>>>> + /delete-node/ cpu6; >>>>>>> + /delete-node/ cpu7; >>>>>> >>>>>> I suggest refactoring by renaming the dtsi files as common and split out >>>>>> j784s4 similar to j722s/am62p rather than using /delete-node/ >>>>>> >>>>> >>>>> I don't mind the suggestion Nishanth if there is a reason behind it. >>>>> Could you tell why we should not be using /delete-node/? >>>>> >>>> >>>> Maintenance, readability and sustenance are the reasons. This is a >>>> optimized die. It will end up having it's own changes in property >>>> and integration details. While reuse is necessary, modifying the >>>> properties with overrides and /delete-nodes/ creates maintenance >>>> challenges down the road. We already went down this road with am62p >>>> reuse with j722s, and eventually determined split and reuse is the >>>> best option. See [1] for additional guidance. >>>> >>>> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n189 >>> >>> Thank you for giving some reasoning, would do the needful! >>> >> >> This refactor will require some interesting naming for the >> common SoC files. Based on your name for the EVM, I'm guessing >> you will go with > > One other reason I was trying to avoid that and going with > /delete-node/. For such a small delta change tbh, this churn doesn't > feel worth the effort to me and is just gonna create confusion. > > EVM one was required as Rob did raise an interesting point and we did > require a soc file that wasn't existing with the previous patchset but > now for deleting just 4 cpus and 1 dsp, am gonna have to rename all the > files, change the hierarchical structure, add all the cpus again with > some weird naming for the file as don't know if some other soc is gonna > come up in future so don't wanna clutter the file names as well with > j784s4-j742s2-j7xxx.dtsi which is just gonna create another set of mess > in future. > Which is why I would suggesting getting the name picked and agreed on here before you start doing the renames (renames for .dtsi files are not a problem, only the final .dtb names seem to require stability as the bootloader tend to load them by name, and those are not changing) What is wrong with just k3-j784s4-common.dtsi? All future spins of this base device can include from this file. Every spin doesn't need to be in the common file's name. Andrew > Regards, > Manorit > >> >> k3-j784s4-common.dtsi >> >> included from the real k3-j784s4.dtsi and the new k3-j742s2.dtsi? >> >> Too bad the Jacinto SoC names don't use a hierarchical naming. :( >> >> J7<family><part><spin><etc>.. >> >> Andrew >> >>> Regards, >>> Manorit >>> >>>> >>>> -- >>>> Regards, >>>> Nishanth Menon >>>> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D >>>
Hi Andrew, On 10:03-20240731, Andrew Davis wrote: > On 7/31/24 9:58 AM, Manorit Chawdhry wrote: > > Hi Andrew, > > > > On 09:37-20240731, Andrew Davis wrote: > > > On 7/31/24 8:57 AM, Manorit Chawdhry wrote: > > > > Hi Nishanth, > > > > > > > > On 06:06-20240731, Nishanth Menon wrote: > > > > > On 09:49-20240731, Manorit Chawdhry wrote: > > > > > > > > + */ > > > > > > > > + > > > > > > > > +#include "k3-j784s4.dtsi" > > > > > > > > + > > > > > > > > +/ { > > > > > > > > + model = "Texas Instruments K3 J742S2 SoC"; > > > > > > > > + compatible = "ti,j742s2"; > > > > > > > > + > > > > > > > > + cpus { > > > > > > > > + cpu-map { > > > > > > > > + /delete-node/ cluster1; > > > > > > > > + }; > > > > > > > > + }; > > > > > > > > + > > > > > > > > + /delete-node/ cpu4; > > > > > > > > + /delete-node/ cpu5; > > > > > > > > + /delete-node/ cpu6; > > > > > > > > + /delete-node/ cpu7; > > > > > > > > > > > > > > I suggest refactoring by renaming the dtsi files as common and split out > > > > > > > j784s4 similar to j722s/am62p rather than using /delete-node/ > > > > > > > > > > > > > > > > > > > I don't mind the suggestion Nishanth if there is a reason behind it. > > > > > > Could you tell why we should not be using /delete-node/? > > > > > > > > > > > > > > > > Maintenance, readability and sustenance are the reasons. This is a > > > > > optimized die. It will end up having it's own changes in property > > > > > and integration details. While reuse is necessary, modifying the > > > > > properties with overrides and /delete-nodes/ creates maintenance > > > > > challenges down the road. We already went down this road with am62p > > > > > reuse with j722s, and eventually determined split and reuse is the > > > > > best option. See [1] for additional guidance. > > > > > > > > > > > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n189 > > > > > > > > Thank you for giving some reasoning, would do the needful! > > > > > > > > > > This refactor will require some interesting naming for the > > > common SoC files. Based on your name for the EVM, I'm guessing > > > you will go with > > > > One other reason I was trying to avoid that and going with > > /delete-node/. For such a small delta change tbh, this churn doesn't > > feel worth the effort to me and is just gonna create confusion. > > > > EVM one was required as Rob did raise an interesting point and we did > > require a soc file that wasn't existing with the previous patchset but > > now for deleting just 4 cpus and 1 dsp, am gonna have to rename all the > > files, change the hierarchical structure, add all the cpus again with > > some weird naming for the file as don't know if some other soc is gonna > > come up in future so don't wanna clutter the file names as well with > > j784s4-j742s2-j7xxx.dtsi which is just gonna create another set of mess > > in future. > > > > Which is why I would suggesting getting the name picked and agreed on > here before you start doing the renames (renames for .dtsi files are not > a problem, only the final .dtb names seem to require stability as the > bootloader tend to load them by name, and those are not changing) > > What is wrong with just k3-j784s4-common.dtsi? All future spins of > this base device can include from this file. Every spin doesn't need > to be in the common file's name. Yeah, was gonna go with that file only right now, but now would I have - k3-j784s4-mcu-wakeup-common.dtsi ( this is not required at this stage, but ig for consistency better to now itself ) - k3-j784s4-main-common.dtsi ( all dsps excluding c7x_3 ) - k3-j784s4-thermal-common.dtsi ( not required again but consistency ) - k3-j784s4-common.dtsi ( all this won't have the cpu but will have all other ranges including for the last dsp and all ) - k3-j784s4.dtsi ( have 8 cores ) - k3-j784s4-main.dtsi ( have an additional dsp ) - k3-j742s2.dtsi ( have 4 cores ) - k3-j742s2-main.dtsi ( have firmware name overrides ) I do find it confusing while developing but mostly people would have to get used to developing in common files and hoping that things should be okay. Regards, Manorit > > Andrew > > > Regards, > > Manorit > > > > > > > > k3-j784s4-common.dtsi > > > > > > included from the real k3-j784s4.dtsi and the new k3-j742s2.dtsi? > > > > > > Too bad the Jacinto SoC names don't use a hierarchical naming. :( > > > > > > J7<family><part><spin><etc>.. > > > > > > Andrew > > > > > > > Regards, > > > > Manorit > > > > > > > > > > > > > > -- > > > > > Regards, > > > > > Nishanth Menon > > > > > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D > > > >
On 20:48-20240731, Manorit Chawdhry wrote: [...] > Yeah, was gonna go with that file only right now, but now would I have > > - k3-j784s4-mcu-wakeup-common.dtsi ( this is not required at this stage, > but ig for consistency better to now itself ) > - k3-j784s4-main-common.dtsi ( all dsps excluding c7x_3 ) > - k3-j784s4-thermal-common.dtsi ( not required again but consistency ) > - k3-j784s4-common.dtsi ( all this won't have the cpu but will have all > other ranges including for the last dsp and all ) We already use k3-am62p-j722s-common-main.dtsi so that people don't ask what is this common to and track down via grep who is including what. I'd rather us follow that convention for now that debate is done with and integrated in master. I don't see a strong reason yet to change the same. Again, everyone will have an subjective opinion, I prefer to follow existing convention that is established on topics that are cosmetic.
diff --git a/arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi new file mode 100644 index 000000000000..13b83560d5a2 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi @@ -0,0 +1,44 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ + * + * EVM Board Schematics: https://www.ti.com/lit/zip/SPAC001 + */ + +/delete-node/ &c71_3; + +&c71_0 { + firmware-name = "j742s2-c71_0-fw"; +}; + +&c71_1 { + firmware-name = "j742s2-c71_1-fw"; +}; + +&c71_2 { + firmware-name = "j742s2-c71_2-fw"; +}; + +&main_r5fss0_core0 { + firmware-name = "j742s2-main-r5f0_0-fw"; +}; + +&main_r5fss0_core1 { + firmware-name = "j742s2-main-r5f0_1-fw"; +}; + +&main_r5fss1_core0 { + firmware-name = "j742s2-main-r5f1_0-fw"; +}; + +&main_r5fss1_core1 { + firmware-name = "j742s2-main-r5f1_1-fw"; +}; + +&main_r5fss2_core0 { + firmware-name = "j742s2-main-r5f2_0-fw"; +}; + +&main_r5fss2_core1 { + firmware-name = "j742s2-main-r5f2_1-fw"; +}; diff --git a/arch/arm64/boot/dts/ti/k3-j742s2.dtsi b/arch/arm64/boot/dts/ti/k3-j742s2.dtsi new file mode 100644 index 000000000000..0b20c992d664 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-j742s2.dtsi @@ -0,0 +1,26 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ + * + * EVM Board Schematics: https://www.ti.com/lit/zip/SPAC001 + */ + +#include "k3-j784s4.dtsi" + +/ { + model = "Texas Instruments K3 J742S2 SoC"; + compatible = "ti,j742s2"; + + cpus { + cpu-map { + /delete-node/ cluster1; + }; + }; + + /delete-node/ cpu4; + /delete-node/ cpu5; + /delete-node/ cpu6; + /delete-node/ cpu7; +}; + +#include "k3-j742s2-main.dtsi"
This device is a subset of J784S4 and shares the same memory map and thus the nodes are being reused from J784S4 to avoid duplication. Here are some of the salient features of the J742S2 automotive grade application processor: The J742S2 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 changes that this devices has from J784S4 are: * 4x Cortex-A72 vs 8x Cortex-A72 * 3x C7x DSP vs 4x C7x DSP * 4 port ethernet switch vs 8 port ethernet switch ( Refer Table 2-1 for Device comparison with J7AHP ) Link: https://www.ti.com/lit/pdf/spruje3 (TRM) Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> --- arch/arm64/boot/dts/ti/k3-j742s2-main.dtsi | 44 ++++++++++++++++++++++++++++++ arch/arm64/boot/dts/ti/k3-j742s2.dtsi | 26 ++++++++++++++++++ 2 files changed, 70 insertions(+)