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
