kruzer

Sure, I don't remember exact steps, but I had to modify the openvfd code to make it work: https://github.com/kruzer/linux_openvfd/commit/1d83779bb9d525e6593b97f7e893cccc73080d4d after building openfvd driver with this change it should be working ok.

@Dragaomaybe this is the problem with eMMc failure in those boxes, mentioned by @jock in the very first post in this thread. You can still use it as a device booted from sd or usb

@Dragao how to root this box with Magisk?

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

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?

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.

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?

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.

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

No, only dtb is needed to compare, try the instructions provided here by @lucky62 If you don't have su preinstalled on android, I will show you how I did it from backup, but some listings from running android will be required.

I hoped for more descriptive errors, but those give no clue. Next step is to compare dtb extracted from original android image, do you have a backup?

It looks ok, I can't see any big difference to mine: http://ix.io/3nfR. Does multitool boot on this box with hdmi? You can compare this log to dmesg form multitool, check if the hdmi lines look similar.

Thank you @jock problem solved, it is building now, without issues.

Yes, there is a problem with one patch: Processing file /Armbian/rk3318/patch/kernel/rockchip64-current/add-csgpio-to-rockchip-spi.patch 1 out of 4 hunks FAILED -- saving rejects to file drivers/spi/spi-rockchip.c.rej spi-rockchip.c.rej

run armbian diagnostic with: sudo armbianmonitor -u and send the generated link, maybe someone clever would be able to find out what is wrong with your hdmi settings

I am struggling with this, and can't build. Steps to reproduce: git clone --depth=1 -b rk3318 https://github.com/paolosabatino/armbian-build.git rk3318 cd rk3318 ./compile.sh BOARD=rk3318-box BRANCH=current BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=yes KERNEL_CONFIGURE=no and after a few minutes, it gives compiler error: drivers/spi/spi-rockchip.c: In function ‘rockchip_spi_probe’: drivers/spi/spi-rockchip.c:756:16: error: ‘rockchip_spi_setup’ undeclared (first use in this function); did you mean ‘rockchip_spi_set_cs’? ctlr->setup = rockchip_spi_setup; ^~~~~~~~~~~~~~~~~~ rockchip_spi_set_cs drivers/spi/spi-rockchip.c:756:16: note: each undeclared identifier is reported only once for each function it appears in drivers/spi/spi-rockchip.c:757:18: error: ‘rockchip_spi_cleanup’ undeclared (first use in this function); did you mean ‘rockchip_spi_can_dma’? ctlr->cleanup = rockchip_spi_cleanup; ^~~~~~~~~~~~~~~~~~~~ rockchip_spi_can_dma Do I need any packages/sources installed? Te rk322x-box Armbian version is building on the same machine without issues.

cool ;-) So you can connect TX too, and you should be able to go through initial armbian config, set password and made it also available to ssh connection.

On my box running focal desktop, cat /proc/cmdline shows 1500000: root=UUID=de2057ff-2fc6-418c-b583-7a1e2dbe8219 rootwait rootfstype=ext4 console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=d25de264-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1

I read somewhere that default baudrate for rockchip is 1500000, i assume you used 115200 instead of 112500 did you try with hdmi disconnected?

I haven't tried with this box, I was using uart on my previous one, where it was clearly marked (TX, RX and GND): there is a similar place on my rk3318 board near the leds, but with no inscriptions and I am not sure if it will work: does your look the same?

Sure, it is big image of original 64GB drive, gzipped 2GB, available here tvbox3318-backup.gz

If that is the case, you should connect a serial console to the board and log messages (errors) from booting process (they are available before hdmi output is established). It may help to detect the reason of booting problem.

The first post in this thread is good point to start. 1. Burn the image with ubuntu focal to sd card and boot it. Follow the "Quick installation instructions to boot from SD Card" 2. If it is running ok, burn the same image to emmc. "Quick installation instructions on eMMC"

@jock thank you very much, it is working 👍

That would be great :-) Anyway, I hope I've correctly extracted dts from android backup made with multitool from my box. I am attaching it with the dmesg output from running android firmware. h96max.dts android_dmesg.txt