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 w
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
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
gt; DM_DRIVER_GET(ti_sci), &dev);
> if (ret)
> printf("\n%s:uclass device error [%d]\n",__func__,ret);
>
> --
> 2.39.2
Tested-by: Kamlesh Gurudasani
on am64x-evm
ire message */
> - secure_hdr.checksum = 0;
> - secure_hdr.reserved = 0;
> + secure_hdr->checksum = 0;
> + secure_hdr->reserved = 0;
> memcpy(&secure_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
secure_hdr is poin
his solution is easily scalable to sitara devices as well.
Mainly considering the difference in type of firewalls.
Regards,
Kamlesh
> 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
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 is
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
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
>>> enfo
From: Kamlesh Gurudasani
ATF and OPTEE regions may be firewalled from non-secure entities.
If we still map them for non-secure A53, speculative access may happen,
which will not cause any faults and related error response will be ignored,
but it's better to not to map those regions fo
From: Kamlesh Gurudasani
Do not include ATF and OPTEE regions in MMU table for am64, am62,
am62a as access to those regions is not allowed anyway.
Create separate table as ATF region are at different location for am64
and am62/am62a.
Signed-off-by: Kamlesh Gurudasani
---
arch/arm/mach-k3
e 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
ra
Reviewed-by: Kamlesh Gurudasani
l patches look good to me.
Reviewed-by: Kamlesh Gurudasani
ing. 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
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 dev
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
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
>>
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
...
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
>>
From: Kamlesh Gurudasani
On high security devices, ROM enables firewalls to protect the OCSRAM
region access during bootup. Only after TIFS has started (and had
time to disable the OCSRAM firewall region) will we have write access to
the region.
This means we will need to move the stack &
From: Kamlesh Gurudasani
On high security devices, ROM enables firewalls to protect the OCSRAM
region access during bootup. Only after TIFS has started (and had
time to disable the OCSRAM firewall region) will we have write access to
the region.
So, move scratch board area to HSM RAM.
Signed
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 re
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 reg
fig | 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
26 matches
Mail list logo
