Hi there
Hope someone can help on this matter.
Consider that we are going to use a secure enabled OMAP-L138 and the NOR legacy boot mode, based on my understanding:
- The DSP start first and run the DSP ROM bootloader. Meanwhile the ARM is in reset mode (?).
- The DSP ROM bootloader writes the ARM reset vector via the PRUs
- The DSP ROM bootloader reads from the NOR flash the DSP Secondary bootloader
- The DSP Secondary bootloader is decrypted, authenticated and placed in L2 RAM (as mentioned in the sprugq9, or shared RAM?– as mentioned in the SPRAB41E–January 2014)
- The DSP Secondary bootloader is executed
- The DSP and the ARM images are decrypted, authenticated and placed in mDDR
- The ARM is taken out of reset
- The DSP goes to sleep (?)
- The ARM begins the execution of the ARM ROM bootloader
- The DSP ROM bootloader reads from the NOR flash the ARM Secondary bootloader
- The ARM Secondary bootloader is executed
- The DSP is woken up
- Basically a jump to the correct address in mDDR is performed
- At this stage both ARM and DSP are running
QUESTIONS:
- Is the above sequence correct?
- How do we specify the exit mode of the ROM bootloader (NOR legacy is a non-AIS boot mode...)?
- Can we have ARM and DSP images independently encrypted and signed? I assume we can't if the SK_setUserkey can only be called once per boot!
- Could you please confirm the question marks in bold?
- Does the configuration of the BOOT pins apply to both ARM and DSP?
- Is there a way to prevent the ARM ROM bootloader to run? Can we modify the ARM reset vector from within the DSP Secondary bootloader so that when the ARM runs it executes immediately the code in the mDDR?
Thanks,
Giuseppe