lucky62

@paradigmanbelow are messages from my box. Looks very similar but I have a different controller. I cannot help more...
From your messages - maybe this is the problem:

 
# dmesg | grep -i openvfd [ 351.437611] openvfd: loading out-of-tree module taints kernel. [ 351.438416] openvfd: module verification failed: signature and/or required key missing - tainting kernel [ 351.440096] OpenVFD: Version: V1.4.0 [ 351.440121] OpenVFD: vfd_gpio_clk: Empty. [ 351.440127] OpenVFD: vfd_gpio_dat: Empty. [ 351.440132] OpenVFD: vfd_gpio_stb: Empty. [ 351.440144] OpenVFD: vfd_gpio0: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 351.440152] OpenVFD: vfd_gpio1: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 351.440162] OpenVFD: vfd_gpio2: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 351.440171] OpenVFD: vfd_gpio3: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 351.440180] OpenVFD: vfd_gpio_protocol: #0 = 0x00; #1 = 0x00; [ 351.440188] OpenVFD: vfd_chars: Empty. [ 351.440193] OpenVFD: vfd_dot_bits: Empty. [ 351.440200] OpenVFD: vfd_display_type: Empty. [ 351.440216] OpenVFD: Detected gpio chips: gpio0, gpio1, gpio2, gpio3, ff100000.syscon:gpio. [ 351.440222] OpenVFD: Failed to verify VFD configuration file, attempt using device tree as fallback. [ 351.441087] OpenVFD: openvfd_gpio_clk: pin = 83, flags = 0x00 [ 351.441111] OpenVFD: openvfd_gpio_dat: pin = 86, flags = 0x00 [ 351.441138] OpenVFD: openvfd_gpio_stb: pin = 82, flags = 0x00 [ 351.441150] OpenVFD: openvfd_gpio0 pin entry not found [ 351.441156] OpenVFD: openvfd_gpio1 pin entry not found [ 351.441162] OpenVFD: openvfd_gpio2 pin entry not found [ 351.441171] OpenVFD: openvfd_gpio3 pin entry not found [ 351.441176] OpenVFD: chars_prop = 00000000c43836d4 [ 351.441185] OpenVFD: chars_prop->length = 5 [ 351.441189] OpenVFD: char #0: 4 [ 351.441195] OpenVFD: char #1: 0 [ 351.441202] OpenVFD: char #2: 1 [ 351.441208] OpenVFD: char #3: 2 [ 351.441213] OpenVFD: char #4: 3 [ 351.441222] OpenVFD: dot_bits_prop = 000000001c63f005 [ 351.441227] OpenVFD: dot_bits_prop->length = 7 [ 351.441233] OpenVFD: dot_bit #0: 0 [ 351.441240] OpenVFD: dot_bit #1: 1 [ 351.441246] OpenVFD: dot_bit #2: 2 [ 351.441251] OpenVFD: dot_bit #3: 3 [ 351.441258] OpenVFD: dot_bit #4: 4 [ 351.441262] OpenVFD: dot_bit #5: 5 [ 351.441269] OpenVFD: dot_bit #6: 6 [ 351.441277] OpenVFD: display.type = 3, display.controller = 0, pdata->dev->dtb_active.display.flags = 0x00 [ 351.442023] OpenVFD: Select FD628 controller [ 351.442217] OpenVFD: SW SPI 3-wire interface intialized (LSB mode)
 

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

Update!
 
New testing minimal and xfce desktop debian images are available on first page!
Latest kernel 5.15: plenty of fixes and upgrades for hardware video decoding Initial (and untested) support for boards with sdcard on external controller U-boot v2021.07, should make USB2 boot more reliable To test hardware video decoding capabilities follow this link to a tutorial with prebuilt mpv binary and instructions on how to use it.

Hello all,
I would like to have a WIFI/BT working on my X88 Pro 10 box.
If I understand correctly I need two things:
Corect DTB file Driver for specific hardware (directly in kernel or compiled as module) Am I right? Any other important point?
 
I have extracted the DTB from running Android - steps I done:
start the Android on TV box install and configure the SSH Server App (Dropbear) connect to Android via SSH be root (su - device must be rooted, usually already is) find the boot partition (ls -l /dev/block/by-name/) I found this: lrwxrwxrwx 1 root root 21 1970-01-01 01:00 boot -> /dev/block/mmcblk1p11 dump partition to the file boot.img (dd if=/dev/block/mmcblk1p11 of=boot.img) move the boot.img to the PC install extract-dtb python package (pip install extract-dtb) extract DTB from boot.img (extract-dtb boot.img) install device-tree-compiler (apt-get install device-tree-compiler) decompile DTB to DTS (dtc -I dtb -O dts -o x88_pro_10_rk3318.dts 01_dtbdump_rockchip,rk3328-box-liantong.dtb) Some notes.
extracted DTB is quite big:
# extract-dtb boot.img Dumped 00_kernel, start=0 end=19752960 Dumped 01_dtbdump_rockchip,rk3328-box-liantong.dtb, start=19752960 end=33554432 Extracted 1 appended dtbs + kernel to dtb # ls -l dtb/ total 32772 -rw-r--r-- 1 root root 19752960 apr 11 16:07 00_kernel -rw-r--r-- 1 root root 13801472 apr 11 16:07 01_dtbdump_rockchip,rk3328-box-liantong.dtb  
It was decompiled successfully but some warning reported (not sure if this is important):
 
# dtc -I dtb -O dts -o x88_pro_10_rk3318.dts 01_dtbdump_rockchip,rk3328-box-liantong.dtb x88_pro_10_rk3318.dts: Warning (unit_address_vs_reg): /usb@ff600000: node has a unit name, but no reg property x88_pro_10_rk3318.dts: Warning (unit_address_vs_reg): /regulators/regulator@0: node has a unit name, but no reg property x88_pro_10_rk3318.dts: Warning (unit_address_vs_reg): /regulators/regulator@1: node has a unit name, but no reg property x88_pro_10_rk3318.dts: Warning (unit_address_format): /reserved-memory/drm-logo@00000000: unit name should not have leading 0s x88_pro_10_rk3318.dts: Warning (simple_bus_reg): /regulators/regulator@0: missing or empty reg/ranges property x88_pro_10_rk3318.dts: Warning (simple_bus_reg): /regulators/regulator@1: missing or empty reg/ranges property x88_pro_10_rk3318.dts: Warning (avoid_unnecessary_addr_size): /syscon@ff100000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property x88_pro_10_rk3318.dts: Warning (avoid_unnecessary_addr_size): /regulators: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property x88_pro_10_rk3318.dts: Warning (graph_child_address): /hdmi@ff3c0000/ports/port: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary x88_pro_10_rk3318.dts: Warning (graph_child_address): /tve@ff373e00/ports/port: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary  
Then I compiled it back and tried to use with armian but TV box was not booting.
I was trying to use also original extracted DTB without decompile/compile with the same result.
 
What I am doing wrong? Should be DTB compiled on armbian?
Any changes required in DTS? (This is new area for me... )
 
Thanks in advance for any help.

Thanks for directing me to the right way.
At first attempt the ir-keytable -t was not working. I was trying to use the different protocols according the LibreElec Infra-Red Remotes page but I was getting the errors:
# ir-keytable -p nec -t Protocols for device can not be changed Protocols changed to Testing events. Please, press CTRL-C to abort. Then I read few other web pages and looking into /etc/rc_maps.cfg and found, that my IR device is not the first (rc0):
 
# ir-keytable Found /sys/class/rc/rc1/ (/dev/input/event2) with: Name: gpio_ir_recv Driver: gpio_ir_recv, table: rc-empty LIRC device: /dev/lirc0 Attached BPF protocols: Operation not supported Supported kernel protocols: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon Enabled kernel protocols: lirc bus: 25, vendor/product: 0001:0001, version: 0x0100 Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc0/ (/dev/input/event1) with: Name: dw_hdmi Driver: cec, table: rc-cec Supported kernel protocols: cec Enabled kernel protocols: cec bus: 30, vendor/product: 0000:0000, version: 0x0001 Repeat delay = 0 ms, repeat period = 125 ms  
So I must start the ir-keytable with  -s rc1 parameter then finally got it working:
# ir-keytable -s rc1 -p nec -t Protocols changed to nec Testing events. Please, press CTRL-C to abort. 3009.632067: lirc protocol(necx): scancode = 0xdf0c 3009.632120: event type EV_MSC(0x04): scancode = 0xdf0c 3009.632120: event type EV_SYN(0x00). 3009.684073: lirc protocol(necx): scancode = 0xdf0c repeat 3009.684129: event type EV_MSC(0x04): scancode = 0xdf0c 3009.684129: event type EV_SYN(0x00). 3009.792069: lirc protocol(necx): scancode = 0xdf0c repeat 3009.792121: event type EV_MSC(0x04): scancode = 0xdf0c 3009.792121: event type EV_SYN(0x00).  
So last point is to find the correct key mapping and make the settings persistent.
 

Firstly - to receive the messages from the board you need only 2 wires:
Ground of Serial port on PC -------> Ground of TV Box RX (input) pin of Serial port -------> TX (output) pin of TV Box You don't need to send the data from PC to the TV Box (at this moment).
 
I think it is clear how to connect the ground wire.
Then unclear point is only - where to connect RX pin of Serial port.
But there is only few pads and try to all in combination of  two baud-rates (115200 and 1500000) should not take much time...
 
Note: Just be sure that you are probing the RECEIVING pin. I have this adapter and surprisingly the pin labels are misleading... RX is the transmitting pin. RX means that this pin should be connected to the RX pin on the other side...
Similar for TX - it is a receiving pin.
 
 
 

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

Regarding the usage of NodeMCU as a USB-to-Serial adapter - the idea is very simple.
As board contains the USB-to-Serial chip (CH340 or CP2102 or FTD or whatever..) and this chip is connected to the MCU to RX/TX pins, then it is enough to block the MCU (by the ENABLE/RESET signal or by programming the RX/TX pins as input) and connect RX/TX pins to our serial interface (instead of MCU). Pins are usually on the headers so it is easy to connect. You can also use others boards with USB-to Serial chips like Arduino, STM32 blue-pill, etc..)
Here is the link from I learn this:
 

EDIT: This how-to is slightly out-of-date, because now the complete images for RK3318 boxes are available here. Thanks to community, especially to @jock.
 
Hello all,
I would like to summarize the required steps to boot armbian on device with RK3318 chip.
I have a X88 Pro device already mentioned here.
I am quite skilled but information are spread in many posts and I spent lot of time to have a clear picture.
Note that instructions below are valid at this time when I am writing it - some things can change in the time...
And hope linux is your friend...
 
You need 4 files:
Armbian image (Links to download armbian image is in the first post of this thread) - thanks to @balbes150 U-boot image and DTB file for RK3318 from here - thanks to @hexdump trust.img file from here - thanks to @caruso  
 
 
As you see - actually Armbian 20.10 builds are in the file.
Select the image for installation according your needs:
   smaller files have no graphical desktop (only terminal/command line)    bigger (desktop) files are full Graphical desktop releases    buster and bullseye are the Debian releases    focal and bionic are Ubuntu releases  
I selected the Ubuntu desktop.
Uncompress selected image:
xz -d Armbian_20.10_Arm-64_focal_current_5.9.0_desktop.img.xz  
Burn the uncompressed image to the SD card:
dd if=Armbian_20.10_Arm-64_buster_current_5.9.0.img of=/dev/<yoursdcard> bs=10M status=progress  
Change <yoursdcard> as needed. In my case the SD card is /dev/sda so my command was:
dd if=Armbian_20.10_Arm-64_buster_current_5.9.0.img of=/dev/sda bs=10M status=progress  
 
Then you need to burn U-boot and Trust Images:
dd if=uboot-rk3318.img of=/dev/<yoursdcard> seek=16384 dd if=trust.img of=/dev/<yoursdcard> seek=24576  
Again change <yoursdcard> as needed...
Now flush the cached writes to the SD card.
sync  
Now remove the SD card from computer and re-insert back.
You should see the two partitions on SD card - BOOT and ROOTFS.
 
Copy the DTB file (rk3318-t9-mainline.dtb) to the folder /dtb/rockchip/ in BOOT partition.
And edit the file /extlinux/extlinux.conf in boot partition to use this DTB.
You can remove commented lines (# at the beginning).
My file looks like this - APPEND line is taken from RK3328 part:
LABEL Armbian LINUX /zImage INITRD /uInitrd # rk-3318 FDT /dtb/rockchip/rk3318-t9-mainline.dtb APPEND root=LABEL=ROOTFS rootflags=data=writeback rw console=uart8250,mmio32,0xff130000 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0  
After editing flush the writes by sync command again, and remove the SD card from computer.
Insert SD card to your RK3318 device and boot...
 
You can experiment with different DTB files and settings... Good luck.

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

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

Hello all nice people, let me do this post since I repute it very important.
There is a lot of people actively deploying things on rk 322x and rk 3318, some  media oriented things ( libreelec, kodi ) some desktop and servers applications.
Now.......it happens that @jock and my self are actively working on those two platforms because I was so lucky in the past to buy for really few bucks ( and i say FEW )  more than 50 different boards reputed faulty, and there were not, just wrong firmware.
But in this big STOCK of boards mostly were 322x ( 3228 3228a 3229 ) and ONLY ONE was 3318,and again I repeat just ONE 3318
 
So it happens that quite EVERY  question on 322x we can answer with sufficient level of accurancy, but on 3318 our experience is limited on HK1,  that is a circle box without display.
Every single help, every single uart log, bootlog any elselog is a mine of infos for us, in particular @jock , but at the same time is really hard provide you a satisfactory answer without debug info, our crystal ball is actually broken

Help us to help you providing as much infos possible and not just saying " it doesn't boot" because in that way is a hard stuff to solve.

Thanks

 

hmm, ok. Good point is that MultiTool is booting... Are you able to retrieve the DTB from Android backup?
Someone from this forum can look into, to find the problem.

Also best would be to have the serial console...
 
EDIT: also you can look at LibreELEC, if there is something for your box and if yes, then you can try to combine the u-boot/dtb from LibreELEC with armbian distro.
Something is here:
https://forum.libreelec.tv/thread/20813-step-by-step-tutorial-libreelec-on-h96-max-also-ir-remote-support/
But I am not sure if this box is compatible with your.

When you will be experimenting, don't flash to the internal memory. Always use the SD card.
Otherwise there is a big risk that your device will be bricked.

@Dragao, for better understanding - you have a two options:
 
1) Boot from external media (SD Card or USB key) - in this case you need only to write the distro image to the media and put it into box and boot. After booting you can run rk3318-config to configure additional devices (wifi, led, ...) In this case MultiTool is not required.
 
2) Boot from internal eMMC - in this case you can use MultiTool to flash the distro image to the internal eMMC, and boot.. Again you can use rk3318-config for further tuning.
 
Both options are described in the first post.
 
I think, you don't need to manipulate dtb/dtbo manually, also I think MultiTool do nothing with dtb/dtbo..
 

@Dragao, for better understanding - you have a two options:
 
1) Boot from external media (SD Card or USB key) - in this case you need only to write the distro image to the media and put it into box and boot. After booting you can run rk3318-config to configure additional devices (wifi, led, ...) In this case MultiTool is not required.
 
2) Boot from internal eMMC - in this case you can use MultiTool to flash the distro image to the internal eMMC, and boot.. Again you can use rk3318-config for further tuning.
 
Both options are described in the first post.
 
I think, you don't need to manipulate dtb/dtbo manually, also I think MultiTool do nothing with dtb/dtbo..
 

This was not helpful. The boot stucked at the same point - ALERT! UUID=bla bla bla does not exists.
I checked the USB key and really - the partition UUID was different than in the armbianEnv. I don't know how UUID was changed. Sorry for my mistake.
So I flashed the image to the USB key again an successfully booted from USB... (overlay was not necessary for boot).

I forgot to attach the serial logs..
serial_boot_internal.log serial_boot_USB2.0.log

I am thinking about automatic conversion of DTB extracted from Android firmware to DTB usable by Armbian (linux).
I am reading the docs about the DT but still I have no clear picture what is required to do this.
 
From the definition, the DT should be OS independent, so why the Android DTB cannot be used directly by Armbian/linux?
 
Currently I have in my mind only two things:
DTB can be older and not fit to the current standards Device names/types (used in compatible=) may be different in linux and thus not recognized Or am I wrong?...
 
This is new area for me, so any comments are welcome..