summaryrefslogtreecommitdiffstats
path: root/bootloader.cpp (unfollow)
Commit message (Collapse)AuthorFilesLines
2016-10-19Verify wipe package when wiping A/B device in recovery.Yabin Cui1-134/+0
To increase the security of wiping A/B devices, let uncrypt write wipe package in misc partition. Then recovery verifies the wipe package before wiping the device. Based on the original cherrypick, this CL also has additional changes to address the LOG statements and libziparchive changes. Bug: 29159185 Test: Build and boot into recovery. Change-Id: I186691bab1928d3dc036bc5542abd64a81bc2168 (cherry picked from commit 6faf0265c9b58db2c15b53f6d29025629d52f882)
2016-09-01Switch recovery to libbase loggingTianjie Xu1-13/+14
Clean up the recovery image and switch to libbase logging. Bug: 28191554 Change-Id: Icd999c3cc832f0639f204b5c36cea8afe303ad35 Merged-In: Icd999c3cc832f0639f204b5c36cea8afe303ad35
2016-08-25Make it backwards compatible with 4.4Ethan Yonker1-8/+11
Change-Id: I668604cddc8e8afbf78709f3f872bea4e9f4aa06
2016-06-30Create bootloader_message static library.Yabin Cui1-235/+0
bootloader_messages merges bootloader_message_writer and bootloader.cpp, so we can use the same library to manage bootloader_message in normal boot and recovery mode. Bug: 29582118 Change-Id: I9efdf776ef8f02b53911ff43a518e035e0c29618
2016-06-21Verify wipe package when wiping A/B device in recovery.Yabin Cui1-41/+58
To increase the security of wiping A/B devices, let uncrypt write wipe package in misc partition. Then recovery verifies the wipe package before wiping the device. Bug: 29159185 Change-Id: I186691bab1928d3dc036bc5542abd64a81bc2168
2016-06-10Remove obsolete MTD support.Elliott Hughes1-87/+2
Bug: http://b/29250988 Change-Id: Ia97ba9082a165c37f74d6e1c3f71a367adc59945
2016-03-29Switch to <android-base/unique_fd.h>.Elliott Hughes1-5/+5
Change-Id: I13ba3f40bd52b5f3e3fe9002a45a9a8630040129
2016-02-19DO NOT MERGE ANYWHERE Use synchronous writes when setting up BCB.Tao Bao1-7/+22
Commit [1] made similar changes into AOSP code, but it requires multiple CLs to cherry-pick into cw-e branch. So we make a separate CL to fix the issue. [1] commit bd82b27341336f0b375c3bc2a7bf48b2ccc20c1f Bug: 27247370 Change-Id: Id5c08a6a29284353f891cdbaa224feee891f3807
2016-01-21Change BCB to perform synchronous writes.Tao Bao1-59/+74
Also some trivial clean-ups in bootloader control block (BCB) code. Change-Id: I42828954caa4d08998310de40fd0391f76d99cbe
2015-05-18bootloader: align with AOSP codethat1-152/+54
- Define a minimal Volume structure so that AOSP code for handling /misc works in TWRP without major changes. - Remove set/get_bootloader_message_*_name Change-Id: Ifcee59568141a184adebb94b8ef8beca072a7942
2015-03-27bootloader: fix crash with empty lines in /cache/recovery/commandthat1-3/+9
original fix from commit 93ffa7579cd75d1bdb2d124aa5cc5f8b6025e3d8 copied to our code. Also fixed a whitespace issue in the same code block. Change-Id: I6396803659c6880cde4f2b2ef08efab5721c215d
2014-07-16Allow custom bootloader msg offset in block miscMatt Mower1-0/+12
Use board define BOARD_RECOVERY_BLDRMSG_OFFSET with a decimal integer to define a custom offset where the bootloader message should be read/written. Change-Id: Id13a23dd41bb7d907b96d657b8e21eb839dfeaa9
2014-07-16Do not wipe block misc on bootloader msg updateMatt Mower1-2/+2
When set_bootloader_message_block() is called, it fopens /misc in write binary mode, wiping all contents other than what is being written. The bootloader msg structure is only 1024+32+32 bytes, so some manufacturers store more than just a bootloader msg on /misc. fopen in read+append mode so that only the bootloader msg is written and the rest of the partition is left untouched. Change-Id: I2d2fbdf067282744864a19d404ca7dc12f688a98
2013-04-08Fix handling of AOSP recovery commandsDees_Troy1-0/+72
2013-04-04Move all AOSP code out of recovery binaryDees_Troy1-2/+65
Improves license compatibility between GPL and Apache Change-Id: I2b165aa575bb6213af6b07936f99610c113443f0
2013-02-20Move to using the new unified fstab in recovery.Ken Sumrall1-21/+22
Instead of reading it's own fstab, have recovery invoke fs_mgr to read the unified fstab. Change-Id: I80c75d2c53b809ac60a4a69f0ef7ebfa707c39e9
2012-09-05TWRP-ify AOSP codeDees_Troy1-0/+2
Pull in most TWRP sources Stub out partition management code Make it compile -- probably will not boot Kind of a mess but have to start somewhere
2011-10-31turn recovery into a C++ binaryDoug Zongker1-0/+0
Change-Id: I423a23581048d451d53eef46e5f5eac485b77555
2011-10-28turn recovery into a C++ binaryDoug Zongker1-202/+0
Change-Id: I68a67a4c8edec9a74463b3d4766005ce27b51316
2011-07-14Check pointer for null before dereferencingAdam Bliss1-0/+8
Change-Id: Ie7563bf8fb2d627454010de7388d0992e2accf91
2011-05-04delay accessing misc partition until its device existsDoug Zongker1-0/+21
When the misc partition is on an emmc device, recovery can get started and try to access it before the kernel has actually created the device. Try statting the device before reading or writing it; delay up to 10 seconds waiting for the device to exist. Change-Id: I93256db4b047c76020490e8a3dc76b8ade643291
2011-05-04delay accessing misc partition until its device existsDoug Zongker1-0/+21
When the misc partition is on an emmc device, recovery can get started and try to access it before the kernel has actually created the device. Try statting the device before reading or writing it; delay up to 10 seconds waiting for the device to exist. Change-Id: I988442d5701394d7152bfab3c571e7548c364f61
2011-04-22delay accessing misc partition until its device existsDoug Zongker1-0/+21
When the misc partition is on an emmc device, recovery can get started and try to access it before the kernel has actually created the device. Try statting the device before reading or writing it; delay up to 10 seconds waiting for the device to exist. Change-Id: Ib9bf6c35fa2c28fc43aa7550aaaffb76c9f6e120
2010-09-21use fs_type "emmc" instead of "block" for consistency (do not merge)Doug Zongker1-2/+2
Change-Id: Iab60665d9c6daef7893896a64b7f319120a5f8ee
2010-09-21remove the notion of "root path"; support mixed flash typesDoug Zongker1-83/+84
Remove the wacky notion of "roots" and "root paths" (those things that look like "FOO:some/path" instead of just "/foo/some/path"). Let each device specify its own table of available partitions and how to mount them (needed for devices that use both MTD/yaffs2 and EMMC/ext4 partitions). (Cherrypicked from gingerbread w/slight edits.) Change-Id: I2479ce76b13e73f1d12035c89386c3a82b3edf51
2010-09-21remove the notion of "root path"; support mixed flash types (do not merge)Doug Zongker1-40/+92
Remove the wacky notion of "roots" and "root paths" (those things that look like "FOO:some/path" instead of just "/foo/some/path"). Let each device specify its own table of available partitions and how to mount them (needed for devices that use both MTD/yaffs2 and EMMC/ext4 partitions). Change-Id: I18b0a572a71c5e087e0b7ae11b1774388339bfd1
2010-08-13support using an EMMC misc partition to store recovery argumentsDoug Zongker1-2/+53
Change-Id: I9f912857cfc6afb8ba764f5541af7f01df029a77
2010-02-03bump updater API version to 3; deprecate firmware update commandDoug Zongker1-249/+0
Remove support for the HTC-specific "firmware" update command and the corresponding edify function write_firmware_update(). This functionality is now done by an edify extension library that lives in vendor/htc. Change-Id: I80858951ff10ed8dfff98aefb796bef009e05efb
2010-01-21save the recovery log from before HTC firmware updatesDoug Zongker1-1/+100
When doing a firmware (radio or hboot) update on HTC devices, save the recovery log in block 1 of the cache partition, before the firmware image and the UI bitmaps. When we boot back into recovery after the firmware update to reformat the cache partition, copy that log out of cache before reformatting it and dump it into the current invocation's log. The practical upshot of all this is that we can see the log output from radio and hboot updates. Change-Id: Ie0e89566754c88f4bed6a90d8a0aa04047b01a27
2010-01-13make offsets in firmware update header not point to bad blocksDoug Zongker1-4/+8
(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?)
2010-01-13make offsets in firmware update header not point to bad blocksDoug Zongker1-4/+8
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?)
2009-03-04auto import from //depot/cupcake/@135843The Android Open Source Project1-0/+267
2009-03-04auto import from //depot/cupcake/@135843The Android Open Source Project1-267/+0
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-30 21:07:53 +0200