174 lines
5.8 KiB
Plaintext
174 lines
5.8 KiB
Plaintext
|
|
FastBoot Version 0.4
|
|
----------------------
|
|
|
|
The fastboot protocol is a mechanism for communicating with bootloaders
|
|
over USB. It is designed to be very straightforward to implement, to
|
|
allow it to be used across a wide range of devices and from hosts running
|
|
Linux, Windows, or OSX.
|
|
|
|
|
|
Basic Requirements
|
|
------------------
|
|
|
|
* Two bulk endpoints (in, out) are required
|
|
* Max packet size must be 64 bytes for full-speed, 512 bytes for
|
|
high-speed and 1024 bytes for Super Speed USB.
|
|
* The protocol is entirely host-driven and synchronous (unlike the
|
|
multi-channel, bi-directional, asynchronous ADB protocol)
|
|
|
|
|
|
Transport and Framing
|
|
---------------------
|
|
|
|
1. Host sends a command, which is an ascii string in a single
|
|
packet no greater than 64 bytes.
|
|
|
|
2. Client response with a single packet no greater than 64 bytes.
|
|
The first four bytes of the response are "OKAY", "FAIL", "DATA",
|
|
or "INFO". Additional bytes may contain an (ascii) informative
|
|
message.
|
|
|
|
a. INFO -> the remaining 60 bytes are an informative message
|
|
(providing progress or diagnostic messages). They should
|
|
be displayed and then step #2 repeats
|
|
|
|
b. FAIL -> the requested command failed. The remaining 60 bytes
|
|
of the response (if present) provide a textual failure message
|
|
to present to the user. Stop.
|
|
|
|
c. OKAY -> the requested command completed successfully. Go to #5
|
|
|
|
d. DATA -> the requested command is ready for the data phase.
|
|
A DATA response packet will be 12 bytes long, in the form of
|
|
DATA00000000 where the 8 digit hexidecimal number represents
|
|
the total data size to transfer.
|
|
|
|
3. Data phase. Depending on the command, the host or client will
|
|
send the indicated amount of data. Short packets are always
|
|
acceptable and zero-length packets are ignored. This phase continues
|
|
until the client has sent or received the number of bytes indicated
|
|
in the "DATA" response above.
|
|
|
|
4. Client responds with a single packet no greater than 64 bytes.
|
|
The first four bytes of the response are "OKAY", "FAIL", or "INFO".
|
|
Similar to #2:
|
|
|
|
a. INFO -> display the remaining 60 bytes and return to #4
|
|
|
|
b. FAIL -> display the remaining 60 bytes (if present) as a failure
|
|
reason and consider the command failed. Stop.
|
|
|
|
c. OKAY -> success. Go to #5
|
|
|
|
5. Success. Stop.
|
|
|
|
|
|
Example Session
|
|
---------------
|
|
|
|
Host: "getvar:version" request version variable
|
|
|
|
Client: "OKAY0.4" return version "0.4"
|
|
|
|
Host: "getvar:nonexistant" request some undefined variable
|
|
|
|
Client: "OKAY" return value ""
|
|
|
|
Host: "download:00001234" request to send 0x1234 bytes of data
|
|
|
|
Client: "DATA00001234" ready to accept data
|
|
|
|
Host: < 0x1234 bytes > send data
|
|
|
|
Client: "OKAY" success
|
|
|
|
Host: "flash:bootloader" request to flash the data to the bootloader
|
|
|
|
Client: "INFOerasing flash" indicate status / progress
|
|
"INFOwriting flash"
|
|
"OKAY" indicate success
|
|
|
|
Host: "powerdown" send a command
|
|
|
|
Client: "FAILunknown command" indicate failure
|
|
|
|
|
|
Command Reference
|
|
-----------------
|
|
|
|
* Command parameters are indicated by printf-style escape sequences.
|
|
|
|
* Commands are ascii strings and sent without the quotes (which are
|
|
for illustration only here) and without a trailing 0 byte.
|
|
|
|
* Commands that begin with a lowercase letter are reserved for this
|
|
specification. OEM-specific commands should not begin with a
|
|
lowercase letter, to prevent incompatibilities with future specs.
|
|
|
|
"getvar:%s" Read a config/version variable from the bootloader.
|
|
The variable contents will be returned after the
|
|
OKAY response.
|
|
|
|
"download:%08x" Write data to memory which will be later used
|
|
by "boot", "ramdisk", "flash", etc. The client
|
|
will reply with "DATA%08x" if it has enough
|
|
space in RAM or "FAIL" if not. The size of
|
|
the download is remembered.
|
|
|
|
"verify:%08x" Send a digital signature to verify the downloaded
|
|
data. Required if the bootloader is "secure"
|
|
otherwise "flash" and "boot" will be ignored.
|
|
|
|
"flash:%s" Write the previously downloaded image to the
|
|
named partition (if possible).
|
|
|
|
"erase:%s" Erase the indicated partition (clear to 0xFFs)
|
|
|
|
"boot" The previously downloaded data is a boot.img
|
|
and should be booted according to the normal
|
|
procedure for a boot.img
|
|
|
|
"continue" Continue booting as normal (if possible)
|
|
|
|
"reboot" Reboot the device.
|
|
|
|
"reboot-bootloader" Reboot back into the bootloader.
|
|
Useful for upgrade processes that require upgrading
|
|
the bootloader and then upgrading other partitions
|
|
using the new bootloader.
|
|
|
|
"powerdown" Power off the device.
|
|
|
|
|
|
|
|
Client Variables
|
|
----------------
|
|
|
|
The "getvar:%s" command is used to read client variables which
|
|
represent various information about the device and the software
|
|
on it.
|
|
|
|
The various currently defined names are:
|
|
|
|
version Version of FastBoot protocol supported.
|
|
It should be "0.3" for this document.
|
|
|
|
version-bootloader Version string for the Bootloader.
|
|
|
|
version-baseband Version string of the Baseband Software
|
|
|
|
product Name of the product
|
|
|
|
serialno Product serial number
|
|
|
|
secure If the value is "yes", this is a secure
|
|
bootloader requiring a signature before
|
|
it will install or boot images.
|
|
|
|
Names starting with a lowercase character are reserved by this
|
|
specification. OEM-specific names should not start with lowercase
|
|
characters.
|
|
|
|
|