OpenHour Chameleon

[deconst]

deconst I have now also running Armbian on my Chameleon, will sound work on yours? On my it won´t work. It seems that the soundchip are not avalible. I also can´t find any setting where i can select something.

Hey! I spent the New Year's break working on this so I may singularly be the best person in the planet right at this moment to answer this question. Thanks for showing interest!

The Miqi builds - that we're using for Open Hour - don't have sound because the description of the sound device is missing from the Miqi's devicetree settings. I recently made a submission to the Armbian Git repository to add this node back in, and sound works again: https://github.com/armbian/build/com...c5efa0e924b9ed
.
(Side note: this is why I really like Armbian, the project maintainers readily accept patches directly to the master branch if they are narrow enough in scope)
.
You can compile a new kernel to add sound to your existing deployment, the Armbian Build system makes it very easy. Note that you have a high chance of causing a boot failure with the Openhour, due to its 'unbrickable' architecture. I recommend compiling a new image on an x86 machine and testing it on a spare SD card before trying it on your existing system:

git clone https://github.com/armbian/build.git
cd build
sudo bash compile.sh

Navigate through the build options:

• Full OS image for flashing,
• Do not change the kernel configuration
• Show CSC/WIP/EOS/TVB
  • Accept the warning
• Miqi: EOS: Rockchip RK3288 quad core 2GB SoC GBE
• dev: Development version (@kernel.org)

The last option is your desired flavour of OS. I like Ubuntu Groovy 20.10, because it has sufficiently recent libraries in its repository for compiling and building projects from Github.

Also Youtube videos are stuttering.

Yes, Firefox can't use hardware decoding so it falls back to the CPU, and the poor little A17 cores can't keep up.

The problem is that the Verisilicon Hantro H1 VPU driver in the 5.10.y kernel only supports stateless decoding but the VA-API (libva) video hardware acceleration API for Linux used by Firefox and other browsers doesn't.

Here are some good introductions to the problem space:

• https://bootlin.com/pub/conferences/...h-mainline.pdf
• https://www.cnx-software.com/2020/11...ainline-linux/
• https://www.youtube.com/watch?v=ETxFvC9Wry0

You may see a 'llibva-v4l2-request' project and I had a good look at all its various forks and branches but nothing works with the 5.10.y kernel. VA-API presents hardware decoding entrypoints to applications like Firefox but no entrypoints emerge even though LibVA tells you it's using the driver. All the boffins who understand this stuff have moved on to Video4Linux 2, which offers video hardware acceleration directly in the kernel.

The mpv that comes with Groovy 20.10 can use V4L2 stateless decoding so you can watch H264 encoded movies fine. Experienced users here could probably do a Kodi spin on the Armbian build which would unlock Linux 5.10 for most Rockchip boxes. Many are still on the 4.4 kernel because the proprietary blobs use that kernel. Modern kernels use the ARM CPUs better though.

There are many, many TV boxes that use the Hantro H1, it's in most Rockchips (RK3288, RK3328, RK3399, PX30, RK1808) and NXP (i.MX 8M Mini).

There are whispers of a Chromium build that supports Gstreamer, and a Gstreamer driver for the Hantro H1. If you get your Chromium-based browser to support H264 hardware decoding, then the 'h264ify' extension will force Youtube to present videos in H264 instead of VP9. My attention to this project has been exhausted, for now, so this is a good place for you to pick this up.

For the latest in VPU support development, see https://forum.armbian.com/topic/13622-mainline-vpu/

For what exactly do you use the box?

The Openhour Chamelon box is beautiful: its entire shroud is the heat sink and it comes with just the essentials: RK3288, 2GB, GbE, HDMI 2.0, 3 USB2 ports, MicroSD card. Its 'unbrickable' SD card architecture takes a little bit of getting used to, but that's a solved problem using the Miqi config in the Armbian distro, and it makes development extremely easy. No worries about flashing chips and bloody JTAG/Serial recovery.

I wanted to use it as a Moonlight client to play Cyberpunk 2077 on the big screen but without VA-API I have to fall back to a hot and loud old laptop. I have thought of setting it up as a home server but the gigabit ethernet issues have put that to one side for now.

I may come back to this when browsers and moonlight catch up with supporting Video4Linux 2, Gstreamer and stateless decoding, or the Hantro VPU driver is rewritten to somehow make stateful decoding possible.

Here's a broad idea of the current state of the Openhour with the Armbian miqi 5.10.y dev trunk:

• Gigabit Ethernet is highly questionable. This is one of two off-SoC chips in the Openhour Chameleon, which uses the RTL8211E. 100Mbit is solid. Gigabit needs hardware clocking but..
• Hardware clocking is (I think) non-functional. The Miqi Armbian config specifies the hardware clock as hym8563 which (I think) is the other off-SoC chip and the Openhour uses something else. No clue what that chip is. If we solve this, we can probably add it as a separate RK3288 TV box device configuration to Armbian like the XT-Q8L-V10.
• GPU works okay. Panfrost still crashes occasionally but it's usable. You can play Supertux! I was getting 45 fps+ PS3-level 3D quality! Turning on dynamic lighting crunches everything to a 9 fps grind but watch this space for improvement over the next 12 months. I captured a video but I don't know how recordmydesktop works so the colours are bad. The colours are fine in person though. https://youtu.be/13j16Sol3Ps
• VPU is barely functional, as above. H264 only. You can get ffmpeg & mpv going. HEVC should one day be supported but further development of the kernel driver appears to be at a standstill. RK3288 does not support VP9 hardware decoding.
• HDMI sound as above. Armbian does all the Pulseaudio config for you, which is a nice touch.
• HDMI CEC is untested. It will probably need some devicetree patches brought across from the Armbian Tinkerboard configuration.
• IR is untested. There is no GPIO mapping for the Openhour remote, but one could probably be ported from the XT-Q8L-V10. I bought the USB Airmouse from Syabas though so I don't really use the remote.
• Bluetooth and Wifi through generic dongles should work fine. I have tested USB audio.
• Widevine DRM, required to access paid streaming services like Netflix, can be extracted from a Chromium OS image.
  • See the last script at https://gist.github.com/avanvucht/e4...3e7805a8859034
  • This requires Vivaldi, but Vivaldi has a conflict with the libc that I'm using. I run vivaldi with vivaldi-snapshot --disable-seccomp-filter-sandbox
  • Pointless without hardware decoding.
  • This is the sole advantage of RK3288 over RK3399, because there are Widevine DRM blobs for ARM 32-bit (armhf) but not for ARM 64-bit (arm64).
  • (Rant) The Mozilla Foundation embraced the Widevine DRM but they consider ARM as low-tier architecture. They really need to pull their thumb out and get Widevine DRM for going for ARM, and direct V4L2 support while they're at it.

Pretty good for a product abandoned by Syabas immediately on release.