Another Potential Use for Pyra

[ekianjo]

Replacing Chromebooks for ARM server development: 

See this article, currently the most stable boards are recycled chromebooks: 

http://www.systemcall.org/blog/2014/06/trashing-chromebooks/

Panda, Beagle boards fail randomly after several hours/days of usage under heavy load. Not sure if the Pyra will fare any better, but if it does it could be another great potential use. 

 

[ThinkPad]

And the point to use it as server is ?

 

[pmprog]

And the point to use it as server is ?

It's obviously a file server so you can remotely access the files on your Pyra on the go

 

[ekianjo]

And the point to use it as server is ?

Read the article.  

 

[Rockthesmurf]

Coming from a games development background; I am consistently baffled as to how anything serious can be done by natively compiling stuff. The article mentions slower boards taking 5+ hours to compile the toolchain, where as the best one can manage 40-80 minutes, that is just to compile the toolchain, not to run the actual tests. Surely they just need to get a cross compiler set up so one x86 node on their Jenkins farm can build the toolchain, then the testing can be done on an ARM node (using one of numerous methods of delivering the toolchain between nodes, such as build artifacts). It is a rather frustrating situation that cross compiling isn't easier with Linux.

In a professional organisation where people are being paid by the hour, having to wait for some crappy embedded device to compile code (rather than cross compiling 10X faster), is just madness.

 

[Yoyobuae]

Isn't the Exynos SoC on the latest one better than the OMAP5 Pyra will likely have while being half the price?

The price of those chromebooks is just ridiculous.

 

[HamishTPB]

It is a rather frustrating situation that cross compiling isn't easier with Linux.

I didn't realise there were problems with this. My experience is very limited, mostly using several Gentoo PCs together as a compiler farm to keep each one up to date (admittedly with similar x86 architectures). That aside, I was under the impression that if a Gnu compiler existed for an arch then it would cross compile relatively easily? This could be a bit of a blow as I was about to start dabbling with cross-compilation to learn a bit about ARM Not a great issue for me in a non-critical, non-production environment to use the Pandora directly of course as it would be in the commercial environments you refer to.

 

[TrashyMG]

Well Ptitseb does all his work directly on the Pandora and he has over 150 PND releases. I can tell from my experience and some testing I've done, the OMAP5 dev board can compile much faster at 500Mhz than a 1Ghz Pandora can set at 1200Mhz. At full clock speed the Pyra should be very good platform to directly develop on. Still not as fast as an X86 Desktop cross-compiling, but a lot less setup and headaches when things don't quite work right.

 

[apink]

The article mentions that the problem for the arm products it covered in the article is not with the cpu, speed or otherwise, but with the ability of the rest of the components on the board to withstand the temperatures associated with days-on-end 100% loads on the cpu.

 

[levi]

Cross-compiling is fine, but traditionally it's much easier to write a compiler for the native system - you don't need to consider the bit order or word length of the host and target machines independently. So traditionally, cross-compilers tend to have a few more bugs than native ones, though these days it's much better than it used to be. On top of that, cross compiling means you need to have twice as many boxes, and have them networked up and synchronised so the tests can be run on the binaries after they've been built, which is a lot of faff. Any of that extra stuff can and will go wrong at times, so it's understandable that people want the simplicity of native.


To be honest, for the stuff I work in, it's starting to change and the last big CI setup I helped put together built windows binaries on Linux, though perhaps mainly because none of us were particularly au fait with the MS build chain, so it was quicker to knock up something on Linux and debug it when it failed.


The Pandora should be better than the boards the article author tested, if it ran from NAND flash. The NAND package, being packed on top of the CPU has a simpler and shorter interconnect to the CPU, and will benefit from the same cooling solution added to keep the CPU cool. Pyra might be a bit trickier since it won't be POP any more, so will need a separate cooling solution. But, with neither of them being designed with this sort of usage in mind, it's hard to say that either will be any better than the boards tested.