Nano4G firmware upgrade process

Protocol description

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)

Sending commands

To send these commands on linux you need the scsirastools (http://scsirastools.sourceforge.net/). On Debian you have to build it youself using configure, make, make install.

Once you built it run as root: sgdiag -I You will get a prompt. First type c to send a custom command, then the number of the device (the list is just above). The CDB length is 10, then the bytes are c6 ... (eg c6 97 00 01 00 00 00 00 00 00 for the first one). Response data length is 4 byte for the first command, 0 for the ones with no data stage or for uploading firmware or log sending, 4096 for log reading). The Output data length is the size of data sent to the ipod (excluding the command). That's it. If the device is an ipod you should get a response, if it isn't you will get an error message.

Commands summary

0xc6 is the first byte, then:

• 0x90 <type> <4-byte size> [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00] -> init update process (type 0 = firmware, 1 = bootloader)
• 0x91 0x00 0x10 [0x00 0x00 0x00 0x00 0x00 0x00] + data -> upload data
• 0x92 [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00] -> end update process
• 0x94 <be32:fwpartsize_in_kb> [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00] -> repatition hdd/flash - only useful when restoring or if the firmware partition was altered. is not used an update (preserving user data/settings) is performed

The bytes in brackets are optional.

TheSeven: from what it looks like the 96 and 31 commands don't even have a handler on the ipod side

Automated image uploading

There's an app that implements this protocol. Its source code is available at our SVN. Use MinGW to compile it (or get the binary here), only Windows version available at the moment. It's written with Classic 1G, Classic 2G, and Classic 3G in mind, but also works with Nano 3G and Nano 4G. More details to come soon on a separate page. We'll be happy if someone could test if it works on Nano 5G and Nano 6G and post the results on the Discussion page.