March 2021 - U-Boot

reserved memory from devicetree definition
by jorge courett 05 Mar '21

05 Mar '21

Hi! Is there any way to use a reserved memory definition in the device tree to avoid that u-boot could use that SDRAM memory region? Or the only way is by compiler configuration? Thanks

3 3

[PATCH 1/1] doc: move README.dfu to HTML documentation
by Heinrich Schuchardt 05 Mar '21

05 Mar '21

Move README.dfu to doc/usage/dfu.rst and convert to reStructured text. In the long run this page should be split into two. One for the overview and one for the dfu command. UEFI capsule updates and dfutftp should be integrated into the overview page. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- MAINTAINERS | 1 + doc/README.dfu | 311 ---------------------------------- doc/usage/dfu.rst | 404 ++++++++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + 4 files changed, 406 insertions(+), 311 deletions(-) delete mode 100644 doc/README.dfu create mode 100644 doc/usage/dfu.rst diff --git a/MAINTAINERS b/MAINTAINERS index de499940e5..c6dd9bf838 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -670,6 +670,7 @@ F: common/dfu.c F: common/update.c F: common/usb_storage.c F: doc/api/dfu.rst +F: doc/usage/dfu.rst F: drivers/dfu/ F: drivers/usb/gadget/ F: include/dfu.h diff --git a/doc/README.dfu b/doc/README.dfu deleted file mode 100644 index eacd5bbfb4..0000000000 --- a/doc/README.dfu +++ /dev/null @@ -1,311 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0+ - -Device Firmware Upgrade (DFU) - -Overview: - - The Device Firmware Upgrade (DFU) allows to download and upload firmware - to/from U-Boot 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). - - U-Boot implements this DFU capability (CONFIG_DFU) with the command dfu - (cmd/dfu.c / CONFIG_CMD_DFU) based on: - - the DFU stack (common/dfu.c and common/spl/spl_dfu.c), based on the - USB DFU download gadget (drivers/usb/gadget/f_dfu.c) - - The access to mediums is done in DFU backends (driver/dfu) - - Today the supported DFU backends are: - - MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP / SCRIPT) - - NAND - - RAM - - SF (serial flash) - - MTD (all MTD device: NAND, SPI-NOR, SPI-NAND,...) - - virtual - - These DFU backends are also used by - - the dfutftp (see README.dfutftp) - - the thordown command (cmd/thordown.c and gadget/f_thor.c) - - The "virtual" backend is a generic DFU backend to support a board specific - target (for example OTP), only based on the weak functions: - - dfu_write_medium_virt - - dfu_get_medium_size_virt - - dfu_read_medium_virt - -Configuration Options: - CONFIG_DFU - CONFIG_DFU_OVER_USB - CONFIG_DFU_MMC - CONFIG_DFU_MTD - CONFIG_DFU_NAND - CONFIG_DFU_RAM - CONFIG_DFU_SF - CONFIG_DFU_SF_PART - CONFIG_DFU_TIMEOUT - CONFIG_DFU_VIRTUAL - CONFIG_CMD_DFU - -Environment variables: - the dfu command uses 3 environments variables: - "dfu_alt_info" : the DFU setting for the USB download gadget with a semicolon - separated string of information on each alternate: - dfu_alt_info="<alt1>;<alt2>;....;<altN>" - - when several devices are used, the format is: - - <interface> <dev>'='alternate list (';' separated) - - each interface is separated by '&' - dfu_alt_info=\ - "<interface1> <dev1>=<alt1>;....;<altN>&"\ - "<interface2> <dev2>=<altN+1>;....;<altM>&"\ - ...\ - "<interfaceI> <devI>=<altY+1>;....;<altZ>&" - - "dfu_bufsiz" : size of the DFU buffer, when absent, use - CONFIG_SYS_DFU_DATA_BUF_SIZE (8 MiB by default) - - "dfu_hash_algo" : name of the hash algorithm to use - -Commands: - dfu <USB_controller> [<interface> <dev>] list - 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 - 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, - the DFU operation will be aborted automatically after <timeout> - seconds of waiting remote to initiate DFU session. - - The possible values of <interface> are : - (with <USB controller> = 0 in the dfu command example) - - "mmc" (for eMMC and SD card) - cmd: dfu 0 mmc <dev> - each element in "dfu_alt_info" = - <name> raw <offset> <size> [mmcpart <num>] raw access to mmc device - <name> part <dev> <part_id> [mmcpart <num>] raw access to partition - <name> fat <dev> <part_id> [mmcpart <num>] file in FAT partition - <name> ext4 <dev> <part_id> [mmcpart <num>] file in EXT4 partition - <name> skip 0 0 ignore flashed data - <name> script 0 0 execute commands in shell - - with <partid> being the GPT or DOS partition index, - with <num> being the eMMC hardware partition number. - - A value of environment variable dfu_alt_info for eMMC could be: - - "u-boot raw 0x3e 0x800 mmcpart 1;bl2 raw 0x1e 0x1d mmcpart 1" - - A value of environment variable dfu_alt_info for SD card could be: - - "u-boot raw 0x80 0x800;uImage ext4 0 2" - - If don't want to flash given image file to storage, use "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, - which performs flashing in batch mode, where more than one file is - processed. - For example, if one makes a single tar file with support for the two - boards with u-boot-<board1>.bin and u-boot-<board2>.bin files, one - can use it to flash a proper u-boot image on both without a failure: - - "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: - --->8--- - setenv dfu_alt_info ... - setenv mbr_parts ... - mbr write ... - --->8--- - Please note that this means that user will be able to execute any - arbitrary commands just like in the u-boot's shell. - - "nand" (raw slc nand device) - cmd: dfu 0 nand <dev> - each element in "dfu_alt_info" = - <name> raw <offset> <size> raw access to mmc device - <name> part <dev> <part_id> raw acces to partition - <name> partubi <dev> <part_id> raw acces to ubi partition - - with <partid> is the MTD partition index - - "ram" - cmd: dfu 0 ram <dev> - (<dev> is not used for RAM target) - each element in "dfu_alt_info" = - <name> ram <offset> <size> raw access to ram - - "sf" (serial flash : NOR) - cmd: dfu 0 sf <dev> - each element in "dfu_alt_info" = - <name> raw <offset> <size> raw access to sf device - <name> part <dev> <part_id> raw acces to partition - <name> partubi <dev> <part_id> raw acces to ubi partition - - with <partid> is the MTD partition index - - "mtd" (all MTD device: NAND, SPI-NOR, SPI-NAND,...) - cmd: dfu 0 mtd <dev> - with <dev> the mtd identifier as defined in mtd command - (nand0, nor0, spi-nand0,...) - each element in "dfu_alt_info" = - <name> raw <offset> <size> raw access to mtd device - <name> part <dev> <part_id> raw acces to partition - <name> partubi <dev> <part_id> raw acces to ubi partition - - with <partid> is the MTD partition index - - "virt" - cmd: dfu 0 virt <dev> - each element in "dfu_alt_info" = - <name> - - <interface> and <dev> are absent: - the dfu command to use multiple devices - cmd: dfu 0 list - cmd: dfu 0 - "dfu_alt_info" variable provides the list of <interface> <dev> with - alternate list separated by '&' with the same format for each <alt> - mmc <dev>=<alt1>;....;<altN> - nand <dev>=<alt1>;....;<altN> - ram <dev>=<alt1>;....;<altN> - sf <dev>=<alt1>;....;<altN> - mtd <dev>=<alt1>;....;<altN> - virt <dev>=<alt1>;....;<altN> - -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 - - dfu_flush_callback : called at the end of the DFU write after DFU - manifestation, used to manage the device when - 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. - - 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. - -Usage: - Example 1: firmware located in eMMC or SD card, with: - - alternate 1 (alt=1) for SPL partition (GPT partition 1) - - alternate 2 (alt=2) for U-Boot partition (GPT partition 2) - - The U-Boot configuration is: - - U-Boot> env set dfu_alt_info "spl part 0 1;u-boot part 0 2" - - U-Boot> dfu 0 mmc 0 list - DFU alt settings list: - dev: eMMC alt: 0 name: spl layout: RAW_ADDR - dev: eMMC alt: 1 name: u-boot layout: RAW_ADDR - - Boot> dfu 0 mmc 0 - - On the Host side: - - list the available alternate setting: - - $> dfu-util -l - dfu-util 0.9 - - Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. - Copyright 2010-2016 Tormod Volden and Stefan Schmidt - This program is Free Software and has ABSOLUTELY NO WARRANTY - Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ - - Found DFU: [0483:5720] ver=0200, devnum=45, cfg=1, intf=0, path="3-1.3.1", \ - alt=1, name="u-boot", serial="003A00203438510D36383238" - Found DFU: [0483:5720] ver=0200, devnum=45, cfg=1, intf=0, path="3-1.3.1", \ - alt=0, name="spl", serial="003A00203438510D36383238" - - To download to U-Boot, use -D option - - $> dfu-util -a 0 -D u-boot-spl.bin - $> dfu-util -a 1 -D u-boot.bin - - To upload from U-Boot, use -U option - - $> dfu-util -a 0 -U u-boot-spl.bin - $> dfu-util -a 1 -U u-boot.bin - - To request a DFU detach and reset the USB connection: - $> dfu-util -a 0 -e -R - - - Example 2: firmware located in NOR (sf) and NAND, with: - - alternate 1 (alt=1) for SPL partition (NOR GPT partition 1) - - alternate 2 (alt=2) for U-Boot partition (NOR GPT partition 2) - - alternate 3 (alt=3) for U-Boot-env partition (NOR GPT partition 3) - - alternate 4 (alt=4) for UBI partition (NAND GPT partition 1) - - U-Boot> env set dfu_alt_info \ - "sf 0:0:10000000:0=spl part 0 1;u-boot part 0 2; \ - u-boot-env part 0 3&nand 0=UBI partubi 0,1" - - U-Boot> dfu 0 list - - DFU alt settings list: - dev: SF alt: 0 name: spl layout: RAW_ADDR - dev: SF alt: 1 name: ssbl layout: RAW_ADDR - dev: SF alt: 2 name: u-boot-env layout: RAW_ADDR - dev: NAND alt: 3 name: UBI layout: RAW_ADDR - - U-Boot> dfu 0 - - $> dfu-util -l - Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ - intf=0, alt=3, name="UBI", serial="002700333338511934383330" - Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ - intf=0, alt=2, name="u-boot-env", serial="002700333338511934383330" - Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ - intf=0, alt=1, name="u-boot", serial="002700333338511934383330" - Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ - intf=0, alt=0, name="spl", serial="002700333338511934383330" - - Same example with MTD backend - - U-Boot> env set dfu_alt_info \ - "mtd nor0=spl part 1;u-boot part 2;u-boot-env part 3&"\ - "mtd nand0=UBI partubi 1" - - U-Boot> dfu 0 list - using id 'nor0,0' - using id 'nor0,1' - using id 'nor0,2' - using id 'nand0,0' - DFU alt settings list: - dev: MTD alt: 0 name: spl layout: RAW_ADDR - dev: MTD alt: 1 name: u-boot layout: RAW_ADDR - dev: MTD alt: 2 name: u-boot-env layout: RAW_ADDR - dev: MTD alt: 3 name: UBI layout: RAW_ADDR - - Example 3: firmware located in SD Card (mmc) and virtual partition on - OTP and PMIC not volatile memory - - alternate 1 (alt=1) for scard - - alternate 2 (alt=2) for OTP (virtual) - - alternate 3 (alt=3) for PMIC NVM (virtual) - - U-Boot> env set dfu_alt_info \ - "mmc 0=sdcard raw 0 0x100000&"\ - "virt 0=otp" \ - "virt 1=pmic" - - U-Boot> dfu 0 list - DFU alt settings list: - dev: eMMC alt: 0 name: sdcard layout: RAW_ADDR - dev: VIRT alt: 1 name: otp layout: RAW_ADDR - dev: VIRT alt: 2 name: pmic layout: RAW_ADDR diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst new file mode 100644 index 0000000000..11c88072b8 --- /dev/null +++ b/doc/usage/dfu.rst @@ -0,0 +1,404 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Device Firmware Upgrade (DFU) +============================= + +Overview +-------- + +The Device Firmware Upgrade (DFU) allows to download and upload firmware +to/from U-Boot 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). + +U-Boot implements this DFU capability (CONFIG_DFU) with the command dfu +(cmd/dfu.c / CONFIG_CMD_DFU) based on: + +- the DFU stack (common/dfu.c and common/spl/spl_dfu.c), based on the + USB DFU download gadget (drivers/usb/gadget/f_dfu.c) +- The access to mediums is done in DFU backends (driver/dfu) + +Today the supported DFU backends are: + +- MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP / SCRIPT) +- NAND +- RAM +- SF (serial flash) +- MTD (all MTD device: NAND, SPI-NOR, SPI-NAND,...) +- virtual + +These DFU backends are also used by + +- the dfutftp (see README.dfutftp) +- the thordown command (cmd/thordown.c and gadget/f_thor.c) + +The "virtual" backend is a generic DFU backend to support a board specific +target (for example OTP), only based on the weak functions: + +- dfu_write_medium_virt +- dfu_get_medium_size_virt +- dfu_read_medium_virt + +Configuration Options +--------------------- + +The following configuration option are relevant for device firmware upgrade: + +* CONFIG_DFU +* CONFIG_DFU_OVER_USB +* CONFIG_DFU_MMC +* CONFIG_DFU_MTD +* CONFIG_DFU_NAND +* CONFIG_DFU_RAM +* CONFIG_DFU_SF +* CONFIG_DFU_SF_PART +* CONFIG_DFU_TIMEOUT +* CONFIG_DFU_VIRTUAL +* CONFIG_CMD_DFU + +Environment variables +--------------------- + +The dfu command uses 3 environments variables: + +dfu_alt_info + The DFU setting for the USB download gadget with a semicolon separated + string of information on each alternate:: + + dfu_alt_info="<alt1>;<alt2>;....;<altN>" + + When several devices are used, the format is: + + - <interface> <dev>'='alternate list (';' separated) + - each interface is separated by '&':: + + dfu_alt_info=\ + "<interface1> <dev1>=<alt1>;....;<altN>&"\ + "<interface2> <dev2>=<altN+1>;....;<altM>&"\ + ...\ + "<interfaceI> <devI>=<altY+1>;....;<altZ>&" + +dfu_bufsiz + size of the DFU buffer, when absent, defaults to + CONFIG_SYS_DFU_DATA_BUF_SIZE (8 MiB by default) + +dfu_hash_algo + name of the hash algorithm to use + +Commands +-------- + +dfu <USB_controller> [<interface> <dev>] list + 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 + 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, + the DFU operation will be aborted automatically after <timeout> + seconds of waiting remote to initiate DFU session. + +The possible values of <interface> are (with <USB controller> = 0 in the dfu +command example) + +mmc + for eMMC and SD card:: + + dfu 0 mmc <dev> + + each element in *dfu_alt_info* being + + * <name> raw <offset> <size> [mmcpart <num>] raw access to mmc device + * <name> part <dev> <part_id> [mmcpart <num>] raw access to partition + * <name> fat <dev> <part_id> [mmcpart <num>] file in FAT partition + * <name> ext4 <dev> <part_id> [mmcpart <num>] file in EXT4 partition + * <name> skip 0 0 ignore flashed data + * <name> script 0 0 execute commands in shell + + with + + partid + being the GPT or DOS partition index, + num + being the eMMC hardware partition number. + + A value of environment variable *dfu_alt_info* for eMMC could be:: + + u-boot raw 0x3e 0x800 mmcpart 1;bl2 raw 0x1e 0x1d mmcpart 1 + + A value of environment variable *dfu_alt_info* for SD card could be:: + + u-boot raw 0x80 0x800;uImage ext4 0 2 + + If don't want to flash given image file to storage, use "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, + which performs flashing in batch mode, where more than one file is + processed. + + For example, if one makes a single tar file with support for the two + boards with u-boot-<board1>.bin and u-boot-<board2>.bin files, one + can use it to flash a proper u-boot image on both without a failure:: + + 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:: + + setenv dfu_alt_info ... + setenv mbr_parts ... + mbr write ... + + Please note that this means that user will be able to execute any + arbitrary commands just like in the u-boot's shell. + +nand + raw slc nand device:: + + dfu 0 nand <dev> + + each element in *dfu_alt_info* being either of + + * <name> raw <offset> <size> raw access to mmc device + * <name> part <dev> <part_id> raw acces to partition + * <name> partubi <dev> <part_id> raw acces to ubi partition + + with + + partid + is the MTD partition index + +ram + raw access to ram:: + + dfu 0 ram <dev> + + dev + is not used for RAM target + + each element in *dfu_alt_info* being:: + + <name> ram <offset> <size> raw access to ram + +sf + serial flash : NOR:: + + cmd: dfu 0 sf <dev> + + each element in *dfu_alt_info* being either of: + + * <name> raw <offset> <size> raw access to sf device + * <name> part <dev> <part_id> raw acces to partition + * <name> partubi <dev> <part_id> raw acces to ubi partition + + with + + partid + is the MTD partition index + +mtd + all MTD device: NAND, SPI-NOR, SPI-NAND,...:: + + cmd: dfu 0 mtd <dev> + + with + + dev + the mtd identifier as defined in mtd command + (nand0, nor0, spi-nand0,...) + + each element in *dfu_alt_info* being either of: + + * <name> raw <offset> <size> forraw access to mtd device + * <name> part <dev> <part_id> for raw acces to partition + * <name> partubi <dev> <part_id> for raw acces to ubi partition + + with + + partid + is the MTD partition index + +virt + virtual flash back end for DFU + + :: + + cmd: dfu 0 virt <dev> + + each element in *dfu_alt_info* being: + + * <name> + +<interface> and <dev> are absent, the dfu command to use multiple devices:: + + cmd: dfu 0 list + cmd: dfu 0 + +*dfu_alt_info* variable provides the list of <interface> <dev> with +alternate list separated by '&' with the same format for each <alt>:: + + mmc <dev>=<alt1>;....;<altN> + nand <dev>=<alt1>;....;<altN> + ram <dev>=<alt1>;....;<altN> + sf <dev>=<alt1>;....;<altN> + mtd <dev>=<alt1>;....;<altN> + virt <dev>=<alt1>;....;<altN> + +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 + +dfu_flush_callback + called at the end of the DFU write after DFU manifestation, used to manage + the device when 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. + +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. + +Usage +----- + +Example 1: firmware located in eMMC or SD card, with: + +- alternate 1 (alt=1) for SPL partition (GPT partition 1) +- alternate 2 (alt=2) for U-Boot partition (GPT partition 2) + +The U-Boot configuration is:: + + U-Boot> env set dfu_alt_info "spl part 0 1;u-boot part 0 2" + + U-Boot> dfu 0 mmc 0 list + DFU alt settings list: + dev: eMMC alt: 0 name: spl layout: RAW_ADDR + dev: eMMC alt: 1 name: u-boot layout: RAW_ADDR + + Boot> dfu 0 mmc 0 + +On the Host side: + +list the available alternate setting:: + + $> dfu-util -l + dfu-util 0.9 + + Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. + Copyright 2010-2016 Tormod Volden and Stefan Schmidt + This program is Free Software and has ABSOLUTELY NO WARRANTY + Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ + + Found DFU: [0483:5720] ver=0200, devnum=45, cfg=1, intf=0, path="3-1.3.1", \ + alt=1, name="u-boot", serial="003A00203438510D36383238" + Found DFU: [0483:5720] ver=0200, devnum=45, cfg=1, intf=0, path="3-1.3.1", \ + alt=0, name="spl", serial="003A00203438510D36383238" + + To download to U-Boot, use -D option + + $> dfu-util -a 0 -D u-boot-spl.bin + $> dfu-util -a 1 -D u-boot.bin + + To upload from U-Boot, use -U option + + $> dfu-util -a 0 -U u-boot-spl.bin + $> dfu-util -a 1 -U u-boot.bin + + To request a DFU detach and reset the USB connection: + $> dfu-util -a 0 -e -R + + +Example 2: firmware located in NOR (sf) and NAND, with: + +- alternate 1 (alt=1) for SPL partition (NOR GPT partition 1) +- alternate 2 (alt=2) for U-Boot partition (NOR GPT partition 2) +- alternate 3 (alt=3) for U-Boot-env partition (NOR GPT partition 3) +- alternate 4 (alt=4) for UBI partition (NAND GPT partition 1) + +:: + + U-Boot> env set dfu_alt_info \ + "sf 0:0:10000000:0=spl part 0 1;u-boot part 0 2; \ + u-boot-env part 0 3&nand 0=UBI partubi 0,1" + + U-Boot> dfu 0 list + + DFU alt settings list: + dev: SF alt: 0 name: spl layout: RAW_ADDR + dev: SF alt: 1 name: ssbl layout: RAW_ADDR + dev: SF alt: 2 name: u-boot-env layout: RAW_ADDR + dev: NAND alt: 3 name: UBI layout: RAW_ADDR + + U-Boot> dfu 0 + +:: + + $> dfu-util -l + Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ + intf=0, alt=3, name="UBI", serial="002700333338511934383330" + Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ + intf=0, alt=2, name="u-boot-env", serial="002700333338511934383330" + Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ + intf=0, alt=1, name="u-boot", serial="002700333338511934383330" + Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\ + intf=0, alt=0, name="spl", serial="002700333338511934383330" + +Same example with MTD backend + +:: + + U-Boot> env set dfu_alt_info \ + "mtd nor0=spl part 1;u-boot part 2;u-boot-env part 3&"\ + "mtd nand0=UBI partubi 1" + + U-Boot> dfu 0 list + using id 'nor0,0' + using id 'nor0,1' + using id 'nor0,2' + using id 'nand0,0' + DFU alt settings list: + dev: MTD alt: 0 name: spl layout: RAW_ADDR + dev: MTD alt: 1 name: u-boot layout: RAW_ADDR + dev: MTD alt: 2 name: u-boot-env layout: RAW_ADDR + dev: MTD alt: 3 name: UBI layout: RAW_ADDR + +Example 3 + +firmware located in SD Card (mmc) and virtual partition on OTP and PMIC not +volatile memory + +- alternate 1 (alt=1) for scard +- alternate 2 (alt=2) for OTP (virtual) +- alternate 3 (alt=3) for PMIC NVM (virtual) + +:: + + U-Boot> env set dfu_alt_info \ + "mmc 0=sdcard raw 0 0x100000&"\ + "virt 0=otp" \ + "virt 1=pmic" + +:: + + U-Boot> dfu 0 list + DFU alt settings list: + dev: eMMC alt: 0 name: sdcard layout: RAW_ADDR + dev: VIRT alt: 1 name: otp layout: RAW_ADDR + dev: VIRT alt: 2 name: pmic layout: RAW_ADDR diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 09372d4a96..310e8841fa 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -4,6 +4,7 @@ Use U-Boot .. toctree:: :maxdepth: 1 + dfu fdt_overlays netconsole partitions -- 2.30.1

1 0

[PATCH 1/1] dfu: newline after updating
by Heinrich Schuchardt 05 Mar '21

05 Mar '21

Currently output of dfu commands ends on a line with leading hash signs ('#'). The succeeding output should be placed on a new line. After writing updates via dfu print a new line. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- drivers/dfu/dfu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c index a298c2c439..2a0813fde8 100644 --- a/drivers/dfu/dfu.c +++ b/drivers/dfu/dfu.c @@ -718,6 +718,7 @@ int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int size) ret = dfu_flush(dfu, NULL, 0, i); if (ret) pr_err("DFU flush failed!"); + puts("\n"); return ret; } -- 2.27.0

1 0

fec_mxc send error while porting fec_mxc driver
by Shengtuo Hu 05 Mar '21

05 Mar '21

Hi, I was recently porting fec_mxc driver in u-boot to another platform. The initialization succeeds. However, invoking fec_send always throws the following error: > fec_send: status 0x8c00 index 0 ret -22 It looks like that the READY bit of the TX buffer descriptor is not cleared, but I still do not know why this happens. Does anyone have any clues about this issue? Thanks! Here are some register values of the ethernet device when the error happens: Ethernet state (ecntrl): 0xf0000102 (Active) TX state (x_des_active): Inactive (no FEC_X_DES_ACTIVE_TDAR bit) RX state (r_des_active): Inactive (no FEC_R_DES_ACTIVE_RDAR bit) TX control (x_cntrl): 0x00000004 RX control (r_cntrl): 0x05f20064 RX desc base (erdsr): 0x4e07fd40 (size: 0x600) TX desc base (etdsr): 0x4e07fdc0 Enabled events (imask): 0x00000000 Pending events (ievent): 0x00000000 Best, Shengtuo Hu

1 0

Rpi boots with boot.scr and does not with extlinux.conf
by Laurentiu-Cristian Duca 05 Mar '21

05 Mar '21

Hello, I am new to u-boot and I am facing the following problem. I use U-Boot 2021.04-rc3-00073-g6a026e5649 in a raspberry pi zero w board. It boots linux when using boot.scr made by using the following boot.cmd " fdt addr ${fdt_addr} && fdt get value bootargs /chosen bootargs fatload mmc 0:1 ${kernel_addr_r} uImage bootm ${kernel_addr_r} - ${fdt_addr} " cmdline.txt is: root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200 See boot messages [1] But if I delete boot.scr and use the following extlinux.conf " label rpi0w-buildroot kernel uImage devicetree bcm2708-rpi-0-w.dtb append root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200 " the boot stops at "Starting kernel ...". See boot messages [2]. Any ideas why it works with boot.scr and it does not with extlinux.conf? Thank you, L-C [1] scanning mmc 0:1... Found U-Boot script /boot.scr 213 bytes read in 2 ms (103.5 KiB/s) ## Executing script at 02400000 4688408 bytes read in 201 ms (22.2 MiB/s) ## Booting kernel from Legacy Image at 00080000 ... Image Name: Linux kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4688344 Bytes = 4.5 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 19bea100 Booting using the fdt blob at 0x19bea100 Loading Kernel Image Using Device Tree in place at 19bea100, end 19bf2f9b Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.95 (laur@laurPC100) (gcc version 7.4.0 (Buildroot 2019.02)) #3 Mon Dec 2 18:29:57 EET 2019 [ 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1 [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 8 MiB at 0x19000000 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 104545 [ 0.000000] Kernel command line: 8250.nr_uarts=1 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:AA:52:0F vc_mem.mem_ba0 [2] Scanning mmc 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 146 bytes read in 4 ms (35.2 KiB/s) 1: rpi0w-buildroot Retrieving file: /boot/extlinux/uImage 4688408 bytes read in 202 ms (22.1 MiB/s) append: root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200 Retrieving file: /boot/extlinux/bcm2708-rpi-0-w.dtb 23315 bytes read in 5 ms (4.4 MiB/s) ## Booting kernel from Legacy Image at 00080000 ... Image Name: Linux kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4688344 Bytes = 4.5 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02600000 Booting using the fdt blob at 0x2600000 Loading Kernel Image Using Device Tree in place at 02600000, end 02608b12 Starting kernel ...

1 1

[v5 0/7] Add Vendor Authorized Boot (VAB) support
by Siew Chin Lim 05 Mar '21

05 Mar '21

This is the 5th version of patchset to add Vendor Authorized Boot (VAB) support for Intel Agilex SoC device. Vendor Authorized Boot is a security feature for authenticating the images such as U-Boot, ARM trusted Firmware, Linux kernel, device tree blob and etc loaded from FIT. After those images are loaded from FIT, the VAB certificate and signature block appended at the end of each image are sent to Secure Device Manager (SDM) for authentication. U-Boot will validate the SHA384 of the image against the SHA384 hash stored in the VAB certificate before sending the image to SDM for authentication. Patch status: Have changes: Patch 2 Other patches unchanged. Detail changelog can find in commit message. v4->v5: -------- Patch 2: - in arch/arm/mach-socfpga/board.c - Move #if IS_ENABLED(CONFIG_SOCFPGA_SECURE_VAB_AUTH) inside board_fit_image_post_process function. - Move #if IS_ENABLED(CONFIG_SPL_BUILD) outside board_prep_linux function. History: -------- [v1]: https://patchwork.ozlabs.org/project/uboot/cover/20201110070505.26935-1-ell… [v2]: https://patchwork.ozlabs.org/project/uboot/cover/20210107100337.45293-1-ell… [v3]: https://patchwork.ozlabs.org/project/uboot/cover/20210205105212.16510-1-ell… [v4]: https://patchwork.ozlabs.org/project/uboot/cover/20210226165733.7591-1-elly… Dalon Westergreen (1): Makefile: socfpga: Add target to generate hex output for combined spl and dtb Siew Chin Lim (6): arm: socfpga: Move Stratix10 and Agilex to use TARGET_SOCFPGA_SOC64 arm: socfpga: soc64: Support Vendor Authorized Boot (VAB) arm: socfpga: cmd: Support 'vab' command arm: socfpga: dts: soc64: Update filename in binman node of FIT image with VAB support configs: socfpga: soc64: Move CONFIG_BOOTCOMMAND to defconfig configs: socfpga: Add defconfig for Agilex with VAB support Makefile | 11 +- arch/arm/Kconfig | 6 +- arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 22 +++ arch/arm/mach-socfpga/Kconfig | 20 +++ arch/arm/mach-socfpga/Makefile | 3 + arch/arm/mach-socfpga/board.c | 45 ++++- arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 1 + arch/arm/mach-socfpga/include/mach/reset_manager.h | 3 +- arch/arm/mach-socfpga/include/mach/secure_vab.h | 63 +++++++ .../arm/mach-socfpga/include/mach/system_manager.h | 3 +- arch/arm/mach-socfpga/secure_vab.c | 186 +++++++++++++++++++++ arch/arm/mach-socfpga/vab.c | 34 ++++ common/Kconfig.boot | 2 +- configs/socfpga_agilex_atf_defconfig | 2 + configs/socfpga_agilex_defconfig | 2 + ..._atf_defconfig => socfpga_agilex_vab_defconfig} | 4 + configs/socfpga_stratix10_atf_defconfig | 2 + configs/socfpga_stratix10_defconfig | 2 + drivers/ddr/altera/Kconfig | 6 +- drivers/fpga/Kconfig | 2 +- drivers/sysreset/Kconfig | 2 +- include/configs/socfpga_soc64_common.h | 10 +- scripts/Makefile.spl | 7 + 23 files changed, 408 insertions(+), 30 deletions(-) create mode 100644 arch/arm/mach-socfpga/include/mach/secure_vab.h create mode 100644 arch/arm/mach-socfpga/secure_vab.c create mode 100644 arch/arm/mach-socfpga/vab.c copy configs/{socfpga_agilex_atf_defconfig => socfpga_agilex_vab_defconfig} (91%) -- 2.13.0

2 8

[PATCHv2] arm64: gic-v3-its: Clear the Pending table before enabling LPIs
by Zhiqiang Hou 05 Mar '21

05 Mar '21

From: Hou Zhiqiang <Zhiqiang.Hou(a)nxp.com> The GICv3 RM requires "The first 1KB of memory for the LPI Pending tables must contain only zeros on initial allocation, and this must be visible to the Redistributors, or else the effect is UNPREDICTABLE". And as the following statement, we here clear the whole Pending tables instead of the first 1KB. "An LPI Pending table that contains only zeros, including in the first 1KB, indicates that there are no pending LPIs. The first 1KB of the LPI Pending table is IMPLEMENTATION DEFINED. However, if the first 1KB of the LPI Pending table and the rest of the table contain only zeros, this must indicate that there are no pending LPIs." And there isn't any pending LPI under U-Boot, so it's unnecessary to load the contents of the Pending table during the enablement, then set the GICR_PENDBASER.PTZ flag. Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou(a)nxp.com> --- V2: - Clear the Pending tables using virtual address. - Correct some typos in the change log. arch/arm/lib/gic-v3-its.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/arm/lib/gic-v3-its.c b/arch/arm/lib/gic-v3-its.c index f5a921b3d1..2dadc48a50 100644 --- a/arch/arm/lib/gic-v3-its.c +++ b/arch/arm/lib/gic-v3-its.c @@ -3,6 +3,7 @@ * Copyright 2019 Broadcom. */ #include <common.h> +#include <cpu_func.h> #include <dm.h> #include <regmap.h> #include <syscon.h> @@ -108,6 +109,8 @@ int gic_lpi_tables_init(void) int i; u64 redist_lpi_base; u64 pend_base; + ulong pend_tab_total_sz; + void *pend_tab_va; if (gic_v3_its_get_gic_addr(&priv)) return -EINVAL; @@ -160,7 +163,12 @@ int gic_lpi_tables_init(void) } } - redist_lpi_base = priv.lpi_base + LPI_PROPBASE_SZ; + pend_tab_total_sz = priv.num_redist * LPI_PENDBASE_SZ; + pend_tab_va = map_physmem(redist_lpi_base, pend_tab_total_sz, + MAP_NOCACHE); + memset(pend_tab_va, 0, pend_tab_total_sz); + flush_cache((ulong)pend_tab_va, pend_tab_total_sz); + unmap_physmem(pend_tab_va, MAP_NOCACHE); pend_base = priv.gicr_base + GICR_PENDBASER; for (i = 0; i < priv.num_redist; i++) { @@ -168,7 +176,8 @@ int gic_lpi_tables_init(void) val = ((redist_lpi_base + (i * LPI_PENDBASE_SZ)) | GICR_PENDBASER_INNERSHAREABLE | - GICR_PENDBASER_RAWAWB); + GICR_PENDBASER_RAWAWB | + GICR_PENDBASER_PTZ); writeq(val, (uintptr_t)(pend_base + offset)); tmp = readq((uintptr_t)(pend_base + offset)); -- 2.17.1

3 2

[PATCH 1/3] rtc: ds1307: Add ds1339 compatible
by Chris Packham 05 Mar '21

05 Mar '21

As far as u-boot is concerned the ds1339 is compatible with the other devices supported by the ds1307 driver. The Linux driver does expose some additional functionality but as far as u-boot is concerned just adding the compatible string is enough. Signed-off-by: Chris Packham <judge.packham(a)gmail.com> --- drivers/rtc/ds1307.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/rtc/ds1307.c b/drivers/rtc/ds1307.c index 17344d4d4ff2..2015ce9bbcd4 100644 --- a/drivers/rtc/ds1307.c +++ b/drivers/rtc/ds1307.c @@ -23,6 +23,7 @@ enum ds_type { ds_1307, ds_1337, + ds_1339, ds_1340, m41t11, mcp794xx, @@ -344,6 +345,7 @@ static const struct rtc_ops ds1307_rtc_ops = { static const struct udevice_id ds1307_rtc_ids[] = { { .compatible = "dallas,ds1307", .data = ds_1307 }, { .compatible = "dallas,ds1337", .data = ds_1337 }, + { .compatible = "dallas,ds1339", .data = ds_1339 }, { .compatible = "dallas,ds1340", .data = ds_1340 }, { .compatible = "microchip,mcp7941x", .data = mcp794xx }, { .compatible = "st,m41t11", .data = m41t11 }, -- 2.30.1

2 3

[PATCH] Azure/GitLab: Use buildman -T0 for binman, etc, test
by Tom Rini 05 Mar '21

05 Mar '21

There are times where buildman seems to get stuck in this job when in CI. Forcing single-threaded here allows us to complete and move on. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- .azure-pipelines.yml | 2 +- .gitlab-ci.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 013b170bf251..506e0c0618e5 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -148,7 +148,7 @@ jobs: export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl export PYTHONPATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt export PATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH} - ./tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w sandbox_spl + ./tools/buildman/buildman -T0 -o ${UBOOT_TRAVIS_BUILD_DIR} -w sandbox_spl ./tools/binman/binman --toolpath ${UBOOT_TRAVIS_BUILD_DIR}/tools test ./tools/buildman/buildman -t ./tools/dtoc/dtoc -t diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 65996a66f0b2..9e0ef8bca9a7 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -170,7 +170,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites: export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl; export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt"; export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}"; - ./tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w sandbox_spl; + ./tools/buildman/buildman -T0 -o ${UBOOT_TRAVIS_BUILD_DIR} -w sandbox_spl; ./tools/binman/binman --toolpath ${UBOOT_TRAVIS_BUILD_DIR}/tools test; ./tools/buildman/buildman -t; ./tools/dtoc/dtoc -t; -- 2.17.1

3 4

[PATCH 0/4] Remove addr parameter from reset_cpu()
by Harald Seiler 05 Mar '21

05 Mar '21

Hi, this is something I had on my mind for a longer time but never got around to actually do until now ... A while back, while working on the patchset that led to commit c5635a032a4b ("ARM: imx8m: Don't use the addr parameter of reset_cpu()"), I noticed that the `addr` parameter of reset_cpu() seems to not actually hold any meaningful value. All call-sites in the current tree just pass 0 and the vast majority of reset_cpu() implementations actually ignore the parameter. I dug a bit deeper to find out why this `addr` parameter exists in the first place and found out that it's mostly a legacy artifact: Historically, the reset_cpu() function had this `addr` parameter to pass an address of a reset vector location, where the CPU should reset to. The times where this was used are long gone and the only trace it left is some (dead) code for the NDS32 arch. The `addr` parameter lived on and it looks like it was sometimes used as a way to indicate different types of resets (e.g. COLD vs WARM). Today, however, reset_cpu() is only ever called with `addr` 0 in the mainline tree and as such, any code that gives a meaning to the `addr` value will only ever follow the `addr == 0` branch. This is probably not what the authors intended and as it seems quite unobvious to me, I think the best way forward is to remove the `addr` parameter entirely. This removes any ambiguity in the "contract" of reset_cpu() and thus hopefully prevents more code being added which wrongly assumes that the parameter can be used for any meaningful purpose. Instead, code which wants to properly support multiple reset types needs to be implemented as a sysreset driver. I did this API change via a coccinelle patch, see "reset: Remove addr parameter from reset_cpu()" for details. I also ran buildman for all boards I could, to verify that everything still compiles. One notable exception is NDS32 because I couldn't get the compiler to work there ... Regards, Harald Harald Seiler (4): nds32: Remove dead reset_cpu() implementation board: ns3: Remove superfluous reset logic Revert "lpc32xx: cpu: add support for soft reset" reset: Remove addr parameter from reset_cpu() arch/arc/lib/reset.c | 4 ++-- arch/arm/cpu/arm920t/ep93xx/cpu.c | 2 +- arch/arm/cpu/arm920t/imx/timer.c | 2 +- arch/arm/cpu/arm926ejs/armada100/timer.c | 2 +- arch/arm/cpu/arm926ejs/mx25/reset.c | 2 +- arch/arm/cpu/arm926ejs/mx27/reset.c | 2 +- arch/arm/cpu/arm926ejs/mxs/mxs.c | 4 ++-- arch/arm/cpu/arm926ejs/spear/reset.c | 2 +- arch/arm/cpu/arm946es/cpu.c | 2 +- arch/arm/cpu/armv7/bcm281xx/reset.c | 2 +- arch/arm/cpu/armv7/bcmcygnus/reset.c | 2 +- arch/arm/cpu/armv7/bcmnsp/reset.c | 2 +- arch/arm/cpu/armv7/ls102xa/cpu.c | 2 +- arch/arm/cpu/armv7/s5p4418/cpu.c | 2 +- arch/arm/cpu/armv7/stv0991/reset.c | 2 +- arch/arm/cpu/armv7m/cpu.c | 2 +- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 4 ++-- arch/arm/cpu/armv8/s32v234/generic.c | 2 +- arch/arm/cpu/pxa/pxa2xx.c | 4 ++-- arch/arm/cpu/sa1100/cpu.c | 2 +- arch/arm/lib/interrupts.c | 2 +- arch/arm/lib/interrupts_m.c | 2 +- arch/arm/lib/reset.c | 2 +- arch/arm/mach-at91/arm920t/reset.c | 2 +- arch/arm/mach-at91/arm926ejs/reset.c | 2 +- arch/arm/mach-at91/armv7/reset.c | 2 +- arch/arm/mach-bcm283x/reset.c | 2 +- arch/arm/mach-davinci/reset.c | 2 +- arch/arm/mach-exynos/soc.c | 2 +- arch/arm/mach-imx/imx8m/soc.c | 2 +- arch/arm/mach-imx/mx7ulp/soc.c | 2 +- arch/arm/mach-k3/common.c | 2 +- arch/arm/mach-keystone/ddr3.c | 4 ++-- arch/arm/mach-keystone/init.c | 2 +- arch/arm/mach-kirkwood/cpu.c | 2 +- arch/arm/mach-lpc32xx/cpu.c | 23 +++++------------- arch/arm/mach-mediatek/mt7622/init.c | 2 +- arch/arm/mach-mediatek/mt8512/init.c | 2 +- arch/arm/mach-mediatek/mt8516/init.c | 2 +- arch/arm/mach-mediatek/mt8518/init.c | 2 +- arch/arm/mach-meson/board-common.c | 4 ++-- arch/arm/mach-mvebu/armada3700/cpu.c | 2 +- arch/arm/mach-mvebu/armada8k/cpu.c | 2 +- arch/arm/mach-mvebu/cpu.c | 2 +- arch/arm/mach-octeontx/cpu.c | 2 +- arch/arm/mach-octeontx2/cpu.c | 2 +- arch/arm/mach-omap2/omap5/hwinit.c | 2 +- arch/arm/mach-omap2/reset.c | 2 +- arch/arm/mach-orion5x/cpu.c | 2 +- arch/arm/mach-owl/soc.c | 2 +- .../mach-socfpga/include/mach/reset_manager.h | 2 +- arch/arm/mach-sunxi/board.c | 2 +- arch/arm/mach-tegra/cmd_enterrcm.c | 2 +- arch/arm/mach-tegra/pmc.c | 2 +- arch/arm/mach-uniphier/arm32/psci.c | 2 +- arch/arm/mach-uniphier/reset.c | 2 +- arch/arm/mach-zynq/cpu.c | 2 +- arch/arm/mach-zynqmp-r5/cpu.c | 2 +- arch/nds32/cpu/n1213/ag101/cpu.c | 2 +- arch/nds32/cpu/n1213/start.S | 22 ----------------- arch/nds32/lib/interrupts.c | 2 +- arch/sandbox/cpu/sdl.c | 4 ++-- arch/sh/cpu/sh4/cpu.c | 2 +- arch/sh/cpu/sh4/watchdog.c | 2 +- arch/x86/cpu/ivybridge/cpu.c | 2 +- board/BuR/brppt2/board.c | 2 +- board/abilis/tb100/tb100.c | 2 +- .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 2 +- board/armltd/total_compute/total_compute.c | 2 +- board/armltd/vexpress/vexpress_common.c | 2 +- board/armltd/vexpress64/vexpress64.c | 2 +- .../armadillo-800eva/armadillo-800eva.c | 2 +- board/beacon/beacon-rzg2m/beacon-rzg2m.c | 2 +- board/bosch/shc/board.c | 2 +- board/broadcom/bcmns2/northstar2.c | 2 +- board/broadcom/bcmns3/ns3.c | 24 +++---------------- board/broadcom/bcmstb/bcmstb.c | 2 +- board/cavium/thunderx/thunderx.c | 2 +- board/compulab/cm_t335/spl.c | 2 +- board/cortina/presidio-asic/presidio.c | 2 +- board/freescale/imx8qm_mek/imx8qm_mek.c | 2 +- board/freescale/imx8qxp_mek/imx8qxp_mek.c | 2 +- board/freescale/mx6memcal/spl.c | 2 +- board/ge/b1x5v2/spl.c | 2 +- board/highbank/highbank.c | 2 +- board/hisilicon/hikey/hikey.c | 2 +- board/hisilicon/hikey960/hikey960.c | 2 +- board/hisilicon/poplar/poplar.c | 2 +- board/kmc/kzm9g/kzm9g.c | 2 +- board/liebherr/display5/spl.c | 2 +- board/phytium/durian/durian.c | 2 +- .../dragonboard410c/dragonboard410c.c | 2 +- .../dragonboard820c/dragonboard820c.c | 2 +- board/renesas/alt/alt.c | 2 +- board/renesas/alt/alt_spl.c | 2 +- board/renesas/blanche/blanche.c | 2 +- board/renesas/condor/condor.c | 2 +- board/renesas/draak/draak.c | 2 +- board/renesas/eagle/eagle.c | 2 +- board/renesas/ebisu/ebisu.c | 2 +- board/renesas/gose/gose.c | 2 +- board/renesas/gose/gose_spl.c | 2 +- board/renesas/grpeach/grpeach.c | 2 +- board/renesas/koelsch/koelsch.c | 2 +- board/renesas/koelsch/koelsch_spl.c | 2 +- board/renesas/lager/lager.c | 2 +- board/renesas/lager/lager_spl.c | 2 +- board/renesas/porter/porter.c | 2 +- board/renesas/porter/porter_spl.c | 2 +- board/renesas/rcar-common/gen3-spl.c | 2 +- board/renesas/salvator-x/salvator-x.c | 2 +- board/renesas/silk/silk.c | 2 +- board/renesas/silk/silk_spl.c | 2 +- board/renesas/stout/cpld.c | 2 +- board/renesas/stout/stout_spl.c | 2 +- board/siemens/capricorn/board.c | 2 +- board/synopsys/emsdp/emsdp.c | 2 +- board/synopsys/iot_devkit/iot_devkit.c | 2 +- board/technexion/pico-imx6ul/spl.c | 2 +- board/technexion/pico-imx7d/spl.c | 2 +- board/toradex/apalis-imx8/apalis-imx8.c | 2 +- board/toradex/apalis-imx8x/apalis-imx8x.c | 2 +- board/toradex/apalis_imx6/apalis_imx6.c | 2 +- board/toradex/colibri-imx8x/colibri-imx8x.c | 2 +- board/toradex/colibri_imx6/colibri_imx6.c | 2 +- board/toradex/colibri_imx7/colibri_imx7.c | 2 +- board/xen/xenguest_arm64/xenguest_arm64.c | 2 +- board/xilinx/versal/board.c | 2 +- board/xilinx/zynqmp/zynqmp.c | 2 +- cmd/tpm_test.c | 2 +- drivers/sysreset/sysreset-uclass.c | 2 +- drivers/watchdog/imx_watchdog.c | 2 +- drivers/watchdog/ulp_wdog.c | 2 +- include/cpu_func.h | 4 ++-- include/sysreset.h | 2 +- 135 files changed, 149 insertions(+), 200 deletions(-) -- 2.26.2

4 16