• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 567 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.

AM6548: OSPI Loading Redundant Images

Barend Ungrodt
Intellectual 1420 points
Part Number: AM6548

Hi Processors Team,

My customer wants to have redundant images for as much of the boot process as possible, to allow failsafe upgrades.  There appears to be some support for this sort of thing at the hardware level, but it's not clear how to use it.  For example, if they have two copies of the full boot stack in OSPI, somehow each image will need to know which of the two copies to load for the next stage. Do we have any documentation explaining how to achieve this?

Thanks,
Barend

  • 0
    TI__Mastermind 44675 points

    Hello Barend,

    I am wondering if you could please refer to section "4.4.5 OSPI/QSPI/SPI Boot Parameter Table" in the AM65 TRM.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    TI__Intellectual 1420 points

    Hi Krunal,

    The customer has seen that section in the TRM, and from it he wanted to know more about implementation. They plan on using Ethernet to boot a secondary copy of the image, but will still have multiple copies of the main OS and we'll use U-Boot to mediate between them.

    Ultimately what they are expecting will probably happen is:

    1. If the defaults aren't sufficient, a small loader that just updates the parameter tables and restarts.  There would probably be two of these, one at each of Read Addr 0 and Read Addr 1 in the default settings to allow for (rare) safe updates.  We could also use the R5 SPL for this if it's small enough and the primary boot defaults are sufficient to boot it.
    2. Use the system watchdog(s) to catch if the system fails during boot.
    3. Some sort of reboot-persistent flag that indicates whether we successfully booted this system.  If this is not set and we rebooted because of watchdog fire, then we need to go to the secondary boot option.

    So I think the question is:

    1. How do we use the watchdogs to catch a failed boot?  Is there a potential gap in coverage when we transition from the R5 to the A53 in the boot flow?
    2. Can we use the MCU scratchpad to store the reboot-persistent flag?  Is this accessible from the A53?

    Thanks,
    Barend

  • 0 in reply to Barend Ungrodt
    TI__Intellectual 1420 points

    Hi Krunal,

    Any update on this?

    Thanks,
    Barend

  • 0 in reply to Barend Ungrodt
    TI__Mastermind 44675 points
    Hello Barend,

    I apologize for the delayed response but I am discussing your queries with our experts and I will get back to you early next week.

    Regards,
    Krunal
  • 0 in reply to Krunal Bhargav34
    TI__Mastermind 44675 points

    Hello Barend,

    As we discussed earlier, I was able to access MCU scratchpad from the A53 (in CCS) without any problems. Also, based on my discussion with our experts, we currently do not have any examples that demonstrate booting from a secondary image if the primary image fails to boot.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Mastermind 7450 points
    In case someone sees this thread and wants to try booting a redundant image from OSPI: The addresses in chapter 4.4.5 in the TRM are apparently wrong (see e2e.ti.com/.../2971968). The actual addresses are 0x0, 0x400000, 0x800000 and 0xc00000.
    We successfully booted from one of the backup addresses (0x400000), but at this point we were only looking at the R5F core and the SBL to boot a TI-RTOS application. Getting this to work for A53 and U-Boot/Linux is going to be some work but should certainly be doable.

    Regards,
    Dominic
  • 0 in reply to Dominic Rath
    TI__Mastermind 44675 points
    Hello Dominic,

    Thank you for the update and an internal ticket has been filed to update the TRM.

    Regards,
    Krunal