jock

Members
  • Content count

    64
  • Joined

  • Last visited

About jock

  • Rank
    Advanced Member

Recent Profile Visitors

387 profile views
  1. 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
  2. jock

    Armbian-Stretch and IR-Remote?

    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
  3. 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...)
  4. jock

    Armbian for RK3288 XT-Q8L-V10 (Q8) boards

    @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)
  5. 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:
  6. jock

    Tinker Board Sound

    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.
  7. jock

    Armbian for RK3288 XT-Q8L-V10 (Q8) boards

    Just added new Armbian 5.46 Ubuntu dekstop prebuilt images
  8. jock

    Enable HDMI in u-boot for RK3288

    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.
  9. jock

    Armbian for RK3288 XT-Q8L-V10 (Q8) boards

    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
  10. jock

    Enable HDMI in u-boot for RK3288

    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 :/
  11. jock

    Armbian for RK3288 XT-Q8L-V10 (Q8) boards

    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
  12. 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
  13. jock

    Armbian for RK3288 XT-Q8L-V10 (Q8) boards

    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
  14. jock

    Armbian for RK3288 XT-Q8L-V10 (Q8) boards

    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.
  15. jock

    ASUS Tinker Board Bluetooth

    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.