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
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
>>
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
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
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
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 ea
l patches look good to me.
Reviewed-by: Kamlesh Gurudasani
ra
Reviewed-by: Kamlesh Gurudasani
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
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
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
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 f
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
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
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
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
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
> 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
21 matches
Mail list logo
