[Droid Eris Q&A, Help & Troubleshooting] bftb0:
Well, there have been a small number of handsets which mysteriously developed massive numbers of "bad pages" of Flash memory within a partition range - so many that the available space for storing data shrinks to less than half the original size of the partition. This hasn't happened very often, though, and I don't think that is your problem - read on.

A little background is useful here: Flash Memory is an inherently unreliable form of memory - not only does it "wear out" after 100,000 to 1,000,000 write cycles, but also, sometimes the chips come straight from the factory with a small number of "pages" already marked bad. This is quite normal though - so, don't let that throw you. In fact, every time a "page" of data is written, there is a check automatically made to verify that the write occurred correctly. If that check fails, that page is marked bad, and the device driver automatically writes the (failed) data to another page. The pages that are previously marked bad will never get used again, so the flash memory chip user doesn't really ever notice that something went bad, and pages are allowed to wear out gradually and gracefully.

So, how much space is supposed to be available in the boot partition? Well, here's a snippet of the output of "dmesg" during the initial kernel boot-up:

<6>[ 7.420013] NAND_READ_ID = 5501bcec
<6>[ 7.420288] status: c03120
<6>[ 7.420318] nandid: 5501bcec maker ec device bc
<6>[ 7.420440] CFG0: cw/page=3 ud_sz=512 ecc_sz=10 spare_sz=4
<6>[ 7.420532] DEV_CMD1: f00f3000
<6>[ 7.420654] <6>NAND_EBI2_ECC_BUF_CFG: 1ff
<6>[ 7.420654] flash_id: 5501bcec size 20000000
<5>[ 7.420715] Creating 6 MTD partitions on "msm_nand":
<5>[ 7.420745] 0x00001ff60000-0x000020000000 : "misc"
<5>[ 7.423309] 0x000002c60000-0x000003160000 : "recovery"
<5>[ 7.431915] [B][COLOR=red]0x000003160000-0x0000033e0000 : "boot"[/COLOR][/B]
<5>[ 7.436920] 0x0000033e0000-0x00000dde0000 : "system"
<5>[ 7.684448] 0x00000dde0000-0x000015fe0000 : "cache"
<5>[ 7.874237] 0x000015fe0000-0x00001ff60000 : "userdata"

Using a hex calculator, I get x33E0000 - x3160000 = x280000 = 2,621,440 bytes.

So, it appears that you can write a file which is 89.921% of full, but you can't write a file which is 99.14% of the size of the boot partition.

I think you just got a little unlucky - you have a couple of bad pages in the boot partition of your flash memory chip. Note also that a "page" has 2048 (user) bytes in it - so those "boot.img" files that you are trying to write are only 11 pages short of the full partition!

I'm actually sort of shocked! I didn't realize that the Eris devs were pushing things that hard in the boot partition! 11 spare pages - out of only 1280 pages total. That means that if slightly less than 1% of your pages go bad, you can't fit their ROMs into your phone :o

For references, here are the sizes of HTC stock boot images:

Cupcake 1.5 v1.16.605.1: 1,810,432 bytes

Cupcake 1.5 v1.17.605.1: 1,794,214 bytes

Eclair 2.1 v2.36.605.1: 2,245,247 bytes

Sorry soldier - you need to petition the overlords to stop sending you so many supplies.

The only alternative you have is to unpack their ROMs, then unpack the boot image, cut some bloat out of it, repack the boot image, re-zip and re-sign the ROM.

(There is one other alternative, but I'll not suggest it because it involves dangerous practices - the truth of the matter is that the devs are letting their boot images get a little bit too big.)

bftb0