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.

AM2634: HSMRT memory region

Part Number: AM2634

Dear Champs,

My customer found HSMRT memory region in sbl_qspi example of MCU+SDK v8.5.0.24 as below, and want to know how this memory region can be moved or if this region can be overlayed after loading.

1. Could you please let me know how MSRAM_HSMRT memory region can be moved to other region?

2. Could you please let me know if this memory region can be overlayed with other memory after downloading FW to HSM internal memory?

Thanks and Best Regards,

SI.

  • Hi ,

    1. Could you please let me know how MSRAM_HSMRT memory region can be moved to other region?

    This is just an example implementation option. Although you cannot put the HSMRT Image in the Flash. It is okay to put the image in sharable area of the chip.

    2. Could you please let me know if this memory region can be overlayed with other memory after downloading FW to HSM internal memory?

    Yes, you can reuse the memory utilized by HSMRT after the firmware download is complete.

    BR,
    Aakash

  • Hi Aakash,

    1. Could you please let me know how MSRAM_HSMRT memory region can be moved to other region?

    This is just an example implementation option. Although you cannot put the HSMRT Image in the Flash. It is okay to put the image in sharable area of the chip.

    Do you mean the memory region can be shared by HSM and R5 core?

    Is all internal memory region(L2OCRAM) sharable area?

    My customer tried to move HSM runtime to other L2OCRAM region, but there was no response with this MSRAM_HSMRT moving in sbl_qspi example.

    Thanks and Best Regards,

    SI.

  • HI Ryan

    Please expect a delay in response as we are still working on this. The expert is Out of Office and will get back to you shortly.

    Regards

    Sri Vidya

  • Hi ,

    Do you mean the memory region can be shared by HSM and R5 core?

    The MPU region configuration should be set as "Sharable and non-Cachable"

    Is all internal memory region(L2OCRAM) sharable area?

    That can be configured and checked via syscfg of SBL.

    My customer tried to move HSM runtime to other L2OCRAM region, but there was no response with this MSRAM_HSMRT moving in sbl_qspi example.

    Can you share more information on this ? or Can you share the updated linker file ?

    BR,
    Aakash

  • Hi, 

    I am the one who is experiencing this issue.

    I tried setting everything from 0x70000000 to 2MB to non-cached in the syscfg file, but the problem still occurs.
    Also, in the QSPI_SBL example, there was no setting to non-cached.

    All I changed was to change the start address of "MSRAM_HSMRT" to 0x70040000 as shown below.
    MSRAM_HSMRT: ORIGIN = 0x70040000 , LENGTH = 0x00040000

    ( recommended uploading the file, but uploading was not allowed due to its policy, so we share the modified part of the .cmd file as above.)

    Is there anything else I should check in this regard?

    Best Regards

    Jiung Choi

  • Hi ,

    Can you send me the snippet of passing scenario in your case ? It should be like this -

    The LoadHsmRtFw time should be approximately 6ms. Also can you send the snippet of the parsed UART Boot Log print ? Use the following FAQ for the same.

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1170785/faq-mcu-plus-sdk-am243x-how-to-identify-if-the-device-is-gp-device-or-hs-device

    Best Regards,
    Aakash

  • Hi, 

    First of all, if I use the SBL example without changing it, the log will be output as shown below. (but LoadHsmRtFw is 69us)

    And when I change the MSRAM_HSMRT area from 0x70027800 to 0x70040000, no log is output. (I haven't modified anything else in the example.)

    And I tried the method in the link, but an error called odd-length occurs as shown below.

    And I got the data like below from UART BOOT and used it.

    000002020100000000000100414d323633580000000000000400cdab00000100010000000000000000000000000000000000000050d39632c39b4506e692c404625dcb0762b9770ae7166e7f1fb537404b7beceba254256c884d098cdb906573b92ee15169f9493be861bef6e4b1c8ffe67edb9c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a858b217d4ed374104020f3ed82d735602fb9d259a97b1826967219658fa186133542c8e6c75da6dc6642e69ae11a7278526aabe02cf712953b0379f0820d2aaC

    Please let me know if there is anything else to check.

    Best Regards

    Jiung Choi

  • Hi Jiung Choi,

    The HSM-Rt Firmware time for installation in your case is 6us. It seems like your firmware is not installed at all. This is because your device version is not the same as the expected version.

    This is the print of your device UID. You should not consider the last 'C' as that is a XMODEM print.

    The ROM version should be the latest version which is 2 instead of 1 as translated from the log. Please request a latest device from the sales rep which has latest ROM version so the HSM-Rt Firmware installation is supported.

    Best Regards,
    Aakash

  • Hi, 

    I understand that the ROM version of the AM2634 I am currently using needs to be changed.

    If HSM-Rt is not installed I guess it shouldn't matter if I change the realm.

    However, if I change the location of HSM-Rt in the Bootloader currently being developed based on the QSPI SBL example, it becomes a brick like this issue.

    If HSM-Rt is not installed, is "Bootloader_socLoadHsmRtFw" function also meaningless? (If so, I'd like to remove it and proceed with development.)

    Best Regards

    Jiung Choi

  • Hi, 

    After replacing the MCU, removing the last 'C' of the meta data and checking the results are as follows. (ROMVer: 0x2)

    Even if I change the HSM-Rt to the same in the QSPI SBL example using that MCU, it still bricks.

    Additionally, this is the UART log if I didn't change the MSRAM_HSMRT location.

    Best Regards

    Jiung Choi

  • Hi ,

    If you wish to remove the function Bootloader_socLoadHsmRtFw then simply comment this function in main() and also comment out the array in the very start of the main file.

    This should work for you.

    Best Regards,
    Aakash

  • Hi ,

    The PG Version as 3 and ROM version as 2 is the correct device variant. Also the 9ms time gives an hint that the time taken by ROM is a real time to sample/install the image.

    I tried a simple change with linker file like this works for me.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/5518.linker.cmd

    Does this not work for you ?

    Best Regards,
    Aakash

  • Hi, 

    Thanks for checking the MCU version.

    But, The linker.cmd file you shared is identical to what I am trying to do. (Only the MSRAM_HSMRT area is changed)

    Also, after applying the linker.cmd you shared, booting in QPSI MODE still bricks.

     - If MSRAM_HSMRT is in the 0x70027800 area, it works normally

     - Bricked if MSRAM_HSMRT is in area 0x70027800

    Best Regards

    Jiung Choi

  • Hi ,

    Let's schedule a call to debug the same. Please request  to send an invite for the same.

    Best Regards,
    Aakash

  • Hi ,

    As per our discussion on the call, due to the change in the linker file the SBL size was increased to 0x46371 and you flashing an application image at 0x40000 which was corrupting the SBL tiimage(x509 Certificate + SBL Binary). This caused the RBL to not find the valid signature and then booted the device in UART boot mode to recover the device.

    Hope this helps.

    Best Regards,
    Aakash