header.
Skipping flash after just checking a 1K header is
incorrect in the case where something scribbles over
the partition after the header because flash_image
would not be able to rewrite the whole
partition due to this check.
Also, Samsung devices use a combined boot and
recovery image where the header is the same even if the
initramfs changes and these do not get flashed even
if the boot.img is actually different due to different
appended initramfs.
Change-Id: I53ab0a23347cdf1fa7ff58dff37e812fd84645be
Detect flash type at runtime rather than requiring this to be set in the
device configuration. The detection is based on the existence of /proc/mtd,
/proc/emmc, or /dev/block/bml1.
Change-Id: I464962a567022c5862c249f06d36c2d1cddeacba
Re add firmware update
Change-Id: I699ad22390ed14e597d17a7bcb32ad1b1af00b4b
support mmc misc
Change-Id: Iff02f8d03db6835f501d052140cebeefee521305
fix compile errors
Change-Id: I032edbd157a8a15f561bb83330c715ebaa008d18
fix compile errors
Change-Id: Idff3449be3376f22fceefc2c35637527f8df8f3f
Initial work to clean up the block devices.
Change-Id: I4be20ac124864a281be9cd116e211a2618404a27
all done
Change-Id: I0338f62f6a045556ebe90b0200685be113178319
fix up nandroid
Change-Id: I886f00271183e6d2921c080b0939341f2cf12a4d
ECC errors are found by comparing the result of ioctl(ECCGETSTATS)
before and after the read. But if an error was found causing us to go
to the next block, we'd compare the stats before the *first* read to
the stats after the second (third, fourth, etc.) reads, so we'd read
to the end of the partition without ever succeeding. Fix logic so we
compare the values before and after each read independently.
Bug: 3162777
Change-Id: I5a13abd7243d2afd1d21bd98cbb233e5124b2e80
Close the update package before invoking the binary, to allow the
installer to unmount /cache if it wants to. Add a function to allow
remounting of a mount as read-only.
Change-Id: Idfcc96c3da66083295177f729263560be58034e4
(This is being cherry-picked from master.)
hboot will apparently fail to install if the first block of the image
(the one pointed to by the offset in the block 0 header) is a bad
block. (Hopefully it handles subsequent bad blocks.)
This change makes the MTD write code keep track of the bad blocks it
has skipped over, so that the offset in the header can be adjusted to
be the address of the first successfully written block.
http://b/2358012 - passion: failure to flash hboot (bad blocks?)
hboot will apparently fail to install if the first block of the image
(the one pointed to by the offset in the block 0 header) is a bad
block. (Hopefully it handles subsequent bad blocks.)
This change makes the MTD write code keep track of the bad blocks it
has skipped over, so that the offset in the header can be adjusted to
be the address of the first successfully written block.
Change-Id: I45d58e32a36d0c1dbc0a7f871bd5985b6c8ff524
http://b/2358012 - passion: failure to flash hboot (bad blocks?)
We fail to detect certain bad blocks (marked in the factory as bad, I
think?) when reading mtd partitions. These come back as a block of
all zeros. Since it's fairly unlikely a legitimate boot or recovery
block will contain 128k of zeros, change mtdutils to skip over such
blocks.
Arve says https://review.source.android.com/10535 may be a long-term
fix for this, but he isn't yet sure.
