CSC Armbian for RK3288 TV Box boards (Q8)

Recommended Posts

DISCLAIMER (PLEASE READ): everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware.

Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related).

Thank you!

This is CSC Armbian for XT-Q8L-V10 boards, also known as Chiptrip Q8, Vsmart Q8, ENY 3288 Q8, etc...

This way even if you install armbian to internal eMMC, you can still easily test different images booting from external devices.

Experts notes: when armbian is installed into eMMC you get U-boot installed too in eMMC. This is important to know because the box won't boot in Maskrom Mode, but instead will always boot the embedded U-boot, no matter if you put an sdcard/usb stick. In practice the embedded U-boot is totally responsible for the boot priority. If you want to restore the Maskrom Mode, just erase U-boot from eMMC using this command:

dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=8128 conv=sync,fsync

Current status:

Wireless: works. pretty fast and stable, signal is strong on my box;

Bluetooth: works. I was able to transfer files and stream audio without problems

USB ports: works, with autosuspend too. A quick benchmark show that transfer rate is quite good (topped at 34 MB/s)

USB OTG: works in host mode. Transfer rate is very good (> 40 MB/s)

MMC: works and is perfectly accessible as storage device. The images above with "eMMC friendly" have been tested and work when installed in eMMC using the standard armbian-config eMMC installer

SDCard: works. legacy kernel is limited to high speed, while mainline works fine in UHS mode too. A quick benchmark with a Samsung EVO card shows the promised 48Mb/s read speed.

Gigabit Ethernet: works, fast and reliably

HDMI: works but may have some minor quirks. Sometime happens that you get a purple vertical line at the very left side of the display or the audio via HDMI does not work. Usually turning off and on the monitor solves both the problems.

Serial: works

Audio: both HDMI audio and SPDIF connector works

IR remote: works on legacy and mainline kernels

Reboot/Suspend process: rebooting the device is a working in progress, at the moment sometimes it works and sometimes it doesn't. Suspend is still not available.

Hardware acceleration: everything which works for rk3288 boards applies here too. This guide or maybe the Media Testing Script will help you gain an hardware accelerated X11 and Chromium (using GL4ES I enjoyed Quake 2 from the start till the end, but also Quake and Quake III Arena work flawlessy, here a quick how-to to compile and install GL4ES)

Share this post

Link to post

Share on other sites

This guide describes how to erase the internal eMMC memory. This won't brick your TV Box, instead will force it to boot from the SD Card. Also I give some steps to backup and restore the original firmware in case you want to restore the original functionality.
The tool used here is rkdeveloptool, which is opensource and is available cloning or downloading the armbian rockchip-linux rkbin github repository mirror

Get into rockusb mode:

Getting into rockusb mode is essential to do anything else

1) plug the power cord inside the device

2) push the Reset button and keep it pushed while plugging the USB cable into the OTG port

I updated the firmware for Debian for SD-card. I made it possible to run MPV with hardware decoding h264, h265, according to the message of JMCC. Here is used DHD wi-fi driver. In my opinion, it works at a higher speed than brcmfmac. And with the reboot there seems to be all right.

Update:

I also noticed that when the OTG cable is connected to the computer, Armbian Ubuntu begun rebooted after selecting the reboot command from the menu.

Share this post

Link to post

Share on other sites

Thanks for the corrections to the device tree. I integrated most of them into the dts and I will publish them as soon as possible. At the moment I'm having problems compiling a working kernel because of some recent changes to the rockchip codebase which are producing non-booting kernels and I can't verify if everything is in place :/

I'm a little confused about the i2c5 bus, which is working pretty fine to me. I don't get any timeout message in dmesg and there shouldn't be any: all the rk3288 boards I viewed so far use the i2c5 bus for the HDMI DDC feature.

Maybe you are having issues with your monitor due to some misconfiguration or malfunction of that? In which case I'm not sure changing i2c5 to i2c4 is a good idea for two reasons. The i2c4 bus currently hosts the rk1000 on some addresses, and also I think the DDC feature is hardwired to the i2c5 bus and we, in the device tree, are just informing the linux driver of that.

Does it work changing i2c5 to i2c4 for you, or you just don't get the timeout messages?

About the OTG cable, you should not use it anymore, I finally found the power hold GPIO which keeps the act8846 powering the board. Nonetheless I noticed the same behaviour you describe: reboot does not work but if I keep the OTG cable connected to the computer reboot works.

Strangely enough, in the system has appeared i2c6 to the address 0xff980000 (HDMI)
And also there are contacts on the ports of interest!

But it is impossible to obtain EDID information.

I also have the MK809-4K on RK3288 chip. I drew attention to the fact that it initially selects the correct mode of HDMI for 1920x1080. Therefore, I also checked the configuration # 3 on it. And it was possible to successfully read the EDID:

So EDID works fine on my box using i2c5. I get devices at addresses 37 and 50 as you described and get-edit tool works fine. Also data is correctly reported (display name, modelines, etc...)

The i2c6 bus appearing in your test can be probably explained taking a look to the kernel documentation. I found this in the device tree documentation:

Quote

- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master
or the functionally-reduced I2C master contained in the DWC HDMI. When
connected to a system I2C master this property contains a phandle to that
I2C master controller.

so that bus is directly embedded into the HDMI controller and spawns up when there is not a master i2c bus for EDID, which is what you did removing the line from the device tree. From what I understand, that works but is suboptimal. To satisfy my curiosity I will try swapping the buses to see what happens. In the meantime you may do tests with another HDMI cable, it is quite common that faulty or cheap cables causes many kinds of issues (HDMI CEC not working or working intermittently for example...)

Share this post

Link to post

Share on other sites

Maybe you can try swapping your dtb file with the one supplied in one of the images above or just try any of them. You will lose some peripherals, but at least you can understand if it is just a hardware description problem or something more serious.

edit: also, reading from the rk3288 datasheet I understand that i2c bus at address 0xff170000 is the bus designated for HDMI DDC, so there are no chances to change it in the device tree

I did not test it, just found it in rk3288-veyron.dtsi device tree from u-boot﻿

Thanks, jock. Unfortunately, this did not change the situation.
I also tried to increase the frequency on i2c5 to 400 KHz - there were no messages about the timeout, but on the whole, nothing has changed dramatically.

Share this post

Link to post

Share on other sites

I didn't try yet to do some tests with the eMMC, mostly because mainline u-boot does not support rockusb protocol, which is very useful in case something goes wrong. It allows the communication via OTG USB port and the rkdeveloptool, which can program the eMMC from a normal computer. In theory it is not possible to brick the box, in pratice a mistaken action may cause the boot loader to stay stuck without the ability to activate the maskrom mode without a manual intervention consisting in shorting the clock pin of the eMMC on the board with ground, which I want to avoid at all costs for obvious reasons

Rockchip's u-boot fork has rockusb mode, but has to be enabled in configuration and compiled by hand. That would be a good starting point. rkdeveloptool can upload the bootloader and can also program the eMMC bootloader part which is normally protected.

By the way, a serial port connected to the headers on the board is a must have if you want to do such experiments because I think that most of the soup is just convincing u-boot to boot from the eMMC

edit: in the guide to erase/backup/restore flash above you can see, in the restore paragraph, how to use rkdeveloptool to upload the bootloader to the box (db command), and program the eMMC bootloader sectors (ul command)

Share this post

Link to post

Share on other sites

@Exellent Finally I had the time to do some tests with the eMMC and it looks like everything works pretty fine.

I changed the boot order of U-boot, so the priority is always the external sd card, then the USB stick and finally the eMMC, so even if the image is installed in embedded memory, it should be always possible to run newer images using an external sdcard. Still there is no rockusb nor fastboot, so it is wise to experiment only if you have access to the serial console.

I added a new image to the first post with "eMMC friendly" tag, if you want to give it a try. Just burn the image on a sdcard and then use armbian-config to install the system into the eMMC

Share this post

Link to post

Share on other sites

@jock very cool, I'll give it a try tonight. The reason for emmc, is that (It might be) faster than eaven the class 10 sd Card. And the Board [Which i pulled from our makerspaces junk] is modded. There is a 32Gb flash chip instead of the 8gb on it. don't aks me how or who it did :D But It would be extremely usefull if work's. But another question; which bootloader [U-Boot ] do u use and where to find it?

Share this post

Link to post

Share on other sites

@jock very cool, I'll give it a try tonight. The reason for emmc, is that (It might be) faster than eaven the class 10 sd Card. And the Board [Which i pulled from our makerspaces junk] is modded. There is a 32Gb flash chip instead of the 8gb on it. don't aks me how or who it did :D But It would be extremely usefull if work's. But another question; which bootloader [U-Boot ] do u use and where to find it?

Ahah cool :D If the job is well-done, it should indeed work flawlessy ;)

U-boot is the very standard mainline u-boot that the Armbian build system clones from the official github repository.

At the moment Armbian uses the version tagged with v2017.11, plus there are some patches that include include the configuration files and device trees for our tv box. You may check it out looking to the github repository in the first post, just follow the official armbian instructions to build u-boot, kernel or armbian images if you want to experiment ;)

Both new images now fully support the IR Remote out of the box, in native mode via kernel keymappings and drivers. Kernel keymap table can be customized using ir-keytable tool. Kernel 4.18.6 also exposes the native lirc interface, so in theory any remote controller can be trained to work with the box

Both new images enables the SPDIF connector (it is untested though due to lack of a Optical DAC at home)

Added devfreq support for the GPU: at the moment the base frequency is 100 Mhz and maximum frequency is 600 Mhz. The GPU may be too lazy to switch frequency, so you can force a minimum frequency issuing (as root) echo300000000 > /sys/class/devfreq/devfreq0/min_freq to force the pre-devfreq default operating frequency. You may also force 600000000 (600 Mhz) as minimum to run the GPU always at full speed. Beware the thermals anyway, when the core reaches 70°C it starts throttling and your performance may not be as you expect if you don't cool enough the SoC

Every other thing which has been put into Armbian lately is also in the images

Share this post

Link to post

Share on other sites

I tested the 4.18.6 image. Unfortunatelly the kernel did not detect mmcblk0 (sdcard) leading to "gave up on waiting for root device". But I could change the root_dev to an usb stick in the config fiiles to boot sucessfully but still without access to the sdcard.

The 4.14.68 works. But after installing to eMMC via armbian-config it does not boot without the sdcard.

Share this post

Link to post

Share on other sites

I see that your board is a tiny bit different than mine. Mine has XT-Q8L-V10, instead yours is ENY-Q8L-V10. Yours has a frontal LCD panel connected to the board header, instead mine has just the IR remote and a red/blue LED.

I think a dmesg log would clarify the mmc device block names. Actually I had no idea on how kernel assigns names for the different devices.

On my setup mmcblk0 is the external Sdcard and mmcblk2 is the internal eMMC. I should normalize this, like mmcblk0 for the eMMC and mmcblk1 for the external SD.

Share this post

Link to post

Share on other sites

With the mainline image it is the same for me. I will post the dmesg of mainline-dev as soon as i have time.

Do you have an idea why the emmc doesnt boot after installing with armbian config?

Do I have to restore uboot manually?

u-boot has its own device mapping and, on my board, u-boot detects the device in reverse order (sdcard has index 1 and mmc has index 0).

I thought it was something common for our boards and not to be worried, but probably it needs to be fixed.

About not booting from eMMC, I have no clue at the moment. Unfortunately no video output during boot makes hard to guess what happens if you don't have a serial port, I'm working on it but it is a bit hard to sort it out :/

edit: mainline-dev actually installs and boots fine on my board, but occasionally it turns off during kernel bring up. Using the serial I see that it is something which happens during the initialization of the sdcard controller and its vcc regulator:

Share this post

Link to post

Share on other sites

thank you. Thats what I realized a moment ago when i tried to plug in my headphones

I want to use the box for making music with zynaddsubfx. The optical spdif port seems to be the right choice. Right now I think of getting the ZHILAI H3. Its a cheap cs4344 based dac and can be powered via usb. If it is too noisy or distorted, I switch to an edirol audio interface.