ARM M4 usage


the M4s won't be on by default, and they're not capable of floating point math (at least not in hardware). but they are turing complete, just not very fast to run debian, nor are they hooked up in standard ways to all the peripherals. (AIUI.) you'd also find it difficult to compile stuff directly on them....
 
Are the M4 cores on the OMAP5 missing the FPU? I guess this wouldn't be too much of a surprise since their main purpose is to be used to control the image processing unit. From the TRM it appears they have a direct connection to the DSP core which could be interesting. I still have more reading to do on this subject however.

My goal here is to be able to load externally compiled bare-metal or RTOS applications onto these cores and allow communication with the A15's. Trying to run Linux on these cores doesn't seem very viable, plus I don't really see the point when there's two A15's sitting right next to them.
 
the M4s won't be on by default, and they're not capable of floating point math (at least not in hardware). but they are turing complete, just not very fast to run debian, nor are they hooked up in standard ways to all the peripherals. (AIUI.) you'd also find it difficult to compile stuff directly on them....

I don't see why compiling things on them would be impossible - just not fast. I've built bits and pieces on a 110MHz StrongARM chip with no FPU, indeed I've even built the linux kernel on either an ARM2 or ARM3 chip (no FPUs there either). I don't know why you'd do it. Now the M4 cores don't implement A32, only Thumb-1 and Thumb-2 instruction sets, which are mostly comprised of 16-bit instructions rather than the pure 32-bit instruction set of A32, so they're not comparable MHz to MHz with my old ARM chips, but they should be in a similar ballpark I'd have thought. I'd guess we'll never actually see anyone compiling anything on the M4 cores in our Pyras - when you have access to much faster A15 cores, why would you?

I'd guess these parts don't have FPUs because as far as I can tell they generally get called M4F cores if they have an FPU.

I should probably have said Debian is a Linux which is only designed to run on heterogeneous cores e.g. Symetrical Multiprocessing in modern x86 cores, or an ARM big-little setup. You can't use these M4s in a big-little configuration because they don't implement the same instruction sets.
 
I don't see why compiling things on them would be impossible - just not fast. I've built bits and pieces on a 110MHz StrongARM chip with no FPU, indeed I've even built the linux kernel on either an ARM2 or ARM3 chip (no FPUs there either). I don't know why you'd do it. Now the M4 cores don't implement A32, only Thumb-1 and Thumb-2 instruction sets, which are mostly comprised of 16-bit instructions rather than the pure 32-bit instruction set of A32, so they're not comparable MHz to MHz with my old ARM chips, but they should be in a similar ballpark I'd have thought. I'd guess we'll never actually see anyone compiling anything on the M4 cores in our Pyras - when you have access to much faster A15 cores, why would you?

now i don't mean to be split hairs, but do you know any gcc's compiled for such Thumb-1 and Thumb-2 instruction sets? (i'm willing to be surprised...)

I'd guess these parts don't have FPUs because as far as I can tell they generally get called M4F cores if they have an FPU.

correct.
 
Compiled for? You mean you can run it on a Thumb-only CPU? No idea, but I'd be very surprised if it weren't possible - Thumb is still turing complete, it just usually results in smaller but slightly slower binaries, although as with all compromises, there are situations where it'll actually generate larger binaries. I just don't know anyone whose built it for Thumb - I don't know of anyone with an M4-only devboard who doesn't have a faster machine to cross compile from. Most M4-only boards are probably a little short on RAM for running a C++ compiler too.
 
@ToastBucket any update on using M4 cores? I thought of asking this as you have Pyra now.
Can these cores be used to run Pyra in low power mode, for example to stay connected to mobile network when a15 can take some rest?
 
Hey @docbroke. Nope I haven’t gotten to this yet. I’ve been focusing on the essentials to get a stable release kernel and bootloader for the first run of units. This is almost done. One of my challenges soon is to investigate what needs to be done for suspend etc to be properly implemented on the OMAP5. I know on the AM335x the M core was used to hold the A core in deep sleep, though I’m not sure if a similar method is used on the OMAP5.
 
I'll just note there are a few links to the processors wiki on ti's site here. Those if important need to be cached before the december switch off of the site.

Edit: It's just this from a couple of posts: https://processors.wiki.ti.com/index.php/RPMsg_Quick_Start_Guide

I've grabbed a copy of that and the included images now. I think I've attached it here. It's not quite as originally served, because that was in a wiki. I've replaced all of the wiki image links with direct relative links.
 

Attachments

  • RPMsg_Quick_Start_Guide.zip
    130.1 KB · Views: 318
Last edited:
Back
Top