CuBox

From XBMC
Jump to: navigation, search
CuBox
SolidRun CuBox.jpg
CuBox hold next to a €1 Euro coin
Developer SolidRun Ltd.
Released Early 2012
OS Android, Ubuntu, Debian GNU/Linux, Fedora, Arch Linux
Power 3 W @ 5V/2A DC
CPU Marvell Armada 510 (ARMv7)
Storage Micro SD card slot
RAM 1 GB DDR3-800MHz
Connectivity HDMI 1.3 with CEC
S/PDIF (optical output)
1000baseT Ethernet
2 x USB 2.0 host ports
1 x eSATA (3Gb/sec)
IrDA (InfraRed) receiver
MicroUSB (console only)
MicroSD slot (comes with 2 GB MicroSD SDXC, upgradable to 64 GB)
Dimensions 55 x 55 x 42 mm
Weight ~91 g
Website http://www.solid-run.com

The CuBox is a very small, fan-less nettop-class computer manufactured by the Israeli company SolidRun Ltd. It is cube-shaped at only approximately 2 × 2 × 2 inches and weighs 91 grams (0.2 lb, or 3.2 oz). CuBox is the first commercially available desktop computer based on the Marvell Technology Group's Armada 500-series SoC (System-on-Chip), and said to currently be the worlds smallest complete desktop computer.[1]

It was announced in December 2011 and began shipping in January 2012, initially being marketed as a cheap open source developer platform for embedded systems, so just like the Raspberry Pi it is not designed for end-user but rather for developers looking to improve their experience with embedded systems.[2][3][4][5][6][7]

Contents

1 Overview

CuBox is a low-power ARM architecture CPU based computer, using the Marvell Armada 510 (88AP510) SoC with an ARM v6/v7-compliant superscalar processor core, Vivante GC600 OpenGL 3.0 and OpenGL ES 2.0 capable 2D/3D graphics processing unit, Marvell vMeta HD Video Decoder hardware engine capable of 1080p video decoding, and TrustZone (Security Extensions) Cryptographic Engines and Security Accelerator (CESA) co-processor.[4][8]

Despite being just about 2-inch-square device size, the platform can stream and decode 1080p content, use desktop class interfaces such as KDE or GNOME under Linux, all in less than 3 Watt and less than 1 Watt in standby.[9]

Solid-Run currently officially only supports Linux kernel 2.6.x or later, and Android 2.2.x and later, and it comes with Ubuntu Desktop 10.04 and Android 2.2 dual-boot pre-installed. An experimental version of Linux kernel 3.4 for the CuBox is however available with source code.

2 XBMC for CuBox

XBMC has already have an initial port for the CuBox with hardware accelerated video decoding using GStreamer, this experimental port was made by Solid-Run developer abeeh (Rabeeh Khoury) in his fork on GitHub.com but the code patches has not yet been submitted upstream into mainline XBMC.

2.1 Installing pre-compiled XBMC on CuBox

2.2 Compiling XBMC for CuBox

2.3 Xilka Linux Distribution on CuBox

3 CuBox Hardware Specifications

For a more detailed hardware specification please see the CuBox hardware specification on the Solid-Run wiki.

CuBox Functional Block Diagram.

3.1 Physical Dimensions

3.2 Core SoC (System on Chip) and integrated co-processor cores

Marvell Armada 510 (88AP510) ARMv6/ARMv7 SoC in a 55nm BGA process package

3.3 External input/output ports, buttons, and interfaces

3.4 HDMI transmitter by NXP Semiconductors Caen

The CuBox (Marvell Armada 510 - 88AP510 SoC) hardware has integrated TDA998x (TDA19988 or TDA19989) HDMI transmitter by NXP Semiconductors Caen to support HDMI output and CEC (Consumer Electronics Control) over HDMI.

HDMI transmitter (from NXP) resolution options:

Display Controller:

3.4.1 Detailed list of supported resolutions

3.5 Vivante GC600 graphic engine

Vivante GC600 OpenGL ES 2.0 GPU (Graphics Processing Unit) running at 250MHz (500MHz in shader processing), scalable up to 285 MHz (571 MHz shader) 32-bit AHB interface for register access with 64-bit AXI interface to access external memory by graphics client, and virtual memory support. Supported Screen Resolutions:

3.5.1 2D and 3D GPU features

3.6 Audio Controller with SPDIF Optical Output Port

3.7 vMeta HD Video Decoder hardware engine

Marvell vMeta HD Video Decoder hardware engine running at 500MHz for decoding H.264, VC-1 and MPEG-2, etc. and vMeta engine also support JPEG/PNG/GIF/TIFF/BMP/Animated GIF decoding acceleration up to 50MP/s. A number of containers are also specified as being supported officially, but that is usually a matter of firmware.

The Video Decode (VMeta) unit decodes the compressed Video Elementary Stream (VES) to produce the reconstructed video frames (in YUV422 format) for display or further processing. The input VES and the output frames are stored in DRAM.

The typical VMeta™ operation sequence can be summarized as:

  1. Demux extracts VES to the buffer inside DRAM.
  2. CPU sets the DMA to start prefetching VES.
  3. CPU invokes the vScope block for upper-level stream processing.
  4. CPU initializes the rest of VMeta, download programs, and initializes VMeta for video decoding.
  5. vScope performs the lower-level stream processing to generate messages (queued in HBO) for the pixel processing block.
  6. vCache fetches the reference pixels for the pCube.
  7. pCube reconstructs the video frames and outputs to DRAM.

3.7.1 Hardware Audio and Video Decoding Codec Formats supported

3.8 Cryptographic Engines and Security Accelerator (CESA)

The 88AP510 integrates hardware-based cryptographic engines and a security accelerator (CESA). The cryptographic engines and the security accelerator reduce CPU packet processing overhead by performing time-consuming cryptographic operations such as Advanced Encryption Standard (AES), Data Encryption Standard (DES), and Triple Data Encryption Standard (3DES) encryption, as well as Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA1) authentication. There are four cryptographic engines that operate independently, one at a time, (one DES encryption/decryption engine, one AES128 encryption engine, one AES128 decryption engine, and one Authentication MD5/SHA engine).

3.9 XOR DMA Engines

4 Stuff left to do by capable developers on the XBMC for CuBox

TODO list for any capable C++ developers willing to help develop XBMC for the CuBox and submit any finished patches upstream to XBMC:

  1. Get the CuBox integrated CEC (Consumer Electronics Control) over HDMI to work with the libcec and thus also work with XBMC, see http://www.solid-run.com/phpbb/viewtopic.php?f=12&t=514 and http://www.solid-run.com/mw/index.php/CEC_%28Consumer_Electronics_Control%29_over_HDMI
  2. Build XBMC on ARM HardFB (Hard Floating Point), a.k.a. armhfp for the CuBox's SoC VFPv3 - Vector Floating Point (VFP) v3 engine, on top of a Linux distribution with hard float support, for more information see http://www.madeo.co.uk/?p=851
  3. Add better reset implementation instead of flushing by seeking, look at the GStreamer and EGL patches created by Rob Clark in this XBMC fork on GitHub => https://github.com/robclark/xbmc/tree/gstreamer-eglimg
  4. Add delay for pipeline gstreamer creation and wait for paused state. The reason is that there is always hickups when video starts to play since XBMC starts sending frames for decoding, but gstreamer pipe still not ready.
  5. Fix proper pipe closing. There seems to be missing 30 frames at the end of every playback. The reason is that gstreamer is done on decoding but video renderer is still showing those decoded frames.
  6. Change ffmpegcolorspace in gstreamer to output either YUV420, UYVU and other supported dove-overlay video layer color formats (I420 is YUV420 but with swapped color space etc...)
  7. DVDVideoCodecGStreamer has lots of cleanup to do. Internally it has lots of printfs that needs to be removed.
  8. MathUtils doesn't build correctly with the native ARM code already in XBMC (probably scratchbox toolchain issue). Notice that sometimes when launching XBMC we get some assert on MathUtils, unclear if it's related or not.
  9. Ugly hack to make XBMC build. Somehow although we don't build LinuxRendererGLES.cpp that header file still being used. For now it's a hack, should be removed in the future.
  10. Second hack is that Status typedef is missing when building WinEventsSDL which leads to build error on XKBlib.h
  11. Hack to disable eglCreateContext that Dove GL driver doesn't like. Needs to be sorted out
  12. Added --with-iwmmxt to fmmpeg configure, but disabled meanwhile since the used processor for build (cortex-a9) doesn't support that. Needs to be fixed in the future (will add performance by using Dove vector operations when codec not supported by video engine and CPU decoding is required).
  13. Implement the GPU backoff algorithm when playing a video. Since the video is rendering directly via a video overlay, no need for tens of fps for GPU in that time since it might only be used for subtitles. Instead of running tens of fps, lower the fps of the gpu and thus keep more DDR bandwidth for the video engine so higher bitrate content can be played.
  14. Add auto video out resolution select mode. On the GUI go for 720p since the graphics is best (images are 720p optimized and fps is faster - more smooth). When playing back switch to either 1080p or to the native resolution of the content with it's corresponding refresh rate.
  15. Assert failures at the beginning when running XBMC. Similar to the item mentioned in XBMC forums here => http://forum.xbmc.org/showthread.php?t=81122
  16. asound.conf is not good enough. there are some noises in 44.1KHz and others.
  17. Disable Xorg screen blanking when playing a movie.
  18. Implement Marvell vMeta hardware engine JPEG (and other image formats) decoding, as done by the XBMC for iOS port, this should increase the GUI speed/smoothness and image caching/thumbnailing immensely. Contact XBMC team developers TheUni, Davilla, and Memphiz about how this is done in XBMC for iOS port.
  19. Check to if Rob Clark has any other relevant GStreamer, EGL, ARM, etc. patches in this XBMC fork on GitHub => https://github.com/robclark/xbmc/tree/gstreamer-eglimg
  20. Possible try to make XBMC run with DoveFB X.Org and FBDev DirectFB 2D / 3D graphics engine drivers|DirectFB using DoveFB support, to run XBMC without X, (as currently XBMC requires X since it runs over EGL with X backend). This depends on latest DirectFB/Mesa, so have to run newer Ubuntu, for more information see https://github.com/xbmc/xbmc/pull/454
  21. When playing in 1080p, LCD refreshes the graphics overlay by 1920x1080x60hzx32bpp = ~500MB/sec. While playing the graphics overlay is either 100% transparent, or there are subtitles in the bottom of the screen. Implement a hardware mechanism that checks graphics overlay every one second; and by partitioning it and crc32 (by hardware engine) each part adjust the starting and ending point of the graphics overlay. This should drastically lower the LCD graphics overlay refresh.
  22. Look into gimli's native VMeta decoder implementation in his reworked marvell-dove tree to use as an alternative to GStreamer => https://github.com/huceke/xbmc/commits/marvell-dove
  23. Utilize CESA co-processor cryptographic engine (TrustZone on CuBox) for hardware acceleration encryption / decryption crypto and ciphers calculations tasks such as SSL, SCP, SSH, AES, DES, 3DES, SHA-1, MD5, hashes, dm-crypt, luks, etc. (such as OpenSSL and OpenSSH via CryptoDev to offload cryptographic tasks from CPU and therefore every dependency module that XBMC utilizes which support CryptoDev) => http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=634

5 See also

6 References

  1. ↑ http://www.myxnews.com/2011/12/solid-run-cubox-worlds-smallest-htpc.html Solid-Run CuBox: World's Smallest HTPC (video)
  2. ↑ http://www.geek.com/articles/chips/cubox-is-a-sexy-ice-cube-sized-arm-computer-20111221/ CuBox is a sexy, ice cube-sized ARM computer
  3. ↑ http://www.crazyengineers.com/cubox-ice-cube-sized-arm-computer-1465/ CuBox – Ice Cube Sized ARM Computer
  4. ↑ 4.0 4.1 http://www.linuxfordevices.com/c/a/News/SolidRun-CuBox/ Android-ready ARM mini-HTPC costs $130, uses just three Watts
  5. ↑ http://www.cnx-software.com/2011/12/14/solid-run-cubox-open-source-platform-for-android-tv-media-center-and-nas-development/ Solid-Run CuBox: Open Source Platform for Android TV, Media Center and NAS Development
  6. ↑ http://coburndomain.org/index.php/2011/12/move-raspberry-pi-cubox-enters-fray-1gb-ddr3-ram-dualcore-cpu-hdmi-gbit-lan-cubed-box/ Move over Raspberry Pi: CuBox enters the fray with 1GB DDR3 RAM, dualcore CPU, HDMI, GBit LAN… all inside a cubed box
  7. ↑ http://www.omgubuntu.co.uk/2011/12/meet-cubox-a-tiny-arm-powered-media-centre-capable-of-running-ubuntu/ Meet CuBox – A Tiny ARM Powered Media Centre Capable of Running Ubuntu
  8. ↑ http://www.linuxfordevices.com/c/a/News/Marvell-Armada-100-500-600-and-1000/ Marvell expands range of ARM SoCs
  9. ↑ http://www.youtube.com/watch?v=twEoMYEJls4 XBMC on SolidRun Platform named CuBox

7 External links

Retrieved from "http://wiki.xbmc.org/index.php?title=CuBox"
Personal tools
Namespaces
Variants
Actions
Navigation
Wiki help
Google Search
Toolbox