RADXA Rock Pro and Rock Light (ARM Development Boards) | Hacker News Reader

RADXA Rock Pro and Rock Light (ARM Development Boards)

radxa.com

14 pointstbrock7 comments

Not much information about the CPU. It says only "ARM Cortex-A9 quad core @ 1.6Ghz". Makes me worried it's again one of those Allwinner or Rockchip cases. In other words, a lot of cores, high frequency and low performance. Number-marketing.

It's Rockchip RK3188. Performance is on par on the ever-so-hyped i.MX6 Novena laptop.

There's been some efforts to reverse-engineer the Mali 400 and write open drivers for it. I'm not sure if they're still making progress or if the project stalled though.

Looks nice, but I miss one crucial thing for me on the specsheet - what levels of hardware video acceleration (both encoding and decoding) are available and how well are these supported under majority of media players (vlc, mplayer, omxplayer?)

It looks like they both have Mali GPUs which are very well supported by Linux. I was considering getting an ODroid board from hard kernel which has the same GPU and is able to play tekken, run OpenGL applications etc, but this seems like a much better deal.

I'm having a (low-end, of course) U3 from ODroid - and it is collecting dust, while my Pi is actively used as XBMC (soon Kali) setup.

The ODroid seems more of a tinkering device:

- no polished media related distribution as far as I could tell (the usual solution is running Debian or something and automatically launching xbmc, as root more often than not in the couple things I tried)

- no way to fix the hdmi output (i.e. overscan issues) - whereas the Pi has a simple text configuration file for that.

What I'm trying to say is: More hardware power doesn't actually give you a better experience..

Would you use the open source Lima driver? Is it usable now?

I haven't used Radxa SBCs, but I did some development for RK3188 GNU/Linux support half an year ago. At the time the hardware video encoders and decoders were not supported on GNU/Linux, but worked ok on Android (with libstagefright support I think).

I've added XV support[0] for video resizing and colorspace conversion, after which mplayer compiled with NEON support and with multithreading could decode in software pretty much any video I've thrown at it.

Things could have significantly improved since then, but I've been out of the loop.

However, I would strongly recommend just going for a Jetson-TK1 - I happen to be posting this from one. You get a fairly comprehensive reference manual and NVIDIA fully supports GNU/Linux (albeit with proprietary Xorg drivers at the time), the ARM cores (Cortex-A15 @ 2.3GHz) are much faster, the GPU supports full OpenGL (as opposed to OpenGL ES) and NVIDIA and the community are working on a fully open source driver stack (with nouveau).

[0] https://github.com/lgeek/xf86-video-fbturbo - very much abandoned alpha-quality software

Reply on news.ycombinator.com