summaryrefslogtreecommitdiffstats
path: root/bootloader.cpp (unfollow)
Commit message (Collapse)AuthorFilesLines
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
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-29 01:36:01 +0200