Potential ARM (Non X86) SoC alternatives

[Exophase]

"RK3188 is better anyway. But yes I think it's better. Compared to OMAP5 it has two more cores"

no it has not. OMAP5 has two Cortex-A15 plus a DSP (which one? C64+, C67 (w/ FPU?)), plus a Cortex-M4 for standby / powersave mode. I like that design.

EDIT: seems like it's the C64+ according to http://www.ti.com/pdfs/wtbu/SWCT010.pdf.

Some embedded Cortex-M3s and a DSP don't count as cores. You want to go down that route we're going to have to start counting all sorts of crap on all of these SoCs - OMAP5 is far from the only one that has DSPs or auxiliary embedded CPUs (even Tegra 2 has an ARM7 somewhere). Who knows what RK3188 has under those categories. Oh and there's then no reason why you wouldn't start counting the GPUs as multiple cores either. No, when someone says core they mean homogeneous ones that the OS can schedule threads on.

 

[vcoleiro1]

I really would like to see all avenues to get a leading SOC explored which I know ED is doing, but, if worst comes to worst. ED could potentially get a Rockchip, or other chinese SOC from one of the manufacturers of PC Sticks in China.  These guys will also do custom work and could make and populate a P2 PCB - along with sourcing the SOC for it.  

So they could be approached to get the SOCs or the whole PCB manufacture.  And there are a number of them like Tena below

Also, I have no idea when the P2 will be released, so talk on specific SOCs is sort of a little hard. But if you were to wait a bit longer, the next Rockchip SOC launching in Q2 next year is supposedly a Quad core Cortex A12 with Mali-T624 GPU which given the thermal properties , power drain and performance of the A12, this might be a better suited option for the P2..

If we do have a choice between ARM and x86 SOCs, then I think some thought on what the P2 should be needs to be had and objectives outlined.  I think the last poll we had that touched on this subject was the one that decided it should fully support Linux and Android. These are the higher level decisions I would have liked to have seen fleshed out before contemplating HW and design. But anyway, I'm sure ED has these in mind.

Also, IF, there is a choice between x86 and ARM, I think the decision needs to be thought out strategically.  I don't think we can flip between the two over and over.  I would say make a decision and stick to it - you wouldn't want to recompile apps when the software libarary gets large in future swapping from P2 to P3 on different architecture.

The decision (x86/ARM) would be based IMO on what the perceived long term prospects of ARM and x86 SOCs are and how they meet your objectives for the P2.

http://www.youtube.com/watch?v=RFHC0LIZ8qQ

 

[bsp]

"and a SATA 2.0 controller".. shut up and take my money

and ok, there's two M4. nice. (..and two SGX cores, how does that work?!)

about the FOSS/closed source graphics driver discussion: I embrace FOSS but only if it gives you the same performance. Working as graphics driver developer myself, I know how much work goes into driver development and why companies like to keep an edge on competitors by keeping it closed (and why this is something you'd rather not do in your spare time). As long as the support / binary driver supply is steady and stable, I'm fine with that.

As you said, OMAP5 is going to be in a lot of embedded devices with long term contracts..

last but not least, OMAP5 is much more similar to the current Pandora than the other alternatives so that should help with keeping compatibility with existing (and future) P1 software.

EDIT: "No, when someone says core they mean homogeneous ones that the OS can schedule threads on." That's your opinion. Not mine and others might beg to differ, too.

 

[Linux-SWAT]

ED should consider to Ask Slashdot for even wider field of view, when time will come.

 

[Exophase]

As you said, OMAP5 is going to be in a lot of embedded devices with long term contracts..

Somebody said that? I'd be surprised if it's true, given the emphasis on mobile devices OMAP has - maybe some other stuff from TI that has Cortex-A15s in it, maybe even some stuff resembling OMAP5 in more than that but I'm doubting OMAP5 specifically.

last but not least, OMAP5 is much more similar to the current Pandora than the other alternatives so that should help with keeping compatibility with existing (and future) P1 software.

I suspect you're thinking that the DSP is going to be required for compatibility on a bunch of stuff now. I'm not seeing it. I wouldn't even count on the DSP being compatible, since TI calls it "mini-C64x." I don't have details but I heard that OMAP4's only had half the execution resources, and if that was the case maybe this carried over to OMAP5. In this case I don't think binary compatibility is too likely given how much of the pipeline and execution units the architecture directly exposes.

EDIT: "No, when someone says core they mean homogeneous ones that the OS can schedule threads on." That's your opinion. Not mine and others might beg to differ, too.

It's not so much an opinion as it is a convention. When people say cores it helps to have an idea when they mean, and when the general public refers to cores in their phones, tablets, and computers and they overwhelmingly do it in a way that's consistent with how I did (that you said was wrong). Unless they're doing it for marketing. Like nVidia and certain Chinese SoC manufacturers occasionally like to.

Or if you'd prefer, I guess we should call Pandora what.. 5 cores? There's the Cortex-A9, C64+, ARM9 in the IVA, and the GPU has two USSE pipes that can simultaneously execute two completely independent code streams. No wait, there's probably an embedded CPU in the wifi/BT module. Or more than one? How are we doing this exactly? The funny thing is since I don't think you know what all "cores" RK3188 has under your criteria you can't be so quick to tell me that it doesn't have 2 more than OMAP5, can you?

 

[xiongxioi]

One concern I have with all the Chinese chips (doesn't not include Mediatek, that's a Taiwanese company), is QA.

They usually have high failure rate, bad performance/power ratio, awful documentation, hideous outdated design architecture (even if they are 28nm as well, that does not prove anything).

Sure, we can make that work, but that could leave a potential customer with a mouth of bad taste. There is not much point in saving a few dollars of cost on a 600 bucks product.

It is rumoured that MTK has given many documents and source codes of their driver to Sony, so it is completely possible they would some day come to their senses and start to support other communities. Since Linux is getting bigger and better and has a lot of growth potential (thanks to valve's SteamOS), it is entirely possible in the not-too-distance future, these companies will pay more attention to Linux. It's not guaranteed, but highly likely.

Pandora is not that underpowered anyway. I would still see myself using it in the coming years. Let's be honest, the situation is more chaotic than ever, and taking our side at this moment in time would mean great risk without any reward.

on one hand, there are companies trying to get into the portable gaming market (NVIDIA), there are companies trying to extend their market (MTK), there are companies trying to compete with a well developed system in a already saturated market (Intel and AMD), there are companies struggling to change their product's target market (Microsoft, apple, Google, even valve).

On the other hand, there are new technologies coming into the scene that all have great promises. VR, universal streaming, cloud services, 3d scan, motion control, 3d printer, universal digital input, 4g, parallel computing all sound like the future of our lives, but we are not sure of whether the time has came.

There is too much uncertainty and too many possibilities.

I say, We should just wait a while, don't take our swing until we have found the target in the "golden range". That way, we will ensure a product that would stay true to its loyal fanbase, but attractive to many outsiders.

 

[ShleeDragon]

we should email these guys for connections.....

http://elinux.org/images/a/ad/Arm-soc-checklist.pdf

http://free-electrons.com/doc/embedded_linux_optimizations.pdf

 

[Hồng Thất Công]

Keep the good discussion going..... I like when the issue is technically debated...

 

[Batou456]

MediaTek: Said no way to Linux drivers happening

Let's dive into that a little more.  Are we talking in terms of addressing the chip blocks, etc, or the GPU?

If the X Server is discarded for Wayland in the OS build, and we're talking months out here when KDE and LXDE behind them will have switched over with Qt 5, that's not necessarily a problem given they will have an Android GPU driver.

As you say the Freedreno and Lima open source driver projects aren't exactly mature, and the big names either aren't exactly wanting to play or make a dedicated Linux GPU driver.  So taking advantage of the Mer efforts associated with Jolla with the Android driver they'd have to maintain isn't necessarily a bad approach versus other options.

 

[ShleeDragon]

It totally depends on how much the ARM soc code is pushed upstream.. lots and lots of the big.LITTLE code isn't in the mainstream kernel... lots of the android kernels could be compiled or with blob'ed modules and userland.

We need vendor support atleast as good as the IT SDKs and drivers... dropping in the SOC might boot in linux but getting most of the functionality to work would be an insane amount of work without it

 

[Mr_Loon]

...

Well like I said, I don't even think Tegra 3 should be on the table. RK3188 is better anyway.

...

Interesting, this was my expectation based on benchmarks when I purchased a $60 Android stick PC with RK3188.

However in real life my Tegra 3 Nexus 7 performs far better (tested with various emulators including DraStic). The performance of the RK3188 is by no means bad, I'd classify it as acceptable for a $60 stick PC.

 

[bsp]

"Somebody said that? I'd be surprised if it's true"

Yep, Grench said that, on the previous page At least I hope this is / will be true.

I suspect you're thinking that the DSP is going to be required for compatibility on a bunch of stuff now. I'm not seeing it. I wouldn't even count on the DSP being compatible, since TI calls it "mini-C64x."

I do not know if they stripped down the C64+ in the OMAP5 but I'd be surprised if they did. Hopefully they just called it "mini-C64x" for marketing reasons (the PVRs in that device are probably far more powerful for graphics/video acceleration). It is also called "IVA-HD" so it should have at least the same, if not higher processing power than the DSP in the Pandora.


About the "core" discussion: I would not go as far as to call the ARM926 or other encapsulated peripheral processors "cores". From a technical point of view, the DSP, at least in the OMAP3 (don't know much about OMAP4 and 5), has access to regular RAM and is fully programmable, documented, and has a freely available toolchain and IDE. That makes it a secondary "core" for me.


The whole design of the OMAPs reminds me a bit of the old Atari Falcon, btw. The Falcon had a Motorola 56001 DSP (far less powerful than the one in the Pandora, of course), and people/devs put it to great use. That was an era when it was common to squeeze every last bit out of what hardware was available. Nowadays it seems like devs rather throw more (easy to program) general purpose "cores" at "it".


(not to belittle your work, Exophase. this is more of a general remark. I could imagine that you specifically would not want to use the DSP since most of the users of your software run it on smartphones where even using the CPU natively is unusual and software is rather meant to be written in Java/Objective-C. Correct me if that assumption is wrong.)


Last but not least: What I find intriguing about the OMAP5 design are the low-power Cortex M4s. I've done some experiments with M3s and M4s in the past year (hobby stuff) and they really are low power, yet quite powerful. I could imagine that it should be possible to e.g. run an MP3 player on one of the M4s while the rest of the system is sleeping. Would it not be fantastic to be able to use a (hypothetical) Pandora 2 as an 100+ hour MP3 player ?


The M4 also has DSP / SIMD extensions (for those who did not know that).


This is non-technical but I'd like to mention that I do not just see the Pandora as a gaming handheld that can emulate devices from times long gone. It is nice that it can do that but the greatest thing about it, IMHO, is that is a portable, low power mini-laptop. If the P2 would have SATA (which OMAP5 provides), and DVI/HDMI/DisplayPort output, I could see that replacing my desktop PC in the future (for most tasks). The P1 is not quite there, yet.

 

[God Ginrai]

(not to belittle your work, Exophase. this is more of a general remark. I could imagine that you specifically would not want to use the DSP since most of the users of your software run it on smartphones where even using the CPU natively is unusual and software is rather meant to be written in Java/Objective-C. Correct me if that assumption is wrong.)

Or maybe he didn't use it because the DSP in the Pandora has had horrible support. Initially, we couldn't even access it because we didn't have the right kernel. And then, if you were to try the right kernel, it had 2 modes to use the DSP, each one having horrible weaknesses. I don't even know if Notaz ever did eventually get the DSP set up as something we could use in SuperZaxxon.

Also, on the core issue, Exophase is totally right. It is common use to talk about the number of processor cores when you are talking about the number of cores in an SoC.

-God Ginrai

 

[bsp]

Also, on the core issue, Exophase is totally right. It is common use to talk about the number of processor cores when you are talking about the number of cores in an SoC.

of course he is right. in fact, we are both right, see http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci and http://www.ti.com/product/tms320dm6446 (same thing applies to the OMAPs). A processor does not become "single-core" just because one of its cores uses a different instruction set. Both cores (ARM and DSP) sit in the same chip and share the same memory, they can even share their caches. TI used to call that a dual-core architecture, they just changed that later for marketing reasons, not technical reasons.

 

[God Ginrai]

Your answer is right here:

It specifically separates the DSP from the processor. The DSP has cores, sure, but it is not cores of the processor, so you don't refer to it as part of the cores of the SoC.

-God Ginrai

 

[WizardStan]

I don't even know if Notaz ever did eventually get the DSP set up as something we could use in SuperZaxxon.

DSP has been available for months, both bridge and link. No one has used it outside of proof of concept. I'm hoping bsp's implementation will be easier to grasp.

 

[bsp]

I sure hope so. I could not find any example code / projects for DSP development on the Pandora before I started the c64_tools project (shortly after I got my Pandora).

Google search also did not turn up anything useful.

There was just some precompiled kernel modules in the firmware, no examples. OK, there is an example PND under Multimedia->Gstreamer DSP which, when clicked on, pops up a message box that reads "The kernel does not currently support the DSP. Do you wish to install one that does? WARNING: THIS MAY BREAK EVERYTHING!". Not very inviting. But let's not derail this thread with DSP related talk. There's much more to a theoretical Pandora successor than just the DSP.

 

[notaz]

Initially, we couldn't even access it because we didn't have the right kernel.

That's not true at all, it's some bs someone thought up and then spread all over the forums.. You could compile dsplink/bridge even for the old 2.6.27 kernel, dsplink was later even included with the old 2.6.27 kernel, still nobody used it (or even did more serious attempts to use it from what I can tell). Well except some people from IRC (aTc?) ran it long ago, and the performance wasn't too good with TI codecs.

OK, there is an example PND under Multimedia->Gstreamer DSP which, when clicked on, pops up a message box that reads "The kernel does not currently support the DSP. Do you wish to install one that does? WARNING: THIS MAY BREAK EVERYTHING!".

Yeah that pnd isn't too nice with it's "if this is not my kernel, shout('THE KERNEL DOESNT SUPPORT DSP!!111)".

 

[God Ginrai]

Initially, we couldn't even access it because we didn't have the right kernel.

That's not true at all, it's some bs someone thought up and then spread all over the forums.. You could compile dsplink/bridge even for the old 2.6.27 kernel, dsplink was later even included with the old 2.6.27 kernel, still nobody used it (or even did more serious attempts to use it from what I can tell). Well except some people from IRC (aTc?) ran it long ago, and the performance wasn't too good with TI codecs.

I particularly remember when the guys in IRC were toying with it. And I specifically remember complaints that it didn't work correctly with the current kernel, but the next version up would work. However they didn't want to use the next version of the kernel, because there were other drivers (the GPU maybe? I don't remember which drivers) that would not work on the more recent kernel.

-God Ginrai

 

[notaz]

I'm quite sure that was the same false rumor from the forums. dsplink has little dependencies on kernel version, and a version of dspbridge existed for 2.6.27.