• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 493 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.

Original question:

AM6548: OSPI Loading Redundant Images

AM6548: OSPI redundant boot / backup addresses

Dominic Rath
Mastermind 7450 points
Part Number: AM6548

Dear TI team,

we're looking into possibilities of having redundant copies of the SBL for a TI-RTOS R5F application on a custom board that's going to boot from QSPI.

I found (mostly out of luck - imho this is hidden too well) that the AM65x ROM uses several backup addresses when booting from flash devices. The TRM lists these addresses for OSPI/QSPI/SPI in table 4-55:

I tried putting my SBL image at 0x20000, keeping the area from 0x00000 to 0x1FFFF erased, but the board wouldn't boot.

While trying to figure out if there's any way of debugging this, I noticed that the AM65x apparently holds the boot parameter table that it uses in RAM, so I had a look at the memory listed in Table 4-110:

I dumped the content at these addresses using the debugger, and found content that mostly matched the documentation, but with different backup read addresses:

Starting from address 0x41C7FD28 (0x41c7fc00 + 296) I read the values 00000000, 00400000, 00800000 and 00C00000.

After putting my SBL image at offset 0x400000 instead of 0x20000, the system booted just fine.

What I'd like to know is:

  • Is this a supported use-case, i.e. should I be able to locate a SBL image at one of the backup addresses and expect the system to boot from there?
  • Are my findings about the actual backup addresses for OSPI correct, or is there something else wrong with our setup/approach that leads to these addresses instead of the ones from the TRM?
  • If the AM65x PG1.0 actually uses 0x400000 etc. as the backup addresses for OSPI boot, is this intentional and just a mistake in the documentation, or is this a bug in the ROM, and future versions of the AM65x are going to use the offsets from the TRM? The smaller step size would probably be better suited to xSPI flashes, since these are most likely only a few MB.

Regards,

Dominic

  • 0
    TI__Guru** 116170 points
    Dominic,

    The TRM is directly created using the Boot ROM spec and I believe the ROM on this device is designed to support this boot use case however I need to check with the Boot ROM team to check the implementation in PG 1.0 and confirm that this feature was tested before providing any further guidance.

    The ROM team is currently a little tied up so please expect some delay in my response. I will post a response early next week based on whatI hear from them.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Mastermind 7450 points
    Hello Rahul,
    did you manage to get any feedback from your ROM team?
    Regards,
    Dominic
  • 0 in reply to Dominic Rath
    TI__Guru** 116170 points

    Dominic,

    Yes, I finally heard back from them this morning. Here is the update from the ROM team.  

    This looks like an error in the TRM. The actual addresses are:

    0, 0x40_0000, 0x80_0000 and 0xc0_0000.

    The feature was tested on pre-silicon simulators, but we are still checking with the silicon verification team to confirm. 

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Mastermind 7450 points

    Hello Rahul,
    thank you for this info.
    This poses a problem for our application, since with a 16MB flash the first backup at 4MB is basically in the middle of the whole area. This puts some restrictions on how we could "partition" our flash.
    The TRM mentions in chapter 4.4 that it is possible to update the boot parameter table by software and then restart the ROM. This suggests that we could achieve the following:
    We put a fixed image in block 0 that just does the boot parameter table update with updated addresses for the flash read addresses (e.g. block 1 as initial and 3 as a backup). The ROM then restarts, and as long as we ensure that block 0 remains untouched and we have one "good" copy we could boot a SBL from either block 1 or block 3.

    Do you know if there's any example on how to do this? Does this mean we need a pre-loader (i.e. actual code) that does the update and the restart, or is this something that works by just putting the updated parameter table at the right loaction, and have the ROM figure out that it needs to re-start with the updated parameter table?

    Regards,
    Dominic

  • 0 in reply to Dominic Rath
    TI__Guru** 116170 points

    Dominic,

    Can you indicate how much of the flash do you  need to use?  there is an option to put the the backup image at the 12MB offset. The ROM will just skip the non-existent backup images at 4 and 8 MB. The basic reason for chosing the 4MB flash image was the fact that we must support all kinds of flashes. The largest ones have very large sectors. We needed to avoid having the primary and backup images both in the same sector – if they are in the same sector then we would have to erase them both before flashing a new image in the field.

    Dominic Rath said:
    The TRM mentions in chapter 4.4 that it is possible to update the boot parameter table by software and then restart the ROM. This suggests that we could achieve the following:
    We put a fixed image in block 0 that just does the boot parameter table update with updated addresses for the flash read addresses (e.g. block 1 as initial and 3 as a backup). The ROM then restarts, and as long as we ensure that block 0 remains untouched and we have one "good" copy we could boot a SBL from either block 1 or block

     As far as I know you are running into another bug in the TRM. We do not support ROM re-entry. We originally planned for it, but was removed from the feature list due to security concerns to support a ROM mechanism that allows user code to jump back into the boot ROM which also supports secure boot.

     One possible suggestion that came from internal discussion of your usecase is that it is possible to use some flashes that have non-constant sector sizes. Some have smaller sectors at either the base address of the flash, or at the high addresses of the flash. If you use a flash with small sectors at the base address you could use a custom two stage boot approach. The first sector can contain the image loaded by ROM. This is then marked as write-protected.

    It loads a secondary boot image that can load the actual desired image. This secondary boot loader can use any desired backup addresses. The idea is that the image loaded by the ROM will never be updated in the field, but the secondary images could be. 

    Regards,

    Rahul

     

  • 0 in reply to Rahul Prabhu
    Mastermind 7450 points

    Hello Rahul,

    thanks for letting me know that re-entering the ROM wont work.

    We don't know yet how big the application will eventually grow, but the idea is that it could well grow to several MB. Putting the backup SBL at 0xc00000 would limit us to < 5 MB per application image (~500 KB first SBL incl. sysfw.bin, two application images from ~500 KB to 12 MB, then the second SBL incl. sysfw.bin).

    Having a fixed intermediate bootloader in block 0 would of course work, but is something that needs to be developed and maintained.

    I guess we'll have to wait and see how big the application eventually turns out and then consider our options.

    Best Regards,

    Dominic