• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 616 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.

MCU-PLUS-SDK-AM243X: OSPI Multi-Partition-Bootloader example not working

Simon Schwab
Prodigy 30 points
Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: TMDS243EVM, SYSCONFIG

Hello TI Team,

I am currently facing a problem with the OSPI multi partition bootloader running into a data_abort exception. I debugged the exception and understood the root cause but cannot get my head around why I am facing the exception in the first place.

First off some details of my environment:

I am running my code on a AM2434B SoC in the HS_FS variant on the TMDS243EVM.
The bootloader code I am using is based off of the sbl_ospi_multi_partition example project from the MCU+ SDK 9.1.0.41. No changes have been made to the SysCfg. A spinlock has been added right before the first call to Bootloader_parseMultiCoreAppImage() to attach the debugger.
All signed appimages and the bootloader itself have been written to the flash at their respective offsets configured in SysCfg (bootloader at offset 0x0) and verified that they've been written.

Issue description:

The exception is thrown in the function Bootloader_verifyMulticoreImage() as the called function Bootloader_getMsgLen() tries to dereference a pointer (x509_cert_ptr) in the FSS0_DAT_REG1 memory region which fails. It appears that this function wants to access the FLASH as a memory mapped peripheral. All other functions called during verification and actual loading of the appimage really read from the flash via OSPI.

Questions:

1. The example does not configure DAC for OSPI. How can memory mapped access work without configurung the OSPI DAC?
2. Are there additional potentially undocumented steps to get the example to work?

  • 0
    TI__Guru 50761 points

    Hi Simon,

    I have taken note of the issue. Please allow me a day to look through the query and get back to you.

    Thanks!

  • 0 in reply to Prashant Shivhare
    TI__Guru 50761 points

    Hi Simon,

    The issue is reproducible with the default images. And it looks like the issue is due to the PHY not enabled in the SBL's sysconfig. If I enable the PHY as shown below, the SBL boots fine.

    Attached are the successful logs

    Starting OSPI Multi-Partition Bootloader ...

DMSC Firmware Version 9.1.6--v09.01.06 (Kool Koala)
DMSC Firmware revision 0x9
DMSC ABI revision 3.1

INFO: Bootloader_runCpu:155: CPU r5f1-0  is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:155: CPU r5f1-1 is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:155: CPU m4f0-0 is initialized to 400000000 Hz !!!
INFO: Bootloader_loadSelfCpu:207: CPU r5f0-0 is initialized to 800000000 Hz !!!
INFO: Bootloader_loadSelfCpu:207: CPU r5f0-1 is initialized to 800000000 Hz !!!
[IPC NOTIFY ECHO] Message exchange started by main core !!!
[m4f0-0]     0.092018s : [IPC NOTIFY ECHO] Remote Core waiting for messages from main core ... !!!
[r5f0-1]     0.002099s : [IPC NOTIFY ECHO] Remote Core waiting for messages from main core ... !!!
[r5f0-1]     2.283646s : [IPC NOTIFY ECHO] Remote core has echoed all messages !!!
[r5f1-0]     0.157146s : [IPC NOTIFY ECHO] Remote Core waiting for messages from main core ... !!!
[r5f1-0]     2.438682s : [IPC NOTIFY ECHO] Remote core has echoed all messages !!!
[r5f1-1]     0.126153s : [IPC NOTIFY ECHO] Remote Core waiting for messages from main core ... !!!
[r5f1-1]     2.408399s : [IPC NOTIFY ECHO] Remote core has echoed all messages !!!
[IPC NOTIFY ECHO] All echoed messages received by main core from 4 remote cores !!!
[IPC NOTIFY ECHO] Messages sent to each core = 1000000
[IPC NOTIFY ECHO] Number of remote cores = 4
All tests have passed!!
[m4f0-0]     3.551528s : [IPC NOTIFY ECHO] Remote core has echoed all messages !!!

    Can you please try the same and let me know if it works for you as well.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 30 points

    Hi Prashant,

    that indeed fixed my issue. However, I am wondering why the generic SDK bootloader code breaks without having the OSPI with PHY mode. Shouldn't it be aware of possibly PHY mode not being enabled? That seems like quite an oversight to me.

    Greetings,

    Simon

  • 0 in reply to Simon Schwab
    TI__Guru 50761 points

    Hi Simon,

    Simon Schwab said:
    Shouldn't it be aware of possibly PHY mode not being enabled?

    You are absolutely right. We are mostly looking at some bug in v9.1.

    I have just tried the v9.0 and apparently it works without any changes. So, probably something changed in the flash driver that causes the issue in v9.1.

    I will create a bug ticket internally and update here if there is any progress.

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 30 points

    Hi Prashant,

    alright thanks for keeping me posted. I'll be awaiting your answer.

  • +1 in reply to Simon Schwab
    TI__Guru 50761 points

    Hi Simon,

    I have bisected the Git commits of the MCU+ SDK repo and found the first commit that results in the issue. The commit is:

    am243x/am64x: ospi: make read/write fxns honor DAC · TexasInstruments/mcupsdk-core@3183735 · GitHub

    This commit is actually meant to bring the design choice that the DAC mode is enabled on demand and disabled immediately. This explains why there is a data abort in `Bootloader_getMsgLen()` since it tries to access the OSPI in DAC mode without first enabling the DAC.

    Now, why simply enabling the PHY resolves the issue when the PHY and DAC are two unrelated aspects is because the OSPI driver, when PHY is enabled in Sysconfig, reads the PHY tuning data using `OSPI_phyReadAttackVector()` as shown below

    As we can see, this enables the DAC mode for reading the PHY but does not disable it (bug as per the design). This means any further direct access to the OSPI works as required by the `Bootloader_getMsgLen()`.

    So, we are dealing with two bugs here as per the design choice:

    1) Disable the DAC mode after use in `OSPI_phyReadAttackVector()`.

    2) Enable and disable the DAC mode as needed in `Bootloader_verifyMulticoreImage()`.

    I will update the bug tickets with the findings and hope that the fix makes it to the v9.2 release scheduled around last week of March.

    Regards,

    Prashant