| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: Id1563ca667c50e61cf1bb15d2cf783a50937eece
|
| |
|
|
| |
Change-Id: If49fa6485f66598d16a7e44fce3129de55fab422
|
| |
|
|
| |
Change-Id: I6fc4ce796bc663d05035927c0af0ce7ab6d07218
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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?)
|
| | |
|
| |
|
|
|
|
| |
With the recovery image being installed by applypatch, the flash_image
tool isn't needed any more. Continue to build it for eng just in case
it's handy for debugging.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
