Nano2G

From iPodLinux

This page sums up everything we know about the 2nd generation iPod nano. Most of it apply to the 3rd generation nano, 4th generation nano and 6th generation iPod (Classic) too.

Introduction

With the release of the 2G nano Apple stopped using PortalPlayer as their CPU manufacturer, and is most probably using a Samsung chip instead. Which chip that would be is unknown as of now.

However the UI is pretty much identical to the first generation Nano. Even the hard reset and Disk Mode key combinations work the same way. Even Disk Mode looks identical to the first generation nano. PortalPlayer/Nvidia is no longer part of the "Legal" texts. Although, neither is Samsung.

Hardware

Component	Details
CPU	An Apple-branded ARM processor marked 337S3291 8701. It is probably a Samsung S5L8701B05, because the markings share an S for Samsung, and 8701 for the part number.
Codec	Another Apple rebranded chip marked APPLE 33850310, probably a Wolfson. Same size and position as previous Wolfson chip. (Wolfson WM8750S? - unknown source)
Utility Flash ROM	SST SST39WF800A,stores Disk Mode, Diagnostic Mode and the code to flash this chip. The data of this chip is decrypted too. See Encryption.
NAND Flash	Depends on the iPod. Common ones are the Samsung K9MBG08U5M and the Hynix HY27UW08BGFM.
PM	National's LM34910 switching power supply and Linear's LTC4066 for charging the battery off USB power.

Links to useful documents: Linux4Nano documents, and Arstechnica 2G Nano Dissection.

Firmware image changes

For a guide to how previous generation iPod firmware is laid out, please read the Firmware page.

Overview

The firmware volume header is unchanged and the firmware directory has the same structures, but one value have changed.

The "ATA!" device id is no longer used. It's changed to "NAND".

A basic dump of the Firmware volume header and directory follows:

Magic           : ]ih[
Directory offset: 0x4000
Extended header : 0x10c
Firmware version: 3

Image #0
  Dev       : DNAN
  Type      : soso
  ID        : 0
  devOffset : 0x5000
  Length    : 6270976
  Load addr : 0x8000000
  Entrypoint: 0x0
  Checksum  : 0x24208612
  Version   : 65536
  flashAddr : 0xffffffff
Image #1
  Dev       : DNAN
  Type      : crsr
  ID        : 0
  devOffset : 0x600800
  Length    : 16779264
  Load addr : 0x0
  Entrypoint: 0x600
  Checksum  : 0x7aac9bd0
  Version   : 0
  flashAddr : 0xffffffff
Image #2
  Dev       : DNAN
  Type      : dpua
  ID        : 1
  devOffset : 0x1601800
  Length    : 1101824
  Load addr : 0x8000000
  Entrypoint: 0x0
  Checksum  : 0xc22ef62
  Version   : 65536
  flashAddr : 0x8000000

Hibernation

The previous generation of iPod Nanos and 5th Generation iPods, if left untouched for more than 14 hours, would fall into a hibernation sleep. The current ram contents would be stored in a 4th file (hibe.fw) on the iPod's hidden firmware partition which would (presumably) restore the stack upon awakening. The 2G nano does not have the hibernating capability. Although the Apple support site says that "5th Generation iPod Videos and nanos" support hibernation, from my observations this does not include the 2G nano.

Encryption

In previous generations of iPods, the osos and rsrc images were unencrypted, while the aupd image was encrypted. However, this seems to have changed. The osos image appears to be encrypted, as is the aupd image. The rsrc image is still unencrypted though.

This means that it is currently not possible to run custom code on this generation.

To run code on these new generations of iPods, we have to decrypt the original firmware. Then we can disassemble it and write drivers for the entirely different hardware. To be able to run our custom code, we need to encrypt it again. Since we neither know the algorithm and the keys used to de/encrypt the firmware, we have to figure this out before development can start.

However figuring this out is not trivial.

Lots of suggestions were made by our userbase. However none of them are feasible, as they are impossible in general or take millions of years to accomplish (brute force).

The only possible way is getting the code that decrypts the firmware. The hope was, that this code is stored in the flash ROM. On May 12 2008 'tof' was able to dump the contents of the SST39WF800A chip (Read the entire story here).

We had a first look at the dump. Instructions at address 0x0 jump to address 0x8000, but the instructions at that location don't make any sense.

ROM:00008000                 STRMI   R7, [R9],#0x3DD
ROM:00008004                 ANDLS   R6, PC, R3,LSL#8
ROM:00008008                 BLLE    0xFFFFFFFFFE3BE444
ROM:0000800C                 STCMI   p5, c0, [R7],#0x3A0!
ROM:00008010                 LDRVCHT R7, [R9],#-0x68
ROM:00008014                 LDMLTIB R11!, {R1,R5-R9,R11-PC}
ROM:00008018                 SBCNE   R10, R4, #0xED00000
ROM:0000801C                 STMCSIB R3!, {R0,R1,R6,R7,R9,SP,PC}
ROM:00008020                 STRVCB  R7, [PC],#0xAD1
ROM:00008024                 STRLTT  R5, [SP],#-0x4D8
ROM:00008028                 STCPLL  p5, c0, [R10],#0x3C0
ROM:0000802C                 TST     R3, R12,ROR#6
ROM:00008030                 RSBLTS  R1, R8, #0xD9000000
ROM:00008034                 SWIEQ   0x2E0C30
ROM:00008038                 EOR     R0, R7, R10,LSL R12

How do we know these instructions are invalid?

Lots of conditional code without any code actually checking for a condition.
Jumps to invalid addresses.

So we think that this code is decrypted by the CPU at boot time, since it has about 50kB embedded boot ROM.

Layout of the flash dump

0x00000	Jump to 0x8000
...
0x40000	Unknown data
...
0x80000	Encrypted data
...
0x55B80	512 byte header
0x55D80	Encrypted data Name: logo Length: 0x2600
0x58380	512 byte header
0x58580	Encrypted data Length: 0x23C40
0x7C1C0	512 byte header
0x7C3C0	Encrypted data Length: 0x4E8C0 Length taken from header, spans over next two images...
0xB3440	512 byte header
0xB3640	Encrypted data Name: flshlogo Length: 0x2600
0xB5C40	512 byte header
0xB5E40	Encrypted data Name: flshdiag Length: 0x14E40
0xCAC80	512 byte header
0xCAE80	Encrypted data Name: flshdisk Length: 0x34F80
0xFFE00	Table of images flshdisk, flshdiag, flshlogo, logo

Headers

/* TODO */

Related Projects

Linux4nano - This project tries to collect as much information as possible about the 2nd generation iPod Nano, to be able run custom code on this device.

Personal tools

Views