Some more of my ideas

[Natsu]

Why should we? Tegra 4 is still ARM.


But nvidia is just not possible. You can only buy their SoC when you use a certified company to create the design and a certified company for production. Those companies usually don't start with less than 100,000 qty, and they probably wouldn't do a design like a Pandora anyways - they would do a tablet, maybe.

You're right, but honestly, I only mention them due to the quad-core Cortex-A15.

 

 

[EvilDragon]

I don't think quad-core would make a huge difference for us.

 

[Binky]

Are there any tri/quad threaded applications that you would seriously want to run on a palmtop anyway?

 

[bzar]

*cue the PS2 emulator comment*

 

[rohezal]

There is a ps2 speedhack which allows the hos machine to use up to 3 cores. This is nice. But some people said we have 4 cores  (2 small cortex 4 2 big cortex 15), so one of the small cores could here a little. I use the pandora to code on the train / bus for ray tracing, calculating 2d stereo images, more processors would be nice for this .

 

[Hồng Thất Công]

Why should we? Tegra 4 is still ARM.

Yeah, the moment I opened my mouth, I knew it was a stupid comment, but was too late

 

[WizardStan]

But some people said we have 4 cores  (2 small cortex 4 2 big cortex 15)

In big.LITTLE, you only have access to one set of cores or the other, unfortunately, except for this one SoC I remember reading about that I've since forgotten who it was from but it definitely wasn't the OMAP5.
edit: the omap5 isn't even big.LITTLE, actually, so that's moot. ED would have to go with something completely different. There's too many rumours going around right now, I'm just going to completely shut up about it until he tells us what he's working with.

 

[EvilDragon]

OMAP5 is not big.LITTLE as TI always had their own implementation similar to big.LITTLE, so they didn't license that.

 

[Exophase]

In big.LITTLE, you only have access to one set of cores or the other, unfortunately, except for this one SoC I remember reading about that I've since forgotten who it was from but it definitely wasn't the OMAP5.

It was never supposed to be like that. That this is how it's being used in Samsung SoCs today is a combination of them screwing up the hardware and them being lazy with the software even after they fixed the broken hardware.

OMAP5 is not big.LITTLE as TI always had their own implementation similar to big.LITTLE, so they didn't license that.

OMAP5 really has nothing close to big.LITTLE no matter what some people might say.. it's not enough to have small processors, even if they share an address space. The driving point behind big.LITTLE is that the OS has freedom to schedule threads agnostically between them. The cores need to run the same instruction set and they need to be cache coherent, neither of which is true between these Cortex-A15 and M4 cores.

TI never had anything like this.. putting down different types of ARM cores for specialized tasks isn't really that unique, others have done that.

For anyone dreaming about utilizing those (most likely low clocked; I don't have actual numbers but I doubt it exceeds 500MHz) Cortex-M4s to get some kind of tangible performance boost, it's not going to happen. They'll be good for the things they were designed for, which is to handle some embedded-style real time or glue logic tasks with better power efficiency. Most likely not the kind of thing any user apps will want to utilize at all, unless they have some kind of special interaction with other parts of the hardware.

 

[Grench]

So... working off the theory that it is an OMAP5,  does that mean that this is the general layout and ports that would theoretically be available?

Spoiler

http://images.anandtech.com/doci/4153/omap5.png

Working clockwise from top left corner...

LPDDR2...  2GB RAM?

NAND/NOR Flash...  not using it per the eMMC conversation?

SD... only 1 SD bus if we're using eMMC for onboard storage?

eMMC...  8 or 16 GB onboard storage?

SATA 2.0...  not used or maybe give it an eSATA port?  (would be VERY cool if so)

USB 3.0 OTG... does this get surfaced as the primary USB port OR as one of those wide micro USB 3.0 dual-port things since this is the switchable host/device port?

3x USB 2.0 host...  does one of these come out as our full sized USB host port?  What could we do with the other 2?

4 camera devices?  Skip adding a camera.  Is there anything other than a camera that these could be coopted into doing for us?

Are we using the TWL6040 for audio?  Would that be up to the standard set by the Pandora?

Up to four displays - wow.

Touch screen controller - does it limit to any specific type/style of touchscreen?

Keypad - does it allow for multiple-key-presses?  Or would we be better off using one of the internal USB host ports for an internal USB keyboard definition to get better response?

UART - Fast IrDA - Can we use this this time?  I'd like to have an IR blaster on the Pyra.

(4) serial UARTS - ignore or use for nub (joysticks) inputs?

WiLink - are we going to use the TI wireless solution?

3G/4G modem - quandry.  I don't think we really need cell-phone like capabilities - but it's there on the chip.  I notice a lot of usable signals are being piped to the 3G/4G modem path (USB, SDIO, etc...)  Can we make better use of these (SDIO = 2nd SD slot)?

Fun stuff.

 

[WizardStan]

Most pins are going to be multiplexed, typically either for their proposed use or as GPIO. A few double up their usage: USBB1 and HSI share the same pins, for example, and USBB2 shares the same pins with UART6 and i2c5. USBB3 seems to be dedicated and operates in both low and full speed mode so no fear of not being able to have that.

Anywho, point is there's going to be trade offs as one peripheral is selected over another: want the high speed modem (GSM) or do we need to save those pins for a second high speed USB port? And each decision cascades into others, forcing you to choose one feature or another one. 6 total UART lines but only one of them has IR capabilities and they are all multiplexed with other things which we might want more.

Looks like the USB3.0 port may be multiplexed with the IR lines, so we'd only be able to have one or the other standard.

On the other hand, if the USB3.0 is exposed externally it'd be pretty straight forward to create an IR plugin and use software to change it. Maybe. Or maybe it's not actually a problem and I'm just misreading the document.

So yeah, I guess the really important point here is that I'm glad someone else is making these decisions because I am way out of my element.

edit: ok yeah, my mistake, the USB3.0 lines are dedicated, they don't even have GPIO attached to them. It looks like it can ONLY support USB3 the way the Pandora's USB can only support USB2 though. It's the USB2HS lines which are multiplexed with the IR lines.

 

[hdonk]

I don't think quad-core would make a huge difference for us.

It depends what you use it for

Personally with the builds I do, make -j4 would be a lot better than make -j2.

Also slicing 3D models uses multiple CPUs.

I guess it depends on whether you intend the Pyra to still be a general purpose handheld, or more aimed at the retro market.

Personally, if you have the choice, I'd say go for as many cores as possible.

 

[_wb_]

Four cores is always better than two cores, but for general purpose applications, I think the memory speed will often be the bottleneck if you manage to keep 4 cores occupied.

 

[slaeshjag]

Assuming that ED went with the OMAP5, it does thankfully have dual channel memory support even for PoP memory, so two cores will hopefully not be that bad..

 

[thatgui]

Assuming that ED went with the OMAP5, it does thankfully have dual channel memory support even for PoP memory, so two cores will hopefully not be that bad..

Unfortunatly it does not have USB3 host capabilities which would have been really nice - thinking of lower power consumption (no bus polling anymore, better data throughput (like booting from an hdd if your Pyra sits on the desk) maybe even creating a multi monitor setup (I know this is also possible with USB2, but only with "mixed" results).

 

[bzar]

OMAP5 has USB3 OTG according to the diagram in a previous post. That can function as USB3 host, no?

 

[slaeshjag]

Assuming that ED went with the OMAP5, it does thankfully have dual channel memory support even for PoP memory, so two cores will hopefully not be that bad..

Unfortunatly it does not have USB3 host capabilities which would have been really nice - thinking of lower power consumption (no bus polling anymore, better data throughput (like booting from an hdd if your Pyra sits on the desk) maybe even creating a multi monitor setup (I know this is also possible with USB2, but only with "mixed" results).

I highly doubt you'll get better multi-monitor support from a USB-dongle than the built in support in the Pyra.

 

[thatgui]

I highly doubt you'll get better multi-monitor support from a USB-dongle than the built in support in the Pyra.

That's why I put a "maybe" in there. Don't know where exactly the bottleneck in a SoC would be, just looking at my colleague using 3x 1980x1200 displays via an USB3 dock on his Dell Ultrabook (Intel Core i5).


I'm currently wondering wether the MIPI LLI/Uniport interface could be usefull or not

 

[slaeshjag]

Internal MIPI DSI will be used for the LCD.

Pretty much all SoC's on the market have an additional HDMI interface on top of that, OMAP5 is no exception.

 

[thatgui]

Internal MIPI DSI will be used for the LCD.

But that interface is exposed extra, or do I just not get the context ?

Pretty much all SoC's on the market have an additional HDMI interface on top of that, OMAP5 is no exception.

Which supports max 2x FullHD, which is also very nice to have, but not very flexible, but by mentioning the additional display capability I just meant it more in an "icing on the cake" way than a must have capability.