Re: [Buildroot] [PATCH v4 00/20] Add support for AM62x-SK HS-FS devices

[Romain Naour <romain.naour@smile.fr>]

Hi Andreas,

Le 20/02/2024 à 21:04, Andreas Dannenberg a écrit :
> Hi Romain,
> 
> On Tue, Feb 20, 2024 at 11:03:54AM +0100, Romain Naour wrote:
>> Hello Andreas,
>>
>> Le 20/02/2024 à 01:41, Andreas Dannenberg a écrit :
>>> On Mon, Feb 19, 2024 at 12:24:52PM +0100, Romain Naour wrote:
>>>> Hello Michael,
>>>>
>>>> Le 19/02/2024 à 12:02, Michael Nazzareno Trimarchi a écrit :
>>>>> Hi Romain
>>>>>
>>>>> On Mon, Feb 19, 2024 at 10:30 AM Romain Naour <romain.naour@smile.fr> wrote:
>>>>>>
>>>>>> Hello Dario,
>>>>>>
>>>>>> Le 17/02/2024 à 17:02, Dario Binacchi a écrit :
>>>>>>> The SK-AM62B-P1 is the newest version of SK-AM62 which includes
>>>>>>> high-security field-securable (HS-FS) silicon to optionally customize keys
>>>>>>> and encryption for security applications.
>>>>>>> This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option,
>>>>>>> which, however, was buggy. This series fixes the errors and bumps the Linux
>>>>>>> kernel and U-Boot required for such a new device.
>>>>>>>
>>>>>>> This series, which in my humble opinion, should have been immediately
>>>>>>> considered to correct the compilation errors in case of HS-FS devcies, has
>>>>>>> seen an increase in patches in version 4 to remove the ti-k3-image-gen
>>>>>>> package thanks to Binman. Additionally, it shares some modifications and
>>>>>>> views on how to implement certain changes with the series
>>>>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=394840.
>>>>>>> Therefore, I think it is necessary not to run them in parallel but to decide
>>>>>>> whether to merge one before the other or to consider a single series where
>>>>>>> the patches can be coherent with each other. I am available for both solutions.
>>>>>>> Let me know.
>>>>>>
>>>>>> Thanks for this new version. I beleive both series should be merged into one
>>>>>> since we want to follow u-boot switch to binman, add more TI K3 SoC support and
>>>>>> keeping exising am62x ans am64x working in GP or HS/HS-FS.
>>>>>>
>>>>>
>>>>> Because the Dario patchset was sent before (end of November), it's
>>>>> reasonable to review and adjust that one
>>>>> and apply your changes for ti_j721e_sk on top of it. It think that is
>>>>> a standard way to make people happy about
>>>>> their work and contribution.
>>>>
>>>> Actually, the two series are about the same topic: TI K3 SoC support (GP, HS,
>>>> HS-FS) not only AM62x-SK HS-FS devices
>>>>
>>>> But due to the complexity of the BSP, the boot flow (4 way to boot!) and the
>>>> switch from custom tool to binman... this series is really difficult to review
>>>> without having a good understanding of TI K3 architecture peculiarity and having
>>>> one of each TI evaluation boards 🙂
>>>
>>> Although I helped conceive some of this and the associated tooling early
>>> on, some of the what may look strange architectural decisions were driven
>>> by different use cases and requirements for the different devices
>>> (especially around automotive fast/early boot, but also security) in
>>> combination with limited on-chip SRAM... So this where we are at now. A
>>> future AM6x device variant will have yet another boot flow, but I can
>>> already say it will be very much simplified over what we have today :)
>>
>> About existing boot flow, I found two recent commit in u-boot that state that
>> the "Split binary" (that requires sysfw.itb) is already a legacy boot flow:
> 
> It's called "legacy boot flow" because it was the boot flow used on the
> first K3 devices that were released (AM65x, J721E). This boot flow was
> not used on follow-on devices. The characteristics of this boot flow is
> that the initial FW image that gets loaded (tiboot3.bin) doesn't contain
> any device firmwares, but only a bootloader (such as U-Boot SPL). Then
> this boot loader will load the System Firmware firmware + config data
> blob (sysfw.itb) into the dedicated core (called "DMSC" = Device Manager
> and Security Controller). And then addiitonal boot stages will be
> loaded. These devices require this boot flow, and with this it is
> required to be supported by U-Boot (and any Linux distribution or build
> systems that build on that).
> 
> TI is still making/selling those "legacy boot flow" devices, and will
> continue to do so for a very long time. One promiment community
> incarnation that you are probably aware of is the BeagleBone AI-64.

Thank you for the detailed explanation!

I previouly worked on a AM57xx SoC that is nowaday legacy SoC, the latest
ti-kernel 6.1 doesn't support some of the driver that where available in
ti-kernel 5.10 (prueth 100M, RPMsg Sockets over virtio-rpmsg transport (use for
ARM-DSP IPC3.x), TI-RTOS (the csl-common package was also removed from meta-ti)).

Also the TI SDK on this plateform doesn't seems very active [1].

So, I'm worried when I read "legacy" :)

[1]
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1290197/processor-sdk-am57x-legacy-processor-s-linux-update-plan

> 
>> arm: dts: k3-binman: Add support for FIT templates
>>
>>     Add templates for FIT images used extensively across K3 boards with most
>>     of the code common. This includes the FIT portions of:
>>     	- tispl.bin
>>     	- u-boot.img
>>     	- sysfw.itb (in case of legacy boot flow)
>>
>> https://gitlab.com/u-boot/u-boot/-/commit/b153bad0f14168d5fcc02ba6bf1a2cd98daba9b5
>>
>>     arm: dts: k3-*-binman: Move to using templated FITs
>>
>>     Reduce redundancy in code by using templates to generate the A72 boot
>>     binaries (tispl.bin and u-boot.img) as well as R5 boot binary sysfw.itb
>>     (for legacy boot following devices J721E and AM65x).
>>
>> https://gitlab.com/u-boot/u-boot/-/commit/4509b9ff0b8cb26907f9e9c3571b43565c859275
>>
>> Which one should be recommended or avoided for a new design?
> 
> Those commits are just a simplification to reduce duplication. As per
> earlier comment the "legacy boot flow" is something we continue needing
> to support. It isn't supposed to imply that those devices are about to
> disappear.
> 
> Not sure if this answered your question; please let me know.

Yes, thank you.

Best regards,
Romain


> 
> --
> Andreas Dannenberg
> Texas Instruments Inc
> 
> 
>>
>> Best regards,
>> Romain
>>
>>
>>>
>>>> The series (based on Dario's work) about ti_j721e_sk suggested to remove TI
>>>> custom tools replaced by binman along with other improvements.
>>>>
>>>> I'll way for v5 and rebase the ti_j721e_sk on top of it.
>>>
>>> Thank you Romain for your buy-in. Let's focus on getting Dario's series
>>> in good shape and then move onto yours. I'd also like to re-introduce
>>> graphics (I had that working before) but I need to wait for all the
>>> "baseline" stuff to settle first.
>>>
>>>
>>> --
>>> Andreas Dannenberg
>>> Texas Instruments Inc
>>>
>>>
>>>
>>>>
>>>> Best regards,
>>>> Romain
>>>>
>>>>
>>>>>
>>>>> Michael
>>>>>
>>>>>> My main concern is to avoid adding a new package for a tool that is already
>>>>>> deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1].
>>>>>>
>>>>>> Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices".
>>>>>>
>>>>>> [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html
>>>>>>
>>>>>> Best regards,
>>>>>> Romain
>>>>>>
>>>>>>>
>>

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot