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:
| 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.
| 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?