CSC Armbian for RK3318/RK3328 TV box boards

[nerdherd96]

17 minutes ago, Dragao said:

Just would like to point out that there is no display at all. Not even for the non graphical part. 

I am not interested in a GUI so for me if I can get the cli to work work be just fine.  but I have same results using a console version of Focal. I have only output on the serial console not through HDMI

Thats good, but working It with a Little desktop Is Better 🤣

[Dragao]

Just now, nerdherd96 said:

Thats good, but working It with a Little desktop Is Better 🤣

That maybe.. Although I beg to differ  

[lucky62]

3 hours ago, Huafu said:

So I was wondering if you could share your work on github or so. I know you're not on legacy branch but either you succeed on enabling HW acceleration and I'd then switch back to 5.x kernel, or I could dig in the diff from your repo to try to make the wifi, IR and LCD work for legacy kernel.

 

Hi @Huafu, there is not much more to share than what was already published in this thread... I was trying to compile kernel, but in the end I am using the kernel from @jock. Also I did nothing with HW acceleration...
WiFi is working, just needs to be enabled by rk3318-config. IR is working also, just you need the toml file (attached) and register it - described here.

 

Regarding the LCD, I compiled the driver from Arthur - without changes. For this you need to install kernel headers into box, download and unpack the driver sources, switch to the driver directory. In the MakeFile you need to change the path to the kernel - in my case it was:

KERNELDIR = /lib/modules/5.10.37-rockchip64/build

 

and you need to create the symlinks to the System.map in the driver directory and in the kernel directory:

ln -sf /boot/System.map-$(uname -r) System.map # in the driver directory
ln -sf /boot/System.map-$(uname -r) /lib/modules/$(uname -r)/build/System.map

 

then compile and install:

make
make modules_install

 

Finally you need DT overlay file - just make a copy from here and install it by armbian-add-overlay. DTS will be automatically compiled and installed. After reboot driver should be loaded. To work with it you need to start OpenVFDService. I am using the version compiled by @jock.

 

Last point - I was not happy with cooling - box was very hot even when idle... So I ordered fan and regulator from Aliexpress, I did a big hole to the top cover and mounted together. Fan is powered from the adapter. No big current. Temperature sensor is glued to the heatsink:

 

 

Soldering - thick wires are for fan (red = + positive). On the left side are the wires of serial interface:

 

 

x88pro10.toml

[jock]

Hello @Huafu, yes the legacy image is an older one. Most of my effort now is to support mainline because rk3328 (and thus rk3318) support is already quite mature and hardware decoding is already there. The kernel (5.10) may lack some recent things, but yet I didn't test it by myself so I don't know if hardware acceleration really works.

 

The legacy image is not yet up-to-date with latest bits as you notice, so no rk3318-config and no overlays. Device trees from 5.10 need to be reviewed to work on kernel 4.4 without issues and honestly I'm not very motivated now because everything is moving towards mainline.

[jock]

5 hours ago, nerdherd96 said:

Nothing ti do. Also with lxdm, once DM starts, screen goes off. If i stop the dm with systemctl, the console reappears.

Hmmm, very strange, it should use native resolution in both desktop and virtual terminal modes. I had to force disable the 3d acceleration of Lima driver via X.org conf file, it was used to work in X but the last time I tried it didn't.

Maybe try posting /var/log/Xorg.0.log so we can take a look into... Also did you try with other HDMI cable and/or other device?

[nerdherd96]

1 hour ago, jock said:

Hmmm, very strange, it should use native resolution in both desktop and virtual terminal modes. I had to force disable the 3d acceleration of Lima driver via X.org conf file, it was used to work in X but the last time I tried it didn't.

Maybe try posting /var/log/Xorg.0.log so we can take a look into... Also did you try with other HDMI cable and/or other device?

Monitors with DisplayPort  not working, but a simple TV works.

[jock]

11 minutes ago, nerdherd96 said:

Monitors with DisplayPort  not working, but a simple TV works.

Good to know. I had a very recent experience with a DisplayPort -> HDMI adapter that was performing very poorly (blurred with slightly altered colors) when connecting a regular computer (DP) to a regular TV (HDMI). Changing the HDMI cable magically makes the thing work perfect. Did not investigate the reason.

 

edit: the same HDMI cable was performing fine when connected to the HDMI port of the computer

[Huafu]

19 hours ago, lucky62 said:

 

Hi @Huafu, there is not much more to share than what was already published in this thread... I was trying to compile kernel, but in the end I am using the kernel from @jock. Also I did nothing with HW acceleration...
WiFi is working, just needs to be enabled by rk3318-config. IR is working also, just you need the toml file (attached) and register it - described here.

 

Regarding the LCD, I compiled the driver from Arthur - without changes. For this you need to install kernel headers into box, download and unpack the driver sources, switch to the driver directory. In the MakeFile you need to change the path to the kernel - in my case it was:

KERNELDIR = /lib/modules/5.10.37-rockchip64/build

 

and you need to create the symlinks to the System.map in the driver directory and in the kernel directory:

ln -sf /boot/System.map-$(uname -r) System.map # in the driver directory
ln -sf /boot/System.map-$(uname -r) /lib/modules/$(uname -r)/build/System.map

 

then compile and install:

make
make modules_install

 

Finally you need DT overlay file - just make a copy from here and install it by armbian-add-overlay. DTS will be automatically compiled and installed. After reboot driver should be loaded. To work with it you need to start OpenVFDService. I am using the version compiled by @jock.

 

Last point - I was not happy with cooling - box was very hot even when idle... So I ordered fan and regulator from Aliexpress, I did a big hole to the top cover and mounted together. Fan is powered from the adapter. No big current. Temperature sensor is glued to the heatsink:

 

 

Soldering - thick wires are for fan (red = + positive). On the left side are the wires of serial interface:

 

 

x88pro10.toml 771 B · 1 download

Hi @lucky62 and @jock, thanks again for your help! Sorry for the late reply, I am limited as a new user in term of number of post per day.

@lucky62 I've followed your great detailed explanations, now I got the mainstream armbian installed on my X88PRO 10 with the latest kernel (5.10.37) from @jock posted in here. The LCD does work (tho I've not yet configured it to show the wifi status and others apart from the current time, but that is not important). Also I've managed to install the IR toml you provided @lucky62, but it wasn't working in kodi, tho I guess it's just some config which I can deal with later.

 

Now next big thing to fix for me is that the board is recognized as 2G of RAM instead of 4G, and the eMMC is recognized as 32G instead of 64G. As far as I understand, this is due to missing/wrong dtb right? Using multitool I've done a backup of the original firmware, from which I've extracted dtbs using extract-dtb. Now I've got many dtb and I don't know which one to choose... and then where to put them and how to instruct the system which one to use.

 

-rw-r--r-- 1 huafu huafu 1.0M May 26 09:14 01_dtbdump_rockchip,rk3328-evb.dtb
-rw-r--r-- 1 huafu huafu 1.0M May 26 09:14 02_dtbdump_rockchip,rk3328-evb.dtb
-rw-r--r-- 1 huafu huafu 1.0M May 26 09:14 03_dtbdump_rockchip,rk3328-evb.dtb
-rw-r--r-- 1 huafu huafu 8.2M May 26 09:14 04_dtbdump_rockchip,rk3328-evb.dtb
-rw-r--r-- 1 huafu huafu  36M May 26 09:14 05_dtbdump_fragment@0.dtb
-rw-r--r-- 1 huafu huafu 5.4M May 26 09:14 06_dtbdump_rockchip,rk3328-box-liantong-avb.dtb
-rw-r--r-- 1 huafu huafu  76K May 26 09:14 07_dtbdump_rockchip,rk3328-box-liantong-avb.dtb
-rw-r--r-- 1 huafu huafu  70M May 26 09:15 08_dtbdump_rockchip,rk3328-box-liantong-avb.dtb
-rw-r--r-- 1 huafu huafu 5.4M May 26 09:15 09_dtbdump_rockchip,rk3328-box-liantong-avb.dtb
-rw-r--r-- 1 huafu huafu 2.0K May 26 09:15 10_dtbdump_fragment@0.dtb
-rw-r--r-- 1 huafu huafu  76K May 26 09:15 11_dtbdump_rockchip,rk3328-box-liantong-avb.dtb

I'm not sure but I believe the one for my board is a `-avb`. The `09_` and `11_` are the same, `08_` is different and I haven't checked the others yet (I've decompiled them using `dtc -I dtb -O dts ...` and checked the diffs). FYI @lucky62 it seems there are some IR mapping in some of them. I didn't want to make a giant post, but if you want I can post all the dts here.

 

Kodi (v17, from armbian repos) is sloooooow, but that is a missing lima or mali driver, I'll try to deal with that after I fixed the wrong RAM and eMMC sizes.

 

18 hours ago, jock said:

Hello @Huafu, yes the legacy image is an older one. Most of my effort now is to support mainline because rk3328 (and thus rk3318) support is already quite mature and hardware decoding is already there. The kernel (5.10) may lack some recent things, but yet I didn't test it by myself so I don't know if hardware acceleration really works.

 

The legacy image is not yet up-to-date with latest bits as you notice, so no rk3318-config and no overlays. Device trees from 5.10 need to be reviewed to work on kernel 4.4 without issues and honestly I'm not very motivated now because everything is moving towards mainline.

@jock don't worry about that, I first tried the legacy since my main goal is to run kodi and only kodi on that box, and in your first post you were redirecting there for media-buster-legacy package.

 

Also I do have another issue with my old TV which have missing part of screen on each border. When I used to plugged a raspberry with raspberry os there, I was changing my config.txt and setting `overscan_left`, `overscan_right`, ...

What is the correct way to do the same with armbian?

 

Thanks for all your help!

[fabiobassa]

Quote

Now next big thing to fix for me is that the board is recognized as 2G of RAM instead of 4G, and the eMMC is recognized as 32G instead of 64G.

@Huafu

I suppose is EXACTLY the amount you have. Guve a try to searching on google yhe name of chip:
among ALL THE BOARDS we experimented didn't yet find one of 4 giga........

[Huafu]

7 minutes ago, fabiobassa said:

@Huafu

I suppose is EXACTLY the amount you have. Guve a try to searching on google yhe name of chip:
among ALL THE BOARDS we experimented didn't yet find one of 4 giga........

Hi @fabiobassa, thanks for your answer. Here is the link to the product I bought: https://www.amazon.fr/gp/product/B08DJYV64M

And here is the corresponding device specs: http://deviceinfohw.ru/devices/item.php?item=239703

[fabiobassa]

@Huafu

Oh, yes, specs can say and clain wht they want. In past we had ANDROID 10 even.... on old 3.10.104 kernel
Open the box and search on google for chip name

[Huafu]

26 minutes ago, fabiobassa said:

@Huafu

Oh, yes, specs can say and clain wht they want. In past we had ANDROID 10 even.... on old 3.10.104 kernel
Open the box and search on google for chip name

Hmmm.. thanks for opening my eyes @fabiobassa. So I opened my box and collected all what I could find.

On the eMMC, you're right, it's a 32G one...

But for the RAM, there are 4 chips of 512M on each side of the board => 8x512M=4G.

Here is a screenshot of the Samsung datasheet I could find corresponding to what is written on the chips:

 

 

Also here are some pictures:

 

 

 

 

 

BTW, I can post more than once a day, yeah!

[kruzer]

3 hours ago, fabiobassa said:

among ALL THE BOARDS we experimented didn't yet find one of 4 giga........

My board is equipped with 4GB RAM, 64 GB emmc. Armbian Focal current is correctly discovering those resources. Although wifi chip supposed to be AP6334/BCM4334 is realiy an AP6330/BCM4330

[fabiobassa]

@kruzer

 

....and again , as you can see, we cannot absolutely TRUST any of publicity or/and brochures from vendors 

 

I am very happy for you board , it must be a really horse power !!!

 

A good substitute for home pc with low consumption 

[kruzer]

21 hours ago, fabiobassa said:

I am very happy for you board , it must be a really horse power !!!

 

A good substitute for home pc with low consumption 

It is all thanks to you, @jock and other people from this great forum. The desktop experience is noticeably better then rk3229, 

OpenOffice Calc starts in 6s, GIMP in 13 (afer reboot), this forum page reloads in 10s in chromium. It feels a bit laggy but still very usable. 

On the other hand, working via vpn on remote windows desktop is just comfortable. I'm considering to use it as cheap, preconfigured box for remote employees in the next covid wave.

[fabiobassa]

@kruzer

 

Quote

.......for remote employees in the next covid wave

 

please don't, let's  use it every day and not just  for the 4th wave 
 

Quote

The desktop experience is noticeably better then rk3229

The 322x is the black duckling of the serie , but as per the novel, it unvealed to be a nice swan too. Of course with its limited resources but for headless programs ( vpn, dns pihole, asterisk voip, ssh, samba, etc etc etc ) is really satisfacting.
But 3318 I must admit is another level ......About laggy things, yet, I really hope and think that experiences will be every day better.
Until just 6/7 moths ago this 3318 was not more than the nth black-box sold around, now is a 85% ready desktop substitute
And a big thank you too, also, because " testing and proposing" , trials and errors, is the best way to achieve results !!!

[Dragao]

What can I do to get the HDMI working (for a non desktop version)  ?

 

Guess if it works for desktop it will also work for the console.. but  I am kinda stuck at the moment. 

 

Can I easily recompile the image with the dtb I grabbed from the boot (Android) ?

Perhaps that will help? 

 

 

[kruzer]

32 minutes ago, Dragao said:

Can I easily recompile the image with the dtb I grabbed from the boot (Android) ?

 

You don't need to recompile kernel. Which dtb is used by uboot is configured in /boot/armbianEnv.txt. If you can boot from sd card, you can edit config on pc, change dtb, and monitor booting process. But I am not sure if the dtbs are compatible between different kernel versions.

In my opinion you should rather find differences in dts from android and armbian, I've tried to compare yours and mine, but I am newbie and didn't find anything obvious.

 

Apart from that, did you try to use different hdmi cable or monitor?

 

 

[Dragao]

51 minutes ago, kruzer said:

You don't need to recompile kernel. Which dtb is used by uboot is configured in /boot/armbianEnv.txt. If you can boot from sd card, you can edit config on pc, change dtb, and monitor booting process. But I am not sure if the dtbs are compatible between different kernel versions.

In my opinion you should rather find differences in dts from android and armbian, I've tried to compare yours and mine, but I am newbie and didn't find anything obvious.

 

Apart from that, did you try to use different hdmi cable or monitor?

 

 

I did not use a different monitor nor cable (as I have no other...)

 

Can I change the config while it's running ? It is currently installed on the internal eMMC  (just lazy to prepare an SD :P) 

 

As your board seems the same as mine I am annoyed yours is working  

 

 

[kruzer]

16 hours ago, Dragao said:

Can I change the config while it's running ?

 

Yes you can edit it while running. But it will be activated on the next boot. With wrong dtb the box could freeze while booting, and then it would be easier to mount the sd in pc and correct the config, and try again.

With a broken system flashed on emmc, you will have to flash it again, or boot Multitool, mount emmc volume and edit /boot/armbianEvn.txt.

 

16 hours ago, Dragao said:

it is currently installed on the internal eMMC  (just lazy to prepare an SD :P) 

Lazy ... ?    you followed the longer path, you had to: flash the multitool, copy an armbian image to multitool sd, boot with the mulititool, backup the original android and finally flash the armbian image ...

instead of just flashing a sd with the new image.

[Dragao]

4 hours ago, kruzer said:

Yes you can edit it while running. But it will be activated on the next boot. With wrong dtb the box could freeze while booting, and then it would be easier to mount the sd in pc and correct the config, and try again.

With a broken system flashed on emmc, you will have to flash it again, or boot Multitool, mount emmc volume and edit /boot/armbianEvn.txt.

 

Lazy ... ?    you followed the longer path, you had to: flash the multitool, copy an armbian image to multitool sd, boot with the mulititool, backup the original android and finally flash the armbian image ...

instead of just flashing a sd with the new image.

Got me there! *busted*

[jock]

Hello @Huafu, the memory amount is normally autodetected: first by the rockchip blob (the ddrbin) that does the very first SDRAM initialization and then by u-boot.

Now I didn't change any bits in the u-boot code, but it may be that, for a reason or another, the rockchip blob is not able to detect the whole amount of memory.

 

The only way to know if the memory is correctly detected is read the serial output with a serial adapter.

You can however post a dmesg log here, but I guess it will just say that you have 2gb of ram and that's all.

 

Another thing that could be useful is the first megabyte of the original firmware, where the ddrbin is stored. Now we are using version v1.15 which turned out to be stable and compatible, but it could be that your board has a different memory arrangement that require a different version (I think it is a remote chance, but never say never ...)

[kruzer]

On 4/23/2021 at 7:19 PM, jock said:

Lima driver acceleration has been disabled in X.org for the moment. It gave issues I need to investigate

I've tried to run the Lima acceleration. Kernel driver is detected correctly:

lima ff300000.gpu: gp - mali450 version major 0 minor 0
lima ff300000.gpu: pp0 - mali450 version major 0 minor 0
lima ff300000.gpu: pp1 - mali450 version major 0 minor 0
lima ff300000.gpu: l2 cache 8K, 4-way, 64byte cache line, 128bit external bus
lima ff300000.gpu: l2 cache 64K, 4-way, 64byte cache line, 128bit external bus
lima ff300000.gpu: bus rate = 491520000
lima ff300000.gpu: mod rate = 491520000
[drm] Initialized lima 1.1.0 20191231 for ff300000.gpu on minor 1

But when i try to enable it in Xorg, or use a simple test code: https://github.com/yuq/gfx/tree/master/gbm-surface, driver throws an error:

[drm:lima_sched_timedout_job [lima]] *ERROR* lima job timeout

By comparing dtb from Android to Armbian, I found some differences in gpu@ff300000  node. First i tried changing the reg parameter:

 

from:
reg = <0x00 0xff300000 0x00 0x30000>;
to:
reg = <0x00 0xff300000 0x00 0x40000>;

But with this overlay:

/dts-v1/;

/ {

	fragment@0 {
		target-path = "/gpu@ff300000";

		__overlay__ {
			reg = <0x00 0xff300000 0x00 0x40000>;
		};
	};
};

the driver throws error on load:

lima ff300000.gpu: can't request region for resource [mem 0xff300000-0xff33ffff]
lima ff300000.gpu: fail to ioremap iomem
lima: probe of ff300000.gpu failed with error -16

Does it mean, that I have to diable another node which has an overlapping address? Or the change of region size from 0x30000 to 0x40000 is not an issue, and i should look for other differences?

 

[hexdump]

@kruzer - iirc this change was done intentionally by @jock - he'll most probably reply soon himself regarding this ... there is btw. a kernel cmdline parameter to extend the timeout: "lima.sched_timeout_ms=1000" and depending on how old your mesa is, it might maybe miss this fix: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10121 - also interesting in this context maybe: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3467 which resulted in that fix ... not sure, maybe your problem is a different one ...

 

best wishes and good luck - hexdump

[kruzer]

Thank you @hexdump for hints, but increasing timeout didn't help. My problem is related to incorrect dtb config i suppose. 

 

Ha, it started to work 

I'am not 100% how to link nodes and properties, but somehow it worked with this dts.

mymali.dts

Edited May 29, 2021 by kruzer
I found a solution

[jock]

Yes @kruzer , the right memory map size is 0x30000. As stated by rockchip documentation, the memory mapping for the gpu device is 192kb in size (0x30000 in hex). Setting it to 256kb (0x40000) overlaps the rkvdec device, hence the error in dmesg.

 

Note that actually the Lima acceleration is disabled in a X.org .conf file. Look for 40-serverflags.conf in /etc/X11/xorg.conf.d, and change AccelMethod option from "None" to "Glamor" to enable it. I disabled the Lima 3D acceleration for two reasons though:

• 2D is less reactive, as once @usual user explained, modesetting X.org driver is not suited for embedded SoC which have to share buffers between subsystems
• the X server was not starting at all, but this could be a problem due to lightdm-gtk-greeter issue

 

[jock]

@kruzer You were right there was an issue with the dtb also. Mysteriously it was missing the gpu operating points table.

I'm building new images right now, hopefully X.org will works without issues anymore.

[jock]

Ok, mainline kernel images have been updated, hopefully lightdm should be fixed from upstream Ubuntu and Lima driver + 3d acceleration is back in town!

 

I suggest however to disable the compositor from Windows Manager Tweaks menu and enabling show on window dragging for faster desktop experience.

[nerdherd96]

On 5/30/2021 at 6:54 PM, jock said:

Ok, mainline kernel images have been updated, hopefully lightdm should be fixed from upstream Ubuntu and Lima driver + 3d acceleration is back in town!

 

I suggest however to disable the compositor from Windows Manager Tweaks menu and enabling show on window dragging for faster desktop experience.

Everything looks good, GPU performance not so good.

I made many experiments. My DVI HDMI monitor has 1920x1200 resolution. If i boot the box with It, display doesn't start. If i connect It to a full HD device and then to the monitor, the display shows up with full HD resolution. I tried to add monitor setup with right CVT calcution but Xorg Stuck on starting.

 

@jock

[jock]

10 hours ago, nerdherd96 said:

Everything looks good, GPU performance not so good.

I made many experiments. My DVI HDMI monitor has 1920x1200 resolution. If i boot the box with It, display doesn't start. If i connect It to a full HD device and then to the monitor, the display shows up with full HD resolution. I tried to add monitor setup with right CVT calcution but Xorg Stuck on starting.

 

@jock

Yep GPU performance is not so good, expecially with the opensource Lima driver and mesa code which is not optimized as well as the closed source binary blob.

About the resolution issue, I guess that 1920x1200 is not a so common resolution; it's a matter of internal timings that are multiplied and divided to derive the various clocks to get the various resolutions.

Often these timings are adjusted to accomodate some resolutions, but break others. I'm no expert at all in this matter and never dig into personally so can't say anything more precise about

Had no time lately to look into libreelec patches, maybe there is something useful there.