freemyipod - User contributions [en]

RetailOS

2024-05-09T19:44:04Z

LemonJesus: add a RTXC 3.2 training manual I found on archive.org

The stock operating system running on non-iOS iPods. It runs everything from device drivers to the clickwheel user interface.

== Naming ==

The only 'official' name seems to be 'retailOS', found in the [[Nano 3G]] WTF. It is also referred to as 'osos' per the file name in the resource partition of the firmware bundle.

== Architecture ==

retailOS is a small, embedded, single-user, single-binary, real time operating system. With time it acquire more and more complex functionality, like PowerVR drivers and being able to load external applications ('eApps') which are used for games.

The core of the system is based on RTXC 3.2, with the end-user interface based on intellectual property from a company called Pixo. <ref>https://web.archive.org/web/20230224105131/https://twitter.com/johnwhitley/status/1451952369248264201</ref>

== Security ==

As evidenced by the success of the [[Notes vulnerability]], at least up to Nano 4G there was no kind of security hardening, and in fact all processes, including games, seem to be running in ARM system mode. This should make exploitation of newer retailOS bugs trivial.

=== Boot chain ===

retailOS is loaded by the second-stage bootloader (stored on NOR/NAND depending on the device generation), from NAND into DRAM.

While other stages of the boot chain (eg. the bootloader, WTF mode in newer devices, the diagnostics tool) are based around EFI firmware volumes and an EFI runtime, retailOS is a single binary blob without any built-in modularity.

=== eApp Signing ===

Not yet documented fully. Each game seems to ship with a Manifest.plist.p7p which is a PKCS#7 signature for the main Manifest.plist.

== Options ==

We have found some 'secret' options that can be set by creating specially named files. See [[RetailOS_Options|Options]].

== Analysis / Memory Layout ==

Loading RetailOS correctly into a decompiler/disassembler is tricky, as the contents of the IMG1 image are a binary blob which self-relocates to the correct places in memory.

These are the memory segments within RetailOS that we know of (at least on Nano 5G):

{| class="wikitable"
|-
! Name !! Marker !! Location in memory !! Description
|-
| sram.text || n/a || SRAM 0x22000000 || SRAM-resident code, most of RTXC lives here.
|-
| sram.bss || n/a || SRAM 0x22030000 || SRAM-resident zero data.
|-
| sram.data || n/a || SRAM 0x22030000 + sram_bss_size || SRAM-resident data.
|-
| dram.textdata || hibe || DRAM 0x08000000 || Combined .text and .data which lives in DRAM. Bulk of code lives here.
|-
| dram.frameworks || miscTBD || DRAM 0x08000000 + dram_textdata_size || 'Framework' system of some kind, interfaces used by eApps.
|-
| dram.bss || n/a || DRAM 0x08000000 + dram_textdata_size + dram_frameworks_size || DRAM-resident zero data.
|}

And here's how the segments are built up within the RetailOS binary blob:

{| class="wikitable"
|-
! Address !! Name !! Size
|-
| Start || sram.text || sram_text_size
|-
| || sram.bss || sram_bss_size
|-
| || sram.data || sram_data_size
|-
| || dram.text || dram_text_size
|-
| End || dram.frameworks || dram_frameworks_size
|}

(yes, the firmware blob ships a sram.bss physically in the file)

So the goal to be able to load the binary is to figure out the segment sizes and then load them into a decompiler/disassembler.

Here, we'll show how to figure out the segment sizes for N5G. First, load the RetailOS body (without the header!) at 0x22000000 in a decompiler. We load it there (intead of into DRAM as it is done on the device) as the stub relocates to this address first by performing the SRAM .text/.data copies very early in the process, and the code is position independent for only a short time.

Then, look at the start function (follow the reset vector):

<pre>
void start(void) { // 0x2200505c
offs = relocation_offset();
/* ... peeks/pokes to bus matrix periph at 0x3ff00000 ... */
if (offs != 0) {
relocate(offs);
}
(*0x22000000) = 0xea000007;
zero_bss();
}
</pre>

relocation_offset will return 0 if the stub is already at 0x22000000, so will return 0 for the way we've loaded it. On a real device, this will be 0x22000000 - 0x08000000 ==
0x1a000000, as the real device loads RetailOS into DRAM first. Thus, relocate() will be called:

<pre>
void relocate(int offs) { // 0x22005ec8
int iVar1 = -offs;
void *blob_start = iVar1 + 0x22000000;
memmove(0x22000000, blob_start, 0xe27c); // copy sram.text
memzero(0x22000000 + 0xe27c, 0xbc4); // zero out sram.bss within blob
memmove(0x22030000, 0x22000000 + 0xe27c + iVar1, 0x20000); // copy sram.bss + sram.data
jump_offset(offs);
memmove(0x08000000, 0x22000000 + 0xe27c + 0x20000 + iVar1, 0x6c3768); // copy dram.textdata
memmove(0x08000000 + 0x6c3768, iVar1 + 0x22000000 + 0xe27c + 0x20000 + 0x6c3768), 0xc40); // copy dram.frameworks
start();
return;
}
</pre>

The above listing shows reconstituted address calculations - in a plain decompilation, all the additions will of course be simplified to a single constant. But you should be able to figure out the following:

# sram_text_size is 0xe27c
# sram_bss_size is 0xbc4
# sram_bss_size + sram_data_size is 0x20000
# dram_textdata_size is 0x6c3768
# dram_frameworks_size is 0xc40

Then, in zero_bss we can find the size of dram.bss:

<pre>
void zero_bss(void) { // 0x22005fec
memzero(0x2200e27c, 0xbc4); // zero out sram.bss
// inlined memzero:
void *start = 0x08000000 + 0x6c3768 + 0xc40;
int size = 0x790a84;
// ...
}
</pre>

From which we can figure out that the dram.bss segment size is 0x790a84.

Thus we can load the file like so (combining sram.bss and sram.data) into a 'clean' decompiler/disassembler session:

{| class="wikitable"
|-
! Name !! Memory Address !! File Offset
|-
| sram.text || 0x22000000 || 0x00000000
|-
| sram.bssdata || 0x22030000 || 0x0000e27c
|-
| dram.textdata || 0x08000000 || 0x0002e27c (0xe27c + 0x20000)
|-
| dram.frameworks || 0x086c3768 || 0x006f19e4 (0xe27c + 0x20000 + 0x6c3768)
|-
| dram.bss || 0x086c43a || n/a (0x790a84 zeroes)
|}

Writing an automated converter into ELF from arbitrary RetailOS blobs is an exercise left to the reader.

== RTXC ==

=== Documentation ===

This seems to be the best public document available about RTXC 3.2: [https://web.archive.org/web/20230218212424/https://datasheet.datasheetarchive.com/originals/library/Datasheets-AS2/DSAAXSA0003458.pdf DSAAXSA0003458.pdf]. It contains example code for most services, but unfortunately is still missing any structure definitions.

There's also some training slides available: [https://ia801800.us.archive.org/26/items/manualzilla-id-5752851/5752851.pdf 5752851.pdf]. These introduce the general architecture and concept of RTXC 3.2.

=== Services / Syscalls ===

While RTXC documentation speaks mostly of 'kernel services' (which are defined as C function signatures/symbols), we like to talk about 'syscalls' and 'syscall numbers' when reverse engineering retailOS. All service functions go through a central dispatch function and that's the easiest point to start reverse engineering the kernel service interface.

The dispatcher receives a saved caller state which contains a pointer to a serialized syscall request in its saved R0. The syscall request is a trivial structure containing a syscall number and arguments. The dispatcher is executed with interrupts enabled (and thus is non-preemptable) and performs actual work on kernel structures. There is no privilege-granting 'gate' mechanism, all caller code is just as privileged as the kernel code.

Service functions in turn prepare the syscall request structure (including syscall number), and then call an intermediary state saving function which then calls the dispatcher after disabling interrupts. Some syscall numbers are used by multiple service functions, with some extra arguments in the request being used to decide on the behaviour of the service call (eg. blocking/nonblocking).

The following table comes from cross-referencing retailOS, publicly available RTXC PDFs and publicly availble RTXC binaries with debug symbols.

{| class="wikitable"
|-
! Name !! Number !! Description
|-
| <code>void KS_pend(SEMA sema)</code> || 0x03 || Semaphore DONE -> PENDING.
|-
| <code>RTXCMSG *KS_receive(MBOX mailbox, TASK task)</code> || 0x05 || Receive from mailbox.
|-
| <code>KSRC KS_enqueue[w](QUEUE queue, void *entry)</code> || 0x0c || Push into FIFO (and block if full with 'w' variant).
|-
| <code>void KS_dequeue[w](QUEUE queue, void *dest)</code> || 0x0d || Pop from FIFO (and block if empty with 'w' variant).
|-
| <code>KSRC KS_lock(RESOURCE resource)</code> || 0x0e || Lock a resource.
|-
| <code>KSRC KS_lockt(RESOURCE resource, TICKS timoeut)</code> || 0x0e || Lock a resource with timeout.
|-
| <code>KSRC KS_unlock(RESOURCE resource)</code> || 0x0f || Unlock an owned resource.
|-
| <code>CLKBLK *KS_alloc_timer(void)</code> || 0x10 || Allocate next free timer from pool.
|-
| <code>CLKBLK *KS_start_timer(CLKBLK *timer, TICKS initial_period, TICKS cycle_time, SEMA sema)</code> || 0x12 || Start timer.
|-
| <code>KSRC KS_stop_timer(CLKBLK *timer)</code> || 0x13 || Stop timer.
|-
| <code>void KS_delay(TASK task, TICKS period)</code> || 0x14 || Block specified task for a period of time.
|-
| <code>void KS_execute(TASK task)</code> || 0x15 || Start a task from its beginning address.
|-
| <code>KSRC KS_deftask(TASK task, PRIORITY priority, char *stack, size_t stacksize, void (*entry)(void))</code> || 0x16 || Define the attributes of an inactive task.
|-
| <code>TASK KS_alloc_task(void)</code> || 0x17 || Allocate the next available Task Control Block from the pool of free TCBs.
|-
| <code>void KS_terminate(TASK task)</code> || 0x18 || Stop a task by setting it to INACTIVE.
|-
| <code>void KS_suspend(TASK task)</code> || 0x19 || Suspend a task until resumed or re-executed.
|-
| <code>void KS_defpriority(TASK task, PRIORITY priority)</code> || 0x1b || Define or set priority of task.
|-
| <code>void KS_yield(void)</code> || 0x1c || Voluntary release of control to any other task of the same priority.
|-
| <code>SEMA KS_waitm(SEMA *semalist)</code> || 0x22 || Wait on multiple semaphores.
|-
| <code>time_t KS_inqtime(void)</code> || 0x24 || Get current time-of-day.
|-
| <code>void KS_deftime(time_t time)</code> || 0x25 || Set current time-of-day.
|-
| <code>TASK KS_inqres(RESOURCE resource)</code> || 0x26 || Get owner of resource.
|-
| <code>KSRC KS_defres(RESOURCE resource, RESATTR condition)</code> || 0x27 || Define priority inversion on resource.
|-
| <code>void *KS_inqtask_arg(TASK task)</code> || 0x28 || Get environment arguments of task.
|-
| <code>void KS_deftask_arg(TASK task, void *arg)</code> || 0x29 || Set environment arguments for task.
|-
| <code>KSRC KS_defqueue(QUEUE queue, size_t width, int depth, void *body, int currsize)</code> || 0x2e || Define queue.
|-
| <code>int KS_user(int (*func) (void *), void *arg)</code> || 0x30 || Execute function as if it were kernel service.
|}

The RTXC memory allocation facilities (<code>KS_alloc/free/create_part/alloc_part/defpart/free_part</code>) are ''not'' used by retailOS and not built into the service dispatcher, at least on [[Nano 5G]].

=== Semaphores ===

The following semaphores are defined in the [[Nano 3G]] retailOS:

{| class="wikitable"
|-
! Number !! Name !! Description
|-
| 0x01 || <code>S_FW_PWR_CHANGE</code> ||
|-
| 0x02 || <code>S_BAT_PWR_CHANGE</code> ||
|-
| 0x03 || <code>S_USB_PWR_CHANGE</code> ||
|-
| 0x04 || <code>S_CNA_CHANGE</code> ||
|-
| 0x05 || <code>S_WHEEL_CHANGE</code> ||
|-
| 0x06 || <code>S_DISKMGRQ</code> ||
|-
| 0x07 || <code>S_TOPPLUG_SWITCH</code> ||
|-
| 0x08 || <code>S_RTCTIMERMGR</code> ||
|-
| 0x09 || <code>S_ALARM_01</code> ||
|-
| 0x0a || <code>S_ALARM_02</code> ||
|-
| 0x0b || <code>S_ALARM_03</code> ||
|-
| 0x0c || <code>S_WATCHDOG</code> ||
|-
| 0x0d || <code>S_CPUMGRQ</code> ||
|-
| 0x0e || <code>S_PCFPOWERMGR</code> ||
|-
| 0x0f || <code>S_POWER_STATE_AC</code> ||
|-
| 0x10 || <code>S_CGR_STATE_TMR</code> ||
|-
| 0x11 || <code>S_DEEPSLEEP</code> ||
|-
| 0x12 || <code>S_ALARM_DONE</code> ||
|-
| 0x13 || <code>S_PIEZOMGR</code> ||
|-
| 0x14 || <code>S_PIEZOMGRSNDR</code> ||
|-
| 0x15 || <code>S_PIEZODONE</code> ||
|-
| 0x16 || <code>S_ACCPOWER</code> ||
|-
| 0x17 || <code>S_ACC_REINIT</code> ||
|-
| 0x18 || <code>S_TOPPLUGSENSER</code> ||
|-
| 0x19 || <code>S_TOPPLUGCHANGE</code> ||
|-
| 0x1a || <code>S_BTMCONNECT</code> ||
|-
| 0x1b || <code>S_BTMPLUGCHANGE</code> ||
|-
| 0x1c || <code>S_BTMREVERIFY</code> ||
|-
| 0x1d || <code>S_BTMREVERTIMED</code> ||
|-
| 0x1e || <code>S_BTMVERCOMP</code> ||
|-
| 0x1f || <code>S_TOPACCPKTRCVD</code> ||
|-
| 0x20 || <code>S_BTMACCPKTRCVD</code> ||
|-
| 0x21 || <code>S_SERIALIDRCVD</code> ||
|-
| 0x22 || <code>S_UARTATXEMPTY</code> ||
|-
| 0x23 || <code>S_UARTBTXEMPTY</code> ||
|-
| 0x24 || <code>S_HDDSCANCOMP</code> ||
|-
| 0x25 || <code>S_BL_ON</code> ||
|-
| 0x26 || <code>S_BL_OFF</code> ||
|-
| 0x27 || <code>S_BL_RAMPDOWN</code> ||
|-
| 0x28 || <code>S_BL_RAMPUP</code> ||
|-
| 0x29 || <code>S_BL_TIMESUP</code> ||
|-
| 0x2a || <code>S_BATT_TIMESUP</code> ||
|-
| 0x2b || <code>S_BATT_AC_PWR</code> ||
|-
| 0x2c || <code>S_BATT_TMR_RST</code> ||
|-
| 0x2d || <code>S_GRAPHMGR</code> ||
|-
| 0x2e || <code>S_VBL</code> ||
|-
| 0x2f || <code>S_DTVRECOVERY</code> ||
|-
| 0x30 || <code>S_CM_HEADPHONE</code> ||
|-
| 0x31 || <code>S_CM_EXTPOWER</code> ||
|-
| 0x32 || <code>S_CM_ACCATTACHED</code> ||
|-
| 0x33 || <code>S_CM_DAC_SETUP</code> ||
|-
| 0x34 || <code>S_ATAWRKLPRDY</code> ||
|-
| 0x35 || <code>S_RTXCBUG</code> ||
|-
| 0x36 || <code>S_BLOCKDEVICE</code> ||
|-
| 0x37 || <code>S_BLOCKDEVICEQ</code> ||
|-
| 0x38 || <code>S_DISPLAY</code> ||
|-
| 0x39 || <code>S_ARB_READY</code> ||
|-
| 0x3a || <code>S_I2C_DONE</code> ||
|-
| 0x3b || <code>S_VSYNC</code> ||
|}

There are three more semaphores (0x3c, 0x3d, 0x3e) that have no name defined and are likely unused. Anything 0x3f and up is a 'Dynamic' semaphore defined at runtime (which we haven't reversed yet).

=== Queues ===

The following queues are defined in the [[Nano 3G]] retailOS:

{| class="wikitable"
|-
! Number !! Name !! Description
|-
| 0x01 || PIXORESQ ||
|-
| 0x02 || PIXOSEMAQ ||
|-
| 0x03 || POSIXRESQ ||
|-
| 0x04 || POSIXSEMAQ ||
|}

=== Mailboxes ===

The following mailboxes are defined in the [[Nano 3G]] retailOS:

{| class="wikitable"
|-
! Number !! Name !! Description
|-
| 0x01 || M_DISKMGR ||
|-
| 0x02 || M_PIEZOMGR ||
|-
| 0x03 || M_GRAPHMGR ||
|-
| 0x04 || M_BLOCKDEVICE ||
|-
| 0x05 || M_DISPLAY ||
|}

=== Resources ===

The following lockable resources are defined in the [[Nano 3G]] retailOS:

{| class="wikitable"
|-
! Number !! Name !! Description
|-
| 0x01 || GPIO_REG_WRITE ||
|-
| 0x02 || GPIO_INT_INIT ||
|-
| 0x03 || RTC_TIME_ADJUST ||
|-
| 0x04 || RTC_ALARM_ADJUST ||
|-
| 0x05 || I2C_MASTER ||
|-
| 0x06 || USB_GRANT ||
|-
| 0x07 || USB_RESP_INIT ||
|-
| 0x08 || USB_RESPONDER ||
|-
| 0x09 || DISKPWRMGRSEND ||
|-
| 0x0a || PIEZOMGRSEND ||
|-
| 0x0b || SERIALVERIFIER ||
|-
| 0x0c || RESISTORVERIFIER ||
|-
| 0x0d || FW_IRAM ||
|-
| 0x0e || ACCPOWER ||
|-
| 0x0f || UARTA ||
|-
| 0x10 || UARGB ||
|-
| 0x11 || PMU_LOCK ||
|-
| 0x12 || ADC_LOCK ||
|-
| 0x13 || DTV_ENC_INIT ||
|-
| 0x14 || BACKLIGHT ||
|}

== External links ==

* [https://web.archive.org/web/19990220054659/http://www.rtxc.com/Products/RTXC/Services.htm RTXC Kernel Services (1999)]
* [https://archive.org/details/manualzilla-id-5752851 RTXC 3.2 Training Manual]

RetailOS

2024-05-09T19:31:34Z

LemonJesus: Un-dead the Twitter link talking about Pixo.

Disk Mode

2024-01-11T06:26:31Z

LemonJesus: created a Disk Mode page

Disk Mode is a binary that serves two purposes: first, it exposes a USB Mass Storage and SCSI device to provide access to the iPod's filesystem. Second, it facilitates the recovery functionality of the iPod. On the Nano 3G, it is stored on NOR Flash.

This page currently focuses on the Nano 3G's Disk Mode unless otherwise noted.

== Memory Layout ==
The memory layout of Disk Mode is far simpler than that of Retail OS. See [[RetailOS#Analysis_.2F_Memory_Layout|analysis of Retail OS's memory layout]] for more details about how this relocation process works. There are only two sections that get relocated:

{| class="wikitable"
|-
! Name !! Memory Address !! File Offset
|-
| sram.text || 0x22000000 || 0x00000000
|-
| dram.textdata || 0x08000000 || 0x000051f4
|}

== Known RTXC Tasks ==
There are several tasks in Disk Mode that RTXC manages. These are inferred by the presence of string names for these tasks:
* HostOSTask
* USBDeviceTask
* ATAWorkLoopTask
* ATAWorkLoopIRQTask
* CNATask

Nano 3G

2023-11-19T19:19:12Z

LemonJesus: porting over my hardware notes

[[Image:nano_3g_frt_a.png|500px]]
[[Image:nano_3g_bck_a.png|500px]]
==Components==
{| class="wikitable"
! Label !! Component !! Part !! Markings !! Notes
|-
| 2
| CPU
| Samsung S5L8702
| 337S3473 8702, NONBWOEC, 0731 ARM
| ARM926EJ-S processor. The package itself is Apple-branded and marked 337S3473 8702.
|-
| 3
| SDRAM
| [http://www.samsung.com/global/system/business/semiconductor/product/2007/11/13/236652ds_k4x56163pi.pdf K4X56163PI] or Qimonda HYE18M169CX75
| 0728, C, HYE18M256, 169CX75, W3338092
| SDRAM - Mobile DDR, 256Mb, 1.8V. WORK ON THIS: Like the flash chip, the memory also varies. The most popular chip seems to be the [http://www.samsung.com/global/system/business/semiconductor/product/2007/11/13/236652ds_k4x56163pi.pdf K4X56163PI]. Another similar one that is sometimes used is the Qimonda HYE18M169CX75
|-
| 5
| Utility Flash
| [http://www.sst.com/products/?inode=41340 SST25VF080B]
| V80B, 729379
| Flash - NOR, 8Mb, Serial SPI
|-
| 6
| NAND Flash
| Varies
| Samsung 728, K9HCG08U5M, PCB0, FCF285X1
|
|-
| 1
| Audio codec
| WM1870
| APPLE, 338S0462, 76BZKTM
|
|-
| 4
| Power manager
| D1671B
| 338S0408, 07258HAH
|
|}

== SPI NOR Test Pads ==

Test pads are available on the back of the board to access SCK, MISO and CS between the SoC and the NOR utility flash. MOSI is also present, but is buried in an internal layer (second from back) which can be accessed by carefully scraping off the top FR4 using a sharp tool, or by using a tiny carbide bit on a milling machine.

[[Image:N3g-spi-nor.png|500px]]
[[Image:N3g-spi-nor-zoom.png|500px]]

== Hardware Notes ==
=== CPU ===
The Apple S5L8702 is an ARM926EJ-S processor designed by Samsung. It is estimated to run at 100MHz (I read this somewhere but I don't remember where). The basics of the chip are similar to the S5L8700x for which there is [[S5L8700 datasheet|a leaked datasheet]]. For some peripherals, merely a base address has changed. For others, full subsystems have been updated and refined.

=== GPU ===
Very little is known about the GPU core other than the fact that it almost certainly exists. It's likely a single PowerVR GPU core that can maybe can decode H.264 content up to 480p (or perhaps there's another peripheral responsible for this?). It's also possible that the GPU is responsible for rendering games, since it appears the games use some form of OpenGL ES. CoverFlow also probably leverages the GPU.

=== I2C ===
The S5L8702 has several I2C busses (two, probably?), but possibly only one is used (bus #0). On this bus, there are currently two known slaves:
* The PMU at address 0x73
* The DAC at address 0x1A
The bus runs at 1.8V with a clock of 333.33KHz.

Other notes about the I2C peripheral from Rockbox:
* s5l8702 I2C controller is similar to s5l8700, known differences are:
** IICCON[5] is not used in s5l8702.
** IICCON[13:8] are used to enable interrupts.
** IICSTA2[13:8] are used to read the status and write-clear interrupts.
* Known interrupts:
** [13] STOP on bus (TBC)
** [12] START on bus (TBC)
** [8] byte transmitted or received in Master mode (not tested in Slave)
** IICCON[4] does not clear interrupts, it is enabled when a byte is transmited or received, in Master mode the tx/rx of the next byte starts when it is written as "1".

=== Digital Audio Subsystem (I2S) ===
The iPod n3g uses a Wolfson DAC (WM1870) to convert digital audio to analog audio. The S5L8702 sends digital audio in the form of I2S data at 44.1kHz with 16-bit resolution. Even if there is no audio playing, at some point during boot up, the I2S peripheral is turned on, meaning the Bit Clock and Word Select are always on. During the 1kHz tone test in the diagnostic menu, the I2S mode is different, possibly a half-data mode since the test tone is one channel.
The S5L8702 seems to support 3 I2S interfaces, but only one is used for audio playback. It's possible another one is used for microphone recording (when an Apple headset with a microphone is plugged in, you can record voice memos) but this is unconfirmed.

The S5L8702 sends data to the DAC at full volume no matter what. Volume is configured via I2C bus #0. As far as I can tell, two commands are issued to change the volume:
Address 0x1A, Data 0x04 <volume>
Address 0x1A, Data 0x07 <volume>
Where <volume> is a number between 0xB7 for quietest to 0xF5 for loudest. It's also possible that a special value of 0x80 is for full mute, but this is unconfirmed. It's also unclear what the 0x04 and 0x07 mean, perhaps it's capable of changing the volume of both channels independently?

Both the I2C and I2S busses run at 1.8V.

=== NAND ===
NAND hardware is an enigma. There has been a rather substantial effort on this subsystem alone. Most of that is documented [https://github.com/lemonjesus/S5L8702-FMISS-Tools here].

==Helpful pages==
Chip analyses:
*http://www2.electronicproducts.com/Applie_iPod_Nano_(4GB)_3rd_Generation-whatsinside-16.aspx#
Teardowns:
*http://content.techrepublic.com.com/2346-13636_11-170826-1.html
*http://www.ifixit.com/Guide/First-Look/iPod-Nano-3rd-Generation/594/1
*http://insidetronics.blogspot.com/2007/09/teardown-ipod-nano-3g.html
*[http://www.combert-elec.com/www/bookpic/200810916515460624.jpg Image of 3G Nano board]