full OMAP5 documentation


I absolutely plan to use the M4s. My company writes software for M4 cores and I'm hoping to convince my boss that it'd be worthwhile to have it running on an OMAP5 board as a demonstration. Once I'm paid to learn how to use them I won't feel like a shit trying to do it in my free time and I may actually come up with something useful. That's my hypothesis anyway, we'll see how it works in practice once I've actually got a Pyra.
Sounds great, do you have already any ideas about possible usecases ?
 
I absolutely plan to use the M4s. My company writes software for M4 cores and I'm hoping to convince my boss that it'd be worthwhile to have it running on an OMAP5 board as a demonstration. Once I'm paid to learn how to use them I won't feel like a shit trying to do it in my free time and I may actually come up with something useful. That's my hypothesis anyway, we'll see how it works in practice once I've actually got a Pyra.
Ah yes, something useful. That is the problem - similiar to DSP on Pandora. :) But even knowing how to run code on the M4 cores will be a step forward so good luck with that.
 
I am hoping the pyra will have enough power to run deadbeef with the LADSPA 3-band parametric equalizer.

If I had 10x the coding skills I would do a DSP based parametric EQ...
 
I am hoping the pyra will have enough power to run deadbeef with the LADSPA 3-band parametric equalizer.

If I had 10x the coding skills I would do a DSP based parametric EQ...
I have no clue how to compare as I never dealt with any of that, but I can play 1080p h264 videos fullspeed on the OMAP5 devboard entirely on the power of the CPU(s). 
 
Last edited by a moderator:
If I had 10x the coding skills I would do a DSP based parametric EQ...
If there is one way to get 10x te coding skills it is having a clear cut project like you just described. It probably wont be the best parametric EQ but you'll without a doubt lean a hell of a lot just trying it.

(I just made my own little tuning machine in PD, and I still dont fully understand everything but I sure understand a lot more than I did before)
 
Maybe they decided public documents are not necessary as you can't easily buy the OMAP...? Who knows what TI are doing...
 
MhjT4nC.jpg
 
The public document is back.
I just went to get them, just in case.  But you have to sign away your life to access them.  Are those terms and conditions for real, should they be taken seriously?  If you're not associated with a company then what do you put in the company name bit?  What do people put when they ask you why you're downloading the documents.
 
In older times they had a note asking to enter "HOME" as a company name and "N/A" as a website if you're downloading for personal use. This is still saved on my TI account and pre-filled like that when I need to download their stuff.
 
Thanks, got them now.

I think they are just covering themselves.  There wasn't much of a verification procedure, it let me have the documents immediately.  I've had harder times getting non-prescription drugs online.
 
I absolutely plan to use the M4s. My company writes software for M4 cores and I'm hoping to convince my boss that it'd be worthwhile to have it running on an OMAP5 board as a demonstration. Once I'm paid to learn how to use them I won't feel like a shit trying to do it in my free time and I may actually come up with something useful. That's my hypothesis anyway, we'll see how it works in practice once I've actually got a Pyra.

Ah yes, something useful. That is the problem - similiar to DSP on Pandora. :) But even knowing how to run code on the M4 cores will be a step forward so good luck with that.

I personally have experience with baremetal programming on a DM8148, which includes the dual-cortex-M3 predecessor (Ducati) to the dual-cortex-M4 subsystem (Benelli). Apart from the cores used the subsystems are identical afaik.

My experience is that it's really easy to at least put one core to use. There's a weird little MMU ("AMMU") integrated into the Unicache that should be setup properly, although the reset defaults are already usable and in particular map address 0 to the local SRAM of the subsystem. This means that firing it up is a simple matter of:
  1. Release subsystem from reset
  2. Upload code to subsystem SRAM, adjust AMMU settings to taste
  3. Release core from reset
And it's up and running! Putting both cores to work is slightly more interesting since, apart from their Private Peripheral Bus, the cores have identical views of the address space. Neither AMMU nor the L2 MMU has the ability to distinguish between the two cores. This means that you effectively have to program them as if they're two threads in a single process, which is slightly annoying.


I used the DSP for real-time audio processing (no DMA, no rx fifo, max 1 sample per channel buffered in the tx fifo), but the DM814x has a proper C674x DSP. I'm not sure what to make of that bastard child Tesla that's on the omap4 and omap5, or what motivated TI to cut a C64x+ core in half and glue it onto another (but differently configured) instance of that weird AMMU/Unicache IP block instead of the usual GEM/CorePac. It certainly won't help that the current version (v8) of TI's C6x compiler dropped support for Tesla as being "obsolete", and there's (afaik) no published instruction set manual, although it probably wouldn't be very difficult to figure it out.
[doublepost=1454610309,1454609424][/doublepost]
Sounds great, do you have already any ideas about possible usecases ?

Note BTW that the subsystem is also closely associated with the camera subsystem (ISS). I don't know if Pyra intends to use it, but if so then you may want to use an M4 core to look after it.
 
There is, at least as far as I know, no plan to use the camera subsystem, the main reason being that there is no viable solution to put a camera somewhere when you consider the available modules given the production size.
 
They're really tiny nowadays of course (the smallest I found with a few minutes of googling was the 6.5 mm x 6.5 mm VX6953CB) but I have no idea how cramped the design already is right now. And of course there's the cost issue.

The camera subsystem, especially the SIMCOP subsubsystem does seem to have its uses without an actual camera, e.g. accelerated JPEG en-/decoding and some types of image processing. I wouldn't be surprised if other uses could be conceived for them. Unfortunately, as usual, public documentation is very limited.
 
As far as I know, the X, Y dimensions weren't nearly as critical as depth Z (lid might be able to house a 3mm tall feature, but not much more), placement (facing in or out or two camera modules? screen board takes whole lid & bezel), cost of module and support for it (optics require special considerations) and complicating the wiring between the base and lid.

So - what was the 3rd (height) dimension of that module? Not that it matters now, though, as the boards, plastics and all are already going into production form.
 
Back
Top