Communication Processor

The Communication Processor (codename GROVER) is the main processor located on the GCP-00x boards in DEM-3000/PDEL-1000 units. CP is responsible for talking with the Host Computer a Development Kit is connected to. This page will cover all the hardware devices on the GCP boards.

= Main board devices =

NEC/Renesas KD77630AF1 EM1-S
The product's name is "EMMA Mobile™1-S". This chip promoted as a «Multimedia Processor for Mobile Applications» and is manufactured by Renesas (it was created by NEC Electronics Corporation before the company was acquired and merged with Renesas).

As a multimedia processor, EMMA hosts a DSP and multiple specialized blocks (e.g. H.264 decoder, LCD interface, IrDA, etc) and a single-core ARM1176JZF-S™ (max. frequency 500MHz) equiped with Dcache and Icache (32KiB each) as its main processor. Sony already used this chip in other products (NV-U37, NAS-SV20Di, NV-U35, RMN-U1, NV-U77V, NV-U97V, ...).

More details can be found in the documentation freely downloadable from the Renesas website.

SAMSUNG K4X2G323PC-8GD8
A 2Gb (256MiB) MDDR DRAM chip manufactured by Samsung.

EMMA is directly wired to this chip (mapped starting at 0x3000'0000 in the physical address space).

SAMSUNG KLM2G1DEHE-B101
A 16Gb (2GiB) MLC "moviNAND" chip manufactured by Samsung. The interface is a standard MMC bus, and the controller supports up to MMC protocol version 4.3.

EMMA is most likely directly wired to this chip (seemingly mapped to SDIC, physical address 0x50090000) and the CP firmware is stored on it.

SMSC USB25120
USB Hub. Directly connected to the data lines of the mini-USB type B port and to the USB3315. Datasheet here.

SMSC USB3315
Hi-Speed USB Transceiver with 1.8V-3.3V UPLI interface. Connected to the USB25120 and presumably connected to EMMA. Datasheet here.

MicroChip PIC16F724
8-bit MCU present for an unknown purpose. Datasheet here.

EPSON RX-4581
Real-Time Clock. Presumably holds time for activation. Datasheet here.

= eMMC Layout =

The eMMC's first sector contains a valid MBR. The following table lists all partitions present in it. Data outside of partitions is all zeroes on the eMMC.

Partition 1
This partition is 0x140000 bytes long and divided in three parts:

Miniboot/Stage2 part
The following program can be used to decrypt Miniboot+stage2 from a raw partition1 binary.

The last 0x20 bytes of the Miniboot payload are an AES-CBC encrypted blob. Once decrypted, the following structure is obtained:

NBL Config
Starts with the following structure:

Everything else besides the last 4 bytes is 0xFF. The last 4 bytes may be a checksum of sorts.

Boot Profile
Starts with  (0x42745066 in LE, , short for Boot Profile.

The last 8 bytes are always  (0x4250 in LE,   for Boot Profile), a field that seems to serve a similar purpose to NBL Config's , and the last 4 bytes are also similar to NBL Config's last 4 (maybe a checksum too).

Ss blob
Starts with  (0x5373 in LE, unknown what this stands for). Seems to start with a 0x40 bytes header, then encrypted data.

Partition 5/6/7
Contains AXFS images of a Linux 2.6 kernel, a rootfs and SCE-specific stuff.

settings.bin
82232 bytes. Contains string:value pairs similar to registry values from SceRegistryMgr (?cache of the registry to avoid fetching it from Kermit every time?) and some information about the CP and activation.

settings.xml
This file is identical  from firmwares 0.995.070-1.500.151.

settings_info.bin
3384 bytes. Contains mostly zeroes. The last 0x128 bytes are identical to 's and contain the CP/activation information.

= EMMA = The EM1-S SoC and its ARM core are the heart of the GCP board.

The information that follows is based on the dump of an eMMC and may not be perfectly accurate.

BootROM
According to the datasheet, the ARM core starts executing the ACPU Boot ROM (32KiB @ 0xFFFF0000) on RESET. The ROM bootloader «reads the Master Boot Record from the eMMC/NAND in which RCA is set to 0x1 and reads 4096 bytes from the LBA of the first active partition table» into SRAM. The loaded blob is called Miniboot in the datasheet, so this name will be used to refer to it.

Miniboot
Miniboot (A) is loaded to physical address 0xA0000000 (Internal SRAM) and executed from there. It runs without the MMU and its main job is to load Stage2. Under specific circumstances, Miniboot (A) can load Miniboot (B) or decrypt and execute a blob already present in DRAM, but we will ignore code related to this and focus on the intresting parts of the main code path.

Miniboot starts by reading a 8-bit value by concatenating the state of different GPIO pins. From this value, and using the very common function, ERK and RIV for an AES-CBC decryption is derived:. Miniboot AES-CBC decrypts in place the last 0x20 bytes of itself (at address 0xA0000FE0). Note the block size of the operation is 4 bytes. The resulting blob contains very important information.

Next, Miniboot performs an integrity check on itself by calculates a "CRC32"(not sure about the exact polynom, but it looks similar to CRC32) checksum over itself (including the decrypted blob - all 0x1000 bytes are included) and comparing it to a value stored in the blob. This ensures that the decryption was successful (otherwise the "CRC32" is garbage) and it has not been tampered with. On mismatch, Miniboot aborts boot (prints an error "message" to UART0, ?turns the red CP LED on? and enters an infinite loop).

Miniboot then reads a certain amount of bytes (this information is stored in the blob) from eMMC starting from the last sector that was read (e.g. offset 0x1000 in partition 1) into a part of DRAM (physical address 0x31F01000). This block's "CRC32" is calculated and compared to the expected value in the blob, then decrypted using the same AES-CBC routine. ERK and RIV come from the blob too. Afterwards, the blob is cleared and Miniboots hands execution to stage2.

NOTE: for the eMMC dump studied, the seed that must be read from GPIO for decryption to succeed is 0x5A, yielding  and. The resulting blob instructs to load 0x5532C bytes from eMMC and decrypt them with  and.

stage2
This part seems to be called NBL (NAND Boot Loader?) and seems to be partially based on FreeBSD's libstand.

System initialization
stage2 starts by "bringing up the system": initializing a lot of hardware registers, turning off unneeded parts of the SoC (e.g. DSP), installing exception handlers and creating page tables. Once the MMU is turned on, most of the RAM is identity-mapped as RWX Device memory in Domain 1, with the following exceptions: * The entirety of BANK12 (physical address 0xC0000000-0xCFFFFFFF) is mapped at vaddress 0xE0000000 (an unused range of physical address space) * DRAM is identity mapped as Device memory, but also mapped as cacheable memory at vaddress 0xC0000000 * The BootROM's first page (0xFFFF0000-0xFFFF0FFF) is not identity mapped but points to DRAM (physical address 0x31FFD000) instead. This is done because exception vectors are located at 0xFFFF0000. All the vectors point back into cached DRAM at 0xCxxxxxxx.

Once this is done, a jump to the next function (in cached RAM, 0xCxxxxxxx) is performed.

Main program
TODO Probably loads + decrypts the fsimages and vmlinux from Linux-xxx partitions at some point

Linux
TODO