I finally got around to looking at the traces I captured a while ago from
the firmware uploader. The traces were awful so I captured some new ones.
If anyone's interested in the logs I can supply (they are huge).
How the firmware uploader works
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Karma operates pretty much the same in Recovery Mode as it does in
regular operation. The same commands are recognized: RIOP [00] [cmd] [seq],
and the "enter storage mode" command is utilized to do the upgrade. My traces
show that, unlike the normal operation mode, the Karma doesn't ack by echoing
the sequence number back to the host. Instead, it appears the uploader just
sends the URB for a given command, reads back the "f0 00 00 ...", then sends
again with 0x80 as byte 4 to read back the response. This would indicate
that a minor change to the usb-storage driver would facilitate using the
Karma even in recovery mode (see hacky 2-liner at end that proves it).
There's no magic switch to make the Karma format itself. The firmware
uploader just accesses the disk like normal to format the disk if you
request it. Likewise, the firmware image itself is just copied to the
appropriate location on disk. Thus, if someone really screws their Karma,
they should be able to take a backup created with dd, patch the kernel
driver with the below patch, then simply restore the image via dd.
I do not know what triggers the reload of the firmware into flash. Perhaps
just disconnecting the endpoint while it's in recovery mode is enough. I
could not figure out how to force it trying various incantations with the
sysfs binding files. My traces don't show any special commands after the
upload.
The firmware image itself appears to be encrypted on disk and in the transfer.
I can see the exact bytes that later show up in the 'zero partition' as part
of the log, so the host sends it in the same format that the Karma uses.
Interestingly, I cannot find the firmware in the resource table of the
executable, but I am sure it is there. I therefore wonder if it is
compressed or encoded with an XOR scheme or something like that. I doubt
they'd encrypt it a second time, but who knows.
So what all this means is: with a suitable backup and the below patch, you
can recover from errors that cause the Karma to continuously reboot without
going back to Windows. However, without that backup in the first place,
you're still in trouble.
PATCH: use one-shot messaging for Karma.
Index: linux-2.6.20-rc5/drivers/usb/storage/karma.c
===================================================================
--- linux-2.6.20-rc5.orig/drivers/usb/storage/karma.c 2007-01-26
09:25:26.000000000 -0500
+++ linux-2.6.20-rc5/drivers/usb/storage/karma.c 2007-01-26
09:26:29.000000000 -0500
@@ -93,11 +93,9 @@
if (seq == 0)
seq = 1;
+err:
US_DEBUGP("karma: sent command %04x\n", cmd);
return 0;
-err:
- US_DEBUGP("karma: command %04x failed\n", cmd);
- return USB_STOR_TRANSPORT_FAILED;
}
/*
--
Bob Copeland %% www.bobcopeland.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-karma-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
