diff options
Diffstat (limited to 'doc')
40 files changed, 907 insertions, 167 deletions
diff --git a/doc/README.omap-ulpi-viewport b/doc/README.omap-ulpi-viewport deleted file mode 100644 index a5240b9e295..00000000000 --- a/doc/README.omap-ulpi-viewport +++ /dev/null @@ -1,27 +0,0 @@ -Reference code ""drivers/usb/ulpi/omap-ulpi-viewport.c" - -Contains the ulpi read write api's to perform -any ulpi phy port access on omap platform. - -On omap ehci reg map contains INSNREG05_ULPI -register which offers the ulpi phy access so -any ulpi phy commands should be passsed using this -register. - -omap-ulpi-viewport.c is a low level function -implementation of "drivers/usb/ulpi/ulpi.c" - -To enable and use omap-ulpi-viewport.c -we require CONFIG_USB_ULPI_VIEWPORT_OMAP and -CONFIG_USB_ULPI be enabled in config file. - -Any ulpi ops request can be done with ulpi.c -and soc specific binding and usage is done with -omap-ulpi-viewport implementation. - -Ex: scenario: -omap-ehci driver code requests for ulpi phy reset if -ehci is used in phy mode, which will call ulpi phy reset -the ulpi phy reset does ulpi_read/write from viewport -implementation which will do ulpi reset using the -INSNREG05_ULPI register. diff --git a/doc/api/efi.rst b/doc/api/efi.rst index 43d6f936fb0..a98298f93dc 100644 --- a/doc/api/efi.rst +++ b/doc/api/efi.rst @@ -178,6 +178,12 @@ Driver binding protocol .. kernel-doc:: include/efi_driver.h :internal: +Device paths +------------ + +.. kernel-doc:: include/efi_device_path.h + :internal: + Unit testing ------------ diff --git a/doc/api/index.rst b/doc/api/index.rst index 506843ed74a..cf9d21e4c1c 100644 --- a/doc/api/index.rst +++ b/doc/api/index.rst @@ -17,7 +17,6 @@ U-Boot API documentation interrupt led linker_lists - lmb logging nvmem part diff --git a/doc/api/lmb.rst b/doc/api/lmb.rst deleted file mode 100644 index 2095bfa1618..00000000000 --- a/doc/api/lmb.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0+ - -Logical memory blocks -===================== - -.. kernel-doc:: include/lmb.h - :internal: diff --git a/doc/board/beagle/j721e_beagleboneai64.rst b/doc/board/beagle/j721e_beagleboneai64.rst index 090b2b3b86a..a57bc743569 100644 --- a/doc/board/beagle/j721e_beagleboneai64.rst +++ b/doc/board/beagle/j721e_beagleboneai64.rst @@ -83,6 +83,7 @@ Target Images Copy the below images to an SD card and boot: * tiboot3-j721e-gp-evm.bin from R5 build as tiboot3.bin +* sysfw-j721e-gp-evm.itb from R5 build as sysfw.itb * tispl.bin_unsigned from Cortex-A build as tispl.bin * u-boot.img_unsigned from Cortex-A build as u-boot.img diff --git a/doc/board/broadcom/bcm7xxx.rst b/doc/board/broadcom/bcm7xxx.rst index f1994d9f975..f559d5c290a 100644 --- a/doc/board/broadcom/bcm7xxx.rst +++ b/doc/board/broadcom/bcm7xxx.rst @@ -149,10 +149,8 @@ and with a generic ARMv7 root file system. * to the Linux source tree as a .dts file. * * To support modifications to the device tree - * in-place in U-Boot, add to Linux's - * arch/arm/boot/dts/Makefile: - * - * DTC_FLAGS ?= -p 4096 + * in-place in U-Boot, set the config variable + * CONFIG_SYS_DTC_PAD_BYTES as needed. * * This will leave some padding in the DTB and * thus reserve room for node additions. diff --git a/doc/board/index.rst b/doc/board/index.rst index 3c5a2c7d1cf..e084c7fb1df 100644 --- a/doc/board/index.rst +++ b/doc/board/index.rst @@ -38,6 +38,7 @@ Board-specific doc kontron/index lenovo/index lg/index + liebherr/index mediatek/index microchip/index microsoft/index diff --git a/doc/board/liebherr/btt.rst b/doc/board/liebherr/btt.rst new file mode 100644 index 00000000000..d22ffa205bd --- /dev/null +++ b/doc/board/liebherr/btt.rst @@ -0,0 +1,34 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. sectionauthor:: Lukasz Majewski <lukma@denx.de> + +BTT devices +=========== + +Those devices are based on IMX's IMX287 SoC. The description regarding the +**btt** family of boards (i.e. `btt3` and `bttc`) is identical as the one for +the already supported **xea** board. + +Building +-------- + +Make sure that `CROSS_COMPILE` is set appropriately: + +.. code-block:: text + + $ make imx28_btt3_defconfig + $ make -j4 u-boot.sb u-boot.img + +Now you should see `u-boot.sb` and `u-boot.img` files in the build directory. + +For initial bringup - one can use `uuu` utulity to boot till u-boot prompt +(USB connection with the board is required). + +Flashing +-------- + +Via U-Boot: + +.. code-block:: text + + => run update_spl + => run update_uboot diff --git a/doc/board/liebherr/index.rst b/doc/board/liebherr/index.rst new file mode 100644 index 00000000000..d8db6bd188c --- /dev/null +++ b/doc/board/liebherr/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Liebherr +======== + +.. toctree:: + :maxdepth: 2 + + btt diff --git a/doc/board/qualcomm/board.rst b/doc/board/qualcomm/board.rst index 003d59a18eb..642c5095261 100644 --- a/doc/board/qualcomm/board.rst +++ b/doc/board/qualcomm/board.rst @@ -23,10 +23,7 @@ Installation ------------ Build ^^^^^ - - $ ./tools/buildman/buildman -o .output qcom - -This will build ``.output/u-boot-nodtb.bin`` using the ``qcom_defconfig``. +We will build ``u-boot-nodtb.bin`` from the u-boot source tree. Generate FIT image (optional) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -81,19 +78,20 @@ Steps: - Build u-boot -As above:: +Use the following commands:: - ./tools/buildman/buildman -o .output qcom + make CROSS_COMPILE=aarch64-linux-gnu- O=.output qcom_defconfig + make CROSS_COMPILE=aarch64-linux-gnu- O=.output -j$(nproc) Or for db410c (and other boards not supported by the generic target):: make CROSS_COMPILE=aarch64-linux-gnu- O=.output dragonboard410c_defconfig - make O=.output -j$(nproc) + make CROSS_COMPILE=aarch64-linux-gnu- O=.output -j$(nproc) Or for smartphones:: make CROSS_COMPILE=aarch64-linux-gnu- O=.output qcom_defconfig qcom-phone.config - make O=.output -j$(nproc) + make CROSS_COMPILE=aarch64-linux-gnu- O=.output -j$(nproc) - gzip u-boot:: @@ -119,6 +117,13 @@ Or with no FIT image:: mkbootimg --kernel u-boot-nodtb.bin.gz-dtb \ --output boot.img --pagesize 4096 --base 0x80000000 +Other devices with boot image version 2 can be built like this example:: + + mkbootimg --pagesize 4096 --header_version 2 \ + --kernel_offset 0x00008000 --kernel u-boot-nodtb.bin.gz \ + --dtb_offset 0x01f00000 --dtb dts/upstream/src/arm64/qcom/qcm6490-fairphone-fp5.dtb \ + --output boot.img + - Flash boot.img using fastboot and erase dtbo to avoid conflicts with our DTB: .. code-block:: bash diff --git a/doc/board/qualcomm/dragonwing.rst b/doc/board/qualcomm/dragonwing.rst new file mode 100644 index 00000000000..d4899415309 --- /dev/null +++ b/doc/board/qualcomm/dragonwing.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. sectionauthor:: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com> + +Qualcomm DragonWing +======================================== + +Qualcomm DragonWing are industrial-grade boards that provides various series +of processors such as IQ6 (QCS615), IQ8 (QCS8300) and IQ9 (QCS9100). +These SoCs are used for factory/industry based applications. +More information can be found on the `Qualcomm's IQ6 product page`_, +`Qualcomm's IQ8 product page`_ and `Qualcomm's IQ9 product page`_. + +.. _Qualcomm's IQ6 product page: https://docs.qualcomm.com/bundle/publicresource/87-83838-1_REV_A_Qualcomm_IQ6_Series_Product_Brief.pdf +.. _Qualcomm's IQ8 product page: https://docs.qualcomm.com/bundle/publicresource/87-83839-1_REV_A_Qualcomm_IQ8_Series_Product_Brief________.pdf +.. _Qualcomm's IQ9 product page: https://docs.qualcomm.com/bundle/publicresource/87-83840-1_REV_A_Qualcomm_IQ9_Series_Product_Brief.pdf + +Installation +------------ +First, setup ``CROSS_COMPILE`` for aarch64. Then, build U-Boot for ``QCS615``, ``QCS8300`` or ``QCS9100``:: + + $ export CROSS_COMPILE=<aarch64 toolchain prefix> + $ make qcom_qcs8300_defconfig + $ make -j8 u-boot.mbn + +Although the board does not have secure boot set up by default, +the firmware still expects firmware ELF images to be "signed". The signature +does not provide any security in this case, but it provides the firmware with +some required metadata. + +To "sign" ``u-boot.elf`` you can use e.g. `qtestsign`_:: + + $ qtestsign -v6 aboot -o u-boot.mbn u-boot.elf + +Then flash the resulting ``u-boot.mbn`` to the ``uefi_a`` partition +on your device with ``fastboot flash uefi_a u-boot.mbn``. + +U-Boot should be running after a reboot (``fastboot reboot``). + +Note that fastboot is not yet supported in U-Boot on Dragonwing boards, as a result, to flash +back the original firmware, or new versoins of the U-Boot, EDL mode must be used. + +A tool like bkerler's `edl`_ can be used for flashing with the firehose loader (for example, for QCS9100 +the firehose loader can be obtained from `dragonwing IQ9 bootbinaries`.) :: + +$ edl.py --loader /path/to/prog_firehose_ddr.elf w uefi_a u-boot.mbn + +.. _qtestsign: https://github.com/msm8916-mainline/qtestsign +.. _edl: https://github.com/bkerler/edl +.. _dragonwing IQ9 bootbinaries: https://artifacts.codelinaro.org/ui/native/qli-ci/flashable-binaries/qimpsdk/qcs9075-rb8-core-kit diff --git a/doc/board/qualcomm/index.rst b/doc/board/qualcomm/index.rst index e2fcbfa19c2..ccf834208e9 100644 --- a/doc/board/qualcomm/index.rst +++ b/doc/board/qualcomm/index.rst @@ -8,6 +8,7 @@ Qualcomm dragonboard410c rb3gen2 + dragonwing board phones debugging diff --git a/doc/board/qualcomm/rdp.rst b/doc/board/qualcomm/rdp.rst index fd14f1d9829..99cf8eba57c 100644 --- a/doc/board/qualcomm/rdp.rst +++ b/doc/board/qualcomm/rdp.rst @@ -21,13 +21,16 @@ First, setup ``CROSS_COMPILE`` for aarch64. Then, build U-Boot for ``IPQ9574``:: This will build ``u-boot.elf`` in the configured output directory. -Although the RDPs do not have secure boot set up by default, the firmware still -expects firmware ELF images to be "signed". The signature does not provide any -security in this case, but it provides the firmware with some required metadata. +The firmware expects the ELF images to be in MBN format. The `elftombn.py` tool +can be used to convert the ELF images to MBN format. -To "sign" ``u-boot.elf`` you can use e.g. `qtestsign`_:: + IPQ9574: (MBN version 6) - $ qtestsign -v6 aboot -o u-boot.mbn u-boot.elf + $ python elftombn.py -f u-boot.elf -o u-boot.mbn -v6 + + IPQ5424: (MBN version 7) + + $ python elftombn.py -f u-boot.elf -o u-boot.mbn -v7 Then install the resulting ``u-boot.mbn`` to the ``0:APPSBL`` partition on your device with:: @@ -51,5 +54,5 @@ U-Boot should be running after a reboot (``reset``). Note that the support added is very basic. Restoring the original U-Boot on boards with older version of the software requires a debugger. -.. _qtestsign: https://github.com/msm8916-mainline/qtestsign +.. _elftombn.py: https://git.codelinaro.org/clo/qsdk/oss/system/tools/meta/-/tree/NHSS.QSDK.13.0.5.r2/scripts?ref_type=heads .. _edl: https://github.com/bkerler/edl diff --git a/doc/board/renesas/renesas.rst b/doc/board/renesas/renesas.rst index 0a38ff42eae..fedfeed42e3 100644 --- a/doc/board/renesas/renesas.rst +++ b/doc/board/renesas/renesas.rst @@ -180,6 +180,12 @@ Renesas is a SoC solutions provider for automotive and industrial applications. - arm64 - r8a779g0_whitehawk_defconfig + * - + - Sparrow Hawk + - R8A779G3 (V4H) + - arm64 + - r8a779g3_sparrowhawk_defconfig + * - RZ/G2 Family - Beacon EmbeddedWorks RZ/G2M SoM - R8A774A1 (RZ/G2M) diff --git a/doc/board/thead/lpi4a.rst b/doc/board/thead/lpi4a.rst index e395c6ae12c..acd7ac2698d 100644 --- a/doc/board/thead/lpi4a.rst +++ b/doc/board/thead/lpi4a.rst @@ -32,6 +32,8 @@ Mainline support The support for following drivers are already enabled: 1. ns16550 UART Driver. +2. eMMC and SD card + Building ~~~~~~~~ @@ -43,87 +45,84 @@ Building export CROSS_COMPILE=<riscv64 toolchain prefix> -The U-Boot is capable of running in M-Mode, so we can directly build it. +3. Build DDR firmware + +DDR driver requires a firmware to function, to build it: + +.. code-block:: bash + + git clone --depth 1 https://github.com/ziyao233/th1520-firmware + cd th1520-firmware + lua5.4 ddr-generate.lua src/<CONFIGURATION_NAME>.lua th1520-ddr-firmware.bin + +4. Build OpenSBI Firmware + +TH1520 port of proper U-Boot runs in S mode, thus OpenSBI is required as +SBI firmware to setup S-mode environment and provide SBI calls. It could +be cloned and built for TH1520 as below, + +.. code-block:: bash + + git clone https://github.com/riscv-software-src/opensbi.git + cd opensbi + make PLATFORM=generic -.. code-block:: console +TH1520 support in OpenSBI requires v1.2 or a more recent version. + +More detailed description of steps required to build fw_dynamic firmware +is beyond the scope of this document. Please refer to OpenSBI +documenation. + +5. Build U-Boot images + +The DDR firmware should be copied to U-Boot source directory before +building. + +.. code-block:: bash cd <U-Boot-dir> + cp <path-to-ddr-firmware> th1520-ddr-firmware.bin make th1520_lpi4a_defconfig - make + make OPENSBI=<opensbi_dir>/build/platform/generic/firmware/fw_dynamic.bin -This will generate u-boot-dtb.bin +This will generate u-boot-with-spl.bin, which contains SPL, DDR firmware, +OpenSBI firmware and proper U-Boot. Booting ~~~~~~~ -Currently, we rely on vendor u-boot to initialize the clock, pinctrl subsystem, -and chain load the mainline u-boot image either via tftp or emmc storage, -then bootup from it. +u-boot-with-spl.bin should be loaded to SRAM through fastboot. Connect +the board to computer with Type-C cable and run -Sample boot log from Lichee PI 4A board via tftp -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. code-block:: bash + + fastboot flash ram u-boot-with-spl.bin + fastboot reboot + +Sample boot log from Lichee PI 4A board via fastboot +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: none - brom_ver 8 [APP][E] protocol_connect failed, exit. + Starting download of 940681 bytes + + downloading of 940681 bytes finished - U-Boot SPL 2020.01-00016-g8c870a6be8 (May 20 2023 - 01:04:49 +0000) - FM[1] lpddr4x dualrank freq=3733 64bit dbi_off=n sdram init - ddr initialized, jump to uboot - image has no header + U-Boot SPL 2025.07-rc3-00005-g3a0ef515b8bb (May 29 2025 - 10:42:46 +0000) + Trying to boot from RAM - U-Boot 2020.01-00016-g8c870a6be8 (May 20 2023 - 01:04:49 +0000) + U-Boot 2025.07-rc3-00005-g3a0ef515b8bb (May 29 2025 - 10:42:46 +0000) - CPU: rv64imafdcvsu - Model: T-HEAD c910 light + CPU: thead,c910 + Model: Sipeed Lichee Pi 4A DRAM: 8 GiB - C910 CPU FREQ: 750MHz - AHB2_CPUSYS_HCLK FREQ: 250MHz - AHB3_CPUSYS_PCLK FREQ: 125MHz - PERISYS_AHB_HCLK FREQ: 250MHz - PERISYS_APB_PCLK FREQ: 62MHz - GMAC PLL POSTDIV FREQ: 1000MHZ - DPU0 PLL POSTDIV FREQ: 1188MHZ - DPU1 PLL POSTDIV FREQ: 1188MHZ - MMC: sdhci@ffe7080000: 0, sd@ffe7090000: 1 - Loading Environment from MMC... OK - Error reading output register - Warning: cannot get lcd-en GPIO - LCD panel cannot be found : -121 - splash screen startup cost 16 ms - In: serial - Out: serial - Err: serial - Net: - Warning: ethernet@ffe7070000 using MAC address from ROM - eth0: ethernet@ffe7070000ethernet@ffe7070000:0 is connected to ethernet@ffe7070000. Reconnecting to ethernet@ffe7060000 - - Warning: ethernet@ffe7060000 (eth1) using random MAC address - 42:25:d4:16:5f:fc - , eth1: ethernet@ffe7060000 - Hit any key to stop autoboot: 2 - ethernet@ffe7060000 Waiting for PHY auto negotiation to complete.. done - Speed: 1000, full duplex - Using ethernet@ffe7070000 device - TFTP from server 192.168.8.50; our IP address is 192.168.8.45 - Filename 'u-boot-dtb.bin'. - Load address: 0x1c00000 - Loading: * ######################### - 8 MiB/s - done - Bytes transferred = 376686 (5bf6e hex) - ## Starting application at 0x01C00000 ... - - U-Boot 2023.07-rc2-00004-g1befbe31c1 (May 23 2023 - 18:40:01 +0800) - - CPU: rv64imafdc - Model: Sipeed Lichee Pi 4A - DRAM: 8 GiB - Core: 13 devices, 6 uclasses, devicetree: separate - Loading Environment from <NULL>... OK - In: serial@ffe7014000 - Out: serial@ffe7014000 - Err: serial@ffe7014000 - Model: Sipeed Lichee Pi 4A - LPI4A=> + Core: 110 devices, 9 uclasses, devicetree: separate + MMC: mmc@ffe7080000: 0, mmc@ffe7090000: 1 + Loading Environment from <NULL>... OK + In: serial@ffe7014000 + Out: serial@ffe7014000 + Err: serial@ffe7014000 + Model: Sipeed Lichee Pi 4A + LPI4A=> diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index 0d9ccd5a768..01fb9411688 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -49,6 +49,7 @@ K3 SoC based boards in other sections * :doc:`../phytec/phycore-am62x` * :doc:`../phytec/phycore-am62ax` * :doc:`../toradex/verdin-am62` +* :doc:`../toradex/verdin-am62p` Boot Flow Overview ------------------ diff --git a/doc/board/toradex/index.rst b/doc/board/toradex/index.rst index 7d510a80112..68934566ad7 100644 --- a/doc/board/toradex/index.rst +++ b/doc/board/toradex/index.rst @@ -11,5 +11,6 @@ Toradex colibri-imx8x smarc-imx8mp verdin-am62 + verdin-am62p verdin-imx8mm verdin-imx8mp diff --git a/doc/board/toradex/verdin-am62p.rst b/doc/board/toradex/verdin-am62p.rst new file mode 100644 index 00000000000..2f3262b8d1e --- /dev/null +++ b/doc/board/toradex/verdin-am62p.rst @@ -0,0 +1,196 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later +.. sectionauthor:: Parth Pancholi <parth.pancholi@toradex.com> + +Verdin AM62P Module +=================== + +- SoM: https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62p +- Carrier board: https://www.toradex.com/products/carrier-board/verdin-development-board-kit + +Quick Start +----------- + +- Setup environment variables +- Get binary-only TI Linux firmware +- Build the ARM trusted firmware binary +- Build the OPTEE binary +- Build U-Boot for the R5 +- Build U-Boot for the A53 +- Flash to eMMC +- Boot + +Setup environment +----------------- + +Suggested current toolchains are ARM 11.3 (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads): + +- https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz +- https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz + +.. code-block:: bash + + $ export CROSS_COMPILE_32=<path/to/arm/toolchain/bin/>arm-none-linux-gnueabihf- + $ export CROSS_COMPILE_64=<path/to/arm64/toolchain/bin/>aarch64-none-linux-gnu- + +Get the TI Linux Firmware +------------------------- + +.. code-block:: bash + + $ echo "Downloading TI Linux Firmware..." + $ git clone -b ti-linux-firmware https://git.ti.com/git/processor-firmware/ti-linux-firmware.git + +Get and Build the ARM Trusted Firmware (Trusted Firmware A) +----------------------------------------------------------- + +.. code-block:: bash + + $ echo "Downloading and building TF-A..." + $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git + $ cd trusted-firmware-a + +Then build ATF (TF-A): + +.. code-block:: bash + + $ export CROSS_COMPILE="$CROSS_COMPILE_64" + $ make PLAT=k3 K3_PM_SYSTEM_SUSPEND=1 TARGET_BOARD=lite SPD=opteed + +Get and Build OPTEE +------------------- + +.. code-block:: bash + + $ echo "Downloading and building OPTEE..." + $ git clone https://github.com/OP-TEE/optee_os.git + $ cd optee_os + +Then build OPTEE: + +.. code-block:: bash + + $ export CROSS_COMPILE="$CROSS_COMPILE_32" + $ export CROSS_COMPILE64="$CROSS_COMPILE_64" + $ make PLATFORM=k3-am62px CFG_ARM64_core=y + +Build U-Boot for R5 +------------------- + +.. code-block:: bash + + $ export CROSS_COMPILE="$CROSS_COMPILE_32" + $ export BINMAN_INDIRS=<path/to/ti-linux-firmware> + $ make O=/tmp/verdin-am62p-r5 verdin-am62p_r5_defconfig + $ make O=/tmp/verdin-am62p-r5 + +Build U-Boot for A53 +-------------------- + +.. code-block:: bash + + $ export CROSS_COMPILE=$CROSS_COMPILE_64 + $ export BL31=<path/to/atf>/build/k3/lite/release/bl31.bin + $ export TEE=<path/to/optee>/out/arm-plat-k3/core/tee-pager_v2.bin + $ export BINMAN_INDIRS="<path/to/ti-linux-firmware> /tmp/verdin-am62p-r5" + $ make O=/tmp/verdin-am62p-a53 verdin-am62p_a53_defconfig + $ make O=/tmp/verdin-am62p-a53 + +Flash to eMMC +------------- + +.. code-block:: console + + => mmc dev 0 1 + => fatload mmc 1 ${loadaddr} tiboot3.bin + => mmc write ${loadaddr} 0x0 0x400 + => fatload mmc 1 ${loadaddr} tispl.bin + => mmc write ${loadaddr} 0x400 0x1000 + => fatload mmc 1 ${loadaddr} u-boot.img + => mmc write ${loadaddr} 0x1400 0x2000 + +As a convenience, instead of having to remember all those addresses and sizes, +one may also use the update U-Boot wrappers: + +.. code-block:: console + + => tftpboot ${loadaddr} tiboot3.bin + => run update_tiboot3 + + => tftpboot ${loadaddr} tispl.bin + => run update_tispl + + => tftpboot ${loadaddr} u-boot.img + => run update_uboot + +Boot +---- + +Output: + +.. code-block:: console + +U-Boot SPL 2025.04-00006-g51dc98d36470 (May 12 2025 - 15:46:57 +0100) +SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)') +Changed A53 CPU frequency to 1250000000Hz (U grade) in DT +SPL initial stack usage: 17080 bytes +Trying to boot from MMC1 +Authentication passed +Authentication passed +Authentication passed +Loading Environment from nowhere... OK +init_env from device 9 not supported! +Authentication passed +Authentication passed +Starting ATF on ARM64 core... + +NOTICE: BL31: v2.12.0(release):v2.12.0-1106-g4301798db096 +NOTICE: BL31: Built : 10:57:58, May 9 2025 +I/TC: +I/TC: OP-TEE version: 4.6.0-18-g76d920d354df (gcc version 12.3.1 20230626 (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35))) #4 Tue May 6 19:48:13 UTC 2025 aarch64 +I/TC: WARNING: This OP-TEE configuration might be insecure! +I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html +I/TC: Primary CPU initializing +I/TC: GIC redistributor base address not provided +I/TC: Assuming default GIC group status and modifier +I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)') +I/TC: Activated SA2UL device +I/TC: Enabled firewalls for SA2UL TRNG device +I/TC: SA2UL TRNG initialized +I/TC: SA2UL Drivers initialized +I/TC: HUK Initialized +I/TC: Primary CPU switching to normal world boot + +U-Boot SPL 2025.04-00006-g51dc98d36470 (May 12 2025 - 15:47:54 +0100) +SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)') +SPL initial stack usage: 1760 bytes +HW CFG: 0x00 +Trying to boot from MMC1 +Authentication passed +Authentication passed + + +U-Boot 2025.04-00006-g51dc98d36470 (May 12 2025 - 15:47:54 +0100) + +SoC: AM62PX SR1.0 HS-FS +DRAM: 2 GiB +Core: 147 devices, 31 uclasses, devicetree: separate +MMC: mmc@fa10000: 0, mmc@fa00000: 1 +Loading Environment from MMC... Reading from MMC(0)... OK +In: serial@2800000 +Out: serial@2800000 +Err: serial@2800000 +Model: Toradex 0099 Verdin AM62P Quad 2GB WB IT V1.0A +Serial#: 15664919 +Carrier: Toradex Dahlia V1.1D, Serial# 11287149 +am65_cpsw_nuss ethernet@8000000: K3 CPSW: nuss_ver: 0x6BA01903 cpsw_ver: 0x6BA81903 ale_ver: 0x00290105 Ports:2 +Setting variant to wifi +Net: +Warning: ethernet@8000000port@1 MAC addresses don't match: +Address in ROM is 58:a1:5f:b8:93:f9 +Address in environment is 00:14:2d:ef:07:17 +eth0: ethernet@8000000port@1 [PRIME]Could not get PHY for mdio@f00: addr 7 +am65_cpsw_nuss_port ethernet@8000000port@2: phy_connect() failed + +Hit any key to stop autoboot: 0 +Verdin AM62P # + diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst index c76a7fbd732..1fef718ceec 100644 --- a/doc/build/gcc.rst +++ b/doc/build/gcc.rst @@ -122,7 +122,7 @@ Out-of-tree building ~~~~~~~~~~~~~~~~~~~~ By default building is performed locally and the objects are saved in the source -directory. To build out-out-tree use one of the two methods below: +directory. To build out-of-tree use one of the two methods below: Add O= parameter to the make command line: diff --git a/doc/develop/binman_tests.rst b/doc/develop/binman_tests.rst index a632694a6fe..5e44686b8ad 100644 --- a/doc/develop/binman_tests.rst +++ b/doc/develop/binman_tests.rst @@ -431,11 +431,11 @@ error message produced by Binman. Sometimes you need to add several tests, each with their own broken image description, in order to check all the error cases. Sometimes you need to capture the console output of Binman, to check it is -correct. You can to this with ``test_util.capture_sys_output()``, for example: +correct. You can to this with ``terminal.capture()``, for example: .. code-block:: python - with test_util.capture_sys_output() as (_, stderr): + with terminal.capture() as (_, stderr): self._DoTestFile('071_gbb.dts', force_missing_bintools='futility', entry_args=entry_args) err = stderr.getvalue() @@ -572,7 +572,7 @@ In the above example, here are some possible steps: def testNxpImx8ImageMkimageMissing(self): """Test that binman can produce an iMX8 image""" - with test_util.capture_sys_output() as (_, stderr): + with terminal.capture() as (_, stderr): self._DoTestFile('339_nxp_imx8.dts', force_missing_bintools='mkimage') err = stderr.getvalue() diff --git a/doc/develop/bootstd/index.rst b/doc/develop/bootstd/index.rst index 4c4e26ccdb7..ec74fc2fb9d 100644 --- a/doc/develop/bootstd/index.rst +++ b/doc/develop/bootstd/index.rst @@ -12,5 +12,6 @@ Standard Boot qfw android cros + rauc script sandbox diff --git a/doc/develop/bootstd/overview.rst b/doc/develop/bootstd/overview.rst index 9fe5630ab16..0a237359575 100644 --- a/doc/develop/bootstd/overview.rst +++ b/doc/develop/bootstd/overview.rst @@ -443,6 +443,7 @@ Bootmeth drivers are provided for booting from various media: - :doc:`extlinux / syslinux <extlinux>` boot from a storage device - :doc:`extlinux / syslinux <extlinux>` boot from a network (PXE) - :doc:`sandbox <sandbox>` used only for testing + - :doc:`RAUC distro <rauc>`: A/B system with RAUC from MMC - :doc:`U-Boot scripts <script>` from disk, network or SPI flash - :doc:`QFW <qfw>`: QEMU firmware interface - :doc:`VBE </develop/vbe>`: Verified Boot for Embedded diff --git a/doc/develop/bootstd/rauc.rst b/doc/develop/bootstd/rauc.rst new file mode 100644 index 00000000000..b2661d18da4 --- /dev/null +++ b/doc/develop/bootstd/rauc.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +RAUC Bootmeth +============= + +This bootmeth provides a way to locate and run an A/B system with RAUC as its +update client. The booted distro must supply a script on an MMC device +containing the final boot instructions necessary. + +This bootmeth assumes a symmetric A/B partition layout, with a separate boot +partition containing the kernel image and another partition for the root +filesystem each. The partition numbers must be specified with +``CONFIG_BOOTMETH_RAUC_PARTITIONS``. The content must be a list of pairs, with +the following syntax: ``1,2 3,4``, where 1 and 3 are the slots' boot partition +and 2 and 4 the slots' root partition. + +Each pair of boot and rootfs partition form a "slot". The default order in which +available slots are tried is set through ``CONFIG_BOOTMETH_RAUC_BOOT_ORDER``, +with the left one tried first. + +The default number of boot tries of each slot is set by +``CONFIG_BOOTMETH_RAUC_DEFAULT_TRIES``. + +In case no valid slot can be found and/or all slots have zero tries left, the +boot order and slot tries are reset to their default values, if +``CONFIG_BOOTMETH_RAUC_RESET_ALL_ZERO_TRIES`` is enabled. This prevents a system +from locking up in the bootloader and tries booting again after a specified +number of tries. + +The boot script must be located in each boot partition. The bootmeth searches +for "boot.scr.uimg" first, then "boot.scr" if not found. + +When the bootflow is booted, the bootmeth sets these environment variables: + +devtype + device type (e.g. "mmc") + +devnum + device number, corresponding to the device 'sequence' number + ``dev_seq(dev)`` + +distro_bootpart + partition number of the boot partition on the device (numbered from 1) + +distro_rootpart + partition number of the rootfs partition on the device (numbered from 1) + +raucargs + kernel command line arguments needed for RAUC to detect the currently booted + slot + +The script file must be a FIT or a legacy uImage. It is loaded into memory and +executed. + +The compatible string "u-boot,distro-rauc" is used for the driver. It is present +if ``CONFIG_BOOTMETH_RAUC`` is enabled. diff --git a/doc/develop/cyclic.rst b/doc/develop/cyclic.rst index 6f1da6f0d9b..a99b17052f5 100644 --- a/doc/develop/cyclic.rst +++ b/doc/develop/cyclic.rst @@ -54,3 +54,16 @@ responsible for calling all registered cyclic functions, into the common schedule() function. This guarantees that cyclic_run() is executed very often, which is necessary for the cyclic functions to get scheduled and executed at their configured periods. + +Idempotence +----------- + +Both the cyclic_register() and cyclic_unregister() functions are safe +to call on any struct cyclic_info, regardless of whether that instance +is already registered or not. + +More specifically, calling cyclic_unregister() with a cyclic_info +which is not currently registered is a no-op, while calling +cyclic_register() with a cyclic_info which is currently registered +results in it being automatically unregistered, and then registered +with the new callback function and timeout parameters. diff --git a/doc/develop/expo.rst b/doc/develop/expo.rst index cc7c36173db..b94340e9a8d 100644 --- a/doc/develop/expo.rst +++ b/doc/develop/expo.rst @@ -65,6 +65,8 @@ item is highlighted. A `textline object` contains a label and an editable string. +A `box object` is a rectangle with a given line width. It is not filled. + All components have a name. This is mostly for debugging, so it is easy to see what object is referred to, although the name is also used for saving values. Of course the ID numbers can help as well, but they are less easy to @@ -105,6 +107,37 @@ refer to objects which have been created. So a menu item is just a collection of IDs of text and image objects. When adding a menu item you must create these objects first, then create the menu item, passing in the relevant IDs. +Position and alignment +~~~~~~~~~~~~~~~~~~~~~~ + +Objects are typically positioned automatically, when scene_arrange() is called. +However it is possible to position objects manually. The scene_obj_set_pos() +sets the coordinates of the top left of the object. + +All objects have a bounding box. Typically this is calculated by looking at the +object contents, in `scene_calc_arrange()`. The calculated dimensions of each +object are stored in the object's `dims` field. + +It is possible to adjust the size of an object with `scene_obj_set_size()` or +even set the bounding box, with `scene_obj_set_bbox()`. The `SCENEOF_SIZE_VALID` +flag tracks whether the width/height should be maintained when the position +changes. + +If the bounding box is larger than the object needs, the object can be aligned +to different edges within the box. Objects can be left- or right-aligned, +or centred. For text objects this applies to each line of text. Normally objects +are drawn starting at the top of their bounding box, but they can be aligned +vertically to the bottom, or centred vertically within the box. + +Where the width of a text object's bounding box is smaller than the space needed +to show the next, the text is word-wrapped onto multiple lines, assuming there +is enough vertical space. Newline characters in the next cause a new line to be +started. The measurement information is created by the Truetype console driver +and stored in an alist in `struct scene_txt_generic`. + +When the object is drawn the `ofs` field indicates the x and y offset to use, +from the top left of the bounding box. These values are affected by alignment. + Creating an expo ---------------- @@ -527,6 +560,7 @@ Future ideas Some ideas for future work: - Default menu item and a timeout +- Complete the text editor - Image formats other than BMP - Use of ANSI sequences to control a serial terminal - Colour selection diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 0c83ef109ab..3c044e67927 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -46,6 +46,7 @@ Implementation cedit event global_data + lmb logging makefiles menus diff --git a/doc/develop/lmb.rst b/doc/develop/lmb.rst new file mode 100644 index 00000000000..b9d0f09c2bb --- /dev/null +++ b/doc/develop/lmb.rst @@ -0,0 +1,166 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Logical Memory Blocks (LMB) +=========================== + +U-Boot has support for reserving chunks of memory which is primarily +used for loading images to the DRAM memory, before these are booted, +or written to non-volatile storage medium. This functionality is +provided through the Logical Memory Blocks (LMB) module. + +Introduction +------------ + +The LMB module manages allocation requests for memory region not +occupied by the U-Boot image. Allocation requests that are made +through malloc() and similar functions result in memory getting +allocated from the heap region, which is part of the U-Boot +image. Typically, the heap memory is a few MiB in size. Loading an +image like the linux kernel might require lot more memory than what +the heap can provide. Such allocations are usually handled through the +LMB module. + +The U-Boot image typically gets relocated to the top of the usable +DRAM memory region. A typical memory layout looks as follows:: + + + + + + | | + | | + | | + | | + | | + --- +--------------+ <--- U-Boot ram top + | | | + | | Text | + | +--------------+ + | | | + | | Data | + | +--------------+ + | | | + | | BSS | + U-Boot Image +--------------+ + | | | + | | Heap | + | | | + | +--------------+ + | | | + | | | + | | Stack | + | | | + | | | + --- +--------------+ + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + | | + +--------------+ <--- ram start + + + +The region of memory below the U-Boot image is the one controlled by +the LMB module. + + +Types of LMB Allocations +------------------------ + +There are two classes of allocation requests that get made to the LMB +module. One type of allocation requests are requesting memory of a +particular number of bytes. This type of allocation is similar to that +done using the malloc type of function calls. The other type of +allocations, are requests made for a specific memory address. The +second type of allocations are usually made for loading images to a +particular memory address. + + +LMB design Pre 2025.01 +---------------------- + +The earlier versions of U-Boot (pre 2025.01 release) +had a local memory map based LMB implementation whereby it was +possible to declare the LMB map inside a function or a C file. This +design resulted in temporary, non-global LMB maps, which also allowed +for re-use of memory. This meant that it was possible to use a region +of memory to load some image, and subsequently the same region of +memory could be used for loading a different image. A typical example +of this usage would be loading an image to a memory address, followed +by writing that image to some non-volatile storage medium. Once this +is done, the same address can be used for loading a different image +and then writing it to it's non-volatile storage +destination. Typically, environment variables like `loadaddr`, +`kernel_addr_r`, `ramdisk_addr_r` are used for loading images to +memory regions. + + +Current LMB implementation +-------------------------- + +Changes were made in the 2025.01 release to make the LMB memory map +global and persistent. With this, the LMB memory map is the same +across all of U-Boot, and also persists as long as U-Boot is +active. Even with this change, there has been consistency as far as +re-use of memory is concerned to maintain backward compatibility. It +is allowed for re-requesting the same region of memory if the memory +region has a particular attribute (LMB_NONE). + +As part of the platform boot, DRAM memory available for use in U-Boot +gets added to the LMB memory map. Any allocation requests made +subsequently will be made from this memory added as part of the board +init. + + +Allocation API +-------------- + +Any request for non-heap memory can be made through the LMB allocation +API. + +.. code-block:: c + + int lmb_alloc_mem(enum lmb_mem_type type, u64 align, + phys_addr_t *addr, phys_size_t size, + u32 flags); + +Correspondingly, the allocated memory can be free'd + +.. code-block:: c + + long lmb_free(phys_addr_t base, phys_size_t size, u32 flags); + +For a detailed API description, please refer to the header file. + + +UEFI allocations with LMB as the backend +---------------------------------------- + +The UEFI specification describes boot-time API's for allocation of +memory. These API's use the same memory that is being used by the LMB +module. Pre 2025.01 release, there wasn't any synchronisation between +the EFI sub-system and the LMB module about the memory that was +getting allocated by each of these modules. This was the primary +reason for making the LMB memory map global and persistent. With this +change, the EFI memory allocation API's have also been changed to use +the LMB module as the backend for the allocation requests. Any other +sub-system which might wish to use the same memory region for it's use +can then use the LMB as the backend for the memory allocations and +it's associated book-keeping. + + +API documentation +----------------- + +.. kernel-doc:: include/lmb.h + diff --git a/doc/develop/makefiles.rst b/doc/develop/makefiles.rst index 37a7deaca92..593556f4dd5 100644 --- a/doc/develop/makefiles.rst +++ b/doc/develop/makefiles.rst @@ -1430,10 +1430,13 @@ When kbuild executes, the following steps are followed (roughly): A central rule exists to create `$(obj)/%.dtb` from `$(src)/%.dts`; architecture Makefiles do no need to explicitly write out that rule. + The device tree can now be padded by the specified number of bytes + by setting CONFIG_SYS_DTC_PAD_BYTES instead of explicitly setting + DTC_FLAGS with the -p option. + Example:: targets += $(dtb-y) - DTC_FLAGS ?= -p 1024 7.9 Preprocessing linker scripts -------------------------------- diff --git a/doc/develop/pics/patman.jpg b/doc/develop/pics/patman.jpg Binary files differnew file mode 100644 index 00000000000..2dcf598e088 --- /dev/null +++ b/doc/develop/pics/patman.jpg diff --git a/doc/develop/pytest/index.rst b/doc/develop/pytest/index.rst index 0a7c1b21a24..dce8a96370f 100644 --- a/doc/develop/pytest/index.rst +++ b/doc/develop/pytest/index.rst @@ -16,12 +16,6 @@ Individual tests .. toctree:: :maxdepth: 1 + :glob: - test_000_version - test_bind - test_bootmenu - test_bootstage - test_button - test_efi_loader - test_net - test_net_boot + test_* diff --git a/doc/develop/pytest/usage.rst b/doc/develop/pytest/usage.rst index 49d269d66a7..779b2dbe24b 100644 --- a/doc/develop/pytest/usage.rst +++ b/doc/develop/pytest/usage.rst @@ -522,3 +522,27 @@ of the `ubman.config` object, for example Build configuration values (from `.config`) may be accessed via the dictionary `ubman.config.buildconfig`, with keys equal to the Kconfig variable names. + +A required configuration setting can be defined via a buildconfigspec() +annotation. The name of the configuration option is specified in lower case. The +following annotation for a test requires CONFIG_EFI_LOADER=y: + +.. code-block:: python + + @pytest.mark.buildconfigspec('efi_loader') + +Sometimes multiple configuration option supply the same functionality. If +multiple arguments are passed to buildconfigspec(), only one of the +configuration options needs to be set. The following annotation requires that +either of CONFIG_NET or CONFIG_NET_LWIP is set: + +.. code-block:: python + + @pytest.mark.buildconfigspec('net', 'net lwip') + +The notbuildconfigspec() annotation can be used to require a configuration +option not to be set. The following annotation requires CONFIG_RISCV=n: + +.. code-block:: python + + @pytest.mark.notbuildconfigspec('riscv') diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index b68b462257d..408820e3cd5 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -75,11 +75,11 @@ For the next scheduled release, release candidates were made on:: * U-Boot |next_ver|-rc2 was released on Mon 12 May 2025. -.. * U-Boot |next_ver|-rc3 was released on Mon 26 May 2025. +* U-Boot |next_ver|-rc3 was released on Mon 26 May 2025. -.. * U-Boot |next_ver|-rc4 was released on Mon 09 June 2025. +* U-Boot |next_ver|-rc4 was released on Mon 09 June 2025. -.. * U-Boot |next_ver|-rc5 was released on Mon 23 June 2025. +* U-Boot |next_ver|-rc5 was released on Mon 23 June 2025. Please note that the following dates are planned only and may be deviated from as needed. diff --git a/doc/device-tree-bindings/config.txt b/doc/device-tree-bindings/config.txt index f50c68bbdc3..fffb69e75de 100644 --- a/doc/device-tree-bindings/config.txt +++ b/doc/device-tree-bindings/config.txt @@ -70,13 +70,13 @@ u-boot,mmc-env-offset-redundant (int) u-boot,mmc-env-partition (int) if present, the environment shall be placed at the last CONFIG_ENV_SIZE blocks of the partition on the - CONFIG_SYS_MMC_ENV_DEV. + CONFIG_ENV_MMC_DEVICE_INDEX. if u-boot,mmc-env-offset* is present, this setting will take precedence. In that case, only if the partition is not found, mmc-env-offset* will be tried. - Note that CONFIG_ENV_MMC_PARTITION overrides this device-tree setting. + Note that CONFIG_ENV_MMC_SW_PARTITION overrides this device-tree setting. u-boot,no-apm-finalize (bool) For x86 devices running on coreboot, this tells U-Boot not to lock diff --git a/doc/usage/cmd/bootefi.rst b/doc/usage/cmd/bootefi.rst index 3efe9e9df57..d6e4e62e383 100644 --- a/doc/usage/cmd/bootefi.rst +++ b/doc/usage/cmd/bootefi.rst @@ -20,19 +20,19 @@ Synopsis Description ----------- -The *bootefi* command is used to launch a UEFI binary which can be either of +The *bootefi* command is used to launch a UEFI binary which can be any of * UEFI application * UEFI boot services driver * UEFI run-time services driver An operating system requires a hardware description which can either be -presented as ACPI table (CONFIG\_GENERATE\_ACPI\_TABLE=y) or as device-tree. -The load address of the device-tree may be provided as parameter *fdt\_addr*. If +presented as ACPI table (CONFIG_GENERATE_ACPI_TABLE=y) or as device-tree. +The load address of the device-tree may be provided as parameter *fdt_addr*. If this address is not specified, the bootefi command will try to fall back in sequence to: -* the device-tree specified by environment variable *fdt\_addr* +* the device-tree specified by environment variable *fdt_addr* * the device-tree specified by environment variable *fdtcontroladdr* The load address of the binary is specified by parameter *image_address*. A @@ -110,7 +110,7 @@ U-Boot can be compiled with UEFI unit tests. These unit tests are invoked using the *bootefi selftest* sub-command. Which unit test is executed is controlled by the environment variable -*efi\_selftest*. If this variable is not set, all unit tests that are not marked +*efi_selftest*. If this variable is not set, all unit tests that are not marked as 'on request' are executed. To show a list of the available unit tests the value *list* can be used @@ -126,7 +126,7 @@ To show a list of the available unit tests the value *list* can be used 'configuration tables' ... -A single test is selected for execution by setting the *efi\_selftest* +A single test is selected for execution by setting the *efi_selftest* environment variable to match one of the listed identifiers :: @@ -140,10 +140,10 @@ return to the command line but require a board reset. Configuration ------------- -To use the *bootefi* command you must specify CONFIG\_CMD\_BOOTEFI=y. -The *bootefi bootmgr* sub-command requries CMD\_BOOTEFI\_BOOTMGR=y. -The *bootefi hello* sub-command requries CMD\_BOOTEFI\_HELLO=y. -The *bootefi selftest* sub-command depends on CMD\_BOOTEFI\_SELFTEST=y. +To use the *bootefi* command you must specify CONFIG_CMD_BOOTEFI=y. +The *bootefi bootmgr* sub-command requries CMD_BOOTEFI_BOOTMGR=y. +The *bootefi hello* sub-command requries CMD_BOOTEFI_HELLO=y. +The *bootefi selftest* sub-command depends on CMD_BOOTEFI_SELFTEST=y. See also -------- diff --git a/doc/usage/cmd/gpt.rst b/doc/usage/cmd/gpt.rst index 8534f78cbac..13e8783be9b 100644 --- a/doc/usage/cmd/gpt.rst +++ b/doc/usage/cmd/gpt.rst @@ -54,7 +54,7 @@ partition string * name=<NAME> - The partition name, required * start=<BYTES> - The partition start offset in bytes, required - * size=<BYTES> - The partition size in bytes or "-" to expand it to the whole free area + * size=<BYTES> - The partition size in bytes or "-" for the last partition to expand it to the whole free area * bootable - Set the legacy bootable flag * uuid=<UUID> - The partition UUID, optional if CONFIG_RANDOM_UUID=y is enabled * type=<UUID> - The partition type GUID, requires CONFIG_PARTITION_TYPE_GUID=y @@ -63,6 +63,23 @@ partition string If 'uuid' is not specified, but CONFIG_RANDOM_UUID is enabled, a random UUID will be generated for the partition + If 'type' is not specified or without CONFIG_PARTITION_TYPE_GUID=y, + the used partition type GUID is PARTITION_BASIC_DATA_GUID. + + Some strings can be also used at the place of the known partition type GUID: + * "mbr" = LEGACY_MBR_PARTITION_GUID (024DEE41-33E7-11D3-9D69-0008C781F39F) + * "msft" = PARTITION_MSFT_RESERVED_GUID (E3C9E316-0B5C-4DB8-817D-F92DF00215AE) + * "data" = PARTITION_BASIC_DATA_GUID (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) + * "linux" = PARTITION_LINUX_FILE_SYSTEM_DATA_GUID (0FC63DAF-8483-4772-8E79-3D69D8477DE4) + * "raid" = PARTITION_LINUX_RAID_GUID (A19D880F-05FC-4D3B-A006-743F0F84911E) + * "swap" = PARTITION_LINUX_SWAP_GUID (0657FD6D-A4AB-43C4-84E5-0933C84B4F4F) + * "lvm" = PARTITION_LINUX_LVM_GUID (E6D6D379-F507-44C2-A23C-238F2A3DF928) + * "u-boot-env" = PARTITION_U_BOOT_ENVIRONMENT(3DE21764-95BD-54BD-A5C3-4ABE786F38A8) + * "system" = PARTITION_SYSTEM_GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) + + The GPT partitions layout and associated 'type' are also printed with the + :doc:`part command <part>` command by typing "part list". + gpt enumerate ~~~~~~~~~~~~~ @@ -162,16 +179,17 @@ Examples Create 6 partitions on a disk:: - => setenv gpt_parts 'uuid_disk=bec9fc2a-86c1-483d-8a0e-0109732277d7; - name=boot,start=4M,size=128M,bootable,type=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7, - name=rootfs,size=3072M,type=0fc63daf-8483-4772-8e79-3d69d8477de4; - name=system-data,size=512M,type=0fc63daf-8483-4772-8e79-3d69d8477de4; - name=[ext],size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4; - name=user,size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4; - name=modules,size=100M,type=0fc63daf-8483-4772-8e79-3d69d8477de4; - name=ramdisk,size=8M,type=0fc63daf-8483-4772-8e79-3d69d8477de4 + => setenv gpt_parts 'uuid_disk=bec9fc2a-86c1-483d-8a0e-0109732277d7;\ + name=boot,start=4M,size=128M,bootable,type=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7;\ + name=rootfs,size=3072M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;\ + name=system-data,size=512M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;\ + name=user,size=512M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;\ + name=modules,size=100M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;\ + name=ramdisk,size=8M,type=0fc63daf-8483-4772-8e79-3d69d8477de4;\ + name=[ext],size=-,type=0fc63daf-8483-4772-8e79-3d69d8477de4' => gpt write mmc 0 $gpt_parts +Last partition "[ext]" with '-' is extended up to the end of the disk Verify that the device matches the partition layout described in the variable $gpt_parts:: @@ -228,3 +246,60 @@ Swap the order of the 'boot' and 'rootfs' partition table entries:: => gpt setenv mmc 0 boot => echo ${gpt_partition_entry} 2 + +Other example: a disk with known partition types:: + + => setenv gpt_parts 'name=u-boot,size=32M,type=data;\ + name=env,size=1M,type=u-boot-env; + name=ESP,size=128M,type=system; + name=rootfs,size=3072M,type=linux; + name=swap,size=100M,type=swap; + name=user,size=-,type=linux' + => gpt write mmc 0 $gpt_parts + + => part list mmc 0 + Partition Map for mmc device 0 -- Partition Type: EFI + Part Start LBA End LBA Name + Attributes + Type GUID + Partition GUID + 1 0x00000022 0x00010021 "u-boot" + attrs: 0x0000000000000000 + type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 + (data) + guid: 502d48f6-81c0-488f-bdc0-ad602498f3ce + 2 0x00010022 0x00010821 "env" + attrs: 0x0000000000000000 + type: 3de21764-95bd-54bd-a5c3-4abe786f38a8 + (u-boot-env) + guid: 9dc62338-459a-485e-bd8f-b3fbf728d9c0 + 3 0x00010822 0x00050821 "ESP" + attrs: 0x0000000000000000 + type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b + (EFI System Partition) + guid: 8a3a1168-6af8-4ba7-a95d-9cd0d14e1b3d + 4 0x00050822 0x00650821 "rootfs" + attrs: 0x0000000000000000 + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 + (linux) + guid: 411ffebc-8a19-469d-99a9-0982409a6851 + 5 0x00650822 0x00682821 "swap" + attrs: 0x0000000000000000 + type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f + (swap) + guid: f8ec0410-95ec-4e3e-8b98-fb8cf271a201 + 6 0x00682822 0x01dacbde "user" + attrs: 0x0000000000000000 + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 + (linux) + guid: c5543e1c-566d-4502-99ad-20545007e673 + +Modifying GPT partition layout from U-Boot:: + + => gpt read mmc 0 current_partitions + => env edit current_partitions + edit: uuid_disk=[...];name=part1,start=0x4000,size=0x4000,uuid=[...]; + name=part2,start=0xc000,size=0xc000,uuid=[...];[ . . . ] + + => gpt write mmc 0 $current_partitions + => gpt verify mmc 0 $current_partitions diff --git a/doc/usage/cmd/setexpr.rst b/doc/usage/cmd/setexpr.rst index 593a0ea91e1..5bc37ae50fc 100644 --- a/doc/usage/cmd/setexpr.rst +++ b/doc/usage/cmd/setexpr.rst @@ -144,8 +144,9 @@ Configuration * The *setexpr* command is only available if CMD_SETEXPR=y. * The *setexpr fmt* sub-command is only available if CMD_SETEXPR_FMT=y. -* The *setexpr gsub* and *setexpr sub* sub-commands are only available if - CONFIG_REGEX=y. +* The *setexpr gsub* and *setexpr sub* sub-commands are only available + if CONFIG_REGEX=y. For an overview of the supported regex syntax, + see :doc:`test`. Return value ------------ diff --git a/doc/usage/cmd/test.rst b/doc/usage/cmd/test.rst new file mode 100644 index 00000000000..d1379117fca --- /dev/null +++ b/doc/usage/cmd/test.rst @@ -0,0 +1,102 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +.. index:: + single: test (command) + +test command +============ + +Synopsis +-------- + +:: + + test <str-op> <s> + test <s1> <str-cmp> <s2> + test <n1> <num-cmp> <n2> + test ! <expr> + test <expr1> -o <expr2> + test <expr1> -a <expr2> + test -e <interface> <dev[:part]> <path> + test <s> =~ <re> + +Description +----------- + +The ``test`` command is similar to the ordinary shell built-in by the +same name. Unlike in ordinary shells, it cannot be spelled ``[``. + +Strings +~~~~~~~ + +The string tests ``-n`` and ``-z``, and string comparison operators +``=``, ``!=``, ``<`` and ``>``, work exactly as in ordinary shells. + +Numbers +~~~~~~~ + +The number comparison operators ``-lt``, ``-le``, ``-gt``, ``-gt``, +``-eq`` and ``-ne`` work as in ordinary shells. + +.. note:: + Numbers are parsed with ``simple_strtol(, 0)``, meaning that they + are treated as decimal unless there is a `0x` prefix, any errors in + parsing are ignored, and parsing stops as soon as a non-digit (for + the selected base) is encountered. And most U-Boot commands that + generate "numeric" environment variables store them as hexadecimal + *without* a `0x` prefix. + +For example, this is not a correct way of testing whether a given file +has a size less than 4KiB:: + + # Assuming readme.txt exists, sets 'filesize' environment variable + $ size mmc 0:1 readme.txt + $ if test "$filesize" -lt 4096 ; then ... + +If the file size is actually 8000 (decimal), its hexadecimal +representation, and thus the value of ``$filesize``, is ``1f40``, so +the comparison that is done ends up being "1 < 4096". + +Logic +~~~~~ + +The ``!`` operator negates the sense of the test of the expression +``<expr>``. + +The ``-o`` and ``-a`` operators perform logical OR and logical AND, +respectively, of the two expressions. + +File existence +~~~~~~~~~~~~~~ + +Like ordinary shells, the ``-e`` operator can be used to test for +existence of a file. However, the U-Boot version takes three +arguments: + +- The interface (e.g. ``mmc``). +- The device number, possibly including a partition specification. +- The usual path argument, which is interpreted relative to the root + of the filesystem. + +Regular expressions +~~~~~~~~~~~~~~~~~~~ + +When ``CONFIG_REGEX`` is enabled, an additional operator ``=~`` is +available. This is similar to the same operator available with bash's +extended test command ``[[ ]]``. The left operand is a string which is +matched against the regular expression described by the right operand. + +The regular expression engine supports these features: + +- Anchoring ``^`` and ``$``, matching at the beginning/end of the + string. +- Matching any single character (including whitespace) using ``.``. +- Character classes ``[ ]``, including ranges ``[0-9]`` and negation + ``[^ /.]``. +- Grouping ``( )``. +- Alternation ``|``. +- Postfix qualifiers ``*``, ``+`` and ``?`` and their non-greedy + variants ``*?``, ``+?`` and ``??`` + +For extracting the parts matching a capture group and/or performing +substitutions, including back references, see :doc:`setexpr`. diff --git a/doc/usage/cmd/wget.rst b/doc/usage/cmd/wget.rst index cc82e495a29..06df2842549 100644 --- a/doc/usage/cmd/wget.rst +++ b/doc/usage/cmd/wget.rst @@ -141,9 +141,9 @@ https://cacerts.digicert.com/DigiCertTLSRSA4096RootG5.crt. Bytes transferred = 1864 (748 hex) # Another server not signed against Digicert will fail => wget https://www.google.com/ - Certificate verification failed HTTP client error 4 + Certificate verification failed # Disable authentication to allow the command to proceed anyways => wget cacert none => wget https://www.google.com/ @@ -185,13 +185,6 @@ TCP Selective Acknowledgments in the legacy network stack can be enabled via CONFIG_PROT_TCP_SACK=y. This will improve the download speed. Selective Acknowledgments are enabled by default with lwIP. -.. note:: - - U-Boot currently has no way to verify certificates for HTTPS. - A place to store the root CA certificates is needed, and then MBed TLS would - need to walk the entire chain. Therefore, man-in-the middle attacks are - possible and HTTPS should not be relied upon for payload authentication. - Return value ------------ diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst index 7e2f2863d06..bb6c351b441 100644 --- a/doc/usage/environment.rst +++ b/doc/usage/environment.rst @@ -562,8 +562,8 @@ only effect after the next boot (yes, that's just like Windows). External environment file ------------------------- -The `CONFIG_USE_DEFAULT_ENV_FILE` option provides a way to bypass the -environment generation in U-Boot. If enabled, then `CONFIG_DEFAULT_ENV_FILE` +The `CONFIG_ENV_USE_DEFAULT_ENV_TEXT_FILE` option provides a way to bypass the +environment generation in U-Boot. If enabled, then `CONFIG_ENV_DEFAULT_ENV_TEXT_FILE` provides the name of a file which is converted into the environment, completely bypassing the standard environment variables in `env_default.h`. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 372ef56c967..c5b45fd9290 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -123,6 +123,7 @@ Shell commands cmd/source cmd/tcpm cmd/temperature + cmd/test cmd/tftpput cmd/trace cmd/true |
