GPD XD

[Chip]

It has gotten better, but only because folks have been pestering rockchip ceaselessly to actually support the chip.  There are a few RK3288 devices like the ugoos UT3 and firefly board that are running ubuntu with fairly complete hardware support.

Obviously it's far too late in the game for the pyra to switch, and even if it wasn't, it still wouldn't be a good idea.  The OMAP 5 is still in better position driver-wise, from what I can understand.

The driver/licensing situation for most ARM SoCs is a mess.  Honestly, if you want to build a mobile device that needs full linux support, your only real option is intel.  The braswell atoms are roughly on par with high end ARM chips for both processing power and power consumption.  And while intel's integrated graphics cores were a laughing stock for more than a decade, they've come a long way in the last couple years, and at least intel actually provides linux support for their stuff.  If you were going to start from scratch on something like the pyra today, you'd be crazy not to at least consider the atom x5 series.

 

[EvilDragon]

The problem is not only the software side, but also the horrible english hardware documentation you often get from chinese hardware manufacturers.

 

[Nintendo]

 

[TrashyMG]

The RK3288 SoC is better than the Pyra OMAP5?

It is more powerful. That doesn't make it strictly better, just more performant. Linux support for the RK3288 is almost nonexistent (or was when the Pyra was being designed, it may have changed in the intervening months) so would have been a terrible choice for us.

It is a bit feature light compared to the OMAP5 too, lack of eSATA, less USB ports etc...

 

[Nintendo]

Pandora silver?

http://boards.dingoonity.org/gpd-devices/is-the-blue-plastic-just-painted-on/msg129334/#msg129334

 

[Exophase]

It has gotten better, but only because folks have been pestering rockchip ceaselessly to actually support the chip.  There are a few RK3288 devices like the ugoos UT3 and firefly board that are running ubuntu with fairly complete hardware support.

Obviously it's far too late in the game for the pyra to switch, and even if it wasn't, it still wouldn't be a good idea.  The OMAP 5 is still in better position driver-wise, from what I can understand.

The driver/licensing situation for most ARM SoCs is a mess.  Honestly, if you want to build a mobile device that needs full linux support, your only real option is intel.  The braswell atoms are roughly on par with high end ARM chips for both processing power and power consumption.  And while intel's integrated graphics cores were a laughing stock for more than a decade, they've come a long way in the last couple years, and at least intel actually provides linux support for their stuff.  If you were going to start from scratch on something like the pyra today, you'd be crazy not to at least consider the atom x5 series.

I wouldn't be so sure that OMAP5 is better. The support I see in that thread alone looks better than the support I'm aware of for OMAP5's SGX543MP2 GPU. Which is not surprising because OMAP5 is using much older GPU IP that is of a very different older microarchitecture. And IMG doesn't seem that enthusiastic about supporting it.

The problem is not only the software side, but also the horrible english hardware documentation you often get from chinese hardware manufacturers.

rk3288's datasheet seems okay. I think they've gotten somewhat better since they opened up more to foreign customers. I can't find a user manual though, and I don't know if they'd provide one for this. The Firefly wiki appears to have a lot of good information on how to use the available interfaces in kernel drivers.

One way or the other there may be little choice but to use companies like Rockchip in future iterations. I doubt there are going to be more suitable SoCs from TI or Freescale and I would consider OMAP5, an all but abandoned product, to only barely qualify. Maybe future Intel SoCs will be an option, or maybe Samsung or nVidia will decide to be more generous, but none of these seem like sure bets.

It is a bit feature light compared to the OMAP5 too, lack of eSATA, less USB ports etc...

The real kicker is lack of USB 3. That's a serious compromise. It does however have gigabit ethernet which could help make up for it in some scenarios.

All things considered I'd probably still pick rk3288 by virtue of having more and probably more power efficient CPU cores, a more powerful and better supported GPU,

 

[EvilDragon]

Is the full documentation for the Rockchip available? Should be around 5000 pages or more.

 

[SNESFAN]

Did some searching around and found some documentation from http://wiki.chipspark.com/en/index.php?title=PopMetal one of their partners.

A tech reference manual 760~ pages

http://wiki.chipspark.com/en/index.php?title=File:Rockchip_RK3288TRM_V1.0_System_and_System_Control.7z

And a data sheet 70~ pages

http://wiki.chipspark.com/en/index.php?title=File:RK3288_datasheet_V03.pdf

I can try to contact them to see if they offer other documentation if you want. What specific documentation are you looking for?

 

[Exophase]

Is the full documentation for the Rockchip available? Should be around 5000 pages or more.

TI and OMAP are not the gold standard for how all SoCs and user manuals must look. Look at the manual for Exynos 5250, which for mobile device purposes is a similar SoC. It's only 881 pages (http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV100-0.pdf) and there isn't really a problem with it lacking information vs the TI manuals.

All that really means is that there are less weird peripherals that you'll probably never use and the language may be less needlessly verbose and redundant. Personally I find the OMAP manuals really difficult to navigate.

Let me give you another example: I've used Cortex-M series microcontrollers from both ST and Atmel that offered similar functionality. And yet the user manual from Atmel was a lot longer. And it wasn't because Atmel had a better user manual, it was because they had a ton of redundant peripherals. They had separate blocks for timer, PWM, real time timer, and real time clock even though they could have been done with the same peripheral type with different features available on different channels. And they had separate blocks for UART and USART when they also could have been done with the same peripheral type. So not only did I have to read multiple sections to learn how to use different peripherals to do the same sorts of things but I had to actually have two copies of nearly the same code because their eval board connected one UART to the UART block and one to the USART block. Suffice it to say that I don't think they're making the better chip.

At any rate, you don't necessarily need the user manual if the Linux drivers are decent and comprehensive, they can give you the infrastructures you need to work with to build a device using the SoC. But the linked TRM (thanks SNESFAN) looks fine for that purpose.

 

[EvilDragon]

I can't check these now (as I am on-the-go on my phone), but do these have all the detailed information for hardware design (design rules, etc.) included?


I know from Nikolaus that there's A LOT you need to know - it's not just which pin needs to be connected where, but also stuff like trace length, timings, etc.

 

[Hồng Thất Công]

This discussion is interesting, suggest mods separate this discussion out to a new thread before it gets burried here.

 

[fusion_power]

Looks good, I want at least that build/material Quality for the Pyra. Clean case, no rough edges, smooth surface finish.

 

[Exophase]

I can't check these now (as I am on-the-go on my phone), but do these have all the detailed information for hardware design (design rules, etc.) included?

I know from Nikolaus that there's A LOT you need to know - it's not just which pin needs to be connected where, but also stuff like trace length, timings, etc.

I don't know but you can look at the schematics and drawings for Firefly board as a reference.

 

[Nintendo]

{snip}

Looks good, I want at least that build/material Quality for the Pyra. Clean case, no rough edges, smooth surface finish.

So...like a New 3DS XL?

 

[directive0]

OpenConsoles posted up an unboxing with some...music?... of some kind?

Enh, about what I expected. Still not drooling over this thing.

https://www.youtube.com/embed/IegizV4MVAE?feature=oembed

 

[Nintendo]

Yeah, that's an old one though. C'mon people! Start posting new vids on YouTube ffs!!!

 

[Chip]

FYI - over on the dingoonity boards, there are quite a few people complaining of issues with the XD.  Some have noticed green lines in the HDMI output, some have wonky dpads, many have issues with crackle from the speakers and/or a high pitched whine from the backlight circuit, and a few have had their XDs die completely (possibly due to the latest firmware update, possibly not).  There's also a good thread on input lag, which is pretty much unavoidable on any android device.

To be fair, there are plenty of people who are reporting no problems at all, so these seem to be run-of-the-mill Chinese QC issues and not crippling design flaws.  But anybody considering this device should be aware of the potential for problems.

 

[Nintendo]

2nd and 3rd batch should be much healthier then

 

[SNESFAN]

I'm still quite happy with mine. I've ran it though about 4 charge cycles so far playing snes and ps1 games. Seeing about 7-8 hours before the 10% warning comes up. I've not experienced any of the reported problems, maybe I was just lucky.

 

[Jumpman]

I'm still quite happy with mine. I've ran it though about 4 charge cycles so far playing snes and ps1 games. Seeing about 7-8 hours before the 10% warning comes up. I've not experienced any of the reported problems, maybe I was just lucky.

It's like anything, the people with problems are always the most vocal. Most people with no issues aren't going to shout from the mountain tops about it.

Chris