jock Posted May 6, 2018 Posted May 6, 2018 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 4 Quote
pro777 Posted May 12, 2018 Posted May 12, 2018 jock, thanks for the excellent work! It is necessary to make efforts for official support in armbian! 0 Quote
jock Posted May 12, 2018 Author Posted May 12, 2018 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%) 0 Quote
jock Posted May 12, 2018 Author Posted May 12, 2018 21 minutes ago, pro777 said: jock, thanks for the excellent work! It is necessary to make efforts for official support in armbian! 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 0 Quote
pro777 Posted May 17, 2018 Posted May 17, 2018 (edited) hi, jock, please consider the following additions and corrections to dts: disable i2c5 to get rid of kernel messages like "0xff170000 timeout ..." &i2c5 { status = "disabled"; }; as a result of the previous editing, change the value of the property of ddc-i2c-bus to i2c4 &hdmi { ddc-i2c-bus = <&i2c4>; #sound-dai-cells = <0>; status = "okay"; }; maybe you forgot, add, please, the element 'dr_mode = "host";' in the node '&usb_otg', so that OTG will work as a usb-host &usb_otg { dr_mode = "host"; vusb_d-supply = <&vcc_otg_5v>; vusb_a-supply = <&vcc_otg_5v>; status = "okay"; }; it's worth adding clocks to i2s &i2s { #sound-dai-cells = <0>; clock-names = "i2s_hclk", "i2s_clk", "i2s_clk_out"; clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>, <&cru SCLK_I2S0_OUT>; status = "okay"; }; It is better to add parts for RK1000, it is also desirable to add to the kernel drivers for it (CONFIG_MFD_RK1000, CONFIG_DRM_RK1000, CONFIG_SND_SOC_RK1000) &i2c4 { status = "okay"; rk1000_ctl: rk1000-ctl@40 { compatible = "rockchip,rk1000-ctl"; reg = <0x40>; reset-gpios = <&gpio7 21 GPIO_ACTIVE_LOW>; clocks = <&cru SCLK_I2S0_OUT>; clock-names = "mclk"; status = "okay"; }; rk1000-tve@42 { status = "okay"; compatible = "rockchip,rk1000-tve"; reg = <0x42>; rockchip,data-width = <24>; rockchip,output = "rgb"; rockchip,ctl = <&rk1000_ctl>; #address-cells = <1>; #size-cells = <0>; }; rk1000_codec: rk1000-codec@60 { compatible = "rockchip,rk1000-codec"; reg = <0x60>; #sound-dai-cells = <0>; rockchip,spk-en-gpios = <&gpio7 5 GPIO_ACTIVE_LOW>; rockchip,pa-en-time-ms = <5000>; rockchip,ctl = <&rk1000_ctl>; status = "okay"; }; }; replace, please, ir-keys table 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>; }; It is also desirable to rename the soundcard in node 'soundcard-hdmi' simple-audio-card,name = "DW-I2S-HDMI"; I updated the firmware for Debian for SD-card. I made it possible to run MPV with hardware decoding h264, h265, according to the message of JMCC. Here is used DHD wi-fi driver. In my opinion, it works at a higher speed than brcmfmac. And with the reboot there seems to be all right. Update: I also noticed that when the OTG cable is connected to the computer, Armbian Ubuntu begun rebooted after selecting the reboot command from the menu. Edited May 18, 2018 by pro777 0 Quote
jock Posted May 22, 2018 Author Posted May 22, 2018 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. 0 Quote
pro777 Posted May 25, 2018 Posted May 25, 2018 On 5/22/2018 at 10:54 PM, jock said: Does it work changing i2c5 to i2c4 for you, or you just don't get the timeout messages? Yes, indeed, I just got rid of the timeout messages in this way. At me here such board: If i2c5 is enabled and indicated to read the ddc information from it, i.e.: Conf.1 &hdmi { /delete-property/pinctrl-names; /delete-property/pinctrl-0; /delete-property/pinctrl-1; ddc-i2c-bus = <&i2c5>; #sound-dai-cells = <0>; status = "okay"; }; &i2c5 { status = "okay"; }; then the following information is received: user@armbian:~$ ls -l /dev/i2c* crw-rw---- 1 root i2c 89, 0 May 25 14:37 /dev/i2c-0 crw-rw---- 1 root i2c 89, 1 May 25 14:37 /dev/i2c-1 crw-rw---- 1 root i2c 89, 2 May 25 14:37 /dev/i2c-2 crw-rw---- 1 root i2c 89, 3 May 25 14:37 /dev/i2c-3 crw-rw---- 1 root i2c 89, 4 May 25 14:37 /dev/i2c-4 crw-rw---- 1 root i2c 89, 5 May 25 14:37 /dev/i2c-5 user@armbian:~$ sudo i2cdetect -y 5 [sudo] password for user: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- user@armbian:~$ sudo get-edid -b 5 [sudo] password for user: 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. ^C DDC information can be obtained via i2c at ports 0x37 (DDC) and 0x50 (EDID). We see that there are no contacts on i2c5 on these ports. We change dts: Conf.2 &hdmi { /delete-property/pinctrl-names; /delete-property/pinctrl-0; /delete-property/pinctrl-1; ddc-i2c-bus = <&i2c4>; #sound-dai-cells = <0>; status = "okay"; }; &i2c5 { status = "disabled"; }; We get: user@armbian:~$ ls -l /dev/i2c* crw-rw---- 1 root i2c 89, 0 May 25 14:47 /dev/i2c-0 crw-rw---- 1 root i2c 89, 1 May 25 14:47 /dev/i2c-1 crw-rw---- 1 root i2c 89, 2 May 25 14:47 /dev/i2c-2 crw-rw---- 1 root i2c 89, 3 May 25 14:47 /dev/i2c-3 crw-rw---- 1 root i2c 89, 4 May 25 14:47 /dev/i2c-4 user@armbian:~$ sudo i2cdetect -y 4 [sudo] password for user: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: UU -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- user@armbian:~$ sudo get-edid -b 4 4 This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface Only trying 4 as per your request. Bus 4 doesn't really have an EDID... Couldn't find an accessible EDID on this bus. I'm sorry nothing was successful. Maybe try some other arguments if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>. As you can see, on i2c4 on ports 0x37 and 0x50 there is also no contact. We check the following configuration: Conf.3 &hdmi { /delete-property/pinctrl-names; /delete-property/pinctrl-0; /delete-property/pinctrl-1; //ddc-i2c-bus = <&i2c4>; #sound-dai-cells = <0>; status = "okay"; }; &i2c5 { status = "disabled"; }; We get: user@armbian:~$ ls -l /dev/i2c* crw-rw---- 1 root i2c 89, 0 May 25 14:51 /dev/i2c-0 crw-rw---- 1 root i2c 89, 1 May 25 14:51 /dev/i2c-1 crw-rw---- 1 root i2c 89, 2 May 25 14:51 /dev/i2c-2 crw-rw---- 1 root i2c 89, 3 May 25 14:51 /dev/i2c-3 crw-rw---- 1 root i2c 89, 4 May 25 14:51 /dev/i2c-4 crw-rw---- 1 root i2c 89, 6 May 25 14:51 /dev/i2c-6 user@armbian:~$ sudo i2cdetect -y 6 [sudo] password for user: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- user@armbian:~$ sudo get-edid -b 6 6 This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface Only trying 6 as per your request. Bus 6 doesn't really have an EDID... Couldn't find an accessible EDID on this bus. I'm sorry nothing was successful. Maybe try some other arguments if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>. Strangely enough, in the system has appeared i2c6 to the address 0xff980000 (HDMI) And also there are contacts on the ports of interest! But it is impossible to obtain EDID information. I also have the MK809-4K on RK3288 chip. I drew attention to the fact that it initially selects the correct mode of HDMI for 1920x1080. Therefore, I also checked the configuration # 3 on it. And it was possible to successfully read the EDID: user@armbian:~$ ls -l /dev/i2c* crw-rw---- 1 root i2c 89, 0 May 25 11:10 /dev/i2c-0 crw-rw---- 1 root i2c 89, 1 May 25 11:10 /dev/i2c-1 crw-rw---- 1 root i2c 89, 2 May 25 11:10 /dev/i2c-2 crw-rw---- 1 root i2c 89, 4 May 25 11:10 /dev/i2c-4 crw-rw---- 1 root i2c 89, 6 May 25 11:10 /dev/i2c-6 user@armbian:~$ sudo i2cdetect -y 6 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- -- -- -- -- -- 37 -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- user@armbian:~$ sudo get-edid -b 6 > edid.bin [sudo] пароль для user: 6 This is read-edid version 3.0.2. Prepare for some fun. Attempting to use i2c interface Only trying 6 as per your request. 256-byte EDID successfully retrieved from i2c bus 6 Looks like i2c was successful. Have a good day. user@armbian:~$ parse-edid < edid.bin Checksum Correct Section "Monitor" Identifier "SAMSUNG" ModelName "SAMSUNG" VendorName "SAM" # Monitor Manufactured week 46 of 2012 # EDID version 1.3 # Digital Display DisplaySize 480 270 Gamma 2.20 Option "DPMS" "false" Horizsync 15-81 VertRefresh 24-75 # Maximum pixel clock is 230MHz #Not giving standard mode: 1152x864, 75Hz #Not giving standard mode: 1280x720, 60Hz #Not giving standard mode: 1280x800, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1600x900, 60Hz #Not giving standard mode: 1680x1050, 60Hz #Extension block found. Parsing... Modeline "Mode 15" 74.25 1920 2448 2492 2640 540 542 547 562 +hsync +vsync interlace Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 1" 85.50 1366 1436 1579 1792 768 771 774 798 +hsync +vsync Modeline "Mode 2" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 3" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 4" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 5" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 6" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 7" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 8" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 9" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 10" 74.250 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 11" 74.250 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 12" 74.250 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 13" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace Modeline "Mode 14" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace Modeline "Mode 16" 74.25 1920 2008 2052 2200 540 542 547 562 +hsync +vsync interlace Modeline "Mode 17" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 18" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync Option "PreferredMode" "Mode 15" EndSection Let's sum up. Configuration # 3 allows us to successfully obtain the EDID information on the MK809-4K. Failure in the case of Q8 can speak of a hardware problem? P.S. jock, tell me, please, what code allows "power hold GPIO which keeps the act8846 powering the board"? 0 Quote
jock Posted May 25, 2018 Author Posted May 25, 2018 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: Quote - ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master or the functionally-reduced I2C master contained in the DWC HDMI. When connected to a system I2C master this property contains a phandle to that I2C master controller. 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...) Quote P.S. jock, tell me, please, what code allows "power hold GPIO which keeps the act8846 powering the board"? 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 0 Quote
pro777 Posted May 26, 2018 Posted May 26, 2018 I tried several hdmi cables. Despite the fact that the boards are almost identical, the result, unfortunately, has not changed: user@armbian:~$ dmesg | grep i2c [ 4.591484] i2c /dev entries driver [ 4.596757] of_get_named_gpiod_flags: can't parse 'vsel-gpios' property of node '/i2c@ff650000/syr827@40[0]' [ 4.596772] of_get_named_gpiod_flags: can't parse 'vsel-gpio' property of node '/i2c@ff650000/syr827@40[0]' [ 4.623910] of_get_named_gpiod_flags: can't parse 'vsel-gpios' property of node '/i2c@ff650000/syr828@41[0]' [ 4.623925] of_get_named_gpiod_flags: can't parse 'vsel-gpio' property of node '/i2c@ff650000/syr828@41[0]' [ 4.739645] rk3x-i2c ff650000.i2c: Initialized RK3xxx I2C bus at f0fba000 [ 4.748307] rk3x-i2c ff140000.i2c: Initialized RK3xxx I2C bus at f0fbc000 [ 4.756830] rk3x-i2c ff150000.i2c: Initialized RK3xxx I2C bus at f0fbe000 [ 4.828714] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/i2c@ff160000/rk1000-ctl@40[0]' - status (0) [ 5.058954] rk3x-i2c ff160000.i2c: Initialized RK3xxx I2C bus at f0fd2000 [ 5.067966] rk3x-i2c ff170000.i2c: Initialized RK3xxx I2C bus at f0fd4000 [ 5.076760] rk3x-i2c ff660000.i2c: Initialized RK3xxx I2C bus at f0fd6000 [ 6.130961] of_get_named_gpiod_flags: parsed 'rockchip,spk-en-gpios' property of node '/i2c@ff160000/rk1000-codec@60[0]' - status (0) [ 7.587827] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 8.587845] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 9.587831] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 10.587841] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 11.587845] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 13.154237] i2c i2c-6: Added multiplexed i2c bus 7 [ 13.160262] i2c i2c-6: Added multiplexed i2c bus 8 [ 28.767585] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 29.767561] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 30.767564] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 31.767546] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 32.767544] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 33.767553] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 34.767573] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 35.767639] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 36.767661] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 37.767644] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 42.727768] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 43.727786] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 44.727810] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 45.727831] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 46.727898] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 47.927965] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 48.927976] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 49.927992] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 50.928016] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 51.928036] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 52.928084] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 53.928074] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 54.928100] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 55.928158] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 [ 56.928096] rk3x-i2c ff170000.i2c: timeout, ipd: 0x00, state: 1 -------------------------------------------------------------------- root@armbian:/home/user# i2cdetect -y 5 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -------------------------------------------------------------------- root@armbian:/home/user# get-edid -b 5 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. ^C Apparently, there are still differences in the electrical scheme. 0 Quote
jock Posted May 26, 2018 Author Posted May 26, 2018 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 0 Quote
pro777 Posted May 26, 2018 Posted May 26, 2018 11 minutes ago, jock said: 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 Yes, of course, I do not mind When I start the firmware with a mainline kernel, the monitor shows: "The mode is not supported" I need to then compile the kernel with the key CONFIG_DRM_LOAD_EDID_FIRMWARE. 0 Quote
jock Posted May 27, 2018 Author Posted May 27, 2018 17 hours ago, pro777 said: Yes, of course, I do not mind When I start the firmware with a mainline kernel, the monitor shows: "The mode is not supported" I need to then compile the kernel with the key CONFIG_DRM_LOAD_EDID_FIRMWARE. 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 0 Quote
pro777 Posted May 27, 2018 Posted May 27, 2018 2 hours ago, jock said: 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 Thanks, jock. Unfortunately, this did not change the situation. I also tried to increase the frequency on i2c5 to 400 KHz - there were no messages about the timeout, but on the whole, nothing has changed dramatically. 0 Quote
jock Posted May 28, 2018 Author Posted May 28, 2018 Just added new Armbian 5.46 Ubuntu dekstop prebuilt images 0 Quote
Exellent Posted May 29, 2018 Posted May 29, 2018 @jock thank you very much for this developement, I'm just wondreing if there is a possebility to compile such an image for the emmc. Would be nice if you could tip me in the right direction :D Thanks in advance and So nice to see still a development on those boards. (I just got mine from junk).. 0 Quote
jock Posted May 30, 2018 Author Posted May 30, 2018 @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) 0 Quote
jock Posted June 23, 2018 Author Posted June 23, 2018 @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 1 Quote
Exellent Posted June 25, 2018 Posted June 25, 2018 @jock very cool, I'll give it a try tonight. The reason for emmc, is that (It might be) faster than eaven the class 10 sd Card. And the Board [Which i pulled from our makerspaces junk] is modded. There is a 32Gb flash chip instead of the 8gb on it. don't aks me how or who it did :D But It would be extremely usefull if work's. But another question; which bootloader [U-Boot ] do u use and where to find it? 0 Quote
jock Posted June 25, 2018 Author Posted June 25, 2018 2 hours ago, Exellent said: @jock very cool, I'll give it a try tonight. The reason for emmc, is that (It might be) faster than eaven the class 10 sd Card. And the Board [Which i pulled from our makerspaces junk] is modded. There is a 32Gb flash chip instead of the 8gb on it. don't aks me how or who it did :D But It would be extremely usefull if work's. But another question; which bootloader [U-Boot ] do u use and where to find it? Ahah cool :D If the job is well-done, it should indeed work flawlessy ;) U-boot is the very standard mainline u-boot that the Armbian build system clones from the official github repository. At the moment Armbian uses the version tagged with v2017.11, plus there are some patches that include include the configuration files and device trees for our tv box. You may check it out looking to the github repository in the first post, just follow the official armbian instructions to build u-boot, kernel or armbian images if you want to experiment ;) 0 Quote
jock Posted September 6, 2018 Author Posted September 6, 2018 Bump up due to some news: New Xenial image with mainline 4.14.68 kernel New Xenial image with latest and greatest 4.18.6 dev kernel (which seems pretty stable to me) Both new images now fully support the IR Remote out of the box, in native mode via kernel keymappings and drivers. Kernel keymap table can be customized using ir-keytable tool. Kernel 4.18.6 also exposes the native lirc interface, so in theory any remote controller can be trained to work with the box Both new images enables the SPDIF connector (it is untested though due to lack of a Optical DAC at home) Added devfreq support for the GPU: at the moment the base frequency is 100 Mhz and maximum frequency is 600 Mhz. The GPU may be too lazy to switch frequency, so you can force a minimum frequency issuing (as root) echo 300000000 > /sys/class/devfreq/devfreq0/min_freq to force the pre-devfreq default operating frequency. You may also force 600000000 (600 Mhz) as minimum to run the GPU always at full speed. Beware the thermals anyway, when the core reaches 70°C it starts throttling and your performance may not be as you expect if you don't cool enough the SoC Every other thing which has been put into Armbian lately is also in the images Enjoy! 2 Quote
Friedolino Posted September 10, 2018 Posted September 10, 2018 I tested the 4.18.6 image. Unfortunatelly the kernel did not detect mmcblk0 (sdcard) leading to "gave up on waiting for root device". But I could change the root_dev to an usb stick in the config fiiles to boot sucessfully but still without access to the sdcard. The 4.14.68 works. But after installing to eMMC via armbian-config it does not boot without the sdcard. 0 Quote
jock Posted September 10, 2018 Author Posted September 10, 2018 Looks strange, normally sdcard controller is described in the common device tree for all the rk3288 devices. Maybe, for some reason, the device is not enumerated as mmcblk0 but something else. Could you paste the dmesg on pastebin or here so I can take a look into? Also if you have access to it, it would be nice to see a photo of the internal board, just to understand if it is a different revision or has some kind of different hardware. 0 Quote
Friedolino Posted September 11, 2018 Posted September 11, 2018 it did not find the uuid. i think with just a different enumerator it would work via uuid. 0 Quote
jock Posted September 11, 2018 Author Posted September 11, 2018 I see that your board is a tiny bit different than mine. Mine has XT-Q8L-V10, instead yours is ENY-Q8L-V10. Yours has a frontal LCD panel connected to the board header, instead mine has just the IR remote and a red/blue LED. I think a dmesg log would clarify the mmc device block names. Actually I had no idea on how kernel assigns names for the different devices. On my setup mmcblk0 is the external Sdcard and mmcblk2 is the internal eMMC. I should normalize this, like mmcblk0 for the eMMC and mmcblk1 for the external SD. 0 Quote
Friedolino Posted September 11, 2018 Posted September 11, 2018 27 minutes ago, jock said: On my setup mmcblk0 is the external Sdcard and mmcblk2 is the internal eMMC. I should normalize this, like mmcblk0 for the eMMC and mmcblk1 for the external SD. With the mainline image it is the same for me. I will post the dmesg of mainline-dev as soon as i have time. Do you have an idea why the emmc doesnt boot after installing with armbian config? Do I have to restore uboot manually? 0 Quote
jock Posted September 11, 2018 Author Posted September 11, 2018 9 hours ago, Friedolino said: With the mainline image it is the same for me. I will post the dmesg of mainline-dev as soon as i have time. Do you have an idea why the emmc doesnt boot after installing with armbian config? Do I have to restore uboot manually? u-boot has its own device mapping and, on my board, u-boot detects the device in reverse order (sdcard has index 1 and mmc has index 0). I thought it was something common for our boards and not to be worried, but probably it needs to be fixed. About not booting from eMMC, I have no clue at the moment. Unfortunately no video output during boot makes hard to guess what happens if you don't have a serial port, I'm working on it but it is a bit hard to sort it out :/ edit: mainline-dev actually installs and boots fine on my board, but occasionally it turns off during kernel bring up. Using the serial I see that it is something which happens during the initialization of the sdcard controller and its vcc regulator: ... [ 2.934789] usbcore: registered new interface driver bfusb [ 2.941136] usbcore: registered new interface driver btusb [ 2.947343] Bluetooth: Generic Bluetooth SDIO driver ver 0.1 [ 2.954765] of: /cpus/cpu@501: Couldn't find opp node [ 2.962388] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 500000 KHz [ 2.971865] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 600000 KHz [ 2.982620] sdhci: Secure Digital Host Controller Interface driver [ 2.987609] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.00 [ 2.989591] sdhci: Copyright(c) Pierre Ossman [ 2.998815] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 3.003679] Synopsys Designware Multimedia Card Interface Driver [ 3.004581] dwmmc_rockchip ff0c0000.dwmmc: IDMAC supports 32-bit address mode. [ 3.011735] usb 1-1: Product: USB 2.0 Hub [MTT] [ 3.018481] dwmmc_rockchip ff0c0000.dwmmc: Using internal DMA controller. [ 3.027111] hub 1-1:1.0: USB hub found [ 3.031669] dwmmc_rockchip ff0c0000.dwmmc: Version ID is 270a [ 3.031700] dwmmc_rockchip ff0c0000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo [ 3.039317] hub 1-1:1.0: 4 ports detected [ 3.043482] vcc_sd: supplied by vcc_io --- stops and turns off --- 0 Quote
Friedolino Posted September 12, 2018 Posted September 12, 2018 Do you know which dac is used on the board? And how is the audio quality? Does it make sense to use a (cheap) dac for the optical audio out? 0 Quote
jock Posted September 13, 2018 Author Posted September 13, 2018 23 hours ago, Friedolino said: Do you know which dac is used on the board? And how is the audio quality? Does it make sense to use a (cheap) dac for the optical audio out? No DAC at all on the board, at least on mine: there is no analog out audio. If you're interested in some kind of audio out from the device you can either use it via HDMI on your monitor/TV or buy a decent optical DAC depending on your requirement. 0 Quote
Friedolino Posted September 13, 2018 Posted September 13, 2018 thank you. Thats what I realized a moment ago when i tried to plug in my headphones I want to use the box for making music with zynaddsubfx. The optical spdif port seems to be the right choice. Right now I think of getting the ZHILAI H3. Its a cheap cs4344 based dac and can be powered via usb. If it is too noisy or distorted, I switch to an edirol audio interface. 0 Quote
jock Posted September 14, 2018 Author Posted September 14, 2018 Yeah you would be the first tester of the spdif interface, since I had no equipment to do it ;) I hope it works though! 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.