the whole firmware update is done through a custom 0xc6 scsi command
first, the update is initiated by a c6 96 00 00 00 00 00 00 00 00 packet, that will get a 4-byte response (meaning unknown)
maybe the count of update log entries?
then the last update log page (4KB) is read using a c6 97 00 01 00 00 00 00 00 00 packet
then a new log page (4KB) is written using a c6 98 00 01 00 00 00 00 00 00 packet
then there is a c6 94 00 02 80 00 00 00 00 00 00 00 00 00 00 00 packet, no idea what it's good for, no data stage
the next stage is uploading the "N58s.bootloader.release.rb3" file, using a c6 90 <type> <size> 00 00 00 00 00 00 00 00 00 packet
<type> is 00 for the MSE, and 01 for the RB3 file, size is the big endian 32bit file size
the transfer itself is done using c6 91 00 10 00 00 00 00 00 00 packets, each (besides the last one, which is trimmed to the
number of bytes left to be transferred) followed by 5 data stages, being 16384, 3584, 16384, 16384 and 12800 bytes in size
I can't think of any reason for this weirds splitting, maybe it isn't even neccessary and just an itunes weirdness
then the transfer is closed using a c6 92 00 00 00 00 00 00 00 00 00 00 00 00 00 00 packet
the next step is uploadinf "Firmware.MSE" the same way
finally a c6 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 is sent (no data stage), and another log entry is written
that's the whole deal.
-- TheSeven 22:21, 30 November 2009 (UTC)
