-
Notifications
You must be signed in to change notification settings - Fork 12
M7MU Firmware Format
The DATANX3000.bin file has a 1024 byte header that matches closely the M7MU firmware header for Samsung K Zoom that was luckily dumped by the Samsung Android team. Version strings have the high bit set, and the relevant data fields seem to match. Use this project's firmware header decoder or write your own.
What's known so far:
- 1024 byte header includes meta-data, SDRAM and NAND initialization, and a table of embedded code sections
- "writer" code starts at
0x400in the file, is mapped to0x40000400and is uncompressed - this is not a boot loader but a firmware flasher apparently - actual application code starts at
0x50000and has seven sections using a custom LZSS compression: M7MU Compression. - Given the SDRAM and NAND init structures, it is well possible that the firmware image is written to flash 1:1 and directly mapped into the M7MU's address space, where the SoC performs initialization from.
- It's unclear yet which part is responsible for uncompressing the LZSS sections.
Header dump of DATANXmini.bin version 1.10:
| Field | Value |
|---|---|
| block_size |
0x400 (1024) |
| writer_load_size |
0x4fc00 (326656) |
| write_code_entry |
0x40000400 (1073742848) |
| sdram_param_size |
0x90 (144) |
| nand_param_size |
0xe1 (225) |
| sdram_data | snipped |
| nand_data | snipped |
| code_size |
0xafee12 (11529746) |
| offset_code |
0x50000 (327680) |
| version1 | "01.10" |
| log | "201501162119" |
| version2 | "GLUAOA2" |
| model | "NXMINI" |
| section_info | 1:0050e66c 2:001a5985 3:00000010 4:00061d14 5:003e89d6 6:00000010 7:00000010 |
| pdr | "" |
| ddr | 00 b3 3f db 26 02 08 00 d7 31 08 29 01 80 00 7c 8c 07 |
| epcr | 00 00 3c db 00 00 08 30 26 00 f8 38 00 00 00 3c 0c 07 |
Header dump of RS_M7MU.bin from Samsung K-Zoom (this is the firmware file that the Android CPU sends to the M7MU CPU, apparently):
| Field | Value |
|---|---|
| block_size |
0x400 (1024) |
| writer_load_size |
0x3fc00 (261120) |
| write_code_entry |
0x40000400 (1073742848) |
| sdram_param_size |
0x90 (144) |
| nand_param_size |
0xe1 (225) |
| sdram_data | snipped |
| nand_data | snipped |
| code_size |
0x5dee12 (6155794) |
| offset_code |
0x40000 (262144) |
| version1 | "00.01" |
| log | "201405289234" |
| version2 | "D20FSHE" |
| model | "06DAGCM2" |
| section_info | 1:001b4b6c 2:0008ba07 3:00050494 4:0025f4bd 5:000ee7e7 6:00000010 7:00000010 |
| pdr | " " |
| ddr | 00 12 3f db 17 00 08 00 17 10 08 29 00 00 00 3c ac 07 |
| epcr | 10 00 3c db 00 00 08 30 26 00 f8 38 00 00 00 3c 0c 07 |
The section_info is a 25x uint32 array containing the number of sections (typically 7), followed by tuples of section number (1..7) and respective section size. The two "(implicit)" sections are not listed in section_info but instead derived from the header and the overall size of the firmware file:
| Offset | Size | Section |
|---|---|---|
| 00000400 | 326656 | boot (implicit) |
| 00050000 | 5301868 | chunk-01 |
| 0055e800 | 1726853 | chunk-02 |
| 00704200 | 16 | chunk-03 |
| 00704400 | 400660 | chunk-04 |
| 00766200 | 4098518 | chunk-05 |
| 00b4ec00 | 16 | chunk-06 |
| 00b4ee00 | 16 | chunk-07 |
| 00b4f000 | 123152628 | SF_RESOURCE (implicit) |
The first section begins at offset_code, and the following sections are 512-byte aligned. In total, the sum of section sizes is approximately 3 kilobytes smaller than code_size, however with the alignment and padding, the sections actually fill up the code_size space.
The sections are compressed individually, see M7MU Compression for details.
Immediately after the last section (not padded to the next block) there is a two-byte value (a checksum?). Otherwise, the sections are padded with zeroes.
After the sections, the remainder(?) of the firmware is filled by the SF_RESOURCE section. After that, there are some hundred bytes of zero-padding and a 9-byte value (another checksum of sorts?)