
Reword some sentences, add missing periods and fix various typos in the dfu documentation.
This was originally contributed on [1]
[1] https://github.com/Maalobs/u-boot/commit/9a21ed8ba722d904b68945f40ca6697b4b1...
Signed-off-by: Mattijs Korpershoek mkorpershoek@baylibre.com --- The author wished to remain anonymous so I just included a link to the original change. --- doc/usage/dfu.rst | 60 +++++++++++++++++++++++++++---------------------------- 1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst index 8845a71df369..8cc09c308d82 100644 --- a/doc/usage/dfu.rst +++ b/doc/usage/dfu.rst @@ -6,11 +6,11 @@ Device Firmware Upgrade (DFU) Overview --------
-The Device Firmware Upgrade (DFU) allows to download and upload firmware -to/from U-Boot connected over USB. +Device Firmware Upgrade (DFU) enables the download and upload of firmware +to/from U-Boot while connected over USB.
U-Boot follows the Universal Serial Bus Device Class Specification for -Device Firmware Upgrade Version 1.1 the USB forum (DFU v1.1 in www.usb.org). +Device Firmware Upgrade Version 1.1 from the USB forum (DFU v1.1 in www.usb.org).
U-Boot implements this DFU capability (CONFIG_DFU) with the command dfu (cmd/dfu.c / CONFIG_CMD_DFU) based on: @@ -43,7 +43,7 @@ target (for example OTP), only based on the weak functions: Configuration Options ---------------------
-The following configuration option are relevant for device firmware upgrade: +The following configuration options are relevant to device firmware upgrade:
* CONFIG_DFU * CONFIG_DFU_OVER_USB @@ -60,7 +60,7 @@ The following configuration option are relevant for device firmware upgrade: Environment variables ---------------------
-The dfu command uses 3 environments variables: +The dfu command uses 3 environment variables:
dfu_alt_info The DFU setting for the USB download gadget with a semicolon separated @@ -90,17 +90,17 @@ Commands --------
dfu <USB_controller> [<interface> <dev>] list - list the alternate device defined in *dfu_alt_info* + List the alternate device defined in *dfu_alt_info*.
dfu <USB_controller> [<interface> <dev>] [<timeout>] - start the dfu stack on the USB instance with the selected medium + Start the dfu stack on the USB instance with the selected medium backend and use the *dfu_alt_info* variable to configure the - alternate setting and link each one with the medium - The dfu command continue until receive a ^C in console or - a DFU detach transaction from HOST. If CONFIG_DFU_TIMEOUT option - is enabled and <timeout> parameter is present in the command line, + alternate setting and link each one with the medium. + The dfu command continues until it receives a ^C in the console or + a DFU detach transaction from the HOST. If the CONFIG_DFU_TIMEOUT option + is enabled and a <timeout> parameter is present in the command line, the DFU operation will be aborted automatically after <timeout> - seconds of waiting remote to initiate DFU session. + seconds of waiting for the remote to initiate a DFU session.
The possible values of <interface> are (with <USB controller> = 0 in the dfu command example) @@ -139,11 +139,11 @@ mmc
u-boot raw 0x80 0x800;uImage ext4 0 2
- If don't want to flash given image file to storage, use "skip" type - entity. + If you don't want to flash the given image file to storage, use the "skip" + type entity.
- - It can be used to protect flashing wrong image for the specific board. - - Especailly, this layout will be useful when thor protocol is used, + - It can be used to protect from flashing the wrong image for the specific board. + - Especially, this layout will be useful when the thor protocol is used, which performs flashing in batch mode, where more than one file is processed.
@@ -153,18 +153,18 @@ mmc
u-boot-<board1>.bin raw 0x80 0x800; u-boot-<board2>.bin skip 0 0
- When flashing new system image requires do some more complex things - than just writing data to the storage medium, one can use 'script' - type. Data written to such entity will be executed as a command list - in the u-boot's shell. This for example allows to re-create partition - layout and even set new *dfu_alt_info* for the newly created paritions. - Such script would look like:: + When flashing a new system image requires you to do some more complex + things than just writing data to the storage medium, one can use 'script' + type. Data written to such an entity will be executed as a command list + in the u-boot's shell. This for example allows you to re-create a partition + layout and even set a new *dfu_alt_info* for the newly created partitions. + Such a script would look like::
setenv dfu_alt_info ... setenv mbr_parts ... mbr write ...
- Please note that this means that user will be able to execute any + Please note that this means the user will be able to execute any arbitrary commands just like in the u-boot's shell.
nand @@ -216,8 +216,8 @@ sf each element in *dfu_alt_info* being either of:
* <name> raw <offset> <size> raw access to sf device - * <name> part <dev_id> <part_id> raw acces to partition - * <name> partubi <dev_id> <part_id> raw acces to ubi partition + * <name> part <dev_id> <part_id> raw access to partition + * <name> partubi <dev_id> <part_id> raw access to ubi partition
with
@@ -288,17 +288,17 @@ Callbacks The weak callback functions can be implemented to manage specific behavior
dfu_initiated_callback - called when the DFU transaction is started, used to initiase the device + called when the DFU transaction is started, used to initialize the device
dfu_flush_callback called at the end of the DFU write after DFU manifestation, used to manage - the device when DFU transaction is closed + the device when the DFU transaction is closed
Host tools ----------
When U-Boot runs the dfu stack, the DFU host tools can be used -to send/receive firmwares on each configurated alternate. +to send/receive firmware images on each configured alternate.
For example dfu-util is a host side implementation of the DFU 1.1 specifications(http://dfu-util.sourceforge.net/) which works with U-Boot. @@ -409,8 +409,8 @@ Same example with MTD backend
Example 3
-firmware located in SD Card (mmc) and virtual partition on OTP and PMIC not -volatile memory +firmware located in SD Card (mmc) and virtual partition on OTP and PMIC +non-volatile memory
- alternate 1 (alt=1) for scard - alternate 2 (alt=2) for OTP (virtual)
--- base-commit: dffa6d0210f57793f1e4e1e209d91ca5642e4d05 change-id: 20240103-dfu-doc-typos-131cfec8eacc
Best regards,