Uses for the Cortex-M4 cores on the OMAP5?


That still doesn't mean you can use the M4 as the control program in a hypervisor setup. The M4 won't have trustzone extensions as far as I know, so you'd need to do everything in software. The M4 can't set traps on the A15 cores, so can't intercept calls the hardware and replace them with virtualised implementations, to the best of my knowledge.

The OMAP5 SoC might be similar enough to the one used by that project, but I doubt it's doing any real work on the M4 cores, so it doesn't help us getting the M4 cores working for us.
 
That doesn't say anything about actually making use of the M4 cores though as far as I can see, it just lists them in the specs of the system it's targeting.

-Neelix

EDIT: Ninja'd by levi (one of these days I'll learn to check that there isn't another page to the thread before replying) :oops:
 
The M4s are co-processors, not fully featured CPU cores. There are several restrictions on what you may do while running on them, which simply makes a hypervisor not a viable option.
 
I'm quite a noob in this section and I don't understand, if I understand things right here. I'was fiddling around with an arduino at home (programming it with Eclipse CDT). So as much I understand, I could use the both M4s as a prototyping board like the arduino? Will it be possible, to write simple C programms, compile them and run them on the M4s, like running code on the Arduino board? This would be awesome!

Do I need an operating system like linux running on the M4's, or can I just run a loop of code. (This brings up the question for me: Does an operating system run on an Arduino Mega2560, when I flash it with a - let's say - LED-Blinky Programm?)

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)

Can anybody help me out here? I'm trying to get my head around over all these complex processor stuff...
Any push in the right direction would help me! :)
 
Letalis Sonus said:
The M4s are co-processors, not fully featured CPU cores. There are several restrictions on what you may do while running on them, which simply makes a hypervisor not a viable option.
Click to expand...
So the M4's on the OMAP SoC are different to Cortex-M4s?
 
tarator said:
I'm quite a noob in this section and I don't understand, if I understand things right here. I'was fiddling around with an arduino at home (programming it with Eclipse CDT). So as much I understand, I could use the both M4s as a prototyping board like the arduino? Will it be possible, to write simple C programms, compile them and run them on the M4s, like running code on the Arduino board? This would be awesome!

Do I need an operating system like linux running on the M4's, or can I just run a loop of code. (This brings up the question for me: Does an operating system run on an Arduino Mega2560, when I flash it with a - let's say - LED-Blinky Programm?)

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)

Can anybody help me out here? I'm trying to get my head around over all these complex processor stuff...
Any push in the right direction would help me! :)
Click to expand...
You don't need to run Linux on the M4's and if you ask me it's actually quite a silly thing to do (I don't know of any PRACTICAL example of a coprocessor with shared ram running a separate full fledged OS). Typically, these coprocessors run embedded Code, exactly like the type you would be running on a small board.
 
tarator said:
I'm quite a noob in this section and I don't understand, if I understand things right here. I'was fiddling around with an arduino at home (programming it with Eclipse CDT). So as much I understand, I could use the both M4s as a prototyping board like the arduino? Will it be possible, to write simple C programms, compile them and run them on the M4s, like running code on the Arduino board? This would be awesome!
Click to expand...

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, like flashing an Arduino, which might be a single compiled program or even a small OS. The M4's might be limited in what interfaces they can use - I would think reading/writing GPIO lines is easy, but doing anything with audio/video/SD/MMC is not (because the main CPU needs kernel drivers for those). But, the M4's seem able to read/write (some of? all?) the system's main RAM, and that'd be a good way to communicate with the OS on the main CPU.

tarator said:
will it be possible to just write something on to the screen? (So simply overtake the screen, and give it back afterwards)
Click to expand...

If on the main CPU you display a full-screen X window, which renders the contents of some region of memory; the M4 could use that region of memory as a 2D framebuffer to write graphics. Or perhaps more easily you use some portion of memory as a text console to begin with.

I think the Qubes OS works this way: applications run in separate VMs, and in order that they can render graphics to a confined portion of the screen, the main OS shows an X window frame, inside which it renders the contents of some shared memory region.

tarator said:
Can anybody help me out here? I'm trying to get my head around over all these complex processor stuff...
Any push in the right direction would help me! :)
Click to expand...

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. We have to hope it is all public and that someone can get it working on the Pyra.

By the way, the BeagleBone Black has something similar, the PRUs. Here's an example of using those with an SDK for Windows:
http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_1:_Toggle_LED_with_PRU_GPO
and here with only free software on Linux (with the special kernel modules loaded):
https://www.embeddedrelated.com/showarticle/586.php

pmprog said:
So the M4's on the OMAP SoC are different to Cortex-M4s?
Click to expand...

I think these cores are basically the same, but as mentioned above you will be limited in how you can interface with the main CPU or other hardware. It also might not be as secure as a hypervisor, if the M4 can read/write arbitrarily in system RAM (I don't know). Or that could even be a useful debugging feature, or a bit like having a BMC, or OpenBoot PROM. It would be really great if the main CPU could go into deep sleep and the M4 wake it or power-on when some event happens...

I don't think the M4's in the Pyra support hardware floating-point (that's Cortex-M4F). But the instruction set is otherwise the same Thumb-2 that other Pyra software is compiled for. They should be really a lot of fun and educational *iff* we can program them.
 
Thanks all for clarification! I'm really getting more and more excited getting the Pyra!

After searching the web a little bit i found this mailing list thread. (I was programming with Eclipse and the AVR-Plugin for my Arduino AtMega2560, which worked quite nice. So I thought maybe I can use the same toolchain for the Cortex M4's)

It mentions a free toolchain for the Cortex M series called CooCox. Here the snippet from the discussion of the mailinglist-thread mentioned above: Although it's in german, I hope you get the key-figures :)
ARM Cortex:
+ 32Bit,
+ Speed/Rechenleistung
+ Memory,
+ Peripherie/Schnittstellen
o freie Compiler Toolchain (am ehsten brauchbar CooCox)
- Komplex (nicht für Einsteiger)

AVR (8Bit):
+ Einfach (für Einsteiger)
+ freie Compiler Toolchain (AVR-GCC: Eclipse mit Plugin oder AVR-Studio)
o Peripherie/Schnitstellen
- Speed/Rechenleistung (falls das wichtig ist)
Click to expand...

Dies anybody of you heard about CooCox or has experience with it?
[doublepost=1465394316,1465392775][/doublepost]The GNU ARM Eclipse toolchain also looks promising on the first view (and runs on linux) :)

http://gnuarmeclipse.github.io/
 
You can directly use the default GCC from the Pyra repo, there's no magic involved in compiling stuff for the M4's, it's not even crossompiling as the M4s are using an instruction set that is fully supported by the A15 cores.

The big difference is that they are using ressources that have to be shared with the A15s: unlike the static hardware address mapping configs used for dedicated embedded boards you'll have to set up memory mapping and the like in software by yourself - it's not just "compile and run", you'll have to write the whole preparation and setup code yourself to get everything you'll need. And last but not least: we don't even know how the M4s will be handled by the kernel, ideally you don't want to configure the MMU and the like via root with direct hardware access in userspace.
 
Letalis Sonus said:
You can directly use the default GCC from the Pyra repo, there's no magic involved in compiling stuff for the M4's, it's not even crossompiling as the M4s are using an instruction set that is fully supported by the A15 cores.

The big difference is that they are using ressources that have to be shared with the A15s: unlike the static hardware address mapping configs used for dedicated embedded boards you'll have to set up memory mapping and the like in software by yourself - it's not just "compile and run", you'll have to write the whole preparation and setup code yourself to get everything you'll need. And last but not least: we don't even know how the M4s will be handled by the kernel, ideally you don't want to configure the MMU and the like via root with direct hardware access in userspace.
Click to expand...

But it is still targeting a different libc, startup code etc. Isn't that called cross compiling?
 
stevenc99 said:
I don't think the M4's in the Pyra support hardware floating-point (that's Cortex-M4F). But the instruction set is otherwise the same Thumb-2 that other Pyra software is compiled for. They should be really a lot of fun and educational *iff* we can program them.
Click to expand...

Note, the armv7-a instruction set (used on the A-15s - the M4 uses a subset called 'armv7e-m') has a number of arm instructions that do not have a thumb-2 equivalent. And the default gcc behaviour allows it to generate these instructions in addition to the thumb-2 instructions. This (in addition to the fpu differences) likely means you won't be able to run the same binaries build for the a15 on the m4. You can pass -march=armv7a / -march=armv7e-m (or -mcpu I think) to select between them, and it *might* be OK for the m4 binaries to run on the a15 (not actually gone through the instruction set to check). I believe restricting gcc to *only* generate m4 compatible thumb-2 isntructions would cause a significant performance degradation, and completely bar the use of hardfp.

Though the ABI (linux for the a15, 'bare metal' or some rtos for the m4)/memory layout/many other things will be vastly different between the a15 and the microcontroller m4, so while you might be able to share individual chunks of m4 code on the a15 you'll never be able to run the 'same' binaries.

As for driving the video, I guess if you setup the DSS to read from a set buffer, and mapped that buffer so it's accessible to the m4 that's do-able. Though I suspect the large power cost of running the screen and DSS to drive it would be much higher than a 'simple' app running on the a15 (I guess something that uses 100% of the m4 will be *much* faster on the a15, so will finish faster per frame/whatever update loop and allow it to sleep more often, reducing the power), so there may be little benefit to doing that.
 
_jr_ said:
But it is still targeting a different libc, startup code etc. Isn't that called cross compiling?
Click to expand...
You don't need any of those, you can compile for bare metal.

Cross-compiling means compiling stuff for a different system, i.e. something with a different architecture or ABI than what the compiler is running with. The kernel is compiled for bare metal and AFAIK brings its own runtime and startup stuff instead, yet you don't cross-compile it if you are already running on a Linux kernel with the same target platform.
 
Letalis Sonus said:
You don't need any of those, you can compile for bare metal.
Click to expand...

The -ffreestanding option to GCC will do that, I think. C library functions (like malloc) will be unavailable in that case, but you'll be able to compile simple C routines into assembly for the M4 that way.

By using #ifdef STDC_HOSTED and some extra code sections, you can probably write a .c source file that compiles either for the M4, or (with different compiler flags) as a full executable to run on the A15 for quick testing.

That's probably the easy part. What we lack right now, are the necessary tools or kernel modules that allow us to 'program' the M4's and start executing code. Ti probably bundle those things on OS images for their EVM boards, but we'd have to get those on the Pyra somehow... maybe someone will know how.
 
JonnyH said:
Display Sub System - it's the display output of the omap (that also does some fancy features like rotation/scaling/limited composition)
Click to expand...
If it does rotation then why do we need a rotator chip?
 
TrashyMG said:
Because the DSS does it horrible...
Click to expand...

Yeah, to get anything like sane performance you have to allocate all framebuffers through 'special' TILER memory mapping, which is a 2d tiled view into the same memory (as otherwise a 90-degree rotated framebuffer would not be able to do any burst traffic over the memory bus, as each pixel would be BUFFER_STRIDE bytes offset from the previous - which the memory bus *really* doesn't like). While it's possible to use it (I helped write the Android hwcomposer omap uses :) it's a massive pain and adds a huge amount of sw complexity, and I think TI stopped maintaining the relevant code paths in the sgx driver, so you wouldn't be able to rotate 3d rendered buffers... I think on Android we switched to pre-rotation through the sgx (as *everything* on android goes through the gpu, and the gpu has an option for zero-cost output rotation).
 
You must log in or register to reply here.

Similar threads

O
[Roadmap] Using the Cortex M4 CPUs
2
Replies
39
Views
14K
WizardStan
WizardStan
ToastBucket
ARM M4 usage
2
Replies
30
Views
20K
Silent-Hunter
Silent-Hunter
Back
Top