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.

  • Resolved

Firmware for OMAP5's M4 pair (IPU)

Prodigy 20 points

Replies: 4

Views: 2475

Hello,

We are trying to do some deviated thing - bring up a firmware on M4 pair of OMAP5 (IPU). This firmware should be started with minimal boot time by bootloader and do its job ASAP, but still be able to serve LK running on A15 once that LK is up. Currently we are thinking about architecture for that firmware.

We have checked simple OSless firmware. We successfully booted it, even got some prints to debug UART. But it is not what we want. Running some services and communicate with LK on A15 on OSless firmware looks like reinventing the wheel.

We are evaluating SYS/BIOS for the task. It looks interesting for our tast, but there are some unclear points. Could we get some clarifications on following:

  1. As we understand, pure Sys/Bios is not really made for OMAP's IPU. All SDKs and drivers advertised for Sys/Bios are not suitable for OMAP devices.
  2. As I understand, there is a one product based on Sys/Bios and made for OMAP's IPU - Ducati. For the Ducati case, Sys/Bios was feat by RPMsg (not considering ISP, camera drivers, OMX). RPMsg's intention is communicating with LK on A15.
  3. Is there any document what describes how to boot Sys/Bios? Is there a ready example on how to boot Sys/Bios from f.e. u-boot?
  4. Ducati (even Sys/Bios-RPMsg) build product is elf. Parsing elf in bootloader is not nice idea considering boot time restrictions. Is it possible getting Sys/Bios-RPMsg binary products?
  5. Is there available Sys/Bios-RPMsg implementations with support of SMP on OMAP's IPU?
Sincerely,
Andrii Anisov.
  • Lots here, I'll try to answer as best I can.

    First, what Linux kernel are you using?  I have some experience with the GLSDK releases on the OMAP5 uEVM, and the rest of my replies assume that environment (though others may work):
        http://processors.wiki.ti.com/index.php/OMAP5_GLSDK_Software_Developers_Guide

    The GLSDK releases leverage IPC 3.x for communication between the Linux-running A15 and the IPU.  IPC 3.x, on Linux, leverages the in-kernel remoteproc (for loading) and rpmsg (for communicating) drivers, and exposes APIs to user space.

    I'll try to answer your questions one by one, hopefully you can piece together my replies into what you're "really" looking for.  :)

    Andrii Anisov
    1. As we understand, pure Sys/Bios is not really made for OMAP's IPU. All SDKs and drivers advertised for Sys/Bios are not suitable for OMAP devices.

    Not true.  The GLSDK uses SYS/BIOS on OMAP5's IPU (as well as the DSP).  As the IPU on OMAP5 is really a dual core M4, SYS/BIOS is configured for SMP (Symmetric Multi Processing) mode, utilizing both cores for scheduling tasks.

    Andrii Anisov
    2. As I understand, there is a one product based on Sys/Bios and made for OMAP's IPU - Ducati. For the Ducati case, Sys/Bios was feat by RPMsg (not considering ISP, camera drivers, OMX). RPMsg's intention is communicating with LK on A15.

    As previously mentioned, IPC 3.x builds on Linux's rpmsg driver for communication.

    IPC includes an API - MessageQ - which is architected to support different "transports" underneath to accommodate many different hardware and software architectures, as well as use cases.  One recent addition in IPC 3.x is an rpmsg-compatible BIOS-side transport, very creatively named TransportRpmsg.  ;)  This transport speaks the same protocol as the Linux-side rpmsg driver and enables MessageQ-based communication.

    So I think what you're saying is roughly true.

    Andrii Anisov
    3. Is there any document what describes how to boot Sys/Bios? Is there a ready example on how to boot Sys/Bios from f.e. u-boot?

    Here it gets really interesting, and gets to the heart of your "real" question.  The GLSDK, and all IPC 3.x Linux-based support to date, builds upon a host/slave model.  That is, the A15 host loads the IPU slave, sets up the rpmsg-required buffers needed for communication, and takes the slave out of reset.

    What you're asking for a feature I've been calling "Late Attach".  It's a requirement that's come from a few users, but that we haven't implemented yet.  It's on the list, and we're just starting to look at it, but nothing to show just yet.  In this Late Attach model, the A15 and IPU cores run as 'peers', handshaking after they've both booted, rather than as 'host/slave'.  In this peer model, some features (power management, crash recovery, etc) may not be feasible and may need to be disabled.

    If you're curious and motivated, you can contact your local TI FAE and we can discuss providing early access to some of our prototypes.  As you suggest, it likely requires carving out resources (e.g. memory, clocks) from Linux, disabling various load/reset code in remoteproc drivers, building the load/reset support into uboot, and adding the ability for the A15/IPU to Late Attach to each other and run as 'peers' rather than a 'host/slave'.

    Andrii Anisov
    4. Ducati (even Sys/Bios-RPMsg) build product is elf. Parsing elf in bootloader is not nice idea considering boot time restrictions. Is it possible getting Sys/Bios-RPMsg binary products?

    Not as far as I know.  Since your loader will responsible for loading the slave, you can use whatever format you want to store the image, but the TI toolchain will generate ELF files.  If you want to create your own elf-to-proprietary-format converter, and enable your loader to load your proprietary format, I think there are elf parsers generally available.

    Andrii Anisov
    5. Is there available Sys/Bios-RPMsg implementations with support of SMP on OMAP's IPU?

    Yep, I think I answered that already.  SYS/BIOS supports SMP for OMAP5's IPU, and the IPC 3.x product supports OMAP5 and the SMP-BIOS-running IPU.

    Finally, because these software forums are generally split by OS, and you're focused on a heterogeneous, multi-OS system, if you have new followup questions, you might consider which forum gets the "more correct" eyeballs on it.  If it's a IPU-side BIOS question, this the right forum.  If it's more of a Linux question, you might have better luck posting to the Linux forum.

    Chris

  • In reply to Chris Ring:

    Chris,

    Thank you for detailed explanation on the topic, it was really useful.

    Due to several reasons we have changed our arch and will not do M4 firmware.

  • We're evaluating on using the M4 pair aswell, can you tell us how did you "flash" the firmware on the M4 and how did you boot them?

    Best Regards
    Roosembert Palacios
  • In reply to Roosemberth Palacios:

    Hi Roosembert,

    If you haven't already, can you please open a new thread for the issue you are having?

    Thanks

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.