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.txtsets 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, 1280×1024. 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
alarmpihad 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) It was obviously working :-) :-) :-) (BTW the best guess around the office is that
alarmpiis 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
- So I decided to look at that file in my
sshsession. 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.txtfor 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_safesetting 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/tvserviceas 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!