ARM M4 usage


ToastBucket

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
333
Location
Seattle
Are the two M4 cores in the OMAP used for anything in the out-of-the-box Pyra OS? I am very interested in playing with these when I'm able to get a Pyra. I will likely be building my own barebones rootfs for experimentation with these but it would be interesting to start out using the preconfigured image, so I'd like to not clobber anything running down there.

UPDATE:
The M4 cores appear to interface with the A15's, I/O, and peripherals on the L3 cache. It also appears that communication between the A15's and the M4's can be done through a software communication layer called RPMsg. At this point we have nothing definitive, but have gathered resources for research which are posted below.

  • Video overview of remoteproc (34:07) and RPMsg (40:25) communication between the A8 core and PRU cores on an AM335x (at this point we can assume that this is similar on the OMAP5):
​

  • Most importantly the OMAP5342 TRM: (I'll let a mod add a link to this, not sure if I can for NDA reasons)
 
Last edited:
There's nothing running on there at present; it's a little like the DSP was on the Pandora. The OS is compiled for and runs entirely on the CPU with maybe some NEON/SIMD extensions, and nothing's configured to run on the M4 cores. Portable OSes like Linux only depend on having one core type to use, so would require a lot of work to do anything with the M4 cores, and as far as I know nobody's yet expressed an interest to get anything running on them, so you're welcome to them.
 
They are not used by the default Pyra OS if I remember correctly.
There are plans to use them for voice/ phone stuff in the future by different community members.
Edit: Ninjad by levi
 
levi said:
Portable OSes like Linux only depend on having one core type to use, so would require a lot of work to do anything with the M4 cores
Click to expand...
Just like any other Cortex-M cores, those in the OMAP do not fulfill the minimum requirements of the Linux kernel - they lack a proper MMU. Using them requires bare metal programming or a proper embedded OS.

The hardware assisted video decoding implementation provided by TI does make use of them, though...
 
How difficult would it be to get FreeRTOS running on one of the M4 cores, or would that require an MMU as well?

Will they have access to peripherals such as the accelerometer and GSM module?
 
hns said:
They are completely inside the OMAP5432 SoC and therefore just wait to be activated by software.
Click to expand...

As already asked by Edgex004, do we know if these cores have any access to external interfaces such as GPIOs, or so we have to run some simple loop on the cortex A15 cores to check for accesses and forward them to the real interfaces?
 
levi said:
As already asked by Edgex004, do we know if these cores have any access to external interfaces such as GPIOs, or so we have to run some simple loop on the cortex A15 cores to check for accesses and forward them to the real interfaces?
Click to expand...
TRM describes the M4 Cores as part of the "IPU Subsystem = Image Processor Unit".
Figure 7-1. IPU Subsystem Overview shows they are connected to L3-Interconnect.
Description of L3-Interconnect reveals that it is sort of a synchronized multi-master data&address bus across the OMAP5 chip.
And it connected for example the A15 cores and the M4 cores and GPU and other masters with slaves like I2C or GPIO controllers.
Hence they can address all peripherals like the A15 can.
What can probably must be negotiated is who gets priority if let's say an A15 and one M4 want to modify a GPIO control register...
 
Letalis Sonus said:
Just like any other Cortex-M cores, those in the OMAP do not fulfill the minimum requirements of the Linux kernel - they lack a proper MMU. Using them requires bare metal programming or a proper embedded OS.

The hardware assisted video decoding implementation provided by TI does make use of them, though...
Click to expand...

I have a decent amount of bare metal and RTOS experience with M3 development particularly with TI chips. This is mainly why I'm interested in toying with them a bit. I'm not quite sure how they'll be useful yet, but getting a little blinky blinky running alongside a Linux kernel in the A15's would be a good start. If we can get a baseline of how to get them up and running, I'm sure somebody (maybe me! :) ) can find a place for them.

I have some research to do (thanks ible and hns for the links), but my instinct on how this may work is U-boot sets the system up and loads device trees, etc. Then either U-boot loads firmware into the M4 RAM space (I read that there is 64K of RAM for these cores. Not sure if thats 64K each or its shared) or it gets loaded by the A15's once U-boot loads the Linux kernel into them. While running, the M4's either do their thing either running fully autonomously or act based on communications sent to/from the A15's (obviously is dependent on what gets loaded into the M4 RAM). When I was researching the AM335x series processors, I remember some sort of message protocol that could be used to allow the A8 core to communicate with the PRU cores. I wouldn't be surprised if there were some similar system present or which could be developed here to communicate with the M4's. As I research and learn I'll be sure to post what I learn. Won't be able to start getting my hands dirty until I get a Pyra, though. I'm one of the guys who never got a Pandora back in the day so I'll have to wait until all this voucher stuff is sorted out before I can get my hands on one.
 
hns said:
TRM describes the M4 Cores as part of the "IPU Subsystem = Image Processor Unit".
Figure 7-1. IPU Subsystem Overview shows they are connected to L3-Interconnect.
Description of L3-Interconnect reveals that it is sort of a synchronized multi-master data&address bus across the OMAP5 chip.
And it connected for example the A15 cores and the M4 cores and GPU and other masters with slaves like I2C or GPIO controllers.
Hence they can address all peripherals like the A15 can.
What can probably must be negotiated is who gets priority if let's say an A15 and one M4 want to modify a GPIO control register...
Click to expand...

Given the number of devices in the SoC that are liable to write to this bus, I'd guess it uses some similar scheduling as Ethernet, or maybe something slightly better tuned for the demands of real-time operation - your basic 'if your send conflicts, wait a while and try again' (meanwhile you'd need to block the processor, but I can't see a way around that especially when your cpu isn't OoO).

If and A15 and an M4 try to change the same GPIO at the same time and one of them turns it on and the other turns it off, it'll depend which gets shaken out of the bus negotiation which lands first, which will then get switched the other way on the next bus clock tick. Maybe there's some fancy way to book devices so they can only be accessed by a specific master, but that seems unlikely to me at this scale and this price point.
 
levi said:
Given the number of devices in the SoC that are liable to write to this bus, I'd guess it uses some similar scheduling as Ethernet, or maybe something slightly better tuned for the demands of real-time operation - your basic 'if your send conflicts, wait a while and try again' (meanwhile you'd need to block the processor, but I can't see a way around that especially when your cpu isn't OoO).

If and A15 and an M4 try to change the same GPIO at the same time and one of them turns it on and the other turns it off, it'll depend which gets shaken out of the bus negotiation which lands first, which will then get switched the other way on the next bus clock tick. Maybe there's some fancy way to book devices so they can only be accessed by a specific master, but that seems unlikely to me at this scale and this price point.
Click to expand...
Digging deeper into the 6000 pages of the TRM will likely give exact answers how or how not this works.
 
levi said:
Given the number of devices in the SoC that are liable to write to this bus, I'd guess it uses some similar scheduling as Ethernet, or maybe something slightly better tuned for the demands of real-time operation - your basic 'if your send conflicts, wait a while and try again' (meanwhile you'd need to block the processor, but I can't see a way around that especially when your cpu isn't OoO).

If and A15 and an M4 try to change the same GPIO at the same time and one of them turns it on and the other turns it off, it'll depend which gets shaken out of the bus negotiation which lands first, which will then get switched the other way on the next bus clock tick. Maybe there's some fancy way to book devices so they can only be accessed by a specific master, but that seems unlikely to me at this scale and this price point.
Click to expand...

The L3 interconnect software synchronization system used on the AM335x series is called RPMsg. From one of the E2E posts hns linked us, it looks like the OMAP5 uses this also to provide communication between the A15's and M4's. I found a couple interesting pages regarding this:
https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/315076
http://processors.wiki.ti.com/index.php/RPMsg_Quick_Start_Guide
https://www.kernel.org/doc/Documentation/rpmsg.txt
 
Reading that last API spec, it seems this bus has the concept of channels and there are send buffers implemented in most if not all senders. Those buffers can still fill up if they don't get emptied by the remote end, in which case you can either use C APIs that will return an error or block waiting for the buffer to free some space. I guess at the bare metal end, each time you try to write to a full buffer it throws an exception or something, so if you wanted robust machine code to send a message regardless you'd need to write the exception vector to handle this and block trying to send periodically - it's up to you how you implement it.
 
Found the resource where I first discovered RPMsg on the AM335x platform. Its a recording from a talk done by a TI engineer that goes over PRU integration into AM335x applications. The whole talk is a great watch for someone trying to get a better baseline understanding of how a multi-core system like the OMAP in the Pyra works, but the parts relevant to this thread are the discussion of remoteproc (34:07) and RPMsg (40:25). I also noticed that this thread is linked to from the wiki, so I've started consolidating our findings in the top post.

​
 
Do you have the slides for that? There's some stuff I'd like to read on there that I can't on this screen.

~5ns blink time for GPIOs deterministing is pretty cool. I wonder if we could do LiFi or something similar with this? The round cycle time is therfore ~10ns. So it should be possible to transmit data at 100KHz. Hmm, that's slower than IRphy so probably not actually that interesting.

The normal candidate for this type of subsystem in a mobile device is to handle the cellular radio. You've got hardware decoding the physical radio signals and filling a memory buffer from them, but you need something to reliably empty that buffer, and respond when necessary. But in the Pyra I think our 4G chip includes a processor to do that real time stuff, so actually as long as we respond within a few seconds we're probably okay at the system processor level.

I'm not sure we can decode mp3s at that speed; I had a 110MHz StrongARM computer that could do MP3s, and this is higher clocked that that. 3 cycles per data fetch isn't bad, and certainly beats the time to pull the next few KB off my hard disc on that computer, but only 4K of instruction RAM might be limiting - I'm not sure how big an MP3 decoder needs to be. libmpg123 on my 32-bit linux box is 355K, but how much of that is boilerplate I dunno, and it's x86 code so a little more verbose that -oS ARM code.

Edit: His response to the question at 38/39 minutes suggests this PRU is not or at least wasn't ARM M4 based. But I guess some of the interconnect stuff can be useful. You already pulled out the bits that would be relevant to us, so I apologise for being interested in the other stuff too ;)
 
Last edited:
levi said:
Edit: His response to the question at 38/39 minutes suggests this PRU is not or at least wasn't ARM M4 based. But I guess some of the interconnect stuff can be useful. You already pulled out the bits that would be relevant to us, so I apologise for being interested in the other stuff too ;)
Click to expand...

No the PRU on the AM335x is not ARM based, it is a very simple little processor aimed at real-time reliability whereas the ARM cores in the OMAP5 are Cortex-M4s. As you stated, this video mainly helps with understanding the L3 communication process. I have not been able to find the slides from this video, but I'll post them if I do.

levi said:
I'm not sure we can decode mp3s at that speed; I had a 110MHz StrongARM computer that could do MP3s, and this is higher clocked that that. 3 cycles per data fetch isn't bad, and certainly beats the time to pull the next few KB off my hard disc on that computer, but only 4K of instruction RAM might be limiting - I'm not sure how big an MP3 decoder needs to be. libmpg123 on my 32-bit linux box is 355K, but how much of that is boilerplate I dunno, and it's x86 code so a little more verbose that -oS ARM code.
Click to expand...
The OMAP5 has a DSP core. If I recall correctly, mp3 decoding requires a lot of frequency domain math which would better suited for a DSP. I wouldn't be surprised if PyraOS is already making use of this but this core would be pretty fun to look at too. Thats not to say that the M4's are necessarily incapable of doing this, these cores are 32bits and are loaded with a lot of atomic math functions. They're pretty capable with complex math.
 
Last edited:
FWIW, I don't think the Pyra OS is using the DSP for anything as it's just Debian with some light tweaking at the moment, and debian's a general purpose os designed to run on turing complete processors and nothing else.
 
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
fahrstuhl
Uses for the Cortex-M4 cores on the OMAP5?
3 4 5
Replies
87
Views
23K
txus
txus
Risca
Couldn't wait for my Pyra, so I bought a OMAP5432 devboard
4 5 6
Replies
106
Views
24K
Magic Sam
Magic Sam
Ziz
Russian ARM processor (maybe for Pyra? :P)
2
Replies
32
Views
3K
Exophase
E
ible
NVidia Jetson Nano
Replies
2
Views
718
Chip
Chip
Back
Top