Firmware for OMAP5's M4 pair (IPU)

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 said:

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 said:

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 said:

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 said:

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 said:

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