• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 851 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: SYSFW image in PSDK RTOS

Daisuke Maeda
Guru 20395 points

Part Number: AM6548

One of the boot images is the system firmware (SYSFW) image for DMSC subsystem. Which file in the SDK should be used?

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_Foundational_Components.html#id86

 Preparing the SD card

 1. To boot the target the SD card should be bootable. Follow the steps at Creating bootable SD card in windows or Creating bootable SD card in Linux.
 2. To update the SBL with a newer version, copy the sbl image (sbl_mmcsd_img_mcu1_0_release.tiimage) to the SD card. Rename it to tiboot3.bin
 3. To update the SYSFW with a newer version, copy the system firmware image (sysfw.bin) to the SD card.
 4. Copy the generated application image(*.appimage) to the SD card. Rename it to app

Each of the following three image files in pdk will correspond to each device type, and the file name will need to be renamed to "sysfw.bin".

 C:\ti\pdk_am65xx_1_0_7\packages\ti\drv\sciclient\soc\V0
  \sysfw.bin             -> for GP device (Silicon Revision 1.0)
  \sysfw_sr2.bin      -> for GP device (Silicon Revision 2.0)
  \sysfw-hs-enc.bin -> for HS device

Is my understand correct?

Best regards,

Daisuke

  • 0
    Mastermind 7730 points

    Hello Daisuke,

    I can only comment on the GP devices. You are correct that either "...\sysfw.bin" (for SR1.0) or "...\sysfw_sr2.bin" (for SR2.0) needs to be placed on the SD card under the name of "sysfw.bin".

    The name of the SYSFW image is determined by the SBL code, and thus could be changed in "sbl_mmcsd.c" line 218. It would for example be possible to automatically determine the silicion revision you're running on, and load the corresponding file.

    It is important to use the right SYSFW image for your silicon revision, because there are subtle differences between the revisions. If you load a SR1.0 firmware into a SR 2.0 processor and then send a SR2.0 board RM config (the RM config IS determined automatically based on the silicon revision), the Sciclient init will fail.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    Guru 20395 points

    Hi Dominic-san,

    Thank you for your reply.

    How to rebuild the SYSFW image?

    Should the SYSFW image be used as is without rebuilding?

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    Mastermind 7730 points

    Hello Daisuke-san,

    if by "rebuilding" you mean "build the binary from the sources, then wrap as a sysfw.bin: I don't think this is supported, at least I've never seen the sources for the SYSFW.

    It might be possible "wrap the actual binary" (available as ti-sci-firmware-am65x[-sr2]-gp.bin) as a sysfw.bin (basically some x509 certificate): That might be possible, but I'm not sure if the certificate needs to be signed with a known key on GP devices. For u-boot the sysfw is built out of ti-sci-firmware-am65x[-sr2]-gp.bin, so chances are you could wrap it yourself.

    Is there a particular reason why you would like to rebuild the SYSFW image?

    I believe the normal (maybe only) use case is to use the SYSFW image as is.

    There was a thread a few weeks ago that worried me a bit, because it seems to indicate that for a certain task the sysfw had to be rebuilt: https://e2e.ti.com/support/processors/f/791/p/895449/3317143

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    Guru 20395 points

    Hi Dominic-san,

    Thank you for your reply.

    The SYSFW image will be used as is. If the SYSFW image needs to be rebuilt, I will post again.

    Best regards,

    Daisuke