Audrey hacking

Also see the Audrey Hacking web site!

These are my experiences messing around with my 3Com Ergo Audrey, which I bought new from someone on eBay on July 23, 2001.

Quick links

Audrey dead Audrey lives again!

Well, looks like my Audrey just paid the ultimate price. I created a QNX 6.1 kernel, about 470KB in size, and flashed it to the device. Now it won't start, and, more important, I can't seem to flash it back again to a good state. If anyone from 3Com or QNX is reading, I'd appreciate it if you'd write to me (see e-mail address below) and tell me what I did.

I figured that what I did would be safe because I was flashing the QNX kernel (0x00000000 - 0x007FFFFF in flash ROM), and even if I screwed up, the IPL (0x00FC0000 - 0x00FFFFFF) would be untouched, and I would be able to flash it back again. What did I do wrong? Did the IPL flash over itself? Is the IPL somehow dependent on the QNX kernel?

Update: Thanks to a hidden but generous soul, my Audrey is back in business and happily giggling again! A replacement motherboard arrived by express courier a few days ago. Thank you!  

New stuff

Wanted!
Your help answering these questions:

  • How does mkifs compute the checksums that
    it builds into the IFS image?
  • Is there any way to get a flash image off an Audrey?  
  • Is there any open source for QNX drivers out there?
  • What's the cheapest place to get a development
    Geode board?
  • Will UBid ever run out of Audreys?
  • Is anyone out there willing to tell me campfire stories
    about the making of the Audrey? (I'll keep names
    anonymous but would really like to make a web page
    that preserves the history of the development effort.)

Questions that have been answered:

Getting the Audrey filesystem off a brand-new Audrey

In theory, these steps should work. I'm still ironing out the details.

Update: I tried this and destroyed my Audrey. I don't think you should try it.

  1. Get the QNX RTP. All the rest of these instructions assume you're familiar with QNX.
  2. Make a basic filesystem image (an IFS) using mkifs. Its size must be less than 512KB (524,288 bytes). It must be for a Geode platform with no BIOS. I recommend putting tar and ftp on the image, as well as all the other basic stuff you'll need to boot.
  3. Generate an Audrey image using the source code I wrote below, and in the dword right before the checksum, put the length of the IFS (very important! The idea here is to flash just the bottom part of the Audrey image). The Audrey image should end up being 32,047,104 bytes.
  4. Put the image on a CF card, cross your fingers, and get ready to call 3Com tech support and tell them your Audrey is broken.
  5. Flash the Audrey.
  6. When the Audrey restarts, you should now be in a plain old QNX command prompt. Next you want to figure out how to get the top 15.5MB of the flash memory into a tar archive, which you'll ftp to a PC, and then poke and prod it!

Flashing the Audrey!

This is how I did it:

  1. Copy the image (32,047,104 bytes) to my Red Hat Linux laptop.
  2. Go to Fry's Electronics and get a Hitachi 32MB CF card and a PC Card adapter. Note: the capacity of the CF card must match the size of the image! I got lucky because mine did!
  3. Put the card/adapter in my laptop.
  4. dd audrey.img > /dev/hde
  5. Verify that it says it copied 62592 records (512 * 62592 = size of image = OK).
  6. Unplug my Audrey (which at this point reported 9/26/2000, 1.00.17.01 RC8), insert CF card, hold down power/datebook buttons, and plug back in.
  7. See "Loading from Compact Flash" with "XLv01.12" in the upper-right corner.
  8. See these:
    Erasing Flash
    Writing to Flash
    Erasing Flash (takes a long time)
    Writing to Flash (takes a long time)
    Erasing Flash
    Writing to Flash
    >>>>>> REMOVE COMPACTFLASH CARD <<<<<<
    >>>>>> REMOVE POWER CABLE <<<<<<
  9. At this point, when the Audrey restarts, it acts like it came right out of the box -- asks for my name, address, credit card number, etc.
If I put in a garbage CF card (one that held the Audrey image but was then formatted by Windows), then the results change:

Auto-updating

My Audrey updated itself! Last night it was 12/7/2000, and this morning (Sunday) it was 1/16/2001. I left the terminal program on, and sure enough, at some time in the night it rebooted itself, presumably after updating its software. So, next question: does the Marimba update system (which seems to be working after all) disallow skipping updates for older machines? In other words, if I have an A machine and the latest update is D, can I jump straight to D or must I first update to B and C?

Update: This is getting to be like Christmas morning every morning! This morning (Monday) my Audrey says it's version 1.02.04.01 RC24, 2/5/2001. So it looks like the answer to my ABCD question is that it has to take each incremental step. Kind of like EverQuest -- what level is your Audrey? I can't wait until they fix the Hotsync bug (I can't sync my Palm with 700 contacts).

This is a dump of 3com.marimba.net's directory structure, pared down to just the interesting stuff, with some "RC" information as reported by people on the web:

 
1.00.10.5
1.00.11.99
1.00.12.1
1.00.12.5
1.00.12.5.d
1.00.12.5.t99
1.00.13.1
1.00.14.0
1.00.16.0
1.00.16.03.d
1.00.16.3
1.00.16.3.d
1.00.16.4
1.00.16.4.d
1.00.16.5
1.00.16.5.d
1.00.17.1      RC8  09/26/2000
1.00.17.1.d
1.00.18.02    ---   01/16/2001
    1.00.18.02 - CONFIG (1 KB)
    1.00.18.02 - KOJAK (1 KB)
1.00.19.01
    1.00.19.01 - KOJAK (56 KB)
    1.00.19.01 - NTO (22 KB)
    1.00.19.02 - CONFIG (1 KB)
1.00.19.02    ---   02/26/2001
    1.00.19.02 - Config (420 KB)
    1.00.19.02 - Config (1 KB)
    1.00.19.02 - Nto (22 KB)
1.01.14.0
1.01.15.0
1.01.16.0
1.01.23.0      RC15 12/07/2000
1.01.23.01, 01/18/2001
    1.01.23.01 - CONFIG (1 KB)
    1.01.23.01 - KOJAK (56 KB)
    1.01.23.01 - NTO (22 KB)
1.01.25.0
1.02.04.0
1.02.04.01     RC24 02/05/2001
    1.02.04.01 - BIOS (257 KB)
    1.02.04.01 - BOOTIMAGE (513 KB)
    1.02.04.01 - Channels (116 KB)
    1.02.04.01 - ChannelSelector (5 KB)
    1.02.04.01 - CONFIG (8 KB)
    1.02.04.01 - ETC (2 KB)
    1.02.04.01 - KOJAK (4890 KB)
    1.02.04.01 - NTO (3845 KB)
    1.02.04.01 - USR (1796 KB)
1.02.08.00  RC26 03/29/2001
    1.02.08.00 - BIOS (257 KB)
    1.02.08.00 - BOOTIMAGE (513 KB)
    1.02.08.00 - CONFIG (8 KB)
    1.02.08.00 - ETC (2 KB)
    1.02.08.00 - KOJAK (4814 KB)
    1.02.08.00 - NTO (3922 KB)
    1.02.08.00 - USR (1796 KB)
1.02.08.01    FINAL 04/23/2001
    config - 1.2.8.1 FINAL (3 KB)

My personal updating story went 1.00.17.1 -> 1.00.18.02 -> 1.02.04.01 -> 1.02.08.00 -> 1.02.08.01.

Tip: If I press cancel when the Audrey starts up and looks for the date/time, and then enter 3:00 a.m. Pacific time, then some time in the next 90 minutes or so, the Audrey does a system software update. I can then shut it off, repeat the process (but this time entering tomorrow's date so it thinks it's been a day since its last update), then it continues to update. I can repeat this cycle and get a complete Audrey update to the final version in about a day's time. This is important because I have heard that 3Com/Marimba is shutting off the auto-updating functionality on August 6, 2001.

People who worked on the project (can't tell whether they work for QNX or for 3Com or someone else)

Note: I think the people with /cvs in the paths are QNX employees. JBoucher comes up in a Google search in a QNX file called nto.pdf. Also, the two people who don't have /cvs in their paths do have either "audrey" or "kojak" in their paths, and since those are both 3Com terms, it makes sense that they are 3Com people and the others are QNX people.

How to compute the image checksum

Add up the dwords (unsigned 32-bit integers) in the part of the image you want to flash (e.g., all 16 megabytes,possibly less). The result should equal the value stored in little-endian format at (CF card size - 512 + 12) in the image (right after 'KOJA' stored in little-endian format). Here is my complete archive of working source for this project. Not a lot of it makes sense right now, but it does contain a program that will do the computation for you.

Connecting the serial cable

This is what I saw once I plugged in my custom CF image (no buttons pressed at startup): 

3Com IPL
Loading from CompactFlash
Config : 0000848A
Sector sz: 00000200
Capacity : 0000F480
Not compressed
File size: 01000000
max_sectors: 00008000
Sum (calculated): 79C9BCD1
Sum (stored): 79C9BCD1
Uncompressed len: 01000000
Scanning for Image at FF000000
Image at: FF000414
Image setup
Starting image
####

And then when I flashed the CF image to the SanDisk (by pressing both power and datebook buttons), this is what I saw (it's long so I put it on a separate page).

Here are some screenshots of the custom image I made.

The only change was turning "RC" in the version string to "MT" -- nothing too earth-shattering, but it proves that it's now possible to create custom images for the Audrey.

Trying to make my own Marimba server

Go to http://3com.marimba.net/ and see what is there. To make a long story short, I have created a flash image that points to a web server on my LAN instead of that site, and so far my Audrey hasn't tried to talk to it. There must be something else I'm missing -- does the Audrey try to update itself only at night, for example? And does anyone know how Marimba is supposed to work so we can get stuff off the marimba.net site?

Update: Aha! I read some documentation on 3Com's site and learned that code updates happen only once, during the "first download of the day." So I unplugged the device, plugged it back in (keep in mind it's now 3:00 a.m. so that seems like the first of the day), and I see this in my Apache log:

192.168.0.6 - - [29/Jul/2001:03:02:04 -0700] "POST /aaaamarimbanetplugin HTTP/1.0" 404 282
192.168.0.6 - - [29/Jul/2001:03:02:04 -0700] "POST /aaaamarimbanetplugin?plugin HTTP/1.0" 404 282

Excellent! This is indeed what I'd hard-coded into one of the URLs. I presume that the post information is what kind of device this is, so the server knows what kind of update to send back to it. 

Image embedded in image

At 0x0000b518 in the CF image, there is a gzip signature: 0x1f 0x8b. Decompressing what is there gets you a file of size 1,025,152 bytes, which starts with the string "imagefs" and seems to be a RAM disk image of QNX. I poked around and didn't see anything particularly interesting. I'm pretty sure it's just QNX kernel binaries.

The compressed image on the CF image runs from 0x0000b518 to 0x007b3eb (0x6fed4 or 458,452 bytes long).

Update: it turns out that the compressed image is actually part of a single QNX entity that starts at offset zero in the image. I downloaded the QNX RTP CD-ROM (astonishingly cool user-interface and installation procedure, by the way!), and when I typed in dumpifs ergo.img, this is what came out: 

   Offset     Size  Name
	0      414  *.boot
      414      100  Startup-header flags1=0x5 flags2=0 paddr_bias=0
      514     b004  startup.*
     b518       5c  Image-header mountpoint=/
     b574      594  Image-directory
     ----     ----  Root-dirent
     ----       15  nto/bin/devf-ram -> /proc/boot/devf-kojak
     ----       14  usr/lib/ldqnx.so.1 -> /proc/boot/libc.so.1
     bb08       52  proc/boot/net_up
     c000    31edc  proc/boot/procnto
    3e000    4c000  proc/boot/libc.so.1
     ----        9  proc/boot/libc.so -> libc.so.1
    8a000     b000  proc/boot/devn-daisy.so
    95000    13638  proc/boot/npm-ttcpip.so
    a9000     e000  proc/boot/libsocket.so.1
     ----        e  proc/boot/libsocket.so -> libsocket.so.1
    b7000    1b4c1  proc/boot/devf-kojak
    d3000     6cc3  proc/boot/pci-bldt
    da000     19b8  proc/boot/setup_pci
    dc000     3f2c  proc/boot/flash
    e0000     2c11  proc/boot/on
    e3000     1aa0  proc/boot/cat
    e5000     29f0  proc/boot/slay
    e8000     66ed  proc/boot/devc-ser8250
    ef000     27c0  proc/boot/flashctl
    f2000     48ed  proc/boot/fesh
    f7000     15f0  proc/boot/enable
    f9000     1704  proc/boot/unlock
    fb000     19c2  proc/boot/LG
    fd000     257f  proc/boot/ln
   100000     2363  proc/boot/rm
   102363     3630  proc/boot/.script
Checksums: image=0xda18d95 startup=0x7216d3db

Audrey filesystem start?

At 0x00080000 (a half-meg into the image) there is what looks like the start of a filesystem. There's a string "QSSL_F3S" a little ways into it. In its web pages, QNX (the company) refers to itself as "QSSL."

Analysis of the files in the QNX image

Most of this is obvious to any QNX developer looking at the file list above, but I had to figure it out on my own. The driver for the 3Com USB Ethernet adapter is "daisy," or filename devn-daisy.so. I don't see any OHCP or UHCP drivers for USB in the file list, so maybe the Daisy driver knows USB? Generally, there isn't a whole heck of a lot in the QNX system here!

Kojak filesystem (devf-kojak) binary: "aclrvxb:f:i:m:p:s:t:u:w:" is probably the list of options passed to getopts. I am able to execute the filesystem on my QNX development system, but I haven't gotten it to do anything interesting yet.

There's a string "/home/hbryson/iad/src/nto/flash/io-flash/f3s_open.c" in devf-kojak, as well as an actual "QSSL_F3S" tag. That maps nicely to the QSSL_F3S tag that's at the beginning of the Kojak filesystem image.

Here's the script used to bring up the network:

slay dhcp.client io-net
io-net -ddaisy -pttcpip -p pppmgr &
sleep 4
dhcp.client &

This is a mangled string from the startup script that is used to start the filesystem:

devf-kojak -r -t1 -w4096 -m/ ??2/dev/fs0p1

Update: The startup command is devf-kojak -r -t1 -w4096 -m/ and the other part means "wait for /dev/fs0p1 to appear before continuing." It's a binary script so the question marks don't mean anything to a human.

Analysis of the files in the Kojak image

Many of the files are encoded in a custom LZO-based format. LZO is a compression algorithm whose claim to fame is decompression speed and low usage of computing resources. It doesn't compress very well, which explains why there are still lots of visible strings in the Kojak image (it also explains why there's occasional corruption of those strings -- that's the compression at work!). The files that start with F3S_FLZO are compressed with this algorithm.

Update: This is just plain old QNX flashlzo format.

Geode chipset research

Linux on the Audrey?

Yes, it's quite possible. But there are some caveats. The IPL (Image Program Loader), which lives in the top 64K of linear memory (0xff000000), will load an appropriately-formatted CF image into memory, update the flash memory, and upon a normal rebooting, execute code at the beginning of the flash memory. However, the IPL expects a proper QNX IFS at the bottom of the CF image, and the IFS must be less than 512KB, because the Audrey filesystem starts at 0x00080000 in the image (I have seen hints that the flash memory is loaded at 0x40000000 in memory, so the Audrey filesystem is probably memory-mapped to 0x40080000). So that leaves us with three options:

  1. Stick with QNX -- not a bad idea because it's a really cool OS! I like microkernels!
  2. Trick the IPL into thinking that LILO at the bottom of the image is really a QNX IPL. Although that's not a bad idea, it means that we can't just drop Jailbait, Midori, or any other standard Linux distribution onto the Audrey. There will always be an IPL/QNX bias in the Audrey.
  3. Do a two-step upgrade process: first, flash the Audrey with a CF image that has a lobotomized IPL and a standard Audrey distribution in the bottom of the image (which will be loaded by the standard IPL), and then flash the lobotomized Audrey with plain old Jailbait. Personally, I prefer this option because it's a hassle just once, and then it'll be easier to hack, hack, hack after that. But modifying the IPL will be pretty scary, because if I get it wrong, goodbye Audrey.

Only after figuring this out will I be able to find out exactly how close this particular Geode platform is to a plain old AT PC.

Using the Audrey

Just for fun

Pulled out the "go to sleep" sound. Plays OK (though quietly) on a Windows machine.

This page is maintained by Sowbug <mike @ this domain>