CSC Armbian for RK3288 TV Box boards (Q8)

[jock]

On 10/29/2018 at 10:45 AM, Sergei Steshenko said:

Any news on new images ?

 

Just built this new Armbian Bionic 5.65 - dev kernel 4.18.16, which seems to work quite well with the updated Media Script by @JMCC for Bionic, but still no hw acceleration for video decoding. This build raises a kernel error about an "Unbalanced IRQ", but the system is stable and the functionality does not seem to be hindered.

 

I also built a default rockchip kernel image. but does not boot. I'm thinking to build the rockchip kernel without armbian patches to see if it is definitely in a bad state or there is some misconfiguration or patch triggering issues. For this you have to wait some time :/

 

edit: I see from the armbian commits that rockchip kernel has been forked by Armbian people, maybe there's a good chance to get something stable soon...

[Sergei Steshenko]

On 10/30/2018 at 1:10 AM, jock said:

 

Just built this new Armbian Bionic 5.65 - dev kernel 4.18.16, which seems to work quite well with the updated Media Script by @JMCC for Bionic, but still no hw acceleration for video decoding. This build raises a kernel error about an "Unbalanced IRQ", but the system is stable and the functionality does not seem to be hindered.

 

I also built a default rockchip kernel image. but does not boot. I'm thinking to build the rockchip kernel without armbian patches to see if it is definitely in a bad state or there is some misconfiguration or patch triggering issues. For this you have to wait some time :/

 

edit: I see from the armbian commits that rockchip kernel has been forked by Armbian people, maybe there's a good chance to get something stable soon...

I have tried the new image and the new media script - in which I chose the experimental option.

 

After playing a short HD video (2:15) in Chromium the desktop got stuck. First the mouse pointer was still moving, but I couldn't do anything with it, e.g. I couldn't move a window. Then the system got stuck completely.

 

I will try the stable version of the media script.

 

At the moment I have a much bigger heatsink (38mm x 38mm x 25mm), so the CPU temperature according to 'armbianmonitor -M' is about 45C, i.e. this is not a factor of instability.

 

Upon boot I still see the vertical magenta strip on the left side of the monitor.

[Sergei Steshenko]

2 hours ago, Sergei Steshenko said:

I have tried the new image and the new media script - in which I chose the experimental option.

 

After playing a short HD video (2:15) in Chromium the desktop got stuck. First the mouse pointer was still moving, but I couldn't do anything with it, e.g. I couldn't move a window. Then the system got stuck completely.

 

I will try the stable version of the media script.

 

At the moment I have a much heatsink (38mm x 38mm x 25mm), so the CPU temperature according to 'armbianmonitor -M' is about 45C, i.e. this is not a factor of instability.

 

Upon boot I still see the vertical magenta strip on the left side of the monitor.

I have tried the stable version of the stuff in the media script. To make sure there's no mix up I ref-lashed the SD card, i.e. it was a clean install.

 

Things are better with the stable version. E.g. Chromium does not cause the system to become uncontrollable as a result of playing the same video.

 

MPV works quite well.

 

GST player appears to be useless, and it was so in earlier images. It is useless in the sense it doesn't play the same videos MPV can play, and it doesn't report any problem. I.e. it does nothing.

 

The bad news is Kodi. It didn't start after asking the used password, and the system became uncontrollable - like in the quoted post. I.e. mouse pointer moves, but that's it - I can do anything. I can't move windows, I can invoke another application, etc.

 

Regarding audio - there are two items with the same name in the sources to select from - IIRC the name is "Built-in Analog Stereo" or something like this. Sound through HDMI plays if I choose the upper entry.

[Sergei Steshenko]

Well, if I first switch to a virtual terminal, and then from there invoke Kodi, it at least partially works. I .e. I was able to watch a video.

 

The vertical magenta stripe is still there - removed by unplugging and plugging again the HDMI cable. Audio source should again be selected, i.e. Kodi is not aware of settings made during the desktop session.

[jock]

Thanks for reporting back all these infos!

At the moment I'm looking into pulseaudio "Build-in Audio Stereo" issue for both SPDIF and HDMI.

A little trick to know who is who is to click on the speaker on the upper right corner, then go to "Default Sink" and then hover the mouse cursor on a label: there should appear a large overlay with many details about the sink, including the hardware name.

 

I'm also experimenting with xf86-video-armsoc driver, which provides a very smooth desktop experience. Some drawbacks are the lack of vsync (can be annoying watching videos), and some strange issues with fullscreen: kodi and glmark2 don't update their content, but quake/quake2 works really well. By the way, I still did not experience any lockup or freeze using it.

 

[jock]

Hello guys, I'm proud to say that the Q8 boards are now in mainline Armbian as CSC supported boards!

 

https://www.armbian.com/xt-q8l-v10/

[pro777]

Fine news!
You are well done!
Thanks!
There will be time, I will tested.

 

[Sergei Steshenko]

18 hours ago, jock said:

Hello guys, I'm proud to say that the Q8 boards are now in mainline Armbian as CSC supported boards!

 

https://www.armbian.com/xt-q8l-v10/

Do the images correct reported in this thread issues ?

[jock]

14 hours ago, Sergei Steshenko said:

Do the images correct reported in this thread issues ?

If you mean issues about the Media Script, no it won't because the issues are of the Media Script (and related things) and not the Armbian image itself.

By the way, I'm having discrete satisfaction using armsoc xf86 driver instead of modesetting: it has good 2D performance and 3D works. Videos are still decoded in software, but Kodi and mpv seems to run fine. I'm using the TV Box as desktop replacement (mostly browsing with Firefox) and it works pretty well!

 

If you want to give it a try, I suggest you to start from a fresh image with mainline or dev kernel.

Decompress this archive (armsoc compiled driver against X.Org 1.19.6, works only on mainline kernels) into /usr/lib/xorg/modules/drivers and create /etc/X11/xorg.conf.d/10-armsoc.conf with this content:

Section "Device"
        Identifier "Mali FBDEV"
        Driver "armsoc"
EndSection

Then decompress also the Media Script and install the Mali drivers with:

$ sudo dpkg -i packages/libs/libmali-rk-midgard-t76x-r14p0-r0p0_1.6-1-0armbian1_armhf.deb

it should be sufficient to run Kodi and mpv

[Sergei Steshenko]

I have read https://github.com/paolosabatino/xf86-video-armsoc - what is "bo" in, say, "Summary of bo reference counting" - ? Is it Buffer Overlays ?

 

Also, regarding "Decompress this archive (armsoc compiled driver against X.Org 1.19.6, works only on mainline kernels)" vs "I suggest you to start from a fresh image with mainline or dev kernel" - does it mean that for dev (not mailine) kernel one has to compile xf86-video-armsoc himself ?

 

What are practical advantages of using xf86-video-armsoc compared to what comes out of the box ?

 

Regarding the issues I've mentioned. I meant issues like sound devices names, for example. And IIRC somebody else was talking about IR remote control codes.

[jock]

11 hours ago, Sergei Steshenko said:

I have read https://github.com/paolosabatino/xf86-video-armsoc - what is "bo" in, say, "Summary of bo reference counting" - ? Is it Buffer Overlays ?

That's X11 nomenclature which I did not dealt with. It may be Buffer Object or whatever, my main purpose for creating another fork of Armsoc driver was to leverage mainline kernel DRM interface and add hardware mouse cursor for Rockchip. Eventually it turned out that the same driver was "tidied up" to run on amlogic and allwinner devices too and made VSynced page flipping somewhat working.

 

11 hours ago, Sergei Steshenko said:

Also, regarding "Decompress this archive (armsoc compiled driver against X.Org 1.19.6, works only on mainline kernels)" vs "I suggest you to start from a fresh image with mainline or dev kernel" - does it mean that for dev (not mailine) kernel one has to compile xf86-video-armsoc himself ?

armbian next and dev kernels are both mainline kernels, instead default (or also legacy) is the kernel branch developed by Rockchip.

You can use the Armsoc driver in the archive I pointed you both with next or dev armbian kernels (which are mainline), but it won't work with default (or legacy) kernels

 

11 hours ago, Sergei Steshenko said:

What are practical advantages of using xf86-video-armsoc compared to what comes out of the box ?

For my personal experience, it works much better with 2D desktop graphics than modesetting + glamor and allows 3D acceleration too. It is far from being perfect, but it is another choice which works and may better fit some needs.

 

11 hours ago, Sergei Steshenko said:

Regarding the issues I've mentioned. I meant issues like sound devices names, for example. And IIRC somebody else was talking about IR remote control codes.

Still working on that pulseaudio issue, trying to find the least intrusive way to define the soundcard description names. Instead I'm not aware about IR remote control codes issues, can you point it out to me?

[Sergei Steshenko]

34 minutes ago, jock said:

I'm not aware about IR remote control codes issues, can you point it out to me?

 I meant bottom part of

post.

[jock]

4 hours ago, Sergei Steshenko said:

 I meant bottom part of

post.

 

The remote keycodes are already fixed ages ago, and it was just a cosmetic issue (I used scancodes instead of human-readable constants, nothing to really worry about)

The i2s problem turned out to be a pro777's box issue.

The soundcard name in the device tree filters into ALSA device name but is not collected by pulseaudio, but I'm working on it. As a workaround you can add these two lines at the bottom of /etc/pulse/default.pa file:

update-sink-proplist alsa_output.platform-soundcard-hdmi.stereo-fallback device.description="HDMI Digital Output"
update-sink-proplist alsa_output.platform-soundcard-spdif.stereo-fallback device.description="SPDIF Digital Output"

 

[Sorm]

@jock I just signed up to the forum. I just wanted to thank you for your work.  I've been reading through the forums for the past few days.  Many years ago I purchased a MK903V Android TV stick.  https://us.gearbest.com/tv-box/pp_157926.html I had a lot of fun messing around with it in Android with emulators and whatnot but It struggled to play videos.  It collected dust for a few years.  With the release for the Tinkerboard,  I got excited to see the RK3288 being used for current Linux builds.  Long story short and through trial and error I was able to get your Q8 Debian (Russian build) running.  I have a lot for learning to do, most of these posts are like a foreign language to me but it's awesome have linux running on this device.  Thank you and everyone else who have shared their work.

[Sergei Steshenko]

On 1/18/2019 at 5:47 PM, Sorm said:

(Russian build)

 

Could you please provide links to info on the build ?

[Sorm]

@Sergei Steshenko Hi Sergei, It's in this sites forum. Jock posted a link under (Cheap TV boxes) in the Community forums.  The link goes to Jock's post in a Russian forum. I'm a beginner with Linux haha so (Russian build) was the best way for me to describe it. It's Jock's work and his decision if he wants to post a link here. 

[pro777]

On 5/17/2018 at 11:03 PM, pro777 said:

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.

Maybe Sorm means the link above? Then it's no secret

[Sorm]

Haha, secrets out! 

[hexdump]

hi @jock - i'm thinking about trying to follow your approach of getting a rk3288 tv-box booting well with a mainline u-boot instead of the very limited rockchip bootloader those boxes come with. the box i have is an orbsmart s92, which i think is identical to the beelink r89, orion r28 and ubox boxes. i have it running quite well so far using some sd-capable rockchip bootloader i once found on the linuxium site, but as said having a real contemporary mainline u-boot would make booting different kernel etc. much easier and maybe even gives me a serial console for the bootloader (the bootloader i have does not seem to use the normal serial port - starting from the kernel boot it works fine then though). i looked at the way you are building the u-boot for the q8 box from the original rockchip and the mainline one and i read your mainline u-boot contributions for the q8 box and have three questions about it:

1. how did you get the memory timing when booted with the original rockchip bootloader - did you add some debug prints to the kernel or did you get it via some userspace program?

2. how big might be the chance that another rk3288 tv-box like my s92 might work with your memory timings?

3. do i need any other specific information about my hardware to get mainline u-boot compiled for it? to me it looks like the memory timing is the only one and everything else i can get from the linux kernel dtb for my box, but maybe i overlooked something ...

 

a lot of thanks in advance and best wishes - hexdump

[jock]

On 1/25/2019 at 10:07 PM, hexdump said:

1. how did you get the memory timing when booted with the original rockchip bootloader - did you add some debug prints to the kernel or did you get it via some userspace program?

2. how big might be the chance that another rk3288 tv-box like my s92 might work with your memory timings?

3. do i need any other specific information about my hardware to get mainline u-boot compiled for it? to me it looks like the memory timing is the only one and everything else i can get from the linux kernel dtb for my box, but maybe i overlooked something ...

Hello @hexdump, I'm glad you find my work useful!

 

About your questions:

1. I programmed a small userspace program that reads the memory controller memory-mapped space to get most of the timings and settings. In the u-boot device tree source file I commented the exact location where the bits are extracted (see here). This stack overflow post may be useful for you, also I distinctly remember had to recompile kernel with CONFIG_STRICT_DEVMEM option disabled to access memory-mapped device memory.

2. low chance, mostly because q8 uses LPDDR2 and other tvboxes uses DDR3. It is very unlikely that a board works and works stable with the timings of another board. By the way, for Q8 the timings in the device tree file are not used actually.

3. as long as you get the memory timings, u-boot should boot fine.

 

For Q8 boards I must use the rockchip binary bootloader (see here) that does memory initialization and timings autodection, so the timings in the DTB file are not used at all. I put them there for completeness and because I wanted to explore the possibility to add LPDDR2 support to u-boot.

 

For your board, you can either use the rockchip binary bootloader or directly start from u-boot, because u-boot can do memory initialization for DDR3 memory, but you have to supply the memory timings yourself via DTB-file because u-boot can't do timings autodetection.

 

[hexdump]

@jock - thank you for the detailed response. this sounds really good - this way it might be even easier than i thought, as i'm completely fine with using the original u-boot part for the memory timing

[rmoriz]

On 5/12/2018 at 3:18 PM, jock said:

Backup:

First we determine the size of the eMMC flash memory

./rkdeveloptool rfi

Flash Info:
	Manufacturer: SAMSUNG, value=00
	Flash Size: 7393 MB
	Block Size: 512 KB
	Page Size: 2 KB
	ECC Bits: 0
	Access Time: 40
	Flash CS: Flash<0> 

in my case the size of the memory is 7393 Megabytes, so you can the command to retrieve the data:

./rkdeveloptool rl 0x0 $((7393 * 2048)) backup.data

this will download the original firmware in backup.data file in less than five minutes.

Restore the original firmware:

First we have to restore the original bootloader. Running these commands will do the job:

./rkdeveloptool db ../rk32/rk3288_ubootloader_v1.01.06.bin
Downloading bootloader succeeded.

./rkdeveloptool ul ../rk32/rk3288_ubootloader_v1.01.06.bin
Upgrading loader succeeded.

./rkdeveloptool wl 0x0 backup.data
Write LBA from file (100%)

 

 

How one can backup the existing bootloader? Where does "rk3288_ubootloader_v1.01.06.bin" come from?

[jock]

4 hours ago, rmoriz said:

 

How one can backup the existing bootloader? Where does "rk3288_ubootloader_v1.01.06.bin" come from?

 

rkdeveloptool, as far as I can remember, can't backup the existing bootloader. When you read the whole eMMC using rkdeveloptool, it skips the first 4 megabytes where the bootloader resides.

I think other tools, like the AndroidTool for Windows, can backup the existing bootloader too.

You could backup manually the bootloader partition accessing a running android installation via serial port.

 

rk3288_ubootloader_v1.01.06.bin came from the original rockchip rkbin repository, now removed but mirrored on github by armbian people. It is a collage of some rockchip binaries and an ancient u-boot binary into a single file.

 

I don't think backing up the bootloader worth it, as the one provided by rockchip looks the same as the one installed on the device.

Also if you want to run armbian, the original bootloader is replaced by a recent and up-to-date mainline u-boot.

 

[skyfly555]

Hello, guys.

 

One question: can this image work with my RK3229?

Specs, by Aida64:

SYSTEM
Device Type: TV
Manufacturer: rockchip
Model: rk322x
Device: rk322x_atv
Hardware: rk30board
Platform: rk322x
Product: rk322x_atv
Installed RAM: 2 GB

CPU
Core Architecture: 4x ARM Cortex-A7 @1392 MHz
Instruction Set: 32-bit ARMv7
Supported ABIs: armeabi-v7a, armeabi

DISPLAY
GPU Renderer: Mali-400 MP
GPU Version: OpenGL ES 2.0

ANDROID
Android Version: 8.1.0 (Oreo).
Android Security Patch Level: 2018-08-05
Build ID: rk322x_atv-userdebug 8.1.0 OPM6.180912.030.E1 20181116.093630 test-keys
Kernel architecture: armv71
Kernel version 4.4.138 (Leelbox@Leelbox) (gcc version 6.3.1 20170404).

I've tried to burn the image but it seems it doesn't boot. I suppose I have to change the dtb file? Don't know how to do that, if it's needed...

 

Thank you,

[jeanrhum]

Hi,

I think your have to upgrade your bootlader first to be able to boot from sd or usb, but I don't know if such a version exists for rk3229. The rootfs of current image is based on armv7 so no problem about that compared to rk3328 images you ask for in another thread, but the kernel itself may not be able to boot your board since the soc is different from rk3288 (at least the gpu).

[jock]

Sorry, but it won't work: rk3229 it a totally different SoC which requires different kernel drivers and thus different device trees etc... etc... Also rk3229 is not supported by mainline kernel and rockchip does not provide any sort of opensource documentation or source code for it.

 

You may try to tinker with the original android kernel: booting a debian stretch using that kernel may be at hand, but surely it may require quite some work and knowledge.

[skyfly555]

Thank you @jeanrhum and @jock for your answer. I have an S905X, too, and, with @balbes150 image, it runs like a charm. I will give the RK3229 to my son to play with it a little bit :) and leave it as it is :)

[paulludwig17]

On 9/15/2018 at 5:25 PM, jeanrhum said:

Hi jock,

 

Thanks for your work, I am able to boot my ugoos ut3s with your 4.18.6 image (haven't tried others). In my case, wifi doesn't work. I suppose my box haven't the same wireless chip as yours. Will make additionnal testing and will try to fix that later.

 

 

Hallo jeanrhum,

 

I'm not a software engineer, but would like to run a linux distribution on my ugoos ut3s, instead of my android OS.

Could you please share your linux image with me and I will make a bootable SD card from this ?

Or could you give me some advice, were I could find something similar ?

Again, I can't compile an own kernel, but ask you for a "ready to boot" image file.

 

Thanks in advance,

Paul

[jeanrhum]

Hi,

Finally I use jock image and it work except for bluetooth. So you can use the following instructions and image: https://www.armbian.com/xt-q8l-v10/

I didn't try latest build, but maybe I will look at it soon.

Don't hesitate to report here your success or fails.

[paulludwig17]

If I understand instructions right, then I've to erase the firmware to boot from the SD card ?

But then, I will loose  android OS in general, what I would like to avoid.

Is there a dual boot firmware available, which will boot from

SD card and switch to internal memory only in case, there is no bootable sd card installed ?

 

At the moment, I have installed a firmware called "wasser 4.0.11", which is an android 6.0.1 version.

In the past I had a ugoos linux version (14.xx) on a SD card, which was able to boot with this firmware.

 

Now I was trying to boot the image for the xt-q8l-v10, box but the display remains dark.

Is there a possibiliy by pressing any keys, to display a bootlog for further analysis ?

 

best regards, Paul