Existing code has transport memory leaks. Use smart pointers
for transport to get rid of those cases and manual memory
management
Test: atest fastboot_test
Test: manually checked transport isn't leaking anymore
Bug: 296629925
Change-Id: Ifdf162d5084f61ae5c1d2b56a897464af58100da
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Trusty Benchmarks need to be evaluated in ABL which is much more
controlled than linux. However fastboot prints evry atomic message from
trusty/abl on its own line starting with "(bootloader)"
Bug: 263454481
Test: - "fastboot oem trusty runtest trusty.hwrng.bench"
Change-Id: I99847a8cc54457c8ec809e219736325dce0ac891
Do not use the implicit cast from unique_fd to int so
that it is clearer to the reader what the ownership model
is.
Test: pass
Change-Id: Iaf40a6eed3fcfd001651980c865ed5efb85ac0eb
The `fastboot fetch` command is a wrapper around
the fetch protocol. It:
- getvar max-fetch-size
- get the size of the partition
- read the data by chunks, chunk size = max-fetch-size.
The name of the partition is passed directly to the device
(with the usual has-slot magic for flashing etc.) If we support
fetching partitions other than vendor_boot in the future, no change
in the driver is needed.
Bug: 173654501
Test: manual
Change-Id: Ie576eea668234df236b096a372e65c5e91c1e48c
Instead of allocating the buffer for the whole
upload (which can be arbitrary number of bytes as
the device determines), read 1 MiB at a time.
Test: pass
Bug: 173654501
Change-Id: Ib601b0341b10b7dccbb429cd21aad86a2d3bfda8
Refactor UploadInner and add a new RunAndReadBuffer helper function
that handles the generic procedure of:
1. Sending a command
2. Receiving a DATA response with N bytes
3. Receiving another response
Test: pass
Bug: 173654501
Change-Id: I568bea127315e42d8a111c23602fc582e7bc935b
When a snapshot is applied or is merging, requests to erase or flash
userdata, metadata, or misc must be protected. In addition, the
set_active command must be restricted when a merge is in progress.
In addition, introduce a "snapshot-update merge" command for assisting
with erase requests when a merge is in progress. As in recovery, this
will force a merge to complete.
Bug: 139154945
Test: apply update
fastboot erase userdata
fastboot erase metadata
fastboot erase misc
fastboot set_active
Change-Id: I152446464335c62c39ffb4cc6366be9de19eac30
This introduces two new commands to the fastboot protocol:
- getvar snapshot-update-status - Return "none", "snapshotted", or
"merging" depending on the current status set by the boot control
HAL.
- snapshot-update [cancel] - Cancel any pending snapshot-based updates
via the boot control HAL. After this, the HAL should return
MergeStatus::CANCELLED and "update-merge-status" should be "none".
If no argument is specified, the snapshot-update-status is returned
via an INFO response.
Bootloaders are expected to implement this in a manner consistent with
the boot control HAL.
Fastboot-based tooling should expect wipes of userdata to fail when
update-merge-status returns "merging". Thus, the force flag now cancel
any pending snapshots.
Bug: 139154945
Test: fastboot getvar snapshot-update-status
fastboot snapshot-update cancel
fastboot snapshot-update
Change-Id: Idc423fe7656b212e929e64eb0e6b85b453e0e8dc
We must initialize UploadInner dsize value to 0, in case
stuck in ReadBuffer when receive DATA packet which dsize
is 0 or non DATA type packet. This will lead to fastboot
hang up unless USB unplugged.
Change-Id: I1e9752585c3d1013b1b1da38ead9ba4c532c2d34
Signed-off-by: qiwu chen <qiwuchen55@gmail.com>
As part of a refactor, commit db511207ed
added a timeout for receving responses for commands. Unfortunately,
the timeout is optimistic as to how quickly target devices can complete
such operations. Flash and erase commands can be quite slow on devices
with traditional flash chips. The fastboot protocol is already adept
at handling such cases because it allows for sending INFO packets during
these periods. We may receive one or more INFO packets during tehse long
operations. Every time we receive an INFO packet, it proves the remote
end is alive, but busy, which should reset our timeout timer.
Change-Id: Ia3bba21c497b22639b626d89711ecd4eb02504ed
Signed-off-by: Dima Zavin <dmitriyz@waymo.com>
Previously, system_clock was used for remote command timeouts
which can get disturbed by NTP adjustments (jumps).
Change-Id: I0ffc159bf34d12e8d3713044524114d60a6a45ca
Signed-off-by: Dima Zavin <dmitriyz@waymo.com>
This allows us to remove libziparchive's dependency on libutils.
Bug: http://b/79112958
Test: ran libbase and libziparchive tests, ran fastboot manually
Change-Id: I95c651976dad222863e5b8c37d4514b778f5dce7
Replace the remnants of engine.cpp with better functionality in
FastBootDriver. Particularly, add prolog() and epilog()
callbacks to FastBootDriver for printing actions and their result to
the console. Then clean up the rest of fastboot.cpp to directly use
FastBootDriver.
Test: fastboot works
Change-Id: I0ff01d6a10f75e9dc1c82b46c6e9bb3bc4c68638
CheckRequirements() had various issues that are cleaned up here,
1) Move from C string parsing to C++
2) Moved from C data structures to C++, including fixing memory leaks.
3) Removed the 'cur_product' global and the 'query_save' function that
stores it
4) Actually writing tests for the parsing function for
android-info.txt
5) Check that a variable needs to be checked for a given product before
trying to read it. Previously, fastboot would fail if a variable
isn't recognized on a device, even if the check should be ignored.
A lot of flexibility is allowed for the input strings, to keep
backwards compatibility with the previous parsers.
Test: fastboot works, unit tests
Change-Id: Idc3bba8b8fe829d8eefe5f6c495e63a9441c0b60
There is little advantage and increasingly much disadvantage to
queueing up fastboot commands before executing them. This change
removes the queue in the most simple way possible to enable further
clean up.
Test: fastboot works
Change-Id: I9abab05df07ed167dbe6a42e1eb9eab8f8d4f157
This change moves Transport ownership back out of FastBootDriver.
Callers of set_transport must ensure that the previous transport is
destroyed. In addition, deleting a transport now ensures that it is
closed.
Bug: 78793464
Test: fastboot, fuzzy_fastboot works
Change-Id: I8f9ed2f7d5b09fd0820b2677d087a027378f26db
This isn't sent by the fastboot client.
This isn't in our bootloader requirement document.
Neither my hikey nor sailfish respond to this.
Test: fastboot still works
Change-Id: I11ff0aed818d98f3427ed427605d99b3c76ccb06
This isn't sent by the fastboot client.
This isn't in our bootloader requirement document.
Neither my hikey nor sailfish respond to this.
The README.md literally uses this as an example for 'unknown command'
Test: fastboot still works.
Change-Id: Ia442a41de517dae078dd7e73c951aadb97646c73
In order to flash logical partitions, "flashall" must be run against
userspace fastboot. When the bootloader supports the "reboot-fastboot"
command, we now attempt to automatically reboot into userspace fastboot.
We do this by closing the transport, sleeping for one second, and then
polling for a new connection until one is available. FastBootDriver is
then assigned the new transport.
Bug: 78793464
Test: fastboot flashall on device with logical partitions, while booted
into bootloader fastboot
Change-Id: I6949871b93ab5e352784cabe0963c6ecfc0af36d
When host fastboot sends sparse blocks to the device, it tries to only
send blocks in multiples of 1024 bytes. If a block is not aligned to this
size, the excess bytes are prepended to the next write operation. This
is implemented by doing the write in two steps: first the previous
excess from the last write (plus new data up to alignment), then a
second write for the aligned remainder of the new data.
This logic has a bug if the final block plus the previous excess data
contains >= 1024 but < 2048 bytes. In this case the first write will
drain 1024 bytes from the data, and the second write will not have 1024
bytes to write. Instead of retaining this data for the next write, it
tries to write 0 chunks (and thus 0 bytes), which hangs the ioctl() call.
Bug: N/A
Test: "fastboot flash super super.img" where super.img is generated by
lpmake, containing system and product_services partitions and
images.
Change-Id: I9e8523c976ec84d5a57b36a28f4b1ca800edb7e7
This change creates a nice and clean API for issuing
fastboot commands without using the fastboot tool itself.
Test: fastboot tool itself (now using libfastboot2)
on sailfish, walleye, and other devices.
Test: flash bootloader bootloader.img
Test: flash radio radio.img
Test: -w update img.zip
Test: Manually getvar and reboot commands.
Bug: 111126621
Change-Id: I0022536b204ce0c5ad8329367fd522fa3c57877d
