jock

@Exellent Finally I had the time to do some tests with the eMMC and it looks like everything works pretty fine. I changed the boot order of U-boot, so the priority is always the external sd card, then the USB stick and finally the eMMC, so even if the image is installed in embedded memory, it should be always possible to run newer images using an external sdcard. Still there is no rockusb nor fastboot, so it is wise to experiment only if you have access to the serial console. I added a new image to the first post with "eMMC friendly" tag, if you want to give it a try. Just burn the image on a sdcard and then use armbian-config to install the system into the eMMC

Could you please point to such dts? It would be at least interesting to see if there's a different driver and what and how resources are allocated for the device

Today my effort is getting the rk3288 tv box boot from USB devices. During the initialization of the OTG USB port, u-boot complaints about dwc_otg_core_host_init() function which is timing out. I tried to manipulate the device tree chaning the dr_mode flag to host, otg and peripheral, but nothing changed. The only way to get rid of the timeout is to disable the device which, by the way, seems to not work anyway. U-Boot 2017.09 (Jun 17 2018 - 18:55:17 +0200) Model: XT-Q8L-V10-RK3288 DRAM: 2 GiB MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0 ** First descriptor is NOT a primary desc on 0:1 ** In: serial Out: serial Err: serial Model: XT-Q8L-V10-RK3288 Net: No ethernet found. starting USB... USB0: Core Release: 3.10a USB1: Core Release: 3.10a dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! dwc_otg_core_host_init: Timeout! scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 ** First descriptor is NOT a primary desc on 0:1 ** switch to partitions #0, OK mmc0(part 0) is current device ** No partition table - mmc 0 ** ** First descriptor is NOT a primary desc on 1:1 ** switch to partitions #0, OK mmc1 is current device ** No partition table - mmc 1 ** The other USB device (the host-only port) works fine instead, I'm able to scan the bus and boots fine too. I saw some tinkerboard u-boot logs around, and they also show this timeout error. I wonder if there is any patch/workaround I'm missing or it is just the u-boot driver which is not working properly

This is what I did to enable remote control on my tv box, which has its own remote controller. I don't know if the same apply for the tinkerboard, at best the key mappings defined below are wrong, at worst the tinkerboard uses a totally differente approach, but anyway this could be a hint if the suggestions you already received did not work. If you're using the default legacy kernel (4.4.x) you have to modify these two configuration options in the kernel .config file to enable the proprietary rockchip driver: CONFIG_ROCKCHIP_REMOTECTL=y CONFIG_ROCKCHIP_REMOTECTL_PWM=y And then add this section to the device tree which configures the remote controller driver to use pwm0 as an input and also configures the key mappings: &pwm0 { compatible = "rockchip,remotectl-pwm"; reg = <0x0 0xff680000 0x0 0x10>; #pwm-cells = <0x3>; pinctrl-names = "default"; pinctrl-0 = <&pwm0_pin>; status = "okay"; interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; remote_pwm_id = <0x0>; handle_cpu_id = <0x1>; remote_support_psci = <0x0>; ir_key1 { rockchip,usercode = <0x1dcc>; rockchip,key_table = <0xff KEY_POWER>, <0xea KEY_PLAYPAUSE>, <0xe9 KEY_STOP>, <0xf9 KEY_PREVIOUSSONG>, <0xf5 KEY_NEXTSONG>, <0xbe KEY_1>, <0xba KEY_2>, <0xb2 KEY_3>, <0xbd KEY_4>, <0xb9 KEY_5>, <0xb1 KEY_6>, <0xbc KEY_7>, <0xb8 KEY_8>, <0xb0 KEY_9>, <0xb6 KEY_0>, <0xb5 KEY_BACKSPACE>, <0xb7 KEY_F6>, <0xfc KEY_HOME>, <0xf0 KEY_BACK>, <0xbf KEY_MENU>, <0xb3 KEY_TEXT>, <0xef KEY_LEFT>, <0xed KEY_RIGHT>, <0xbb KEY_DOWN>, <0xf8 KEY_UP>, <0xee KEY_ENTER>, <0xfd KEY_VOLUMEDOWN>, <0xf3 KEY_MUTE>, <0xf1 KEY_VOLUMEUP>, <0xfe KEY_F1>, <0xfa KEY_F2>, <0xf6 KEY_F3>, <0xf2 KEY_F4>; }; }; then you should be able to find some more devices in /dev/input/event*, one of which is your remote controller. As I said, the key mappings may be wrong for your remote, or maybe the tinkerboard uses another PWM

You should not get flickering or horizontal lines if you're using standard consumer-grade monitors. Industrial monitors have a fixed resolution and refresh rate (I've seen a couple of them in my life), but consumer monitors usually have their built-in scaler to adapt a non-native resolution. The quality of what you get is far worse than native, but indeed you should not get artifacts. Which version of armbian did you try? I experienced issues trying the variant with the legacy rockchip kernel (4.4) and to solve the problem I had to dig and manually change some bits in the device tree by hand. I opened an issue on github (https://github.com/rockchip-linux/kernel/issues/91) but I get no responses from the official team. By the way, that is not your specific case, because I see you're using the mainline kernel. Normally you should be able to grab the EDID configuration from the monitor installing the read-edid package and running: get-edid -b 5 -q | parse-edid The output is intersting because in theory you can create an xorg.conf file using this output to specify the resolution X.org should use. The output is something like this: Section "Monitor" Identifier "PL2390" ModelName "PL2390" VendorName "IVM" # Monitor Manufactured week 6 of 2016 # EDID version 1.3 # Digital Display DisplaySize 510 290 Gamma 2.20 Option "DPMS" "true" Horizsync 30-83 VertRefresh 55-76 # Maximum pixel clock is 170MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1152x864, 75Hz #Not giving standard mode: 1440x900, 75Hz #Extension block found. Parsing... Modeline "Mode 13" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 1" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 2" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 5" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 6" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 8" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 9" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 10" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 11" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync Modeline "Mode 12" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 14" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Modeline "Mode 15" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync Option "PreferredMode" "Mode 13" EndSection Another hint: always use a good quality HDMI cable. There are cheap cables out which generate all sort of problems, mostly when the monitor is trying to send data back (EDID, but also CEC...)

@Exellentthanks, happy to see some nice hardware becoming useful I didn't try yet to do some tests with the eMMC, mostly because mainline u-boot does not support rockusb protocol, which is very useful in case something goes wrong. It allows the communication via OTG USB port and the rkdeveloptool, which can program the eMMC from a normal computer. In theory it is not possible to brick the box, in pratice a mistaken action may cause the boot loader to stay stuck without the ability to activate the maskrom mode without a manual intervention consisting in shorting the clock pin of the eMMC on the board with ground, which I want to avoid at all costs for obvious reasons Rockchip's u-boot fork has rockusb mode, but has to be enabled in configuration and compiled by hand. That would be a good starting point. rkdeveloptool can upload the bootloader and can also program the eMMC bootloader part which is normally protected. By the way, a serial port connected to the headers on the board is a must have if you want to do such experiments because I think that most of the soup is just convincing u-boot to boot from the eMMC edit: in the guide to erase/backup/restore flash above you can see, in the restore paragraph, how to use rkdeveloptool to upload the bootloader to the box (db command), and program the eMMC bootloader sectors (ul command)

I got the same purple vertical line on the very left when using Armbian on my rk3288 tv-box with mainline kernel. I guess it is an HDMI driver problem because I don't remember it ever happened using the default kernel. In my case, turning off and on the monitor makes the purple line go away. Another power cycle makes it appear again, and so on... Now I'm running very latest mainline kernel (4.1.44) and the purple line seems to be gone, but I still get a minimally stretched framebuffer so that the monitor seems to be set in a non-native resolution. This is something I related to this other fact:

Mainline kernel is a bit odd on my armbian build for my rk3288 tv box. It works but I think there is something not perfect in the HDMI driver because sound works every other time I power cycle the monitor. When the sound is not working ,text and graphics looks a bit blurry, like the monitor is not set up for native resolution. Doing a power cycle gives sharp text and graphics and perfectly working sound.

Just added new Armbian 5.46 Ubuntu dekstop prebuilt images

This is the u-boot environment: I see stdout and stderr pointing to vidconsole, I guess it means it is enabled in u-boot config, isn't it? Also coninfo command tells this when an HDMI display is connected to the device And if I disconnect the monitor, the vidconsole entry disappears. So it makes me guess that u-boot sees the display, but does not activate it for some reason.

You may try to add this block to the device tree to slow down the i2c5 bus and add some delays and see what happens: &i2c5 { status = "okay"; clock-frequency = <100000>; i2c-scl-falling-time-ns = <300>; i2c-scl-rising-time-ns = <1000>; }; I did not test it, just found it in rk3288-veyron.dtsi device tree from u-boot

Mmmh, as far as I can see, the driver happens to be in mainline u-boot, the configuration allows to select HDMI driver and there are lot of references. Also there is a driver which reacts to the device tree compatible="rockchip,rk3288-dw-hdmi" string, but still I get "No signal" from my monitor. It looks like that everything is in place but there is just a missing switch that turns on HDMI :/

Maybe you can try swapping your dtb file with the one supplied in one of the images above or just try any of them. You will lose some peripherals, but at least you can understand if it is just a hardware description problem or something more serious. edit: also, reading from the rk3288 datasheet I understand that i2c bus at address 0xff170000 is the bus designated for HDMI DDC, so there are no chances to change it in the device tree

Is it possible to patch the device tree someway to enable HDMI output and having the console on the framebuffer for debugging in current non-development armbian version? Thanks

I guess there is something wrong with the i2c driver. This is the output I can gather using the armbian image with 4.4.126 kernel: root@xt:/home/paolo# dmesg | grep i2c [ 2.876359] i2c /dev entries driver [ 2.877897] of_get_named_gpiod_flags: can't parse 'vsel-gpios' property of node '/i2c@ff650000/syr827@40[0]' [ 2.877913] of_get_named_gpiod_flags: can't parse 'vsel-gpio' property of node '/i2c@ff650000/syr827@40[0]' [ 2.881312] of_get_named_gpiod_flags: can't parse 'vsel-gpios' property of node '/i2c@ff650000/syr828@41[0]' [ 2.881328] of_get_named_gpiod_flags: can't parse 'vsel-gpio' property of node '/i2c@ff650000/syr828@41[0]' [ 2.908968] rk3x-i2c ff650000.i2c: Initialized RK3xxx I2C bus at f0fba000 [ 2.910075] rk3x-i2c ff140000.i2c: Initialized RK3xxx I2C bus at f0fbc000 [ 2.911169] rk3x-i2c ff160000.i2c: Initialized RK3xxx I2C bus at f0fbe000 [ 2.912242] rk3x-i2c ff170000.i2c: Initialized RK3xxx I2C bus at f0fd2000 [ 2.913370] rk3x-i2c ff660000.i2c: Initialized RK3xxx I2C bus at f0fd4000 [ 8.226809] i2c i2c-6: Added multiplexed i2c bus 7 [ 8.228102] i2c i2c-6: Added multiplexed i2c bus 8 root@xt:/home/paolo# i2cdetect -y 5 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@xt:/home/paolo# get-edid -b 5 | parse-edid 5 This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface Only trying 5 as per your request. 256-byte EDID successfully retrieved from i2c bus 5 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "PL2390" ModelName "PL2390" VendorName "IVM" # Monitor Manufactured week 6 of 2016 # EDID version 1.3 # Digital Display DisplaySize 510 290 Gamma 2.20 Option "DPMS" "true" Horizsync 30-83 VertRefresh 55-76 # Maximum pixel clock is 170MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1152x864, 75Hz #Not giving standard mode: 1440x900, 75Hz #Extension block found. Parsing... Modeline "Mode 13" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 1" 25.200 640 656 752 800 480 490 492 525 -hsync -vsync Modeline "Mode 2" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 5" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 6" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 8" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 9" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 10" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 11" 54.000 1440 1464 1592 1728 576 581 586 625 -hsync -vsync Modeline "Mode 12" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 14" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Modeline "Mode 15" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync Option "PreferredMode" "Mode 13" EndSection So EDID works fine on my box using i2c5. I get devices at addresses 37 and 50 as you described and get-edit tool works fine. Also data is correctly reported (display name, modelines, etc...) The i2c6 bus appearing in your test can be probably explained taking a look to the kernel documentation. I found this in the device tree documentation: so that bus is directly embedded into the HDMI controller and spawns up when there is not a master i2c bus for EDID, which is what you did removing the line from the device tree. From what I understand, that works but is suboptimal. To satisfy my curiosity I will try swapping the buses to see what happens. In the meantime you may do tests with another HDMI cable, it is quite common that faulty or cheap cables causes many kinds of issues (HDMI CEC not working or working intermittently for example...) Check the u-boot device tree for &pinctrl section. You'll find these lines: &pinctrl { u-boot,dm-pre-reloc; pinctrl-names = "default"; pinctrl-0 = <&power_led>, <&pwr_hold>; ... act8846 { /* * Original q8 device tree says: * - gpio0 11 HIGH -> power hold * - gpio7 1 LOW -> possibly pmic-vsel, we omit it here */ /*pmic_vsel: pmic-vsel { rockchip,pins = <7 1 RK_FUNC_GPIO &pcfg_output_low>; };*/ pwr_hold: pwr-hold { rockchip,pins = <0 11 RK_FUNC_GPIO &pcfg_pull_up>; }; }; ... }; This way u-boot is instructed to turn the power led GPIO active and the power hold GPIO (which is pin 11 of bank 0) active at boot. edit: I made some tests with other i2c buses, nothing did work, only i2c5 is able to retrieve a valid EDID to me

Thanks for the corrections to the device tree. I integrated most of them into the dts and I will publish them as soon as possible. At the moment I'm having problems compiling a working kernel because of some recent changes to the rockchip codebase which are producing non-booting kernels and I can't verify if everything is in place :/ I'm a little confused about the i2c5 bus, which is working pretty fine to me. I don't get any timeout message in dmesg and there shouldn't be any: all the rk3288 boards I viewed so far use the i2c5 bus for the HDMI DDC feature. Maybe you are having issues with your monitor due to some misconfiguration or malfunction of that? In which case I'm not sure changing i2c5 to i2c4 is a good idea for two reasons. The i2c4 bus currently hosts the rk1000 on some addresses, and also I think the DDC feature is hardwired to the i2c5 bus and we, in the device tree, are just informing the linux driver of that. Does it work changing i2c5 to i2c4 for you, or you just don't get the timeout messages? About the OTG cable, you should not use it anymore, I finally found the power hold GPIO which keeps the act8846 powering the board. Nonetheless I noticed the same behaviour you describe: reboot does not work but if I keep the OTG cable connected to the computer reboot works.

I'm developing this armbian fork for some rk3288 tv boxes. In my case audio via HDMI is working well in next kernel (4.14). I used the patched tinkerboard dts as "inspiration" for that part. I also had problems with audio until I bypassed these two lines: chroot $SDCARD /bin/bash -c "sed -i -e '/#load-module module-alsa-sink/r /usr/local/bin/pulseaudio.txt' /etc/pulse/default.pa >/dev/null 2>&1" chroot $SDCARD /bin/bash -c "rm /usr/local/bin/pulseaudio.txt" in build/config/sources/rockchip.conf for tinkerboard. You may take a look on github for that source code Also bluetooth is working fine (no hardware rfkill though), and I can happily stream audio from the phone to the monitor, but those tv boxes use broadcom-based AP6330 wifi SoCs.

Thanks pro, it would be really nice to have official support for these boards, they look pretty polished and really rock-solid to me and the SoC is quite amazing

This guide describes how to erase the internal eMMC memory. This won't brick your TV Box, instead will force it to boot from the SD Card. Also I give some steps to backup and restore the original firmware in case you want to restore the original functionality. The tool used here is rkdeveloptool, which is opensource and is available cloning or downloading the armbian rockchip-linux rkbin github repository mirror Get into rockusb mode: Getting into rockusb mode is essential to do anything else 1) plug the power cord inside the device 2) push the Reset button and keep it pushed while plugging the USB cable into the OTG port 3) check if the device is connected, use lsusb: lsusb Bus 001 Device 005: ID 058f:6377 Alcor Micro Corp. AU6375 4-LUN card reader Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Bus 001 Device 029: ID 2207:320a Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth Bus 002 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 002 Device 002: ID 046d:c312 Logitech, Inc. DeLuxe 250 Keyboard Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub you should be able to see a device with ID 2207:320a. If so, you are in rockusb mode and can jump to Backup, Restore or erase eMMC paragraphs below Erase the eMMC: To completely erase the eMMC card just run ./rkdeveloptool ef it will take around a minute, then the flash memory will be completely erased and your box will boot from the sdcard Backup: First we determine the size of the eMMC flash memory ./rkdeveloptool rfi Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 7393 MB Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash<0> in my case the size of the memory is 7393 Megabytes, so you can the command to retrieve the data: ./rkdeveloptool rl 0x0 $((7393 * 2048)) backup.data this will download the original firmware in backup.data file in less than five minutes. Restore the original firmware: First we have to restore the original bootloader. Running these commands will do the job: ./rkdeveloptool db ../rk32/rk3288_ubootloader_v1.01.06.bin Downloading bootloader succeeded. ./rkdeveloptool ul ../rk32/rk3288_ubootloader_v1.01.06.bin Upgrading loader succeeded. ./rkdeveloptool wl 0x0 backup.data Write LBA from file (100%)

DISCLAIMER (PLEASE READ): everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware. Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related). Thank you! This is CSC Armbian for XT-Q8L-V10 boards, also known as Chiptrip Q8, Vsmart Q8, ENY 3288 Q8, etc... All source code has been merged into Armbian mainline project. I still keep my personal public Armbian fork for experimental features: https://github.com/paolosabatino/armbian-build Nightly images: download directory Quick installation instructions on eMMC: Build or download your preferred Armbian image from Download directory and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the sd card, then push the power button for 1 second (the led will turn blue) After 10 seconds HDMI will turn on and you will get logging messages; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed! Boot from SD Card/USB stick (with Armbian already installed in eMMC, empty eMMC or no eMMC😞 Build or download your preferred Armbian image from Download directory; Burn the image on your SD card/USB stick; Plug the SD card/USB stick in the device; Push the power button for 1 second (the led will turn blue); After 10 seconds HDMI will turn on and you will get logging messages; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed! Boot from SD Card/USB stick (with original firmware or other firmware): In case your box has the original firmware installed, use the Multitool to erase the internal flash. Don't worry, you will not brick your box: once the eMMC is emptied, the box will automatically boot from SD Card. This is called Maskrom mode and is common to all Rockchip devices. Instructions and download links for the Multitool are at the bottom of this post. After erasing the internal eMMC, just follow the "Boot from SD Card" procedure above and then you are fine. Boot priority: Newer images (those with mainline kernel >= 4.14.50) now support booting from multiple devices. Priority is fixed and boot devices are probed in this order: External SD card External USB storage device (Any USB Stick/Hard drive attached to USB host ports) Internal eMMC This way even if you install armbian to internal eMMC, you can still easily test different images booting from external devices. Experts notes: when armbian is installed into eMMC you get U-boot installed too in eMMC. This is important to know because the box won't boot in Maskrom Mode, but instead will always boot the embedded U-boot, no matter if you put an sdcard/usb stick. In practice the embedded U-boot is totally responsible for the boot priority. If you want to restore the Maskrom Mode, just erase U-boot from eMMC using this command: dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=8128 conv=sync,fsync Current status: Wireless: works. pretty fast and stable, signal is strong on my box; Bluetooth: works. I was able to transfer files and stream audio without problems USB ports: works, with autosuspend too. A quick benchmark show that transfer rate is quite good (topped at 34 MB/s) USB OTG: works in host mode. Transfer rate is very good (> 40 MB/s) MMC: works and is perfectly accessible as storage device. The images above with "eMMC friendly" have been tested and work when installed in eMMC using the standard armbian-config eMMC installer SDCard: works. legacy kernel is limited to high speed, while mainline works fine in UHS mode too. A quick benchmark with a Samsung EVO card shows the promised 48Mb/s read speed. Gigabit Ethernet: works, fast and reliably HDMI: works perfectly Serial: works Audio: both HDMI audio and SPDIF connector works IR remote: works on legacy and mainline kernels Reboot/Suspend process: rebooting the device is a working in progress, at the moment sometimes it works and sometimes it doesn't. Suspend is still not available. Hardware acceleration: everything which works for rk3288 boards applies here too. This guide or maybe the Media Testing Script will help you gain an hardware accelerated X11 and Chromium (using GL4ES I enjoyed Quake 2 from the start till the end, but also Quake and Quake III Arena work flawlessy, here a quick how-to to compile and install GL4ES) Multimedia: On mainline kernel 3D acceleration is provided by Panfrost driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Multitool: The Multitool is a small but powerful tool to easy operate on internal eMMC flash of RK3288 devices. Features: Backup the content of internal eMMC Restore a previously backed-up image to eMMC Erase the eMMC (via fast blkdiscard or zero-fill as fallback) Burn an Armbian (or LibreELEC) image directly on the eMMC Provide a recovery shell for manual maintenance Windows-friendly: everything is placed in a NTFS partition Image compression format autodetection: they are decompressed on-the-fly during burn process Network support for remote maintenance via SSH (instructions to access via network here) Instructions are simple: Download the image from here Burn it on an sdcard Open the NTFS partition with your preferred file manager Place the images you want to burn on the device in images directory (backups will be stored in backups directory) Plug the sd card in the RK3288 device Power the device and wait few seconds, the Multitool menu will appear on screen and can be navigated with the keyboard Last edit: 07/06/2020 - updated installation instructions

Try to turn off and on the monitor. Once and then I have glitches with a pink column of pixels at the left border which, I guess, is something that should be fixed in hdmi drivers. By the way I tested the HDMI on a couple of devices, a Philips Monitor/TV and a Iiyama Monitor, both Full-HD and with in-built speakers and both works fine either with output and sound. For my understanding, rk1000 device drives only analog audio and video, so it not of any use on our TV boxes.

Sorry, that was my mistake. So I was too zealant in changing some regulators in order to support suspend features and so on and disabled the lcd power regulator Overwrite /boot/dtb/rk3288-q8.dtb with the rk3288-q8.dtb attached to this message and HDMI should finally work. I also provide the device tree source for reference, but copying the binary will suffice. rk3288-q8.dtb rk3288-q8.dts

@pro777 and anyone who is interested, I publish here the first draft of my work. Take this as a "proof of concept" for future work, this is nothing more than a test image. edit: see this page for better and more up-to-date armbian images The test image can be downloaded from here. It is an image of Armbian based upone latest 5.41 release for tinkerboard, with u-boot and kernel compiled using the device trees I adapted on the base of the original device tree coming from my tv box. A lot of work has already been done by other people. Current status: - Wireless, pretty fast and stable, signal is strong on my box; - Bluetooth, seems to work. I just tested a file transfer. - USB Host: works quite well but autosuspend is disable for the 4-port hub connected to this non-OTG SoC port due to issues. Transfer rate is quite good (topped at 34 MB/s) - USB OTG: works quite well in host mode, no quirks apparently. Transfer rate is very good (topped at 38 MB/s) - MMC: can be accessed, did not try to program it though - SDCard: works very well, in ultra high speed mode too. Tested a lousy class-4 sdcard and reached more than 60 MB/s! - Gigabit Ethernet: seems to work fast and reliably - HDMI: has some quirks, expecially if you attach and detach the devices. Generally works, but resolution is not configurable (see the note at the bottom) - Serial: works - Audio: HDMI audio works, but SPDIF is still a work in progress - IR remote: does not work, still trying to understand if a special driver is required or I am missing some pieces of the puzzle - Boot/Reboot/Suspend process: still some mysteries lays around here. The boot process on my box is a bit problematic (see the instructions below) and requires some attention. Suspend is not available at all. Rebooting the device via command line actually shuts it down. - Hardware acceleration: the kernel driver is there, userland drivers are still messy, but something can be achieved for the X server (see the link to the guide below) and probably the framebuffer GL ES driver works too Instructions: - First of all, you should boot your box in Maskrom Mode. One of the fastest ways is to zero-fill the internal MMC, I followed this as reference: https://github.com/nolange/rk3288-guide/blob/master/bootloader.md When in maskrom mode, the First Program Loader (which is the bootloader inside the SoC) will try to boot first from MMC chip, then SD card and finally USB. If you don't boot in maskrom mode, the SoC will always try to boot from the MMC chip, which has an obsolete u-boot - Flash the image over an microsd card, then plug the card into the box - If your box has a power button (mine has), push it and keep it pushed for some seconds, until you hopefully see the power led blinking. When the led is blinking, the kernel has started and your can stop pushing the power button. Note that if you push the power button for more than 10 seconds, the box will shut down. Another solution could be to connect the OTG port to your computer: doing this won't require you the keep the button pushed. - As usual, armbian default credentials are user: root password: 1234 You should be able to follow this guide to gain some hardware accelerated X server. It worked for me and I was able to obtain some pleasant Chrome experience. In /opt directory there are some firmwares and binaries downloaded from rockchip official github pages, and also the source device trees, scripts, and the configuration files I used to build the custom kernel and u-boot. I tried to stay stick to the default configs, so modifications should be minor. Also there is an enable_bt.h script to load the patch firmware and enable the bluetooh device. Kernel is 4.14, (current armbian mainline) and u-boot is 2018.3 (current mainline). I also tested latest 4.16 mainline kernel and rockchip pre-2018 u-boot, they also work. From the device tree, the CPU is configured to run at a maximum frequency of 1.6 Ghz and trigger the first thermal trip points at 70°C. A nice heatsink, or even a fan, are suggested. edit: for HDMI, I made a mistake. You will need to manually copy a new device tree binary into /boot/dtb directory. Look here for the dtb file

At the moment I have no published firmware yet. I would like to solve the boot problem soon if possibile, but I may think to share some preliminary work so who is interested can look into. I should really do some tidying up of the source device tree, kernel patches, binary firmwares and other things needed to make the thing work; I guess I can share my working image as a preliminary "demo" just for testing, sources may come as soon as possible

Great job! I'm working from the mainline side: kernel 4.16 and latest u-boot (2018-3) are working fine. I'm still facing a problem against the bootstrap and reboot (looking into the act8846 power regulator datasheet, see this), but most of the hardware is working very well, including gpu-accelerated chromium, wifi, bluetooth. I'm still missing the IR remote control.