Grover

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.

Name	Partition #	Start LBA	End LBA	Size in sectors	Contents	Notes
	N/A	0	1	1
	1	64	2623	2560	Miniboot + stage2	Marked as active in MBR
	2	2624	3801087	3798464	Partitions 5/6/7/8	This is an extended partition
Linux-normal0	5	2640	502719	500080	FAT16 filesystem with 3 files: fsimage0.trf,fsimage1.trf and vmlinux.trf	Those partitions are identical
Linux-normal1	6	502736	1002815	500080
Linux-recovery	7	1002832	1127871	125040
N/A	8	1127888	1377919	250032	FAT16 filesystem with 3 files: settings.bin, settings.xml and settings_info.bin

Partition 1

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

Partition 1 layout

Offset in partition	Size	Contents	Notes
0x0	0x80000	Miniboot + stage2 (A)	Identical - second may be a recovery?
0x80000	0x80000	Miniboot + stage2 (B)
0x100000	0x40000	Unknown	Starts with NC, lots of 0xFF, some strings like Linux-normal0, ...

Miniboot + stage2 layout

Offset in part	Size	Content
0x0	0x1000	Miniboot
0x1000	Variable	AES-CBC encrypted stage2

Partition 5/6/7

Contains AXFS images of a Linux 2.6 kernel (vmlinux.trf), a rootfs (fsimage0.trf) and SCE-specific stuff (fsimage1.trf).

Partition 8

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 (CP_SERIAL_ID) and activation (ActivationKey).

settings.xml

This file is identical vs0:tool/settings_def_for_licensee.xml from firmwares 0.995.070-1.500.151.

settings_info.bin

3384 bytes. Contains mostly zeroes. The last 0x128 bytes are identical to settings.bin'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.

Boot Process

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 ([62:61]:[59]:[68:67]:[65:64]:[63]). From this value, and using the very common function lcrng(x) = (x * 1103515245) + 12345, ERK and RIV for an AES-CBC decryption is derived: RIV=lcrng(seed), ERK=lcrng(RIV). 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 ERK=0x41065F68 and RIV=0x1FB7C28B. The resulting blob instructs to load 0x5532C bytes from eMMC and decrypt them with ERK=0xDED7C26C and RIV=0x3D0E58A3.

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