This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: Software update strategy - Best practises

Part Number: AM6442

Tool/software:

Dear TI experts,

we develop a product based on the AM64x-SK design. We plan to have a long lifecycle for our product (> 10 years). Of course, over the whole lifetime we want (and must) be able to roll out software updates. For this, we implement a recovery system (based on swupdate). While it is possible to also update the bootloader, we highly prefer if we could only update the rootfs, and leave our bootloader untouched.

Now the bootloader image (to be precise, tiboot3.bin) contains the SYSFW (see 3.1.1.1. General Information — Processor SDK AM64X Documentation), which is loaded to DMSC during boot, and is used by the linux kernel as well as by the firmware running on the R5 later.

My questions are now:

1. Can the SYSFW be considered as stable? So will every linux kernel (currently we plan to release with 6.12, but in a few years, we might switch to a new one) be able to interact with the SYSFW contained in the never touched tiboot3.bin?

2. The same question arises for the binaries ATF and OPTEE, which are contained in tispl.bin and are loaded from the A53 SPL during boot.

3. If the answer to the first question is No, are there commendations / best practises / examples of a proper product life cycle management?

Many thanks in advance.

BR Benjamin

  • Hi Benjamin,

    1. Can the SYSFW be considered as stable? So will every linux kernel (currently we plan to release with 6.12, but in a few years, we might switch to a new one) be able to interact with the SYSFW contained in the never touched tiboot3.bin?

    Yes, SYSFW is considered as stable now, and its existing ABI won't change, so new kernel won't break. Any ABI change would be by adding new SCI request types in ABI.

    2. The same question arises for the binaries ATF and OPTEE, which are contained in tispl.bin and are loaded from the A53 SPL during boot.

    The answer to #1 applied here too.

    However, please keep in mind that the SYSFW, ATF, or OPTEE in new SDKs might have bugs fixes which you won't get if U-Boot binaries don't get updated on your platform. It may not be an issue though if your system has gone through a full test before releasing it to production.

  • Forgot to mention that though we don't change existing ABI in SYSFW, we don't guarantee the new version kernel won't break with old version SYSFW. The processor SDK doesn't validate such scenarios.

  • Hi Bin,

    thanks for your answer, but I am not sure if I understood the second part correctly. Does it mean, that if we have SYSFW Version 11.00.07 (as it is in TISDK 11.00.09), this version can be considered to be stable (so no breaking changes will happen). But  it can happen that you release  SYSFW Version 12.00.00 (with breaking changes), and support for SYSFW version 11.00.07 wil lbe dropped in the ti-linux-kernel?

    This would mean, that I cannot upgrade to the new kernel version, right?

    Does TI in general support older versions of SYSFW, or is there a high risk that the support for an older SYSFW version is dropped?

     

  • Hi Benjamin,

    Does it mean, that if we have SYSFW Version 11.00.07 (as it is in TISDK 11.00.09), this version can be considered to be stable (so no breaking changes will happen). But  it can happen that you release  SYSFW Version 12.00.00 (with breaking changes), and support for SYSFW version 11.00.07 wil lbe dropped in the ti-linux-kernel?

    Sorry, it doesn't mean that.

    In this example, you can still use SDK12.0 kernel with SDK11.0 SYSFW & U-Boot (in theory, since we don't validate mixed SDK component versions), it is just that anything new or changed in SDK12.0 SYSFW won't be available to SDK 12.0 kernel.

    Does TI in general support older versions of SYSFW, or is there a high risk that the support for an older SYSFW version is dropped?

    The support for SYSFW follows the generic SDK support guidelines, typically for a couple years. But there is a slightly different in how SYSFW is supported. Unlike U-Boot or kernel which are provided in source code and can be patched, the SYSFW is provided in binaries, any new issue found in a particular version can only be fixed in the new SDK releases, which means in new versions of SYSFW.