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	0x10000	Sixteen NBL Configurations
0x110000	0x10000	Two Boot Profiles
0x120000	0x10000	Two unknown blobs (see Communication Processor#Ss blob)
0x130000	0x10000	Zeroes

Miniboot/Stage2 part

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

Miniboot + stage2 part layout

Offset in part	Size	Content
0x0	0x1000	Miniboot (raw ARM binary)
0x1000	Up to 0x7F000	AES-CBC encrypted stage2 (raw ARM binary)

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

struct miniboot_encblob {
   uint32_t unk0;         //<! Unused?
   uint32_t miniboot_crc; //<! CRC32 of Miniboot (including this structure, decrypted and with this field zero'ed out)
   uint32_t stage2_len;   //<! Size of stage2 in bytes
   uint32_t stage2_crc;   //<! CRC32 of stage2 before decryption
   uint32_t stage2_riv;   //<! RIV for AES-CBC decryption of stage2
   uint32_t stage2_erk;   //<! ERK for AES-CBC decryption of stage2
   uint32_t stage2_unk1;  //<! Unknown. Some kind of size? 0x13000000 in studied eMMC
   uint32_t stage2_unk2;  //<! Unknown. Some kind of size? 0x1305532C in studied eMMC (= stage2_unk1 + stage2_len)
};

NBL Config

Starts with the following structure:

struct nblcfg_data {
  uint16_t magic;      //<! 'NC' for NBL Config
  uint8_t _rsvd[2];    //<! Reserved
  uint8_t boot_stat;   //<! Boot status
  uint8_t kern_sel;    //<! Kernel selection
  uint8_t disp_stat;   //<! Display status - this field is most likely deprecated on GCP (always 0xFF)
  uint8_t _rsvd2[116]; //<! Reserved
  ushort color;        //<! Related to partitioning?
  ushort cksum;        //<! Calculate with the following routine
};

uint16_t nbl_calc_cksum(struct nblcfg_data *config) {
  uint16_t sum = 0;
  
  for (int i = 0; i < sizeof(*config) - sizeof(uint16_t); i++) { //don't include config->cksum in checksum
    sum += ((uint8_t*)config)[i];
  }

  return sum;
}

//Values for kern_self
#define KERN_SEL_RECOVERY 0x01  //<! Recovery kernel
#define KERN_SEL_NORMAL 0x02    //<! Normal kernel

//Values for boot_stat
#define BOOT_STAT_BOOTING 0x01   //<! Booting
#define BOOT_STAT_BOOTDONE 0x02  //<! Boot done

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

Boot Profile

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

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

Ss blob

Starts with Ss (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 (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

System software

See also Communication Processor Update Package.

Status LED

 Green  : ?CP running?
 Blue   : Main board (Kermit) not connected, usually because 5V power adapter is not connected
 Cyan   : CP firmware updating
 Yellow : ?CP RTC updating?