• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 564 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PROCESSOR-SDK-AM64X: Boot process simplification

Walter Stoll
Intellectual 490 points
Part Number: PROCESSOR-SDK-AM64X


Hi Team

Is there any good reason why you bundle U-Boot-SPL into tispl.bin ? Why not just U-Boot ?

Background: We are currently adapting U-Boot four our custom board. I never experienced a boot process that has the complexity of what is implemented on the AM64x. To me the need  for running U-Boot-SPL first on the Cortex-R5F boot processor and later in the boot process again on the Cortex-A53 application processor is not obvious. I would like to understand the rationale behind this approach. Note, that we construct our images by means of Yocto. Therefore we are - in therory - free to change that flow. I would like to bundle U-Boot into tispl.bin. This would simplify the boot process. Moreover we have clear responsibilities. Currently we must be very careful about what we modify in the U-Boot-SPL related code because it affects both, the Cortex-R5F and the Cortex-A53. An awful approach from our point of view.

  • 0
    TI__Guru**** 174211 points

    Hi Walter,

    First I want to clarify - tispl.bin runs by A53 in DDR (and u-boot.img runs on A53 as well). It is tiboot3.bin which runs by R5F in SRAM. So merging tispl.bin with u-boot.img doesn't change the fact that code change could affect both R5F and A53. Can you please elaborate your question?

  • 0 in reply to Bin Liu
    Intellectual 490 points

    Yes, I am aware of that. However, tiboot3.bin comprises U-Boot-SPL for the R5F and tispl.bin comprises again U-Boot-SPL but now for the A53. What I am thinking about is to keep tiboot3.bin as is but modify tispl.bin by replacing U-Boot-SPL with U-Boot. This would result in a new image, e.g. tiuboot.bin, comprising ATF, OPTEE and U-Boot.

  • 0 in reply to Walter Stoll
    TI__Guru**** 174211 points

    Hi Walter,

    It is a good question, why A53 U-Boot has been split into tispl.bin and u-boot.img. I guess this is due to a historical reason that U-Boot has been spit to MLO and u-boot.img in previous 32-bit ARM devices. But I have sent a request to our SW Dev team for comments. I will update once I get a response.

  • +1 in reply to Walter Stoll
    TI__Guru**** 174211 points

    Hi Walter,

    The reason of the A53 U-Boot split is due to a 50ms CAN-FD bus response time requirement in tiboot3.bin for an early K3 platform. Splitting A53 U-Boot makes smaller tispl.bin, so that tiboot3.bin can quickly load it then switch over to the CAN firmware. This convention is then carried over to all later K3 platforms.

    Yes, technically it is possible to merge tispl.bin and u-boot.img together, or even faster, tispl.bin and u-boot.img can be skipped then tiboot3.bin directly load and boot kernel image.

  • 0 in reply to Bin Liu
    TI__Guru 70272 points

    Hi Walter,

    also while optimizations are always possible, we have traditionally wanted to keep some degree of consistency between all our AM6x devices when it comes to the boot flow (R5 SPL --> A53 SPL -> A53 U-Boot) for our production solution. Some devices like the AM62x have a very different on-chip RAM situation vs AM64x and would not allow for a larger tiboot3.bin initial image.

    Some general comments. All this being said we have been working internally on boot-time optimizations that includes cutting out some stages and we want to publish some how-to's regarding this. Also agreed on the complexity being a little bit on the high side, esp. when it comes to working/customizing this on the Yocto side however unless you are after some drastic boot time optimizations I'd recommend sticking to the flow we provide via Yocto to allow for better support/migration. Lastly, we do have future devices in development that will drastically simplify the boot approach (supported by some architectural changes that go along with it).

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 490 points

    Hi Andreas

    Thanks for this background information. I agree that it might not be a good idea to change the bootflow from a maintenance perspective.