Re: [PATCH] configs: am62x_evm_a53_defconfig: Remove CONFIG_SYS_BOOTM_LEN
Manorit Chawdhry writes: > Hi Kamlesh, > > On 17:20-20240708, Kamlesh Gurudasani wrote: >> Increase the maximum size of the buffer that is used to decompress >> the OS image in to. >> >> If image size is greater than the buffer, boot >> will fail with following error, >> "Error: inflate() returned -5" >> "gzip compressed: uncompress error -1" >> >> Default limit for ARM64 platforms is 0x400, remove >> CONFIG_SYS_BOOTM_LEN=0x800, so that it follows default limit. > > Why were we failing with a larger buffer size..? Thanks for reviewing, Manorit. Typo in the commit msg, extra zero. It should be 0x800000 as in actual diff. Will fix in v2. Kamlesh > > Regards, > Manorit > >> >> Signed-off-by: Kamlesh Gurudasani >> --- >> configs/am62x_evm_a53_defconfig | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/configs/am62x_evm_a53_defconfig >> b/configs/am62x_evm_a53_defconfig >> index ca993b427b..dfa5ecc847 100644 >> --- a/configs/am62x_evm_a53_defconfig >> +++ b/configs/am62x_evm_a53_defconfig >> @@ -32,7 +32,6 @@ CONFIG_SPL_SPI=y >> CONFIG_SPL_LOAD_FIT=y >> CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 >> CONFIG_BOOTSTD_FULL=y >> -CONFIG_SYS_BOOTM_LEN=0x80 >> CONFIG_BOOTCOMMAND="run findfdt; run envboot; bootflow scan -lb" >> CONFIG_BOARD_LATE_INIT=y >> CONFIG_SPL_MAX_SIZE=0x58000 >> >> --- >> base-commit: fd46ea0e701920eb205c2bce9d527bf0dec10b59 >> change-id: 20240708-remove-bootm-len-ab4e46039656 >> >> Best regards, >> -- >> Kamlesh Gurudasani >>
[PATCH] configs: am62x_evm_a53_defconfig: Remove CONFIG_SYS_BOOTM_LEN
Increase the maximum size of the buffer that is used to decompress the OS image in to. If image size is greater than the buffer, boot will fail with following error, "Error: inflate() returned -5" "gzip compressed: uncompress error -1" Default limit for ARM64 platforms is 0x400, remove CONFIG_SYS_BOOTM_LEN=0x800, so that it follows default limit. Signed-off-by: Kamlesh Gurudasani --- configs/am62x_evm_a53_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index ca993b427b..dfa5ecc847 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -32,7 +32,6 @@ CONFIG_SPL_SPI=y CONFIG_SPL_LOAD_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 CONFIG_BOOTSTD_FULL=y -CONFIG_SYS_BOOTM_LEN=0x80 CONFIG_BOOTCOMMAND="run findfdt; run envboot; bootflow scan -lb" CONFIG_BOARD_LATE_INIT=y CONFIG_SPL_MAX_SIZE=0x58000 --- base-commit: fd46ea0e701920eb205c2bce9d527bf0dec10b59 change-id: 20240708-remove-bootm-len-ab4e46039656 Best regards, -- Kamlesh Gurudasani
Re: [PATCH] arm: dts: k3-*-binman: Make default DM file optional
Neha Malcom Francis writes:
> The default DM firmware path is non-optional as of now. Make it
> optional so that users that choose to provide DM via TI_DM argument
> instead of BINMAN_INDIRS can do so without build errors.
>
> Signed-off-by: Neha Malcom Francis
> ---
> arch/arm/dts/k3-am625-sk-binman.dtsi | 1 +
> arch/arm/dts/k3-am62a-sk-binman.dtsi | 1 +
> arch/arm/dts/k3-am62p-sk-binman.dtsi | 1 +
> arch/arm/dts/k3-j7200-binman.dtsi| 1 +
> arch/arm/dts/k3-j721e-binman.dtsi| 1 +
> arch/arm/dts/k3-j721s2-binman.dtsi | 1 +
> arch/arm/dts/k3-j784s4-binman.dtsi | 1 +
> 7 files changed, 7 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
> b/arch/arm/dts/k3-am625-sk-binman.dtsi
> index dfd38d64f63..eddf05594d5 100644
> --- a/arch/arm/dts/k3-am625-sk-binman.dtsi
> +++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
> @@ -149,6 +149,7 @@
> filename = "ti-dm.bin";
> blob-ext {
> filename =
> "ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f";
> + optional;
> };
> };
>
> diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
> b/arch/arm/dts/k3-am62a-sk-binman.dtsi
> index ec3bf7ce913..6f82f26bf85 100644
> --- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
> +++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
> @@ -152,6 +152,7 @@
> filename = "ti-dm.bin";
> blob-ext {
> filename =
> "ti-dm/am62axx/ipc_echo_testb_mcu1_0_release_strip.xer5f";
> + optional;
> };
> };
> ti-spl {
> diff --git a/arch/arm/dts/k3-am62p-sk-binman.dtsi
> b/arch/arm/dts/k3-am62p-sk-binman.dtsi
> index dea14945bf5..2233921d320 100644
> --- a/arch/arm/dts/k3-am62p-sk-binman.dtsi
> +++ b/arch/arm/dts/k3-am62p-sk-binman.dtsi
> @@ -72,6 +72,7 @@
>
> blob-ext {
> filename =
> "ti-dm/am62pxx/ipc_echo_testb_mcu1_0_release_strip.xer5f";
> + optional;
> };
> };
>
> diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
> b/arch/arm/dts/k3-j7200-binman.dtsi
> index e8020fec2dc..a524b246187 100644
> --- a/arch/arm/dts/k3-j7200-binman.dtsi
> +++ b/arch/arm/dts/k3-j7200-binman.dtsi
> @@ -281,6 +281,7 @@
> filename = "ti-dm.bin";
> blob-ext {
> filename =
> "ti-dm/j7200/ipc_echo_testb_mcu1_0_release_strip.xer5f";
> + optional;
> };
> };
> ti-spl {
> diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
> b/arch/arm/dts/k3-j721e-binman.dtsi
> index 1514d897634..0483fc5dd3f 100644
> --- a/arch/arm/dts/k3-j721e-binman.dtsi
> +++ b/arch/arm/dts/k3-j721e-binman.dtsi
> @@ -310,6 +310,7 @@
> filename = "ti-dm.bin";
> blob-ext {
> filename =
> "ti-dm/j721e/ipc_echo_testb_mcu1_0_release_strip.xer5f";
> + optional;
> };
> };
> ti-spl {
> diff --git a/arch/arm/dts/k3-j721s2-binman.dtsi
> b/arch/arm/dts/k3-j721s2-binman.dtsi
> index 46297ebef9e..d121d8c0c54 100644
> --- a/arch/arm/dts/k3-j721s2-binman.dtsi
> +++ b/arch/arm/dts/k3-j721s2-binman.dtsi
> @@ -149,6 +149,7 @@
> filename = "ti-dm.bin";
> blob-ext {
> filename =
> "ti-dm/j721s2/ipc_echo_testb_mcu1_0_release_strip.xer5f";
> + optional;
> };
> };
> ti-spl {
> diff --git a/arch/arm/dts/k3-j784s4-binman.dtsi
> b/arch/arm/dts/k3-j784s4-binman.dtsi
> index e4dd6e14a66..146cd7652c9 100644
> --- a/arch/arm/dts/k3-j784s4-binman.dtsi
> +++ b/arch/arm/dts/k3-j784s4-binman.dtsi
> @@ -170,6 +170,7 @@
>
> blob-ext {
> filename =
> "ti-dm/j784s4/ipc_echo_testb_mcu1_0_release_strip.xer5f";
> + optional;
> };
> };
>
> --
> 2.34.1
Reviewed-by: Kamlesh Gurudasani
Re: [PATCH] arm: mach-k3: am642: Fix reset for workaround errata ID i2331
Andrew Davis writes:
> To workaround an issue in AM642 we reset the SoC in early boot. For that
> we first probed the sysreset driver by calling uclass_get_device(). The
> ti-sci sysreset driver is now probed during the ti-sci firmware probe.
> Update this call to probe the firmware driver which will then probe
> the sysreset driver allowing do_reset() to again function as expected.
>
> Reported-by: Jonathan Humphreys
> Fixes: fc5d40283483 ("firmware: ti_sci: Bind sysreset driver when enabled")
> Signed-off-by: Andrew Davis
> ---
> arch/arm/mach-k3/am642_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
> index ddf47ef0a9b..80c3cb3479f 100644
> --- a/arch/arm/mach-k3/am642_init.c
> +++ b/arch/arm/mach-k3/am642_init.c
> @@ -226,7 +226,7 @@ void board_init_f(ulong dummy)
>* The warm reset realigns internal clocks and prevents the lockup from
>* happening.
>*/
> - ret = uclass_first_device_err(UCLASS_SYSRESET, );
> + ret = uclass_get_device_by_driver(UCLASS_FIRMWARE,
> DM_DRIVER_GET(ti_sci), );
> if (ret)
> printf("\n%s:uclass device error [%d]\n",__func__,ret);
>
> --
> 2.39.2
Tested-by: Kamlesh Gurudasani
on am64x-evm
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
Dhruva Gole writes:
> The secure_hdr needs to be 0 init-ed however this was never being put
> into the secure_buf, leading to possibility of the first 4 bytes of
> secure_buf being possibly garbage.
>
> Fix this by initialising the secure_hdr itself to the secure_buf
> location, thus when we make it 0, it automatically ensures the first 4
> bytes are 0.
>
> Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> Interface (TI SCI)")
> Signed-off-by: Dhruva Gole
> ---
>
> Boot tested for sanity on AM62x SK
> https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
>
> Cc: Nishanth Menon
> Cc: Tom Rini
>
> drivers/firmware/ti_sci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index f5f659c11274..83ee8401a731 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
> {
> struct k3_sec_proxy_msg *msg = >tx_message;
> u8 secure_buf[info->desc->max_msg_size];
> - struct ti_sci_secure_msg_hdr secure_hdr;
> + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> ti_sci_secure_msg_hdr *)secure_buf;
> int ret;
>
> if (info->is_secure) {
> /* ToDo: get checksum of the entire message */
> - secure_hdr.checksum = 0;
> - secure_hdr.reserved = 0;
> + secure_hdr->checksum = 0;
> + secure_hdr->reserved = 0;
> memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
secure_hdr is pointer now, the value may be same but (struct
ti_sci_secure_msg_hdr) would make more sense
Regards,
Kamlesh
> xfer->tx_message.len);
>
>
> base-commit: a1448e3cf9a0602d284566d6cacf60b96c3c1316
> --
> 2.34.1
Re: [RFC PATCH 0/2] RFC version for ATF and OP-TEE Firewalling
Manorit Chawdhry writes: > This is a start to firewall ATF and OP-TEE memory regions using the > firewalls present in K3 SoCs. Please give reviews as to what can be > better in the implementation. > > Signed-off-by: Manorit Chawdhry Hi Manorit, thanks for the patches. I hope this solution is easily scalable to sitara devices as well. Mainly considering the difference in type of firewalls. Regards, Kamlesh
Re: [EXTERNAL] [PATCH] common: spl: Warn about overflow of SRAM stack
Vignesh Raghavendra writes: > If early stack usage is exactly same as SIZE_LIMIT_PROVIDE_STACK, then > its most likely to have overflowed beyond this limit and corrupted any > regions beyond stack. Warn about this to the user. > > Signed-off-by: Vignesh Raghavendra > --- > > I found this useful when debugging slient corruption of code/data leading > to random failures post relocation. > > common/spl/spl.c | 7 +++ > 1 file changed, 7 insertions(+) Reviewed-by: Kamlesh Gurudasani
Re: [PATCH v4 23/23] configs: am64x: Enable TI_SECURE_DEV options
Andrew Davis writes: >>> > > Depending on when we expect this binman series to go in should guide > how we handle this. My hope is that this can go into -next very > soon, but that would still mean it won't hit master branch until > v2023.10. > > Fixing the issue Kamlesh describes below in time for v2023.07 > would be my preference then (if Tom is willing to take it as a fix > for v2023.07 that is). I know this fix will be unneeded once > this binman series goes in so it feels like throw away work, > but I don't want AM64x HS-FS broken until v2023.10 :( > >> If we do not have TI_SECURE_DEV option enabled, generated >> tispl.bin_fs will not have capability too parse signed u-boot.img_fs. >> >> tispl.bin_fs will be able to parse u-boot.img_unsigned. >> > > Are you sure about these two above statements? SPL should be able to > parse signed FIT images on GP with or without TI_SECURE_DEV. The way I understand, POST_PROCESS flag is enabled by default if we enable TI_SECURE_DEV option, spl can parse signed images if POST_PROCESS flag is enabled. If we enable POST_PROCESS flag seperately without enabling TI_SECURE flag, GP spl should be able to parse signed images, but that is not defined in current am64 defconfig. That flag is enabled in am62x defconfig, that is able to parse signed u-boot without TI_SECURE_DEV enabled. That was actually one of my concern, if there is no TI_SECURE_DEV enabled, don't generate signed images at all in binman flow, because they won't work. But going forward as we are planning to not have new devices with GP, we can ignore this thing. I got your point though, I'll just go ahead and send seperate patch for enabling TI_SECURE_DEV and the fix for generating tispl.bin for GP > >> If we enable TI_SECURE_DEV in KIG flow, only tispl.bin_HS will be >> generated, which breaks the GP flow.
Re: [EXTERNAL] Re: [PATCH v4 23/23] configs: am64x: Enable TI_SECURE_DEV options
Kamlesh Gurudasani writes: > Neha Malcom Francis writes: > >> Hi Andrew >> >> On 18/05/23 22:09, Andrew Davis wrote: >>> On 5/18/23 9:27 AM, Neha Malcom Francis wrote: >>>> From: Kamlesh Gurudasani >>>> >>>> AM64x family of SoCs by default will have some level of security >>>> enforcement checking. Enable CONFIG_TI_SECURE_DEVICE by default so all >>>> levels of secure SoCs will boot with binman. >>>> >>>> Signed-off-by: Kamlesh Gurudasani >>>> Signed-off-by: Neha Francis >>>> Signed-off-by: Neha Malcom Francis >> >> (apologies for the incorrect tags) >> >>>> --- >>> >>> This fix is independent of the binman changes and should go >>> in first anyway to keep bisectability. >>> >>> Andrew >>> >> >> This fix breaks KIG flow though, which is why it was decided to be put >> in along with the binman series. >> > If we do not have TI_SECURE_DEV option enabled, generated > tispl.bin_fs will not have capability too parse signed u-boot.img_fs. > > tispl.bin_fs will be able to parse u-boot.img_unsigned. > > If we enable TI_SECURE_DEV in KIG flow, only tispl.bin_HS will be > generated, which breaks the GP flow. By GP flow, I mean the scripts to support the GP
Re: [PATCH v4 23/23] configs: am64x: Enable TI_SECURE_DEV options
Neha Malcom Francis writes: > Hi Andrew > > On 18/05/23 22:09, Andrew Davis wrote: >> On 5/18/23 9:27 AM, Neha Malcom Francis wrote: >>> From: Kamlesh Gurudasani >>> >>> AM64x family of SoCs by default will have some level of security >>> enforcement checking. Enable CONFIG_TI_SECURE_DEVICE by default so all >>> levels of secure SoCs will boot with binman. >>> >>> Signed-off-by: Kamlesh Gurudasani >>> Signed-off-by: Neha Francis >>> Signed-off-by: Neha Malcom Francis > > (apologies for the incorrect tags) > >>> --- >> >> This fix is independent of the binman changes and should go >> in first anyway to keep bisectability. >> >> Andrew >> > > This fix breaks KIG flow though, which is why it was decided to be put > in along with the binman series. > If we do not have TI_SECURE_DEV option enabled, generated tispl.bin_fs will not have capability too parse signed u-boot.img_fs. tispl.bin_fs will be able to parse u-boot.img_unsigned. If we enable TI_SECURE_DEV in KIG flow, only tispl.bin_HS will be generated, which breaks the GP flow. Unless, the patch to fix the issue of generating tispl.bin is merged.
Re: [PATCH] arm: mach-k3: common: don't reconfigure background firewalls
Manorit Chawdhry writes: > K3 devices have some firewalls set up by ROM that we usually remove so > that the development is easy in HS devices. > > While removing the firewalls disabling a background region before > disabling the foreground regions keeps the firewall in a state where all > the transactions will be blacklisted until all the regions are disabled. > This causes a race for some other entity trying to access that memory > region before all the firewalls are disabled and causes an exception. > > Since the background regions configured by ROM are in such a manner > that they allow all transactions, don't touch the background regions at > all. > > Signed-off-by: Manorit Chawdhry Reviewed-by: Kamlesh Gurudasani
Re: [PATCH] arm: mach-k3: common: Default to non fitImage boot on HS-FS
Vignesh Raghavendra writes: > Allow non fitImage bootflow on Field Securable (HS-FS) devices in > addition to GP, force fitImage boot only on Security enforced (HS-SE) > devices where signed images are necessary to maintain chain of trust. > > Signed-off-by: Vignesh Raghavendra Reviewed-by: Kamlesh Gurudasani
Re: [PATCH 0/3] J7 merge HS configs
Manorit Chawdhry writes: > This series depends on the fixes provided for j721e as that series also > includes some base support for running the other HS platforms. > > Link for dependent series > - > https://lore.kernel.org/u-boot/20230324-j721e-upstream-hs-v6-0-5aa43a481...@ti.com/ > > Signed-off-by: Manorit Chawdhry > --- > Manorit Chawdhry (3): > configs: j721s2: Merge the HS and non-HS defconfigs > Kconfig: j721s2: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region > configs: j7200: Merge the HS and non-HS defconfigs All patches look good to me. Reviewed-by: Kamlesh Gurudasani
Re: [PATCH] configs: am62ax: enable secure device configs by default
Bryan Brattlof writes: > TI's security enforcing SoCs will authenticate each binary it loads by > comparing it's signature with keys etched into the SoC during the boot > up process. The am62ax family of SoCs by default will have some level of > security enforcement checking. To keep things as simple as possible, > enable the CONFIG_TI_SECURE_DEVICE options by default so all levels of > secure SoCs will work out of the box > > Enable the CONFIG_TI_SECURE_DEVICE by default > > Signed-off-by: Bryan Brattlof Reviewed-by: Kamlesh Gurudasani
Re: [EXTERNAL] Re: [PATCH 0/2] add support for hs bootflows on am62 devices
Tom Rini writes: > On Fri, Mar 17, 2023 at 02:21:16PM +0530, Kamlesh Gurudasani wrote: >> Tom Rini writes: >> ... >> >> Hi Tom, >> >> >> >> Could you please review and merge this patches as these are bug fixes to >> >> get HS devices working. >> > >> > Is this a regression fix vs v2023.01 or new feature support? Thanks. >> Its regression fix vs 2023.01 for HS devices. Thanks. > > To be clear, when did HS support work on am62, upstream? We have three devices GP, HS-FS and HS-SE GP and HS-FS works with same r5 spl config. With recent changes in system firmware update it broke HS-FS, beacuse firewall condition were overlooked while adding r5-spl config. This series make sure that those firewall conditions are satisfied. Once HS-FS is working it needs small change in r5-spl config to get HS-SE working. Changes needed for HS-SE to work will be sent in another patch. ~Kamlesh > > -- > Tom
Re: [EXTERNAL] Re: [PATCH 0/2] add support for hs bootflows on am62 devices
Tom Rini writes: ... >> Hi Tom, >> >> Could you please review and merge this patches as these are bug fixes to >> get HS devices working. > > Is this a regression fix vs v2023.01 or new feature support? Thanks. Its regression fix vs 2023.01 for HS devices. Thanks. ~Kamlesh > > -- > Tom
Re: [PATCH 0/2] add support for hs bootflows on am62 devices
Bryan Brattlof writes: > Hi Kamlesh! > > On March 2, 2023 thus sayeth kaml...@ti.com: >> From: Kamlesh Gurudasani >> >> Add support for high security bootflow on am62 devices. >> >> On HS devices, ROM and TIFS will protect the RAM regions with >> firewalls. This means the wakeup domain's SPL will need to move the >> stack and heap to HSM RAM to ensure it stays within its allotted >> memory regions. >> >> Kamlesh Gurudasani (2): >> arm: mach-k3: am62: move scratch board area to HSM RAM >> configs: am62: move stack and heap to HSM RAM >> >> arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +-- >> configs/am62x_evm_r5_defconfig| 16 +++- >> 2 files changed, 12 insertions(+), 7 deletions(-) > > Thanks for getting this fixed! Does TIFS drop the On Chip SRAM firewall > completely once it's started? or only for the r5? > > Reviewed-by: Bryan Brattlof > > ~Bryan Hi Tom, Could you please review and merge this patches as these are bug fixes to get HS devices working. Thanks. ~Kamlesh
Re: [PATCH v3 3/4] Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
Manorit Chawdhry writes: > In non-combined boot flow for K3, all the firewalls are locked by default > until sysfw comes up. Rom configures some of the firewall for its usage > along with the SRAM for R5 but the PSRAM region is still locked. > > The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the > firewall exception before sysfw came up. The exception started happening > after adding multi dtb support that accesses the scratchpad for reading > EEPROM contents. > > The commit changes R5 MCU scratchpad for j721e to an SRAM region. > Reviewed-by: Kamlesh Gurudasani ...
Re: [PATCH 0/2] add support for hs bootflows on am62 devices
Bryan Brattlof writes: > Hi Kamlesh! > > On March 2, 2023 thus sayeth kaml...@ti.com: >> From: Kamlesh Gurudasani >> >> Add support for high security bootflow on am62 devices. >> >> On HS devices, ROM and TIFS will protect the RAM regions with >> firewalls. This means the wakeup domain's SPL will need to move the >> stack and heap to HSM RAM to ensure it stays within its allotted >> memory regions. ... > > Thanks for getting this fixed! Does TIFS drop the On Chip SRAM firewall > completely once it's started? or only for the r5? It is open completely after TIFS drops it. It is generic RAM, should be available for use to all cores. Ideally, it should have been opened up by ROM only, then we wouldn't have run in to this issue. (r5 accessing it before TIFS opens it up) Thanks for the review. > Reviewed-by: Bryan Brattlof > > ~Bryan
Re: [PATCH 0/2] add support for hs bootflows on am62 devices
Kamlesh Gurudasani writes: Please ignore this series on personal id, bouncing back on u-boot@lists.denx.de Will debug and post on u-boot@lists.denx.de directly. > Add support for high security bootflow on am62 devices. > > On HS devices, ROM and TIFS will protect the RAM regions with > firewalls. This means the wakeup domain's SPL will need to move the > stack and heap to HSM RAM to ensure it stays within its allotted > memory regions. > > Kamlesh Gurudasani (2): > arm: mach-k3: am62: move scratch board area to HSM RAM > configs: am62: move stack and heap to HSM RAM > > arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +-- > configs/am62x_evm_r5_defconfig| 16 +++- > 2 files changed, 12 insertions(+), 7 deletions(-) > > -- > 2.34.1
Re: [PATCH 0/5] add support for hs bootflows to am62a
Bryan Brattlof writes: > Hello everyone! > > Texas Instruments has started to enable security settings inside all the > boot ROM and TIFS firmware in all of their SoCs. One of the few changes > this brings is ROM and TIFS will now begin protecting the RAM regions > they're using with firewalls. > > This means the wakeup domain's SPL will need to move the stack and heap > to HSM RAM to ensure it stays within its allotted memory regions as well > as move the needed boot information to the main domain's bootloaders that > will no longer have access to HSM RAM. > > We will also need to edit the bootcmd to pull in the kernel and dtb's > fitImage if uboot is enforcing the high security bootflow. While we're > editing this bootcmd, we can also take the opportunity to convert it to > a distro_bootcmd macro. > > Thanks for reviewing! > ~Bryan > > Bryan Brattlof (5): > configs: restrict am62ax wakup SPL size > configs: am62a: move stack and heap to HSM RAM > arm: mach-k3: copy bootindex to OCRAM for main domain SPL > configs: am62a: convert bootcmd to distro_bootcmd > configs: am62a: use kernel fitImage when using secure bootflow > > arch/arm/mach-k3/Kconfig | 4 ++- > arch/arm/mach-k3/am62a7_init.c| 16 +++-- > .../arm/mach-k3/include/mach/am62a_hardware.h | 17 +- > configs/am62ax_evm_a53_defconfig | 1 - > configs/am62ax_evm_r5_defconfig | 15 +--- > include/configs/am62ax_evm.h | 34 +-- > 6 files changed, 74 insertions(+), 13 deletions(-) > > > base-commit: 52d91e1c20b399ddab276e2c03e5788ed5e5fdd2 > -- > 2.39.0 All patches look good to me. Reviewed-by: Kamlesh Gurudasani Thanks
