CSC Armbian for RK322x TV box boards

[Roscar Cunanan]

On 7/25/2020 at 2:12 AM, jock said:

Hello @victroniko, very glad you find our work useful!

 

Well, it looks like there's another wifi chip in the cauldron of rk322x boxes

Found some informations about the ESP8089 on the linux-sunxi site which points to this other repository that already has some kernel integration and, most of all, the firmware files.

 

I managed to integrate it very easily into rockchip 4.4 kernel, and compiled it into a kernel module: esp8089.ko.gz

 

Now first of all download the three firmware files from the jwrdegoede's repository I linked above and put them in /lib/firmware

 

Copy that file in your box root and then execute:

gzip -d esp8089.ko.gz
mv esp8089.ko /lib/modules/4.4.194-rk322x/kernel/drivers/net/wireless
depmod
modprobe esp8089 config=crystal_26M_en=2

This other repository (it's a fork from al177's) contains a PDF file with some compilation and usage informations from ESP8089 manufacturer you may wish to try in case it does not really work.

It looks like the chip also requires some GPIO juggling to make it work: the original device tree (DTB or resource.img) of the board could be very helpful here. Also dmesg log is always very helpful!

 

Here you can download the kernel headers as a DEB package. You will need to install this in case you want to compile the driver directly on the board. Install it this way:

sudo su
export ARCH=arm
dpkg -i linux-headers-legacy-rk322x_20.08.0-trunk_armhf.deb

 

hey jock,

 

im trying to build a linux driver for a gigabit ethernet adapter i used for another device into my rk322x armbian build. im on Armbian_20.08.0-trunk_Rk322x-box_buster_legacy_4.4.194_minimal.img.xz because its the only one that works well when flashed in nand. but when i try to build it, the following error is returned (after i imported the headers you provided):

 

root@omvbox:/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE# make
NOW IN default
KDIR is /lib/modules/4.4.194-rk322x/build
PWD is /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE
make -C /lib/modules/4.4.194-rk322x/build SUBDIRS=/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.194-rk322x'
  CC [M]  /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE/ax88179_178a.o
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
make[2]: *** [scripts/Makefile.build:284: /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE/ax88179_178a.o] Error 1
make[1]: *** [Makefile:1473: _module_/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.4.194-rk322x'
make: *** [Makefile:33: default] Error 2
 

 

it looks like this issue is architecture related.  are you on ubuntu or debian?

[jock]

Update:

Legacy images have been updated with ssv6x5x driver working out of the box.!

 

The esp8089 driver has been included in the new images, but it still require to manually put the firmware files and wlan-esp8089 device tree overlay in armbianEnv.txt. I will get this tidied up and ready on next release

[jock]

7 hours ago, Roscar Cunanan said:

hey jock,

 

im trying to build a linux driver for a gigabit ethernet adapter i used for another device into my rk322x armbian build. im on Armbian_20.08.0-trunk_Rk322x-box_buster_legacy_4.4.194_minimal.img.xz because its the only one that works well when flashed in nand. but when i try to build it, the following error is returned (after i imported the headers you provided):

 

root@omvbox:/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE# make
NOW IN default
KDIR is /lib/modules/4.4.194-rk322x/build
PWD is /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE
make -C /lib/modules/4.4.194-rk322x/build SUBDIRS=/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.194-rk322x'
  CC [M]  /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE/ax88179_178a.o
gcc: error: unrecognized command line option ‘-mgeneral-regs-only’
make[2]: *** [scripts/Makefile.build:284: /home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE/ax88179_178a.o] Error 1
make[1]: *** [Makefile:1473: _module_/home/roscar/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.4.194-rk322x'
make: *** [Makefile:33: default] Error 2
 

 

it looks like this issue is architecture related.  are you on ubuntu or debian?

Hello,

 

yeah there are some issues with the kernel headers packaging. In particular, as you noticed, there is a problem with the architecture armhf/arm64.

Everything should work if you first export some compilation variables:

export KSRC=/lib/modules/$(uname -r)/build
export CROSS_COMPILE=arm-linux-gnueabihf-
export ARCH=arm
make -j 4

The ARCH variable should fix your particular problem

[nokirunner]

On 8/16/2020 at 12:38 PM, jock said:

Update:

Legacy images have been updated with ssv6x5x driver working out of the box.!

 

The esp8089 driver has been included in the new images, but it still require to manually put the firmware files and wlan-esp8089 device tree overlay in armbianEnv.txt. I will get this tidied up and ready on next release

thanks mate, this makes life so much easier

[Reddwarf]

@jock Slightly off-topic question: I'm struggeling with an A5X Max 4k box, do you have any knowledge about this box and how to make it run Armbian? I would like to use it for something useful, the box is too light to be used as a paperweight (lol)...

[fabiobassa]

@Reddwarf

what processor is inside that A5X ? Rockchip too ?

[Reddwarf]

7 minutes ago, fabiobassa said:

@Reddwarf

what processor is inside that A5X ? Rockchip too ?

Yes it's a RK3328, ie 64bit, so not really related to this topic but I know nowhere else to ask...

[jock]

@Reddwarf Searching that box through google, I find an RK3328 device. Unfortunately I have no experience with rk3328, but I guess the general rules about rockchip socs probably applies to this one too. You may profit from the first post, specifically from the unbrick section and the rkdeveloptool instructions to make and restore backups/images.

You probably need a male-to-male USB cable to do such low-level tricks, but if you grab the original Android image you can probably be able to restore at least the original functionality.

[Reddwarf]

4 minutes ago, jock said:

@Reddwarf Searching that box through google, I find an RK3328 device. Unfortunately I have no experience with rk3328, but I guess the general rules about rockchip socs probably applies to this one too. You may profit from the first post, specifically from the unbrick section and the rkdeveloptool instructions to make and restore backups/images.

You probably need a male-to-male USB cable to do such low-level tricks, but if you grab the original Android image you can probably be able to restore at least the original functionality.

Yes I have the original Android image and can flash it with the factory tool. But I want to run Armbian and the problem is that the box does not boot from sdcard or usb with the factory bootloader. I'v tried to flash a new bootloader with the rkdeveloptool but the response is "this operation is not supported". If I flash Armbian in the box it does not boot. However, the factory tool is capable of flashing bootloader (I can see it does that while flashing Android), so if there is a way to replace the bootloader aection in the Android image I might be on dry ground.

[jock]

12 minutes ago, Reddwarf said:

Yes I have the original Android image and can flash it with the factory tool. But I want to run Armbian and the problem is that the box does not boot from sdcard or usb with the factory bootloader. I'v tried to flash a new bootloader with the rkdeveloptool but the response is "this operation is not supported". If I flash Armbian in the box it does not boot. However, the factory tool is capable of flashing bootloader (I can see it does that while flashing Android), so if there is a way to replace the bootloader aection in the Android image I might be on dry ground.

My hypothesis is that you are in loader mode, so you can upload a firmware update but can't upgrade your loader.

To be able to upgrade the loader also you must be in maskrom mode. To enter maskrom mode you can either gate the clock of the eMMC (via the screwdriver trick of the unbrick section) or run rkdeveloptool rd 3 while in loader mode.

Once you're there, first you have to "download" the loader binary on the soc (that's called usbplug in this stage) to initialize DDR memory and load the basic services of the SoC, and then you can finally upgrade the loader itself (see the rkdeveloptool db and ul commands on the first post on how to restore backups).

 

You may take a look to this repository for binaries for rk3328

[Reddwarf]

20 minutes ago, jock said:

My hypothesis is that you are in loader mode, so you can upload a firmware update but can't upgrade your loader.

To be able to upgrade the loader also you must be in maskrom mode. To enter maskrom mode you can either gate the clock of the eMMC (via the screwdriver trick of the unbrick section) or run rkdeveloptool rd 3 while in loader mode.

Once you're there, first you have to "download" the loader binary on the soc (that's called usbplug in this stage) to initialize DDR memory and load the basic services of the SoC, and then you can finally upgrade the loader itself (see the rkdeveloptool db and ul commands on the first post on how to restore backups).

 

You may take a look to this repository for binaries for rk3328

Thanks, how can I determine what binary I should use for updating the loader? If I run Cpu-z on the original Android is says that the cpu is a 3028, what is correct?

[hexdump]

you might have a look at this, but you are on your own then (no warranties or support from my side) - for me it worked to get my h96max h2 which cannot boot from sd card too working by installing an adjusted u-boot - https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328-no-sd-boot

[Reddwarf]

4 minutes ago, hexdump said:

you might have a look at this, but you are on your own then (no warranties or support from my side) - for me it worked to get my h96max h2 which cannot boot from sd card too working by installing an adjusted u-boot - https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328-no-sd-boot

Thanks, might need a bit modifying, I'll have to read me up on rk3328....

 

[jock]

2 hours ago, Reddwarf said:

Thanks, how can I determine what binary I should use for updating the loader? If I run Cpu-z on the original Android is says that the cpu is a 3028, what is correct?

Never heard about rockchip 3028, it is quite sure you have a rk3328, or maybe the little rk3318 brother.

To be sure, you should read what's printed on the soc itself. There is also this table: https://forum.xda-developers.com/showpost.php?p=56219933&postcount=2 that matches the USB vendor/device ids with the soc. I don't know if it is verified.

 

Once you got the SoC, you will need the usbplug binary for both the db and ul commands, but this will flash another rockchip proprietary loader, which I don't know it is what you want...

 

edit: I just read about @hexdump instructions, that's a good recipe on how to compile and install mainline u-boot as a bootloader, but I'm understand it correctly, there is some chain-loading between proprietary u-boot and mainline u-boot. You can customize the boot options and avoid being slave of the rockchip u-boot binaries, but requires manual intervention. I would point out some clarifications: as @fabiobassa once told me, the 0x2000 offset when using rl/wl commands of rkdeveloptool is due to maskrom or loader mode: in maskrom mode there is no offset, so you can write the entire eMMC/NAND. In loader mode the first 0x2000 sectors are hidden, hence the offset.

 

[fabiobassa]

Personally haven't a 3328 but most part of work on 3229 was " social engeneering"

Is quite un-probabily that in rockchip have made 2 millions different bootloaders and/or 2 millions ddrbin for all the mostrous amount of chip they have

Most probabily they have some generic that EARLY boot on 32 bit and some others that boot on 64 bit
In effect most of code of 3229 was related to ancient 3036 so should NOT be that difficult adapt to your particular case !

 

[victroniko]

On 8/3/2020 at 5:41 AM, jock said:

I prepared this other kernel module: esp8089.nop2p.ko  I blindly changed a couple of source code lines to avoid the p2p0 interface creation. I don't know if this works, but you may give it a chance. Overwrite the existing esp8089.ko with this one and reboot to see if it has any effect...

 

Quick update on ESP8089: with this module, it works every time 

 

Didn't do any speed tests as I'm somewhat far from the router (the box lost connection randomly, but my laptop does that too). General web browsing and system upgrades were on par with ethernet. Need to do final tests but I feel we're 95% there... a BIG thank you @jock!!

[xwiggen]

ok, I've got a MXQPro 2G/16G RK3228A which doesn't boot after rk322x-config to either setting. What does work is the rk3228a-box-mxq4kpro.dtb I took from https://github.com/knaerzche/LibreELEC.tv/releases/tag/b7186bc

 

[hexdump]

8 hours ago, jock said:

...

 

edit: I just read about @hexdump instructions, that's a good recipe on how to compile and install mainline u-boot as a bootloader, but I'm understand it correctly, there is some chain-loading between proprietary u-boot and mainline u-boot. You can customize the boot options and avoid being slave of the rockchip u-boot binaries, but requires manual intervention. I would point out some clarifications: as @fabiobassa once told me, the 0x2000 offset when using rl/wl commands of rkdeveloptool is due to maskrom or loader mode: in maskrom mode there is no offset, so you can write the entire eMMC/NAND. In loader mode the first 0x2000 sectors are hidden, hence the offset.

 

@jock @fabiobassa - to explain the difference between the addresses by the maskrom vs loader mode makes sense ... i think i did this hybrid setup with original initial boot blocks and mainline u-boot back then because i was thinking that this is the only way to get it working with the existing trust image ... where is it actually defined if trust images will be used or not - is it somewhere fused in the hw or is it just a matter of the initial boot blocks? if its just a matter of the boot blocks, then i should even be able to replace the entire boot with something adjusted self compiled maybe ... another reason i did it that way was that shortly before i did something similar for a rk3318 box for which there was no atf i could build myself (rk3328 one did not work) so i had to keep the original initial boot blocks there ...

 

best wishes - hexdump

[jock]

17 hours ago, hexdump said:

@jock @fabiobassa - to explain the difference between the addresses by the maskrom vs loader mode makes sense ... i think i did this hybrid setup with original initial boot blocks and mainline u-boot back then because i was thinking that this is the only way to get it working with the existing trust image ... where is it actually defined if trust images will be used or not - is it somewhere fused in the hw or is it just a matter of the initial boot blocks? if its just a matter of the boot blocks, then i should even be able to replace the entire boot with something adjusted self compiled maybe ... another reason i did it that way was that shortly before i did something similar for a rk3318 box for which there was no atf i could build myself (rk3328 one did not work) so i had to keep the original initial boot blocks there ...

 

best wishes - hexdump

I think the boot process is the same or very similar among rk322x and rk3318/rk3328. I had the time to study the rk322x boot and make some intresting experiments.

The standard firmware boot that uses proprietary rockchip binaries and sources usually do these steps:

1. the SoC ROM code reads the ddrbin at sector 0x40 and executes it to initialize DDR memory
2. the SoC ROM then reads the code that follows the ddrbin and finds the miniloader (you can find various versions of miniloaders from the kwiboo repository I linked before)
3. the miniloader takes control and checks for GPT partitions called "uboot" and "trustos", if partitions are found sets PTR_UBOOT and PTR_TRUSTOS pointers to the partitions sectors, otherwise sets the pointers to default values respectively of 0x2000 and 0x4000
4. the miniloader looks for the "LOADER" (that's exactly a string with uppercase characters) signature at PTR_UBOOT sector, if the signature is found loads u-boot in memory, otherwise increases the PTR_UBOOT pointer by 0x800 sectors and retries
5. the miniloader looks for "TRUST" signature at PTR_TRUSTOS to do the same job
6. the miniloader boots the trust os (that's a build of the ATF), which installs itself, and then boots u-boot
7. u-boot finally loads the device tree and boots the kernel

when you use prepare the u-boot and trust images with  loaderimage --pack command, is actually decorating uboot/trust image with a header (the LOADER/TRUST signatures, maybe other things like checksums and the memory location where the image should be loaded into).

Likewise you can extract u-boot and trust images from flash memory looking at those locations and obtain the originals using loaderimage --unpack command. @knaerzche extracted a working trustos from a rk3228 box image this way and now LibreELEC uses that blob as trustos for all rk322x images. I'm also using a trustos extracted this way to boot the multitool, and it works pretty well.

 

The other boot process that uses mainline u-boot and Opensource OPTEE (in place of ATF) is as follows:

1. The SoC ROM code reads the u-boot TPL at sector 0x40, this initializes DDR memory
2. the SoC ROM code reads the u-boot SPL that immediately follows the TPL
3. u-boot SPL executes the OPTEE trustos
4. u-boot SPL executes the main u-boot
5. u-boot loads device tree and boots the kernel

For some extents, you can mix the two boot processes, for example in Armbian I use the second boot process, but at the step 1 I use the proprietary ddrbin because u-boot TPL does not support DDR2 memories.

 

My guess is that the rk3318/rk3328 boot process is very much the same

 

[jock]

On 8/18/2020 at 7:22 PM, xwiggen said:

ok, I've got a MXQPro 2G/16G RK3228A which doesn't boot after rk322x-config to either setting. What does work is the rk3228a-box-mxq4kpro.dtb I took from https://github.com/knaerzche/LibreELEC.tv/releases/tag/b7186bc

 

Hum, can you be more specific on what image you installed, what settings you choose in rk322x-config and about your hardware?

Normally the only setting that can prevent booting is setting eMMC in place of NAND and viceversa.

Also when you select eMMC in rk322x-config it also enables DDR mode which is usually safe but may be a source of troubles.

 

In such case, you can run rk322x-config and then manually remove the emmc entry from overlays in /boot/armbianEnv.txt  and then reboot

[nokirunner]

Guys, I have something new, I don't know if it's only valid on my device or if it concerns others.
With the Armbian image 20.08.0 - Ubuntu Focal Desktop - Mainline kernel 5.6.19 which contains the LIMA open source video drivers I found that the default configuration the acceleration does not work. these socs have two videocard card0 and card1, on my xorg configuration  card0 was set, it worked in the sense that the desktop started but the video acceleration was bad. I changed this setting to card1 and voilà the acceleration is activated as it should.
the file to edit is this: /etc/X11/xorg.conf.d/40-serverflags.conf
change card0 with card1
 

Section "ServerFlags"
        Option "AutoAddGPU" "off"
EndSection

Section "Device"
    Identifier "meson"
    Driver "modesetting"
    Option "kmsdev" "/dev/dri/card1" #card1 now is good
EndSection

My device is a scishion-v88 I don't know if it is a problem that only concerned my device or is it a much more general problem, in the meantime I have reported it, in case other devices are afflicted by the same problem with the LIMA drivers.

@jock I tried to activate the wifi ssv6x5x drivers on the 5.6 kernel but I couldn't, are the new drivers working on the legacy kernel also compatible with the 5.6 kernel?

[jock]

1 hour ago, nokirunner said:

Guys, I have something new, I don't know if it's only valid on my device or if it concerns others.
With the Armbian image 20.08.0 - Ubuntu Focal Desktop - Mainline kernel 5.6.19 which contains the LIMA open source video drivers I found that the default configuration the acceleration does not work. these socs have two videocard card0 and card1, on my xorg configuration  card0 was set, it worked in the sense that the desktop started but the video acceleration was bad. I changed this setting to card1 and voilà the acceleration is activated as it should.
the file to edit is this: /etc/X11/xorg.conf.d/40-serverflags.conf
change card0 with card1
 

Section "ServerFlags"
        Option "AutoAddGPU" "off"
EndSection

Section "Device"
    Identifier "meson"
    Driver "modesetting"
    Option "kmsdev" "/dev/dri/card1" #card1 now is good
EndSection

My device is a scishion-v88 I don't know if it is a problem that only concerned my device or is it a much more general problem, in the meantime I have reported it, in case other devices are afflicted by the same problem with the LIMA drivers.

@jock I tried to activate the wifi ssv6x5x drivers on the 5.6 kernel but I couldn't, are the new drivers working on the legacy kernel also compatible with the 5.6 kernel?

 

Dunno, on my setup if I left card0 I get hardware acceleration and glxinfo/es2_info show me that lima driver is in use, but desktop experience is not so great and the cursor is often flashing.

If I use card1 the desktop experience is better, but there is not hardware acceleration and glxinfo/es2_info show me llvmpipe, which is software renderer.

 

I think Lima driver and mesa bits are just not working very nice with X11, probably they deliver the best experience using wayland-based desktop environments. Don't want to say and heresy, but xfce lately is becoming quite slow, people says lxde is snappier on such hardware.

 

About ssv6x5x, I did not even try it on mainline kernel, it is a miracle it compiles and works on legacy 4.4 Probably the drivers requires a complete overhaul to work well with mainline kernels.

Its sibling, the ssv6051 driver, has been left behind by rockchip itself in the jump to the 4.19 kernel they recently made. ssv6x5x and ssv6051 are very similar, and both of them are incredibly messy!

[nokirunner]

@jock right now i'm trying to understand each other better, apparently, lima is just "the rederer" every producer then has his own drivers or something like that .. in our case it should be rockchip ... i'm just investigating right now

https://gitlab.freedesktop.org/lima/web

 

Quote

xorg.conf

For xserver >=1.20, if you have issues with starting X, you may try the following xorg.conf:

Section "ServerFlags"
        Option  "AutoAddGPU" "off"
        Option "Debug" "dmabuf_capable"
EndSection

Section "OutputClass"
        Identifier "Lima"
        MatchDriver "<display DRM driver>"
        Driver "modesetting"
        Option "PrimaryGPU" "true"
EndSection

Note that the Mali GPU is only for rendering, each SoC has its own separate display engine. You need to find your display engine DRM driver name and replace <display DRM driver> with it. For example, see the list of display drivers mentioned above.

above in the wiki :
 

Quote

 

Display drivers

Allwinner: sun4i-drm

Amlogic: meson

Exynos: exynos

Ericsson MCDE: mcde

Rockchip: rockchip

Tinydrm: tinydrm

 

edit: the display drivers  it could be these:
https://github.com/rockchip-linux/libmali

 

which appears to have been updated to work with mesa 20.1.5 APIs... which as far as I understand are the blobs updated to work with the new mesa

[xwiggen]

On 8/20/2020 at 9:24 AM, jock said:

Hum, can you be more specific on what image you installed, what settings you choose in rk322x-config and about your hardware?

Normally the only setting that can prevent booting is setting eMMC in place of NAND and viceversa.

Also when you select eMMC in rk322x-config it also enables DDR mode which is usually safe but may be a source of troubles.

 

In such case, you can run rk322x-config and then manually remove the emmc entry from overlays in /boot/armbianEnv.txt  and then reboot

I've installed images from download page (bother buster linux 4, focal linux 4) and installed them to eMMC with multitool. They boot nicely and are stable.

I did use the libreElec dtb file, then the alternating led flashing red/blue went away and blue stayed on.

 

Right now after testing some days, I can't boot libreElec from SD or eMMC (which worked ok previously, with erasing flash thru multitool), also adding dtb now leaves me with an unbootable system

??

I can flash with multitool one of the stable images. If i select RK3228A, RK3228B or RK3229 and reboot, I get a message that UUID=.... not found and drops to an initramfs prompt.

 

really weird.

 

 

[jock]

8 minutes ago, xwiggen said:

I've installed images from download page (bother buster linux 4, focal linux 4) and installed them to eMMC with multitool. They boot nicely and are stable.

I did use the libreElec dtb file, then the alternating led flashing red/blue went away and blue stayed on.

 

Right now after testing some days, I can't boot libreElec from SD or eMMC (which worked ok previously, with erasing flash thru multitool), also adding dtb now leaves me with an unbootable system

??

I can flash with multitool one of the stable images. If i select RK3228A, RK3228B or RK3229 and reboot, I get a message that UUID=.... not found and drops to an initramfs prompt.

 

really weird.

 

 

I don't understand exactly what you mean when you say "libreelec dtb" and adding "dtb"...

Newer images (like those in the armbian download page) use device tree overlays, so you don't have to substitute or handle dtb files manually.

 

Did you try to follow my suggestion to run rk322x-config, don't reboot yet but remove emmc string  from overlays in /boot/armbianEnv.txt and then reboot?

[jock]

21 hours ago, nokirunner said:

@jock right now i'm trying to understand each other better, apparently, lima is just "the rederer" every producer then has his own drivers or something like that .. in our case it should be rockchip ... i'm just investigating right now

https://gitlab.freedesktop.org/lima/web

 

above in the wiki :
 

edit: the display drivers  it could be these:
https://github.com/rockchip-linux/libmali

 

which appears to have been updated to work with mesa 20.1.5 APIs... which as far as I understand are the blobs updated to work with the new mesa

Yes every manufacturer has its own 2D hardware, Lima handles the Mali graphics which is 3D only; but when you use X.org with modesetting driver, it uses glamor desktop acceleration, which in turn doesn't use the 2D hardware but uses OpenGL to accelerate the desktop. Confused?

I am. In my opinion X.org people choose this way to handle things and we have a driver (modesetting) that works with many OpenGL drivers, but with suboptimal performance because bad 3D is used (Mali 400 is the poorest GPU on the ARM market today) in place of good dedicated 2D hardware.

 

I tried also the suggested xorg.conf options, and the X.org server started correctly with hardware acceleration, but I didn't notice any particular performance benefit.

I would be happy to get the same performance as kernel 4.4 with armsoc, but at the moment it seems that Lima just can't afford that.

 

Note: you can still run the proprietary Mali stack (kernel driver + opengl userland libraries) and Armsoc on kernel 5.6, but you have to compile the kernel driver yourself and still they have limitations (no OpenGL driver, just OpenGL ES)

[hexdump]

@jock - missing opengl can be worked around quite well with gl4es: https://github.com/ptitSeb/gl4es

[nokirunner]

2 hours ago, jock said:

Yes every manufacturer has its own 2D hardware, Lima handles the Mali graphics which is 3D only; but when you use X.org with modesetting driver, it uses glamor desktop acceleration, which in turn doesn't use the 2D hardware but uses OpenGL to accelerate the desktop. Confused?

I am. In my opinion X.org people choose this way to handle things and we have a driver (modesetting) that works with many OpenGL drivers, but with suboptimal performance because bad 3D is used (Mali 400 is the poorest GPU on the ARM market today) in place of good dedicated 2D hardware.

@jock From what I have investigated, I don't think it's a question of SOC performance, I think the driver especially the kernel side dri rockchip is badly built at some point. It should take care of the management of the hdmi and of the video buffering and little more and it is evident that it is poorly managed, so much so that when we put card1 instead of card0 it becomes 2D fast but the hdmi loses the management of the monitor resolutions, and even in the "very slow" mode with card0 the resolution management of the monitor works only to a limited extent (many resolutions are missing) it may also be that in the latest kernel these problems have already been solved, I noticed that these drivers, both on the kernel side and on the mesa are heavy developed.    Looking at the git of the rockchip dri kernel you see there are a lot of changes in the last few months, i would be curious to see if the upcoming kernel 5.9  has fixed these known problems.

[jock]

11 hours ago, nokirunner said:

@jock From what I have investigated, I don't think it's a question of SOC performance, I think the driver especially the kernel side dri rockchip is badly built at some point. It should take care of the management of the hdmi and of the video buffering and little more and it is evident that it is poorly managed, so much so that when we put card1 instead of card0 it becomes 2D fast but the hdmi loses the management of the monitor resolutions, and even in the "very slow" mode with card0 the resolution management of the monitor works only to a limited extent (many resolutions are missing) it may also be that in the latest kernel these problems have already been solved, I noticed that these drivers, both on the kernel side and on the mesa are heavy developed.    Looking at the git of the rockchip dri kernel you see there are a lot of changes in the last few months, i would be curious to see if the upcoming kernel 5.9  has fixed these known problems.

this mesa issue about Lima seems very similar to what we are experiencing: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3033

[nokirunner]

2 hours ago, jock said:

this mesa issue about Lima seems very similar to what we are experiencing: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3033

yes i had seen, yesterday i had peeked a little bit all bugtrackers, but i still don't believe it's a 3D side , problem issue, it's a bug in buffering kernel DRI driver badly managed somehow, i don't know if you have noticed, but the slowness is in fits and starts (a singhiozzo) as if it were speeded up, and then the buffering cycle stops for some reason, especially noticeable when drag a window, it is just noticeable that it is something derived from a poorly done mechanism, sometimes slow so much that if we try to click some icon, the refresh is so poor that it fails to operate the function.
I am even more convinced of this because by going to see the patches they worked on the management of the hdmi

https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip

Quote

Commits on Jun 23, 2020

drm: bridge: dw-hdmi: Pass drm_display_info to dw_hdmi_support_scdc()

 

Laurent Pinchart authored and sravnborg committed on 23 Jun

drm: bridge: dw-hdmi: Constify mode argument to dw_hdmi_phy_ops .init()

 

Laurent Pinchart authored and sravnborg committed on 23 Jun

drm: bridge: dw-hdmi: Pass drm_display_info to .mode_valid()

 

Laurent Pinchart authored and sravnborg committed on 23 Jun

drm: bridge: dw-hdmi: Pass private data pointer to .mode_valid()

and there are other patches under review that may be coming: (dw-hdmi bridging)
https://patchwork.freedesktop.org/project/dri-devel/list/?submitter=15894

well, at least hopefully I'm right ..

the "2D" just that there is glamor, should be accelerated without problems by the LIMA driver, instead it is totally broken (singhiozzo). while windows that contain 3D elements is accelerated working fine. The rockchip custom "card" should only manage the buffering and the hdmi functions, and in any case it is so slow , that you can see that it is not merely a question of poor performance, it is as if the 2D rastering functions were managed by "cpu" functions , as if the gpu drivers totally missing (reminds me of old windows xp machines when drivers are not installed yet) or thinking about it better, managed by llvmpipe 3D emulation via cpu ... just like when we put "card1" ... that 2D is accelerated to a lot, but 3D is managed by llvmpipe via cpu

however we are here to try hypothesize the problem, when the best thing to do would be to make the problem known with a bug report, I would do it, but I have not the faintest idea how to describe the problem at the technical level...