Poking at a 3.4 kernel on a GFN

[Kurlon]

Because I heard rumors of improved kernel LZO performance in 3.3, and known improvements in udlfb perf in 3.3 I've decided to try and get the latest kernel running on my GFN.

Starting with the existing core/linux PKGBUILD and tweaking it to pull down 3.4 and patch as is failed miserably:
http://pastie.org/3958914

The first error is in arch/arm/mach-kirkwood/mpp.h

The patch:
$this->bbcode_second_pass_code('', '--- arch/arm/mach-kirkwood/mpp.h 2011-10-24 07:10:05.000000000 +0000
+++ arch/arm/mach-kirkwood/mpp.h 2012-05-10 00:59:12.771678903 +0000
@@ -102,6 +102,7 @@
#define MPP11_SATA0_ACTn MPP( 11, 0x5, 0, 1, 0, 1, 1, 1, 1 )

#define MPP12_GPO MPP( 12, 0x0, 0, 1, 1, 1, 1, 1, 1 )
+#define MPP12_GPIO MPP( 12, 0x0, 1, 1, 1, 1, 1, 1, 1 )
#define MPP12_SD_CLK MPP( 12, 0x1, 0, 1, 1, 1, 1, 1, 1 )
#define MPP12_AU_SPDIF0 MPP( 12, 0xa, 0, 1, 0, 0, 0, 0, 1 )
#define MPP12_SPI_MOSI MPP( 12, 0xb, 0, 1, 0, 0, 0, 0, 1 )')

What's already there:
$this->bbcode_second_pass_code('', '#define MPP12_GPO MPP( 12, 0x0, 0, 1, 1, 1, 1, 1, 1 )
#define MPP12_GPIO MPP( 12, 0x0, 1, 1, 0, 0, 0, 1, 0 )
#define MPP12_SD_CLK MPP( 12, 0x1, 0, 0, 1, 1, 1, 1, 1 )
#define MPP12_AU_SPDIF0 MPP( 12, 0xa, 0, 0, 0, 0, 0, 0, 1 )
#define MPP12_SPI_MOSI MPP( 12, 0xb, 0, 0, 0, 0, 0, 0, 1 )
#define MPP12_TW1_SDA MPP( 12, 0xd, 0, 0, 0, 0, 0, 0, 1 )')

So, the question is, use the provided definition for MPP12_GPIO or adjust the patch to replace it with the one ALARM has been using already?

The next two failures are in arch/arm/mach-kirkwood/sheevaplug-setup.c and come from the fact that the kernel already has the changes the patches bring, so that's an easy fix to the PKGBUILD.

drivers/mmc/core/core.c faults because the timeouts have been raised even further than ALARM tweaks them too. Easy patch to adjust, can leave the initial timeout as is and just bump the secondary.

The last batch of errors are in drivers/net/wireless/mwifiex/sdio.c and it looks like it's a combo of some of the tweaks already being present plus some formatting changes futzing the works. Should be easy enough for me to correct.

[WarheadsSE]

The mwifiex.* I got pulled into 3.4, thus is unneeded from that point on

[Kurlon]

Sweet, looks like most of my 'work' will just be removing expired patches then.

[Kurlon]

I've got the archlinuxarm.patch file cleaned up, that's applying cleanly with no warnings now, so I'm up to updating .config for 3.4.

http://pastie.org/3961342

The former gentoo user in me is screaming to say 'Y' to this.

[Kurlon]

http://pastie.org/3961385

Build failed at init/main.o. I want to say I've seen this ld error pop up in the forum recently?

[Kurlon]

I temporarily edited /etc/makepkg.conf to remove -Wl from LDFLAGS which got me around that hangup. Nest stumbling block was at: http://pastie.org/3961566

I need to review the sheevaplug esata patches again.

[Kurlon]

Got most things cleaned up, build was looking good... died in aufs?

http://pastie.org/3961857

Digging to see what I can find on this one.

[Kurlon]

Cheated and removed the aufs patches for now, that got me past that hurdle. New fail is in libertas wireless.

http://pastie.org/3962654

I've no idea on this one either.

[Kurlon]

After much mucking around, and nearly bricking my GFN in the process, I've got a working GFN running a 3.4 kernel.

It was not a clean process. To start, I had to tweak the LDFLAGS setting in /etc/makepkg.conf

$this->bbcode_second_pass_code('', '#LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
LDFLAGS="-O1,--sort-common,--as-needed,-z,relro"')

Next I had to clean up some patches to account for changes in the src, as well as drop some patches. Most notably I dumped the AUFS 3 patches out of the process as they were breaking the build. Once that was done I could complete a kernel build without issue, huzzah!

Too bad it wouldn't boot. I got nailed by the Kirkwood/u-boot/3.2 bug. Fortunately someone over at Doozan's forums has been experimenting on this front and has a patched up modern u-boot that deals with the issue.

http://forum.doozan.com/read.php?3,6965

Once I upgraded, I thought I bricked my GFN, no boot, no netconsole. Turns out I hadn't completely destroyed it, but it'd only boot off USB, the boot env was gone. More pain later I finally got a working env sorted and successfully booted into 3.4!

http://pastebin.ca/2156370 - u-boot env
http://pastebin.ca/2156372 - dmesg showing 3.4

So far, so good! 3.4 nets me an improved udlfb module that supports the xorg damage extension. When enabled this results in a dramatic improvement in perf for my USB displaylink adapter. Unfortunately, ALARM's xorg build does not have the patch for fbdev applied to allow it to support this feature... so I punted and built libdlo and xorg-displaylink from AUR instead. Note, I had to set LDFLAGS back to stock for these to work.

https://aur.archlinux.org/packages.php?ID=26552 - just add 'arm' and build and install
http://aur.archlinux.org/packages.php?ID=33110 - grab the submitted updated PKGBUILD from the thread rather than the one in AUR, add 'arm', build and install

To enable the displaylink driver, you need a config stub file in /etc/X11/xorg.conf.d ala:
$this->bbcode_second_pass_code('', 'Section "Device"
Identifier "dl"
Driver "displaylink"
Option "ReportDamage" "true"
Option "fbdev" "/dev/fb0"
EndSection')

This assumes you've got a working displaylink device. If you have a bastard child unit that shows up as a mass storage device, toss this into your udev rules dir:

$this->bbcode_second_pass_code('', 'ATTR{idVendor}=="17e9", ATTR{bConfigurationValue}=="2", RUN+="/usr/bin/dlconfig %p"')

/usr/bin/dlconfig should look like:

$this->bbcode_second_pass_code('', '#! /bin/bash
if [ -e /sys$1/bConfigurationValue ]; then
/sbin/modprobe udlfb console=1 fb_defio=0 shadow=0
echo 1 > /sys$1/bConfigurationValue
/sbin/modprobe fbcon
fi;')

Make sure fb_defio is set to 0 if using the displaylink driver in xorg. If not, set it to 1 and use fbdev instead.

With all that, xfce wasn't happy, it'd load but the background never got set. Any menus wouldn't show up, windows tried clustering in the upper right corner, it just didn't play nice. Dropping down to twm and suddenly I'm in GFN + USB Video nirvana. The mouse pointer is glassy smooth instead of jerky, firing up video intensive apps like Paintown the screen doesn't loose sync randomly, and the update rate is MUCH higher. For giggles I went so far as to install mplayer and watch various video streams online, including an 800kbps techno feed and the machine managed to pull it off. It wasn't perfect, but it was usable. 640x480 seems to be the limit for 30fps activity, any larger a window and USB2's limitations start impacting you.

Unfortunately, the other reason I wanted to test 3.4 has gone missing, zram is no longer present nor do I see where to configure it in the kernel conf so I'll have to chase that down.

Known issues so far:
- The new uboot hangs scanning the USB bus for mass storage devices if my Kensington K33926 dock is plugged in at power up. The work around is to leave it unplugged until u-boot moves on to autobooting.
- Reboots don't, the system halts correctly, shuts down the USB port, turns the status LED off, and then just sits there. I need to get a serial cable going so I can take a closer look at what's going on to sort this one.
- 3.4 + displaylink == unhappy gtk apps, xfce in particular just doesn't like it.

[Kurlon]

Found out where zram went... it's now x86 only. Bah, have to wait for some portable functions to be written so I can get that functionality back.