The method basically consists of cutting off the legs of the PLCC chip as close to the package as possible, so as to minimize strain on the paths on the motherboard while cutting. After that, the legs can easily be de-soldered from the board, and it’s trivial to solder on a PLCC socket. Obviously you loose the PLCC chip in the process, but this method is a lot easier than removing the PLCC chip with a heat gun. It’s also safer for the surrounding components.

Here are some photos:

The chip prior to modification.

Legs cut off on two sides of the chip. It’s important to use the right cutter for this job – it needs to be able to cut very closely to the package of the chip. I used a Hakko CHP Ergonomic Micro Cutter, part number TR20M.

PLCC chip removed.

PLCC chip without legs.

The legs have been de-soldered. If you look carefully near pins 1 and 2 on the top row, you’ll see I was foolish and used too much force and a too small soldering tip while de-soldering. I damaged the board. Luckily the pins involved are all on the same big pad, and everything still works.

This is the socket prior to soldering. I had to remove the plastic ‘floor’ of the socket in the center to allow easy access to the pins for soldering. You can put that piece of plastic back in the socket after it has been soldered onto the board, even loose. It will prevent PLCC chips from being pushed too deep into the socket, where not all pins might make contact with the socket.

The PLCC socket, installed.

And that works great. Recently, on deploying a new server, I discovered that the machine would just hang trying to kexec into Xen 3.2.1.

After a lot of digging and some fun setting up a test environment with qemu, I discovered that this broke somewhere between Xen 3.1.0 and 3.1.3. A message to the Xen-devel mailing list today yielded a quick response from a Xen developer suggesting I try the ‘no-real-mode’ parameter as an argument to the hypervisor.

The no-real-mode option stops Xen from doing some bios calls, and it also tells it to ignore the e820 bios table.

Here’s an lab.conf that works:

CMDLINE="no-real-mode com1=115200,8n1 cdb=com1"
INITRD=""
KERNEL="/xen-3.1.4.gz"
MODULE1="/vmlinuz-2.6.18.8-xen root=/dev/md1 ro xencons=ttyS0 console=tty0 console=ttyS0,115200"
MODULE2="/initrd.img-2.6.18.8-xen"

Note that you need to pass no-real-mode as the first xen command line argument, otherwise it won’t work.

And somehow that solves the problem for Xen 3.1.3 and 3.1.4, both under qemu + coreboot and qemu + bochs. Kexec’ing into Xen 3.1.2 triple-faults qemu under qemu + coreboot, but works fine under qemu + bochs. That smells like a coreboot bug. I’ll try on real hardware tomorrow to see if this bug is specific to our qemu port, or a more general coreboot problem. To be continued..

Many thanks to the folks who made this happen:

* Konsult Stuge
* coresystems GmbH
* Kitchener Waterloo Linux User Group and Richard Weait
* Breakfast Design

Marc’s AMD talk [PDF] was fascinating – AMD’s really behind coreboot, and there is a lot of hardware support in the pipeline. Awesome stuff.

Finally, we also ported a new board to v3: support for the PC Engines Alix.2C3 is now in the coreboot v3 tree. It’s not perfect yet – there’s an irq conflict between the usb ports and eth2 that needs to be sorted out, but we hope to fix that shortly and other than that it works great.

Update 2008-04-18: this is the Silicon Mechanics press release.

Update 2008-05-09: the irq issues on the alix.2c3 are resolved. Get revision 680 or higher.

I rarely give presentations so I figured I’d better spend some time to configure my laptop (a Dell 1420N) properly. The first step was easy – the Fn-F8 CRT/LCD button just works – it duplicates the LCD output onto the external VGA connector. I had never tried this before

I’m writing my talk in OpenOffice.org Impress, which I then export to PDF and show in Evince‘s excellent presentation mode.

I wanted to be able to control the slideshow via Bluetooth with my phone, a Nokia E70 – and it turns out that’s easy with the excellent anyRemote software. I already had bluetooth working for obex file transfers between the phone and the computer.

While connecting to the phone from the computer worked fine for file transfers, I could not connect from the phone to the computer. The phone gave me the message that the computer was an ‘unsupported device’. Redoing the bluetooth pairing seemed to fix that, I’m not sure yet why.

Making sure that the computer is discoverable can be done with:

hciconfig hci0 piscan

I also had to tell the computer to switch to ‘security mode 3′ and enable authentication and encryption:

hciconfig hci0 auth
hciconfig hci0 encrypt

Here’s what I did:

* installed anyremote, anyremote-docs, anyremote-j2me-client and ganyremote debian packages from the anyRemote download area on sourceforge.
* copied /usr/share/anyremote-J2ME-client/anyRemote64.jar to the phone via obex, and installed it on the phone. This is the anyRemote client.
* copied nokia-e70.cfg and keyboard.cfg from the cfg-data subdirectory of the anyremote tarball to /etc/anyremote (these files are not in the anyremote debian package for some reason)
* started up ganyremote, and pointed it at /etc/anyremote for config files; made sure to have it show ‘examples’ in the application list
* start anyRemote from ganyremote
* use the gAnyRemote device browser to locate the phone; configured it to always run the nokia E70 sample application when it sees the phone
* started up the anyRemote client on the phone; searched for computer, found it, connected to it

With the E70 application selected, you essentially get bluetooth keyboard functionality. With the ‘keyboard’ application selected, you get a few keys mapped to the numeric phone keypad.

With this, I can put Evince in presentation mode and move between slides by using the phone’s joystick. If I leave the gAnyRemote application running I just have to connect to the computer from the phone, fire up the anyRemote client, and I’m in business.

Using buildrom makes building a ROM image very simple – it’s a matter of doing

make menuconfig

and then selecting the relevant options, followed by

make

The major obstacle for this board remains the hardware – some soldering is required, and the newer revisions of the board have a new kind of ROM chip that flashrom can not handle yet. But we’re going to work on that.

But they still have a proprietary BIOS. This particular 4801 came with BIOS version 1.29, which was succeeded by version 1.30, with these errata:

comBIOS vers 1.30
* fixed bug from 1.29 with LBA disk translation
* fixed net48xx Serial COM1 RI noise SMI lockup

I was having problems with grub on a compactflash card – grub error 16, which means corrupt filesystem, which is not the case. I came across this hint that a BIOS upgrade might solve the problem. Upgrading the BIOS should be simple, right? There’s a ‘download’ command, and then a ‘flashbios’ command. The download has to happen with … Xmodem/CRC. Seriously.

And that turns out to be a bit less than trivial on a modern GNU/Linux system. Minicom has a send file mode, of course, but I couldn’t get the file across, kept getting errors like ‘Retry 0: NAK on sector’. Minicom was configured to call the ‘sx’ command. I tried with ‘cu’, but couldn’t get that to work either.

In the end I had to

a) drop speed to 19200 baud
b) make sure that XON/XOFF flow control was disabled in minicom
c) start the download with the ‘download -’ command in minicom (note that extra dash, presumably a stdin redirection)
d) quit minicom
e) from the command line, feed it the new bios like this
sx -vv b4801_130.bin /dev/ttyUSB0

That worked:

Sending b4801_130.bin, 608 blocks: Give your local XMODEM receive command now.
Bytes Sent: 77824 BPS:1771

Transfer complete

Finally:

> flashupdate
Updating BIOS Flash ,,,,,,,,,,,,,,,,,,,,,,,,..,,,,.. Done.

Apparently, upgrading is also pretty easy with ‘cu’ on openbsd, but the ‘lsz’ tool referred there doesn’t seem to exist in GNU/Linux land.

This was way more complicated than it should have been. I’m inclined to think that this would be easier if the Soekris ran a free bios – someone would have managed to squeeze in something a little more sane than xmodem for file transfers. Perhaps something that actually works with standard tools like minicom or cu. In other words, there is room for improvement here. The LinuxBIOS project has been making a lot of headway of late with Geode support…

But at least the BIOS upgrade solved my ‘error 16′ problem.

This is a great alternative to de-soldering the original chip to add a socket. He still needs to do some more testing, but this sure looks promising!

In other news, the LinuxBIOS v2 mainline tree now has the m57sli-s4 code merged, so it builds and works properly without need for extra patches. I’ll update my build tutorial shortly.

The project is based off an inexpensive Xilinx Spartan FPGA development board ($150). The idea is to use it to build a flash emulator that can plug into a motherboard flash socket if there is one, or clip onto an existing flash chip if it is soldered onto the board. It would also allow the flashing of a soldered-on chip, even if the board has been ‘bricked’.

Initially, Bari is planning to support SPI flash devices – but hopefully LPC will be supported soon, too. Most current mainboards use LPC-based PLCC chips – even though SPI-based boards are starting to appear. Bari is looking for help – particularly on the PC software side; some sort of tool will need to be written to communicate with the FLASH-PLAICE board. Do get in touch if you can lend a hand!

This tutorial still works off Yinghai Lu’s big MCP55 patch, but a patch from Ed Swierk hit the list today which resolves the last issues for building the m57sli code (if you disable the USB debug code). I’ve tested it – it works fine – so I hope it will be merged into the tree later today or tomorrow. I’ll update the tutorial when that happens.

Remaining issues for the m57sli port are: ethernet MAC address changes between proprietary BIOS and LinuxBIOS (but that might get resolved soon), and no ACPI support yet.