Raspberry Pi setup notes part 1: getting the display to work!

About

Contact

Raspberry Pi setup notes part 1: getting the display to work!

Posted on 20 June 2012 in Raspberry Pi

I received my Raspberry Pi yesterday, and today got it working well enough to display a text-based console on a DVI monitor using Arch Linux. There were a few hiccups along the way, so here are the complete notes so that anyone googling for the same errors as the ones I saw can benefit from my experience.

tl;dr: the file /boot/config.txt sets up various things before the OS is loaded, including HDMI settings. The one in the Arch Linux SD card image didn't work with my machine setup. The system default, which you can get just by removing that file completely, worked just fine.

Here are the details showing how I got to that...

I started with a Stock Arch Linux SD image
The monitor was a basic Acer DVI one, 1280x1024. It was attached to the RPi's HDMI port using a DVI -> HDMI adapter (labelled DVI-D -> HDMI) from Nikkai via Maplin. NB there are lots of different kinds of DVI plugs/sockets: here are some diagrams on Wikipedia. The socket on the adapter had holes for DVI-I dual link, and the plug from the monitor's cable was DVI-D single link. Nonetheless, as I eventually got it working, I guess that they are intercompatible to some degree.
As well as the monitor, the RPi was plugged into a USB keyboard, and an ethernet switch.
When I plugged my MicroUSB mains adapter into the RPi, the display remained blank -- it said there was no signal.
I checked out the logs of my DHCP server and saw that something called alarmpi had just got a lease, so I sshed to the IP and was able to log in using the default username/password for the Arch Linux distro (root/root) It was obviously working :-) :-) :-) (BTW the best guess around the office is that alarmpi is Arch Linux ARM Pi.
A bit of poking around with Google found various forum posts, many of which suggested that the key was the settings in /boot/config.txt
So I decided to look at that file in my ssh session. On the image I was using, it contained this:

hdmi_mode=19
#arm_freq=800
disable_overscan=1

A forum post referenced this page, which appears to be a script to build a Debian wheezy image for the RPi; specifically, it contains the complete /boot/config.txt for that image, which has detailed comments explaining what a bunch of the switches do. So I edited my own config, merging that file in with the original settings (which I flagged with ### Original OOB setting:

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
### Original OOB setting:
disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
### Original OOB setting:
hdmi_mode=19

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# for more options see http://elinux.org/RPi_config.txt

I noticed that saving the file was slow. My best current guess for why this is is that the boot stuff is mounted from a separate tiny partition at the start of the SD card, FAT-formatted, which the RPi's chipset knows how to read to start the whole bootstrap process before there's even an operating system installed. And writing to that partition is just harder work than writing to a normal one. But perhaps I'm completely off-base about the reason for the slowdown, although I'm pretty sure about the bootstrap/partition thing.
Anyway, the hdmi_safe setting looked interesting, so I tried uncommenting it and rebooting. That didn't help.
Another likely one was suggested in this forum post: setting hdmi_force_hotplug=1. But that didn't help either.
I'd also noticed that people were suggesting running /opt/vc/bin/tvservice as a diagnostic tool; I ran it, but it failed:

[root@alarmpi ~]# /opt/vc/bin/tvservice
/opt/vc/bin/tvservice: error while loading shared libraries: libvcos.so: cannot open shared object file: No such file or directory

Clearly something important was either missing or just not on the search path. Check:

[root@alarmpi ~]# ldd /opt/vc/bin/tvservice
        libvcos.so => not found
        libpthread.so.0 => /lib/libpthread.so.0 (0x400f9000)
        libdl.so.2 => /lib/libdl.so.2 (0x40074000)
        librt.so.1 => /lib/librt.so.1 (0x4007f000)
        libc.so.6 => /lib/libc.so.6 (0x4013f000)
        /lib/ld-linux.so.3 (0x4004c000)

Right. This forum post made it clear where it was, so:

[root@alarmpi ~]# ls /opt/vc/lib/
libbcm_host.so    libEGL.so        libGLESv2_static.a  libkhrn_static.a  libmmal.so       libvcfiled_check.a  libvcos.so
libcontainers.so  libEGL_static.a  libilclient.a       libluammal.so     libopenmaxil.so  libvchiq_arm.a      libvmcs_rpc_client.a
libdebug_sym.so   libGLESv2.so     libkhrn_client.a    liblua.so         libOpenVG.so     libvchostif.a       libWFC.so
[root@alarmpi ~]# export LD_LIBRARY_PATH=/opt/vc/lib/:LD_LIBRARY_PATH
[root@alarmpi ~]# ldd /opt/vc/bin/tvservice
        libvcos.so => /opt/vc/lib/libvcos.so (0x400c2000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4012d000)
        libdl.so.2 => /lib/libdl.so.2 (0x40038000)
        librt.so.1 => /lib/librt.so.1 (0x400ff000)
        libc.so.6 => /lib/libc.so.6 (0x4014d000)
        /lib/ld-linux.so.3 (0x40010000)

Good. Now let's get some diagnostics:

[root@alarmpi ~]# /opt/vc/bin/tvservice -s
state 0x40002, 720x480 @ 60Hz, interlaced
[root@alarmpi ~]# /opt/vc/bin/tvservice -m CEA
Group CEA has 0 modes:
[root@alarmpi ~]#

Hmmm. Not terribly helpful. But maybe there are more options? This forum post suggested one:

[root@alarmpi ~]# /opt/vc/bin/tvservice -m DMT
Group DMT has 13 modes:
           mode 4: 640x480 @ 60Hz, progressive
           mode 5: 640x480 @ 72Hz, progressive
           mode 6: 640x480 @ 75Hz, progressive
           mode 8: 800x600 @ 56Hz, progressive
           mode 9: 800x600 @ 60Hz, progressive
           mode 10: 800x600 @ 72Hz, progressive
           mode 11: 800x600 @ 75Hz, progressive
           mode 16: 1024x768 @ 60Hz, progressive
           mode 17: 1024x768 @ 70Hz, progressive
           mode 18: 1024x768 @ 75Hz, progressive
           mode 21: 1152x864 @ 75Hz, progressive
           mode 35: 1280x1024 @ 60Hz, progressive
           mode 36: 1280x1024 @ 75Hz, progressive

ooookay... mode 35 looks the most relevant for my monitor...
But reading the forum post further, it also sounds like removing the config.txt and rebooting is a good thing for debugging. Let's do that first.

[root@alarmpi ~]# mv /boot/config.txt .
[root@alarmpi ~]# ls /boot
arm128_start.elf  bootcode.bin      kernel_emergency.img  start.elf
arm192_start.elf  cmdline.txt       kernel.img
arm224_start.elf  kernel_debug.img  loader.bin
[root@alarmpi ~]# ls .
config.txt

Rebooted, and... well, bugger me, it worked!