• State
  • Locked Locked
  • Replies 15 replies
  • Subscribers 30 subscribers
  • Views 495 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

AM2434: OTP Keywriter keyrevision 1 with Cust MPK Hash all zeroes

AM2434: SecureBoot - appimage authentication fails - firewall configuration?

Mark Orkenyi
Prodigy 60 points
Part Number: AM2434

Tool/software:

Hi,
We're trying to test out Secureboot on our own hardware and platform. I managed to do successful tests on the LP-AM243x.

I ran into an issue where the signed (hs-se) SBL boots up, however it fails to boot the application.

By debugging we found that it fails at the following part:

Sciclient_procBootGetProcessorState

Fullscreen
1
2
3
4
5
6
7
retVal = Sciclient_service(&reqParam, &respParam);
if((retVal != SystemP_SUCCESS) ||
((respParam.flags & TISCI_MSG_FLAG_ACK) != TISCI_MSG_FLAG_ACK))
{
retVal = SystemP_FAILURE;
}
return retVal;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

the return value of Sciclient_service is SystemP_SUCCESS, however the flags are not valid. 

Our best guess at the moment is the firewall configuration.

  • Could you please provide an example or guide on how and with which parameters to configure the firewalls to enable image authentication?

As a side note, we also had to enable direct access on the OSPI, so that the bootloader can read the certificate from the flash directly.This was also not mentioned anywhere in the documentation.

Thanks,

Mark

  • 0
    TI__Guru 57531 points

    Hi Mark,

    I am not able to connect the dots in your query.

    You are mentioning about the image authentication failure but then reporting the issue occurs in Sciclient_procBootGetProcessorState. These two are not related. Could you please clarify the issue?

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    My bad, I wrote the wrong function name, sorry for the confusion.
    It's the Sciclient_procBootAuthAndStart()
    Apart from that, it's the same code part.
    Attached the call stack, that might help explain where i'm standing at.

    Thanks,

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Thanks for the clarification!!

    Could you please enable and share the Sysfw logs? This should give us the reason of authentication failure.

    The Sysfw logs can be enabled as follows:

    • Change "#undef SYSFW_TRACE_ENABLE" to "#define SYSFW_TRACE_ENABLE" in source/drivers/sciclient/sciclient_default_boardcfg/am64x/sciclient_defaultBoardcfg.c.
    • Build the board configurations with: make -s -C tools/sysfw/boardcfg
    • Add another UART instance in the SBL for MAIN_UART1.
    • Build the SBL.

    If the steps are followed correctly, you should see Sysfw logs on MAIN_UART1.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Thanks, I'm using our own hardware and platform with another toolchain, so I will need some time to do this.

    Is there any way to get those sysfw logs into the terminal in CCS through the XDS110?

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Changing and rebuilding the board configuration is necessary. As for the UART, you may collect the logs from Memory Buffer also as described here

    https://software-dl.ti.com/tisci/esd/latest/4_trace/trace.html#trace-memory-buffer-location

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Unfortunately I don't have UART1 routed out, so can't access that. I enabled the SYSFW_TRACE_ENABLE macro, powered up the board, I can see the data in the memory browser, (0x44043000 for am243x if I'm right), but how to parse that?
    I found a sysfw trace parser script in the sdk, but it is not parsing that dat file.
    Could you please help to understand that log?

    Mark
    memdump.dat

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    I think you have saved the data using CCS in "TI RAW" something format. Could you instead save the data as binary?

    If in doubt, you can just simply include this function and call after the Bootloader_parseMulticoreAppimage function in the SBL's main file. This function reads the logs from the memory and dumps it on the same UART as the normal logs.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    void dump_tifs_logs()
    {
    #define TIFS_LOGS_BUFFER_ADDR 0x44043000
    #define TIFS_LOGS_BUFFER_SIZE 0x0FE0
    uint8_t* ptr = (uint8_t*)TIFS_LOGS_BUFFER_ADDR;
    DebugP_log("\r\n<<TIFS_LOGS\r\n");
    for(int32_t i = 0; i < TIFS_LOGS_BUFFER_SIZE; i++)
    {
    DebugP_log("%c", *ptr);
    ptr++;
    }
    DebugP_log("\r\nTIFS_LOGS\r\n");
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi,

    Thanks for the quick reply!
    Yes, saving it as binary worked. I've attached the logs, but based on that I guess the cause of failure is: "Issue with Hash operation"

    Unfortunately I don't understand what this means, could you please provide more context about this message?

    4442.out.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Configuring trace data version to: 0x03007
    x4F80001A
    0x4380001A: Resource Management: UDMAP_TX_CH_CFG(NavSS UDMAP TX channel configuration): UDMA device ID: 26
    0x00C20201: BasePort: Unknown Action: 0x03 MSG:0x020201
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x61800201: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x00000201
    0x61C0008D: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 141 Clock ID: 0
    0x00C20201: BasePort: Unknown Action: 0x03 MSG:0x020201
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x61800201: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x00000201
    0x61C00050: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 80 Clock ID: 0
    0x00C20200: BasePort: Unknown Action: 0x03 MSG:0x020200
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x61800200: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x00000200
    0x61C00050: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 80 Clock ID: 0
    0x62000002: Power Management: MSG_PARAM_VAL(TI-SCI message content: value): Target Value: 0x00000002
    0x62C0005B: Power Management: PD_GET(Power Domain Get): PSC ID: 0 Power domain ID: 0 PD Usage Count: 91
    0x64024000: Power Management: RETENTION_GET(Retention Get): LPSC ID: 0 Power domain ID: 9 Module Retention Count: 0
    0x6400C003: Power Management: RETENTION_GET(Retention Get): LPSC ID: 0 Power domain ID: 3 Module Retention Count: 3
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Mark Orkenyi said:
    I guess the cause of failure is: "Issue with Hash operation"

    This seems to be some internal issue with the SA2UL probably it getting timed out or something.

    Are you seeing this issue on each reset or just randomly? If it is the former then it is possible something is wrong with the way flash is configured otherwise the debugging is gonna be complex.

    On another note, why are there three PROC_AUTH_BOOT messages? And so much processing after the those messages?

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi,

    "This seems to be some internal issue with the SA2UL probably it getting timed out or something."
    I had worked with SA2UL previously and for that I had to separately configure firewalls. So my original question remains, what are the required firewall configuration for authentication to work?

    "Are you seeing this issue on each reset or just randomly? "

    It's happening every time. the application never starts.

    "On another note, why are there three PROC_AUTH_BOOT messages? And so much processing after the those messages?"

    I have no idea. We are creating the appimage with the multicoreImageGen.js out of rprc's. (script is provided in the sdk)
    This is working fine if authentication is not enabled.

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points
    Mark Orkenyi said:
    I had worked with SA2UL previously and for that I had to separately configure firewalls. So my original question remains, what are the required firewall configuration for authentication to work?

    The System Firmware owns the SA2UL and has full access to it so this should not be a firewall issue.

    Mark Orkenyi said:
    It's happening every time. the application never starts.

    I am suspecting something wrong with with flash.

    What is the size of the appimage being authenticated? And do you have any RAM large enough on the board where we could read the image from flash and then request for authentication. If it is successful, this should strongly mean something wrong with the reading from flash in DAC mode by Sysfw.

    Mark Orkenyi said:
    I have no idea. We are creating the appimage with the multicoreImageGen.js out of rprc's. (script is provided in the sdk)

    If there is only one appimage being booted then there should be only one PROC_AUTH_BOOT message in the logs. Could you once evaluate why the Bootloader_socAuthImage is being three times if there is only one appimage?

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Prashant Shivhare said:
    Could you once evaluate why the Bootloader_socAuthImage is being three times if there is only one appimage?

    We're using our own bootloader based on the sbl_ospi one, and the 3 PROC_AUTH_BOOT messages were caused by our modifications. Fixed that, but of course it's not the cause.

    Prashant Shivhare said:
    What is the size of the appimage being authenticated? And do you have any RAM large enough on the board where we could read the image from flash and then request for authentication. If it is successful, this should strongly mean something wrong with the reading from flash in DAC mode by Sysfw.

    Yes, the image can fit into PSRAM, so i'm currently trying to test that out. I will get back once I have more info.

    Thanks for the support!

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Mark Orkenyi said:
    Yes, the image can fit into PSRAM, so i'm currently trying to test that out. I will get back once I have more info.

    Sure. Let me know if any help is needed!!

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    I was able to move the image to PSRAM, then modify our bootloader to use that address for authenticating the image. It was successful this way and the image booted afterwards.

    So I assume based on your comment that it might a flash-related issue. We are using an OSPI flash.

    Do you have any idea what to check or what could be the cause of this issue and how to solve it?

    Thanks,

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Mark Orkenyi said:
    Do you have any idea what to check or what could be the cause of this issue and how to solve it?

    Are you already running the flash at its maximum configurations like PHY enables, running at maximum clock, protocol 8D-8D-8D, etc.

    Also, I hope you have DAC enabled throughtout the bootloader driver so that the SYSFW could do memory mapped reads to OSPI. This actually is a known bug and will be fixed in the next release v10.0.

    am64x, am243x: bootloader: Fix DAC mode not enabled in ospi bootloaders · TexasInstruments/mcupsdk-core@82faf8f · GitHub

    Regards,

    Prashant