P4wnP1_aloa icon indicating copy to clipboard operation
P4wnP1_aloa copied to clipboard

Display HAT's and VCHI(Q) issues on P4wnP1_aloa v0.1.1-beta

Open xorr0 opened this issue 4 years ago • 1 comments

I've tried everything I can think of in attempt to get my 1.3inch 240x240 IPS LCD display HAT for Raspberry Pi to work on my raspberry pi zero w. Specifically I've been trying to get the display working using fbcp-ili9341 on P4wnP1_aloa v0.1.1-beta using the guide from fbcp-ili9341 issue#109 as it pertains to my exact same display and kali linux.

I can get fbcp-ili9341 built BUT it just flat out will NOT work on the current P4wnP1_aloa v0.1.1-beta as it fails with the error * failed to open vchiq instance. IMHO it's due to an issue with the current state of kernel build? with reference to the bcm2835_vchiq (which I've only found out exists in troubleshooting this issue). To help anyone else that comes across this issue, I found this and this to be helpful in explaining what a VCHIQ is and does.

I am aware that P4wnP1_aloa has not upgraded to a newer re4son kernel version due to some specific issues with the wifi firmware (based on the v0.1.1-beta release notes). I am open to learing the process to rebuild the 4.14.80 re4son kernel myself on the P4wnP1_aloa to see if I can troubleshoot things in effort to get it to work, but I've yet to figure out/learn that exact process so far.

I can get the display working just fine running the current version of 2020.2a Kali Linux RaspberryPi Zero/Zero W which runs re4son 4.19.93-Re4son+ kernel

  • Here is the exact error I get when running the built fbcp-ili9341 from using the guide from fbcp-ili9341 issue#109:
root@kali:~/devel/fbcp-ili9341/build# ./fbcp-ili9341
bcm_host_get_peripheral_address: 0x20000000, bcm_host_get_peripheral_size: 33554432, bcm_host_get_sdram_address: 0x40000000
BCM core speed: current: 400000000hz, max turbo: 400000000hz. SPI CDIV: 30, SPI max frequency: 13333333hz
Initializing display
InitSPI done
* failed to open vchiq instance
  • Here is an output from dmesg on my raspberry pi zero w running P4wnP1_aloa v0.1.1-beta that reports issues with a missing firmware node (this happens on a FRESH install of P4wnP1_aloa v0.1.1):
root@kali:~# dmesg | grep -i vchiq
[    0.428865] bcm2835_vchiq 2000b840.mailbox: Missing firmware node
[    0.430793] bcm2835_vchiq: probe of 2000b840.mailbox failed with error -2
  • Not much comes up on google searches, but this showed up where someone mentions the issue is related to:

    This looks like you are running a upstream DTB with a downstream kernel.

    • Hell, I even tried just moving over the /boot/bcm2708-rpi-zero-w.dtb from 2020.2a Kali Linux RaspberryPi Zero/Zero W just to see, but no go. According to /boot/overlays/README it explains how to troubleshoot Directory Tree issues by setting dtdebug=on in /boot/config.txt, rebooting and running vcdbg log msg but that didn't give me any insights into bcm2835_vchiq issues.
  • Comparing P4wnP1_aloa v0.1.1-beta and 2020.2a Kali Linux RaspberryPi Zero/Zero W, I've found that the /dev/vchiq does not exist on P4wnP1_aloa v0.1.1-beta, yet one exists on 2020.2a Kali Linux RaspberryPi Zero/Zero W:
root@kali:~/devel/fbcp-ili9341/build# ls -al /dev/vchiq
ls: cannot access '/dev/vchiq': No such file or directory

~~~VERSUS KALI~~~

root@kali:/home/kali# ls -al /dev/vchiq
crw-rw---- 1 root video 243, 0 Jul 12 11:54 /dev/vchiq
  • Running an HDMI status check, I get an error about VCHI:
root@kali:/opt/vc/bin# ./tvservice -s
[E] Failed to initialize VCHI (ret=-1)
  • During troubleshooting I've found an issue with shared libraries, where the dynamic loader wasn't searching /opt/vc/lib:
root@kali:/lib/arm-linux-gnueabi# ldd /opt/vc/lib/libvchiq_arm.so
        libvcos.so => not found
        libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xb6f85000)
        libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xb6f72000)
        librt.so.1 => /lib/arm-linux-gnueabi/librt.so.1 (0xb6f5b000)
        libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xb6e06000)
        /lib/ld-linux.so.3 (0xb6fba000)
  • Simple fix was to add the file /etc/ld.so.conf.d/00-vmcs.conf (like Kali linux has) to point to /opt/vc/lib and running ldconfig:
root@kali:/opt/vc# echo "/opt/vc/lib" > /etc/ld.so.conf.d/00-vmcs.conf
root@kali:/opt/vc# ldconfig
root@kali:/opt/vc# ldd /opt/vc/lib/libvchiq_arm.so
        libvcos.so => /opt/vc/lib/libvcos.so (0xb6f60000)
        libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xb6f34000)
        libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xb6f21000)
        librt.so.1 => /lib/arm-linux-gnueabi/librt.so.1 (0xb6f0a000)
        libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xb6db5000)
        /lib/ld-linux.so.3 (0xb6f7c000)
  • While talking about /opt/vc, there is an issue with all the files in /opt/vc/bin not being seen in the $PATH, I personally just setup dynamic links for all files /opt/vc/bin to /usr/bin

  • I am not sure exactly what is going on, as the P4wnP1_aloa v0.1.1-beta kernel config says it was built with CONFIG_BCM2835_VCHIQ=y:

root@kali:~# modprobe configs
root@kali:~# zgrep -i vchi /proc/config.gz 
CONFIG_BCM2835_VCHIQ=y
CONFIG_BCM2835_VCHIQ_SUPPORT_MEMDUMP=y
  • The difference on 2020.2a Kali Linux RaspberryPi Zero/Zero W kernel config is that it has a VCHIQ_MMAL module enabled:
root@kali:/home/kali# zgrep -i vchi /proc/config.gz
CONFIG_BCM2835_VCHIQ=y
CONFIG_BCM2835_VCHIQ_MMAL=m

root@kali:/home/kali# lsmod | grep -i vchi
bcm2835_mmal_vchiq     32768  2 bcm2835_codec,bcm2835_v4l2
vc_sm_cma              36864  1 bcm2835_mmal_vchiq

root@kali:/home/kali# modinfo bcm2835_mmal_vchiq
filename:       /lib/modules/4.19.93-Re4son+/kernel/drivers/staging/vc04_services/vchiq-mmal/bcm2835-mmal-vchiq.ko
version:        0.0.1
license:        GPL
author:         Dave Stevenson, <[email protected]>
description:    BCM2835 MMAL VCHIQ interface
srcversion:     A704BFEFA76A443EAA7F079
depends:        vc-sm-cma
staging:        Y
intree:         Y
name:           bcm2835_mmal_vchiq
vermagic:       4.19.93-Re4son+ mod_unload modversions ARMv6 p2v8

I am not sure what the solution is, I figured I would post this in an effort to obtain feedback -- or to present findings to others that may have gone down this rabbithole to let them know you are not alone. I am willing to do any legwork if anyone has suggestions/comments. Here's to hoping the next P4wnP1_aloa build has a updated re4son kernel that everything works properly.

PS: I also had no luck dealing with fbtft, but concentrated most troubleshooting on the fbcp-ili9341 project, hence the report centering on it.

xorr0 avatar Jul 13 '20 13:07 xorr0

Hi @xorr0 I was just considering using an waveshare oled hat with buttons to navigate using the oled screen. There is a nice tutorial on how to achieve this. The only problem however is that the 3d case print model isn't covering the oled screen and buttons unfortunately.. I will receive my raspberry pi zero W with pre installed headers in 2 weeks. I wanted to use it as a wpa handshake capturer (pwnagotchi with e-ink screen) but now I ain't sure I might give P4wnP1_aloa a try with or without oled screen. What have you ended up doing with the P4wnP1_aloa and the display Hat? Sorry for my grammar mistakes english is my secondary language.

saqeria avatar Aug 26 '20 21:08 saqeria