[PATCH v4 23/23] configs: am64x: Enable TI_SECURE_DEV options
kamlesh at ti.com
Mon May 22 16:50:49 CEST 2023
Andrew Davis <afd at ti.com> 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
> 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.
More information about the U-Boot