On 5/22/23 7:35 AM, Kamlesh Gurudasani wrote:
Neha Malcom Francis <n-fran...@ti.com> 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 <kaml...@ti.com>
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 <kaml...@ti.com>
Signed-off-by: Neha Francis <n-fran...@ti.com>
Signed-off-by: Neha Malcom Francis <n-fran...@ti.com>
(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.
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.
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.
That would be the better solution, if GP cannot use tispl.bin_HS
currently then the tispl.bin generation fix should go first, then this
patch, then the rest of binman changes can go in after (next cycle).
Andrew
