Flash Memory Map for the Eris:
Code:
PARTITION   START        END          SIZE(1KB)  SIZE(128KB)  NOTES

radio       0x00000000 - 0x02980000   42,496     332          (3)
- gap! -    0x02980000 - 0x029a0000      128       1          (3)
hboot       0x029a0000 - 0x02a60000      768       6          (2)
misc3       0x02a60000 - 0x02aa0000      256       2          (5)
mfg         0x02aa0000 - 0x02ae0000      256       2          (6)
sp1         0x02ae0000 - 0x02ba0000      768       6          (4)
misc2       0x02ba0000 - 0x02c00000      384       3          (4)
mfg2        0x02c00000 - 0x02c60000      384       3          (4)
recovery    0x02c60000 - 0x03160000    5,120      40
boot        0x03160000 - 0x033e0000    2,560      20
system      0x033e0000 - 0x0dde0000  174,080    1360
cache       0x0dde0000 - 0x15fe0000  133,120    1040
userdata    0x15fe0000 - 0x1ff60000  163,328    1276
misc        0x1ff60000 - 0x20000000      640       5
( You can verify the above on your own phone with a combination of examining /proc/mtd, "dmesg" output immediately after the boot, and output of "fastboot oem listpartition" )


(1) Note all partitions are aligned to a 128-KB boundary (0x20000 - 18 bits)
Presumably this is why "fastboot oem listpartition" reports sizes in this unit

(2) Hboot images from HTC for the Eris have always been exactly 512 KB. Slack space is here,
but I found nothing but 0xFF's in the slack area.

(3) Attempting to dump the from this partition produces many, many error messages of the form:

mtd: MEMGETBADBLOCK returned -1 at 0x02940000 (errno=5)
mtd: MEMGETBADBLOCK returned -1 at 0x02960000 (errno=5)

(4) On my phone, dumps of partitions "sp1", "mfg2" and "misc2" produced un-interesting data blobs: all 0xFF's
Note that I have never flashed a custom boot splashscreen.

(5) Nearly "empty" - bytes not 0x00 or 0xFF are all string data (including CID)

(6) Contains "interesting" string data (including handset ID, manufacturing date, etc) and other binary data. Performing interesting handset operations and then recapturing a partition dump (before/after) and performing a binary diff could reveal strategic locations.


HOW-TO

Most people have absolutely no business doing this - you have been warned.

Under no circumstances should you hand-type any of these addresses; a simple typo could lead to disaster.

Code:
fastboot -c " mtdparts=msm_nand:0x000a0000@0x1ff60000(misc),0x00500000@0x02c60000(recovery),0x00280000@0x03160000(boot),0x0aa00000@0x033e0000(system),0x08200000@0x0dde0000(cache),0x09f80000@0x15fe0000(userdata) " boot recovery-RA-Eris-v1.6.2.img
will produce the standard kernel partition mappings. Note the leading and trailing spaces in the quoted string - and that the order of appearance is critically important

You may append one or more** of the following, separated with commas as shown in the above (standard mapping) command.

0x02980000@0x00000000(radio)
0x000c0000@0x029a0000(hboot)
0x00040000@0x02a60000(misc3)
0x00040000@0x02aa0000(mfg)
0x000c0000@0x02ae0000(sp1)
0x00060000@0x02ba0000(misc2)
0x00060000@0x02c00000(mfg2)

** I performed individual boots adding only one non-standard partition, and can not guarantee that a disaster will not result if you try to append more than one - or all of them - in one boot.

You can verify the additional partitions have been kanged into the kernel's device tree with

adb shell cat /proc/mtd

and may dump individual partitions via the command "dump_image" (provided by Amon_RA in /sbin), as in the following example:

mount /sdcard
dump_image mfg /sdcard/part.mfg.img



bftb0