• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 181 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.

AM625: OSPI Controller Powers Down If Boot Priority Is SD on TI AM625x

Hossein Farkhonde
Prodigy 60 points

Part Number: AM625

Tool/software:

Hello,

We have a single‑board computer based on the TI AM625x processor. This processor’s OSPI port is connected to an encrypted SPI‑NOR flash using proprietary commands, so it cannot be accessed in the normal way. (For boot it runs the standard commands, then locks itself, and the system normally boots from that flash.)

It’s worth noting that the flash’s proprietary commands are longer than the STIG command set, so we cannot use STIG to control this device. To be able to program the flash, after a lengthy effort we reverse‑engineered the necessary commands and addresses from the MCU + SDK and now drive the flash chip via its registers in quad mode at full speed.

However, I’m now encountering an issue with the Cadence OSPI registers. If the system’s primary boot device is OSPI, everything works perfectly. But if the boot priority is set to SD (so the CPU doesn’t even attempt to boot from OSPI), the Cadence controller stops responding to commands—it appears to power down.

This functionality is critical for field recovery of boards that, for example, have lost their flash contents due to exposure to a strong magnetic field or other customer‑site events. Is there any register write or command sequence to re‑enable (power up) the OSPI controller via its registers?

For reference, we are running TI’s Linux kernel ti‑linux‑kernel‑10.01.10 (Linux 6.6) with the BeaglePlay package, and our programming utility runs in userspace via an mmap of /dev/mem.

Thank you for any guidance.

  • 0
    TI__Guru 70822 points

    Hi Hossein,

    Hossein Farkhonde said:
    However, I’m now encountering an issue with the Cadence OSPI registers. If the system’s primary boot device is OSPI, everything works perfectly. But if the boot priority is set to SD (so the CPU doesn’t even attempt to boot from OSPI), the Cadence controller stops responding to commands—it appears to power down.

    Usually peripheral modules are initialized by their respective Kernel drivers which in turn will leaverage and communicate with the system's Device Manager (DM) firmware to configure peripheral operating status, clocks, etc. I suppose you no longer use the OSPI Kernel driver in case of SD card boot at all, hence some of the required low-level initialization may not happen?

    Try using the `k3conf` tool as shown below to check and manipulate low-level OSPI peripheral enable and clock status. You can also compare working vs, non-working scenarios and see if there are differences, and then try to use the `k3conf` tool to manipulate the peripheral (it communicates to the Device Manager firmware behind the scenes, similarly like a proper OSPI kernel driver woud by way of the Kernel's clock/power/reset frameworks).

    Lastly, if you want to do things manually, you will probably also need to consider about pinmux if the Kernel driver isn't used.

    Regards, Andreas