SLP Firmware Format

Reverse engineering of SLP firmware files

This is the container format used for Samsung Linux Platform (SLP) on NX300/NX1/Gear360/..., e.g. nx300.bin. The firmware file contains a header and multiple partition files.

Relevant links:

• DIY NX300 firmware
• Gear 360 firmware structure

Additional data from:

• reverse engineering fw_generator (thanks Samsung for shipping debug symbols!)

Firmware Meta Header fwfile_meta

Each firmware file begins with a 64 byte meta header, defined as follows:

Offset	Size	Type	Name	Comment
0	4	char[4]	magic_code	"SLP\0" in all known files
4	8	char[8]	version_user	null-terminated version string like "1.01"
12	16	char[16]	project_name	human readable device name, e.g. "NX1"
28	16	char[16]	version_date	firmware release, e.g. "NX1GLUANK6"
44	1	char	has_pcache	V1: 0/1 bool; V2: number of partition images (usually 9 or 10)
45	4	uint32	pcache_offset	V1: offset to pcache fw_image_header in firmware file; V2: ???
49	15	char[15]	reserved	V1: unused; V2: additional revision string

It's constructed by the fw_generator from a version.info file that's part of release planning and is also often bundled into the rootfs.

Example version.info content from the extracted nx300m.bin, with version_user, project_name, version_date and ???:

1.15
NX300M
NX300MGLUANL1
DSP_NX300MGLUANL1_SR1

Firmware Image Structure fw_image_header

The firmware meta header is followed by the image header, containing a list of partition images. For each partition, the following data is stored:

Offset	Size	Type	Name	Comment
0	4	uint32	img_len	Length of partition image
4	4	uint32	crc32	CRC32 of partition image
8	4	uint32	img_offset	Offset of partition image in bin file
12	4	uint32	magic	0x87654321 shifted depending on the partition position
16	8	char[8]	???	Only present in Tizen 2.x images, often filled with zeros

On Tizen 1.x devices, there are five image headers with 16 bytes each, on Tizen 2.x it's 10x 24 bytes (luckily, there is no version tag in the meta header!).

The order of the images is hardcoded in fw_generator, e.g. as follows for V1:

1. vImage
2. D4_IPL.bin
3. D4_PNLBL.bin
4. uImage
5. platform.img (rootfs)

They can be extracted from the image with dd and re-created using the fw_generator.