[Roadmap] Using the Cortex M4 CPUs

[Kiga]

Is it be possible to run android on the M4s? I guess it wouldn't be possible to interact directly with the apps.

 

[ible]

nope. really low level, simple stuff. if they can be made to run an OS, it will be a very reduced version of linux (more like an RTOS, probably).

 

[SNESFAN]

This thread is interesting, just two days ago I had suggested something similar and was assured from multiple sources it wasn't possible.

 

[Kiga]

nope. really low level, simple stuff. if they can be made to run an OS, it will be a very reduced version of linux (more like an RTOS, probably).

Okay. Maybe it is possible to have an android kernel on M4s and then run most of the process on the A15s? Even if it is feasible I don't know if it would be better than emulation though.

 

[Orbstheorem]

Hi all

@Roosembert Palacios : nice project, I really hope it'll come to fruition !

What about running some unikernels on the M4s ?

Cheers, Magic Sam

It's the first time I hear about them, so I quickly check with wikipedia and looks somewhat limited.
I think having the ability to easily compile and run (almost) any linux software without recompiling the entire system is one of the main targets.

Besides...

In addition, device drivers are required for the specific hardware the library OS runs on.

This would be very painfull to write...
[doublepost=1464546100,1464545917][/doublepost]

Just for beginners, this thread is about what exactly? Sorry to ask but i'm not sure what exactly do you plan and why, to much tech stuff.

The OMAP 5432 (The SoC the pyra is using) features (among other things) two ARM Cortex-M4 processors which are currently of no use. The main Idea is to get Linux running on those core so we can use them for something useful. The interest relies in these cores being really low power and having access to the system memory.
[doublepost=1464546389][/doublepost]

Okay. Maybe it is possible to have an android kernel on M4s and then run most of the process on the A15s? Even if it is feasible I don't know if it would be better than emulation though.

I'm not even sure that M4s have the hardware support for running something like the android kernel. Besides, I think android would be too heavy for the M4s to confortably run.
Heterogeneous multiprocessing would be a complete pain in the neck. I can't imagine the complexity of the context switch strategy somebody would have to implement...

 

[levi]

The kernel that android uses is of course a linux kernel, so that work is already planned.

Okay. Maybe it is possible to have an android kernel on M4s and then run most of the process on the A15s? Even if it is feasible I don't know if it would be better than emulation though.

The M4s are not able to supervise the A15s, so I don't think they'll be able to schedule processes on the latter.

 

[fusion_power]

The OMAP 5432 (The SoC the pyra is using) features (among other things) two ARM Cortex-M4 processors which are currently of no use. The main Idea is to get Linux running on those core so we can use them for something useful. The interest relies in these cores being really low power and having access to the system memory.

Ah, now I understand. I didn't knew that the OMAP5 SoC also has additional 2 "mini processors". I hope they will be put into usage, would be sad if we again have an "DSP-issue" like with the Pandora, meaning that there are potential cool HW features that can't be used in practise. ^^

 

[levi]

Yes, the M4s are rather like the DSP the OMAP3 had - it's awesome that someone's stepped up to try to get use of them this early in the development cycle. I guess technically they're more like the ARM9(?) core that was in the OMAP3 but nobody here but Exo ever mentioned its existence as far as I know. As the OMAP5 DSP is the analogue of the OMAP3 DSP, so hopefully some of the lessons learned there can translate.

 

[Letalis Sonus]

I guess technically they're more like the ARM9(?) core that was in the OMAP3

That core is a lot more restricted, though. IIRC it was originally only included to assist the DSP with video decoding, and with the way they implemented it you really can't use it for anything else - it isn't even documented.

The M4s do have a lot more potential, they were actually included to allow you to play with them, it should be much easier to develop something using them than trying to use the DSP - with a few tricks you might even be able to create a program that could move a process from the main CPU onto one of the M4s at will, they do use a subset of the Thumb2 instruction set supported by the big CPU cores. With quite a lot of things the bigger question is whether it's worth it - those cores were originally designed for embedded microcontrollers after all.

 

[ible]

i am mostly interested in the M4s because the bitbox is based around a single M4 (though with a lower frequency, but floating point support), and it's super fun to develop for it.

if possible, it'd be fun to use the Pyra M4s to race-the-beam and write to the screen, just like on the bitbox. but... i'm not sure that's possible.

 

[WizardStan]

The fact that you can just use gcc to compile code for them automatically makes them more accessible than the DSP in my opinion. Needing a completely different compiler chain was the biggest turn-off to everything I ever tried to do with the DSP.

 

[Djoga'Ro]

The kernel that android uses is of course a linux kernel, so that work is already planned.

Isn't the android kernel a fork? Did they merge? Did android drop its own and switch? DID LINUX DROP ITS OWN AND SWITCH? AHHHHHH!!!

 

[Agricola]

Isn't the android kernel a fork? Did they merge? Did android drop its own and switch? DID LINUX DROP ITS OWN AND SWITCH? AHHHHHH!!!

IIRC, Android is still a fork, but a few of its additions were implemented in the Linux Kernel.

But according to my very limited knowledge about this and this website about the Linux Kernel it probably won't run without a Memory Management Unit which the M4 probably doesn't have, which is why Linux for embedded systems (µClinux) is the only viable option. The link provided in the first post by @Roosembert Palacios (I mean this one) also points to a Kernel based on µClinux. If I'm wrong about any of this, please somebody correct me, I just searched a bit on Google and am no developer of any program or OS myself.

Edit: Oh, and by the way, eventhough I understand less than half of what you guys are talking about here, I love this thread.

 

[Djoga'Ro]

IIRC, Android is still a fork, but a few of its additions were implemented in the Linux Kernel.

But according to my very limited knowledge about this and this website about the Linux Kernel it probably won't run without a Memory Management Unit which the M4 probably doesn't have, which is why Linux for embedded systems (µClinux) is the only viable option. The link provided in the first post by @Roosembert Palacios (I mean this one) also points to a Kernel based on µClinux. If I'm wrong about any of this, please somebody correct me, I just searched a bit on Google and am no developer of any program or OS myself./QUOTE]
That's my understanding, too. In terms of linux kernels there has work already been done, which can be build upon. In term of the android kernel there's not. For a moment I thought, I've had missed something significant.

 

[Orbstheorem]

IIRC, Android is still a fork, but a few of its additions were implemented in the Linux Kernel.

But according to my very limited knowledge about this and this website about the Linux Kernel it probably won't run without a Memory Management Unit which the M4 probably doesn't have, which is why Linux for embedded systems (µClinux) is the only viable option. The link provided in the first post by @Roosembert Palacios (I mean this one) also points to a Kernel based on µClinux. If I'm wrong about any of this, please somebody correct me, I just searched a bit on Google and am no developer of any program or OS myself.

Edit: Oh, and by the way, eventhough I understand less than half of what you guys are talking about here, I love this thread.

It actually does have a MMU,

However, I'm not sure how viable is it to be used by the linux kernel. I'll have to go check the code. But I Won't be doing that at least for a month
[doublepost=1464594772,1464594571][/doublepost]

Yes, the M4s are rather like the DSP the OMAP3 had - it's awesome that someone's stepped up to try to get use of them this early in the development cycle. I guess technically they're more like the ARM9(?) core that was in the OMAP3 but nobody here but Exo ever mentioned its existence as far as I know. As the OMAP5 DSP is the analogue of the OMAP3 DSP, so hopefully some of the lessons learned there can translate.

Can somebody please put me up to speed on what happened with the DSP on the Pandora? I'm quite new in here ^^/
[doublepost=1464595009][/doublepost]

i am mostly interested in the M4s because the bitbox is based around a single M4 (though with a lower frequency, but floating point support), and it's super fun to develop for it.

if possible, it'd be fun to use the Pyra M4s to race-the-beam and write to the screen, just like on the bitbox. but... i'm not sure that's possible.

"Technically" it should be possible, as we can access the Main System memory from the M4. But we'd had to make some sort of integration to share the screen resource among both systems (Main A15 and Secondary M4).

 

[slaeshjag]

If you're quite new, I'm happy to tell you that you will have plenty of time doing this. Currently, like with all "new" Ti chips, the software part is quite amazingly broken. It'll be years before you can save any noticable amount of power by offloading stuff to the M4's. Suspend to RAM was descoped afaik, meaning it's broken and Ti want to forget that it was a feature to begin with, meaning it'll be up to the users to attempt fixing it, as with pretty much any other power management feature that was planned and descoped.

 

[Orbstheorem]

If you're quite new, I'm happy to tell you that you will have plenty of time doing this. Currently, like with all "new" Ti chips, the software part is quite amazingly broken. It'll be years before you can save any noticable amount of power by offloading stuff to the M4's. Suspend to RAM was descoped afaik, meaning it's broken and Ti want to forget that it was a feature to begin with, meaning it'll be up to the users to attempt fixing it, as with pretty much any other power management feature that was planned and descoped.

I'm used to TI's software support. I did development for am335x before and it was a real pain with all the broken sources and back at the time Ti's Gitorious was down...

 

[M-HT]

Yes, the M4s are rather like the DSP the OMAP3 had - it's awesome that someone's stepped up to try to get use of them this early in the development cycle. I guess technically they're more like the ARM9(?) core that was in the OMAP3 but nobody here but Exo ever mentioned its existence as far as I know. As the OMAP5 DSP is the analogue of the OMAP3 DSP, so hopefully some of the lessons learned there can translate.

That core is a lot more restricted, though. IIRC it was originally only included to assist the DSP with video decoding, and with the way they implemented it you really can't use it for anything else - it isn't even documented.

A bit off-topic, but the ARM9 core was mentioned a few time and it's actually documented - you can find some details in/around this post.

 

[levi]

Can somebody please put me up to speed on what happened with the DSP on the Pandora? I'm quite new in here ^^/

I think that thread M_HT linked to was close to the beginning of the DSP story. Basically, it took a few years for a low level engineer with an interest in getting the dsp working to come along, and then a few more years until it was possible to use that stuff in an actual game. Once the Pandora was capable of running many emulators, most engineer hours were spent on tidying up the OS, maintaining the kernel, and porting thousands of programs across, and getting odd bits of hardware in the OMAP SoC working was a niche interest at best.

 

[WizardStan]

Can somebody please put me up to speed on what happened with the DSP on the Pandora? I'm quite new in here ^^/

There was major struggles to get the DSP. Eventually M-HT got a platform in place and the whole thing became available, but by this time it's been several years and it's just kind of bleh to try and do anything.