Merge branch 'next'

Signed-off-by: Tom Rini <trini@konsulko.com>

8 files changed, 410 insertions, 11 deletions

diff --git a/doc/board/allwinner/index.rst b/doc/board/allwinner/index.rst
new file mode 100644
index 0000000000..7352ccd5c0
--- /dev/null
+++ b/doc/board/allwinner/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Allwinner (sunxi) boards
+========================
+
+.. toctree::
+   :maxdepth: 2
+
+   sunxi
diff --git a/doc/board/allwinner/sunxi.rst b/doc/board/allwinner/sunxi.rst
new file mode 100644
index 0000000000..797222d8d3
--- /dev/null
+++ b/doc/board/allwinner/sunxi.rst
@@ -0,0 +1,319 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2021 Arm Ltd.
+
+Allwinner SoC based boards
+==========================
+For boards using an Allwinner ARM based SoC ("sunxi"), the U-Boot build
+system generates a single integrated image file: ``u-boot-sunxi-with-spl.bin.``
+This file can be used on SD cards, eMMC devices, SPI flash and for the
+USB-OTG based boot method (FEL). To build this file:
+
+* For 64-bit SoCs, build Trusted Firmware (TF-A, formerly known as ATF) first,
+  you will need its ``bl31.bin``. See below for more details.
+* Optionally on 64-bit SoCs, build the `crust`_ management processor firmware,
+  you will need its ``scp.bin``. See below for more details.
+* Build U-Boot::
+
+  $ export BL31=/path/to/bl31.bin		# required for 64-bit SoCs
+  $ export SCP=/path/to/scp.bin			# optional for some 64-bit SoCs
+  $ make <yourboardname>_defconfig
+  $ make
+* Transfer to an (micro)SD card (see below for more details)::
+
+  $ sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=8k seek=1
+* Boot and enjoy!
+
+.. note::
+  The traditional SD card location the Allwinner BootROM loads from is 8KB
+  (sector 16). This works fine with the old MBR partitioning scheme, which most
+  SD cards come formatted with. However this is in the middle of a potential
+  GPT partition table, which will become invalid in this step. Newer SoCs
+  (starting with the H3 from late 2014) also support booting from 128KB, which
+  is beyond even a GPT and thus a safer location.
+
+For more details, and alternative boot locations or installations, see below.
+
+Building Arm Trusted Firmware (TF-A)
+------------------------------------
+Boards using a 64-bit Soc (A64, H5, H6, H616, R329) require the BL31 stage of
+the `Arm Trusted Firmware-A`_ firmware. This provides the reference
+implementation of secure software for Armv8-A, offering PSCI and SMCCC
+services. Allwinner support is fully mainlined. To build bl31.bin::
+
+  $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
+  $ cd trusted-firmware-a
+  $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_a64 DEBUG=1
+  $ export BL31=$(pwd)/build/sun50i_a64/debug/bl31.bin
+
+The target platform (``PLAT=``) for A64 and H5 SoCs is sun50i_a64, for the H6
+sun50i_h6, for the H616 sun50i_h616, and for the R329 sun50i_r329. Use::
+
+  $ find plat/allwinner -name platform.mk
+
+to find all supported platforms. TF-A's `docs/plat/allwinner.rst`_ contains
+more information and lists some build options.
+
+Building the Crust management processor firmware
+------------------------------------------------
+For some SoCs and boards, the integrated OpenRISC management controller can
+be used to provide power management services, foremost suspend to RAM.
+There is a community supported Open Source implementation called `crust`_,
+which runs on most SoCs featuring a management controller.
+
+This firmware part is optional, setting the SCP environment variable to
+/dev/null avoids the warning message when building without one.
+
+To build crust's scp.bin, you need an OpenRISC (or1k) cross compiler, then::
+
+  $ git clone https://github.com/crust-firmware/crust.git
+  $ cd crust
+  $ make <yourboard>_defconfig
+  $ make CROSS_COMPILE=or1k-none-elf- scp
+  $ export SCP=$(pwd)/build/scp/scp.bin
+
+Find a list of supported board configurations in the `configs/`_ directory.
+The `crust README`_ has more information about the building process, including
+information about where to get OpenRISC cross compilers.
+
+Building the U-Boot image
+-------------------------
+Find the U-Boot defconfig file for your board first. Those files live in
+the ``configs/`` directory; you can grep for the stub name of the devicetree
+file, if you know that, or for the SoC name to find the right version::
+
+    $ git grep -l MACH_SUN8I_H3 configs
+    $ git grep -l sun50i-h6-orangepi-3 configs
+
+The `linux-sunxi`_ wiki also lists the name of the defconfig file in the
+respective board page. Then use this defconfig file to create the .config
+file, and build the image::
+
+    $ make <yourboard>_defconfig
+    $ make
+
+For 64-bit boards, this requires either the BL31 environment variable to be
+set (as shown above in the TF-A build example), or it to be supplied on the
+build command line::
+
+    $ make BL31=/src/tf-a.git/build/sun50i_h616/debug/bl31.bin
+
+The same applies to the (optional) SCP firmware.
+
+The file containing everything you need is called ``u-boot-sunxi-with-spl.bin``,
+you will find it in the root folder of your U-Boot (build) tree. Except for
+raw NAND flash devices this very same file can be used for any boot source.
+It will contain the SPL image, fitted with the proper signature recognised by
+the BROM, and the required checksum. Also it will contain at least U-Boot
+proper, either wrapped in the legacy U-Boot image format, or in a FIT image.
+The board's devicetree is also included, either appended to the U-Boot proper
+image, or contained in the FIT image. If required by the SoC, this FIT file will
+also include the other firmware images.
+
+Installing U-Boot
+-----------------
+
+Installing on a (micro-) SD card
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+All Allwinner SoCs will try to find a boot image at sector 16 (8KB) of
+an SD card, connected to the first MMC controller. To transfer the generated
+image to an SD card, from any Linux device (including the board itself) with
+an (micro-)SD card reader, type::
+
+    $ sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1k seek=8
+
+``/dev/sdx`` needs to be replaced with the block device name of the SD card
+reader. On some machines this could be ``/dev/mmcblkX``.
+Newer SoCs (starting from the H3 from 2014, and including all ARM64 SoCs),
+also look at sector 256 (128KB) for the signature (after having checked the
+8KB location). Installing the firmware there has the advantage of not
+overlapping with a GPT partition table. Simply replace the "``seek=8``" above
+with "``seek=128``".
+
+You can also use an existing (mainline) U-Boot to write to the SD card. Load
+the generated U-Boot image somewhere into DRAM (via ``ext4load``, ``fatload``,
+or ``tftpboot``), then write to MMC device 0::
+
+    => fatload mmc 0:1 $kernel_addr_r u-boot-sunxi-with-spl.bin
+    => mmc dev 0
+    => mmc write $kernel_addr_r 0x10 0x7f0
+
+To use the alternative boot location on newer SoCs::
+
+    => mmc write $kernel_addr_r 0x100 0x700
+
+Installing on eMMC (on-board flash memory)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Some boards have a soldered eMMC chip, some other boards have an eMMC socket
+to receive an optional eMMC module. U-Boot can be installed to those chips,
+to boot without an SD card inserted. The Boot-ROM can boot either from the
+regular user data partition, or from one of the separate eMMC boot partitions.
+U-Boot can be installed either from a running Linux instance on the device,
+from a running (mainline) U-Boot, or via an adapter for the (removable)
+eMMC module.
+
+Installing on an eMMC user data partition from Linux
+````````````````````````````````````````````````````
+If you have a running Linux instance on the device, and have somehow copied
+over the image file to that device, you can write the image directly into the
+eMMC device from there.
+Find the name of the block device file first, it is one of the
+``/dev/mmcblk<X>`` devices. eMMC devices typically also list a
+``/dev/mmcblk<X>boot0`` partition (see below), this helps you to tell it apart
+from the SD card device.
+To install onto the user data partition::
+
+    $ sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/dev/mmcblkX bs=1k seek=8
+
+Similar to SD cards, the BROM in newer SoCs (H3 and above) also checks
+sector 256 of an eMMC, so you can use "``seek=128``" as well. Having a GPT
+on an eMMC device is much more likely than on an SD card, so you should
+probably stick to the alternative location, or use one of the boot partitions.
+
+Installing on an eMMC boot partition from Linux
+```````````````````````````````````````````````
+In the following examples, ``/dev/mmcblkX`` needs to be replaced with the block
+device name of the eMMC device. The eMMC device can be recognised by also
+listing the boot partitions (``/dev/mmcblkXboot0``) in ``/proc/partitions``.
+
+To allow booting from one of the eMMC boot partitions, this one needs to be
+enabled first. This only needs to be done once, as this setting is
+persistent, even though the boot partition can be disabled or changed again
+any time later::
+
+    # apt-get install mmc-utils
+    # mmc bootbus set single_hs x1 x4 /dev/mmcblkX
+    # mmc bootpart enable 1 1 /dev/mmcblkX
+
+The first "1" in the last command points to the boot partition number to be
+used, typically devices offer two boot partitions.
+
+By default Linux disables write access to the boot partitions, to prevent
+accidental overwrites. You need to disable the write protection (until the
+next reboot), then can write the U-Boot image to the *first* sector of the
+selected boot partition::
+
+    # echo 0 > /sys/block/mmcblkXboot0/force_ro
+    # dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblkXboot0 bs=1k
+
+Installing on an eMMC user data partition from U-Boot
+`````````````````````````````````````````````````````
+You can also write the generated image file to an SD card, boot the device
+from there, and burn the very same image to the eMMC device from U-Boot.
+The following commands copy the image from the SD card to the eMMC device::
+
+    => mmc dev 0
+    => mmc read $kernel_addr_r 0x10 0x7f0
+    => mmc dev 1
+    => mmc write $kernel_addr_r 0x10 0x7f0
+
+You can also copy an image from the 8K offset of an SD card to the 128K
+offset of the eMMC (or any combination), just change the "``0x10 0x7f0``" above
+to "``0x100 0x700``", respectively. Of course the image file can be loaded via
+any other loading method, including ``fatload``, ``ext4load``, ``tftpboot``.
+
+Installing on an eMMC boot partition from U-Boot
+````````````````````````````````````````````````
+The selected eMMC boot partition needs to be initially enabled first (same
+as in Linux above), you can do this from U-Boot with::
+
+    => mmc dev 1
+    => mmc bootbus 1 1 0 0
+    => mmc partconf 1 1 1 1
+
+The first "1" in both commands denotes the MMC device number. The second "1"
+in the partconf command sets the required ``BOOT_ACK`` option, the last two "1"s
+selects the active boot partition and the target for the next data access,
+respectively. So for the next "``mmc write``" command to address one of the boot
+partitions, the last number must either be "1" or "2", "0" would switch (back)
+to the normal user data partition.
+
+Then load the ``u-boot-sunxi-with-spl.bin`` image file into DRAM, either by
+reading directly from an SD card or eMMC user data partition, or from a
+file system or TFTP (see above), and transfer it to the boot partition::
+
+    => tftpboot $kernel_addr_r u-boot-sunxi-with-spl.bin
+    => mmc write $kernel_addr_r 0 0x7f0
+
+After that the device should boot from the selected boot partition, which takes
+precedence over booting from the user data partition.
+
+Installing on SPI flash
+^^^^^^^^^^^^^^^^^^^^^^^
+Some devices have a SPI NOR flash chip soldered on the board. If it is
+connected to the SPI0 pins on PortC, the BROM can also boot from there.
+Typically the SPI flash has the lowest boot priority, so SD card and eMMC
+devices will be considered first.
+
+Installing on SPI flash from Linux
+``````````````````````````````````
+If the devicetree enables and describes the SPI flash device, you can access
+the SPI flash content from Linux, using the `MTD utils`_::
+
+    # apt-get install mtd-utils
+    # mtdinfo
+    # mtd_debug erase /dev/mtdX 0 0xf0000
+    # mtd_debug write /dev/mtdX 0 0xf0000 u-boot-sunxi-with-spl.bin
+
+``/dev/mtdX`` needs to be replaced with the respective device name, as listed
+in the output of ``mtdinfo``.
+
+Installing on SPI flash from U-Boot
+```````````````````````````````````
+If SPI flash driver and command support (``CONFIG_CMD_SF``) is enabled in the
+U-Boot configuration, the image file can be installed via U-Boot as well::
+
+    => tftpboot $kernel_addr_r u-boot-sunxi-with-spl.bin
+    => sf probe
+    => sf erase 0 +0xf0000
+    => sf write $kernel_addr_r 0 $filesize
+
+Installing on SPI flash via USB in FEL mode
+```````````````````````````````````````````
+If the device is in FEL mode (see below), the SPI flash can also be written to
+with the sunxi-fel utility, via an USB(-OTG) cable from any USB host machine::
+
+    $ sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
+
+Booting via the USB(-OTG) FEL mode
+----------------------------------
+If none of the boot locations checked by the BROM contains a medium or valid
+signature, the BROM will enter the so-called FEL mode, in which it will
+listen to commands from a host on the SoC's USB-OTG interface. Those commands
+allow to read from and write to arbitrary memory locations, also to start
+execution at any address, which allows to bootstrap a board solely via an
+USB cable. Some boards feature a "FEL" or "U-Boot" button, which forces
+FEL mode despite a valid boot location being present. The same can be achieved
+via a `magic binary`_ on an SD card, which allows to enter FEL mode on any
+board.
+
+To use FEL booting, let the board enter FEL mode, via any of the mentioned
+methods (no boot media, FEL button, SD card with FEL binary), then connect
+a USB cable to the board's USB OTG port. Some boards (Pine64, TV boxes) don't
+have a separate OTG port. In this case mostly one of the USB-A ports is
+connected to USB0, and can be used via a non-standard USB-A to USB-A cable.
+
+Typically there is no on-board indication of FEL mode, other than a new USB
+device appearing on the connected host computer. The USB vendor/device ID
+is 1f3a:efe8. Mostly this will identify as "sunxi SoC OTG connector in
+FEL/flashing mode", but older distributions might still report "Onda
+(unverified) V972 tablet in flashing mode".
+
+The `sunxi_fel`_ tool implements the proprietary BROM protocol, and allows to
+bootstrap U-Boot by just providing our venerable u-boot-sunxi-with-spl.bin::
+
+    $ sudo apt-get install sunxi-tools
+    $ sunxi-fel uboot u-boot-sunxi-with-spl.bin
+
+Additional binaries like a kernel, an initial ramdisk or a boot script, can
+also be uploaded via FEL, check the Wiki's `FEL page`_ for more details.
+
+.. _`Arm Trusted Firmware-A`:  https://www.trustedfirmware.org/projects/tf-a/
+.. _`docs/plat/allwinner.rst`: https://trustedfirmware-a.readthedocs.io/en/latest/plat/allwinner.html
+.. _`crust`: https://github.com/crust-firmware/crust
+.. _`configs/`: https://github.com/crust-firmware/crust/tree/master/configs
+.. _`crust README`: https://github.com/crust-firmware/crust/blob/master/README.md#building-the-firmware
+.. _`linux-sunxi`: https://linux-sunxi.org
+.. _`MTD utils`: http://www.linux-mtd.infradead.org/
+.. _`magic binary`: https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/fel-sdboot.sunxi
+.. _`sunxi_fel`: https://github.com/linux-sunxi/sunxi-tools
+.. _`FEL page`: https://linux-sunxi.org/FEL/USBBoot
diff --git a/doc/board/armltd/index.rst b/doc/board/armltd/index.rst
new file mode 100644
index 0000000000..c20d8a0a26
--- /dev/null
+++ b/doc/board/armltd/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Arm Ltd
+=============
+
+.. toctree::
+   :maxdepth: 2
+
+   vexpress64.rst
diff --git a/doc/board/armltd/vexpress64.rst b/doc/board/armltd/vexpress64.rst
new file mode 100644
index 0000000000..d87b1c38f5
--- /dev/null
+++ b/doc/board/armltd/vexpress64.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Arm Versatile Express
+=====================
+
+The vexpress_* board configuration supports the following platforms:
+
+ * FVP_Base_RevC-2xAEMvA
+ * Juno development board
+
+Fixed Virtual Platforms
+-----------------------
+
+The Fixed Virtual Platforms (FVP) are complete simulations of an Arm system,
+including processor, memory and peripherals. They are set out in a "programmer's
+view", which gives a comprehensive model on which to build and test software.
+
+The supported FVPs are available free of charge and can be downloaded from the
+Arm developer site [1]_ (user registration might be required).
+
+Supported features:
+
+ * GICv3
+ * Generic timer
+ * PL011 UART
+
+The default configuration assumes that U-Boot is bootstrapped using a suitable
+bootloader, such as Trusted Firmware-A [4]_. The u-boot binary can be passed
+into the TF-A build: ``make PLAT=<platform> all fip BL33=u-boot.bin``
+
+The FVPs can be debugged using Arm Development Studio [2]_.
+
+Juno
+----
+
+Juno is an Arm development board with the following features:
+
+ * Arm Cortex-A72/A57 and Arm Cortex-A53 in a "big.LITTLE" configuration
+ * A PCIe Gen2.0 bus with 4 lanes
+ * 8GB of DRAM
+ * GICv2
+
+More details can be found in the board documentation [3]_.
+
+References
+----------
+
+.. [1] https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
+.. [2] https://developer.arm.com/tools-and-software/embedded/arm-development-studio
+.. [3] https://developer.arm.com/tools-and-software/development-boards/juno-development-board
+.. [4] https://trustedfirmware-a.readthedocs.io/
\ No newline at end of file
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 7c24e29410..16f66388eb 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality:
 
 Additionally, a number of optional peripherals can be added to the PCI bus.
 
+See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
+the devicetree actually generated by QEMU.
+
 Building U-Boot
 ---------------
 Set the CROSS_COMPILE environment variable as usual, and run:
@@ -41,14 +44,15 @@ The minimal QEMU command line to get U-Boot up and running is:
 
 - For ARM::
 
-    qemu-system-arm -machine virt -bios u-boot.bin
+    qemu-system-arm -machine virt -nographic -bios u-boot.bin
 
 - For AArch64::
 
-    qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin
+    qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios u-boot.bin
 
 Note that for some odd reason qemu-system-aarch64 needs to be explicitly
-told to use a 64-bit CPU or it will boot in 32-bit mode.
+told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument
+ensures that output appears on the terminal. Use Ctrl-A X to quit.
 
 Additional persistent U-boot environment support can be added as follows:
 
diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst
index 4b8e104a21..3409fff811 100644
--- a/doc/board/emulation/qemu-riscv.rst
+++ b/doc/board/emulation/qemu-riscv.rst
@@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for
 the VirtIO standard networking and block storage devices. It has CLINT, PLIC,
 16550A UART devices in addition to VirtIO and it also uses device-tree to pass
 configuration information to guest software. It implements RISC-V privileged
+
+See :doc:`../../develop/devicetree/dt_qemu` for information on how to see
+the devicetree actually generated by QEMU.
 architecture spec v1.10.
 
 Building U-Boot
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 13f4db848e..5607e1f946 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -9,8 +9,10 @@ Board-specific doc
    actions/index
    advantech/index
    AndesTech/index
+   allwinner/index
    amlogic/index
    apple/index
+   armltd/index
    atmel/index
    congatec/index
    coreboot/index
diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
index 42bb94148d..0c5d3a90f0 100644
--- a/doc/board/st/stm32mp1.rst
+++ b/doc/board/st/stm32mp1.rst
@@ -645,16 +645,18 @@ On EV1 board, booting from SD card, without OP-TEE_::
   dev: eMMC alt: 15 name: mmc1_rootfs layout: RAW_ADDR
   dev: eMMC alt: 16 name: mmc1_userfs layout: RAW_ADDR
   dev: MTD alt: 17 name: nor0 layout: RAW_ADDR
-  dev: MTD alt: 18 name: nand0 layout: RAW_ADDR
-  dev: VIRT alt: 19 name: OTP layout: RAW_ADDR
-  dev: VIRT alt: 20 name: PMIC layout: RAW_ADDR
+  dev: MTD alt: 18 name: nor1 layout: RAW_ADDR
+  dev: MTD alt: 19 name: nand0 layout: RAW_ADDR
+  dev: VIRT alt: 20 name: OTP layout: RAW_ADDR
+  dev: VIRT alt: 21 name: PMIC layout: RAW_ADDR
 
 All the supported device are exported for dfu-util tool::
 
   $> dfu-util -l
-  Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="PMIC", serial="002700333338511934383330"
-  Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="OTP", serial="002700333338511934383330"
-  Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nand0", serial="002700333338511934383330"
+  Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=21, name="PMIC", serial="002700333338511934383330"
+  Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=20, name="OTP", serial="002700333338511934383330"
+  Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=19, name="nand0", serial="002700333338511934383330"
+  Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=18, name="nor1", serial="002700333338511934383330"
   Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=17, name="nor0", serial="002700333338511934383330"
   Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=16, name="mmc1_userfs", serial="002700333338511934383330"
   Found DFU: [0483:df11] ver=9999, devnum=99, cfg=1, intf=0, alt=15, name="mmc1_rootfs", serial="002700333338511934383330"
@@ -705,12 +707,12 @@ You can update the boot device:
 When the board is booting for nor0 or nand0,
 only the MTD partition on the boot devices are available, for example:
 
-- NOR (nor0 = alt 20) & NAND (nand0 = alt 26) ::
+- NOR (nor0 = alt 20, nor1 = alt 26) & NAND (nand0 = alt 27) :
 
   $> dfu-util -d 0483:5720 -a 21 -D tf-a-stm32mp157c-ev1.stm32
   $> dfu-util -d 0483:5720 -a 22 -D tf-a-stm32mp157c-ev1.stm32
   $> dfu-util -d 0483:5720 -a 23 -D fip-stm32mp157c-ev1.bin
-  $> dfu-util -d 0483:5720 -a 27 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
+  $> dfu-util -d 0483:5720 -a 28 -D st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
 
 - NAND (nand0 = alt 21)::