• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 1096 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.

AM6442: HS board keywriter programming and boot sequence.

Zekun Bai
Expert 3955 points
Part Number: AM6442
Other Parts Discussed in Thread: UNIFLASH

Hi, Experts

I want to check if HS board keywriter programming sequence is feasible.

Back ground is customer  use OSPI Norflash as boot media to mass production.

Here is the sequence step by step, please help to double check:

Signed tiboot.bin and other boot files

Use uniflash to store the boot image to Nor flash.

Boot mode on Board is 

Connect PC host to Board through DFU.

Power on, Rom fistly use ospi boot mode to boot, failed because Key have't been wrote to board.

Then Rom jump to backup boot mode, which is DFU boot mode. Keywriter will be used as SBL and boot, key is flashed into ROM.

Power off, power on. Now Rom can succeed to boot use Nor flash boot image.

Please help to check if it is feasible of whole process? Thanks. 

Regards

Zekun

  • 0
    TI__Guru 74911 points

    Hi Zekun,

    I will once check the procedure and get back to you.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru 74911 points

    Hi Zekun,

    The following setup

    => Signed R5 SPL@0x0 offset in OSPI

    => Primary boot: OSPI, Backup boot: USB DFU

    => First POR: Expectation is ROM fails to boot from Primary boot and fallbacks to Backup boot

    will not work. The ROM will accept the Signed R5 SPL on HSFS device and boots the different components on the respective cores. So, the ROM won't fallback to the Backup boot.

    I will get back to you with alternate suggestions.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Expert 3955 points

    Hi, Prashant

    >>The ROM will accept the Signed R5 SPL on HSFS device and boots the different components on the respective cores.

    My question is if we signed and encrypted the binary, even ROM can accept the Signed R5 SPL, it can't boot normally because decryption will failed, am I right? If yes, will it jump to backup boot mode or just failed? Could you help to check if it is right?

    Regards

    Zekun

  • 0 in reply to Zekun Bai
    TI__Guru 74911 points

    Hi Zekun,

    On HSFS devices, the ROM will accept even the signed images with encrypted binaries. The ROM loads the encrypted binary as it is and resets the core to its entry point. Since, the binary is encrypted, the boot ofcourse fails but the important part is ROM will not fallback to the backup bootmode since the failure occurs after the image has been accepted.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Expert 3955 points

    Got it. Thanks. If you have any other feasible ideas, please let me know.

    Thanks.

    Zekun

  • 0 in reply to Zekun Bai
    TI__Guru 74911 points

    Hi Zekun,

    Following are the alternate options for Key Programming and flashing SDK images.

    Option A: Booting from Backup Boot Media

    Requirements

    • Bootmode => Primary: OSPI, Backup: UART/DFU (DFU preferable)
    • Flash is completely empty. More importantly, the flash is erased at 0x0 and 0x400000 offsets so that ROM fallbacks to backup boot.

    Procedure

    On First POR:

    • Device state: HS-FS
    • ROM boots OTP Keywriter from the selected backup boot media.
      • Program the Keys according to the keywriter guide.
      • Convert HS-FS to HS-SE.

    On Second POR:

    • Device state: HS-SE
    • ROM boots flash writer from the selected backup boot media.
      • Flash the SDK images (SBL/Applications)

    On Third POR:

    • Device state: HS-SE
    • ROM boots from the primary boot media OSPI.

    Option B: Booting from Primary Boot Media

    Requirements

    • Bootmode => Primary: OSPI, Backup: Don't Care
    • OSPI is pre-flashed as:
      • OTP Keywriter binary at primary offset of 0x0.
      • Flash writer at redundant offset of 0x400000.

    Procedure

    On First POR:

    • Device state: HS-FS
    • ROM boots OTP Keywriter from the primary offset 0x0 of OSPI.
      • Program the Keys according to the keywriter guide.
      • Convert HS-FS to HS-SE.

    On Second POR:

    • Device state: HS-SE
    • ROM boots flash writer from the redundant offset 0x400000.
      • Flash the SDK images (SBL/Applications)

    On Third POR:

    • Device state: HS-SE
    • ROM boots from the OSPI primary offset 0x0.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Expert 3955 points

    Hi， Prashant

    Really appreciate your so detailed info.

    Here is one question, why second POR won't boot from offset 0x0?

    >>

    On Second POR:

    • Device state: HS-SE
    • ROM boots flash writer from the redundant offset 0x400000.
      • Flash the SDK images (SBL/Applications)

    Regards

    Zekun

  • 0 in reply to Zekun Bai
    TI__Guru 74911 points

    Hi Zekun,

    Zekun Bai said:
    Here is one question, why second POR won't boot from offset 0x0?

    This is because the OTP Keywriter binary, which is flashed at offset 0x0, is an HSFS image and signed with ROM degenerate key (dummy key). So, on second POR (device is HSSE), the ROM checks the authentication of the image at 0x0 which will fail expectedly since the OTP Keywriter is not signed with the programmed keys. The ROM then fallbacks to booting from the redundant offset 0x400000.

    The redundant offset 0x400000 is supposed to store HSSE Flash Writer which ROM will boot successfully.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Expert 3955 points

    Hi Prashant

    OK, it is clear to me. Thanks.

    But regarding sysfw, from my understanding, first POR sysfw need signed with TI dummy key. Second POR, due to sysfw is still be signed by TI dummy key, which should be replaced by the one signed with customer key. It won't boot successfully. Please correct me if I misunderstand.

    Regards

    Zekun 

  • 0 in reply to Zekun Bai
    TI__Guru 74911 points

    Hi Zekun,

    The Sysfw is always signed with the TI keys (not dummy) only on both HSFS and HSSE devices. The customer keys are only used to sign SBL binary or application images.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Expert 3955 points

    Hi, Prashant

    OK, I am new to AM64. I used to support TDA4 product. Jacinto product usually combine several image, including sysfw.dtb, R5_spl, Rm, Pm, into tiboot3.bin. Then signed with customer key. 

    So in SPL boot mode, AM64 sysfw is always signed with TI dummy key, right? 

    Thanks

    Zekun

  • +1 in reply to Zekun Bai
    TI__Guru 74911 points

    Hi Zekun,

    Zekun Bai said:
    Jacinto product usually combine several image, including sysfw.dtb, R5_spl, Rm, Pm, into tiboot3.bin. Then signed with customer key. 

    This is the case with the MPU devices as well. This is called ROM Combined Image Format.

    The SPL tiboot3.bin is created with the following components:

    1) SBL binary

    2) Board Configurations binary

    4) Sysfw certificate binary

    3) Sysfw binary

    The Sysfw binary here is always signed with the TI Keys and the corresponding certificate is provided as a blob with the SDK. The whole tiboot3.bin instead is signed with the customer keys for HSSE devices.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Expert 3955 points

    Thanks Prashant

    Close it.

    Regards

    Zekun

  • 0 in reply to Zekun Bai
    TI__Expert 3955 points

    Hi, Prashant

    I had a meeting with customer and recommend them solution 2.

    They had two questions about this:

    On Second POR:

    • Device state: HS-SE
    • ROM boots flash writer from the redundant offset 0x400000.
      • Flash the SDK images (SBL/Applications)

    1. Why need third POR? Can we flash the SDK images like SBL into 0x400000, second POR will boot from ox0, failed and boot from 0x400000. Is it feasible? What is the extra time consumption of booting from 0x0 then jump to 0x400000? 

    2. If three POR is needed, what is the meaning of flash writer? Do we have this in SDK and from where it load the images to flash? SD card or something? We used to flash images into Norflash via Uniflash tools.

    Regards

    Zekun

  • 0 in reply to Zekun Bai
    TI__Guru 74911 points

    Hi Zekun,

    1. It is feasible but it will come at the following costs:

    • Increased boot time => The ROM will always fail to boot from 0x0 offset and boots SBL from 0x400000 offset. This adds the authentication time for the image at 0x0 offset. The jump is taken as soon as the authentication of the image at 0x0 fails.
    • Less redundancy => Not having any valid SBL image at 0x0 reduces the redundancy in the system. In an ideal system, the SBL is flashed at both offsets 0x0 and 0x400000 so that the ROM can try to boot the same SBL from 0x40000 offset if the ROM fails to authenticate the SBL at 0x0 for any reasons.

    2. The flash writer is any tool that once boots can receive the image and flash them. Depending on the tool, the images can be received from any interface UART, DFU, etc.

    Regards,

    Prashant

  • 0
    TI__Expert 3955 points

    Hi, Prashant

    POR twice is feasible, got it thanks.

    POR 3 times, in second power on, it also need to boot before flash writer. So customer need to integrate the flash writer into SBL or SPL boot flow. As I know, we don't have demo in Jacinto SDK, not sure in Sitara SDK?

    Regards

    Zekun

  • 0 in reply to Zekun Bai
    TI__Guru 74911 points

    Hi Zekun,

    The flash writer can be single stage (SBL/SPL based) or multi stage application. For instance,

    • MCU+ SDK: It has single stage SBL based UART Uniflash & DFU Uniflash. The respective Uniflash image can be flashed at 0x400000 which will boot on second POR. Once boots, it waits for images to be received over respective interface and flash them.
    • Processor SDK: The A53 U-Boot is leveraged for flashing via UART, DFU, or Ethernet. It is a multi stage boot with the different images flashed as shown below. On second POR, ROM boots HSSE tiboot3.bin from 0x400000 which boots subsequent images from their offsets. Once A53 U-Boot boots, it can trigger the flashing procedure.
      • tiboot3.bin @0x400000
      • tispl.bin @0x100000 (default)
      • u-boot.img @0x300000 (default)

    I can think of one more approach around Key Programming and Flashing images.

    Option C

    Requirements

    • Bootmode => Primary: OSPI, Backup: Don't Care
    • OSPI is pre-flashed as:
      • OTP Keywriter binary at primary offset of 0x0.
      • All the boot images except SBL flashed at their respective offsets not overlapping with the OTP Keywriter and Flash Writer.
      • SBL flashed at some known location X in the OSPI not overlapping with anything.
      • Flash writer at redundant offset of 0x400000 => This flash writer is single stage SBL/SPL based with the only job of moving the SBL from known location X to primary offset 0x0 and optionally redundant offset 0x400000.

    Procedure

    On First POR:

    • Device state: HS-FS
    • ROM boots OTP Keywriter from the primary offset 0x0 of OSPI.
      • Program the Keys according to the keywriter guide.
      • Convert HS-FS to HS-SE.

    On Second POR:

    • Device state: HS-SE
    • ROM boots flash writer from the redundant offset 0x400000.
      • Flash writer copies the SBL image from known location X to the primary offset 0x0 and optionally redundant offset 0x400000.

    On Third POR:

    • Device state: HS-SE
    • ROM boots from the OSPI primary offset 0x0.

    Please note these are only suggestions and the customer should test them thoroughly.

    Regards,

    Prashant