Uses for the Cortex-M4 cores on the OMAP5?

[Orbstheorem]

I do not know if this is relevant because I don't understand well the OMAP architecture and it sounds weird to have different OSes in different CPUs on one computer, but just in case, if it wasn't mentioned, I saw a news piece on Frosted OS for Cortex-M4

Seems like is worth to take a look at!

 

[Agricola]

Is this Frosted OS Unix compatible? Can one run Bash and Vim on it? What's better about it than µClinux?
These links are so hard to read if you're not a developer and if your native language isn't English...

 

[pyrat]

Is this Frosted OS Unix compatible? Can one run Bash and Vim on it? What's better about it than µClinux?

I don't know. They say the Frosted OS kernel is POSIX. That's roughly Unix, yes. But I doubt they have all the Unix userspace. You can probably port or compile bash and vim for Frosted OS, but I don't know if people already has.
Also it works on other systems, not on the Pyra. And before you make it work on the Pyra you would have to think on how to let it access each device without disturbing linux on the A15.

So don't get too excited. Using the M4s requires work. Frosted OS may or may not be a place to take small pieces of the work from.

 

[Orbstheorem]

The required work to be done is similar to porting Linux to a new Architecture. Not from the routines and architecture instructions point of view, but from the platform bringup procedure.

We have to implement a platform for linux (peripheral setup, mmu configuration, processor initialization, irq vector tables) which is very diferent from TI's mainline. Mostly for taking into account that the Linux running on the A15 has already setup, configured and 'reserved' most of the devices. Even the load process will be different as is probably a better idea to manually load the kernel than creating an SPL and porting uBoot.

Fortunally (à priori) most of the work should be done in setup_arch mem_init init_IRQ and time_init functions so they will cooperate with the A15's kernel.

There's still an interesting challenge which is desinging an efficient IPC protocol for both kernels to talk. TI has its own IPC protocol but I'm not so sure we want to go that way. Something simplier should work. In principle, we need first a serial console and an (fake) ethernet connection so we can use nfs for the A7's rootfs.

EDIT: cf

 

[zmatt]

AFAIK it's made for exactly that: video and sound en- and decoding.

For me it would be use enough if all the audio/video codecs would be handled via DSP and M4.

Actually the subsystem for that is IVA-HD. Unlike its precedessor IVA2 on the omap3 it doesn't embed a C64x+ DSP. Instead there's a separate C64x-derivative "Tesla" DSP, which seems to be focussed on audio since it has a direct connection to the Audio Backend (ABE) subsystem. The main intended purpose of the M4 subsystem is looking after the camera subsystem (ISS) and real-time management of video streams in general.

I'm idly wondering if one of the M4s could be used to keep the DSP fed with data. Is there a need to make that easier to schedule?

Ehh, what?

These are most useful when you need to sample inputs very fast, like an oscilloscope or logic analyser does,

I'd consider using timer-triggered DMA for that if nothing better is available.

How about a hypervisor boot environment on the m4's that could then boot different VMs running different kernels for the a15 cores?

LOL, how about a hypervisor boot environment on the Cortex-A15 since it has actual hardware virtualization support? (which is separate and distinct from TrustZone btw)

If it's possible to run a self written programm on the M4s (I assume without an operating system), while running the Pyra with it's standard operating system, will it be possible to just write something on to the screen? (So simply overtake the screen, and give it back afterwards)

Yes, although no "overtaking" would be involved... you could just scribble onto framebuffers if you know where they are located. A nicer solution would be to allocate a private framebuffer for it and stick it on an overlay, or have JonnyH render it on a rotating cube for you

Developing software for both cores simultaneously is a bit tricky since they share the same address space (apart from the Private Peripheral Bus) so it behaves mostly like two threads rather than like two processes.

I'm pretty sure that's how they're intended. The main CPU has some kind of debug system allowing you to write code to the M4's

It has no access to the debug functionality of those cores, you'd need JTAG for that. It does however have direct access to the local RAM and can set up the MMUs.

For starters we'd need the appropriate software for writing code to the M4's. There is probably some software development kit for this, and/or some kernel driver is needed.

You can just use /dev/mem, and the procedure is quite simple: release subsystem from reset, write code to subsystem RAM, optionally configure the MMUs, release core(s) from reset.

 

[txus]

Actually the subsystem for that is IVA-HD. Unlike its precedessor IVA2 on the omap3 it doesn't embed a C64x+ DSP. Instead there's a separate C64x-derivative "Tesla" DSP, which seems to be focussed on audio since it has a direct connection to the Audio Backend (ABE) subsystem. The main intended purpose of the M4 subsystem is looking after the camera subsystem (ISS) and real-time management of video streams in general.


[...]

Thank you for the quite informative post! You seem to know your way around the OMAP, M4s and IVA-HD... Do you know if getting gst-ducati (or gst-openmax) from https://gitlab.com/groups/gstreamer-omap to work is a feasible possibility? The most problematic item in there seems to be libdce, but I may be wrong. And I think ducati was related to OMAP4, but the difference as far as I could unterstand is not that big (M3s instead of M4s, but I think the changes for that were already in the ducati FreeRTOS). HW accelerated video decoding would actually be one of the most useful and seemingly supported use cases for something like the Pyra!

 

[zmatt]

Thank you for the quite informative post! You seem to know your way around the OMAP, M4s and IVA-HD... Do you know if getting gst-ducati (or gst-openmax) from https://gitlab.com/groups/gstreamer-omap to work is a feasible possibility?

on TI SoCs I know my way around the hardware. Not so much the software stacks I'm afraid.

And I think ducati was related to OMAP4

Ducati is the codename for the dual-M3 subsystem present on the omap4 and dm81xx; the dual-M4 successor on the omap5 is called Benelli. As far as I know there's no functional difference other than the M3->M4 substitution so it's possible the same binaries work unchanged.

 

[txus]

Thanks a lot, zmatt!