Hyperpixel 4 display not working
steveiliop56 opened this issue · 6 comments
Hello,
I am trying to get my hyperpixel 4 display to work with aosp 14 on my rpi 4 but it doesn't seem to. I am using this config:
# Kernel
arm_64bit=1
kernel=Image
# Ramdisk
# gpio=21=ip,pu
# [gpio21=1]
initramfs ramdisk.img followkernel
# [gpio21=0]
# initramfs ramdisk-recovery.img followkernel
[all]
# Audio
dtparam=audio=on
# Audio DAC
#dtoverlay=allo-boss-dac-pcm512x-audio
#dtoverlay=allo-piano-dac-pcm512x-audio
#dtoverlay=allo-piano-dac-plus-pcm512x-audio
#dtoverlay=hifiberry-dacplus
#dtoverlay=i-sabre-q2m
#dtoverlay=iqaudio-dac
#dtoverlay=justboom-dac
# Boot device
dtoverlay=android-sdcard
#dtoverlay=android-usb
#dtoverlay=android-nvme
# Camera
camera_auto_detect=1
start_x=1
# CPU
arm_boost=1
#arm_freq=1500
# Display
disable_overscan=1
# Display panel
#[gpio21=1]
#dtoverlay=cutiepi-panel
#dtoverlay=vc4-kms-dsi-7inch
dtoverlay=vc4-kms-dpi-hyperpixel4
#dtoverlay=vc4-kms-dsi-lt070me05000
#dtoverlay=vc4-kms-dsi-lt070me05000-v2
[all]
#dtoverlay=rpi-backlight
# Fan
#dtoverlay=gpio-fan
#dtoverlay=i2c-fan
#dtoverlay=rpi-poe
#dtoverlay=rpi-poe-plus
# Graphics acceleration
disable_fw_kms_setup=1
#[gpio21=1]
dtoverlay=vc4-kms-v3d
[all]
# I2C
#dtparam=i2c_arm=on
# I2S
#dtparam=i2s=on
# IR
#dtoverlay=gpio-ir,gpio_pin=18
# Keys
#dtoverlay=gpio-key,gpio=21,keycode=116,label="POWER"
#dtoverlay=gpio-key,gpio=26,keycode=115,label="VOLUME_UP"
#dtoverlay=gpio-key,gpio=20,keycode=114,label="VOLUME_DOWN"
# RTC
#dtoverlay=i2c-rtc,ds3231
# Sensors
#dtoverlay=android-i2c-sensor,mpu6050
# Serial console
#enable_uart=1
# SPI
#dtparam=spi=on
# Touchscreen
#dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=0,swapxy=0,pmax=255,xohms=150,xmin=200,xmax=3900,ymin=200,ymax=3900
#dtoverlay=edt-ft5406
#dtoverlay=goodix
#dtoverlay=rpi-ft5406
# USB
dtoverlay=dwc2,dr_mode=peripheral
[cm4]
dtoverlay=dwc2,dr_mode=otg
[all]
include config_user.txt
Note: I removed all the gpio specific things because the hyperpixel requires all 40 pins.
As mentioned in #101, you would also need to change the forced display resolution. Since this appears to be using my personal build rather than your own build from Raspberry Vanilla source code, you would do this by removing/modifying /boot/resolution.txt as suggested in the FAQ on my site.
Also, please provide appropriate logs (logcat, dmesg) as it's impossible to tell otherwise.
Yeah the weird thing is if I use the config I provided before the system doesn't seem to boot. I connected an hdmi cable and I am not seeing anything neither on the hyperpixel neither on the hdmi display. Even if it is the forced resolution thing shouldn't it show anything on the hdmi display? The hyperpixel uses a custom dtoverlay so the the raspberry pi touchscreen setting in the settings is not suitable.
How would you use it on your regular Linux distribution (e.g. recent Raspberry Pi OS with Linux kernel version 6.1 or 6.6)? What additional configuration does it require? In addition to that, on Android you would need to change the forced display resolution to something that the display supports. Otherwise your display will show nothing.
But like said, there's no point in guessing without seeing any logs. You can use e.g. ADB on the USB-C to capture logs (since disabling serial console might be required). Looking at the vc4-kms-dpi-hyperpixel4 overlay, it uses SPI for something and I2C for touchscreen but those likely get enabled with the overlay regardless if you've set them in config.txt.
The Raspberry touchscreen settings option is only for the official Raspberry 7" DSI display/touchscreen.
In raspberry pi os I would firstly make sure that spi, i2c and serial console are all disabled them I would add dtoverlay=vc4-kms-dpi-hyperpixel4 in the end of my config.txt.
Yes, and if it hasn't been repeated enough already, on my Android releases there's one additional configuration requirement.
If it doesn't work with the suggested configuration, it's impossible to say why without seeing any logs.
Closing as there hasn't been any interaction in a month. Assuming the issue still exists but no logs were provided to help resolve the issue.