Not everything is as fast as planned

Until we know even how to get the m4s to start running it's probably a little premature to start allocating work for them.  Although the code written for a driver to periodically run can probably run as well on an M4 if we can figure them out, so there's unlikely to be work lost even if we do switch to using the M4s somewhere down the line.

Personally I'm dubious that the M4s even have access to the GPIOs directly though, so it won't be able to read the VSync signal from the rotation chip.  They're probably sat behind a very simple MMU.
My thoughts using one of the M4s were around having this relatively simple process help enable command mode while allowing the primary cores to 'sleep' even when there is something static on the screen.  I'm likely oversimplifying the effort required.

It's hard to believe that there would be advertised cores within the SoC that have no documentation regarding their capabilities or how to address them.
The M4 are called "IPU" (Image Processing Unit) and they simply use shared memory with the A15 cores. Both M4 share an additional 64k RAM and a 16k boot ROM and have a MMU.

You can find a description in chapter 7 in the TRM (if you find a copy or have one under NDA).

And links like these:

What I have not found is a description of the ROM contents. But it appears that TI provides a patched kernel and tools so that something called "SYS/BIOS" is loaded into the M4 and started. And the A15 can use remote procedure calls to trigger code in the M4.

Therefore, I think it is possible to run the VSYNC gpio/interrupt handler on one of the M4 cores, but that a second phase optimization after the Pyra becomes available to the masses. As a first step it is easier to add it as an irg handler to the A15.
Last edited by a moderator:
The M4s are also used as a gateway to the video codec. That is also a possibility we should not want to loose, so we should take it into account.