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.

List of documents including TRM: http://www.ti.com/wcmcomponents/doc...=9263&familyId=601&tabId=7392&docCategoryId=6

Direct link to TRM Rev AF: http://www.ti.com/lit/pdf/swpu249

If these links ever break I have saved a copy and can send it to people.

Edit: some other potentially useful documents

Early version of the data manual with electrical specifications: http://pdf.radioaktiv.ru/ds/ti/swps051e.pdf
Operating condition addendum with voltage and frequency data: http://www.ti.com/lit/ug/swpu329/swpu329.pdf
Silicon revision 2.0 errata http://www.ti.com/lit/pdf/swpz037
 
Last edited:
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).
 
daveshah said:
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.
levi said:
Good luck finding a httpd, vncd or even an ftpd daemon running under ms-dos then.
Click to expand...
Did that. It was ugly but it worked. Still hate 386 protected mode coding.
 
Last edited:
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.
 
levi said:
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.
Click to expand...
If they were not limited to Thumb-2, they wouldn't be Cortex-M cores. ARM invented Cortex-R to cover that.

levi said:
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.
 
Just because I did some reading:

From the cortex_a15_trm:
1.3 Features
The Cortex-A15 MPCore processor includes the following features:
• Full implementation of the ARMv7-A architecture

Whilst the OMAP5432TRM states:
7.1.2 Features
The IPU subsystem integrates the following:
• Two ARM Cortex-M4 microprocessors (IPU_C0 and IPU_C1):
– ARMv7-M and Thumb®-2 instruction set architecture (ISA)
– ARMv6 SIMD and digital signal processor (DSP) extensions

The difference between ARMv7-A and ARMv7-M can be found at http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka16827.html
 
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.
 
Alphasys said:
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.
 
I registered acccount many times before and failed to create account.
So, I think it may need special account to download TRM.

But I registered again after read your post and it completed.
Finally, I can download TRM.
Thanks for your information. :)
 
You must log in or register to reply here.

Similar threads

skeezix
Do You _Need_ A Pnd Documentation Reader For Windows?
Replies
8
Views
2K
skeezix
skeezix
skeezix
Do you _need_ a pnd Documentation reader for Windows?
2
Replies
27
Views
3K
MarioPandio
MarioPandio
O
[Roadmap] Using the Cortex M4 CPUs
2
Replies
39
Views
14K
WizardStan
WizardStan
maciek_urbanski
Direct (close-to-the-metal) open-source SGX driver
9 10 11
Replies
206
Views
58K
pmjobin
P
S
GP32 Wanna write an emu for GP32 of this hand-held?
Replies
12
Views
3K
saimo
S
Back
Top