Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 10/4/23 1:06 PM, Nishanth Menon wrote:
On 23:22-20231004, Apurva Nandan wrote:
[...]
+ .virt = 0x5UL,
+ .phys = 0x5UL,
+ .size = 0x4UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
Why not reuse CONFIG_SOC_K3_J721S2 or adopt it?
The mem_map regions are different for J784S4 from J721S2,
and on the hardware side also, i.e. J784S4 has 4x8G DDR slots,
so how can we bring it in same CONFIG as J721S2?
Is'nt that what device tree is for? what harm do we run into if
we define the common super set in the common file?
Been wanting to fix that for a while now, posted RFC for it here:
https://lore.kernel.org/u-boot/20231122151411.11268-1-...@ti.com/
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
Hi Nishanth, On 06:13-20231006, Nishanth Menon wrote: > On 09:46-20231006, Manorit Chawdhry wrote: > > Hi Nishanth, > > > > On 06:26-20231005, Nishanth Menon wrote: > > > On 10:29-20231005, Manorit Chawdhry wrote: > > > > Hi Nishanth, > > > > > > > > On 07:24-20231004, Nishanth Menon wrote: > > > > > On 10:43-20231004, Manorit Chawdhry wrote: > > > > > > > > > > > These are required to remove the firewall configurations that are > > > > > > done > > > > > > by ROM, those are not the ones that are being handled by OIDs. The > > > > > > > > > > I am not sure I understand this clearly. OIDs are setup to open up > > > > > firewalls or close firewalls as the system requires and since it > > > > > is authenticated, not compromiseable.- U-boot by itself (even if > > > > > authenticated), is not a secure entity for it to dictate the firewall > > > > > configuration (u-boot must be assumed to be compromised after > > > > > authentication is complete). So, doing firewall configuration via APIs > > > > > after boot, to me looks broken approach. > > > > > > > > > > > > > I know U-boot ain't that secure given the most trusted entity is always > > > > gonna be the software that starts up the system, we can't expect those > > > > to be doing all the work and based on that we have the secure boot > > > > designed to configure firewalls (that are not owned by anymore) and > > > > U-boot R5 being one of the early bootloaders do come as a part of it. > > > > > > > > Regarding the OIDs thing, I don't think the OID in question is looked by > > > > ROM and ROM always configures some firewalls for it's usecase that are > > > > present in those arrays. > > > > > > > > The OID that we are using in the series that you had shared is looked by > > > > TIFS instead of ROM and TIFS is the entity that is authenticating the > > > > binary along with setting up the firewalls. > > > > > > > > > > current series that is being worked on is to add additional > > > > > > firewalling > > > > > > support with OIDs that TIFS will be handling. > > > > > > The above patch is > > > > > > essentially added to have the same development experience on GP > > > > > > devices > > > > > > similar to HS after the secure boot is done so that people don't > > > > > > end up > > > > > > > > > > huh? the code seems to blindly call the > > > > > remove_fwl_configs(cbass_hc_cfg0_fwls, > > > > > ARRAY_SIZE(cbass_hc_cfg0_fwls)); > > > > > where is the distinction of HS vs GP here? This implementation looks > > > > > completely broken to me at least.. please correct what I missed here. > > > > > > > > Since this call is used across all SoCs there wasn't any point to make > > > > the differentiation between GP and HS here, remove_fwl_configs > > > > internally handles looking at the firewalls and disabling them if they > > > > are enabled ( Which would be only in the case of HS devices ), for GP it > > > > would automatically by a noop. > > > > > > Correct me if I understand the security chain here: > > > > > > ROM sets up firewalls that are needed by itself > > > TIFS (in multicertificate will setup it's own firewalls) > > > R5 SPL comes along and opens up other firewalls > > > Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs > > > to > > > set up firewalls to protect themselves (enforced by TIFS) > > > A53 SPL and U-boot itself startups but has no ability to change the > > > protection firewalls enforced by x509 OIDs. > > > > > > Further, firewalls have lockdown bit that enforces the setting (and > > > cannot be over-ridden) till system restart is requested > > > > > > Is this correct? If so, needs to be clearly documented. > > > > Yes, this seems correct. Will be updating it in the upstream > > documentation in another series. > > > > Thanks. I suggest: > a) Add documentation as part of firewall series[1] including information > as to how to customize the flow as needed. > b) once the firewall series is merged > c) am69/j784s4 series and add reference in code to the section of > documentation. Sure, would do the following in firewalling series. Thanks! Regards, Manorit > > [1] > https://lore.kernel.org/all/20231004-binman-firewalling-v3-0-e4a102324...@ti.com/ > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 09:46-20231006, Manorit Chawdhry wrote: > Hi Nishanth, > > On 06:26-20231005, Nishanth Menon wrote: > > On 10:29-20231005, Manorit Chawdhry wrote: > > > Hi Nishanth, > > > > > > On 07:24-20231004, Nishanth Menon wrote: > > > > On 10:43-20231004, Manorit Chawdhry wrote: > > > > > > > > > These are required to remove the firewall configurations that are done > > > > > by ROM, those are not the ones that are being handled by OIDs. The > > > > > > > > I am not sure I understand this clearly. OIDs are setup to open up > > > > firewalls or close firewalls as the system requires and since it > > > > is authenticated, not compromiseable.- U-boot by itself (even if > > > > authenticated), is not a secure entity for it to dictate the firewall > > > > configuration (u-boot must be assumed to be compromised after > > > > authentication is complete). So, doing firewall configuration via APIs > > > > after boot, to me looks broken approach. > > > > > > > > > > I know U-boot ain't that secure given the most trusted entity is always > > > gonna be the software that starts up the system, we can't expect those > > > to be doing all the work and based on that we have the secure boot > > > designed to configure firewalls (that are not owned by anymore) and > > > U-boot R5 being one of the early bootloaders do come as a part of it. > > > > > > Regarding the OIDs thing, I don't think the OID in question is looked by > > > ROM and ROM always configures some firewalls for it's usecase that are > > > present in those arrays. > > > > > > The OID that we are using in the series that you had shared is looked by > > > TIFS instead of ROM and TIFS is the entity that is authenticating the > > > binary along with setting up the firewalls. > > > > > > > > current series that is being worked on is to add additional > > > > > firewalling > > > > > support with OIDs that TIFS will be handling. > > > > > The above patch is > > > > > essentially added to have the same development experience on GP > > > > > devices > > > > > similar to HS after the secure boot is done so that people don't end > > > > > up > > > > > > > > huh? the code seems to blindly call the > > > > remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); > > > > where is the distinction of HS vs GP here? This implementation looks > > > > completely broken to me at least.. please correct what I missed here. > > > > > > Since this call is used across all SoCs there wasn't any point to make > > > the differentiation between GP and HS here, remove_fwl_configs > > > internally handles looking at the firewalls and disabling them if they > > > are enabled ( Which would be only in the case of HS devices ), for GP it > > > would automatically by a noop. > > > > Correct me if I understand the security chain here: > > > > ROM sets up firewalls that are needed by itself > > TIFS (in multicertificate will setup it's own firewalls) > > R5 SPL comes along and opens up other firewalls > > Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to > > set up firewalls to protect themselves (enforced by TIFS) > > A53 SPL and U-boot itself startups but has no ability to change the > > protection firewalls enforced by x509 OIDs. > > > > Further, firewalls have lockdown bit that enforces the setting (and > > cannot be over-ridden) till system restart is requested > > > > Is this correct? If so, needs to be clearly documented. > > Yes, this seems correct. Will be updating it in the upstream > documentation in another series. > Thanks. I suggest: a) Add documentation as part of firewall series[1] including information as to how to customize the flow as needed. b) once the firewall series is merged c) am69/j784s4 series and add reference in code to the section of documentation. [1] https://lore.kernel.org/all/20231004-binman-firewalling-v3-0-e4a102324...@ti.com/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
Hi Nishanth, On 06:26-20231005, Nishanth Menon wrote: > On 10:29-20231005, Manorit Chawdhry wrote: > > Hi Nishanth, > > > > On 07:24-20231004, Nishanth Menon wrote: > > > On 10:43-20231004, Manorit Chawdhry wrote: > > > > > > > These are required to remove the firewall configurations that are done > > > > by ROM, those are not the ones that are being handled by OIDs. The > > > > > > I am not sure I understand this clearly. OIDs are setup to open up > > > firewalls or close firewalls as the system requires and since it > > > is authenticated, not compromiseable.- U-boot by itself (even if > > > authenticated), is not a secure entity for it to dictate the firewall > > > configuration (u-boot must be assumed to be compromised after > > > authentication is complete). So, doing firewall configuration via APIs > > > after boot, to me looks broken approach. > > > > > > > I know U-boot ain't that secure given the most trusted entity is always > > gonna be the software that starts up the system, we can't expect those > > to be doing all the work and based on that we have the secure boot > > designed to configure firewalls (that are not owned by anymore) and > > U-boot R5 being one of the early bootloaders do come as a part of it. > > > > Regarding the OIDs thing, I don't think the OID in question is looked by > > ROM and ROM always configures some firewalls for it's usecase that are > > present in those arrays. > > > > The OID that we are using in the series that you had shared is looked by > > TIFS instead of ROM and TIFS is the entity that is authenticating the > > binary along with setting up the firewalls. > > > > > > current series that is being worked on is to add additional firewalling > > > > support with OIDs that TIFS will be handling. > > > > The above patch is > > > > essentially added to have the same development experience on GP devices > > > > similar to HS after the secure boot is done so that people don't end up > > > > > > huh? the code seems to blindly call the > > > remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); > > > where is the distinction of HS vs GP here? This implementation looks > > > completely broken to me at least.. please correct what I missed here. > > > > Since this call is used across all SoCs there wasn't any point to make > > the differentiation between GP and HS here, remove_fwl_configs > > internally handles looking at the firewalls and disabling them if they > > are enabled ( Which would be only in the case of HS devices ), for GP it > > would automatically by a noop. > > Correct me if I understand the security chain here: > > ROM sets up firewalls that are needed by itself > TIFS (in multicertificate will setup it's own firewalls) > R5 SPL comes along and opens up other firewalls > Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to > set up firewalls to protect themselves (enforced by TIFS) > A53 SPL and U-boot itself startups but has no ability to change the > protection firewalls enforced by x509 OIDs. > > Further, firewalls have lockdown bit that enforces the setting (and > cannot be over-ridden) till system restart is requested > > Is this correct? If so, needs to be clearly documented. Yes, this seems correct. Will be updating it in the upstream documentation in another series. Thanks and regards, Manorit > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 10:29-20231005, Manorit Chawdhry wrote: > Hi Nishanth, > > On 07:24-20231004, Nishanth Menon wrote: > > On 10:43-20231004, Manorit Chawdhry wrote: > > > > > These are required to remove the firewall configurations that are done > > > by ROM, those are not the ones that are being handled by OIDs. The > > > > I am not sure I understand this clearly. OIDs are setup to open up > > firewalls or close firewalls as the system requires and since it > > is authenticated, not compromiseable.- U-boot by itself (even if > > authenticated), is not a secure entity for it to dictate the firewall > > configuration (u-boot must be assumed to be compromised after > > authentication is complete). So, doing firewall configuration via APIs > > after boot, to me looks broken approach. > > > > I know U-boot ain't that secure given the most trusted entity is always > gonna be the software that starts up the system, we can't expect those > to be doing all the work and based on that we have the secure boot > designed to configure firewalls (that are not owned by anymore) and > U-boot R5 being one of the early bootloaders do come as a part of it. > > Regarding the OIDs thing, I don't think the OID in question is looked by > ROM and ROM always configures some firewalls for it's usecase that are > present in those arrays. > > The OID that we are using in the series that you had shared is looked by > TIFS instead of ROM and TIFS is the entity that is authenticating the > binary along with setting up the firewalls. > > > > current series that is being worked on is to add additional firewalling > > > support with OIDs that TIFS will be handling. > > > The above patch is > > > essentially added to have the same development experience on GP devices > > > similar to HS after the secure boot is done so that people don't end up > > > > huh? the code seems to blindly call the > > remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); > > where is the distinction of HS vs GP here? This implementation looks > > completely broken to me at least.. please correct what I missed here. > > Since this call is used across all SoCs there wasn't any point to make > the differentiation between GP and HS here, remove_fwl_configs > internally handles looking at the firewalls and disabling them if they > are enabled ( Which would be only in the case of HS devices ), for GP it > would automatically by a noop. Correct me if I understand the security chain here: ROM sets up firewalls that are needed by itself TIFS (in multicertificate will setup it's own firewalls) R5 SPL comes along and opens up other firewalls Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to set up firewalls to protect themselves (enforced by TIFS) A53 SPL and U-boot itself startups but has no ability to change the protection firewalls enforced by x509 OIDs. Further, firewalls have lockdown bit that enforces the setting (and cannot be over-ridden) till system restart is requested Is this correct? If so, needs to be clearly documented. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
Hi Nishanth, On 07:24-20231004, Nishanth Menon wrote: > On 10:43-20231004, Manorit Chawdhry wrote: > > > These are required to remove the firewall configurations that are done > > by ROM, those are not the ones that are being handled by OIDs. The > > I am not sure I understand this clearly. OIDs are setup to open up > firewalls or close firewalls as the system requires and since it > is authenticated, not compromiseable.- U-boot by itself (even if > authenticated), is not a secure entity for it to dictate the firewall > configuration (u-boot must be assumed to be compromised after > authentication is complete). So, doing firewall configuration via APIs > after boot, to me looks broken approach. > I know U-boot ain't that secure given the most trusted entity is always gonna be the software that starts up the system, we can't expect those to be doing all the work and based on that we have the secure boot designed to configure firewalls (that are not owned by anymore) and U-boot R5 being one of the early bootloaders do come as a part of it. Regarding the OIDs thing, I don't think the OID in question is looked by ROM and ROM always configures some firewalls for it's usecase that are present in those arrays. The OID that we are using in the series that you had shared is looked by TIFS instead of ROM and TIFS is the entity that is authenticating the binary along with setting up the firewalls. > > current series that is being worked on is to add additional firewalling > > support with OIDs that TIFS will be handling. > > The above patch is > > essentially added to have the same development experience on GP devices > > similar to HS after the secure boot is done so that people don't end up > > huh? the code seems to blindly call the > remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); > where is the distinction of HS vs GP here? This implementation looks > completely broken to me at least.. please correct what I missed here. Since this call is used across all SoCs there wasn't any point to make the differentiation between GP and HS here, remove_fwl_configs internally handles looking at the firewalls and disabling them if they are enabled ( Which would be only in the case of HS devices ), for GP it would automatically by a noop. Regards, Manorit > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 23:22-20231004, Apurva Nandan wrote:
[...]
> > > + .virt = 0x5UL,
> > > + .phys = 0x5UL,
> > > + .size = 0x4UL,
> > > + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > > + PTE_BLOCK_NON_SHARE |
> > > + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > > + }, {
> > > + /* List terminator */
> > > + 0,
> > > + }
> > > +};
> > Why not reuse CONFIG_SOC_K3_J721S2 or adopt it?
> The mem_map regions are different for J784S4 from J721S2,
> and on the hardware side also, i.e. J784S4 has 4x8G DDR slots,
> so how can we bring it in same CONFIG as J721S2?
Is'nt that what device tree is for? what harm do we run into if
we define the common super set in the common file?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 02/10/23 21:31, Nishanth Menon wrote: On 22:25-20231001, Apurva Nandan wrote: Add J784S4 initialization files for initial SPL boot. Signed-off-by: Hari Nagalla [ add firewall configurations and change the R5 MCU scratchpad ] Signed-off-by: Manorit Chawdhry Signed-off-by: Dasnavis Sabiya Signed-off-by: Apurva Nandan --- arch/arm/mach-k3/Kconfig | 16 +- arch/arm/mach-k3/Makefile | 3 + arch/arm/mach-k3/arm64-mmu.c | 52 +++ arch/arm/mach-k3/include/mach/hardware.h | 4 + .../mach-k3/include/mach/j784s4_hardware.h| 60 arch/arm/mach-k3/include/mach/j784s4_spl.h| 47 +++ arch/arm/mach-k3/include/mach/spl.h | 4 + arch/arm/mach-k3/j784s4_fdt.c | 15 + arch/arm/mach-k3/j784s4_init.c| 332 ++ 9 files changed, 526 insertions(+), 7 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h create mode 100644 arch/arm/mach-k3/j784s4_fdt.c create mode 100644 arch/arm/mach-k3/j784s4_init.c diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 9168bf842d..0af2ec6ddb 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -22,6 +22,9 @@ config SOC_K3_AM625 config SOC_K3_AM62A7 bool "TI's K3 based AM62A7 SoC Family Support" +config SOC_K3_J784S4 + bool "TI's K3 based J784S4 SoC Family Support" + endchoice config SYS_SOC @@ -30,7 +33,7 @@ config SYS_SOC config SYS_K3_NON_SECURE_MSRAM_SIZE hex default 0x8 if SOC_K3_AM654 - default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x1c if SOC_K3_AM642 default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -42,7 +45,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE hex default 0x58000 if SOC_K3_AM654 - default 0xc if SOC_K3_J721E || SOC_K3_J721S2 + default 0xc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x18 if SOC_K3_AM642 default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -52,15 +55,14 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE config SYS_K3_MCU_SCRATCHPAD_BASE hex default 0x4028 if SOC_K3_AM654 - default 0x41cff9fc if SOC_K3_J721S2 - default 0x41cff9fc if SOC_K3_J721E + default 0x41cff9fc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the base address of MCU Scratchpad RAM. config SYS_K3_MCU_SCRATCHPAD_SIZE hex default 0x200 if SOC_K3_AM654 - default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the size of MCU Scratchpad RAM. @@ -68,7 +70,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX hex default 0x41c7fbfc if SOC_K3_AM654 default 0x41cffbfc if SOC_K3_J721E - default 0x41cfdbfc if SOC_K3_J721S2 + default 0x41cfdbfc if SOC_K3_J721S2 || SOC_K3_J784S4 default 0x701bebfc if SOC_K3_AM642 default 0x43c3f290 if SOC_K3_AM625 default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R @@ -172,7 +174,7 @@ config K3_ATF_LOAD_ADDR config K3_DM_FW bool "Separate DM firmware image" - depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN + depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_J784S4) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN default y help Enabling this will indicate that the system has separate DM diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index fd77b8bbba..6fe36c265c 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/ obj-$(CONFIG_SOC_K3_AM625) += am62x/ obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ +obj-$(CONFIG_SOC_K3_J784S4) += j784s4/ obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-$(CONFIG_ARM64) += cache.o @@ -16,6 +17,7 @@ obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o endif ifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_SOC_K3_AM654) += am654_init.o @@ -24,6 +26,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o obj-$(CONFIG_SOC_K3_AM642) += am642_init.o obj-$(CONFIG_SOC_K3_AM625) += am625_init.o obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o obj-$(CONFIG_K3_LOAD_SYSFW)
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 02/10/23 21:31, Nishanth Menon wrote: On 22:25-20231001, Apurva Nandan wrote: Add J784S4 initialization files for initial SPL boot. Signed-off-by: Hari Nagalla [ add firewall configurations and change the R5 MCU scratchpad ] Signed-off-by: Manorit Chawdhry Signed-off-by: Dasnavis Sabiya Signed-off-by: Apurva Nandan --- arch/arm/mach-k3/Kconfig | 16 +- arch/arm/mach-k3/Makefile | 3 + arch/arm/mach-k3/arm64-mmu.c | 52 +++ arch/arm/mach-k3/include/mach/hardware.h | 4 + .../mach-k3/include/mach/j784s4_hardware.h| 60 arch/arm/mach-k3/include/mach/j784s4_spl.h| 47 +++ arch/arm/mach-k3/include/mach/spl.h | 4 + arch/arm/mach-k3/j784s4_fdt.c | 15 + arch/arm/mach-k3/j784s4_init.c| 332 ++ 9 files changed, 526 insertions(+), 7 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h create mode 100644 arch/arm/mach-k3/j784s4_fdt.c create mode 100644 arch/arm/mach-k3/j784s4_init.c diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 9168bf842d..0af2ec6ddb 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -22,6 +22,9 @@ config SOC_K3_AM625 config SOC_K3_AM62A7 bool "TI's K3 based AM62A7 SoC Family Support" +config SOC_K3_J784S4 + bool "TI's K3 based J784S4 SoC Family Support" + endchoice config SYS_SOC @@ -30,7 +33,7 @@ config SYS_SOC config SYS_K3_NON_SECURE_MSRAM_SIZE hex default 0x8 if SOC_K3_AM654 - default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x1c if SOC_K3_AM642 default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -42,7 +45,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE hex default 0x58000 if SOC_K3_AM654 - default 0xc if SOC_K3_J721E || SOC_K3_J721S2 + default 0xc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x18 if SOC_K3_AM642 default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -52,15 +55,14 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE config SYS_K3_MCU_SCRATCHPAD_BASE hex default 0x4028 if SOC_K3_AM654 - default 0x41cff9fc if SOC_K3_J721S2 - default 0x41cff9fc if SOC_K3_J721E + default 0x41cff9fc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the base address of MCU Scratchpad RAM. config SYS_K3_MCU_SCRATCHPAD_SIZE hex default 0x200 if SOC_K3_AM654 - default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the size of MCU Scratchpad RAM. @@ -68,7 +70,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX hex default 0x41c7fbfc if SOC_K3_AM654 default 0x41cffbfc if SOC_K3_J721E - default 0x41cfdbfc if SOC_K3_J721S2 + default 0x41cfdbfc if SOC_K3_J721S2 || SOC_K3_J784S4 default 0x701bebfc if SOC_K3_AM642 default 0x43c3f290 if SOC_K3_AM625 default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R @@ -172,7 +174,7 @@ config K3_ATF_LOAD_ADDR config K3_DM_FW bool "Separate DM firmware image" - depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN + depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_J784S4) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN default y help Enabling this will indicate that the system has separate DM diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index fd77b8bbba..6fe36c265c 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/ obj-$(CONFIG_SOC_K3_AM625) += am62x/ obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ +obj-$(CONFIG_SOC_K3_J784S4) += j784s4/ obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-$(CONFIG_ARM64) += cache.o @@ -16,6 +17,7 @@ obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o endif ifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_SOC_K3_AM654) += am654_init.o @@ -24,6 +26,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o obj-$(CONFIG_SOC_K3_AM642) += am642_init.o obj-$(CONFIG_SOC_K3_AM625) += am625_init.o obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o obj-$(CONFIG_K3_LOAD_SYSFW)
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 10:43-20231004, Manorit Chawdhry wrote: > These are required to remove the firewall configurations that are done > by ROM, those are not the ones that are being handled by OIDs. The I am not sure I understand this clearly. OIDs are setup to open up firewalls or close firewalls as the system requires and since it is authenticated, not compromiseable.- U-boot by itself (even if authenticated), is not a secure entity for it to dictate the firewall configuration (u-boot must be assumed to be compromised after authentication is complete). So, doing firewall configuration via APIs after boot, to me looks broken approach. > current series that is being worked on is to add additional firewalling > support with OIDs that TIFS will be handling. > The above patch is > essentially added to have the same development experience on GP devices > similar to HS after the secure boot is done so that people don't end up huh? the code seems to blindly call the remove_fwl_configs(cbass_hc_cfg0_fwls, ARRAY_SIZE(cbass_hc_cfg0_fwls)); where is the distinction of HS vs GP here? This implementation looks completely broken to me at least.. please correct what I missed here. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
Hi Nishanth,
On 11:01-20231002, Nishanth Menon wrote:
> > diff --git a/arch/arm/mach-k3/j784s4_init.c b/arch/arm/mach-k3/j784s4_init.c
[..]
> > +struct fwl_data infra_cbass0_fwls[] = {
> > + { "PSC0", 5, 1 },
> > + { "PLL_CTRL0", 6, 1 },
> > + { "PLL_MMR0", 8, 26 },
> > + { "CTRL_MMR0", 9, 16 },
> > + { "GPIO0", 16, 1 },
> > +}, wkup_cbass0_fwls[] = {
> > + { "WKUP_PSC0", 129, 1 },
> > + { "WKUP_PLL_CTRL0", 130, 1 },
> > + { "WKUP_CTRL_MMR0", 131, 16 },
> > + { "WKUP_GPIO0", 132, 1 },
> > + { "WKUP_I2C0", 144, 1 },
> > + { "WKUP_USART0", 160, 1 },
> > +}, mcu_cbass0_fwls[] = {
> > + { "MCU_R5FSS0_CORE0", 1024, 4 },
> > + { "MCU_R5FSS0_CORE0_CFG", 1025, 3 },
> > + { "MCU_R5FSS0_CORE1", 1028, 4 },
> > + { "MCU_R5FSS0_CORE1_CFG", 1029, 1 },
> > + { "MCU_FSS0_CFG", 1032, 12 },
> > + { "MCU_FSS0_S1", 1033, 8 },
> > + { "MCU_FSS0_S0", 1036, 8 },
> > + { "MCU_PSROM49152X32", 1048, 1 },
> > + { "MCU_MSRAM128KX64", 1050, 8 },
> > + { "MCU_MSRAM128KX64_CFG", 1051, 1 },
> > + { "MCU_TIMER0", 1056, 1 },
> > + { "MCU_TIMER9", 1065, 1 },
> > + { "MCU_USART0", 1120, 1 },
> > + { "MCU_I2C0", 1152, 1 },
> > + { "MCU_CTRL_MMR0", 1200, 8 },
> > + { "MCU_PLL_MMR0", 1201, 3 },
> > + { "MCU_CPSW0", 1220, 2 },
> > +}, cbass_rc_cfg0_fwls[] = {
> > + { "EMMCSD4SS0_CFG", 2400, 4 },
> > +}, cbass_hc2_fwls[] = {
> > + { "PCIE0", 2547, 24 },
> > +}, cbass_hc_cfg0_fwls[] = {
> > + { "PCIE0_CFG", 2577, 7 },
> > + { "EMMC8SS0_CFG", 2579, 4 },
> > + { "USB3SS0_CORE", 2580, 4 },
> > + { "USB3SS1_CORE", 2581, 1 },
> > +}, navss_cbass0_fwls[] = {
> > + { "NACSS_VIRT0", 6253, 1 },
> > +};
[..]
> > +void board_init_f(ulong dummy)
> > +{
[..]
> > +
> > + remove_fwl_configs(cbass_hc_cfg0_fwls,
> > ARRAY_SIZE(cbass_hc_cfg0_fwls));
> > + remove_fwl_configs(cbass_hc2_fwls, ARRAY_SIZE(cbass_hc2_fwls));
> > + remove_fwl_configs(cbass_rc_cfg0_fwls,
> > ARRAY_SIZE(cbass_rc_cfg0_fwls));
> > + remove_fwl_configs(infra_cbass0_fwls,
> > ARRAY_SIZE(infra_cbass0_fwls));
> > + remove_fwl_configs(mcu_cbass0_fwls,
> > ARRAY_SIZE(mcu_cbass0_fwls));
> > + remove_fwl_configs(wkup_cbass0_fwls,
> > ARRAY_SIZE(wkup_cbass0_fwls));
> > + remove_fwl_configs(navss_cbass0_fwls,
> > ARRAY_SIZE(navss_cbass0_fwls));
>
> Why do you need this? firewall configuration was coming in via OIDs in
> https://lore.kernel.org/all/CAPnjgZ14Uy+gBC8kgqVA7m9NXN_WiXFffu5Ob=vz=e76rmd...@mail.gmail.com/
>
These are required to remove the firewall configurations that are done
by ROM, those are not the ones that are being handled by OIDs. The
current series that is being worked on is to add additional firewalling
support with OIDs that TIFS will be handling. The above patch is
essentially added to have the same development experience on GP devices
similar to HS after the secure boot is done so that people don't end up
hitting random firewall exceptions that the ROM had configured.
Regards,
Manorit
>
> > + }
> > +
[..]
Re: [PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 22:25-20231001, Apurva Nandan wrote: > Add J784S4 initialization files for initial SPL boot. > > Signed-off-by: Hari Nagalla > [ add firewall configurations and change the R5 MCU scratchpad ] > Signed-off-by: Manorit Chawdhry > Signed-off-by: Dasnavis Sabiya > Signed-off-by: Apurva Nandan > --- > arch/arm/mach-k3/Kconfig | 16 +- > arch/arm/mach-k3/Makefile | 3 + > arch/arm/mach-k3/arm64-mmu.c | 52 +++ > arch/arm/mach-k3/include/mach/hardware.h | 4 + > .../mach-k3/include/mach/j784s4_hardware.h| 60 > arch/arm/mach-k3/include/mach/j784s4_spl.h| 47 +++ > arch/arm/mach-k3/include/mach/spl.h | 4 + > arch/arm/mach-k3/j784s4_fdt.c | 15 + > arch/arm/mach-k3/j784s4_init.c| 332 ++ > 9 files changed, 526 insertions(+), 7 deletions(-) > create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h > create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h > create mode 100644 arch/arm/mach-k3/j784s4_fdt.c > create mode 100644 arch/arm/mach-k3/j784s4_init.c > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig > index 9168bf842d..0af2ec6ddb 100644 > --- a/arch/arm/mach-k3/Kconfig > +++ b/arch/arm/mach-k3/Kconfig > @@ -22,6 +22,9 @@ config SOC_K3_AM625 > config SOC_K3_AM62A7 > bool "TI's K3 based AM62A7 SoC Family Support" > > +config SOC_K3_J784S4 > + bool "TI's K3 based J784S4 SoC Family Support" > + > endchoice > > config SYS_SOC > @@ -30,7 +33,7 @@ config SYS_SOC > config SYS_K3_NON_SECURE_MSRAM_SIZE > hex > default 0x8 if SOC_K3_AM654 > - default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 > + default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 > default 0x1c if SOC_K3_AM642 > default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7 > help > @@ -42,7 +45,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE > config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE > hex > default 0x58000 if SOC_K3_AM654 > - default 0xc if SOC_K3_J721E || SOC_K3_J721S2 > + default 0xc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 > default 0x18 if SOC_K3_AM642 > default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7 > help > @@ -52,15 +55,14 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE > config SYS_K3_MCU_SCRATCHPAD_BASE > hex > default 0x4028 if SOC_K3_AM654 > - default 0x41cff9fc if SOC_K3_J721S2 > - default 0x41cff9fc if SOC_K3_J721E > + default 0x41cff9fc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 > help > Describes the base address of MCU Scratchpad RAM. > > config SYS_K3_MCU_SCRATCHPAD_SIZE > hex > default 0x200 if SOC_K3_AM654 > - default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 > + default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 > help > Describes the size of MCU Scratchpad RAM. > > @@ -68,7 +70,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX > hex > default 0x41c7fbfc if SOC_K3_AM654 > default 0x41cffbfc if SOC_K3_J721E > - default 0x41cfdbfc if SOC_K3_J721S2 > + default 0x41cfdbfc if SOC_K3_J721S2 || SOC_K3_J784S4 > default 0x701bebfc if SOC_K3_AM642 > default 0x43c3f290 if SOC_K3_AM625 > default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R > @@ -172,7 +174,7 @@ config K3_ATF_LOAD_ADDR > > config K3_DM_FW > bool "Separate DM firmware image" > - depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || > SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN > + depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || > SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_J784S4) && !CLK_TI_SCI && > !TI_SCI_POWER_DOMAIN > default y > help > Enabling this will indicate that the system has separate DM > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile > index fd77b8bbba..6fe36c265c 100644 > --- a/arch/arm/mach-k3/Makefile > +++ b/arch/arm/mach-k3/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/ > obj-$(CONFIG_SOC_K3_J721S2) += j721s2/ > obj-$(CONFIG_SOC_K3_AM625) += am62x/ > obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ > +obj-$(CONFIG_SOC_K3_J784S4) += j784s4/ > obj-$(CONFIG_ARM64) += arm64-mmu.o > obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o > obj-$(CONFIG_ARM64) += cache.o > @@ -16,6 +17,7 @@ obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o > obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o > obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o > obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o > +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o > endif > ifeq ($(CONFIG_SPL_BUILD),y) > obj-$(CONFIG_SOC_K3_AM654) += am654_init.o > @@ -24,6 +26,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o > obj-$(CONFIG_SOC_K3_AM642) += am642_init.o > obj-$(CONFIG_SOC_K3_AM625) += am625_init.o > obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o >
[PATCH v4 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
Add J784S4 initialization files for initial SPL boot. Signed-off-by: Hari Nagalla [ add firewall configurations and change the R5 MCU scratchpad ] Signed-off-by: Manorit Chawdhry Signed-off-by: Dasnavis Sabiya Signed-off-by: Apurva Nandan --- arch/arm/mach-k3/Kconfig | 16 +- arch/arm/mach-k3/Makefile | 3 + arch/arm/mach-k3/arm64-mmu.c | 52 +++ arch/arm/mach-k3/include/mach/hardware.h | 4 + .../mach-k3/include/mach/j784s4_hardware.h| 60 arch/arm/mach-k3/include/mach/j784s4_spl.h| 47 +++ arch/arm/mach-k3/include/mach/spl.h | 4 + arch/arm/mach-k3/j784s4_fdt.c | 15 + arch/arm/mach-k3/j784s4_init.c| 332 ++ 9 files changed, 526 insertions(+), 7 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/j784s4_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/j784s4_spl.h create mode 100644 arch/arm/mach-k3/j784s4_fdt.c create mode 100644 arch/arm/mach-k3/j784s4_init.c diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 9168bf842d..0af2ec6ddb 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -22,6 +22,9 @@ config SOC_K3_AM625 config SOC_K3_AM62A7 bool "TI's K3 based AM62A7 SoC Family Support" +config SOC_K3_J784S4 + bool "TI's K3 based J784S4 SoC Family Support" + endchoice config SYS_SOC @@ -30,7 +33,7 @@ config SYS_SOC config SYS_K3_NON_SECURE_MSRAM_SIZE hex default 0x8 if SOC_K3_AM654 - default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x1c if SOC_K3_AM642 default 0x3c000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -42,7 +45,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE hex default 0x58000 if SOC_K3_AM654 - default 0xc if SOC_K3_J721E || SOC_K3_J721S2 + default 0xc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 default 0x18 if SOC_K3_AM642 default 0x38000 if SOC_K3_AM625 || SOC_K3_AM62A7 help @@ -52,15 +55,14 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE config SYS_K3_MCU_SCRATCHPAD_BASE hex default 0x4028 if SOC_K3_AM654 - default 0x41cff9fc if SOC_K3_J721S2 - default 0x41cff9fc if SOC_K3_J721E + default 0x41cff9fc if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the base address of MCU Scratchpad RAM. config SYS_K3_MCU_SCRATCHPAD_SIZE hex default 0x200 if SOC_K3_AM654 - default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 + default 0x200 if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4 help Describes the size of MCU Scratchpad RAM. @@ -68,7 +70,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX hex default 0x41c7fbfc if SOC_K3_AM654 default 0x41cffbfc if SOC_K3_J721E - default 0x41cfdbfc if SOC_K3_J721S2 + default 0x41cfdbfc if SOC_K3_J721S2 || SOC_K3_J784S4 default 0x701bebfc if SOC_K3_AM642 default 0x43c3f290 if SOC_K3_AM625 default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R @@ -172,7 +174,7 @@ config K3_ATF_LOAD_ADDR config K3_DM_FW bool "Separate DM firmware image" - depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN + depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_J784S4) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN default y help Enabling this will indicate that the system has separate DM diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index fd77b8bbba..6fe36c265c 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e/ j7200/ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/ obj-$(CONFIG_SOC_K3_AM625) += am62x/ obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/ +obj-$(CONFIG_SOC_K3_J784S4) += j784s4/ obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-$(CONFIG_ARM64) += cache.o @@ -16,6 +17,7 @@ obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o endif ifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_SOC_K3_AM654) += am654_init.o @@ -24,6 +26,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_init.o obj-$(CONFIG_SOC_K3_AM642) += am642_init.o obj-$(CONFIG_SOC_K3_AM625) += am625_init.o obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_init.o +obj-$(CONFIG_SOC_K3_J784S4) += j784s4_init.o obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o endif obj-y += common.o security.o diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
