• Content Count

  • Joined

  • Last visited

  1. OK - Found the line in #5" LVDS LCD CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:30000,le:40,ri:40,up:29,lo:13,hs:48,vs:3,sync:3,vmode:0" CONFIG_VIDEO_LCD_POWER="PH12" CONFIG_VIDEO_LCD_BL_EN="PH8" CONFIG_VIDEO_LCD_BL_PWM="PB2" Adding this in /home/<USER>/build/cache/sources/u-boot/v*/configs/Bananapro_defconfig and adding the pwm-section (exactly as above) in /home/<user>/build/cache/sources/u-boot/v*/arch/arm/dts/sun7i-a20-bananapro.dts and /home/<USER>/build/cache/sources/linux-mainline/orange-pi-5.4/arch/arm/boot/dts/sun7i-a20-bananapro.dts at the given time while executing ./ CREATE_PATCHES=yes creates the deb-files, from which I applied the named three on a fresh installation from an image made by ./ without modifications. But still - no output on Display - what have I overseen? PWM is working and I can controll it via gpio34 as described above. In the description is written, that 7"-Display is LVMS and 5"-Display is RGB, what doesn't make much sense, but I think this is meant by the presence ofthe Line CONFIG_VIDEO_LCD_PANEL_LVDS=y in case of 7"-LCD and the absence in case of 5"-LCD. Is there anything else to be done? Any special driver to be activated, which isn't active by default? Please, give me a hint! BR Guido
  2. Tried with latest Armbian source and lemakers 5" lcd (without touch), which worked fine with the legacy kernel. So I tried the CONFIG_VIDEO_LCD_MODE from an older post here and skipped all the i2c3 and pio and touchdriver stuff. but unfortunately, all I achieved is an enlighted backlight. The Display doesn't react. HDMI is still working fine. Does somebody know the correct settings in a) for the 5" display? Thx BR Guido
  3. I'm using Kernel 3.4.113-sun7i (ubuntu) at Banana Pi pro and Wifi is working well out of the box. Unfortunately it isn't switched off, when LAN is connected, so I searched a way to deactivate it manually. Unfortunately, I tried this: sudo nmcli r wifi off That did, what I expected. But after switching back sudo nmcli r wifi on It is not longer able to connect to my WPA2-AP. Syslog shows: Feb 26 22:44:24 localhost wpa_supplicant[779]: nl80211: Could not re-add multicast membership for vendor events: -2 (No such file or directory) Feb 26 22:44:24 localhost wpa_supplicant[779]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (none) none Feb 26 22:44:24 localhost wpa_supplicant[779]: dbus: Failed to construct signal Feb 26 22:44:27 localhost wpa_supplicant[779]: wlan0: Trying to associate with XX:XX:XX:XX:XX:XX (SSID='XYZ123' freq=2437 MHz) Feb 26 22:44:27 localhost wpa_supplicant[779]: wlan0: Associated with XX:XX:XX:XX:XX:XX Feb 26 22:44:27 localhost wpa_supplicant[779]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE Feb 26 22:44:31 localhost wpa_supplicant[779]: wlan0: CTRL-EVENT-DISCONNECTED bssid=XX:XX:XX:XX:XX:XX reason=2 Feb 26 22:44:31 localhost wpa_supplicant[779]: wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect Feb 26 22:44:31 localhost wpa_supplicant[779]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="XYZ123" auth_failures=1 duration=10 reason=WRONG_KEY Feb 26 22:44:31 localhost wpa_supplicant[779]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD which says more or less, that the PSK is wrong - but it hasn't changed. Maybe it is related to the message in line 2 above? Any hint is welcome, where I can search to make the link working again without reinstalling the whole system. BR GD
  4. I tested the actual Xenial on my BPP but got a crashdump each time I reboot or shutdown the system. I found, that armhwinfo was causing this crash by removing the module a20_tp. Disabling the line /sbin/modprobe -r $(cut -f1 -d' ' </proc/modules) in /etc/init.d/armhwinfo avoid this problem. This line is part of a patch Thomas Kaiser introduced in October last year. I don't know, if this problem occurs only in my configuration (nothing special, but a connected Lemaker 5" LCD may be the difference), or it is related to the Kernel 3.4.113 only, but it goes reproducably wrong, if this line is active. It cause the oposite of the intention of this patch, because after the crash, the next module (sunxi_ir) is ending in a loop. So no sync is executed and the power stays on. Without this line, all works well. I think, the patch has to be patched again - don't touch a20_tp. BR Guido