Jump to content

Enable HDMI in u-boot for RK3288


jock

Recommended Posts

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

Link to comment
Share on other sites

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 :/

Link to comment
Share on other sites

This is the u-boot environment:

Spoiler

arch=arm
baudrate=115200
board=xt-q8l-v10_rk3288
board_name=xt-q8l-v10_rk3288
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc0 mmc1 usb0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; ;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=0
cpu=armv7
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
fdt_addr_r=0x01f00000
fdt_high=0x0fffffff
fdtcontroladdr=7cf669a8
initrd_high=0x0fffffff
kernel_addr_r=0x02000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=reserved1,size=64K,uuid=${uuid_gpt_reserved1};name=reserved2,size=4M,uuid=${uuid_gpt_reserved2};name=loader2,size=4MB,uuid=${uuid_gpt_l;
preboot=usb start
pxefile_addr_r=0x00100000
ramdisk_addr_r=0x04000000
reset_reason=POR
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_foe
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} e
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x00000000
soc=rockchip
stderr=serial,vidconsole
stdin=serial,usbkbd
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
vendor=rockchip

Environment size: 4252/8188 bytes

 

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

Spoiler

=> coninfo
List of available devices:
serial@ff690000 00000007 IO
serial   00000003 IO stdin
nulldev  00000003 IO
vidconsole 00000002 .O stdout stderr

 

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.

Link to comment
Share on other sites

A nice recent finding: in u-boot console using the i2c command is useful to report the EDID of the connected monitor.

Setting the i2c bus to 5 and reading from address 50 reports the proper EDID of my monitor:

=> i2c dev 5
Setting bus to 5
=> i2c edid 50
EDID version: 1.3
Product ID code: 562d
Manufacturer: IVM
Serial number: 000001ae
Manufactured in week: 6 year: 2016
Video input definition: digital signal, voltage level 0
Monitor is non-RGB
Maximum visible display size: 51 cm x 29 cm
Power management features: active off, no suspend, no standby
Estabilished timings:
        720x400         70 Hz (VGA 640x400, IBM)
        640x480         60 Hz (VGA)
        640x480         67 Hz (Mac II, Apple)
        640x480         75 Hz (VESA)
        800x600         56 Hz (VESA)
        800x600         60 Hz (VESA)
        800x600         75 Hz (VESA)
        1024x768        60 Hz (VESA)
        1024x768        70 Hz (VESA)
        1024x768        75 Hz (VESA)
        1280x1024       75 (VESA)
Standard timings:
        1920x1080       60 Hz
        1280x1024       60 Hz
        1440x900        60 Hz
        1680x1050       60 Hz
        1280x960        60 Hz
        1152x864        75 Hz
        1440x900        75 Hz
        1920x1080       60 Hz (detailed)
Monitor range limits, horizontal sync: 30-83 kHz, vertical refresh: 55-76 Hz, max pixel clock: 170 MHz
Monitor serial number: 11298JG20043
Monitor name: PL2390

But the monitor is just in suspend mode, not displaying anything. It is turned on later when the kernel probes for mali gpu.

This should prove that the HDMI interface is *really* working,  but there are some "minor" bits to turn on the display

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines