rk3288 alternative boards (cheap tv boxes).

[debianxfce]

9 hours ago, James Kingdon said:

.If you have a large number of independent jobs then more cores work well (provided there's sufficient total memory bandwidth), but that tends to be more a server style of workload than a typical SBC case. Of the 8-way boards, the NanoPi M3 works the best for me so far, as long as I can stay within the 1G ram budget. Can't wait to get that running 64 bit.

The chromium browser uses all 8 Amlogic S912 cpu cores when playing youtube video. That is a good thing for home users when you do not have gpu accelerated graphics driver.. Iceweacel/Firefox is a piece of shit when it tries to play youtube video.

[James Kingdon]

6 minutes ago, debianxfce said:

The chromium browser uses all 8 Amlogic S912 cpu cores when playing youtube video. That is a good thing for home users when you do not have gpu accelerated graphics driver.

Good point, that's a pretty good use case.

[chrisf]

On 7/12/2017 at 6:54 PM, debianxfce said:

 

So one test at cnxsoft says. But in a real work 64-bit and 2x more cores is faster with Linux, because symmetric multitasking and memory use. I did buy some rk3xxx quad core tvbox over year ago and returned it, because it could boot only 2 of 10 times. It was very expensive then, over 100 eur.  Also it is easy to make Debian testing Xfce work with Sunvell T95Z Plus. 

The the real world the S912 has 4 A53 cores up to 1.536GHz and 4 cores up to 1.0GHz. The 64bit only really gives you double the CPU registers. It adds a memory capacity and bandwidth overhead though.

 

I would pick an A15/17 over an A53 any day. The A57 is similar in performance to the A17 but it takes up a lot more die space, so chip makers didn't really focus on it.

The A53 was designed with performance-per-watt in mind, not performance-per-clock. It was supposed to be the "LITTLE" in a big.LITTLE SoC along side A57 cores.

 

[James Kingdon]

17 hours ago, chrisf said:

The the real world the S912 has 4 A53 cores up to 1.536GHz and 4 cores up to 1.0GHz. The 64bit only really gives you double the CPU registers. It adds a memory capacity and bandwidth overhead though.

Ah, forgive me for joining both sides of the argument...

 

Double the cpu registers is good, the fact that those registers are 64 bits wide instead of 32 bits also helps dramatically if the application is dealing with 64 bit data, and it also brings the newer instruction set. All of those things together will often add up to 20 to 40% performance boost on the same hardware (i.e. switching from 32 bit userspace to 64 bit), and sometimes substantially more. The A53 core is pretty good, and I think once we see more use of aarch64 it will become better appreciated (which is not to say I wouldn't be happy with a bunch of A75 cores either). Even in 32bit mode a good 8 way A53 soc can hold it's own with A17 cores in terms of max throughput (i.e. when all cores can be kept busy). A standard test case I use runs about 40% faster on a NanoPi M3 than on a UGOOS UT3S, and 10% faster than an XU4. As another example, checkout the M3 on the John the Ripper benchmark:

You can see more benchmarks from this comparison here: http://openbenchmarking.org/result/1707120-TR-1703199RI54&obr_sor=y&obr_sor=y&obr_hgv=NanoPi+M3+32bit

I only ran the M3 results, the other results were merged in from previous peoples work.

 

As is typical with performance discussions, there's an awful lot of "it depends" involved. A small number of faster cores is often easier to get max performance out of. Some applications are well suited to running on a larger number of cores, some applications devolve into a memory bandwidth test. And sometimes performance per watt or performance per $ is more critical than absolute max throughput.

[Myy]

While having more than 1KB of storage in registers is extremely valuable,  don't you lose cache capacity if you have to encode addresses on 64 bits ? Not counting the fact that data structures that fit well in 32 bits might fit very badly in 64 bits, due to bad padding. Thanks to the x86-64 architectures, most data structures are optimized for 64 bits. That said, in cases where the data structures have been optimized for ARM32, this can also have an impact on the data cache.

Anyway, if you have to encode addresses on 64 bits, you'll have more data cache pressure if memory pointers are abused, as it's the case with a lot of tools.

 

Also, GCC had a bad reputation regarding optimized ARM code generation, and I'm wondering if the new GCC and CLANG (which should be very ARM oriented, due to Apple current hardware alignments) can generate code that take profit of all the features of this new architecture.

 

[debianxfce]

On 14/07/2017 at 6:03 PM, James Kingdon said:

Ah, forgive me for joining both sides of the argument...

 

Double the cpu registers is good, the fact that those registers are 64 bits wide instead of 32 bits also helps dramatically if the application is dealing with 64 bit data, and it also brings the newer instruction set. All of those things together will often add up to 20 to 40% performance boost on the same hardware (i.e. switching from 32 bit userspace to 64 bit), and sometimes substantially more. The A53 core is pretty good, and I think once we see more use of aarch64 it will become better appreciated (which is not to say I wouldn't be happy with a bunch of A75 cores either). Even in 32bit mode a good 8 way A53 soc can hold it's own with A17 cores in terms of max throughput (i.e. when all cores can be kept busy). A standard test case I use runs about 40% faster on a NanoPi M3 than on a UGOOS UT3S, and 10% faster than an XU4. As another example, checkout the M3 on the John the Ripper benchmark:

You can see more benchmarks from this comparison here: http://openbenchmarking.org/result/1707120-TR-1703199RI54&obr_sor=y&obr_sor=y&obr_hgv=NanoPi+M3+32bit

I only ran the M3 results, the other results were merged in from previous peoples work.

 

As is typical with performance discussions, there's an awful lot of "it depends" involved. A small number of faster cores is often easier to get max performance out of. Some applications are well suited to running on a larger number of cores, some applications devolve into a memory bandwidth test. And sometimes performance per watt or performance per $ is more critical than absolute max throughput.

You forgot Meta Performance Per Dollar, that is what matters and a53 beats 32-bit your hyped nanopi. All those test are artificial, no linux kernel compilation time for example. Sure my octacore A53 S912 beats some 32-bit quad core.

[Shimon]

Good news for all Q8 owners: MK902II Android 5.1 firmware seems to be working great on this box (thanks @mo123!) 

 

My earlier Termux suggestion (that required Lollipop to use) is fully workable now. I have yet to check if the firmware is similar to Ugoos's, able to boot Linux from SD automatically, but it probably should work one way or another. 

[jock]

Hello anyone, I managed to pack a basic system for my Q8 tv box which seems to be *really* working.

It is a very basic debian wheezy running on the stock 3.10.0 kernel, no framebuffer console, and misses a lot of things, but it is a start point for anyone who wants to experiment with this tv box. The goal is to achieve armbian running on a fairly recent kernel!

 

Here you can download the archive, which contains the basic image parts and a bash script to flash them onto an sd card.

The system is a bare minimal debian wheezy which asks a DHCP server for an IP and spawns SSH daemon. Check the included readme.txt file for more detailed infos.

 

Have fun!

[jock]

Hello, back again on the topic.

 

I studied for quite some time this q8l, found a lot of interesting things about and now I'm able to boot a pretty stable Linux mainline kernel with a minimal but totally functional debian stretch.

Linux kernel has been built using the scripts from RockMyy (https://github.com/Miouyouyou/RockMyy).

Unfortunately there is an issue with the USB ports which is preventing me from publish a working image. I found some info about the very same issue in this mailing list thread: the guy suggests that patching the dts file solved his problem, but it didn't work for me. If someone is interested or has an idea on how to solve I could pack the things up and share this preliminary work.

[Myy]

Could you provide your dmesg logs ?

 

Also, what's the issue with the USB ports exactly ? They just don't work or is it more subtle ?

[jock]

13 hours ago, Myy said:

Could you provide your dmesg logs ?

 

Also, what's the issue with the USB ports exactly ? They just don't work or is it more subtle ?

 

Hello Myy, I guess you're behind the kernel work. First of all, thank you!

Attached to this post there is the output of lsusb -v and lsusb -t before attaching the USB device and the output of dmesg after the USB stick is attached.

There is a 4-port hub soldered on the board after the SoC USB port, it is controlling the two exposed USB ports.

If I boot the system with the USB stick attached it is correctly detected and works too. As long as I leave at least one device attached I can connect and disconnect other devices. All of them get properly detected and work. When I unpopulate all the ports I can't connect any USB device anymore because I get the USB reset and read errors you can see in dmesg log.

If I plug an USB device after the system boot I get the reset/read errors and the USB ports stop responding. Also the 4 port hub disappears from the list of USB devices.

The mailing list thread describes a very similar problem but the proposed solutions (autosuspend, reset pins in device tree) seem not to work in my case.

 

PS: I compared the original device tree and the one I'm using which is a rework by DengueTim based on the firefly device tree. I attach it also to this post in case you want to take a look into. I tinkered a bit with it: enabled the apparently unused generic-ehci usb host @ff500000, added some resets... but I'm not a master in there and I'm still trying to realize how device trees work.

 

dmesg.log

lsusb.before.log

lsusb-t.before.log

rk3288-q8.dts

[Myy]

Hmm, the usb driver seems to be whining about missing regulators so there might be a few things to check here. Or maybe it's a red herring.

 

Wasn't the q8 kind of similar to "MiQi" devices ? If you temporarily swap the MiQi DTS with the q8 DTS, do you have USB devices enabled ? If yes, does the same bug happen ?

 

Also, if you shorten the following sections from :

 

&usb_host0_ehci {
    reg = <0x0 0xff500000 0x0 0x20000>;
    resets = <&cru SRST_USBHOST0_PHY>;
    reset-names = "phy-reset";
    status = "okay";
};

&usb_host1 {
    pinctrl-names = "default";
    pinctrl-0 = <&usbhub_rst>;
    resets = <&cru SRST_USBHOST1_PHY>;
    reset-names = "phy-reset";
    status = "okay";
};

 

to

 

&usb_host0_ehci {
    status = "okay";
};

&usb_host1 {
    status = "okay";
};

 

Does it work better ?

 

[jock]

21 hours ago, Myy said:

Hmm, the usb driver seems to be whining about missing regulators so there might be a few things to check here. Or maybe it's a red herring.

 

Wasn't the q8 kind of similar to "MiQi" devices ? If you temporarily swap the MiQi DTS with the q8 DTS, do you have USB devices enabled ? If yes, does the same bug happen ?

 

Also, if you shorten the following sections from :

 

&usb_host0_ehci {
    reg = <0x0 0xff500000 0x0 0x20000>;
    resets = <&cru SRST_USBHOST0_PHY>;
    reset-names = "phy-reset";
    status = "okay";
};

&usb_host1 {
    pinctrl-names = "default";
    pinctrl-0 = <&usbhub_rst>;
    resets = <&cru SRST_USBHOST1_PHY>;
    reset-names = "phy-reset";
    status = "okay";
};

 

to

 

&usb_host0_ehci {
    status = "okay";
};

&usb_host1 {
    status = "okay";
};

 

Does it work better ?

 

 

Swapped the device tree with the MiQi, the box didn't boot at all, crashing in the middle of the kernel boot :/

The missing regulators should not be a real problem, at least I think I saw them on some other kernel logs from tinkerboard bootstrap.

Reverted back the usb_host0_ehci and usb_host1 sections to status = "okay" only, but no luck either.

 

I'll do some more research, and post here the findings

[jock]

Ok, I did some research, trial and errors, a lot of time lost around this issue. At last, I found that setting the autosuspend property for the USB host to a large number doesn't immediately kill the dwc2 USB host port, so this is definitely an autosuspend problem, which led me  back to the mailing list thread I linked above.

The most recent post of that I can find is this:

https://patchwork.kernel.org/patch/9469811/

 

The patch is not yet in upstream kernel, so I patched it manually and adding the proper reset lines to usbphy2 section this post I finally made it work!

The working device tree is attached to this post, along with a dmesg for the most curious.

 

Anyway the author of the patch says that this is a "workaround", because RK3288 has an errata about the dwc2 host post messing around with the usb bus when it is reset.

There is some tuning to gain performance and reduce cpu usage, which is definitely too high at the moment.

 

rk3288-q8.dts

dmesg.log

[pro777]

Hello, 

Look, here you can download firmware for Q8.
Debian 9 for the SD card and MMC with rockchip kernel 4.4.114. Features:
- Installed Mali r14p0 drivers, 

- Installed the release of the Rockchip MPP library from 171225,

- Use the LXDE desktop,
- Installed Kodi 17.3,
- The Onboard virtual keyboard is installed.
Benefits:

- Smooth playback of video 4K H264 and H265 (HEVC) using Qt Simple Player,

- Hardware support Chromium Browser, 
- The presence of sound and WI-FI,
-  Operation of the IR remote control.

 

P.S. There is also the prospect of adding an Q8 to a supported board for Armbian.

 

[jock]

On 4/3/2018 at 2:43 PM, pro777 said:

Hello, 

Look, here you can download firmware for Q8.
Debian 9 for the SD card and MMC with rockchip kernel 4.4.114. Features:
- Installed Mali r14p0 drivers, 

- Installed the release of the Rockchip MPP library from 171225,

- Use the LXDE desktop,
- Installed Kodi 17.3,
- The Onboard virtual keyboard is installed.
Benefits:

- Smooth playback of video 4K H264 and H265 (HEVC) using Qt Simple Player,

- Hardware support Chromium Browser, 
- The presence of sound and WI-FI,
-  Operation of the IR remote control.

 

P.S. There is also the prospect of adding an Q8 to a supported board for Armbian.

 

Great job!

I'm working from the mainline side: kernel 4.16 and latest u-boot (2018-3) are working fine.

I'm still facing a problem against the bootstrap and reboot (looking into the act8846 power regulator datasheet, see this), but most of the hardware is working very well, including gpu-accelerated chromium, wifi, bluetooth. I'm still missing the IR remote control. 

[pro777]

9 hours ago, jock said:

Great job!

I'm working from the mainline side: kernel 4.16 and latest u-boot (2018-3) are working fine.

I'm still facing a problem against the bootstrap and reboot (looking into the act8846 power regulator datasheet, see this), but most of the hardware is working very well, including gpu-accelerated chromium, wifi, bluetooth. I'm still missing the IR remote control. 

 

Excellent. Can you give a link to your firmware?

How did u-boot 2018.3 run?

[jock]

On 7/4/2018 at 11:00 PM, pro777 said:

 

Excellent. Can you give a link to your firmware?

How did u-boot 2018.3 run?

 

At the moment I have no published firmware yet. I would like to solve the boot problem soon if possibile, but I may think to share some preliminary work so who is interested can look into.

I should really do some tidying up of the source device tree, kernel patches, binary firmwares and other things needed to make the thing work; I guess I can share my working image as a preliminary "demo" just for testing, sources may come as soon as possible

[jock]

@pro777 and anyone who is interested, I publish here the first draft of my work. Take this as a "proof of concept" for future work, this is nothing more than a test image.

 

edit: see this page for better and more up-to-date armbian images

 

The test image can be downloaded from here.

 

It is an image of Armbian based upone latest 5.41 release for tinkerboard, with u-boot and kernel compiled using the device trees I adapted on the base of the original device tree coming from my tv box. A lot of work has already been done by other people.

 

Current status:

- Wireless, pretty fast and stable, signal is strong on my box;

- Bluetooth, seems to work. I just tested a file transfer.

- USB Host: works quite well but autosuspend is disable for the 4-port hub connected to this non-OTG SoC port due to issues. Transfer rate is quite good (topped at 34 MB/s)

- USB OTG: works quite well in host mode, no quirks apparently. Transfer rate is very good (topped at 38 MB/s)

- MMC: can be accessed, did not try to program it though

- SDCard: works very well, in ultra high speed mode too. Tested a lousy class-4 sdcard and reached more than 60 MB/s!

- Gigabit Ethernet: seems to work fast and reliably

- HDMI: has some quirks, expecially if you attach and detach the devices. Generally works, but resolution is not configurable (see the note at the bottom)

- Serial: works

- Audio: HDMI audio works, but SPDIF is still a work in progress

- IR remote: does not work, still trying to understand if a special driver is required or I am missing some pieces of the puzzle

- Boot/Reboot/Suspend process: still some mysteries lays around here. The boot process on my box is a bit problematic (see the instructions below) and requires some attention. Suspend is not available at all. Rebooting the device via command line actually shuts it down.

- Hardware acceleration: the kernel driver is there, userland drivers are still messy, but something can be achieved for the X server (see the link to the guide below) and probably the framebuffer GL ES driver works too

 

Instructions:

- First of all, you should boot your box in Maskrom Mode. One of the fastest ways is to zero-fill the internal MMC, I followed this as reference: https://github.com/nolange/rk3288-guide/blob/master/bootloader.md

When in maskrom mode, the First Program Loader (which is the bootloader inside the SoC) will try to boot first from MMC chip, then SD card and finally USB. If you don't boot in maskrom mode, the SoC will always try to boot from the MMC chip, which has an obsolete u-boot

- Flash the image over an microsd card, then plug the card into the box

- If your box has a power button (mine has), push it and keep it pushed for some seconds, until you hopefully see the power led blinking. When the led is blinking, the kernel has started and your can stop pushing the power button. Note that if you push the power button for more than 10 seconds, the box will shut down. Another solution could be to connect the OTG port to your computer: doing this won't require you the keep the button pushed.

- As usual, armbian default credentials are user: root password: 1234

 

You should be able to follow this guide to gain some hardware accelerated X server. It worked for me and I was able to obtain some pleasant Chrome experience.

 

In /opt directory there are some firmwares and binaries downloaded from rockchip official github pages, and also the source device trees, scripts, and the configuration files I used to build the custom kernel and u-boot. I tried to stay stick to the default configs, so modifications should be minor. Also there is an enable_bt.h script to load the patch firmware and enable the bluetooh device.

 

Kernel is 4.14, (current armbian mainline) and u-boot is 2018.3 (current mainline). I also tested latest 4.16 mainline kernel and rockchip pre-2018 u-boot, they also work.

From the device tree, the CPU is configured to run at a maximum frequency of 1.6 Ghz and trigger the first thermal trip points at 70°C. A nice heatsink, or even a fan, are suggested.

 

edit: for HDMI, I made a mistake. You will need to manually copy a new device tree binary into /boot/dtb directory. Look here for the dtb file

Edited May 9, 2018 by jock

[pro777]

jock,

Thanks for the provided firmware and instruction. I tried the firmware on your link. I have a problem: there is no display for hdmi. As a monitor I use Samsung TV. Why is it better to work with the kernel from Rockchip: there is an available VPU driver in it, unlike the newest kernels. DTS I use on the basis of a firefly. It requires minimal changes and gives a good result. Try also u-boot from Rockchip with dts from the firefly. There usb is work, mmc do not need to disable - everything is displayed correctly.

[jock]

On 4/14/2018 at 8:34 PM, pro777 said:

jock,

Thanks for the provided firmware and instruction. I tried the firmware on your link. I have a problem: there is no display for hdmi. As a monitor I use Samsung TV. Why is it better to work with the kernel from Rockchip: there is an available VPU driver in it, unlike the newest kernels. DTS I use on the basis of a firefly. It requires minimal changes and gives a good result. Try also u-boot from Rockchip with dts from the firefly. There usb is work, mmc do not need to disable - everything is displayed correctly.

 

Sorry, that was my mistake. So I was too zealant in changing some regulators in order to support suspend features and so on and disabled the lcd power regulator

Overwrite /boot/dtb/rk3288-q8.dtb with the rk3288-q8.dtb attached to this message and HDMI should finally work. I also provide the device tree source for reference, but copying the binary will suffice.

rk3288-q8.dtb

rk3288-q8.dts

[pro777]

On 16.04.2018 at 9:28 PM, jock said:

 

Sorry, that was my mistake. So I was too zealant in changing some regulators in order to support suspend features and so on and disabled the lcd power regulator

Overwrite /boot/dtb/rk3288-q8.dtb with the rk3288-q8.dtb attached to this message and HDMI should finally work. I also provide the device tree source for reference, but copying the binary will suffice.

rk3288-q8.dtb

rk3288-q8.dts

 

HDMI joined. But at me Samsung for some reason does not support HDMI parameters which are exposed by a kernel.  The inscription "This resolution is not supported" appears. With sound there is a problem: background sound is heard, but bad with speech. Use the RK1000 codec for sound. Drivers can be easily transferred from the Rockchip repository.

[jock]

12 hours ago, pro777 said:

 

HDMI joined. But at me Samsung for some reason does not support HDMI parameters which are exposed by a kernel.  The inscription "This resolution is not supported" appears. With sound there is a problem: background sound is heard, but bad with speech. Use the RK1000 codec for sound. Drivers can be easily transferred from the Rockchip repository.

 

Try to turn off and on the monitor. Once and then I have glitches with a pink column of pixels at the left border which, I guess, is something that should be fixed in hdmi drivers.

By the way I tested the HDMI on a couple of devices, a Philips Monitor/TV and a Iiyama Monitor, both Full-HD and with in-built speakers and both works fine either with output and sound.

For my understanding, rk1000 device drives only analog audio and video, so it not of any use on our TV boxes.

[mo123]

Anyone that still have a working rk3288-ugoos-ut3s.dts file for a 4.4 kernel or can make one compatible up to the latest RK 4.4.167 kernel one?

It seems all the Omegamoon sources are dead that were used for an old LE build.

I want to try to use it to build a working LibreELEC image using a new 4.4.167 kernel.

I have an Android 4.4.112 kernel dts for the UT3S that boots Nougat, can post it if it will help someone.

If I build LE for Miqi RK3288, it boots on the UT3S but gets stuck on the LE splash screen.

So the Miqi dts could be a starting point but need changes from a UT3S dts file, I think the rk3288-firefly-reload.dts already in the 4.4.167 kernel might also be a good starting point, it would only lack fan support and some other things perhaps.

Perhaps if LE boots, it wouldn't be too difficult to get an Armbian image going too.

I think all the Ugoos Linux images used a 3.10 kernel, not 4.4 that is available now,.

[jeanrhum]

6 hours ago, mo123 said:

I have an Android 4.4.112 kernel dts for the UT3S that boots Nougat, can post it if it will help someone.

Yes please, can you post it?

I was able to boot jock image with my ut3s, but not all features working. Look at this topic: