[RockerC]

Does anyone know if Kodi can be installed on the android version? Is it like a normal android install?

Android images are not available for it yet, Hardkernel plan on releasing those in the beginning of next year.

So right now you have no choice, it is Linux or nothing, with Ubuntu images available from Hardkernel.

[Hedda]

Just wish they had full-sized HDMI and lined up the microUSB and HDMI ports so people can reuse Pi B+ cases (why else make it Pi-shaped?).

Agree about using a full-sized HDMI port instead, but for the rest I can see that maybe just being be a commercial decision so that they can sell their own cases, cables and accessories.

I mean that is why Apple have their own proprietary ports and cables on iDevices instead of using standard USB connectors and plugs that follows the the USB committee specifications.

[csgabe]

GPU is Quad Core Mali-450 or Dual Core Mali-450?

[Ned Scott]

Just wish they had full-sized HDMI and lined up the microUSB and HDMI ports so people can reuse Pi B+ cases (why else make it Pi-shaped?).

Agree about using a full-sized HDMI port instead, but for the rest I can see that maybe just being be a commercial decision so that they can sell their own cases, cables and accessories.

I mean that is why Apple have their own proprietary ports and cables on iDevices instead of using standard USB connectors and plugs that follows the the USB committee specifications.

Hardkernel typically doesn't try to make a lot of money on accessories, which is another reason I like them. Their case for the ODROID-C1 is only $4.50, for example.

(Off topic, but as far as Apple's lighting port goes, I'd argue that isn't the case. The "lighting port" connector seems to stand up really well to repeated abuse (more than my microUSB cables/ports, at least), and it is a multi-function port and not just a USB port (HDMI, audio in/out, etc). Which, of course, doesn't excuse them from not making it an open standard (like they did with MiniDisplayPort) rather than charging for "lighting certification", but from a physical/technical standpoint I understand not using USB standards. Especially considering how poorly designed micro-B 3.0 connectors were, IMO. Had USB-C type connectors been available when Apple changed their port, then I think it would be a lot harder for Apple to claim they needed their own new connector.)

[illiac4]

It looks really good and also the prices for remote are low. I hope it will get the support from XBMC community. Is GPU mali good for XBMC? Will openelec support it?

[noggin]

It looks really good and also the prices for remote are low. I hope it will get the support from XBMC community. Is GPU mali good for XBMC? Will openelec support it?

I think as long as the Mali GPU supports OpenGL with proper drivers, which are required for XBMC to render its user interface etc., then the GPU compatibility shouldn't be a problem. Pretty certain the Mali has this support - and the fact that they have demo-ed the UI running on the C1 is a good sign.

The usual issue is the VPU/MFC (i.e. the bit of the SoC that supports H264/MPEG2/VC-1 and now H265/HEVC hardware decoding). This is a separate unit to the GPU, and this is the bit that needs properly supported drivers for XBMC to be useful on it. The i.MX6 and the Broadcom SoC that the Raspberry Pi use have good support for this, which is why they have good XBMC support (and OpenElec runs on them) The Cedar VFP in the Allwinner series doesn't have good support, which is why they have patchy Linux support (after there was so much enthusiasm initially when the Mele range first came to market)

If the VPU/MFC in use for the C1 doesn't have good mainline support and requires either a specific forked version of XBMC and the patches aren't pushed back to the mainline version, or worse requires an external player, then XBMC support will be variable.

The demos posted don't show video playback last time I checked - which suggests VPU/MFC integration is still a work in progress. But it is early days, and Hardkernel are much better at supporting their boards than many others. If I'm honest, though, the U2 didn't really achieve the level many thought it would. I suspect because it launched around the same time that XBMC devs decided to concentrate less on ARM Linux and more on ARM Android versions - because of the sheer numbers of different ARM platforms that started to appear. I can see why, but the limitations of Android are still significant, particularly for those of us in Europe/Aus/NZ etc.

[ProsjektX]

WRT to GigE. Looking at the ODroid PCB there is a separate chip labelled for GigE - so presumably they have implemented it externally independently of any Ethernet built in to the S805? (I assume there is a high speed bus they are using to connect the two?)

No. That chip is a PHY (Physical layer / driver) for Ethernet. Meaning that the S805 has a built-in ethernet MAC but needs an external PHY, typically over an RGMII interface (4 bit two way parallel bus dedicated for ethernet). That's the way it is (almost) always done for SOCs like this. This generic R/GMII interface allows you to put PHY's from different vendors, with different properties, or even Ethernet switch controllers onto this interface.

[j1nx]

Network
 Integrated IEEE 802.3 10/100/1000 Gigabit Ethernet controller with RMII/RGMII interface
 Supports Energy Efficiency Ethernet (EEE) mode
 Optional 50MHz and 125MHz clock output to Ethernet PHY
 WiFi/IEEE802.11 & Bluetooth supporting via SDIO/USB/UART/PCM

[looun]

It looks really good and also the prices for remote are low. I hope it will get the support from XBMC community. Is GPU mali good for XBMC? Will openelec support it?

I think as long as the Mali GPU supports OpenGL with proper drivers, which are required for XBMC to render its user interface etc., then the GPU compatibility shouldn't be a problem. Pretty certain the Mali has this support - and the fact that they have demo-ed the UI running on the C1 is a good sign.

The usual issue is the VPU/MFC (i.e. the bit of the SoC that supports H264/MPEG2/VC-1 and now H265/HEVC hardware decoding). This is a separate unit to the GPU, and this is the bit that needs properly supported drivers for XBMC to be useful on it. The i.MX6 and the Broadcom SoC that the Raspberry Pi use have good support for this, which is why they have good XBMC support (and OpenElec runs on them) The Cedar VFP in the Allwinner series doesn't have good support, which is why they have patchy Linux support (after there was so much enthusiasm initially when the Mele range first came to market)

If the VPU/MFC in use for the C1 doesn't have good mainline support and requires either a specific forked version of XBMC and the patches aren't pushed back to the mainline version, or worse requires an external player, then XBMC support will be variable.

The demos posted don't show video playback last time I checked - which suggests VPU/MFC integration is still a work in progress. But it is early days, and Hardkernel are much better at supporting their boards than many others. If I'm honest, though, the U2 didn't really achieve the level many thought it would. I suspect because it launched around the same time that XBMC devs decided to concentrate less on ARM Linux and more on ARM Android versions - because of the sheer numbers of different ARM platforms that started to appear. I can see why, but the limitations of Android are still significant, particularly for those of us in Europe/Aus/NZ etc.

very nice explanation

[Hedda]

If the VPU/MFC in use for the C1 doesn't have good mainline support and requires either a specific forked version of XBMC and the patches aren't pushed back to the mainline version, or worse requires an external player, then XBMC support will be variable.

The demos posted don't show video playback last time I checked - which suggests VPU/MFC integration is still a work in progress. But it is early days

Pretty sure that you are wrong on all accounts there when it comes to the existing AMLogic VPU support in Kodi, as mainline Kodi already have had great support for AMLogic's VPUs on Android and Linux for a long time now, checkout history in these other threads for more info:

http://forum.kodi.tv/showthread.php?tid=181739
http://forum.kodi.tv/showthread.php?tid=180446
http://forum.kodi.tv/showthread.php?tid=192034

You have to remember that Pivos XIOS DS and other early ARM-devices for XBMC, such as Jynxbox, was almost all based on AMLogic, so even if those have a little bit older SoC they still uses the same VPU technology, and Davilla and others have upstreamed most if not all of that work so much of that is already in mainline.

Thus no special forks of Kodi should be needed needed for AMLogic SoCs, as the VPU playback code for AMLogic on Linux and Android is already available in mainline, and the only noticeable patches that are missing are from mainline is HEVC/H265 support for AMLogic but there is a pull request available for it, (see http://forum.kodi.tv/showthread.php?tid=206333 ).

The video from Hardkernel clearly shows playback in Kodi with a comment that it is "Powered by AMLogic's VPU Hardware decoder", check it out again starting at time-stamp 2:25 here

[jjd-uk]

Following on from the above from Hedda, the vital bit is



On the 4th line there is: dc:am-h264

I think the dc-am is the shorthand for the Kodi Amcodec hardware decoder that interfaces to the VPU.

[j1nx]

For the people that are interested. A snipped from the quick reference manual.

CPU Sub-system
 Quad core ARM Cortex-A5 CPU up to 1.5GHz (DVFS)
 ARMv7 instruction set, power efficient architecture
 32KB instruction cache and 32KB data cache
 512KB Unified L2 cache
 Advanced NEON and VFP co-processor
 Advanced TrustZone security system
 Application based traffic optimization using internal QoS-based switching fabrics
3D Graphics Processing Unit
 Quad-core ARM Mali-450 GPU up to 600MHz+ (DVFS)
 Dual Geometry Processors with 32KB L2 cache
 Dual Pixel Processors with 128KB L2 caches
 Concurrent multi-core processing
 1200Mpix/sec and 132Mtri/sec
 Full scene over-sampled 4X anti-aliasing engine with no additional bandwidth usage
 OpenGL ES 1.1/2.0 and OpenVG 1.1 support

2.5D Graphics Processor
 Fast bitblt engine with dual inputs and single output
 Programmable raster operations (ROP)
 Programmable polyphase scaling filter
 Supports multiple video formats 4:2:0, 4:2:2 and 4:4:4 and multiple pixel formats (8/16/24/32 bits graphics layer)
 Fast color space conversion
 Advanced anti-flickering filter
Crypto Engine
 Supports AES block cipher with 128/192/256 bits keys, standard 16 bytes block size and streaming ECB, CBC and CTR modes
 Supports DES/3DES block cipher with ECB and CBC modes supporting 64 bits key for DES and 192 bits key for 3DES
 Built-in LSFR Random number generator

Video/Picture CODEC
 Amlogic Video Engine (AVE) with dedicated hardware decoders and encoders
 Hardware based trusted video path (TVP)
 Supports multiple “secured” video decoding sessions and simultaneous decoding and encoding
 Video/Picture Decoding
o H.265 HEVC [email protected] up to 1080P@60fps
o H.264 AVC [email protected] up to 1080P@60fps
o H.264 MVC up to 1080P@60fps
o MPEG-4 ASP@L5 up to 1080P@60fps (ISO-14496)
o WMV/VC-1 SP/MP/AP up to 1080P@60fps
o AVS JiZhun Profile up to 1080P@60fps
o MPEG-2 MP/HL up to 1080P@60fps (ISO-13818)
o MPEG-1 MP/HL up to 1080P@60fps (ISO-11172)
o RealVideo 8/9/10 up to 1080P@60fps
o WebM up to VGA
o Multiple language and multiple format sub-title video support
o MJPEG and JPEG unlimited pixel resolution decoding (ISO/IEC-10918)
o Supports JPEG thumbnail, scaling, rotation and transition effects
o Supports *.mkv,*.wmv,*.mpg, *.mpeg, *.dat, *.avi, *.mov, *.iso, *.mp4, *.rm and *.jpg file formats
 Video/Picture Encoding
o Independent JPEG and H.264 encoder with configurable performance/bit-rate
o JPEG image encoding
o H.264 video encoding up to 1080P@30fps

Video Post-Processing Engine
 Motion adaptive 3D noise reduction filter
 Advanced motion adaptive edge enhancing de-interlacing engine
 3:2 pull-down support
 Programmable poly-phase scalar for both horizontal and vertical dimension for zoom and windowing
 Programmable color management filter (to enhance blue, green, red, face and other colors)
 Dynamic Non-Linear Luma filter
 Programmable color matrix pipeline
 Video mixer: 2 video planes and 2 graphics planes per video output

Video Output
 Built-in HDMI 1.4b transmitter including both controller and PHY with CEC and HDCP, 1200p@60 max resolution output
 CVBS 480i/576i standard definition output
 Supports all standard SD/HD/FHD video output formats: 480i/p, 576i/p, 720p, and 1080i/p
 Supports 3D HDMI display

Audio Decoder and Input/Output
 Supports MP3, AAC, WMA, RM, FLAC, Ogg and programmable with 5.1 down-mixing
 I2S audio interface supporting 2-channel input/output
 Built-in serial digital audio SPDIF/IEC958 output and PCM input/output
 Supports concurrent dual audio stereo channel output with combination of I2S+PCM
Memory and Storage Interface
 16/32-bit SDRAM memory interface running up to DDR1600
 Supports up to 2GB DDR3, DDR3L with single rank and LPDDR2, LPDDR3 with dual ranks
 TrustZone protected DRAM memory region and internal SRAM
 Supports SLC/MLC/TLC NAND Flash with 60-bit ECC, compatible to ONFI 2.1 and Toggle 2.0 mode
 SDSC/SDHC/SDXC card and SDIO interface with 1-bit and 4-bit data bus width supporting spec version 2.x/3.x/4.x DS/HS modes up to UHS-I SDR50
 eMMC and MMC card interface with 1/4/8-bit data bus width supporting spec version 4.4x/4.5x HS200 (up to 100MHz clock), compatible with standard iNAND interface
 Supports serial 1, 2 or 4-bit NOR Flash via SPI interface
 Built-in 4k bits One-Time-Programming ROM for key storage

Network
 Integrated IEEE 802.3 10/100/1000 Gigabit Ethernet controller with RMII/RGMII interface
 Supports Energy Efficiency Ethernet (EEE) mode
 Optional 50MHz and 125MHz clock output to Ethernet PHY
 WiFi/IEEE802.11 & Bluetooth supporting via SDIO/USB/UART/PCM
Digital Television Interface
 Transport stream (TS) input interface with built-in demux processor for connecting to external digital TV tuner/demodulator
 Built-in PWM, I2C and SPI interfaces to control tuner and demodulator
 Integrated ISO 7816 smart card controller
Integrated I/O Controllers and Interfaces
 Dual USB 2.0 high-speed USB I/O, one USB Host and one USB OTG
 5 UART, 5 I2C and 1 SPI interface with 3 slave selects
 Five PWMs
 Programmable IR remote input/output controllers
 Built-in 10bit SAR ADC with 2 input channels
 A set of General Purpose IO interfaces with built-in pull up and pull down

System, Peripherals and Misc. Interfaces
 Integrated general purpose timers, counters, DMA controllers
 Integrated RTC with battery backup option
 24 MHz and 32 KHz crystal oscillator input
 Embedded debug interface using ICE/JTAG

Power Management
 Multiple external power domains controlled by PMIC
 Multiple internal power domains controlled by software
 Multiple sleep modes for CPU, system, DRAM, etc.
 Multiple internal PLLs for DVFS operation
 Multi-voltage I/O design for 1.8V and 3.3V
 Power management auxiliary processor in dedicated always-on (AO) power domain to communicate with external PMIC
Security
 Trustzone based Trusted Execution Environment (TEE)
 Secured boot, OTP, internal control buses and storage
 Protected memory regions and scrambled memory data interface
 Trusted Video Path and Secured (needs SecureOS software)



OpenELEC already runs on Almost all Amlogic devices. (Meson3 currently being worked on as back support)
https://github.com/codesnake/OpenELEC.tv

The Amlogic devices are all a little bit different, but a proper Amlogic project folder and devices system is ready at Alex his github account. It is being prepared to be PR-ed to mainline OpenELEC, but they are currrently a bit busy with i.MX6 first. The will look at it after that (I have been told)

[droidelec]

Yes j1nx, yesterday I saw wetek_support added to projects. I think WeTek Play will be first officially supported AMLogic device.

[lrusak]

OpenELEC already runs on Almost all Amlogic devices. (Meson3 currently being worked on as back support)
https://github.com/codesnake/OpenELEC.tv

The Amlogic devices are all a little bit different, but a proper Amlogic project folder and devices system is ready at Alex his github account. It is being prepared to be PR-ed to mainline OpenELEC, but they are currrently a bit busy with i.MX6 first. The will look at it after that (I have been told)

The current challenges with amlogic devices are the fact that each different SOC requires different graphics driver blobs and different kernel configs. This makes it difficult to have many different SOC's in the build system because we don't want to supply 10+ different build of OpenELEC. That would be way too much to maintain.

Currently we are discussing the best way to approach this and when support improves we may take on more SOC's

[j1nx]

@Irusak, thanks for the update.

You are right. With the Amlogic project and "devices" overlay as it is now, you could just choose which devices to support.

And leave any other devices as "unsupported".