DFU mode detect, high when USB plugged and POWER switch is enabled, used only during boot

P1.0

I

POWER switch

P1.1

I

USB detect? goes low when USB plug is removed

P1.2

I

unknown input, used as external interrupt

P1.3

I

headphone detect (0 = headphones present)

P1.4

I

tuner interrupt?

P1.5

I

Melfas touch key controller DATA signal

P1.6

I

Melfas touch key controller DRDY signal

P2.X

I/O

SMC data I/O

P3.2

O

LEDs behind white menu/back buttons

P3.3

O

LEDs behind blue up/down/left/right buttons

P3.4

O

Melfas touch key controller DCLK signal

P4.1

O

SMC CLE

P4.2

O

LED behind middle button

P4.3

I

HOLD switch

P4.4

I

SMC nWR

P4.5

I

SMC nRD

P4.7

O

radio power

P5.0

O

audio mute (0 = mute)

P5.1

I/O

unknown input/output

P5.2

O

unknown output

P5.3

O

charging current set (0 = about 220 mA, 1 = about 300 mA)

P5.4

I

charging status (1 = charging)

P5.6

O

charger enable

P6.3

O

UART1 TxD

P6.4

I

UART1 RxD

P6.5

O

SMC chip enable

P6.6

O

SMC chip enable

P7.0

O

LCDnRST

P7.1

O

LCDnCS

P7.2

O

IISMCK

P7.3

O

IISWS

P7.4

O

IISBCLK

P7.5

O

IISD_OUT

P7.6

I

IISD_IN

P10.0

O

I2C SCL

P10.1

I/O

I2C SDA

The LCD is connected to NOR flash RAM port, plus pins P7.0 and P7.1 for reset and select.

I2C devices

Internal i2c bus:

0x20: Si4703 FM tuner, similar to Si4700 and Si4702, but with RDS support

0x34: WM1800 codec

0x60-0x6F: looks like an S35390A RTC

Touch key controller

The touch keys are controlled by a Melfas touch key chip.

When a key is touched, the controller pulls down P1.6, signalling that the CPU can now use P3.4 to clock in a 20-bit word from pin P1.5. The status (touched or released) of each touch key can be determined from the bits in this word.

The measured battery voltage seems to be valid only when the USB plug is inserted.

Charger

Charging can be enabled and disabled by software. The charger stops charging automatically when done. Software can monitor the charging status (charging busy or done) and configure one of two charging current settings.

Display

This player seems to support two (yet unidentified) LCDs. The lcd type is determined by looking at pin P0.4. These LCDs seem to have similarities with the displays used in the Onda VX-747 and the Meizu M3.

Audio codec

The WM1800 audio codec has no publicly available documentation, but the register layout is very similar to that of other Wolfson codecs, e.g. the WM8960.

USB modes

The Samsung can present itself with three different USB configurations: MTP, MSC and DFU.

MTP mode

In MTP mode, it presents itself as a device with three endpoints (2x bulk, 1x interrupts) additional to the mandatory control endpoint 0. The USB interface says it uses a vendor specific class, subclass and protocol. Windows recognises this as an MTP device. Vendor id (VID) and product id (PID) in this mode are 0x04E8/0x5091.

MSC mode

In MSC mode, it presents itself as a regular MSC device, with two "drives" (at least it does so on Linux). One of the drives contains the usual stuff like a "Music" folder, but also some interesting files in the "SYSTEM" folder (seems like debugging info). The other drive seems to contain all kinds of low-level configuration files. MSC mode can be enabled by putting a firmware update file along with a specific "config.dat" file on the player and letting it update on reboot. Vendor id (VID) and product id (PID) in this mode are 0x04E8/0x5090.

DFU mode

DFU mode can be entered by plugging in the USB cable, then doing a hard reset (by pressing a pin in the hole at the back of the player) and holding the power button at the same time. The screen stays dark in this mode. The player now presents itself as a DFU device, with 0 extra endpoints additional to the mandatory control endpoint 0. Vendor id (VID) and product id (PID) in this mode are 0x0419/0x0145. This is exactly the same VID/PID as the Meizu M6SL in DFU mode!

Experimentation with the meizu_dfu tool shows that the DFU upgrader program can be uploaded successfully to the YP-S3 too, so we can run a rockbox bootloader test program in RAM.

NAND analysis

It is possible to upload a "BluesUtilNand" DFU image to the player, this DFU image allows access to the NAND memory over USB.

this could be the Whimory FTL signature, the bootloader refers to "Whimory 2.2.0"

00082000

00008000

DFU image

Looks like a DFU image, it has the "CUFD" signature at 0x00082020, strings refer to "NOR SST 2M"

00102000

00008000

DFU image

Same as above

00180000

00008000

DFU image

Same as above

00188000

0018C000

Bootloader DFU

Contains code to read/write/format the FTL, contains the graphics for the glowing S3 logo

04F80000

-

some table

Looks like some tables, could be FAT or FTL tables

05880000

-

FS data

file data (mp3 data)

The utility also allows uploading of "spare" NAND. The spare NAND blocks are much smaller than the main NAND. A possible use is meta-data for the FTL (e.g. markers, error correction data, erase/usage counters)