• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 116
ODROID C2 S905 2GB RAM HDMI 2.0 $46
#16
Hi guys,

I have a "generic" Android Box running Amlogic s905 chipset and same GPU as the ODROID-C2 specs. Here is my question in regards to firmware (I'm a noob).

Can I flash the ODROID-c2 firmware to my Android box since they have same CPU/GPU? My rationale is that the ODROID community will produce better firmware with this chipset vs the generic chinese manufacturer...

Please say yes it's possible.
Reply
#17
My S905 - ODROID-C2 arrived today, and I've been playing around with Android Lollipop and Kodi, impressions:
  • Fast, snappy AMLogic Android Lollipop device, slightly faster than my S812-H WeTek Core also running Android Lollipop. There really is not much between them in terms of speed tho.
  • No fancy Android Lollipop custom GUI launcher like I see on the Core. That custom, slick WeTek Launcher I really miss !
  • Standard Android type desktop like you see in KitKat 4.4.4. But bigger icons and easier to use with Lollipop OS.
  • Boots to Lollipop desktop in 18 seconds when equipped with Fast eMMC5.0 HS400 Flash Storage Smile
  • Excellent deinterlacing video quality for broadcast TV viewing.
  • 10-bit HEVC decoding, video is output as 8-bit due to lack of Software Support (inc. Kodi)
  • Ethernet Network speeds are impressively fast.
  • 2160p video output at up to 60Hz, in fact you can run the Android desktop or the Kodi GUI at 2160p/60Hz with great fluidity. The S905 upscales the 1080p Kodi GUI to 2160p nicely indeed. Smile
  • If you use the nicely tweaked WeTek Jarvis mediaplayer on the C2 you will get smooth playback of 25fps mpeg2/vob DVD ISO Rips.
  • Standard Widevine Level 3 DRM = 480p Netflix (+ others). Max video output resolution Sad

  • No refresh rate switching is working in Kodi Jarvis or Krypton, both versions need AML mods for the S9xx series of SoC's Sad
  • So consequently 3:2 pulldown judder is the end result with 23.976/24fps video output set at 60Hz, unless you disguise the judder with a TV's Motion Smoothing settings. You may then hate the "Soap Opera Effect" of the resulting video.
  • Kernel is AML / Linux v3.14.29
  • HDMI-CEC control is currently not working
Untested at this stage
  • HD Audio decoding to Multichannel PCM Audio output using the WeTek, Jarvis mediaplayer
Android Lollipop on the S905 has an interesting Android - Setting > Playback Settings > HDMI Self Adaptation > On/Off
This seems to be the equivalent of the completely user transparent, S8xx's Kernel Frame Rate Automation to produce smooth 23.976fps video output. Its basically a Frame Rate Automation On/Off switch.

The other point of interest is I can watch 25/50fps broadcast TV at 60Hz Kodi GUI (no refresh switching) with no noticeable video stutter or massive judder with my TV's motion smoothing settings on Low.

Conclusion, a nice fast little upgrade to the C1+ if you need 10-bit HEVC decoding and 2160p @ 60Hz video output. The optimisations in the ART Runtime code contained in the Android Lollipop OS on a C2 / S905 make a noticeable difference. Kodi Krypton / Jarvis, the WeTek version especially runs smoothly.
You will also get half decent S905 Firmware support from HardKernel themselves. There is a healthy, knowledgable Linux community built around HardKernel products that definitely helps as well Smile

Coming down the Pipe, OE 6.95.9 / Kodi Jarvis for the C2


@runnerway,
mpeg2/vob 25fps movie DVD Rips play fine in the WeTek Jarvis mediaplayer, if you select Software Deinterlacing in the Video OSD (save as default). WeTek's modded Jarvis defaults to ff-mpeg2 Software decoding for vob's only.
Consequently normal am-mpeg2 used for Live TV playback remains unaffected. Its seamless Smile

@asipsis,
Probably not as there is a custom U-Boot and AML Kernel in the C2. You can only try it I suppose, but you may brick the box or stuff will not work. You may get lucky who knows.

Reply
#18
Sounds very encouraging wrxtasy. Though why you'd want to watch 50Hz at 60Hz with motion smoothing beats me. Mangling the picture twice rather than not at all... Wink

10 bit HEVC decode + 2160/60p output on a US$40 board is a pretty amazing spec. I'd love to try this with a DVB-S2 receiver and see what it does with the HEVC UHD test transmissions we have in Europe (and my off-air World Cup and Commonwealth Games recordings made from the BBC DVB-T2 broadcasts in 2014)
Reply
#19
25/50fps at 60Hz is an acceptable, viewable, workaround until AML Kodi refresh rate switching is fixed for S9xx devices. The results were very surprising !

I have a bunch of 2160p / 10bit HEVC test clips.
Just found the 10-bit HEVC 2160/50fps Astra-SES_Demo_UHD_satellite_end-of-2015 clip. Playing that in Kodi produces the predictable green/pink color banding, I'm surmising due to the due to lack of 10-bit video output from Kodi.

Another Astra 10-bit HEVC 2160/50 clip of a City and Tropical beach looks very nice tho, without blocky artifacts or banding.

Will have to find a AML 10-bit video output, player to really test properly.

Big Buck Bunny: 8-bit H264 2160/60p will not play properly, I'm wondering if 2160p 50/60Hz is limited to HEVC only ?
Or amcodec spits the dummy at Variable Bitrate H264 video.

Reply
#20
(2016-02-08, 12:33)wrxtasy Wrote: Untested at this stage
  • HD Audio decoding to Multichannel PCM Audio output using the WeTek, Jarvis mediaplayer
Android Lollipop on the S905 has an interesting Android - Setting > Playback Settings > HDMI Self Adaptation > On/Off
This seems to be the equivalent of the completely user transparent, S8xx's Kernel Frame Rate Automation to produce smooth 23.976fps video output. Its basically a Frame Rate Automation On/Off switch.
Multichannel PCM test would be interesting. On Minix U1, it is just stereo output. In fact, XBMC for Minix (beta2) doesn't even have the option to select # of channels. All multichannel PCM is set to be transcoded to AC3. Selecting more than 2 channels in regular Kodi will freeze the box requiring a reboot.

Do you see two levels of self adaptation? 1 - for 3:2 pulldown, 2 - matches the frame rate of the content

(2016-02-08, 13:05)wrxtasy Wrote: 25/50fps at 60Hz is an acceptable, viewable, workaround until AML Kodi refresh rate switching is fixed for S9xx devices. The results were very surprising !
It does switch on Minix U1 via self adaptation, but some users are reporting issues with 4K 25Hz on Samsung UHD TVs.
Reply
#21
Any progress on 3D MVC?

Thanks!
MY CURRENT MEDIA PLAYER | MY HOME THEATER
MINIX NEO U22-XJ COREELEC v19 MATRIX | EGREAT A10 | NVIDIA SHIELD | LG 75 NANO90 DV/HDR+ | Sony 43 Android TV HDR
XBOX SERIES X  | PS4 PRO 4K | JBL 9.1 System 5.1.4 DTS:X/ATMOS 
Reply
#22
(2016-02-08, 20:27)movie78 Wrote: Any progress on 3D MVC?

Thanks!


Doubtful yet, I think the best bet is the kodi apk in the s905 thread for at least proper MVC 3d playback even if it's not frame packed until koying puts out a newer spmc build which might be on its way soon looking at his github. Problem is all the hd audio stuff they all look to be working on, maybe when they get that sorted it'll make more sense to put out a release.
Main System - HTPC - Intel I3 6300 - Asrock z170 - 16 GB DDR4 - 128gb SSD - 65" UHD HDR Sony Android TV - Pioneer VSX 1130-K - 7.2.2 speakers
Other devices currently in use - 55" 3D UHD LG TV - 2 Fire TV's - Nexus Player - MiniMX s905 - Voyo Vmac Mini
Ubuntu Server - 12 TB NAS - MYSQL - Torrent Box
Reply
#23
Hope we will have a stable openelec on it.
can't wait to buy it!
Reply
#24
At wrxtasy's request, a cross post from a point I made in the Wetek Core thread (when asked whether a C2 would be a better bet than a Core)

Quote:Yes - it has taken the C1/C1+ a long time to become a decent media player, and it has been out for a while now. There were a number of show-stopping bugs that took a long time to iron out, due to the limited dev effort and experience. (The most obvious was the major HDMI clock issue that meant you couldn't use your C1 with many AVRs as they suffered continuous video drop outs, and even without an AVR you got sound drop outs)

I suspect that we may have new issues with the C2 SoC (S905) that could take a while to find and fix, particularly as it is a move from 32 bit to 64 bit ARM architecture, which is quite new to the scene.

The thing that worries me the most about the C2 is the very old kernel that is being deployed with it. 3.14 LTS was released in March 2014, and ceases to receive long term support in August 2016 (i.e. 6 months time)

3.14 LTS is the 12th LTS kernel release, but the most recent is 4.4 LTS, which is the 15th LTS release and supported until Feb 2018.

I know there are reasons for kernels for some platforms to lag behind the current releases, but 3.14 is looking quite elderly, and will increasingly limit the platform. It's interesting to compare to the Raspberry Pi 2 - which is keeping pretty much up to date with the kernel releases it appears?

This isn't esoteric navel gazing either - a kernel this old will not include support for newer peripherals, like recent WiFi and DVB adapters. You are then at the mercy of being able to build and back port drivers to the kernel yourself, or rely on others to build things for you. wrxtasy does a splendid job with his OE builds, but if you want to run odroibian or other general linux distros, it all gets boringly hard very quickly when compared to x86 or the Pi 2 platform. (But not as bad as some of the dreadful Allwinner stuff... <shudder>)
Reply
#25
Thanks Smile

Yes agreed with everything written. Its taken about a year to finally have me satisfied that the old C1+ is at a stage with OpenELEC that I'm 95% happy. The very recent GPU drivers fix was a very welcome and long overdue patch for all S8XX AML OE platforms to fix the Kodi GUI tearing.

For AML platforms that have integrated WiFi, BT and IR and are primarily used as Android devices like the WeTek Core an old Linux Kernel does not present much of a problem. But once you start selling a device like a C2 as a Linux development board, yep an old Kernel will become a issue down the track. This is squarely AMLogic fault I believe as it looks like they release a combined Android / Linux Kernel to every AML developer (Codesnake please correct anything here)

Back to the C2 Kernel, I found this topic of conversation very interesting regarding AMLogic Kernels vs the RPi2:
Popcornmix may want to chime in.

http://forum.odroid.com/viewtopic.php?f=...50#p125310

crashoverride Wrote:
rooted Wrote:I don't know of any Arm device other than Raspberry running a 4.y.y based kernel.
That actually made me stop and think for a bit about how the Raspberry Pi runs 4.x.y ...

The RPi is actually a VideoCore 4 processor with an ARM co-processor. The VC4 part runs a closed source OS (TreadX, IIRC) that controls the board and then enables the ARM co-processor after booting. The ARM co-processor passes messages back and forth through a mailbox to the VC4 OS. Since the ARM part is just a co-processor, its far more trivial to port newer kernels to it.

With that in mind, we should be able to do the exact same "trick" on Odroid C2. We can boot the board with a XEN hypervisor and run a hardware accelerated VM with a mainline Linux kernel.

Reply
#26
(2016-02-17, 15:22)wrxtasy Wrote:
crashoverride Wrote:
rooted Wrote:I don't know of any Arm device other than Raspberry running a 4.y.y based kernel.
That actually made me stop and think for a bit about how the Raspberry Pi runs 4.x.y ...

The RPi is actually a VideoCore 4 processor with an ARM co-processor. The VC4 part runs a closed source OS (TreadX, IIRC) that controls the board and then enables the ARM co-processor after booting. The ARM co-processor passes messages back and forth through a mailbox to the VC4 OS. Since the ARM part is just a co-processor, its far more trivial to port newer kernels to it.

With that in mind, we should be able to do the exact same "trick" on Odroid C2. We can boot the board with a XEN hypervisor and run a hardware accelerated VM with a mainline Linux kernel.

That is not very accurate. The VC4 firmware acts more like uboot than the linux kernel. It does some one time initialisation, like enabling sdram, starting clocks, enabling power domains to allow linux to boot, but linux runs just like on any other platform. If you are not actively using GPU features you can even crash the GPU and be completely unaware. The arm and linux will happily carry on running.

The reason the newer linux kernels run on it, is because each time a kernel revision comes out, I rebase onto it, fix merge conflicts, test it, fix any issues that have arisen, push it out to testers (e.g. Milhouse builds here, and "BRANCH-next rpi-update" for general linux users) and try to fix any issues that are reported in testing. Eventually we bump the stable kernel. The work required is by no means trivial.

If you like bleeding edge, the latest 4.5-rc4 kernel is here.
Reply
#27
(2016-02-17, 15:22)wrxtasy Wrote: Thanks Smile

Yes agreed with everything written. Its taken about a year to finally have me satisfied that the old C1+ is at a stage with OpenELEC that I'm 95% happy. The very recent GPU drivers fix was a very welcome and long overdue patch for all S8XX AML OE platforms to fix the Kodi GUI tearing.

For AML platforms that have integrated WiFi, BT and IR and are primarily used as Android devices like the WeTek Core an old Linux Kernel does not present much of a problem.
Until you run Linux on the Core - which is what we do with OpenElec. Adding USB peripherals to the Core, like the C1+ and C2, will require recent drivers in many cases. It's fine for a 'sealed box' approach - but not everyone wants that.

Quote:But once you start selling a device like a C2 as a Linux development board, yep an old Kernel will become a issue down the track. This is squarely AMLogic fault I believe as it looks like they release a combined Android / Linux Kernel to every AML developer (Codesnake please correct anything here)

Precisely.

Quote:Back to the C2 Kernel, I found this topic of conversation very interesting regarding AMLogic Kernels vs the RPi2:
Popcornmix may want to chime in.

http://forum.odroid.com/viewtopic.php?f=...50#p125310

crashoverride Wrote:
rooted Wrote:I don't know of any Arm device other than Raspberry running a 4.y.y based kernel.
That actually made me stop and think for a bit about how the Raspberry Pi runs 4.x.y ...

The RPi is actually a VideoCore 4 processor with an ARM co-processor. The VC4 part runs a closed source OS (TreadX, IIRC) that controls the board and then enables the ARM co-processor after booting. The ARM co-processor passes messages back and forth through a mailbox to the VC4 OS. Since the ARM part is just a co-processor, its far more trivial to port newer kernels to it.

With that in mind, we should be able to do the exact same "trick" on Odroid C2. We can boot the board with a XEN hypervisor and run a hardware accelerated VM with a mainline Linux kernel.

Yes - I'm not au fait enough with kernel development to comment. How the Pi / Pi 2 are keeping up when other ARM platforms aren't (x86 boxes are) doesn't massively worry me, and it will be great if other platforms can use whatever approaches the Pi is using to stay up to date.
Reply
#28
(2016-02-17, 15:40)popcornmix Wrote:
(2016-02-17, 15:22)wrxtasy Wrote:
crashoverride Wrote:That actually made me stop and think for a bit about how the Raspberry Pi runs 4.x.y ...

The RPi is actually a VideoCore 4 processor with an ARM co-processor. The VC4 part runs a closed source OS (TreadX, IIRC) that controls the board and then enables the ARM co-processor after booting. The ARM co-processor passes messages back and forth through a mailbox to the VC4 OS. Since the ARM part is just a co-processor, its far more trivial to port newer kernels to it.

With that in mind, we should be able to do the exact same "trick" on Odroid C2. We can boot the board with a XEN hypervisor and run a hardware accelerated VM with a mainline Linux kernel.

That is not very accurate. The VC4 firmware acts more like uboot than the linux kernel. It does some one time initialisation, like enabling sdram, starting clocks, enabling power domains to allow linux to boot, but linux runs just like on any other platform. If you are not actively using GPU features you can even crash the GPU and be completely unaware. The arm and linux will happily carry on running.

The reason the newer linux kernels run on it, is because each time a kernel revision comes out, I rebase onto it, fix merge conflicts, test it, fix any issues that have arisen, push it out to testers (e.g. Milhouse builds here, and "BRANCH-next rpi-update" for general linux users) and try to fix any issues that are reported in testing. Eventually we bump the stable kernel. The work required is by no means trivial.

If you like bleeding edge, the latest 4.5-rc4 kernel is here.

Thought so. No smoke and mirrors. No shortcuts. You're just putting the work in that other ARM platform developers aren't...
Reply
#29
Agreed with Popcornmix, its not trivial work at all, and for that I hope he is getting paid by the RPi foundation.

I believe Intel employ a whole army of devs just for Kernel work alone.

Reply
#30
(2016-02-17, 15:50)wrxtasy Wrote: Agreed with Popcornmix, its not trivial work at all, and for that I hope he is getting paid by the RPi foundation.

I believe Intel employ a whole army of devs just for Kernel work alone.

Which begs the question, why aren't AMLogic... If it's just because they can save the money and continue to release new Android builds based on old kernels, they will presumably hit a point where they need to move to a newer kernel. (3.14 LTS only has 6 month of LTS left after all...)
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 116

Logout Mark Read Team Forum Stats Members Help
ODROID C2 S905 2GB RAM HDMI 2.0 $4610