| Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I63f28b3b4ba4185c23b972fc8f93517295b1672a
|
|
And a few trival fixes to suppress warnings.
Change-Id: I38734b5f4434643e85feab25f4807b46a45d8d65
|
|
Also add missing TEMP_FAILURE_RETRYs on read, write, and lseek.
Bug: http://b/20625546
Change-Id: I03b198e11c1921b35518ee2dd005a7cfcf4fd94b
(cherry picked from commit 7bad7c4646ee8fd8d6e6ed0ffd3ddbb0c1b41a2f)
|
|
Also add missing TEMP_FAILURE_RETRYs on read, write, and lseek.
Bug: http://b/20625546
Change-Id: I03b198e11c1921b35518ee2dd005a7cfcf4fd94b
|
|
Change-Id: I7009959043150fabf5853a43ee2448c7fbea176e
|
|
Bug: 18887435
Change-Id: Ice44c14fc8ee79eab259caf486e123b6af21ceb0
|
|
Recovery now draws directly to the framebuffer by rolling its own
graphics code, rather than depending on libpixelflinger.
The recovery UI is modified slightly to eliminate operations that are
slow with the software implementation: when the text display / menu is
turned on, it now appears on a black background instead of a dimmed
version of the recovery icon.
There's probably substantial room for optimization of the graphics
operations.
Bug: 12131110
Change-Id: Iab6520e0a7aaec39e2ce39377c10aef82ae0c595
Conflicts:
minui/resources.c
|
|
Recovery now draws directly to the framebuffer by rolling its own
graphics code, rather than depending on libpixelflinger.
The recovery UI is modified slightly to eliminate operations that are
slow with the software implementation: when the text display / menu is
turned on, it now appears on a black background instead of a dimmed
version of the recovery icon.
There's probably substantial room for optimization of the graphics
operations.
Bug: 12131110
Change-Id: Iab6520e0a7aaec39e2ce39377c10aef82ae0c595
|
|
Recovery currently has a random mix of messages printed to stdout and
messages printed to stderr, which can make logs hard to read. Move
everything to stdout.
Change-Id: Ie33bd4a9e1272e731302569cdec918e0534c48a6
|
|
Bug: 8580410
Change-Id: Ie60dade81c06589cb0daee431611ded34adef8e6
|
|
A few signed/unsigned comparison warnings were all that stood in the way
of a clean clang build.
Change-Id: Id8c47fcfa500a6ac164bddb855831cdc17d99847
Author: Edwin Vane <edwin.vane@intel.com>
Reviewed-by: Tareq A Siraj <tareq.a.siraj@intel.com>
|
|
See https://android-git.corp.google.com/g/#/c/157220
Bug: 5449033
Change-Id: I9ef9f808a852c36903c8afc40136c89c9ec07630
|
|
See https://android-git.corp.google.com/g/157065
Bug: 5449033
Change-Id: If6c6ea354caf02fb3bf155931b23e4a6d2f751e9
|
|
See https://android-git.corp.google.com/g/156801
Bug: 5449033
Change-Id: I3b4ea2184555bc0b570ec858601d4c43ecffb6f8
|
|
Change-Id: I423a23581048d451d53eef46e5f5eac485b77555
|
|
Change-Id: I68a67a4c8edec9a74463b3d4766005ce27b51316
|
|
Bug: 5010576
Change-Id: Ib465fdb42c8621899bea15c04a427d7ab1641a8c
|
|
Change-Id: Iada6268b0a72ee832113ea397334cc7950a37051
|
|
Free allocated MtdReadContext after freeing buffer field in struct,
not before.
Change-Id: I237920dc36115389cd2d6948e7a962dbec22fe56
|
|
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
|
|
Change-Id: Id1563ca667c50e61cf1bb15d2cf783a50937eece
|
|
Change-Id: If49fa6485f66598d16a7e44fce3129de55fab422
|
|
Change-Id: I6fc4ce796bc663d05035927c0af0ce7ab6d07218
|
|
(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?)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|