DragonBox Pyra Goes Up For Pre-Order

[castlefox]

From their FAQ

Q: Weren't you the one who screwed up the Pandora??
A: Yes and no. I was part of the original Pandora team but I actually didn't do the calculations or handle the production, I only took care about the community.
When the UK company (OpenPandora Ltd.) gave up, I decided to try to keep going and took care of the production, which has then worked flawlessly. The same company which was producing the Pandora from then on will also produce the Pyra.

[kingu]

No offence, but

None taken.

a product has to be free first before we can talk about that.

Im detailing the nature of how open it is, because it has implications for how free the device is.

If GPU isn't free (leaked code is still technically illegal to use), I'm not calling it "free".

Nor did I.

I don't give a fuck about blobs per-se, the issue here is that blobs can't be integrated in kernel and cannot benefit from fixing and updating from the kernel/Xorg developers.

I care, and it sounds like you do too.

the GPU isn't a bluetooth/wifi/3g dongle that can go and burn in hell with or without blobs, the GPU is CRUCIAL for any device with a screen, so yeah, I'd rather want it to be free in a device advertised as such.

There is a free driver for the vivante 2D accelerator. (etnaviv) I mentioned you don't need to have 3D acceleration, if you are so inclined.

Who is developing this GPU driver? Are they developing it (more like "do they have the source code") or it comes in binary form, straight from IT?

Imagination Technologies. TI licenses it. ImgTec does not own all of it. The DRM driver is open, so the userspace part is covered.

If they can at least keep the driver updated to work with the kernel it's going to not suck so much.

Yes, they can.

Mind me, I know that there weren't terribly better choices, I doubt that there were Snapdragons with similar CPU performance within the same price range of what they have chosen.

You cant just chose as a small player. Also Qualcomm has blobs aplenty on the surrounding stuff, which is a part of this bigger picture. Android drivers is not the same as Linux drivers. The pyra chose to be modular, because more options are better options

Edit: 516+prototype units sold now, which means the threshold for production has been met.

[droidhacker]

Call it "DragonBox"... powered by OMAP? WHAT IN THE FUCKING FUCK?
If you call it DRAGONBOX, it should have a FUCKING DRAGON IN IT!!!
Snapdragon, to be precise.

[FLHerne]

Call it "DragonBox"... powered by OMAP? WHAT IN THE FUCKING FUCK?
If you call it DRAGONBOX, it should have a FUCKING DRAGON IN IT!!!
Snapdragon, to be precise.

DragonBox is ED's electronics company - in addition to the Pandora and Pyra, he sells third-party emulators/cartridge-readers/controllers etc.

[SystemCrasher]

Well, it's a good thing the CPU board is upgradable, so that in the future, you can simply replace the CPU board if/when a new CPU board for the Pyra is made available.

Still, 720P@5" LCD and dual-core 32-bit CPU not what I call exciting at these price tags. "Replace" means I have to pay quite some money first, no?

Furthermore, at least with OMAP3, as seen in Nokia N900, Ti proven to be troublesome vendor. E.g. "smart reflexes" were only available on "secure" parts, undocumented and demanding NDA, while "non-secure" parts totally lacked it. Not to mention Ti chosen not to let users into ARM TrustZone, which is bad for privacy & security. Not sure if they've reconsidered somethnig, but overall it seems I'm not a big fan of Ti or OMAPs, their overengineering always brings issues, but their bang per buck is really unexciting.

So, overall, idea is cool. But implementation is, erm, well, I guess there is plenty room for improvement. Or maybe I'm just too picky/too greedy (and I wouldn't deny I have quite specific views on hardware either).

[stevenc]

From benchmarks I've seen, the Cortex-A15 at 1.5GHz (on a prototype Beagleboard X15, dual-core), if it had 4GB RAM as is planned for the Pyra, should be able to out-perform a 2GHz Odroid-XU4 octa-core, a quad-core CuBox or the WandBoard Quad. Perhaps because the A15 cores are faster at a given clock speed than older Cortex-A8/A9; and many workloads are probably limited to a single core's performance anyway.

It would be nice to see some OMAP5 benchmark results on OpenBenchmarking.org / Phoronix soon.

[tigerroast]

Still, 720P@5" LCD and dual-core 32-bit CPU not what I call exciting at these price tags. "Replace" means I have to pay quite some money first, no?

You'd have to pay a lot less money than if those modules were not replaceable, buying just the module rather than a whole new Pyra. The price of any module depends on the MOQ of the components needed vs. how many units might sell (which is a major reason why the OMAP5 was chosen) and, after the release, how many Pyras are in the wild.

Specifically, as of right now, the total cost of producing one Pyra in a batch of 1000 is ~$352 with current exchange rates. Note that includes all components (CPU board, screen, case, etc.) plus all production costs (prod. time, assembly, testing, packaging, Global Component's coverage for damages exceeding a 5% failure rate). Also note that's production costs only (which excludes profit, marketing, distribution, etc.). The CPU board costs a fraction of that. How big a fraction is beyond me.

Basically, you'd pay less to buy a Pyra and then upgrade the screen and CPU to 1080p and (hypothetically) a Snapdragon 808, respectively, than you would buying the first model Pyra and upgrading to a whole new Pyra with those components. Even if such modules came out and a non-4G Pyra owner decides he wants 4G as well, then a trade-in/package deal for just the boards+screen could easily be offered for less than a whole new Pyra since that excludes assembly and parts costs.

Furthermore, at least with OMAP3, as seen in Nokia N900, Ti proven to be troublesome vendor. E.g. "smart reflexes" were only available on "secure" parts, undocumented and demanding NDA, while "non-secure" parts totally lacked it. Not to mention Ti chosen not to let users into ARM TrustZone, which is bad for privacy & security. Not sure if they've reconsidered somethnig, but overall it seems I'm not a big fan of Ti or OMAPs, their overengineering always brings issues, but their bang per buck is really unexciting.

On the contrary, TI has been nothing but accommodating with Dragonbox, and the dev team seem to like the swath of features the OMAP5 brings outside of the clock speed of its main processors.

So, overall, idea is cool. But implementation is, erm, well, I guess there is plenty room for improvement. Or maybe I'm just too picky/too greedy (and I wouldn't deny I have quite specific views on hardware either).

The implementation? If the OMAP5 works fine, then there's nothing wrong with its implementation. Even if the OMAP5 itself is seen as unfavorable, it can be swapped out for another CPU board without buying a new Pyra.

[stevenc]

The CPU board costs a fraction of that. How big a fraction is beyond me.

The Pyra's CPU board (including RAM and eMMC) might just as easily be used on something other than a Pyra... and work out cheaper than the upcoming Beagleboard X15, but having twice the RAM. Having that on a developer board with Ethernet and real serial port would be awesome.

On the contrary, TI has been nothing but accommodating with Dragonbox,

Just this past week, I saw TI engineers submitting patches on LKML to enable new OMAP5 features for the Pyra. That's really cool.

I don't expect OMAP5 to be ditched and left without kernel updates, like many cheaper SoCs have in the past.

[Lightkey]

stevenc: You will be able to get that from https://shop.goldelico.com/wiki.php?...%20Cortex%2015 ; Dr. Nikolaus "hns" Schaller's company Golden Delicious, who designed the Pyra PCBs.

[Shimon]

From benchmarks I've seen, the Cortex-A15 at 1.5GHz (on a prototype Beagleboard X15, dual-core), if it had 4GB RAM as is planned for the Pyra, should be able to out-perform a 2GHz Odroid-XU4 octa-core,

You mixed up your comparison - XU4 is based on Cortex-A15 too.