full OMAP5 documentation

Not sure whether I'm breaking any rules by posting such an old thread...

TI pulled most of their OMAP5 stuff, fortunately they are still hosting the TRM - grab it while you can! The previous links don't work, but try these - as before a TI account is needed for export control purposes, but no actual NDA etc is required.

Let's hope I'm not breaking ITAR rules, or when North Korea start using OMAP5s on their nukes it will all be my fault....

On a more serious note there's quite a bit of interest to anyone like me interested in low level hacking of their Pyra.

It does seem there's quite a bit to play with, as well as the previously discussed Cortex M4s which I'm trying to find a use for - low power music playback perhaps, they should decode MP3 fine - there are also two barely documented ARM968E-S cores in the video subsystem. It would be an interesting challenge to see if you could get them to do something useful - the two ARM9s would have about the power of a GP2X.

I suppose this means you could hypothetically sell the Pyra as having a septacore processor (2 A15, 2 M4, 2 ARM9 and 1 DSP).

On a more serious note there's quite a bit of interest to anyone like me interested in low level hacking of their Pyra.

Click to expand...

Heck yeah, I sure am as well. It would be such a shame not to utilize all the bits the Pyra has to offer. Especially, in my humble opinion, the extra CPU cores that the OS leaves alone/unused. They could surely run a lightweight daemon by themselves, leaving more cycles for the OS and apps on the "better" cores.

Would be so nice to be able to use a VNCd, httpd, ftpd without actually bogging down the OS with these tasks, among other things.

Running any kind of deamon on it requires a full linux stack to run. I don't expect hardly anyone to be doing that with the M4 CPU - you'd probably been to run something like uclinux, but that seems to have died a few years ago now. I'm not sure if anything replaced that, or if everyone just decided to pony up for a rPi and stop messing about with these weird arse boards. I'm thinking use cases might be more like a short loop of thumb code to monitor a sensor and wake up the main cpu if something interesting occurs for it to handle, and it may well turn out that since you can't clock the CPU all the way down to 0, you can do that on a non sped up CPU anyway.

@levi Please correct me if I'm wrong, but reading the PDF I found about the OMAP 5, it looks like all of the cores are directly addressable from the running OS. So where does this whole new linux stack suddenly come from? It even states that the cores all run the same instruction set and a single OS instance can control all the cores, share memory, I/O's and external interrupts. All of which I would need to run a vncd, but none of it seems impossible.
And, secondly... Although I'm relatively new to Linux, I am an accomplished programmer and already have made several daemons according to RFC specifications.
Even if I can only offload a partial daemon to an M4 core, it's still a win over just using the A15's. That said, the M4's may be pretty underpowered for a vncd, but could still be used as secure storage en/decoder with the built in crypto in the SoC. Although that also seems a bit underpowered, with things like DES, AES and MD5 in there, which are all vulnerable.

I don't believe it to be the case that the M4 cores run the full A32 instruction set, as far as I last checked, all of the cortex-M chips are limited to T16 instructions.

To be fair though, I don't know how even simple linux SMD works. Does it run a full kernel on each core from different RAM, or is one core's program counter hooked into a simple round robin scheduler or something? Each core will have its own PC, and probably a little L1 cache but from there they can be hooked into the same RAM as everything else, if that's they way they designed this SoC.

But as I don't think the M4 cores can run debian, you're going to need something else for them to run so that they can keep listening for tasks to start.

To be fair though, I don't know how even simple linux SMD works. Does it run a full kernel on each core from different RAM, or is one core's program counter hooked into a simple round robin scheduler or something? Each core will have its own PC, and probably a little L1 cache but from there they can be hooked into the same RAM as everything else, if that's they way they designed this SoC.

Click to expand...

The cores are always running independent instances of software, that's how multicore systems work. I'd really like to know how you assume a system with a shared PC is even supposed to work at all, even lockstep cores always use dedicated PC registers.

Minimum requirement for running Linux is an MMU, Cortex-M cores don't have an MMU. The OMAP5 does implement an MMU to interface the M4 cores with the rest of the system, but it is not able to satisfy what's needed by the kernel. Linux simply does not run on Cortex-M cores, end of story.

ucLinux ran kind of linux on an M4 system sans mmu, as I understand it. It's rather unupdated these days though, as I previously mentioned, probably because it's a lot of work to keep it up to date in these days of security patches.

But yeah, if I were to write a system for the M4s, I'd be reading up on the T16 instruction set and maybe porting a few library functions from somewhere to make a usable headless single tasking system.

Caved in and gave Arm my personal info to gain access to their "restricted" section. The things you have to do to get some info on your supposedly open hardware... *sigh* Alright, time to dive head first into this pile of documents and see what can be done with these things.

The things you have to do to get some info on your supposedly open hardware... *sigh*

Click to expand...

Well... you might notice that you won't get very far reading only ARM's own documents. The part that made ARM so successful is their modularity: You don't buy a whole system architecture, you only license those modules that you like - and get everything else from elsewhere. Some manufacturers like Broadcom like to hack their own crappy replacements (e.g. an own interrupt controller) to save money - which can really be a PITA, especially if you can't get their documents. This is not only a problem of hobby hackers, even fairly large companies sometimes really struggle to get those PDFs, especially if you're one of the first who has to write software for it.

Pretty much everything I've needed so far from ARM was publicly available without registration, though. You'll more likely need access to TI's documents.

ARMs hiding of documents has annoyed me in the past, although by now most of the A15 documents are freely available, just due to how long it's been out. I should probably have a swizz and see if there's anything there that I've failed to get thus far.