[Roadmap] Using the Cortex M4 CPUs

[Orbstheorem]

This is a sumary of the research I've been doing on this subject. This reflects to my best will what I think can be done according to the documentation I've found.

First at all, the Cortex M4 cores might be clocked around 167 MHz 200MHz
Second, I found the OMAP543x Technical Reference Manual
This document explains the internal architecture of the OMAP5.

The bad news is that starting up a coprocessor seems way more complicated that I though. (Check the linked document to see a little bit about it).

The good news is that I might have some clues though, so basically the plan boils down to this:
1) Proof of Concept of M4s booting and running: Dummy blinky led, using (internal) timer interrupt.
2) Try something based on this to load the kernel.
3) Getting an embedded cortex m4 linux image stable (at least not to panic).
4) Get a remote shell (like having uart on a devel board) to the linux system running on the M4s...
5) Setup some sort of tmpfs so we can "share" files with the other system
6) Buy some pizza to celebrate userland on Cortex M4

What to do next?

According to the Technical Reference Manual (p1418), the cortex M4's MMU can be configured from the A15s and can be allowed access to system memories and peripherals.

The main ideas:
- Assign the USB Port of the modem to the M4's address space so it can use the device.
- Basically use the M4s as a baseband processor:
- - Control the state of the modem
- - Wake up the main system (via an interrupt) in case of a network event (ie. a call or an SMS).
- - Export the internet connection via networking (? ideas here please)

Personally my main target would be being able to shutdown (ie. suspend to ram) the A15s and keep myself connected to the network so I can receive network events.

Challenges:
Stage I: Booting the M4s:
This is (by far) most tricky part.
Hints:
- Locate the ram segments assigned to the boot of these cores.
- Write and Compile a simple test program that pokes the interrupts of the system to have some feedback from the M4 cores. (Basic embedded programming...).
- Lock these segments from kernel space (so they can't be swapped off. This shouldn't be that hard). Flash an executable into this space (trivial aswell...).
- Find all the reset signals to be tweaked so the M4s will exit from reset state.
- Setup some sort of "fake" uart to communicate with the M4 cores.

Stage II: Running Linux on the M4s:
- Cross Compiling a Cortex M4 version of the Linux Kernel. (Not necessarly the one I linked abode).
- Enable the MMU as soon as possible.
- Setup some sort of "fake" uart to communicate with the M4 cores.
- Setup some tmpfs for making a rootfs for init (/sbin/init) and busybox.

Stage III: Connecting both kernels:
- Setup some sort of "shared" tmpfs so we can easily upload binaries and files into the M4 system.
- Setup interrupts so the M4s can wake up the A15s.

Stage IV: Setup USB (MMAP?) on the M4 kernel:
- Take the USB Peripheral from usb_core subsystem and reset it.
- (MMAP?) link the USB Port to the M4 kernel.

Stage V: Setup networking:
- Setup some sort of TAP interface on both sides.
- Setup the modem software (the driver should be included on the linux kernel...).

Let me know what you think about this project. All opinions welcome.

Personally I've done some kernel driver development and Embedded (both linux and RTOS) Systems development. But I'm still somewhat concerned about all this, I'd rather discuss this with you so we can maybe figure a better plan.

Thanks for reading

Best Regards

@EvilDragon can you please show this to Nikolaus and tell us what he thinks?

--- Update 29.05.16 ---
I won't be working anymore on this project until I get my pyra for two reasons:
- I found enough information to say this is feasible an requires mostly experimentation, I'll leave bellow the clues I've found so me or anyone interested can retake this later.
- The following weeks I'll be on exams and I should focus (I'm a student, sorry ).

Related:
http://processors.wiki.ti.com/index.php/Early_Boot_and_Late_Attach
https://git.ti.com/ipc
https://github.com/goldelico/gta04-kernel/tree/work/hns/pyrav5/drivers/remoteproc

 

[levi]

I advice getting pizza first; all that hard work needs something to power the brain!

I hadn't envisaged running a full linux kernel on these cores - what benefits does that give? I guess it would let multiple users run processes on it at the same time, but I'd kind of envisaged it just running a single process for simplicity's sake. I guess it's not really the same as the DSP, which is likely mainly used by the foreground process which is occuping the screen - the M4s are more configured for real time long-running processes, like servicing the GSM module. If the MMU can be mapped onto the LED GPIO addresses, and it turns out those don't need the A15s powered up to toggle, then it could be useful to notify using those LEDs. LEDs and speakers even better.

Since there are two M4s, perhaps one running a linux kernel, and the other one left bare for the foreground process.

 

[ible]

sounds great. really looking forward to whatever you can piece together and share. i'm more of a "userland" guy (can't really program interfacing with the hardware directly, or at least i haven't tried), so i won't be too much help in getting things going, but perhaps in figuring out uses for it.

 

[liveunderwater]

Not sure about needing or wanting a linux kernel in the M4s. I just ate and am being lazy about looking things up but it sounds like the M4s are like the PRUs in the Beaglebone Black. Probably best used for long term processes as put here

the M4s are more configured for real time long-running processes, like servicing the GSM module.
Since there are two M4s, perhaps one running a linux kernel, and the other one left bare for the foreground process.

If the M4s also have a scratch pad memory to do one cycle (or is it one T on the black?) register swaps I feel it would be best to leave the kernel on the A15 to let the M4s go ballistic on some very specific process. Look at the BeagleLogic for example using its two PRU cores at 200mhz and splitting that down to 100mhz with nops to sample an entire PRU worth of data and then using the scratch pad register swap instead of a nop to interrupt the other PRU to fetch scratch data and move to slower DDR while the first PRU keeps pumping away data... How any of this would be relevant to the Pyra I'm not sure... aside from perhaps also have a built in logic analyzer

 

[Askarus]

I like the project a lot

 

[hns]

Great idea and plan!
I would prefer to try to run a separate Linux on the M4. It gives highest flexibility, as soon as it is running stable. E.g. submitting and running shell scripts on the M4 is much easier than learning another assembler code (PRU) or API for inter-process communication or fiddling around with version upgrades and dependencies of something different from Linux.
One more idea: we have a "volumed" daemon that polls the potentiometer adc and controls the amixer master volume. The tricky part in this case might be to set the master volume in the twl6040 in a way that it stays in sync with amixer on the A15.
About the Pizza: please plan for two. One before starting and another when done

 

[Orbstheorem]

I advice getting pizza first; all that hard work needs something to power the brain!

I hadn't envisaged running a full linux kernel on these cores - what benefits does that give? I guess it would let multiple users run processes on it at the same time, but I'd kind of envisaged it just running a single process for simplicity's sake. I guess it's not really the same as the DSP, which is likely mainly used by the foreground process which is occuping the screen - the M4s are more configured for real time long-running processes, like servicing the GSM module. If the MMU can be mapped onto the LED GPIO addresses, and it turns out those don't need the A15s powered up to toggle, then it could be useful to notify using those LEDs. LEDs and speakers even better.

Since there are two M4s, perhaps one running a linux kernel, and the other one left bare for the foreground process.

Not sure about needing or wanting a linux kernel in the M4s. I just ate and am being lazy about looking things up but it sounds like the M4s are like the PRUs in the Beaglebone Black. Probably best used for long term processes as put here


If the M4s also have a scratch pad memory to do one cycle (or is it one T on the black?) register swaps I feel it would be best to leave the kernel on the A15 to let the M4s go ballistic on some very specific process. Look at the BeagleLogic for example using its two PRU cores at 200mhz and splitting that down to 100mhz with nops to sample an entire PRU worth of data and then using the scratch pad register swap instead of a nop to interrupt the other PRU to fetch scratch data and move to slower DDR while the first PRU keeps pumping away data... How any of this would be relevant to the Pyra I'm not sure... aside from perhaps also have a built in logic analyzer

I also think that runnig a complete linux kernel would be somewhat overkill, but I've done enough embedded to know the pain of porting software to embedded systems (I'm looking at you USB Driver). Besides, I wouldn't like to recompile all the code running on the M4s just to update the frequency of the leds (for example).

I think we should give linux a go, or at least try. We wouldn't have backports on every kernel update, but more like a static kernel.

Btw, anyone has an idea how could we "fake" the uart?

 

[lukey]

Great idea and plan!
I would prefer to try to run a separate Linux on the M4. It gives highest flexibility, as soon as it is running stable.

Or eLua which should have less overhead. But since we have two cores we could use one for "official" stuff like syncing the Display and Rotator Chip, pooling the volume wheel, etc. And one for Pyra optimized Applications or for tinkering with it (like generating an Composite Signal on some exposed GPIO Pins). Also it looks like "only" uClinux works.

 

[ashcloud]

Can the M4 continue to run even if the main CPU/System is in suspend? It would be awesome to have a crontab on the m4s which can wake up the main system.

 

[kabaiakh]

It would be awesome to have a crontab on the m4s which can wake up the main system.

And play your favourite music to use the Pyra as an alarm clock.
Being woken up by cron(8) ... quite an achievement.
Anyone doing that with his Pandora ?

 

[Letalis Sonus]

First at all, the Cortex M4 cores might be clocked around 167 MHz

TI's product page says 200 MHz. Don't mix up the 5430 with the 5432, we'll get the latter.

 

[Orbstheorem]

Or eLua which should have less overhead. But since we have two cores we could use one for "official" stuff like syncing the Display and Rotator Chip, pooling the volume wheel, etc. And one for Pyra optimized Applications or for tinkering with it (like generating an Composite Signal on some exposed GPIO Pins). Also it looks like "only" uClinux works.

I think a full linux *might* work as the M4s have a MMU (As opossed to the usual embedded device).

Can the M4 continue to run even if the main CPU/System is in suspend? It would be awesome to have a crontab on the m4s which can wake up the main system.

Yes, There should be an interrupt from M4s to A15s to take them off deep sleep...

TI's product page says 200 MHz. Don't mix up the 5430 with the 5432, we'll get the latter.

Thanks for the correction! I wasn't sure...

 

[rSl]

cool project!
this is way over my skills, but i wish all the best for awesome results!
and pizza galore!!

 

[Galaxis]

TI's product page says 200 MHz. Don't mix up the 5430 with the 5432, we'll get the latter.

Are we talking about the "IPU subsystem" M4s in the "ISS megacell" on the block diagram? I'm probably rehashing things that everyone knows, but since I haven't really thought about those up to now: It seems that TI planned that as companion for the DSP, to do image processing for a camera module. Workflow seems quite similar to the DSP, too - load up some TI-supplied firmware, and talk to it via the TI IPC API. There's some cursory discussion to be found on the TI forums, like here or here or this one about bringig up a custom firmware on the M4s. That last post has an answer from TI, with some information about what did and what didn't work back in 2013:

[..] the A15 host loads the IPU slave, sets up the rpmsg-required buffers needed for communication, and takes the slave out of reset. [booting the IPU independently] likely requires carving out resources (e.g. memory, clocks) from Linux, disabling various load/reset code in remoteproc drivers, building the load/reset support into uboot, and adding the ability for the A15/IPU to Late Attach to each other and run as 'peers' rather than a 'host/slave'.

 

[Orbstheorem]

Dear all, I've updated the first post with some new info., I really can't wait to have my Pyra!

 

[hns]

Dear all, I've updated the first post with some new info., I really can't wait to have my Pyra!

You could even consider to make the first steps on an OMAP5432EVM or IGEP5 board...
Any sponsor around (AFAIK they still can be bought e.g. from https://svtronics.com/5432)?

 

[liveunderwater]

Power management:
– Local power-management control:
Configurable through the WUGEN_IPU registers.
– Three sleep modes supported, controlled by the local power-management module.
– IPU is clock-gated in all sleep modes.
– INTC_IPU interrupt interface stays awake.

To me that says that the sleep states of the M4 IPUs is pretty versatile and independent of the A15
[doublepost=1464501331,1464501090][/doublepost]To me, the best use of the M4 IPUs would be for time sensitive processing like emulated audio/video cores. They do have a shared cache with the A15 but I have not yet read (in the 6000 pages) how many cycles it takes to mov
[doublepost=1464502239][/doublepost]Hey mods, as I'm reading through this TI ref doc... I can't paste that here can I?

 

[slaeshjag]

Is it the one with "TI Confidential - NDA Restrictions" printed in the header of every page? If so, then no.

 

[Magic Sam]

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

 

[fusion_power]

Let me know what you think about this project. All opinions welcome.

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.