Sunday, February 24, 2008

Dump Log Command

If your EyeFi card is malfunctioning and you contact support, they'll likely ask you to dump the card's log. You can do this from the tray icon in Windows.

The first step in dumping a log is issuing an 'o' command. The 'o' command is the EyeFi's own ioctl(). It is a multiplexed command that can do several things depending on the byte after the 'o'. 0x1 seems to fetch the card's MAC address, for instance. An "o 0x7" command is always issued right before the log is dumped. It always (as far as I have seen) returns 0x00010000. That happens to be the length of the log: ~64k. But, the RSPM file is only 16k in length. So, how do we dump a 64k log 16k at a time?

'm' is the log dump command. It looks like this:
struct dump_log {
char cmd; // 'm'
u32 offset;
};
The card's MIPS cpu runs in big-endian mode (MIPS is bi-endian), so that offset needs to be byte-swapped if you're running the control software on an x86 machine.

The result in RSPM is all ASCII, except for the first 8 bytes for offset 0; I thought these were garbage for a while, but when I started comparing the logs to those obtained from Windows I realized that my logs were shifted around. The end of my logs didn't contain the latest entry; it was somewhere in the middle. It turns out that those first 8 bytes are actually two 4-byte numbers giving two offsets into the log data. The log data returned from this command are actually a circular buffer and those 8 bytes specify its start and end. The log file actually begins and ends in the middle of the buffer. So, the data that comes back from the card after issuing 4 of those 'm' commands looks like this:
struct log_buf {
u32 log_end_offset;
u32 log_start_offset;
char data[16384*4-8];
};
There was one last thing. The logs I got back were a bit smaller than the Windows logs. That's because, coming back from the card, the data has UNIX-style carriage returns. But, the manager turns them into DOS-style before writing the file.

No comments: