• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 4 answers
  • Subscribers 31 subscribers
  • Views 939 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.

AM2434: migration guide for apps image from GP to HS-FS

Sung-IL
Mastermind 30950 points
Part Number: AM2434
Other Parts Discussed in Thread: AM2432

Dear Champs,

My customer has a trouble to bring-up HS-FS device on their board which worked well with GP device, and their current MCU+SDK v8.1.

To bring-up HSFS device, they realized they should modify their SW for HSFS device and they are now referring to below.

https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/HSFS_MIGRATION_GUIDE.html 

They confused and have no idea what should be done to run their application image.

They assumed there is nothing to do in their application code by referring below except signing.

NON-SBL Example Appimage Build

In case of example applications other than SBL (hello_world, dpl_demo etc...) the same application image file (*.appimage) can be booted by SBL on HS-FS / GP device, nothing special to be done for HS-FS since there is no extra signing needed.

Note: Appimages would eventually need signing by x509Certificate in HS-FS. This change is yet to be implemented. Once this is done, the appimages would have different extensions for HS-FS image. *.appimage would now become *.appimage.hs_fs

But, when they try to build hello world example, they found there were 2 images were generated as below, and they assumed hello_world.release.appimage.hs_fs is a signed image of hello_world.release.appimage.

- hello_world.release.appimage

- hello_world.release.appimage.hs_fs

So, they tried to sign hello_world.release.appimage using below scripted as explained in UG.

$ python3 appimage_x509_cert_gen.py --bin /path/to/hello_world.release.appimage --authtype 1 --key /path/to/rom_degenerateKey.pem --output /path/to/hello_world.release.appimage.hs_fs.signed

When they compared this generated 'hello_world.release.appimage.hs_fs.signed' and 'hello_world.release.appimage.hs_fs', they expected both images should be same, but it was not.

And also, hello_world.release.appimage.hs_fs.signed was not worked.

So, they are curious if it is OK just to sign their application image running on GP device and what is exact procedure to run their legacy application code on HSFS device.

Could you please clarify how they can migrate their application code for GP device to HSFS device?

Thanks and Best Regards,

SI.

  • 0
    TI__Mastermind 26145 points

    Hi ,

    Sung-IL said:
    When they compared this generated 'hello_world.release.appimage.hs_fs.signed' and 'hello_world.release.appimage.hs_fs', they expected both images should be same, but it was not.

    No this is not the correct understanding. The image will still be same but it will be appended by an x509 certificate which will have the SHA value for the *.appimage which was provided as an input. During the boot the SBL shall verify the Hash value of the image (via SYSFW) and then will boot the image. This is how the boot image is authenticated in HS-FS devices. The key used in the certificate is ROM Degenerate key which is valid for all the HS-FS devices.

    Sung-IL said:
    Could you please clarify how they can migrate their application code for GP device to HSFS device?

    The step that was used is the correct way to migrate from GP device to HS-FS devices.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    TI__Mastermind 30950 points

    Aakash,

    Thanks for your immediate response.

    They succeed to run SBL now, and have no idea how they can migrate application image running on GP device to HSFS device.

    When they signed their previous application image built in SDKv8.1.0, they found it was not worked in HSFS device. Of course, they signed their application image using the tool of SDKv8.5.0. The application image was built in SDKv8.1.0.

    Should they built their application image using SDKv8.5.0?

    And could you please check if below memory map used in their application can be worked on HSFS device?

    ~~~~~~~~~

    MEMORY

    {

        R5F_VECS  : ORIGIN = 0x00000000 , LENGTH = 0x00000040

        R5F_TCMA  : ORIGIN = 0x00000040 , LENGTH = 0x00007FC0

        R5F_TCMB0 : ORIGIN = 0x41010000 , LENGTH = 0x00008000

     

        /* when using multi-core application's i.e more than one R5F/M4F active, make sure

         * this memory does not overlap with other R5F's

         * last 16KB is reserved DMSC

         * MSRAM_BOOT is used by SBL, when SBL handover done (application start)

         * it's free to use. Use this area for SYSTEM malloc area (TLSF).

         */

        MSRAM_BOOT : ORIGIN = 0x70000000 , LENGTH = 0x080000

        MSRAM      : ORIGIN = end(MSRAM_BOOT) , LENGTH = (0x701E0000 - end(MSRAM_BOOT))//0x190000-0x15000

     

            MSRAM_SBL  : ORIGIN = 0x701FC000 , LENGTH = 0x004000

     

    //     FLASH     : ORIGIN = 0x60100000 , LENGTH = 0x80000 //ysh

    //     FLASH2     : ORIGIN = 0x60180000 , LENGTH = 0x80000        //icj

        /*

         * Found hidden SRAM, M4F IRAM(192KB) and DRAM(64KB) also accessible from R5F

         * Tested with networking memalloc pool, performace difference is ignorable.

        * We don't use M4F cpu.

         */

        M4F_IRAM  : ORIGIN = 0x05000000 , LENGTH = 0x00030000

        M4F_DRAM  : ORIGIN = 0x05040000 , LENGTH = 0x00010000

     

        MCAN0_RAM  : ORIGIN = 0x20708000 , LENGTH = 0x00008000 /* 32KB */

     

        ICSSG0_RAM1  : ORIGIN = 0x30010000 , LENGTH = 0x00010000 /* 64KB */

    }

     

    ~~~~~~~~~~

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 26145 points

    Hi SI,

    By my analysis, migration from 08.01 to 08.05 would need following changes that might be needed.

    1. Application does not need changes other than conversion to .app_image.hs_fs

    2. You need to change the SYSFW to the one that is released with 08.05 which is encrypted and signed with TI keys. You also need to use the certificate with this SYSFW.

    3. SDK does not support Legacy Boot Mode hence, transition to be done to combined boot flow. By this the SYSFW certificate and Board Config will be part of the SBL Certificate.

    4. SBL signing is also optional, will be part of certificate.

    5. If you change the SYSFW to 08.05 version, the SCICLIENT implementations for PM, RM also changes, hence you should upgrade the SBL, Examples everything.

    Hence, the best option for the customer would be to migrate to latest version.

    Hope it helps.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    TI__Mastermind 30950 points

    Aakash,

    They succeeded to boot and run SBL on HSFS device with SYSFW on 08.05. And, there is no issue to run hello_world example. So, I think there is no issue to run the board and their boot loader, but pls let me know if you have any other opinion.

    The only remained issue in their migration is their application is not worked even when they signed their application image to convert to .app_image.hs_fs.

    Do you mean they should compile their application again in SDKv8.5.0? Is there any difference in compiler and linker between SDKv8.1.0 and SDKv8.5.0?

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 30950 points

    Hi Aakash,

    It looked SCICLIENT is an issue.

    Could you please provide guide how they can apply new SCILIENT(of SDKv8.5.0) on their application built in SDKv8.1 for HSFS device?

    They updated all tool chains to SDKv8.5.0 and now using TI ARM CLANG 2.1.2LTS for ARM compiler.

    When they compiled it in SDKv8.1.0 with TI ARM CLANG 2.1.2LTS and signing it for HSFS device using script of SDKv8.5.0, they found it would be halt after running sometimes as below.

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 26145 points

    Hi ,

    I have already mentioned. You are trying to play with a lot of variables while moving from GP(of 08.01) to HS-FS which is something we won't be able to support.

    The most optimum solution would be to ask your customer to migrate to 08.05 release for all the SW blocks. I have stated my reason on the previous thread.

    1. Application does not need changes other than conversion to .app_image.hs_fs

    2. You need to change the SYSFW to the one that is released with 08.05 which is encrypted and signed with TI keys. You also need to use the certificate with this SYSFW.

    3. SDK does not support Legacy Boot Mode hence, transition to be done to combined boot flow. By this the SYSFW certificate and Board Config will be part of the SBL Certificate.

    4. SBL signing is also optional, will be part of certificate.

    5. If you change the SYSFW to 08.05 version, the SCICLIENT implementations for PM, RM also changes, hence you should upgrade the SBL, Examples everything to 08.05.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    TI__Mastermind 30950 points

    Hi Aakash,

    Thanks for your comments. 

    Although I suggested to move to SDKv8.5, customer found something in their debug.

    Their application image was built in SDKv8.1, and

    1. they found it worked well with SBL_NULL and downloading 'application image' through JTAG.

    2. but, their application image was not worked with SBL_OSPI.

    Is there any issue in signing SW to work with image generated in SDKv8.1?

    As I mentioned, they are using latest tool chain and SBL of SDKv8.5 now. 

    And also, they found

    3. they tried to run small application image with SBL_OSPI, and it looks it works.

    Is there any limitation in memory size in HS-FS device when comparing with GP device?

    And, how about xip image?

    Should they sign XIP application image for HS-FS device? 

    they signed xip image also, but it does not worked either.

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 30950 points

    Hi Aakash,

    Could you please let me know your opinion on this issue?

    And also, in HSFS RTM device(AM2432BKEGHIALXR), they could not access to internal memory of M4F SS in AM2432.

    Do you have any idea what is the issue?

    When they updated to the latest version of SCICLIENT  and to the latest SDK v8.5.0,24, do you expect all these errors can be fixed?

    Thanks and Best Regards,

    SI.

  • 0 in reply to Sung-IL
    TI__Mastermind 26145 points

    Hi Sung-IL,

    Is the user using SBL-NULL or DEV Boot mode ?

    Sung-IL said:
    in HSFS RTM device(AM2432BKEGHIALXR), they could not access to internal memory of M4F SS in AM2432.

    Is the core enabled ? Can the user connect to the core via debugger ?

    Sung-IL said:
    do you expect all these errors can be fixed?

    We have a functional SDK release of 08.05. These are irregular issues we have faced when you have different versions of SDK. I am sure a lot of problems will be automatically handled.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    TI__Mastermind 30950 points

    Hi Aakash,

    Thanks for the immediate response.

    Aakash Kedia said:
    Is the user using SBL-NULL or DEV Boot mode ?

    They are using SBL-NULL.

    Aakash Kedia said:
    Is the core enabled ? Can the user connect to the core via debugger ?

    I will check, but I think the core is enabled as they have used internal memory of M4F SS in XAM2434(ES sample).

    Thanks and Best Regards,

    SI.