GPIO on a Gumstix Console VX

Every embedded-style project begins by blinking LEDs. Once the LEDs blink, anything is possible.

My platform is the Gumstix starter pro pack, which includes a “verdex XM4” main board, and the “console vx” expansion board. I was initially thinking I would hijack one of the serial ports, so I started looking at the docs for the Gumstix UARTS. However, I’m trying to do this with as little change to the default software environment as possible, and the default environment does not include a terminal program (e.g., minicom). Likewise, some tests of the serial ports using “echo” and “cat” did not impress.

Thus, I changed my focus to the general purpose I/O (GPIO) through-holes on the console vx. I found this discussion where people are trying to achieve something similar with the console LCD expansion board, which is actually quite similar to my console vx. The critical information, though, was that there is such a directory as /proc/gpio, and that echo and cat are sufficient to interact with the files contained therein. I followed the advice in that discussion and started with the AC97 header. These schematics were helpful in learning what went where, as was Table 4.1 in the Table 4.1 in the PXA255 Processor Developer’s Manual.

Looking at the bottom of the console vx board, the AC97 header has two rows of 4 pins, and the top-right one has a square solder pad (as opposed to the others, which are round). I deduced that the square hole was ground. Here is an ASCII diagram of which GPIO pins go to which through-holes:

?,30,29,GND
31,?,?,28

Thus, to set and clear one of pins 28-31, one would enter the following at the command prompt:
$ echo “GPIO out set” > /proc/gpio/GPIO28
$ echo clear > /proc/gpio/GPIO28

The string “GPIO out” tells the system to put this pin into the “GPIO mode”. Most of the pins also have alternate functions, so this is necessary. During a boot cycle, the pins seem to “remember” that they are in GPIO mode and set to ‘out’, so those can be omitted after the first invocation.

Advertisements

Firmware updates for AMD CPUs

AMD has recently decided to add support for updating the firmware on its processors on amd64.org. The Linux instructions simply say that the “Microcode update for AMD processors uses the firmware loading infrastructure.” I wasn’t familiar with the firmware loading infrastructure, and it took some serious detective work to figure things out.

I did `aptitude install firmware-tools`

I then noticed (since firmware-tools does not appear to have any meaningful documentation) that /etc/firmware now exists. I then found
this message suggesting that the firmware should live in /etc/firmware, and this message suggesting a directory structure of amd-ucode/microcode_amd.bin. Well, that didn’t work. I received errors to the tune of:


microcode: CPU0: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
microcode: CPU1: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
microcode: CPU2: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
microcode: CPU3: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
Microcode Update Driver: v2.00 , Peter Oruba

I then ran a simple ‘locate firmware’ command and saw many instances in /lib/firmware. I moved amd-ucode/microcode_amd.bin into that directory, and received more meaningful feedback in `dmesg` (following rmmod microcode; modprobe microcode`):


microcode: CPU0: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU0: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU0: updated (new patch_level=0x1000083)
microcode: CPU1: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU1: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU1: updated (new patch_level=0x1000083)
microcode: CPU2: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU2: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU2: updated (new patch_level=0x1000083)
microcode: CPU3: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU3: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU3: updated (new patch_level=0x1000083)
Microcode Update Driver: v2.00 , Peter Oruba

It still doesn’t look perfect (i.e., it thinks the particular .bin file is not right for my CPU), but at least now I think I’m using the “firmware loading interface” successfully.

Many links to http://www.urbanmyth.org/microcode/ were also provided, but that site seems to be Intel-only.

UPDATE 2009/05/05:

It was working just fine. The microcode_amd.bin file contains more than one microcode patch, and it’s just an “eccentricity” of the microcode.ko module that it prints a warning about the mismatch.

Subtle bugs in Thunderbird

In this post I will bash Thunderbird. However, it is my mail client of choice, so even though it is somewhat crappy it is better than everything else.

On OS X: sometimes attachments don’t work correctly. My best An attempt at an explanation is that, when viewing multiple emails with attachments in succession, and trying to open each attachment (e.g., PDFs from a network scanner) by double-clicking on the attached file, sometimes the attachment of the previously viewed email opens instead.

In Linux and on OS X: Auto-checking for new mail in IMAP folders (e.g., I have sieve script that auto-sorts certain emails) sometimes doesn’t work. When it fails, I have to click on the folder before Thunderbird will realize that it contains new messages. Today it actually crashed, and then when I restarted Thunderbird the two folders that get the most mail were re-downloaded in their entirety. This is the first time Thunderbird has actually crashed in a way that I thought might be related to this issue (which is good -> crashes are easier to debug than subtle logic problems).

Anyways, just venting. It would be schweeeet if these bugs got tracked down and fixed. If I had a time machine, I would attempt to do it myself.