There's always time to play

Tuesday, January 13, 2009

Kernel Mode-Setting on Intel hardware

Today I was going to try kernel modesetting, or kms in short, on my machines with intel graphic chipsets. First I was going to try it on was my 'old' laptop with an intel 915 chipset. I configured a 2.6.29-rc1 kernel and tried it, but as soon as it wanted to change mode my screen would turn black and only show something as soon as X was started again. One time it did seem to have working consoles again after X was started, but that didn't seem reproducible.

I decided to move to the next victim, my MSI Wind with intel 945 chipset. I was hoping a newer chipset would work better, so I took the same route again and rebooted, and it worked! The only thing that didn't work was X, but I knew I had to get something near version 2.6 of the intel Xorg driver to have that working with kms again.

So while I installed new drivers I went looking for the differences between the kernel configurations of both machines. I started at the framebuffer section, because I knew I had the uvesafb driver compiled in on my 'old' laptop and I had intelfb compiled in on both laptops, so my first guess was to disable the uvesafb driver and try what happens. Immediate success, I had native 1680x1050 on the console on my 'old' laptop, and X would even start. I didn't have recent intel Xorg drivers however, so switching between X and consoles was still as slows as it had always been. But having the consoles at native resolution is already so much of an improvement, that you shouldn't really care.

Meanwhile, my MSI Wind had finished installing newer intel Xorg drivers and I was ready to start X, success again. Switching between X and consoles is simply amazingly fast. I have however noticed a small issue here, somehow gdm thinks the vertical resolution is about twice what it really is, so I only see the top half of the screen and thus no login box. Once I'm logged in the issue seems to persist and my cursor is invisible, but my terminal keyboard shortcut works and the terminal is completely visible, so I can live with that for now.

Next machine is my Asus EEEpc 701/4G surf, which features an intel 915 chipset again. I compiled a 2.6.29-rc1 kernel again, using the config I made last week when I created my bootable usb stick. Copied the kernel to my usb stick, booted and... failure. Same kind of problem as on my 'old' laptop, screen turns black. Because I use the gentoo minimal image I never get to a X server either, so it stays black. Back to the kernel config, what went wrong? Somehow console framebuffer support was turned off, and I also had some other options turned off like low level display driver support. I don't think the latter really matters, but the first was an issue. After that it booted fine, except for the fact that I now used the in-kernel squashfs support which was at version 4.0 already, while the patch I previously used to patch my kernel sources was at version 3.4. Seems like the disk-format changed in between, so I can't mount the image, but I can get the fancy native resolution console.

Everything seems to work now, except for one thing, my 'old' laptop refuses to start X after updating to one of the 2.6 beta intel graphic drivers. Seems to get a hard lock, so I'll have to dig into that. I might have some newer packages installed on my msi wind, so I'll start by comparing versions and then I'll see. So far I'm happy.

Other issues I noticed are that on all the machines I seem to get some output from the drm driver that something is going wrong, including occasional call traces where something apparently went terribly wrong, but almost everything works. I also noticed that after a while the screen blanks, even though I think it shouldn't. Even worse, pressing a key won't turn it back on again, but switching to console, pressing a key does. After that I can switch back to X again and it works.

So now I only have one thing left to do, and that's check if it also works on the MacBook me and my girlfriend use together, but I guess I'll have to do some more work on my bootable usb stick before that's going to work.

Wednesday, January 7, 2009

Creating a multiboot USB-stick using syslinux

Since I have an eeepc-701, I need a way to boot it from external media so I can mess with it. I have a Corsair Flash Survivor (16GB), so I'm going to use that for rescue-goodness. I'll give step by step instructions on how to create a similar boot disk. In these instructions I'll assume that /dev/sdc is the usb drive, /dev/sdc1 is the partition we're using for the filesystem. Further mine will be mounted at /media/Corsair and I'll also assume you can find the appropiate packages if you haven't gotten them yet (dosfstools and syslinux in gentoo). Last but not least most of these commands will need root permissions, so prepend them with sudo if that's your thing, or become root and do it all as root.

Format the usb drive as fat 32
Of course there are other options than fat 32 to create a bootable usb drive, but syslinux needs a FAT filesystem to work.
# mkdosfs -F 32 -n Corsair /dev/sdc1

Mount the usb drive
Unplugging and replugging will work for me as I use Gnome with automount support, should probably work for most people using a larger desktop environment. If not:
# mkdir -p /media/Corsair
# mount /dev/sdc1 /media/Corsair

Create a syslinux directory
Syslinux needs somewhere to store its files, I prefer doing that in a directory so I don't get a cluttered view every time I look at the files on my usb drive.
$ mkdir /media/Corsair/syslinux

Unmount and install syslinux
Unmount in whatever way suits you, just don't unplug yet. The -d option tells syslinux to use our directory 'syslinux' to store its files, just make sure the directory is there before running syslinux.
# umount /media/Corsair
# syslinux -d syslinux /dev/sdc1

Mount again
Remount the device to put more on it than just syslinux.
# mount /dev/sdc1 /media/Corsair

There's only two things left to do now:
1. Move images to the usb drive
2. Create the syslinux.cfg file

Move images to the usb drive
I create two directories to start with: gentoo and gparted. Inside the gentoo directory I put the kernel, initrd and squashfs from the minimal install cd and renamed them to include the release number in the files. At first I named my kernel just 'kernel-2008.0', but that seems to confuse syslinux so I renamed it to kernel-2008.0.img in the end. Better extensions suggestions for the kernel are welcome. I also copied all the .msg files from the gentoo cd to the syslinux directory I created on the root of the filesystem, so I can press F1-F6 and see irrelevant gentoo messages, however, changing these is easy and will be done when I have more time. It also seems gentoo needs a file called 'livecd' on the root, else it won't find the media as the fs media. It's cluttering the drive, but removing the file will just cause gentoo not to find a valid root fs. Last but not least I compiled a kernel that has support for most of the hardware in my eeepc 701/4G surf, and named that 'kernel-eee' straight on the root of the USB drive. I needed at least 2.6.28 so I could have support for the onboard network card, whatever way I'm installing it I'm gonna want network support. The kernel is monolithic (no modules and no module loading support) and works fine with the gentoo 2008.0 squashfs.

Inside the gparted directory I again put the kernel, initrd and squashfs files. I just took them from the livecd, left names as they were.

Create the syslinux.cfg file
I took most of this file straight out of the isolinux.cfg that came on the gentoo cd and customized where necessary.
default gentoo
timeout 150
prompt 1
display boot.msg
F1 kernels.msg
F2 F2.msg
F3 F3.msg
F4 F4.msg
F5 F5.msg
F6 F6.msg
F7 F7.msg

label eee
kernel /kernel-eee
append root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs loop=/gentoo/minimal-2008.0.squashfs cdroot initrd=/gentoo/initrd-2008.0.igz

label gentoo
kernel /gentoo/kernel-2008.0.img
append root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs loop=/gentoo/minimal-2008.0.squashfs cdroot initrd=/gentoo/initrd-2008.0.igz vga=791

label gentoo-nofb
kernel /gentoo/kernel-2008.0.img
append root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs loop=/gentoo/minimal-2008.0.squashfs cdroot initrd=/gentoo/initrd-2008.0.igz

label gparted
kernel /gparted/vmlinuz
append initrd=/gparted/initrd1.img boot=live union=aufs noswap vga=791 ip=frommedia nolocales live-media-path=gparted

label memtest86
kernel memtest86

Syslinux uses relative paths by default, so if you use no '/' syslinux will look for the files inside the dir syslinux is. The solution is simple, use absolute paths for the kernel and initrd and it's all OK. Most important change made to this file is the append lines. For gentoo, the loop parameter needs to point to the squashs image, so I changed that to /gentoo/minimal-2008.0.squashfs (name of the image in my case). I added a line for my eeepc kernel, which just boots into a gentoo minimal cd.

Next was gparted. Gparted supports a 'live-media-path=' parameter, this needs to be used when the gparted squashfs image is not directly in the root of the filesystem on the usb drive. Other than that gparted just looks for any file with name *.{squashfs,ext2,ext3,jffs2} so the name doesn't really matter as long as the extension hasn't changed.

I also left the memtest line in place, added the memtest image to the root of the drive and my rescue-drive is mostly done.

It should also be possible to do the same thing using grub, except for the F1-F6 messages and the default message (or can grub do that too?). I'm definately gonna add grub to it, probably replacing syslinux with grub. Using grub might also allow for use of other filesystems on the drive, which might end up being a big plus too. Come back again to read about that, once I've tried it myself.

Sunday, January 4, 2009

Configuring a linux kernel for another architecture than host

On my 64 bit gentoo installation I wanted to compile a kernel for 32 bit machines (specifically my eee pc 701), but somehow menuconfig was as smart to notice I was running a 64 bit machine and so showed me stuff to build a 64 bit kernel. After a quick search I found the solution:
make ARCH=i386 (oldconfig|menuconfig|)