hexdump

@Nuno Cruz - the original dtb is for android and most probably for another kernel version too, so there is no way to make it work without a lot of adaption work

allwinner h616 is not supported yet by linux, so no way forward here ...

@jock - your theory sounds good i think - might be the case ... the 4.4.189 kernel config i used as starting point was the one from your last 4.4.189 based images ... this is the one i used then after a "make oldconfig" which resulted in the working 4.4.194 kernel: https://github.com/hexdump0815/linux-rockchip-rk322x-kernel/blob/96bf87bd0014f2d5a17ddcd1202980d2023d2302/config.322 best wishes - hexdump

@fabiobassa - good point - i now used the config from the 4.4.189 kernel plus make oldconfig for building 4.4.194 and the resulting kernel now boots and works perfectly fine update: i did not yet find the console connector on this box, but of all the librelec images it only booted the ddr2 one, so i assume it has dd2 memory ... about the rk3228: the funny thing is that it runs nicely with the 1.4ghz clock speed of the rk3229-xt-mx4vr-v01.dtb ... @jock - maybe your 4.4.194 kernel config should be reviewed and potentially adjusted? btw. i can confirm that your above suggested cursor fix for your armsoc xorg server works well ... a lot of thanks and best wishes - hexdump

as said this is still very much work in progress i guess ...

@jock - i tried reducing the opp tables on mainline to 1.2ghz and to lower the opp and gpu clocks on the rockchip kernel - nothing changed. also with the working 4.4.189 kernel it works with the full opp and gpu clocks without any problem. @fabiobassa - here is the efuse content: root@r39-4k:~# hexdump -C /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000 52 4b 23 82 81 d4 70 55 52 4b 4e 30 39 30 32 35 |RK#...pURKN09025| 00000010 00 00 00 00 01 2c 15 03 00 03 81 00 00 80 00 00 |.....,..........| how to interpret this? update: i also tried to boot the 4.4.194 kernel with the 4.4.189 dtb to rule out potential dtb changes - it does not work the same way the 4.4.194 kernel with its own dtb does not work, so the reason for the problems should be somewhere in code changes between 4.4.189 and 4.4.194 i guess ... a lot of thanks in advance and best wishes - hexdump

gles3.0 is not ready yet - you might give this a try: https://www.phoronix.com/scan.php?page=news_item&px=Panfrost-Gallium3D-GLES-3.0

@jock - i did some more tests: i build a kernel myself based on your sources and patches but with HIGHMEM disabled again and the 4.4.194 kernel still hangs in the middle of the boot on my 2gb r39-4k rk3229 box (4.4.189 works fine with just showing 1gb ram and 4.4.194 works well on my 1gb mk809iv rk3228 box) - does it work for you on any rk3229 2gb box? do you have an idea which of the patches between your 4.4.189 and 4.4.194 kernels might trigger this hanging? i also built a 5.4.22 mainline kernel based on your patches - it boots further (i can get into x11 even with it) but starts to be quite erratic and eventually hangs later - but it at least discovers the 2gb ram properly according to the logs best wishes - hexdump

@jock - what is this repo for actually? - https://github.com/paolosabatino/rockchip-4.4-mali - i thought that the rockchip tree already comes with its gpu subtree (https://github.com/rockchip-linux/kernel/tree/stable-4.4-rk3288-linux-v2.x/drivers/gpu/arm) ... and: did you already try to get the mali blobs somehow working with mainline on the rk322x? a lot of thanks in advance and best wishes - hexdump

@Alessandro - you may try the following on a linux system, assuming your sdcard is in /dev/mysdcard (whichever device this might be in your case): "zcat working Librelec-xyz.img.gz | dd of=/dev/mysdcard bs=512 count=32768 status=progress" then use "fdisk /dev/mysdcard" to create a partition starting at sector 32768 (something like o, n, p, 1, 32768, enter, w, q - might be wrong - all off mind) and then dump the armbian image to it: "xzcat Armbian-xyz.img.xz | dd of=/dev/mysdcard bs=512 skip=8192 seek=32768 status=progress" and then try to boot that sd card - i think the armbian image uses an offset of 8192 sectors (@jock please correct me if i'm wrong here) - i never tried it this way, but in theory it should work and maybe be the fastest way to get libreelec boot and armbian rootfs combined good luck and best wishes - hexdump

i think it could still be trust.img related: my box absolutely reliably shut down after exactly 60 seconds each time (and in those 60 seconds booted fine up until x11) before i wrote the proper trust.img file obtained from the emmc to the sd card - since then it is working perfectly fine ...

@jock - i just tried 4.4.194 on the mk809iv too now and there it works, but the mouse cursor is gone in xorg armsoc, which ist still there with 4.4.189. @Alessandro - can you please measure the time between power-on and the self-shutdown of the box? - maybe its like with my r39-4k a problem with the trust.img? for me that time was exactly one minute each time ... best wishes - hexdump

@jock - thanks a lot - i'll give them a try soon ... update: i gave the 4.4 versions (both) a try on the 2gb ram r39-4k and they hang at some point - retried the old kernel and that one still works (but only exposes 1gb ram) ... could this be the himem instability you mentioned? will have to check in more detail in the next days ... sadly without a working serial console its hard really see where it hangs (screen goes black and keyboard is dead) best wishes - hexdump

@jock - thanks a lot for the info - looking forward to your new build and images ... meanwhile i got my mk809iv working too in the same way without having to erase anything on it using the liberelec mk809iv dtb ... btw. does anyone of you know how to switch those hdmi sticks into update/loader mode? i so far did not find any switch yet ... is there an easy way to open those devices? a lot of thanks and best wishes - hexdump

i think is is as far as you can get - it simply is that slow (but at least the cpu keeps more free as the gpu is doing the rendering - with wayland it is supposed to be a bit faster due to less memory copy around in that case) and i also get those segmentation faults from time to time ... keep in mind those blobs were never ment for mainline

one thing is a bit strange: the box is supposed to have 2gb of ram and even the android dmesg shows 2gb of ram which usually can be trusted quite well but with linux i only see 1 gb and some strange high memory remarks: [ 0.000000] Truncating RAM at 0x60000000-0xe0000000 to -0xa0000000 [ 0.000000] Consider using a HIGHMEM enabled kernel. ... [ 0.000000] On node 0 totalpages: 258560 [ 0.000000] free_area_init_node: node 0, pgdat b1228ec0, node_mem_map e76ba000 [ 0.000000] Normal zone: 2304 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 258560 pages, LIFO batch:31 ... [ 0.000000] Memory: 866500K/1034240K available (12835K kernel code, 867K rwdata, 3160K rodata, 800K init, 580K bss, 36668K reserved, 131072K cma-reserved) [ 0.000000] Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) lowmem : 0xb0000000 - 0xf0000000 (1024 MB) modules : 0xaf000000 - 0xb0000000 ( 16 MB) .text : 0xb0008000 - 0xb0c910dc (12837 kB) .init : 0xb1094000 - 0xb115c000 ( 800 kB) .data : 0xb115c000 - 0xb1234da4 ( 868 kB) .bss : 0xb1236000 - 0xb12c7174 ( 581 kB) does the rk3229 support 2gb of ram natively without any tricks? and another question: are there any mali blobs (x11, fbdev, wayland) available or working for rk3229? best wishes - hexdump

this xorg conf does not refer to the armsoc driver - here is a proven to be working example for an armsoc xorg.conf: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/X11/xorg.conf.d.samples/01-armsoc.conf

here are some images of the board ... i think i just fried a serial to usb converter while testing the three copper pins on the back side a few minutes ago ... in general: the box is booting perfectly fine, its just that it hangs / shuts down or whatever exactly one minute after the box was powered up for any kind of image i try (libreelec, armbian) ... i also tried to extract the trust.img via rkdeveloptool from emmc (rkdeveloptool rl 0x4000 0x2000 rl-0x4000-0x2000.out) and wrote it to the proper position on the sd card (dd if=rl-0x4000-0x2000.out of=/dev/sdx bs=512 seek=12288) but it did not make any difference in the end ... update: the offset for writing it to the sd card was wrong above - here are the proper commands and now the box is working fine rkdeveloptool rl 0x4000 0x2000 rl-0x4000-0x2000.out dd if=rl-0x4000-0x2000.out of=/dev/sdx bs=512 seek=24576 but if the board looks familiar to you and you know where the serial port connectors are, i would still be interested to know that ...

xorg seems to use the modeset driver, but you need to use the armsoc driver - something is wrong with your xorg config ... for the legacy mali driver the xorg server does not need the mali libs yet - only the gl app need them

maybe build your own kernel with lima disabled (i'm not sure, but i think it might conflict with the old mali driver even if the module is not loaded) ... make sure you apply those two patches: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-gem-cma-Export-with-handle-allocator.patch https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av7/sunxi-drm-sun4i-Add-GEM-allocator.patch here are my own notes on getting this to work, which are verified to work up until v5.4 kernels: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.av7-mali-sunxi good luck and best wishes - hexdump

update: i just tried the same with my own ubuntu root fs and got it booting to modesetting x11 fine - but always, be it in x11 or on the console, after nearly exactly 1 minute after powering on the system the screen goes black and the system hangs ... i think i read something about that and that there was a fix for that - do you maybe know the fix? looks a bit like some watchdog thing or something similar ... a lot of thanks in advance and best wishes - hexdump

@jock - i think at least on newer rk3229 boxes (with a newer boot loader) you seem to be able to boot from sd card without having to erase the emmc content. i just did an experiment on my r394k rk3229 box: i took your ubuntu image and later took the root fs from it, then dd'ed the first 16mb (boot stuff) from a working libreelec build (https://github.com/knaerzche/LibreELEC.tv/releases/tag/RK322x-le92-0bca75f and https://forum.libreelec.tv/thread/21117-unoffical-le-9-2-images-for-rk3229-rk3228/?pageNo=1) to a fresh sd card, created a partition on it starting at sector 32768 (to not overwrite the boot stuff), made that active in fdisk (not sure if this is really required for u-boot to search for its extlinux there), created an ext4 fs on it, rsynced your image root fs to it, created an /extlinux/extlinux.conf with the following content: TIMEOUT 30 DEFAULT rk3229 MENU TITLE rk3229 boot options LABEL rk3229 MENU LABEL rk3229 kernel LINUX ../boot/vmlinuz-4.4.189-rk322x FDT ../boot/dtb-4.4.189-rk322x/rk3229-r329q.dtb INITRD ../boot/initrd.img-4.4.189-rk322x APPEND earlyprintk root=UUID=<put-your-root-fs-uuid-here> console=ttyS2,115200n8 console=tty0 rootwait rootfstype=ext4 consoleblank=0 loglevel=8 adjusted the root fs uuid accordingly, put the sd card into the box and powered it on ... and it booted fine from the sd card although the android on the internal emmc is still there. i noticed something similar on a rk3318 box too: the rockchip bootloader initial stages seem to load a u-boot.img from the sd card if there is one there (i think it was at sector 16384 offset) and i think this is how it works here: emmc boot loader starts with its first stage and sees that there is a u-boot.img stage on the sd-card and starts this one and from there it goes on. with my box the system boots to a login prompt and then i think tries to start x11 - there it seems to hang and the keyboard got dead (num lock which is working fine during boot does not respond anymore - i tried all usb ports etc., mouse is still fine though, i.e. it got power still and its led was on) so that i cannot switch back to the console. i tried to disable the x11 startup on the root fs of the image but failed - do you know a quick way to disable it directly on the filesystem? do you have an idea why the system locks up? sadly this box does not seem to have serial console connectors is your kernel supposed to work on rk3228a too? if yes, then i might give it a try on my mk809iv as well ... a lot of thanks for your work on getting armbian working on those boxes and best wishes - hexdump

another thing to keep in mind is that your user needs access to /dev/mali - usually granted via some udev rule and the video group (usermod -a -G video username) ... example udev rule: https://github.com/hexdump0815/imagebuilder/blob/master/files/extra-files/etc/udev/rules.d/50-mali.rules good luck and best wishes - hexdump

please keep in mind that my dtb file was for a mainline kernel and not for the 4.4 rockchip kernel used in some images ...

@gaelsee - you might give my rk3328-t9 dtb from the rk3328 tv box thread here a try (you should find it going backwards a few pages in that thread) - that should at least solve the sd card problem ... good luck and best wishes - hexdump