diff options
Diffstat (limited to 'doc')
83 files changed, 4259 insertions, 516 deletions
diff --git a/doc/CONTRIBUTE.rst b/doc/CONTRIBUTE.rst index a47dfdca221..a95b9c98263 100644 --- a/doc/CONTRIBUTE.rst +++ b/doc/CONTRIBUTE.rst @@ -19,17 +19,16 @@ projects available to review if you are unsure of expectations. Repository ---------- -The official U-Boot repository is located at https://source.denx.de/u-boot/u-boot +The official U-Boot repository is located at https://git.u-boot-project.org/u-boot/u-boot -Further more detailed documentation can be found at the following link: -https://docs.u-boot.org/en/latest/index.html +Further more detailed documentation can be found at the following link: :doc:`/index`. Contributions ------------- Contributions to the project are welcome. The U-Boot project uses a fairly traditional Linux style development work-flow using git and `a mailing list -<https://lists.denx.de/listinfo/u-boot>`_. +<https://lists.u-boot-project.org/listinfo/u-boot>`_. Patches should be sent to the mailing list using ``git send-email`` or the equivalent commands using ``b4`` or ``patman`` with appropriate sign-off and @@ -39,6 +38,22 @@ script. Please don't send patches as attachments, and ensure corporate mail systems don't reformat patches, append disclaimers or other unnecessary notes. The b4 tool automates a number of components mentioned above. +Code is not the only thing you can contribute to the project. As most +open-source projects, the U-Boot project suffers from a lack of reviewers. +Consider spending some time reading patches on `the mailing list archive +<https://lists.u-boot-project.org/pipermail/u-boot/>`_ and providing feedback to +contributors when something could be improved or if you have questions. Contrary +to what's most often believed, you do not need to be an expert to review patches +and the project will benefit from people with different skillsets and experience +looking at the same patches and each catch different bugs. + +The project would also benefit from more :ref:`develop/index:testing`. + +New sections or updates to the documentation are most welcome, e.g. +:ref:`usage/index:shell commands`. See :doc:`/develop/docstyle`. + +Thank you for your help! + Patch Series ------------ diff --git a/doc/README.gpt b/doc/README.gpt index 386ac2e0fc8..a6e1fd7ce8d 100644 --- a/doc/README.gpt +++ b/doc/README.gpt @@ -286,6 +286,8 @@ Some strings can be also used at the place of known GUID : (E6D6D379-F507-44C2-A23C-238F2A3DF928) "u-boot-env" = PARTITION_U_BOOT_ENVIRONMENT (3DE21764-95BD-54BD-A5C3-4ABE786F38A8) + "xbootldr" = PARTITION_XBOOTLDR + (BC13C2FF-59E6-4262-A352-B275FD6F7172) "uuid_disk=...;name=u-boot,size=60MiB,uuid=...; name=kernel,size=60MiB,uuid=...,type=linux;" diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst index 19e2ee9d407..96c544ae11b 100644 --- a/doc/android/fastboot.rst +++ b/doc/android/fastboot.rst @@ -212,6 +212,15 @@ or initiate a reboot:: and once the client comes back, the board should reset. +It's possible to interrupt the fastboot command using Ctrl-c:: + + => fastboot usb 0 + Operation aborted. + +``CONFIG_CMD_FASTBOOT_ABORT_KEYED`` can be enabled so that *any* keypress +will interrupt the fastboot command, rather than just Ctrl-c. This can be +quite useful on mobile devices which lack a means to input Ctrl-c. + You can also specify a kernel image to boot. You have to either specify the an image in Android format *or* pass a binary kernel and let the fastboot client wrap the Android suite around it. On OMAP for instance you diff --git a/doc/board/alliedtelesis/index.rst b/doc/board/alliedtelesis/index.rst new file mode 100644 index 00000000000..a8de2986609 --- /dev/null +++ b/doc/board/alliedtelesis/index.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2026 Allied Telesis Labs + +Allied Telesis +============== + +.. toctree:: + :maxdepth: 2 + + x220 + diff --git a/doc/board/alliedtelesis/x220.rst b/doc/board/alliedtelesis/x220.rst new file mode 100644 index 00000000000..6ca5f61ec4e --- /dev/null +++ b/doc/board/alliedtelesis/x220.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2026 Allied Telesis Labs + +x220 Platforms +============== + +Introduction +------------ + +The x220 has is a range of L2+ switches using the Marvell AlleyCat3 switch with +integrated ARMv7 CPU. It is also sold under some different brands for different +markets. + +- x220-52GP +- x220-52GT +- x220-28GS +- GS980M/52PS +- GS980M/52 +- x230-52 + +DDR Traning (binhdr) +-------------------- + +The AlleyCat3 uses a binary blob for it's DDR training. This is launched by +the built-in bootloader prior to U-Boot starting. + +To generate binary.0 from Marvell's bin_hdr.elf use the following command + +.. prompt:: bash $ + + arm-softfloat-linux-gnueabi-objcopy -S -O binary bin_hdr.elf \ + board/alliedtelesis/x220/binary.0 + +Alternatively, it is possible to extract the binary.0 from an existing U-Boot +image + +.. prompt:: bash $ + + ./tools/dumpimage -T kwbimage -p 1 -o board/alliedtelesis/x220/binary.0 u-boot.kwb diff --git a/doc/board/amlogic/beelink-gt1-ultimate.rst b/doc/board/amlogic/beelink-gt1-ultimate.rst index a78a1a2ff25..22afae0ed40 100644 --- a/doc/board/amlogic/beelink-gt1-ultimate.rst +++ b/doc/board/amlogic/beelink-gt1-ultimate.rst @@ -30,19 +30,19 @@ U-Boot Compilation .. code-block:: bash - $ export CROSS_COMPILE=aarch64-none-elf- - $ make beelink-gt1-ultimate_defconfig - $ make + $ export CROSS_COMPILE=aarch64-none-elf- + $ make beelink-gt1-ultimate_defconfig + $ make U-Boot Signing with Pre-Built FIP repo -------------------------------------- .. code-block:: bash - $ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 - $ cd amlogic-boot-fip - $ mkdir my-output-dir - $ ./build-fip.sh beelink-gt1 /path/to/u-boot/u-boot.bin my-output-dir + $ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 + $ cd amlogic-boot-fip + $ mkdir my-output-dir + $ ./build-fip.sh beelink-gt1 /path/to/u-boot/u-boot.bin my-output-dir U-Boot Manual Signing --------------------- @@ -53,58 +53,58 @@ for signing. However you can download them from the amlogic-fip-repo. .. code-block:: bash - $ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 - $ cd amlogic-boot-fip/beelink-gt1 - $ export FIPDIR=$PWD + $ git clone https://github.com/LibreELEC/amlogic-boot-fip --depth=1 + $ cd amlogic-boot-fip/beelink-gt1 + $ export FIPDIR=$PWD Go back to the mainline U-Boot source tree then: .. code-block:: bash - $ mkdir fip - $ cp $FIPDIR/bl2.bin fip/ - $ cp $FIPDIR/acs.bin fip/ - $ cp $FIPDIR/bl21.bin fip/ - $ cp $FIPDIR/bl30.bin fip/ - $ cp $FIPDIR/bl301.bin fip/ - $ cp $FIPDIR/bl31.img fip/ - $ cp u-boot.bin fip/bl33.bin + $ mkdir fip + $ cp $FIPDIR/bl2.bin fip/ + $ cp $FIPDIR/acs.bin fip/ + $ cp $FIPDIR/bl21.bin fip/ + $ cp $FIPDIR/bl30.bin fip/ + $ cp $FIPDIR/bl301.bin fip/ + $ cp $FIPDIR/bl31.img fip/ + $ cp u-boot.bin fip/bl33.bin - $ $FIPDIR/blx_fix.sh \ - fip/bl30.bin \ - fip/zero_tmp \ - fip/bl30_zero.bin \ - fip/bl301.bin \ - fip/bl301_zero.bin \ - fip/bl30_new.bin \ - bl30 + $ $FIPDIR/blx_fix.sh \ + fip/bl30.bin \ + fip/zero_tmp \ + fip/bl30_zero.bin \ + fip/bl301.bin \ + fip/bl301_zero.bin \ + fip/bl30_new.bin \ + bl30 - $ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0 + $ python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0 - $ $FIPDIR/blx_fix.sh \ - fip/bl2_acs.bin \ - fip/zero_tmp \ - fip/bl2_zero.bin \ - fip/bl21.bin \ - fip/bl21_zero.bin \ - fip/bl2_new.bin \ - bl2 + $ $FIPDIR/blx_fix.sh \ + fip/bl2_acs.bin \ + fip/zero_tmp \ + fip/bl2_zero.bin \ + fip/bl21.bin \ + fip/bl21_zero.bin \ + fip/bl2_new.bin \ + bl2 - $ $FIPDIR/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin - $ $FIPDIR/aml_encrypt_gxl --bl3enc --input fip/bl31.img - $ $FIPDIR/aml_encrypt_gxl --bl3enc --input fip/bl33.bin - $ $FIPDIR/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig - $ $FIPDIR/aml_encrypt_gxl --bootmk \ - --output fip/u-boot.bin \ - --bl2 fip/bl2.n.bin.sig \ - --bl30 fip/bl30_new.bin.enc \ - --bl31 fip/bl31.img.enc \ - --bl33 fip/bl33.bin.enc + $ $FIPDIR/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin + $ $FIPDIR/aml_encrypt_gxl --bl3enc --input fip/bl31.img + $ $FIPDIR/aml_encrypt_gxl --bl3enc --input fip/bl33.bin + $ $FIPDIR/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig + $ $FIPDIR/aml_encrypt_gxl --bootmk \ + --output fip/u-boot.bin \ + --bl2 fip/bl2.n.bin.sig \ + --bl30 fip/bl30_new.bin.enc \ + --bl31 fip/bl31.img.enc \ + --bl33 fip/bl33.bin.enc Then write U-Boot to SD or eMMC with: .. code-block:: bash - $ DEV=/dev/boot_device - $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1 - $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=440 + $ DEV=/dev/boot_device + $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1 + $ dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=440 diff --git a/doc/board/apple/m1.rst b/doc/board/apple/m1.rst index 8fa7637629e..900c5e6d91e 100644 --- a/doc/board/apple/m1.rst +++ b/doc/board/apple/m1.rst @@ -8,21 +8,24 @@ developed by the Asahi Linux project. At this point the machines with the following SoCs work: - Apple M1 SoC (t8103) + - Apple M2 SoC (t8112) - Apple M1 Pro SoC (t6000) - Apple M1 Max SoC (t6001) - Apple M1 Ultra SoC (t6002) + - Apple M2 Pro SoC (t6020) + - Apple M2 Max SoC (t6021) + - Apple M2 Ultra SoC (t6022) On these SoCs the following hardware is supported: - S5L serial port - - SPI keyboard (on laptops) + - SPI keyboard (on M1 laptops) - Framebuffer - NVMe storage - USB 3.1 Type-C ports -Device trees are currently provided for the M1 Mac mini (2020, J274), -M1 MacBook Pro 13" (2020, J293), M1 MacBook Air (2020, J313) and M1 -iMac (2021, J456/J457). +Device trees are provided in dts/upstream/src/arm64/apple/ and available +for all M1 and M2 (t8103, t8112, t600x and t602x) devices. Building U-Boot --------------- @@ -77,7 +80,7 @@ supported SoCs. * - SoC - Base Address - * - M1 (t8103) + * - M1 (t8103) and M2 (t8112) - 0x235200000 - * - M1 Pro/Max/Ultra (t6000/t6001/t6002) + * - M1 Pro/Max/Ultra (t6000/t6001/t6002) and M2 Pro/Max/Ultra (t6020/t6021/t6022) - 0x39b200000 diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 1c91c7f3ac6..9e993ca9783 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -24,8 +24,78 @@ 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 ---------------- +Building (secure) +----------------- + +U-Boot +^^^^^^ + +- For AArch64:: + + make qemu_arm64_defconfig + make + +On successful build 'u-boot.bin' should be created. It's necessary in the following +steps (building TF-A). + +OP-TEE +^^^^^^ + +- For AArch64:: + + git clone https://github.com/OP-TEE/optee_os.git + cd optee_os + git checkout 4.9.0 + export CROSS_COMPILE64=aarch64-none-elf- + export CROSS_COMPILE32=arm-none-eabi- + make PLATFORM=vexpress-qemu_armv8a CFG_TRANSFER_LIST=y CFG_MAP_EXT_DT_SECURE=y + +At least OP-TEE v4.9.0 for AArch64 needs both compiler (64-Bit and 32-Bit edition) for +a successful build. On a successful build following files should be created under the +directory 'out/arm-plat-vexpress/core' from OP-TEE:: + + optee_os/out/arm-plat-vexpress/core/tee-header_v2.bin + optee_os/out/arm-plat-vexpress/core/tee-pageable_v2.bin + optee_os/out/arm-plat-vexpress/core/tee-pager_v2.bin + +TF-A +^^^^ + +- For AArch64:: + + git clone https://github.com/ARM-software/arm-trusted-firmware.git + cd arm-trusted-firmware + git submodule update --init + git checkout v2.14.0 + export CROSS_COMPILE=aarch64-none-elf- + export BL32=path/to/tee-header_v2.bin + export BL32_EXTRA1=path/to/tee-pager_v2.bin + export BL32_EXTRA2=path/to/tee-pageable_v2.bin + export BL33=path/to/u-boot.bin + make PLAT=qemu BL32_RAM_LOCATION=tdram SPD=opteed TRANSFER_LIST=1 all fip + +On successful build the following files should be created under the directory +'build/qemu/release' from TF-A:: + + arm-trusted-firmware/build/qemu/release/bl1.bin + arm-trusted-firmware/build/qemu/release/fip.bin + +The following file is at least created with TF-A v2.14.0 and can be directly passed +with the '-bios' option to QEMU:: + + arm-trusted-firmware/build/qemu/release/qemu_fw.bios + +If the single file ('qemu_fw.bios') doesn't exist, 'bl1.bin' and 'fip.bin' can be +concatenated with the command 'dd' alternatively:: + + dd if=bl1.bin of=qemu_fw.bios bs=4096 conv=notrunc + dd if=fip.bin of=qemu_fw.bios seek=64 bs=4096 conv=notrunc + +Building (non-secure) +--------------------- + +U-Boot +^^^^^^ Set the CROSS_COMPILE environment variable as usual, and run: - For ARM:: @@ -38,8 +108,18 @@ Set the CROSS_COMPILE environment variable as usual, and run: make qemu_arm64_defconfig make -Running U-Boot --------------- +Running U-Boot (secure) +----------------------- + +- For AArch64:: + + qemu-system-aarch64 -machine virt,secure=on,virtualization=on \ + -nographic -cpu cortex-a57 -bios qemu_fw.bios + +For additional QEMU command description see running U-Boot in non-secure state. + +Running U-Boot (non-secure) +--------------------------- The minimal QEMU command line to get U-Boot up and running is: - For ARM:: diff --git a/doc/board/index.rst b/doc/board/index.rst index 7870f1bc246..4103fef8d8f 100644 --- a/doc/board/index.rst +++ b/doc/board/index.rst @@ -10,6 +10,7 @@ Board-specific doc actions/index advantech/index andestech/index + alliedtelesis/index allwinner/index amlogic/index anbernic/index @@ -71,6 +72,7 @@ Board-specific doc theobroma-systems/index ti/index toradex/index + tq/index variscite/index wexler/index xen/index diff --git a/doc/board/intel/slimbootloader.rst b/doc/board/intel/slimbootloader.rst index 87d71a55bdc..a1d9102859b 100644 --- a/doc/board/intel/slimbootloader.rst +++ b/doc/board/intel/slimbootloader.rst @@ -170,7 +170,7 @@ Build Instruction to use ELF U-Boot $ python BuildLoader.py build <qemu or apl> -p "OsLoader.efi:LLDR:Lz4;u-boot:U-BT:Lzma" -.. _U-Boot: https://source.denx.de/ +.. _U-Boot: https://git.u-boot-project.org/ .. _`Slim Bootloader`: https://github.com/slimbootloader/ .. _`Intel FSP`: https://github.com/IntelFsp/ .. _`Getting Started`: https://slimbootloader.github.io/getting-started/ diff --git a/doc/board/nxp/imx8mq_evk.rst b/doc/board/nxp/imx8mq_evk.rst index 4b0624e7e86..4a9d9e404c5 100644 --- a/doc/board/nxp/imx8mq_evk.rst +++ b/doc/board/nxp/imx8mq_evk.rst @@ -45,11 +45,11 @@ Build U-Boot $ make imx8mq_evk_defconfig $ make -Burn the flash.bin to MicroSD card offset 33KB: +Burn the flash.bin to MicroSD card offset 32KB: .. code-block:: bash - $sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=notrunc + $sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=notrunc Boot ---- diff --git a/doc/board/nxp/index.rst b/doc/board/nxp/index.rst index 8cd24aecf33..52c8e85fa5b 100644 --- a/doc/board/nxp/index.rst +++ b/doc/board/nxp/index.rst @@ -30,3 +30,4 @@ NXP Semiconductors mx6ullevk rproc psb + quickboot diff --git a/doc/board/nxp/quickboot.rst b/doc/board/nxp/quickboot.rst new file mode 100644 index 00000000000..0fd72b4e13b --- /dev/null +++ b/doc/board/nxp/quickboot.rst @@ -0,0 +1,59 @@ +.. SPDX-License-Identifier: GPL-2.0+ + Copyright 2026 NXP + +DDR QuickBoot flow +------------------ + +Some NXP SoCs (which use OEI - iMX943, iMX95, iMX952 etc.) support saving +DDR training data (collected by OEI during Training flow) from volatile +to non-volatile memory, which is then available to OEI at next cold reboot. +OEI uses the saved data to run Quickboot flow and avoid training the DDR again. +This significantly reduces the boot time. + +The location of the quickboot data in NVM is a space left in the bootloader by +mkimage, with the size of 64K. The qb command searches for this space to +save the data. Thus, the NVM should also be a boot device and contain +the bootloader at the time of the saving. + +U-Boot provides no authentication for quickboot data, only its integrity +is verified via the CRC32. The authentication is done in OEI. With +the exception of iMX95 A0/A1, which use CRC32 as well for verifying +the data, the rest of the SoCs use ELE to verify the MAC stored +in the ddrphy_qb_state structure. + +If the quickboot data in memory is not valid (CRC32 check fails), +U-Boot does not save it to NVM. So, if OEI runs Quickboot flow -> no +data is written to volatile memory -> invalid data -> no saving happens +(qb save fails during qb check). + +After successful saving, U-Boot clears the data in volatile memory so +that qb check fails at next reboot and the NVM isn't accessed again. + +There are 2 ways to save this data, both can be enabled: + +1. automatically, in SPL (by enabling CONFIG_SPL_IMX_QB) + +- this will save the data on the current boot device (e.g. SD) +- other configs specific to the boot device need to be enabled (CONFIG_SPL_MMC_WRITE for saving to eMMC/SD) +- use for: automating qb save / saving quickboot data if using Falcon mode (skipping U-Boot proper) + +2. using qb command in U-Boot console (by enabling CONFIG_CMD_IMX_QB) + +- supports saving on the current boot device, or on another, specified device. +- supports specifying the hwpartition for eMMC (for booting from boot0/boot1) +- if flashing via uuu, the command can be added in an uuu script (boot device needs to be specified) +- use 'qb erase' to force DDR re-training +- use for: saving quickboot data during flashing / controlling the NVM to save to / forcing re-training + +:: + + # To save/erase on current boot device + # For eMMC boot1, mmc 0:2 has to be specified explicitly + => qb save/erase + + # To save/erase on other boot device + => qb save/erase mmc 0 # eMMC boot0 + => qb save/erase mmc 0:1 # eMMC boot0 + => qb save/erase mmc 0:2 # eMMC boot1 + => qb save/erase mmc 1 # SD + => qb save/erase spi # NOR SPI diff --git a/doc/board/phytec/k3-common.rst b/doc/board/phytec/k3-common.rst index ffb50b51ad6..3adb176ea8a 100644 --- a/doc/board/phytec/k3-common.rst +++ b/doc/board/phytec/k3-common.rst @@ -1,6 +1,53 @@ .. SPDX-License-Identifier: GPL-2.0+ .. sectionauthor:: Wadim Egorov <[email protected]> +Boot Flow +--------- + +The default `bootcmd` performs three steps: + +.. code-block:: + + run start_watchdog; bootflow scan -lb; run ${boot}boot + +Boot devices are scanned in the order given by `boot_targets`: + +.. code-block:: + + mmc1 mmc0 spi_flash dhcp + +For each device, U-Boot tries the boot methods listed in `bootmeths`: + +.. code-block:: + + [rauc] script efi extlinux pxe + +The `rauc` bootmeth is only present when `CONFIG_BOOTMETH_RAUC=y` is set in +the A53 defconfig. RAUC slot selection is handled entirely by the bootmeth; +no environment-side configuration is required. + +The legacy `${boot}boot` chain (`mmcboot`, `spiboot`, `netboot`) is kept for +backwards compatibility and prints a deprecation warning when run. New +deployments should rely on the standard boot mechanism (`bootflow`) only. + + +Watchdog +-------- + +`bootcmd` runs `start_watchdog` before starting the boot flow. When +`CONFIG_WATCHDOG_TIMEOUT_MSECS` is set to a non-zero value and the +`watchdog` environment variable points to a watchdog device, U-Boot enables +the watchdog with that timeout. + +After this point the OS is responsible for servicing the watchdog. If it +does not feed the watchdog before the timeout expires, the SoC will reset. +Make sure the watchdog driver is enabled and configured in the kernel and +userspace before relying on this. + +To skip the watchdog start, either build with `CONFIG_WATCHDOG_TIMEOUT_MSECS=0` +or set `watchdog_timeout_ms=0` in the environment. + + Environment ----------- diff --git a/doc/board/phytec/phycore-am62ax.rst b/doc/board/phytec/phycore-am62ax.rst index e1f741011e7..aa3518a07ff 100644 --- a/doc/board/phytec/phycore-am62ax.rst +++ b/doc/board/phytec/phycore-am62ax.rst @@ -9,7 +9,7 @@ SoM (System on Module) featuring TI's AM62Ax SoC. It can be used in combination with different carrier boards. This module can come with different sizes and models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM62Ax family. -A development Kit, called `phyBOARD-Lyra <https://www.phytec.com/product/phyboard-am62x>`_ +A development Kit, called `phyBOARD-Lyra <https://www.phytec.com/product/phyboard-am62a>`_ is used as a carrier board reference design around the AM62Ax SoM. Quickstart @@ -57,10 +57,10 @@ Set the variables corresponding to this platform: $ export UBOOT_CFG_CORTEXR=phycore_am62ax_r5_defconfig $ export UBOOT_CFG_CORTEXA=phycore_am62ax_a53_defconfig $ export TFA_BOARD=lite - $ # we dont use any extra TFA parameters + $ # we don't use any extra TFA parameters $ unset TFA_EXTRA_ARGS $ export OPTEE_PLATFORM=k3-am62ax - $ # we dont use any extra OPTEE parameters + $ # we don't use any extra OPTEE parameters $ unset OPTEE_EXTRA_ARGS 1. Trusted Firmware-A: @@ -147,7 +147,7 @@ the main domain serial port: Boot Modes ---------- -The phyCORE-AM62x development kit supports booting from many different +The phyCORE-AM62Ax development kit supports booting from many different interfaces. By default, the development kit is set to boot from the micro-SD card. To change the boot device, DIP switches S5 and S6 can be used. Boot switches should be changed with power off. diff --git a/doc/board/phytec/phycore-am62x.rst b/doc/board/phytec/phycore-am62x.rst index bd61d0c16cf..5349ba429d4 100644 --- a/doc/board/phytec/phycore-am62x.rst +++ b/doc/board/phytec/phycore-am62x.rst @@ -60,7 +60,7 @@ Set the variables corresponding to this platform: $ # we don't use any extra TFA parameters $ unset TFA_EXTRA_ARGS $ export OPTEE_PLATFORM=k3-am62x - $ # we dont use any extra OPTEE parameters + $ # we don't use any extra OPTEE parameters $ unset OPTEE_EXTRA_ARGS .. include:: ../ti/am62x_sk.rst @@ -177,6 +177,25 @@ Boot switches should be changed with power off. - 11001010 - 00100000 +DDR RAM Size +------------ + +By default, the R5 SPL detects the populated DDR size by reading the SoM +EEPROM and configures the DDR controller and the U-Boot device-tree memory +node accordingly. The phyCORE-AM62x is available with 1 GB, 2 GB, or 4 GB of +DDR. If the EEPROM cannot be read or is invalid, the SPL falls back to a +2 GB configuration. + +EEPROM-based detection can be bypassed by enabling +`CONFIG_PHYCORE_AM62X_RAM_SIZE_FIX` in the R5 defconfig and selecting one of: + +* `CONFIG_PHYCORE_AM62X_RAM_SIZE_1GB` +* `CONFIG_PHYCORE_AM62X_RAM_SIZE_2GB` +* `CONFIG_PHYCORE_AM62X_RAM_SIZE_4GB` + +This is mainly useful if no detection is needed or for boards without a +populated SoM EEPROM. + .. include:: k3-common.rst Further Information diff --git a/doc/board/phytec/phycore-am64x.rst b/doc/board/phytec/phycore-am64x.rst index 71f1fd7b404..20887d443a9 100644 --- a/doc/board/phytec/phycore-am64x.rst +++ b/doc/board/phytec/phycore-am64x.rst @@ -60,8 +60,8 @@ Set the variables corresponding to this platform: $ # we don't use any extra TFA parameters $ unset TFA_EXTRA_ARGS $ export OPTEE_PLATFORM=k3-am64x - # we don't use any extra OPTEE parameters - unset OPTEE_EXTRA_ARGS + $ # we don't use any extra OPTEE parameters + $ unset OPTEE_EXTRA_ARGS .. include:: ../ti/am62x_sk.rst :start-after: .. am62x_evm_rst_include_start_build_steps @@ -148,7 +148,7 @@ Boot Modes The phyCORE-AM64x development kit supports booting from many different interfaces. By default, the development kit is set to boot from the micro-SD -card. To change the boot device, DIP switches S5 and S6 can be used. +card. To change the boot device, DIP switches SW3 and SW4 can be used. Boot switches should be changed with power off. .. list-table:: Boot Modes @@ -175,6 +175,24 @@ Boot switches should be changed with power off. - 11011100 - 00000000 +DDR RAM Size +------------ + +By default, the R5 SPL detects the populated DDR size by reading the SoM +EEPROM and configures the DDR controller and the U-Boot device-tree memory +node accordingly. The phyCORE-AM64x is available with 1 GB or 2 GB of DDR. +If the EEPROM cannot be read or is invalid, the SPL falls back to a 2 GB +configuration. + +EEPROM-based detection can be bypassed by enabling +`CONFIG_PHYCORE_AM64X_RAM_SIZE_FIX` in the R5 defconfig and selecting one of: + +* `CONFIG_PHYCORE_AM64X_RAM_SIZE_1GB` +* `CONFIG_PHYCORE_AM64X_RAM_SIZE_2GB` + +This is mainly useful if no detection is needed or for boards without a +populated SoM EEPROM. + .. include:: k3-common.rst Further Information diff --git a/doc/board/renesas/build-env-aarch32.rst b/doc/board/renesas/build-env-aarch32.rst new file mode 100644 index 00000000000..5120a042ccb --- /dev/null +++ b/doc/board/renesas/build-env-aarch32.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas 32-bit ARM SoC build environment setup +============================================== + +In order to cross-compile U-Boot for the ARM 32-bit target, it is necessary +to install a suitable toolchain. The toolchain is available in various +distribution repositories as ``arm-linux-gnueabi-*`` or similar package. + +Debian example: + +.. code-block:: console + + $ apt install binutils-arm-linux-gnueabi cpp-arm-linux-gnueabi gcc-arm-linux-gnueabi + +Alternatively, it is possible to download prebuilt toolchain from +kernel.org cross-development toolchains page +https://www.kernel.org/pub/tools/crosstool/ . + +Once the toolchain is installed, add toolchain into ``PATH`` variable: + +.. code-block:: console + + $ export PATH=$PATH:<path/to/arm32/toolchain/bin/> + $ export CROSS_COMPILE=arm-linux-gnueabi- diff --git a/doc/board/renesas/build-env-aarch64.rst b/doc/board/renesas/build-env-aarch64.rst new file mode 100644 index 00000000000..979b599e951 --- /dev/null +++ b/doc/board/renesas/build-env-aarch64.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas 64-bit ARM SoC build environment setup +============================================== + +In order to cross-compile U-Boot for the aarch64 target, it is necessary +to install a suitable toolchain. The toolchain is available in various +distribution repositories as ``aarch64-linux-gnu-*`` or similar package. + +Debian example: + +.. code-block:: console + + $ apt install binutils-aarch64-linux-gnu cpp-aarch64-linux-gnu gcc-aarch64-linux-gnu + +Alternatively, it is possible to download prebuilt toolchain from +kernel.org cross-development toolchains page +https://www.kernel.org/pub/tools/crosstool/ . + +Once the toolchain is installed, add toolchain into ``PATH`` variable: + +.. code-block:: console + + $ export PATH=$PATH:<path/to/arm64/toolchain/bin/> + $ export CROSS_COMPILE=aarch64-linux-gnu- diff --git a/doc/board/renesas/build-env-sh.rst b/doc/board/renesas/build-env-sh.rst new file mode 100644 index 00000000000..52f5cff8198 --- /dev/null +++ b/doc/board/renesas/build-env-sh.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas 32-bit SH4 SoC build environment setup +============================================== + +In order to cross-compile U-Boot for the SH4 32-bit target, it is necessary +to install a suitable toolchain. The toolchain is available in various +distribution repositories as ``sh4-linux-gnu-*`` or similar package. + +Debian example: + +.. code-block:: console + + $ apt install binutils-sh4-linux-gnu cpp-sh4-linux-gnu gcc-sh4-linux-gnu + +Alternatively, it is possible to download prebuilt toolchain from +kernel.org cross-development toolchains page +https://www.kernel.org/pub/tools/crosstool/ . + +Once the toolchain is installed, add toolchain into ``PATH`` variable: + +.. code-block:: console + + $ export PATH=$PATH:<path/to/sh4/toolchain/bin/> + $ export CROSS_COMPILE=sh4-linux-gnu- diff --git a/doc/board/renesas/index.rst b/doc/board/renesas/index.rst index fb6558ec11b..be932aa01fb 100644 --- a/doc/board/renesas/index.rst +++ b/doc/board/renesas/index.rst @@ -7,4 +7,17 @@ Renesas :maxdepth: 2 renesas + build-env-sh + build-env-aarch32 + build-env-aarch64 + rcar-gen3-salvator-x + rcar-gen3-ulcb + rcar-gen3-geist + rcar-gen3-ebisu + rcar-gen3-draak + rcar-gen3-install + rcar-gen3-install-hf + rcar-gen3-install-sf + rcar-gen4-sparrow-hawk + rcar-gen5-ironhide rzn1 diff --git a/doc/board/renesas/rcar-gen3-draak.rst b/doc/board/renesas/rcar-gen3-draak.rst new file mode 100644 index 00000000000..7b94eaa4b23 --- /dev/null +++ b/doc/board/renesas/rcar-gen3-draak.rst @@ -0,0 +1,47 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 D3 Draak board +================================= + +- Renesas R-Car D3 Draak board: https://elinux.org/R-Car/Boards/Draak + +Build U-Boot +------------ + +Please follow :doc:`Renesas 64-bit ARM SoC build environment setup <build-env-aarch64>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make r8a77995_draak_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +Please follow :doc:`Renesas R-Car Gen3 U-Boot installation <rcar-gen3-install>` +to install U-Boot into HyperFlash. diff --git a/doc/board/renesas/rcar-gen3-ebisu.rst b/doc/board/renesas/rcar-gen3-ebisu.rst new file mode 100644 index 00000000000..f9632705abc --- /dev/null +++ b/doc/board/renesas/rcar-gen3-ebisu.rst @@ -0,0 +1,47 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 E3 Ebisu board +================================= + +- Renesas R-Car E3 Ebisu board: https://elinux.org/R-Car/Boards/Ebisu + +Build U-Boot +------------ + +Please follow :doc:`Renesas 64-bit ARM SoC build environment setup <build-env-aarch64>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make r8a77990_ebisu_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +Please follow :doc:`Renesas R-Car Gen3 U-Boot installation <rcar-gen3-install>` +to install U-Boot into HyperFlash. diff --git a/doc/board/renesas/rcar-gen3-geist.rst b/doc/board/renesas/rcar-gen3-geist.rst new file mode 100644 index 00000000000..7bedb3a79cb --- /dev/null +++ b/doc/board/renesas/rcar-gen3-geist.rst @@ -0,0 +1,45 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 M3Le Geist board +=================================== + +Build U-Boot +------------ + +Please follow :doc:`Renesas 64-bit ARM SoC build environment setup <build-env-aarch64>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make r8a779md_geist_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +Please follow :doc:`Renesas R-Car Gen3 U-Boot installation <rcar-gen3-install>` +to install U-Boot into SPI NOR. diff --git a/doc/board/renesas/rcar-gen3-install-hf.rst b/doc/board/renesas/rcar-gen3-install-hf.rst new file mode 100644 index 00000000000..d3a753eb2eb --- /dev/null +++ b/doc/board/renesas/rcar-gen3-install-hf.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 U-Boot HyperFlash installation +================================================= + +U-Boot can be installed on R-Car Gen3 systems into HyperFlash from U-Boot. + +.. note:: + + This update mechanism is only available in case the TFA has been built + with `RCAR_RPC_HYPERFLASH_LOCKED=0`. + +Install U-Boot into HyperFlash using NOR write from U-Boot +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order to install U-Boot using write into HyperFlash, first build U-Boot +for this target and collect ``u-boot.bin`` build artifact. Then start the +target, drop into U-Boot shell, and load the build artifact into DRAM at +well known address: + +.. code-block:: console + + => tftp 0x50000000 u-boot.bin + +Finally, write U-Boot into HyperFlash: + +.. code-block:: console + + => erase 0x8640000 +${filesize} && cp.w 0x50000000 0x8640000 0x80000 + +.. note:: + + The `cp.w` size parameter is in 16-bit short word units, not in Bytes. + The `cp.w` size parameter size in Bytes would be 0x100000 . + +Install U-Boot into HyperFlash using dfu_tftp update from U-Boot +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order to install U-Boot using dfu_tftp update, first build U-Boot for +this target and collect ``u-boot.bin`` build artifact. Then bundle this +``u-boot.bin`` into an update fitImage using the following fitImage source +file. The update fitImage source file is named ``update.its`` in this example: + +.. code-block:: dts + + // update.its + /dts-v1/; + + / { + description = "Update fitImage for U-Boot"; + + images { + bootparam { + description = "U-Boot"; + data = /incbin/("u-boot.bin"); + type = "standalone"; + os = "U-Boot"; + arch = "arm64"; + compression = "none"; + load = <0x8640000>; + }; + }; + }; + +Generate the update fitImage using the following command: + +.. code-block:: console + + $ mkimage -f update.its update.itb + +Then start the target, drop into U-Boot shell, and load the ``update.itb`` +artifact into DRAM at well known address: + +.. code-block:: console + + => tftp 0x50000000 update.itb && dfu tftp 0x50000000 diff --git a/doc/board/renesas/rcar-gen3-install-sf.rst b/doc/board/renesas/rcar-gen3-install-sf.rst new file mode 100644 index 00000000000..4e8667e1b48 --- /dev/null +++ b/doc/board/renesas/rcar-gen3-install-sf.rst @@ -0,0 +1,29 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 U-Boot SPI NOR installation +============================================== + +U-Boot can be installed on R-Car Gen3 systems into SPI NOR from U-Boot. + +.. note:: + + This update mechanism is only available in case the TFA has been built + with `RCAR_RPC_HYPERFLASH_LOCKED=0 SPD=none`. + +Install U-Boot into SPI NOR using write from U-Boot +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order to install U-Boot using write into SPI NOR, first build U-Boot +for this target and collect ``u-boot.bin`` build artifact. Then start the +target, drop into U-Boot shell, and load the build artifact into DRAM at +well known address: + +.. code-block:: console + + => tftp 0x50000000 u-boot.bin + +Finally, write U-Boot into SPI NOR: + +.. code-block:: console + + => sf probe && sf update 0x50000000 0x640000 $filesize diff --git a/doc/board/renesas/rcar-gen3-install.rst b/doc/board/renesas/rcar-gen3-install.rst new file mode 100644 index 00000000000..33189d9227b --- /dev/null +++ b/doc/board/renesas/rcar-gen3-install.rst @@ -0,0 +1,34 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 U-Boot installation +====================================== + +U-Boot can be installed on R-Car Gen3 systems in multiple ways. + +The generic installation method, which also requires physical hardware +access, is to install U-Boot using the `flash_writer`_ tool. This +procedure is documented below. + +Installation into the HyperFlash can be performed from U-Boot, please +refer to :doc:`Renesas R-Car Gen3 U-Boot HyperFlash installation <rcar-gen3-install-hf>` +for details. + +Installation into the SPI NOR can be performed from U-Boot, please +refer to :doc:`Renesas R-Car Gen3 U-Boot SPI NOR installation <rcar-gen3-install-sf>` +for details. + +.. note:: + + The maximum u-boot.bin size for this target is 1 MiB or 0x100000 Bytes + +Install U-Boot using flash_writer tool +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order to install U-Boot using flash_writer tool, first build U-Boot +for this target and collect ``u-boot-elf.srec`` build artifact. Then +follow the `application note`_ shipped together with the flash_writer +tool to install the ``u-boot-elf.srec`` artifact using `XLS2 command`_. + +.. _`flash_writer`: https://github.com/renesas-rcar/flash_writer +.. _`application note`: https://github.com/renesas-rcar/flash_writer/blob/rcar_gen3/docs/application-note.md +.. _`XLS2 command`: https://github.com/renesas-rcar/flash_writer/blob/rcar_gen3/docs/application-note.md#341-write-to-the-s-record-format-images-to-the-serial-flash diff --git a/doc/board/renesas/rcar-gen3-salvator-x.rst b/doc/board/renesas/rcar-gen3-salvator-x.rst new file mode 100644 index 00000000000..37f009452e5 --- /dev/null +++ b/doc/board/renesas/rcar-gen3-salvator-x.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 H3/M3-W/M3-N Salvator-X(S) board +=================================================== + +- Renesas R-Car Gen3 Salvator-X board: https://elinux.org/R-Car/Boards/Salvator-X +- Renesas R-Car Gen3 Salvator-XS board: https://elinux.org/R-Car/Boards/Salvator-XS + +Build U-Boot +------------ + +Please follow :doc:`Renesas 64-bit ARM SoC build environment setup <build-env-aarch64>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make rcar3_salvator-x_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +Please follow :doc:`Renesas R-Car Gen3 U-Boot installation <rcar-gen3-install>` +to install U-Boot into HyperFlash. diff --git a/doc/board/renesas/rcar-gen3-ulcb.rst b/doc/board/renesas/rcar-gen3-ulcb.rst new file mode 100644 index 00000000000..88ec2276a36 --- /dev/null +++ b/doc/board/renesas/rcar-gen3-ulcb.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen3 H3/M3-W/M3-N ULCB board +========================================== + +- Renesas R-Car H3 ULCB board: https://elinux.org/R-Car/Boards/H3SK +- Renesas R-Car M3-W ULCB board: https://elinux.org/R-Car/Boards/M3SK +- Renesas R-Car M3-N ULCB board: https://elinux.org/R-Car/Boards/M3NSK + +Build U-Boot +------------ + +Please follow :doc:`Renesas 64-bit ARM SoC build environment setup <build-env-aarch64>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make rcar3_ulcb_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +Please follow :doc:`Renesas R-Car Gen3 U-Boot installation <rcar-gen3-install>` +to install U-Boot into HyperFlash. diff --git a/doc/board/renesas/rcar-gen4-sparrow-hawk.rst b/doc/board/renesas/rcar-gen4-sparrow-hawk.rst new file mode 100644 index 00000000000..a1b92ecab57 --- /dev/null +++ b/doc/board/renesas/rcar-gen4-sparrow-hawk.rst @@ -0,0 +1,91 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Retronix R-Car Gen4 V4H Sparrow Hawk board +========================================== + +- Retronix R-Car V4H Sparrow Hawk board: https://www.retronix.com.tw/en/product_sbc.html +- Retronix R-Car V4H Sparrow Hawk documenation: https://rcar-community.github.io/Sparrow-Hawk/index.html + +Build U-Boot +------------ + +Please follow :doc:`Renesas 64-bit ARM SoC build environment setup <build-env-aarch64>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make r8a779g3_sparrowhawk_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +In order to install U-Boot using write into SPI NOR, first build U-Boot +for this target and collect ``flash.bin`` build artifact. Then start the +target, drop into U-Boot shell, and load the build artifact into DRAM at +well known address: + +.. code-block:: console + + => tftp 0x50000000 flash.bin + +Finally, write U-Boot into SPI NOR: + +.. code-block:: console + + => sf probe && sf update 0x50000000 0 ${filesize} + +Bundle TFA BL31 into Linux kernel fitImage +------------------------------------------ + +The Retronix R-Car V4H Sparrow Hawk board starts both TFA BL31 and Linux +kernel from U-Boot. Both TFA BL31, Linux kernel and DT blob have to be +bundled into the fitImage. + +Perform the following steps to build TFA at least v2.14.y: + +.. code-block:: console + + $ git clone https://github.com/ARM-software/arm-trusted-firmware.git + $ cd arm-trusted-firmware + $ make -j$(nproc) bl31 \ + PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \ + CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \ + PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \ + ENABLE_ASSERTIONS=0 + +The bundling is done using U-Boot ``mkimage`` tool: + +.. code-block:: console + + mkimage \ + -f auto -E -A arm64 -C none -e 0x50200000 -a 0x50200000 \ + -d /path/to/linux/arch/arm64/boot/Image \ + -b /path/to/linux/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dtb \ + -y /path/to/arm-trusted-firmware/build/rcar_gen4/*/bl31.bin \ + -Y 0x46400000 \ + /path/to/output/fitImage diff --git a/doc/board/renesas/rcar-gen5-ironhide.rst b/doc/board/renesas/rcar-gen5-ironhide.rst new file mode 100644 index 00000000000..39fbfdbfe00 --- /dev/null +++ b/doc/board/renesas/rcar-gen5-ironhide.rst @@ -0,0 +1,204 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Renesas R-Car Gen5 X5H Ironhide board +===================================== + +Renesas R-Car Gen5 X5H Ironhide board U-Boot can be built for two separate cores: + +- Cortex-M33 RSIP core, which is the boot core +- Cortex-A720AE core, which is the application core + +Cortex-A720AE target +^^^^^^^^^^^^^^^^^^^^ + +Build U-Boot +------------ + +Please follow :doc:`Renesas 64-bit ARM SoC build environment setup <build-env-aarch64>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make r8a78000_ironhide_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +In order to install U-Boot for Cortex-A720AE into UFS, first build U-Boot +for this target and collect ``u-boot-elf.srec`` build artifact. + +Next, configure the board for SCIF loader boot. Upload IPL flash_writer +mot binary. Use the tool to write ``u-boot-elf.srec`` into HyperFlash +at offset 0x8e300000 . Finally, power off the board and configure the +board back to HyperFlash boot mode. + +Cortex-M33 RSIP target +^^^^^^^^^^^^^^^^^^^^^^ + +Build U-Boot +------------ + +Please follow :doc:`Renesas 32-bit ARM SoC build environment setup <build-env-aarch32>` +to correctly set up the build environment before attempting to build U-Boot. + +Clone up to date U-Boot source code and change directory into the +newly cloned source directory: + +.. code-block:: console + + $ git clone https://source.denx.de/u-boot/u-boot.git/ + $ cd u-boot + +Configure U-Boot: + +.. code-block:: console + + $ make r8a78000_ironhide_cm33_defconfig + +Compile U-Boot: + +.. code-block:: console + + $ make + +To speed up build process, -jN option can be passed to make to start +multiple jobs at the same time, this is beneficial especially on SMP +systems. The following example starts up to number of CPUs in the +system jobs, which is the recommended amount: + +.. code-block:: console + + $ make -j$(nproc) + +Install U-Boot +-------------- + +In order to install U-Boot for RSIP into HyperFlash, first build U-Boot +for this target and collect ``u-boot-elf.shdr`` and ``u-boot-elf.srec`` +build artifacts. + +Next, configure the board for SCIF loader boot. Upload IPL flash_writer +mot binary. Use the tool to write ``u-boot-elf.shdr`` into HyperFlash +at offset 0, and ``u-boot-elf.srec`` into HyperFlash at offset 0x40000 . +Finally, power off the board and configure the board back to HyperFlash +boot mode. + +Power on the board, U-Boot on RSIP will start. Interaction with U-Boot +on RSIP is possible via HSCIF1, which is the second serial console that +is available on the USB-to-Serial adapter port. HSCIF1 is used in order +to avoid interference with software running on the Cortex-A720AE cores, +which uses HSCIF0. + +Ethernet boot of bootloader components +-------------------------------------- + +The U-Boot for RSIP is capable of ethernet access, which allows download +of bootloader components via TFTP. This is useful during development and +can be used for fast iterative testing of either SCP firmware, TFA BL31, +OPTEE-OS, U-Boot or Linux on the SCP core and Cortex-A720AE cores +respectively. + +An example U-Boot environment applicable to ``include/configs/rcar-gen5-common.h`` +or executable manually is listed below. The environment script ``rsip_ipl_boot_ca0`` +implements download of SCP firmware ``scp.bin``, TFA BL31 ``bl31.bin``, +U-Boot ``u-boot.bin`` and Linux ``fitImage`` from TFTP server at address +``192.168.1.1/24`` and starts those components on the SCP and Cortex-A720AE +cores respectively. OPTEE-OS is loaded from UFS to retain at least this +example of UFS loading, however, it perfectly fine to download OPTEE-OS +via TFTP in the same manner as the other components are downloaded: + +.. code-block:: console + + rsip_ipl_params_base=0x8c100000 + rsip_ipl_params_optee=0x8c100088 + rsip_ipl_params_uboot=0x8c100030 + rsip_ipl_scp_ep=0x8c180000 + rsip_ipl_optee_ep=0x8c400000 + rsip_ipl_tfa_ep=0x8c200000 + rsip_ipl_uboot_ep=0x8e300000 + rsip_ipl_linux_ep=0x91000000 + + rsip_ipl_params_write= /* Build handoff structure */ \ + base ${rsip_ipl_params_base} ; \ + mw 0x00 0 0x9e ; /* Clear the area */ \ + mw 0x00 0x00300103 ; /* type, version, size */ \ + mw 0x20 0x${rsip_ipl_params_uboot} ; /* U-Boot descriptor */ \ + \ + base ${rsip_ipl_params_uboot} ; \ + mw 0x00 0x00580101 ; /* type, version, size */ \ + mw 0x04 0x00000001 ; /* attr */ \ + mw 0x08 ${rsip_ipl_uboot_ep} ; /* U-Boot entry point */ \ + mw 0x10 0x000003c5 ; /* SPSR */ \ + \ + base ${rsip_ipl_params_optee} ; \ + mw 0x00 0x00580201 ; /* type, version, size */ \ + mw 0x04 0x00000008 ; /* attr */ \ + mw 0x08 ${rsip_ipl_optee_ep} ; /* OPTEE-OS entry point */ \ + mw 0x10 0x000003c5 ; /* SPSR */ \ + \ + base 0 + + rsip_ipl_boot_ca0= /* Start TFA BL31, OPTEE-OS, U-Boot, Linux on Cortex-A720AE core 0 */ \ + setenv ipaddr 192.168.1.10 && \ + setenv serverip 192.168.1.1 && \ + setenv netmask 255.255.255.0 && \ + \ + tftp ${rsip_ipl_scp_ep} scp.bin && \ + tftp ${rsip_ipl_tfa_ep} bl31.bin && \ + tftp ${rsip_ipl_uboot_ep} u-boot.bin && \ + tftp ${rsip_ipl_linux_ep} fitImage && \ + \ + scsi scan && /* Scan for UFS devices */ \ + rproc init && /* Start remoteproc */ \ + rproc load 0 ${rsip_ipl_scp_ep} 0x60000 && /* Load SCP STCM */ \ + rproc start 0 && /* Start SCP */ \ + scsi read ${rsip_ipl_optee_ep} 0x5200 0x200 && /* Load OPTEE-OS from UFS */ \ + run rsip_ipl_params_write && /* Write entry point descriptors */ \ + \ + rproc load 13 ${rsip_ipl_tfa_ep} 4 && /* Set up Cortex-A720AE Core 0 */ \ + rproc start 13 /* Start Cortex-A720AE Core 0 */ + + +.. note:: + + U-Boot on RSIP environment is not persistent across reboots, + but this will likely change in the upcoming U-Boot release. + +.. note:: + + U-Boot on RSIP can start the SCP core via rproc command, but + it can not stop SCP after it was started. This was intended + as a safety mechanism, since SCP is central component of the + system, however, this will likely change in the upcoming U-Boot + release. + +.. note:: + + U-Boot on RSIP can start non-SCP cores via ``rproc`` command only + after the SCP got started, because those cores are started via + SCMI calls to the SCP. diff --git a/doc/board/renesas/renesas.rst b/doc/board/renesas/renesas.rst index fedfeed42e3..c0cefc15dd8 100644 --- a/doc/board/renesas/renesas.rst +++ b/doc/board/renesas/renesas.rst @@ -14,237 +14,104 @@ Renesas SoC based boards Renesas is a SoC solutions provider for automotive and industrial applications. -.. list-table:: Supported Renesas SoC based boards - :widths: 10, 25, 15, 10, 25 - :header-rows: 1 +.. table:: Supported Renesas SoC based boards - * - Family - - Board - - SoC - - Arch - - defconfig + +--------+------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | Family | Generation | Architecture | SoC | Core | Board | defconfig | + +========+==================+==================================+====================+====================+==============================================+==================================+ + | R2D | | :doc:`SH <build-env-sh>` | SH7751 | SH4 | R2D-PLUS | r2dplus_defconfig | + +--------+------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | R-Car | | | | | Lager | lager_defconfig | + | | | | R8A7790 (H2) | Cortex A7 or A15 +----------------------------------------------+----------------------------------+ + | | | | | | Stout | stout_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | Koelsch | koelsch_defconfig | + | | | | R8A7791 (M2-W) | +----------------------------------------------+----------------------------------+ + | | | | | Cortex A15 | Porter | porter_defconfig | + | | Gen2 | :doc:`arm <build-env-aarch32>` +--------------------+ +----------------------------------------------+----------------------------------+ + | | | | R8A7792 (V2H) | | Blanche | blanche_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | R8A7793 (M2-N) | Cortex A7 or A15 | Gose | gose_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | Alt | alt_defconfig | + | | | | R8A7794 (E2) | Cortex A7 +----------------------------------------------+----------------------------------+ + | | | | | | Silk | silk_defconfig | + | +------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | :doc:`Salvator-X(S) <rcar-gen3-salvator-x>` | rcar3_salvator-x_defconfig | + | | | | R8A77951 (H3) | +----------------------------------------------+----------------------------------+ + | | | | | | :doc:`ULCB <rcar-gen3-ulcb>` | rcar3_ulcb_defconfig | + | | | +--------------------+ +----------------------------------------------+----------------------------------+ + | | | | | | :doc:`Salvator-X(S) <rcar-gen3-salvator-x>` | rcar3_salvator-x_defconfig | + | | | | R8A77960 (M3-W) | Cortex A53 or A57 +----------------------------------------------+----------------------------------+ + | | | | | | :doc:`ULCB <rcar-gen3-ulcb>` | rcar3_ulcb_defconfig | + | | | +--------------------+ +----------------------------------------------+----------------------------------+ + | | | | | | :doc:`Salvator-X(S) <rcar-gen3-salvator-x>` | rcar3_salvator-x_defconfig | + | | | | R8A77965 (M3-N) | +----------------------------------------------+----------------------------------+ + | | | | | | :doc:`ULCB <rcar-gen3-ulcb>` | rcar3_ulcb_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | Gen3 | :doc:`arm64 <build-env-aarch64>` | R8A779MD (M3Le) | Cortex A57 | :doc:`Geist <rcar-gen3-geist>` | r8a779md_geist_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | Eagle | r8a77970_eagle_defconfig | + | | | | R8A77970 (V3M) | +----------------------------------------------+----------------------------------+ + | | | | | | V3MSK | r8a77970_v3msk_defconfig | + | | | +--------------------+ +----------------------------------------------+----------------------------------+ + | | | | | | Condor | r8a77980_condor_defconfig | + | | | | R8A77980 (V3H) | Cortex A53 +----------------------------------------------+----------------------------------+ + | | | | | | V3HSK | r8a77980_v3hsk_defconfig | + | | | +--------------------+ +----------------------------------------------+----------------------------------+ + | | | | R8A77990 (E3) | | :doc:`Ebisu <rcar-gen3-ebisu>` | r8a77990_ebisu_defconfig | + | | | +--------------------+ +----------------------------------------------+----------------------------------+ + | | | | R8A77995 (D3) | | :doc:`Draak <rcar-gen3-draak>` | r8a77995_draak_defconfig | + | +------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | R8A779A0 (V3U) | Cortex A76 | Falcon | r8a779a0_falcon_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | Spider | r8a779f0_spider_defconfig | + | | | | R8A779F0 (S4) | Cortex A55 +----------------------------------------------+----------------------------------+ + | | | | | | S4SK | r8a779f4_s4sk_defconfig | + | | Gen4 | :doc:`arm64 <build-env-aarch64>` +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | White Hawk | r8a779g0_whitehawk_defconfig | + | | | | R8A779G3 (V4H) | +----------------------------------------------+----------------------------------+ + | | | | | Cortex A76 | :doc:`Sparrow Hawk <rcar-gen4-sparrow-hawk>` | r8a779g3_sparrowhawk_defconfig | + | | | +--------------------+ +----------------------------------------------+----------------------------------+ + | | | | R8A779H0 (V4M) | | Gray Hawk | r8a779h0_grayhawk_defconfig | + | +------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | :doc:`arm <build-env-aarch32>` | | Cortex M33 RSIP | | r8a78000_ironhide_cm33_defconfig | + | | Gen5 +----------------------------------+ R8A78000 (X5H) +--------------------+ :doc:`Ironhide <rcar-gen5-ironhide>` +----------------------------------+ + | | | :doc:`arm64 <build-env-aarch64>` | | Cortex A720AE | | r8a78000_ironhide_defconfig | + +--------+------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | RZ | A1 | :doc:`arm <build-env-aarch32>` | R7S72100 (RZ/A1H) | Cortex A9 | GR-PEACH | grpeach_defconfig | + | +------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | Beacon EmbeddedWorks RZ/G2M SoM | rzg2_beacon_defconfig | + | | | | R8A774A1 (RZ/G2M) | Cortex A53 or A57 +----------------------------------------------+----------------------------------+ + | | | | | | HopeRun HiHope RZ/G2M | hihope_rzg2_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | Beacon EmbeddedWorks RZ/G2N SoM | rzg2_beacon_defconfig | + | | G2 | :doc:`arm64 <build-env-aarch64>` | R8A774B1 (RZ/G2N) | Cortex A57 +----------------------------------------------+----------------------------------+ + | | | | | | HopeRun HiHope RZ/G2N | hihope_rzg2_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | R8A774C0 (RZ/G2E) | Cortex A53 | Silicon Linux RZ/G2E evaluation kit (EK874) | silinux_ek874_defconfig | + | | | +--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | | | Beacon EmbeddedWorks RZ/G2H SoM | rzg2_beacon_defconfig | + | | | | R8A774E1 (RZ/G2H) | Cortex A53 or A57 +----------------------------------------------+----------------------------------+ + | | | | | | HopeRun HiHope RZ/G2H | hihope_rzg2_defconfig | + +--------+------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ + | | | | R9A06G032 (RZ/N1D) | | Schneider RZ/N1D board | rzn1_snarc_defconfig | + | | :doc:`N1 <rzn1>` | :doc:`arm <build-env-aarch32>` +--------------------+ Cortex A7 +----------------------------------------------+----------------------------------+ + | | | | R9A06G033 (RZ/N1S) | | Schneider RZ/N1S board | rzn1_snarc_defconfig | + +--------+------------------+----------------------------------+--------------------+--------------------+----------------------------------------------+----------------------------------+ - * - R2D - - R2D-PLUS - - SH7751 - - sh - - r2dplus_defconfig +Generic build procedure +----------------------- - * - RZ/A1 - - GR-PEACH - - R7S72100 (RZ/A1H) - - arm - - grpeach_defconfig +This procedure applies only unless the ``Board`` column in +the table above does not contain a link to board specific +details. - * - R-Car Gen2 - - Lager - - R8A7790 (H2) - - arm - - lager_defconfig +Locate the appropriate defconfig in the table above. +Follow toolchain setup procedure in ``Architecture`` column. +Finally, apply standard build procedure: - * - - - Stout - - R8A7790 (H2) - - arm - - stout_defconfig - - * - - - Koelsch - - R8A7791 (M2-W) - - arm - - koelsch_defconfig - - * - - - Porter - - R8A7791 (M2-W) - - arm - - porter_defconfig - - * - - - Blanche - - R8A7792 (V2H) - - arm - - blanche_defconfig - - * - - - Gose - - R8A7793 (M2-N) - - arm - - gose_defconfig - - * - - - Alt - - R8A7794 (E2) - - arm - - alt_defconfig - - * - - - Silk - - R8A7794 (E2) - - arm - - silk_defconfig - - * - R-Car Gen3 - - Salvator-X(S) - - R8A77951 (H3) - - arm64 - - rcar3_salvator-x_defconfig - - * - - - ULCB - - R8A77951 (H3) - - arm64 - - rcar3_ulcb_defconfig - - * - - - Salvator-X(S) - - R8A77960 (M3-W) - - arm64 - - rcar3_salvator-x_defconfig - - * - - - ULCB - - R8A77960 (M3-W) - - arm64 - - rcar3_ulcb_defconfig - - * - - - Salvator-X(S) - - R8A77965 (M3-N) - - arm64 - - rcar3_salvator-x_defconfig - - * - - - ULCB - - R8A77965 (M3-N) - - arm64 - - rcar3_ulcb_defconfig - - * - - - Eagle - - R8A77970 (V3M) - - arm64 - - r8a77970_eagle_defconfig - - * - - - V3MSK - - R8A77970 (V3M) - - arm64 - - r8a77970_v3msk_defconfig - - * - - - Condor - - R8A77980 (V3H) - - arm64 - - r8a77980_condor_defconfig - - * - - - V3HSK - - R8A77980 (V3H) - - arm64 - - r8a77980_v3hsk_defconfig - - * - - - Ebisu - - R8A77990 (E3) - - arm64 - - r8a77990_ebisu_defconfig - - * - - - Draak - - R8A77995 (D3) - - arm64 - - r8a77995_draak_defconfig - - * - R-Car Gen4 - - Falcon - - R8A779A0 (V3U) - - arm64 - - r8a779a0_falcon_defconfig - - * - - - Spider - - R8A779F0 (S4) - - arm64 - - r8a779f0_spider_defconfig - - * - - - S4SK - - R8A779F4 (S4) - - arm64 - - r8a779f4_s4sk_defconfig - - * - - - White Hawk - - R8A779G0 (V4H) - - arm64 - - r8a779g0_whitehawk_defconfig - - * - - - Sparrow Hawk - - R8A779G3 (V4H) - - arm64 - - r8a779g3_sparrowhawk_defconfig - - * - RZ/G2 Family - - Beacon EmbeddedWorks RZ/G2M SoM - - R8A774A1 (RZ/G2M) - - arm64 - - rzg2_beacon_defconfig - - * - - - HopeRun HiHope RZ/G2M - - R8A774A1 (RZ/G2M) - - arm64 - - hihope_rzg2_defconfig - - * - - - Beacon EmbeddedWorks RZ/G2N SoM - - R8A774B1 (RZ/G2N) - - arm64 - - rzg2_beacon_defconfig - - * - - - HopeRun HiHope RZ/G2N - - R8A774B1 (RZ/G2N) - - arm64 - - hihope_rzg2_defconfig - - * - - - Silicon Linux RZ/G2E evaluation kit (EK874) - - R8A774C0 (RZ/G2E) - - arm64 - - silinux_ek874_defconfig - - * - - - Beacon EmbeddedWorks RZ/G2H SoM - - R8A774E1 (RZ/G2H) - - arm64 - - rzg2_beacon_defconfig - - * - - - HopeRun HiHope RZ/G2H - - R8A774E1 (RZ/G2H) - - arm64 - - hihope_rzg2_defconfig - - * - :doc:`RZ/N1 Family <rzn1>` - - Schneider RZ/N1D board - - R9A06G032 (RZ/N1D) - - arm64 - - rzn1_snarc_defconfig - - * - - - Schneider RZ/N1S board - - R9A06G033 (RZ/N1S) - - arm64 - - rzn1_snarc_defconfig - -Build ------ - -Locate the appropriate defconfig in the table above. Then apply standard build -procedure:: +.. code-block:: console make <board_defconfig> make diff --git a/doc/board/renesas/rzn1.rst b/doc/board/renesas/rzn1.rst index e6d636b89e8..24ce7709dd7 100644 --- a/doc/board/renesas/rzn1.rst +++ b/doc/board/renesas/rzn1.rst @@ -10,12 +10,14 @@ This document describes how to build and flash U-Boot for the RZ/N1. U-Boot ^^^^^^ +Please follow :doc:`Renesas 32-bit ARM SoC build environment setup <build-env-aarch32>` +to correctly set up the build environment before attempting to build U-Boot. Clone the U-Boot repository and build it as follows: .. code-block:: bash - git clone --depth 1 https://source.denx.de/u-boot/u-boot.git + git clone --depth 1 https://git.u-boot-project.org/u-boot/u-boot.git cd u-boot make rzn1_snarc_defconfig make CROSS_COMPILE=arm-linux-gnu- diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index 141071f528a..9351a5b8eae 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -126,6 +126,7 @@ List of mainline supported Rockchip boards: - Xunlong Orange Pi 3B (orangepi-3b-rk3566) * rk3568 + - 9Tripod X3568 v4 (9tripod-x3568-v4-rk3568) - Rockchip Evb-RK3568 (evb-rk3568) - Banana Pi BPI-R2 Pro (bpi-r2-pro-rk3568) - EmbedFire LubanCat 2 (lubancat-2-rk3568) @@ -133,6 +134,7 @@ List of mainline supported Rockchip boards: - FriendlyElec NanoPi R5S (nanopi-r5s-rk3568) - Generic RK3566/RK3568 (generic-rk3568) - Hardkernel ODROID-M1 (odroid-m1-rk3568) + - LinkEase EasePi R1 (easepi-r1-rk3568) - Lunzn FastRhino R66S (fastrhino-r66s-rk3568) - QNAP TS-433 (qnap-ts433-rk3568) - Radxa E25 Carrier Board (radxa-e25-rk3568) @@ -143,6 +145,7 @@ List of mainline supported Rockchip boards: - ArmSoM Sige5 (sige5-rk3576) - Firefly ROC-RK3576-PC (roc-pc-rk3576) - FriendlyElec NanoPi M5 (nanopi-m5-rk3576) + - FriendlyElec NanoPi R76S (nanopi-r76s-rk3576) - Generic RK3576 (generic-rk3576) - Luckfox Omni3576 (omni3576-rk3576) - Radxa ROCK 4D (rock-4d-rk3576) @@ -225,7 +228,7 @@ U-Boot .. code-block:: bash - git clone --depth 1 https://source.denx.de/u-boot/u-boot.git + git clone --depth 1 https://git.u-boot-project.org/u-boot/u-boot.git cd u-boot To build px30 boards: @@ -247,7 +250,7 @@ To build rk3288 boards: .. code-block:: bash - make evb-rk3288-mk808_defconfig + make evb-rk3288-rk808_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- To build rk3308 boards: diff --git a/doc/board/spacemit/bananapi-f3.rst b/doc/board/spacemit/bananapi-f3.rst index f2220950a3a..1ece2ce9d02 100644 --- a/doc/board/spacemit/bananapi-f3.rst +++ b/doc/board/spacemit/bananapi-f3.rst @@ -29,7 +29,7 @@ built for SpacemiT K1 SoC as below: .. code-block:: console cd <U-Boot-dir> - make bananapi-f3_defconfig + make spacemit_k1_defconfig make OPENSBI=<OpenSBI-dir>/build/platform/generic/firmware/fw_dynamic.bin This will generate u-boot.itb diff --git a/doc/board/spacemit/index.rst b/doc/board/spacemit/index.rst index e7d3d94e459..a5e35ee12ab 100644 --- a/doc/board/spacemit/index.rst +++ b/doc/board/spacemit/index.rst @@ -6,4 +6,5 @@ SpacemiT :maxdepth: 1 bananapi-f3 + k1-spl diff --git a/doc/board/spacemit/k1-spl.rst b/doc/board/spacemit/k1-spl.rst new file mode 100644 index 00000000000..187eed56e8e --- /dev/null +++ b/doc/board/spacemit/k1-spl.rst @@ -0,0 +1,243 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +SpacemiT K1 SPL Build and Test Guide +===================================== + +This guide explains how to build and test U-Boot SPL on SpacemiT K1 based +boards. It covers building SPL with DDR initialization, generating the signed +FSBL image, and deploying via USB fastboot. + +Tested boards: Banana Pi BPI-F3, MusePi Pro. + +.. note:: + + The procedure described here loads SPL into SRAM via USB fastboot and + does not modify the on-board flash, so a power cycle restores the + board's normal boot path. + + At this stage of the patchset, SPL initializes DDR and then halts with + "SPL: Unsupported Boot Device!" because SPI NOR storage support is not + yet available in U-Boot proper. This document will be updated when + U-Boot stage support is ready. + +Prerequisites +~~~~~~~~~~~~~ + +- A SpacemiT K1 board with USB Type-C and UART access +- USB-to-UART adapter (3.3V TTL) +- ``minicom`` or equivalent serial terminal, configured at 115200 8N1 +- ``fastboot`` tool on the host + +Hardware Setup +~~~~~~~~~~~~~~ + +**1. UART Connection** + +Remove all other cables first, then attach UART. Connect a 3.3V +USB-to-UART cable to the board's UART header (J25 on the BPI-F3):: + + BPI-F3 top view + +--------------------------------------------------+ + | | + | J15: USB-C [====] [FDL] [PWR] [RST] | + | | + | | + | J25 (UART header) | + | [TXD] [RXD] [GND] | + +--------------------------------------------------+ + +After UART is connected, attach the USB Type-C cable to the OTG port +(J15 on BPI-F3) to power on. + +**2. Serial Console** + +.. code-block:: console + + $ minicom -D /dev/ttyUSB0 + +Default baudrate: 115200. + +Building U-Boot SPL +~~~~~~~~~~~~~~~~~~~~ + +**1. Obtain the DDR training firmware** + +The DDR training firmware is a proprietary binary provided by SpacemiT. It is +not included in U-Boot and must be downloaded separately from: + +https://github.com/spacemit-com/spacemit-firmware/tree/master/k1/v0.2 + +Download ``ddr_fw.bin`` from that directory. + +This binary is integrated into the SPL image at build time via the binman +framework. When the SPL image is loaded to SRAM (e.g., via USB fastboot), +the SPL executes the DDR firmware from SRAM to perform DDR initialization. + +**2. Obtain OpenSBI fw_dynamic.bin** + +Any pre-built ``fw_dynamic.bin`` is sufficient. Upstream OpenSBI +sources are at https://github.com/riscv-software-src/opensbi if you +need to build one. + +At this stage of the patchset, SPL halts before invoking OpenSBI, +but U-Boot's binman still packages ``fw_dynamic.bin`` into +``u-boot.itb`` and the build fails if it is missing. + +**3. Build SPL** + +.. code-block:: console + + $ export CROSS_COMPILE=riscv64-linux-gnu- + $ export ARCH=riscv + $ export DDR_FW_FILE=$(pwd)/ddr_fw.bin + $ export OPENSBI=/path/to/fw_dynamic.bin + $ make spacemit_k1_defconfig + $ make + +Output: ``u-boot-spl-ddr.bin`` in the build directory. This image contains the +SPL code and the DDR firmware blob packaged together via binman. + +.. note:: + + If ``DDR_FW_FILE`` is not set, the build completes with an empty + placeholder. The resulting SPL will boot but cannot initialize DDR. + +**4. Generate signed FSBL image** + +The K1 BootROM requires a signed first-stage bootloader (FSBL). The signing +tool (``tools/build_binary_file.py``) is in SpacemiT's vendor U-Boot repository: + +.. code-block:: console + + $ git clone -b k1-bl-v2.2.y https://gitee.com/spacemit-buildroot/uboot-2022.10 + +The script uses ``fsbl_ddr.json`` which may not exist by default. If +``fsbl_ddr.json`` does not exist in +``uboot-2022.10/board/spacemit/k1-x/configs/``, +create it by copying ``fsbl.json`` and replacing the reference to +``u-boot-spl.bin`` with ``u-boot-spl-ddr.bin``: + +.. code-block:: console + + $ cd uboot-2022.10/board/spacemit/k1-x/configs + $ cp fsbl.json fsbl_ddr.json + $ sed -i 's/u-boot-spl\.bin/u-boot-spl-ddr.bin/g' fsbl_ddr.json + +Create the ``fsbl.sh`` script below in the ``uboot-2022.10`` directory. +Update the path variables to match your local setup: + +.. code-block:: bash + + #!/bin/sh + MAINLINE_UBOOT_IMG_PATH="{your path}/u-boot" + MAINLINE_SPL_IMG_PATH="{your path}/u-boot/spl" + FSBL_PATH="{your path}/uboot-2022.10/spl_bin" + KEY_TOOL_PATH="{your path}/uboot-2022.10/tools" + CONFIG_PATH="{your path}/uboot-2022.10/board/spacemit/k1-x/configs" + + mkdir -p ${FSBL_PATH} + echo "Clean binaries in ${FSBL_PATH}" + rm -f ${FSBL_PATH}/u-boot-spl-ddr.bin + rm -f ${FSBL_PATH}/u-boot-spl.bin + + if [ ! -d ${MAINLINE_SPL_IMG_PATH} ]; then + MAINLINE_UBOOT_IMG_PATH="{your path}/build" + MAINLINE_SPL_IMG_PATH="{your path}/build/spl" + fi + + # The signing tool reads u-boot-spl-ddr.bin from the path declared in + # fsbl_ddr.json's "source" field, which is resolved relative to the + # JSON file's directory -- i.e. one level up from CONFIG_PATH, not + # FSBL_PATH. Stage the unsigned binary there before signing. + cp ${MAINLINE_UBOOT_IMG_PATH}/u-boot-spl-ddr.bin ${CONFIG_PATH}/../ + python3 ${KEY_TOOL_PATH}/build_binary_file.py \ + -c ${CONFIG_PATH}/fsbl_ddr.json \ + -o ${FSBL_PATH}/FSBL.bin + +Then run: + +.. code-block:: console + + $ chmod +x fsbl.sh + $ ./fsbl.sh + +Output: ``FSBL.bin`` in the ``spl_bin`` directory, ready for deployment. + +Deploying via USB Fastboot +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To enter BootROM fastboot mode: + +1. Power off the board by unplugging its power supply. +2. **Press and hold** the FDL button (called "Boot Key" on some boards; + see the board layout above for the BPI-F3). +3. While holding the button, use a USB cable to connect the OTG port to + your host. This cable is also used by fastboot to upload the firmware. +4. Release the button. + +On the host, ``fastboot devices`` should list the board:: + + dfu-device DFU download + +The serial console shows the BootROM's USB download handler trace, +including a line like:: + + usb2d_initialize : enter + +This indicates the board is ready to accept an image via USB. + +.. tip:: + + If you are worried about insufficient USB power, you can first plug + in the power, then release the button, and then plug in the USB + cable. + +On the host: + +.. code-block:: console + + $ sudo fastboot stage FSBL.bin + $ sudo fastboot continue + +Expected Output +~~~~~~~~~~~~~~~~ + +During successful SPL boot with DDR initialization, the serial console +shows output like:: + + <debug_uart> + + U-Boot SPL 2026.04-rc4-00430-g8b84b1ed8ea9 (May 08 2026 - 09:08:27 -0400) + Fail to detect board:-19 + vdd_core, value:900000 + vdd_1v8, value:1800000 + vdd_1v8_mmc, value:1800000 + DDR firmware: [0xc0815840]:0xf0227179, size:0x8d98 + DDR is ready + SPL: Unsupported Boot Device! + SPL: failed to boot from all boot devices + ### ERROR ### Please RESET the board ### + +To walk through the key lines: + +- ``DDR firmware: [...], size:0x8d98`` - DDR firmware loaded successfully +- ``DDR is ready`` - DDR initialization completed +- ``SPL: failed to boot from all boot devices`` - expected at this stage, + confirms that SPL with DDR init is working correctly + +If SPL hangs before printing DDR messages, verify that ``DDR_FW_FILE`` was set +during build and that ``ddr_fw.bin`` is not empty. + +.. tip:: + + To see verbose DDR training output from the DDR firmware (per-phase + training pass/fail logs), add ``#define DEBUG`` at the top of + ``board/spacemit/k1/spl.c`` and rebuild. SPL then passes ``puts`` as + the firmware's log callback; otherwise the callback is ``NULL`` and + the firmware runs silently. + +References +~~~~~~~~~~~ + +- `DDR firmware repository <https://github.com/spacemit-com/spacemit-firmware>`_ +- `SpacemiT vendor U-Boot (signing tool) <https://gitee.com/spacemit-buildroot/uboot-2022.10>`_ diff --git a/doc/board/starfive/jh7110_common.rst b/doc/board/starfive/jh7110_common.rst index e9c0ed5b022..013bab50045 100644 --- a/doc/board/starfive/jh7110_common.rst +++ b/doc/board/starfive/jh7110_common.rst @@ -170,7 +170,7 @@ Build U-Boot .. code-block:: console - git clone https://source.denx.de/u-boot/u-boot.git u-boot.git + git clone https://git.u-boot-project.org/u-boot/u-boot.git u-boot.git make -C u-boot.git O=u-boot starfive_visionfive2_defconfig make -C u-boot.git O=u-boot OPENSBI=opensbi/platform/generic/firmware/fw_dynamic.bin diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst index 74ece0c9acf..d3ecaf59909 100644 --- a/doc/board/ti/k3.rst +++ b/doc/board/ti/k3.rst @@ -170,7 +170,7 @@ online * **Das U-Boot** - | **source:** https://source.denx.de/u-boot/u-boot.git + | **source:** https://git.u-boot-project.org/u-boot/u-boot.git | **branch:** master * **Trusted Firmware-A (TF-A)** @@ -651,6 +651,17 @@ Refer (:ref:`U-boot ARMV8 build <k3_rst_include_start_build_steps_uboot>`) This will need to be explicitly disabled by changing the boot_targets to disallow fallback during testing. +DDR Configuration +----------------- + +The K3 DDRSS driver (drivers/ram/k3-ddrss/k3-ddrss.c) configures the DDR during +the R5 SPL stage. The driver utilizes an auto-generated configuration file +containing necessary settings for the DDR. It configures the frequency, timing +parameters, training algorithms etc. for DDR initialization. The configuration +DTSI can be generated using the `Sysconfig tool <https://dev.ti.com/sysconfig>`_ +and selecting the software product as "DDR Configuration for \*" as well as the +required device. + Saving environment ------------------ @@ -1258,3 +1269,86 @@ Currently, OpenOCD does not support tracing for K3 platforms. Tracing function could be beneficial if the bug in code occurs deep within nested function and can optionally save developers major trouble of stepping through a large quantity of code. + +Firmware TPM (fTPM) Support +--------------------------- + +K3 family of devices with **eMMC** are capable of supporting firmware TPM +(fTPM) functionality through OP-TEE, providing TPM 2.0 capabilities +without requiring discrete TPM hardware. +The fTPM Trusted Application runs in OP-TEE secure world and uses +eMMC Replay Protected Memory Block (RPMB) for secure persistent +storage. + +The fTPM implementation consists of: + +* **fTPM TA**: Microsoft's fTPM Trusted Application (TA) running in OP-TEE +* **RPMB Storage**: eMMC RPMB partition for persistent TPM NV storage +* **U-Boot Support**: TPM commands and RPMB access via OP-TEE + +fTPM can be used to enable security features such as: + +* Measured boot +* Secure key storage +* Platform attestation + +Enabling fTPM in U-Boot +^^^^^^^^^^^^^^^^^^^^^^^ + +The following are the steps to enable fTPM in uboot: + +1. Programming Keys into eMMC RPMB +"""""""""""""""""""""""""""""""""" + +Since fTPM uses RPMB for persistent storage, the eMMC RPMB must be +provisioned with an authentication key on first boot. This requires +building optee_os with the ``CFG_RPMB_WRITE_KEY=y`` flag + +.. prompt:: bash $ + + # inside optee_os source + make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y \ + PLATFORM=$OPTEE_PLATFORM CFG_RPMB_WRITE_KEY=y + +.. warning:: + + Programming the RPMB key is a **one-time, irreversible operation**. + The key is derived from the Hardware Unique Key (HUK) and cannot + be changed once programmed. For further details, refer + `Secure Storage <https://optee.readthedocs.io/en/latest/architecture/secure_storage.html>`_ + +On first boot with this configuration, OP-TEE will automatically program +the RPMB authentication key. Subsequent boots should use OP-TEE built +without this flag. + +2. Generate fTPM TA binary +"""""""""""""""""""""""""" + +To generate fTPM TA binary, follow the +`Building the TA <https://github.com/OP-TEE/optee_ftpm#building-the-ta>`_ +steps mentioned in the OP-TEE fTPM Github repository + +3. Build OP-TEE with TA: +"""""""""""""""""""""""" + +With the TA generated from last step, build optee-os with RPMB and early +TA enabled: + +.. prompt:: bash $ + + # inside optee_os source + make CROSS_COMPILE=$CC32 CROSS_COMPILE64=$CC64 CFG_ARM64_core=y \ + PLATFORM=$OPTEE_PLATFORM CFG_RPMB_FS=y CFG_REE_FS=n \ + CFG_EARLY_TA=y CFG_RPMB_ANNOUNCE_PROBE_CAP=n \ + EARLY_TA_PATHS=/path/to/ftpm_ta.stripped.elf + +Expected Outcome +^^^^^^^^^^^^^^^^ + +To verify fTPM support is working, run tpm2 commands in u-boot prompt: + +.. code-block:: console + + => tpm2 info + Microsoft OP-TEE fTPM + => tpm2 init diff --git a/doc/board/toradex/aquila-imx95.rst b/doc/board/toradex/aquila-imx95.rst new file mode 100644 index 00000000000..edd40252657 --- /dev/null +++ b/doc/board/toradex/aquila-imx95.rst @@ -0,0 +1,175 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Toradex Aquila iMX95 Module +=========================== + +- SoM: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95 +- Carrier board: https://www.toradex.com/products/carrier-board/aquila-development-board-kit + +Quick Start +----------- + +- Setup environment +- Get ahab-container.img +- Get DDR PHY Firmware Images +- Get and Build OEI Images +- Get and Build System Manager Image +- Get and Build the ARM Trusted Firmware +- Build the Bootloader Image +- Boot + +Setup environment +----------------- + +Suggested current toolchains are ARM 14.3 (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads): + +- https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz +- https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz + +.. code-block:: console + + $ export TOOLS=<path/to/directory/with/toolchains> + $ 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 ahab-container.img +---------------------- + +Note: `$srctree` is the U-Boot source directory + +.. code-block:: console + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.2-89161a8.bin + $ sh firmware-ele-imx-2.0.2-89161a8.bin --auto-accept + $ cp firmware-ele-imx-2.0.2-89161a8/mx95b0-ahab-container.img $(srctree) + +Get DDR PHY Firmware Images +--------------------------- + +Note: `$srctree` is the U-Boot source directory + +.. code-block:: console + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.28-994fa14.bin + $ sh firmware-imx-8.28-994fa14.bin --auto-accept + $ cp firmware-imx-8.28-994fa14/firmware/ddr/synopsys/lpddr5*v202409.bin $(srctree) + +Get and Build OEI Images +------------------------ + +Note: `$srctree` is the U-Boot source directory +Get OEI from: https://git.toradex.com/cgit/imx-oei-toradex.git/ +branch: main + +.. code-block:: console + + $ git clone -b main https://git.toradex.com/cgit/imx-oei-toradex.git/ + $ cd imx-oei-toradex + + $ make board=toradex-aquila-imx95 oei=ddr DEBUG=1 r=B0 all + $ cp build/toradex-aquila-imx95/ddr/oei-m33-ddr.bin $(srctree) + + $ make board=toradex-aquila-imx95 oei=tcm DEBUG=1 r=B0 all + $ cp build/toradex-aquila-imx95/tcm/oei-m33-tcm.bin $(srctree) + +The Makefile will set `DDR_CONFIG` automatically based on the selected silicon +revision. + +Get and Build the System Manager Image +-------------------------------------- + +Note: `$srctree` is the U-Boot source directory +Get System Manager from: https://git.toradex.com/cgit/imx-sm-toradex.git/ +branch: main + +.. code-block:: console + + $ git clone -b main https://git.toradex.com/cgit/imx-sm-toradex.git/ + $ cd imx-sm-toradex + $ make config=aquila-imx95 all + $ cp build/aquila-imx95/m33_image.bin $(srctree) + +Get and Build the ARM Trusted Firmware +-------------------------------------- + +Note: `$srctree` is the U-Boot source directory +Get ATF from: https://github.com/nxp-imx/imx-atf/ +branch: lf_v2.12 + +.. code-block:: console + + $ export CROSS_COMPILE=$CROSS_COMPILE_64 + $ unset LDFLAGS + $ unset AS + $ git clone -b lf_v2.12 https://github.com/nxp-imx/imx-atf.git + $ cd imx-atf + $ make PLAT=imx95 bl31 + $ cp build/imx95/release/bl31.bin $(srctree) + +Build the Bootloader Image +-------------------------- + +.. code-block:: console + + $ export CROSS_COMPILE=$CROSS_COMPILE_64 + $ make aquila-imx95_defconfig + $ make + +Flash to eMMC +------------- + +.. code-block:: console + + > tftpboot ${loadaddr} flash.bin + > setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200 + > mmc dev 0 1 && mmc write ${loadaddr} 0x0 ${blkcnt} + +As a convenience, instead of the last two commands, one may also use the update +U-Boot wrapper: + +.. code-block:: console + + > run update_uboot + +Boot +---- + +Boot sequence is: + +* SPL ---> ATF (TF-A) ---> U-Boot proper + +Output: + +.. code-block:: console + + U-Boot SPL 2026.07-rc3-00300-ge16706b72e14 (Jun 11 2026 - 13:07:49 +0200) + SYS Boot reason: por, origin: -1, errid: -1 + WDT: Started watchdog@42490000 with servicing every 1000ms (40s timeout) + Trying to boot from MMC1 + Load image from MMC/SD 0xd2800 + NOTICE: BL31: v2.10.0 (release):lf-6.6.52-2.2.1-dirty + NOTICE: BL31: Built : 06:40:36, Jul 7 2025 + + + U-Boot 2026.07-rc3-00300-ge16706b72e14 (Jun 11 2026 - 13:07:49 +0200) + + CPU: NXP i.MX95 Rev2.0 A55 at 1800 MHz - invalid sensor data + DRAM: 7.8 GiB + Core: 321 devices, 30 uclasses, devicetree: separate + WDT: Started watchdog@42490000 with servicing every 1000ms (40s timeout) + MMC: FSL_SDHC: 0, FSL_SDHC: 1 + Loading Environment from MMC... Reading from MMC(0)... OK + In: serial@44380000 + Out: serial@44380000 + Err: serial@44380000 + Model: Toradex 0098 Aquila iMX95 Hexa 8GB WB IT V1.0A + Serial#: 12594391 + + BuildInfo: + - ELE firmware version 2.0.2-c110ba4b + + Net: WARNING: no MAC address assigned for MAC0 + imx_get_mac_from_fuse: fuse read err: 0 + eth0: enetc-0 [PRIME] + Hit any key to stop autoboot: 0 + Aquila iMX95 # diff --git a/doc/board/toradex/index.rst b/doc/board/toradex/index.rst index 27f059542e6..c5955ea1ad8 100644 --- a/doc/board/toradex/index.rst +++ b/doc/board/toradex/index.rst @@ -8,6 +8,7 @@ Toradex apalis-imx8 aquila-am69 + aquila-imx95 colibri_imx7 colibri-imx8x smarc-imx8mp @@ -16,3 +17,4 @@ Toradex verdin-am62p verdin-imx8mm verdin-imx8mp + verdin-imx95 diff --git a/doc/board/toradex/verdin-imx95.rst b/doc/board/toradex/verdin-imx95.rst new file mode 100644 index 00000000000..d252277cc20 --- /dev/null +++ b/doc/board/toradex/verdin-imx95.rst @@ -0,0 +1,171 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Verdin iMX95 Module +========================== + +- SoM: https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95 +- Carrier board: https://www.toradex.com/products/carrier-board/verdin-development-board-kit + +Quick Start +----------- + +- Setup environment +- Get ahab-container.img +- Get DDR PHY Firmware Images +- Get and Build OEI Images +- Get and Build System Manager Image +- Get and Build the ARM Trusted Firmware +- Build the Bootloader Image +- Boot + +Setup environment +----------------- + +Suggested current toolchains are ARM 14.3 (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads): + +- https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz +- https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz + +.. code-block:: console + + $ export TOOLS=<path/to/directory/with/toolchains> + $ 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 ahab-container.img +---------------------- + +Note: `$srctree` is the U-Boot source directory + +.. code-block:: console + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.2-89161a8.bin + $ sh firmware-ele-imx-2.0.2-89161a8.bin --auto-accept + $ cp firmware-ele-imx-2.0.2-89161a8/mx95b0-ahab-container.img $(srctree) + +Get DDR PHY Firmware Images +--------------------------- + +Note: `$srctree` is the U-Boot source directory + +.. code-block:: console + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.28-994fa14.bin + $ sh firmware-imx-8.28-994fa14.bin --auto-accept + $ cp firmware-imx-8.28-994fa14/firmware/ddr/synopsys/lpddr4x*v202409.bin $(srctree) + +Get and Build OEI Images +------------------------ + +Note: `$srctree` is the U-Boot source directory +Get OEI from: https://git.toradex.com/cgit/imx-oei-toradex.git/ +branch: main + +.. code-block:: console + + $ git clone -b main https://git.toradex.com/cgit/imx-oei-toradex.git/ + $ cd imx-oei-toradex + + $ make board=toradex-verdin-imx95 oei=ddr DEBUG=1 r=B0 all + $ cp build/toradex-verdin-imx95/ddr/oei-m33-ddr.bin $(srctree) + +The Makefile will set `DDR_CONFIG` automatically based on the selected silicon +revision. + +Get and Build the System Manager Image +-------------------------------------- + +Note: `$srctree` is the U-Boot source directory +Get System Manager from: https://git.toradex.com/cgit/imx-sm-toradex.git/ +branch: main + +.. code-block:: console + + $ git clone -b main https://git.toradex.com/cgit/imx-sm-toradex.git/ + $ cd imx-sm-toradex + $ make config=verdin-imx95 all + $ cp build/verdin-imx95/m33_image.bin $(srctree) + +Get and Build the ARM Trusted Firmware +-------------------------------------- + +Note: `$srctree` is the U-Boot source directory +Get ATF from: https://github.com/nxp-imx/imx-atf/ +branch: lf_v2.12 + +.. code-block:: console + + $ export CROSS_COMPILE=$CROSS_COMPILE_64 + $ unset LDFLAGS + $ unset AS + $ git clone -b lf_v2.12 https://github.com/nxp-imx/imx-atf.git + $ cd imx-atf + $ make PLAT=imx95 bl31 + $ cp build/imx95/release/bl31.bin $(srctree) + +Build the Bootloader Image +-------------------------- + +.. code-block:: console + + $ export CROSS_COMPILE=$CROSS_COMPILE_64 + $ make verdin-imx95_defconfig + $ make + +Flash to eMMC +------------- + +.. code-block:: console + + > tftpboot ${loadaddr} flash.bin + > setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200 + > mmc dev 0 1 && mmc write ${loadaddr} 0x0 ${blkcnt} + +As a convenience, instead of the last two commands, one may also use the update +U-Boot wrapper: + +.. code-block:: console + + > run update_uboot + +Boot +---- + +Boot sequence is: + +* SPL ---> ATF (TF-A) ---> U-Boot proper + +Output: + +.. code-block:: console + + U-Boot SPL 2026.04-00756-ge7053d7cab88 (Apr 15 2026 - 12:27:34 +0200) + SYS Boot reason: pmic, origin: -1, errid: -1 + SYS shutdown reason: pmic, origin: -1, errid: -1 + Trying to boot from MMC1 + Primary set selected + Load image from MMC/SD 0xca000 + NOTICE: BL31: v2.12.0(release):lf-6.12.20-2.0.0 + NOTICE: BL31: Built : 17:34:12, Oct 21 2025 + + + U-Boot 2026.04-00756-ge7053d7cab88 (Apr 15 2026 - 12:27:34 +0200) + + CPU: NXP i.MX95 Rev2.0 A55 at 1800 MHz - invalid sensor data + DRAM: 7.8 GiB + Core: 323 devices, 28 uclasses, devicetree: separate + MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 + Loading Environment from MMC... Reading from MMC(0)... OK + In: serial@44380000 + Out: serial@44380000 + Err: serial@44380000 + Model: Toradex 0089 Verdin iMX95 Hexa 8GB WB IT V1.0B + Serial#: 12594936 + + BuildInfo: + - ELE firmware version 2.0.2-2a118457 + + Setting variant to wifi + Net: No ethernet found. + Hit any key to stop autoboot: 0 + Verdin iMX95 # diff --git a/doc/board/tq/index.rst b/doc/board/tq/index.rst new file mode 100644 index 00000000000..775957474e7 --- /dev/null +++ b/doc/board/tq/index.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later or CC-BY-4.0 + +.. Copyright (c) 2024-2026 TQ-Systems GmbH <[email protected]>, +.. D-82229 Seefeld, Germany. + +TQ-Systems +========== + +.. toctree:: + :maxdepth: 2 + + tqma6ul + tqma7 diff --git a/doc/board/tq/tqma6ul.rst b/doc/board/tq/tqma6ul.rst new file mode 100644 index 00000000000..2b346715642 --- /dev/null +++ b/doc/board/tq/tqma6ul.rst @@ -0,0 +1,105 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later or CC-BY-4.0 + +.. Copyright (c) 2017-2025 TQ-Systems GmbH <[email protected]>, +.. D-82229 Seefeld, Germany. + +######################################## +U-Boot for the TQ-Systems TQMa6x modules +######################################## + +The following hardware revisions are supported: + +Modules: + ++------------+----------+ +| TQMa6ULx | REV.030x | ++------------+----------+ +| TQMa6ULLx | REV.030x | ++------------+----------+ +| TQMa6ULxL | REV.030x | ++------------+----------+ +| TQMa6ULLxL | REV.030x | ++------------+----------+ + +Mainboards: + ++----------+----------+ +| MBa6ULx | REV.020x | ++----------+----------+ + +Hardware on modules TQMa6ULx, TQMa6ULxL, TQMa6ULLx and TQMa6ULLxL + +- eMMC +- RTC +- PMIC +- SPI-NOR (optional) +- EEPROM +- Temperature sensor +- RAM (256 MiB / 512 MiB) + +Supported hardware on Starterkit MBa6ULx: + +- 2 Ethernet PHY connected to FEC0 / FEC1 (usage depends on CPU) +- SD-card slot +- UART +- USB + +Note: To change the Ethernet port to use for networking functionality, use the +U-Boot generic environment variable ``ethact``. + +.. code-block:: bash + + setenv ethact <FEC> + +*********** +Boot source +*********** + +- SD/eMMC +- USB/SDP (with NXP UUU tool) +- SPI NOR (functional but requires additional prepended NXP header. + Not supported in U-Boot.) + +******** +Building +******** + +To build U-Boot for the TQ-Systems TQMa6L modules: + +.. code-block:: bash + + make <som>_<baseboard>_<boot>_defconfig + make + + +**som** is a placeholder for the module base variant: + ++------------+------------+----------------+ +| tqma6ulx | TQMa6ULx | i.MX6UL | ++------------+------------+----------------+ +| tqma6ullx | TQMa6ULLx | i.MX6ULL | ++------------+------------+----------------+ +| tqma6ulxl | TQMa6ULxL | i.MX6UL (lga) | ++------------+------------+----------------+ +| tqma6ullxl | TQMa6ULLxL | i.MX6ULL (lga) | ++------------+------------+----------------+ + +**baseboard** is a placeholder for the mainboard to compile for: + ++----------+----------+ +| mba6ul | MBa6ULx | ++----------+----------+ + +**boot** is a placeholder for the boot device: + ++------+---------+ +| mmc | SD/eMMC | ++------+---------+ +| spi | SPI-NOR | ++------+---------+ + +************ +Support Wiki +************ + +See `TQ Embedded Wiki for TQMa6ulx <https://support.tq-group.com/en/arm/tqma6ulx>`_. diff --git a/doc/board/tq/tqma7.rst b/doc/board/tq/tqma7.rst new file mode 100644 index 00000000000..60fd883968d --- /dev/null +++ b/doc/board/tq/tqma7.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +.. Copyright (c) 2020-2026 TQ-Systems GmbH <[email protected]>, +.. D-82229 Seefeld, Germany. + +######################################## +U-Boot for the TQ-Systems TQMa7x modules +######################################## + +This file contains information for the port of +U-Boot to the TQ-Systems TQMa7x modules. + +*********** +Boot source +*********** + +The following boot sources are supported: + +- SD/eMMC +- USB (SDP) + +QSPI boot is functional but requires an additional prepended NXP header +image. This currently unsupported in u-boot. + +******** +Building +******** + +To build U-Boot for the TQ-Systems TQMa7x modules: + +.. code-block:: bash + + make tqma7_mba7_<boot>_defconfig + make + +**boot** is a placeholder for the boot device: + ++------+-----------+ +| mmc | SD/eMMC | ++------+-----------+ +| uuu | USB (SDP) | ++------+-----------+ + +The default build artifact is named ``u-boot-with-spl.imx``. + +***************************************** +Serial Download Protocol (SDP) / USB boot +***************************************** + +The complete system image can be programmed with ``uuu`` +(https://github.com/nxp-imx/mfgtools) to eMMC. + +Serial Download Protocol is supported on the Micro-B USB port (X5) of MBa7x. +The command ``fastboot usb 0`` is used to enable the fastboot gadget. + +Build SDP enabled U-Boot image +============================== + +.. code-block:: bash + + make <som>_mba7_uuu_defconfig + make + +Booting +======= + +With UUU + +.. code-block:: bash + + uuu -b spl <UUU U-Boot image> + +************ +Support Wiki +************ + +See `TQ Embedded Wiki for TQMa7x <https://support.tq-group.com/en/arm/tqma7x>`_. diff --git a/doc/build/documentation.rst b/doc/build/documentation.rst index b55a4666643..65f767440bd 100644 --- a/doc/build/documentation.rst +++ b/doc/build/documentation.rst @@ -40,7 +40,7 @@ The *htmldocs* target is used to build the HTML documentation. It uses the # Display the documentation in a graphical web browser x-www-browser doc/output/index.html -The HTML documentation is published at https://docs.u-boot.org. The build +The HTML documentation is published at https://docs.u-boot-project.org. The build process for that site is controlled by the file *.readthedocs.yml*. Infodoc documentation diff --git a/doc/build/source.rst b/doc/build/source.rst index d21ee055f33..8407945a13f 100644 --- a/doc/build/source.rst +++ b/doc/build/source.rst @@ -7,7 +7,7 @@ You can download the source via .. code-block:: bash - git clone https://source.denx.de/u-boot/u-boot.git + git clone https://git.u-boot-project.org/u-boot/u-boot.git A mirror of the source is maintained on Github diff --git a/doc/chromium/chainload.rst b/doc/chromium/chainload.rst index b00ee94eaa4..0f61e020db8 100644 --- a/doc/chromium/chainload.rst +++ b/doc/chromium/chainload.rst @@ -42,9 +42,9 @@ Nyan-big Compiled based on information here:: - https://lists.denx.de/pipermail/u-boot/2015-March/209530.html + https://patch.msgid.link/[email protected]/ https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big - https://lists.denx.de/pipermail/u-boot/2017-May/289491.html + https://patch.msgid.link/CALr8Vo1WvO=m1W2zvT=MOQ3k-fNtcCtBjk2+zgKha0j28s8g6A@mail.gmail.com/ https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card 1. Build U-Boot diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst index 2a69162fa95..b8d2bf23a54 100644 --- a/doc/develop/codingstyle.rst +++ b/doc/develop/codingstyle.rst @@ -24,54 +24,6 @@ The following rules apply: <https://peps.python.org/pep-0008/>`_. Use `pylint <https://github.com/pylint-dev/pylint>`_ for checking the code. -.. _b4_contrib: - -* Use the `b4 <https://b4.docs.kernel.org/en/latest/>`__ tool to prepare and - send your patches. b4 has become the preferred tool to sending patches for many - Linux kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that - targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` for - recipient discovery. - - Start a topical series with ``b4 prep`` and keep the commits organised with - ``git rebase -i``. ``b4 prep --edit-cover`` opens an editor for the cover - letter, while ``b4 prep --auto-to-cc`` collects reviewers and maintainers from - both the configuration file and ``scripts/get_maintainer.pl``. - - .. code-block:: bash - - b4 prep -n mmc-fixes - git rebase -i origin/master - b4 prep --edit-cover - b4 prep --auto-to-cc - - Run the style checks before sending. ``b4 prep --check`` wraps the existing - tooling so you see the output from ``scripts/checkpatch.pl`` alongside b4's - own validation. You can always invoke ``scripts/checkpatch.pl`` directly for - additional runs. - - .. code-block:: bash - - b4 prep --check - - When the series is ready, use ``b4 send``. Begin with ``--dry-run`` to review - the generated emails and ``--reflect`` to copy yourself for records before - dispatching to ``[email protected]``. - - .. code-block:: bash - - b4 send --dry-run - b4 send --reflect - b4 send - - After reviews arrive, collect Acked-by/Tested-by tags with ``b4 trailers -u`` - and fold them into your commits before resending the updated series. - - .. code-block:: bash - - b4 trailers -u - git rebase -i origin/master - b4 send - * Run ``scripts/checkpatch.pl`` directly or via ``b4 prep --check`` so that all issues are resolved *before* posting on the mailing list. For more information, read :doc:`checkpatch`. @@ -80,8 +32,10 @@ Code Formatting with clang-format ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ U-Boot provides a `.clang-format` configuration file that was copied directly -from the Linux kernel without any modifications, ensuring complete compatibility -with kernel coding standards. Here are common ways to use clang-format: +from the Linux kernel, ensuring complete compatibility with kernel coding +standards. + +Here are common ways to use clang-format: **Basic usage for single files:** diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 634114af59a..7d6117d5c4b 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -232,6 +232,64 @@ outside the U-Boot repository. You can use `DEVICE_TREE_INCLUDES` Kconfig option to specify a list of .dtsi files that will also be included when building .dtb files. +Scripts embedded in control DTB +------------------------------- + +The `DEVICE_TREE_INCLUDES` option can also be used to make the control +DTB serve double duty as a FIT image. By including a `scripts.dtsi` +file containing something like:: + + / { + images { + default = "boot"; + boot { + description = "Bootscript"; + data = /incbin/("boot.sh"); + type = "script"; + compression = "none"; + }; + factory-reset { + description = "Script for performing factory reset"; + data = /incbin/("factory-reset.sh"); + type = "script"; + compression = "none"; + }; + }; + }; + +one can call those scripts using the `source` command in the U-Boot shell:: + + source ${fdtcontroladdr}:boot + +or just ``source ${fdtcontroladdr}`` for invoking the default. + +Since one does not need to separately build a "real" FIT image +containing those scripts, this simplifies both the build process and +the boot logic, as the latter does not need to first load the FIT +image from storage. + +Another advantage is that when the bootloader and boot script must be +updated together, it is easier to achieve a guaranteed atomic update +when the boot script is embedded inside the U-Boot binary, instead of +stored separately. + +For the above to work, one must enable the `CONTROL_DTB_AS_FIT` config +option, which will (when the address passed to the `source` command is +the address of U-Boot's control DTB) elide certain sanity checks that +are normally done: With the above `.dtsi` snippet, the control DTB +does not quite become a "real" FIT image - it lacks `timestamp` and +`description` properties, but more importantly, FIT images cannot +contain nodes with `@` in their names (unit addresses) anywhere, and +the control DTB obviously does have such nodes. + +This is not a security problem, as the control DTB is necessarily +trusted. In any secure boot setup where the bootloader is verified, +that mechanism must also include verification of the control DTB. So +in fact, since the scripts embedded this way are then also +automatically verified, it simplifies implementation of secure +boot. When using a separate FIT image, one must build it with +appropriate signatures, just as when building a FIT image containing a +kernel/dtb/initramfs. Devicetree bindings schema checks --------------------------------- diff --git a/doc/develop/driver-model/spi-howto.rst b/doc/develop/driver-model/spi-howto.rst index 9dc3b9b4aac..65dd50e7d55 100644 --- a/doc/develop/driver-model/spi-howto.rst +++ b/doc/develop/driver-model/spi-howto.rst @@ -649,8 +649,8 @@ board. Prepare patches and send them to the mailing lists -------------------------------------------------- -You can use 'tools/patman/patman' to prepare, check and send patches for -your work. See tools/patman/README for details. +You can prepare, check and send patches for your work using the tools described +in :doc:`/develop/sending_patches`. A little note about SPI uclass features --------------------------------------- diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst index e46cd39d601..a7ed4aab0a5 100644 --- a/doc/develop/environment.rst +++ b/doc/develop/environment.rst @@ -49,3 +49,43 @@ The signature of the callback functions is:: include/search.h The return value is 0 if the variable change is accepted and 1 otherwise. + +Flags for environment variables +------------------------------- + +Environment flags validate the values given to environment variables and +restrict how environment variables can be changed. + +The static list is configured with CONFIG_ENV_FLAGS_LIST_STATIC. The list +must be in the following format:: + + type_attribute = [s|d|x|b|i|m] + access_attribute = [a|r|o|c|w] + attributes = type_attribute[access_attribute] + entry = variable_name[:attributes] + list = entry[,list] + +The type attributes are: + +* s - String (default) +* d - Decimal +* x - Hexadecimal +* b - Boolean ([1yYtT|0nNfF]) +* i - IP address, if networking is enabled +* m - MAC address, if networking is enabled + +The access attributes are: + +* a - Any (default) +* r - Read-only +* o - Write-once +* c - Change-default +* w - Writeable, if CONFIG_ENV_WRITEABLE_LIST is enabled + +CONFIG_ENV_FLAGS_LIST_DEFAULT defines the ``.flags`` variable in the +default or embedded environment. Any association in ``.flags`` overrides +an association in the static list. + +If CONFIG_REGEX is defined, the variable name is evaluated as a regular +expression. This allows multiple variables to define the same flags without +explicitly listing them all. diff --git a/doc/develop/historical/generic_board.rst b/doc/develop/historical/generic_board.rst index 12550a140e0..17a92687c5b 100644 --- a/doc/develop/historical/generic_board.rst +++ b/doc/develop/historical/generic_board.rst @@ -64,17 +64,17 @@ separate function calls so that they can easily be included or excluded for a particular architecture. It also makes it easier to adopt Graeme's initcall proposal when it is ready. -http://lists.denx.de/pipermail/u-boot/2012-January/114499.html +https://patch.msgid.link/[email protected]/ This series removes the dependency on generic relocation. So relocation happens as one big chunk and is still completely arch-specific. See the relocation series for a proposed solution to this for ARM: -http://lists.denx.de/pipermail/u-boot/2011-December/112928.html +https://patch.msgid.link/CAPnjgZ0jesqX1Y71S5xoYQDGPuARfOX48RGbU9Mw=P5HGYcOKg@mail.gmail.com/ or Graeme's recent x86 series v2: -http://lists.denx.de/pipermail/u-boot/2012-January/114467.html +https://patch.msgid.link/[email protected]/ Instead of moving over a whole architecture, this series takes the approach of simply enabling generic board support for an architecture. It is then up diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 3c044e67927..0b757e8601e 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -16,7 +16,6 @@ General docstyle kconfig memory - patman process release_cycle security @@ -50,6 +49,7 @@ Implementation logging makefiles menus + pmbus printf smbios spl diff --git a/doc/develop/memory.rst b/doc/develop/memory.rst index 5177229630d..3da39bb6c66 100644 --- a/doc/develop/memory.rst +++ b/doc/develop/memory.rst @@ -111,6 +111,15 @@ U-Boot Proper Flow This follows the same as in SPL flow. In board_init_f(), a part of memory is reserved at the end of RAM (see reserve_* functions in init_sequence_f) + #. Relocation address + + By default U-Boot will try to relocate below the 4GiB boundary. If + RELOC_ADDR_TOP is enabled U-Boot will look into the dram bank config of + gd->dram[] and try to relocate to the highest available bank. Use this + with caution as devices that can only DMA below 4GiB will misbehave + since their buffers may be allocated above the 32-bit boundary. + Boards can override thre relocation address via board_get_usable_ram_top(). + #. Code Relocation relocate_code() is called which relocates U-Boot code from the current diff --git a/doc/develop/patman.rst b/doc/develop/patman.rst deleted file mode 120000 index 0fcb7d61d40..00000000000 --- a/doc/develop/patman.rst +++ /dev/null @@ -1 +0,0 @@ -../../tools/patman/patman.rst
\ No newline at end of file diff --git a/doc/develop/pmbus.rst b/doc/develop/pmbus.rst new file mode 100644 index 00000000000..f5550541e83 --- /dev/null +++ b/doc/develop/pmbus.rst @@ -0,0 +1,637 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +PMBus support in U-Boot +======================= + +This document describes U-Boot's PMBus 1.x support: what it is for, +how it is structured, and how to add support for a new PMBus chipn +either from scratch from a chip datasheet or by porting an existing +Linux ``drivers/hwmon/pmbus/`` driver. + +.. contents:: + :local: + :depth: 2 + +Intent and scope +---------------- + +U-Boot's PMBus layer is not a hardware monitoring (hwmon) clone of +the Linux kernel's ``drivers/hwmon/pmbus/`` subsystem. Linux owns the +runtime side: continuous polling, sysfs publication, alert IRQ +handling, fan control loops. U-Boot owns the boot time side. Concretely +the U-Boot PMBus support exists to: + +* Identify the PMBus regulator(s) a board carries at boot: + ``MFR_ID``, ``MFR_MODEL``, ``MFR_REVISION`` reads, plus a quick + ``STATUS_WORD`` sanity check. +* Print telemetry so an operator can confirm rail voltages, input + current, and temperature before handing off to the kernel. One shot + reads, on demand, via the ``pmbus`` and ``regulator`` U-Boot + commands (``pmbus dev <name>; pmbus telemetry``, + ``regulator dev <name>; regulator value``). +* Decode chip alerts when a rail trips an over/under voltage, + over current, or thermal threshold; so a boot log shows why the + previous boot failed, before the kernel even comes up. +* Optionally trim a critical rail (typically the SoC core) before + the kernel takes over; "set the voltage prior to a kernel boot + to better protect the board". This is the existing + ``board/nxp/common/vid.c`` AVS path and any future per board + speed binning trim. + +Out of scope, by design: + +* No periodic polling. No worker thread. No background updates. +* No sysfs / procfs / userspace surface. U-Boot has none. +* No fan speed control loop. The kernel runs that. +* No long tail of virtual sensor registers (``PMBUS_VIRT_*``). +* No sensor caching / update timestamps. + +If you find yourself wanting any of those, the answer is "wait until +Linux comes up". Keep U-Boot's PMBus surface minimal. + +Architecture overview +--------------------- + +The framework is split into four layers (layer 3 comes in two +flavours, 3a and 3b), + +:: + + +----------------------------------------+ + | Layer 1: include/pmbus.h | + | Standard PMBus 1.x command codes, | + | numeric format enum, sensor class | + | enum, struct pmbus_driver_info, | + | decoder + transport prototypes, | + | STATUS_WORD bit names. | + +----------------------------------------+ + | Layer 2: lib/pmbus.c | + | Format decoders (LINEAR11/LINEAR16/| + | DIRECT) and encoder (LINEAR16), | + | two stage SMBus block read helper, | + | STATUS_*-bit print tables, generic | + | dispatcher pmbus_reg2data(). | + +----------------------------------------+ + | Layer 3a: drivers/power/regulator/ | + | <chip>.c | + | UCLASS_REGULATOR per chip drivers | + | ; one struct pmbus_driver_info | + | plus regulator set_value/get_value | + | ops. Optional: per chip identify() | + | hook to refine format from the | + | chip's own VOUT_MODE. | + +----------------------------------------+ + | Layer 3b: drivers/power/regulator/ | + | pmbus_generic.c | + | Catch all driver matching | + | compatible = "pmbus". | + | Auto detects format via VOUT_MODE | + | and PMBUS_QUERY where supported. | + | Use for compliant chips with no | + | per chip driver yet; ship | + | telemetry today, write a per chip | + | driver later only if quirks demand | + | it. | + +----------------------------------------+ + | Layer 4: board/<vendor>/<board>/ | + | <chip>_diag.c | + | Diagnostic commands only: | + | <chip>_info / <chip>_raw | + | Reads via regulator_get_value() | + | and lib/pmbus.c helpers. LINEAR / | + | DIRECT math NOT here. | + +----------------------------------------+ + +Generic vs. board specific separation rule. Layer 1, 2, and 3 +files are tree level and platform agnostic. Their comments may +reference only: + +* the PMBus 1.x specification, and +* chip manufacturer datasheets. + +Never a specific board, SoC, or product. Board-specific quirks +(a particular bus number, a particular slave address, a particular +PCB feedback divider, board local design notes) live exclusively in +``board/<vendor>/<board>/`` files. + +CLI commands +------------ + +The framework publishes one top level command, ``pmbus``, plus a +vendor namespace dispatcher so per chip code can register chip +specific extensions without touching the framework. + +Active device model +~~~~~~~~~~~~~~~~~~~ + +``pmbus`` mirrors the ``regulator`` command: select an active device +once, then operate on it across subcommands. The active device is +selected by I2C bus (decimal sequence number) and 7 bit address (hex, +``0x`` optional, à la ``i2c`` convention):: + + => pmbus dev 0:10 + pmbus: active i2c0:0x10 MFR_ID="MPS" MFR_MODEL="MPQ8785" vendor=mps + +The framework probes ``MFR_ID`` (in both natural and reverse byte +orders) at selection time, looks the result up in the chip match +registry populated by per chip code via ``pmbus_register_chip()``, +and caches the matched ``pmbus_driver_info``. All subsequent +subcommands consume that cached metadata. + +Standard subcommands +~~~~~~~~~~~~~~~~~~~~ + +:: + + pmbus list list UCLASS_REGULATOR devices (DM bound) + pmbus dev [<bus>:<addr>] show / select active PMBus device + pmbus info identification banner + driver_info + pmbus telemetry decoded VIN, VOUT, IIN, IOUT, TEMP + pmbus status decode every STATUS_* register + pmbus dump hex dump of every standard register + pmbus read <reg> [b|w|s] raw read (b=byte, w=word, s=string) + pmbus write <reg> <val> [b|w] raw write + pmbus clear [faults] issue CLEAR_FAULTS (03h) + pmbus vout [<uV>] read or set VOUT_COMMAND (microvolts) + pmbus scan [<bus>] PMBus aware probe of one or all I2C buses + +The ``<reg>`` argument accepts either a hexadecimal address +(``88``, ``0x`` optional) or a symbolic name (``READ_VIN``, +``VOUT_MODE``, ``MFR_ID``); symbolic names win when both parsed. +``<val>`` is hexadecimal too. Only ``pmbus vout``'s microvolt +argument and bus numbers are decimal. +Format selectors after the register select the SMBus transaction width: +``b`` for byte, ``w`` for 16 bit little endian word, +``s`` for the SMBus block read used by string registers. + +Decoded telemetry honours the active device's ``pmbus_driver_info``; +when no chip match has been registered, VOUT falls back to LINEAR16 +driven by ``VOUT_MODE`` and the other sensors fall back to LINEAR11. + +Vendor namespace +~~~~~~~~~~~~~~~~ + +Per chip drivers and board files publish chip specific subcommands +in the ``pmbus <vendor> ...`` namespace by calling +``pmbus_register_vendor_handler()`` at init time. The framework +dispatches ``pmbus mps last``, ``pmbus mps clear last``, and +``pmbus mps clear force`` to the MPS handler when the active +device matches the ``mps`` vendor. Additional vendor handlers for +``lltc``, ``renesas``, etc. land alongside the per chip drivers +that need them. + +Relationship to ``vdd_override`` / ``vdd_read`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The NXP Layerscape ``vdd_override <mV>`` and ``vdd_read`` commands +remain available in their original form for compatibility with +existing AVS production scripts. The new ``pmbus vout`` and +``pmbus vout <uV>`` subcommands cover the read and single shot +write paths against the same chips, but do not implement +``vdd_override``'s full sequence (board drop compensation, fuse +target derivation, multi step convergence loop, atomic +``PAGE_PLUS_WRITE`` block transaction, ``WRITE_PROTECT`` dance). +For interactive bring up ``pmbus vout`` is sufficient; for +production AVS, ``vdd_override`` stays canonical. + +Lifecycle: from board boot to Linux handoff +------------------------------------------- + +The PMBus framework spans the entire U-Boot lifecycle. This section +walks the boot timeline phase by phase, showing when each piece +comes online and how the regulator uclass and the ``pmbus`` CLI +converge on the same chip. + +Timeline overview +~~~~~~~~~~~~~~~~~ + +:: + + Phase 0 chip power on chip ramps to NVM default VOUT + Phase 1 boot ROM / SPL / TF-A PMBus typically untouched + Phase 2 U-Boot relocation, DM init regulators bound, not probed + Phase 3 first regulator probe chip driver runs, framework lights up + Phase 4 board hooks / boot scripts snapshot, AVS trim, gating + Phase 5 Linux handoff DT passed, chip state preserved + Phase 6 Linux runtime kernel pmbus driver takes over + +Phase 0: chip power on +~~~~~~~~~~~~~~~~~~~~~~ + +When the regulator chip receives its input voltage, it ramps its +output to the VOUT default programmed into its NVM at factory +provisioning. PMBus is silent: no software runs anywhere on the +SoC yet. + +Phase 1: pre U-Boot stages +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boot ROMs, secondary boot loaders (SPL, ARM TF-A BL2 / BL31) +typically do not touch PMBus. They focus on PLLs, DDR PHY init, +and bringing up enough hardware to load the next stage. Some +platforms have a pre U-Boot AVS path in board specific TF-A +code that writes ``VOUT_COMMAND`` from a fuse derived target; +that path is independent of the U-Boot framework described here. + +Phase 2: U-Boot relocation and DM init +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After relocation, U-Boot binds device tree nodes to drivers but +does not probe them. UCLASS_REGULATOR devices for PMBus chips +are bound (driver and DT match resolved) but the ``.probe`` +callback has not run yet. + +Framework state at this point: + +* chip match registry: empty +* vendor handler registry: empty +* active device: none +* regulator uclass: devices bound, none probed + +Phase 3: lazy regulator probe +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The first caller into the regulator uclass for a given chip +triggers the chip driver's ``.probe``. Typical first callers: + +* a board ``EVENT_SPY`` at ``EVT_LAST_STAGE_INIT`` (boot snapshot) +* a U-Boot script: ``regulator dev <name>; regulator value`` +* the ``pmbus dev <name>`` CLI command (resolves to the regulator) +* another DT consumer with a ``regulator-supplies`` reference + +The probe chain looks like this:: + + <chip>_probe(dev) + pmbus_regulator_probe_common(dev, &<chip>_info, page) + dev_read_addr(dev) -> reg = <addr> + i2c_get_chip(dev->parent, addr) -> I2C chip handle + priv->i2c_dev = handle + priv->info = &<chip>_info + priv->page = page + (page > 0) write PMBUS_PAGE + <chip>_identify_vout(priv->i2c_dev) [optional] + read VOUT_MODE; refine info->format[PSC_VOLTAGE_OUT] + pmbus_regulator_apply_voltage_scale(dev, fb_div) [optional] + write PMBUS_VOUT_SCALE_LOOP if DT property set + pmbus_register_chip(&<chip>_match) [idempotent] + pmbus_register_vendor_handler(&<chip>_op) [idempotent] + +Once probed, three independent surfaces are functional against +the same chip: + +* the regulator uclass API (``regulator_get_value``, + ``regulator_set_value``, ``regulator_get_enable``, + ``regulator_set_enable``) +* the ``pmbus`` CLI (chip is reachable by name through + ``pmbus_resolve_by_name()``, by raw ``<bus>:<addr>`` through + ``pmbus_set_active()``) +* the chip's vendor extension subcommands (``pmbus <vendor> ...``) + +Phase 4: board hooks and boot scripts +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boards hook the boot flow at well known points to drive board +specific PMBus behaviour. The framework prescribes none of these; +they are conventions: + +* boot time rail snapshot. An ``EVENT_SPY`` at + ``EVT_LAST_STAGE_INIT`` reads telemetry through the regulator + uclass and prints a one shot summary to the console. Useful + for operator visibility on serial during bring up. + +* pre kernel rail trim (AVS). A board hook in + ``board_late_init`` or a custom event spy reads a fuse derived + target voltage and calls ``regulator_set_value_force()`` to + trim the SoC core rail before kernel handoff. + +* Linux handoff gate. A bootcmd reads the rail voltage + through the regulator command and refuses to boot Linux if + the rail is outside the expected range. + +Phase 5: Linux handoff +~~~~~~~~~~~~~~~~~~~~~~ + +When U-Boot transfers control to Linux, it passes the device +tree (potentially patched). The DT compatible strings for PMBus +regulators must match those in the upstream kernel binding so +the kernel's ``drivers/hwmon/pmbus/<chip>.c`` picks them up. +Property names are shared with the kernel binding +(``regulator-name``, ``regulator-min-microvolt``, +``mps,vout-fb-divider-ratio-permille``, etc.); see "DT alignment +with Linux" below. + +The chip itself is left in the state U-Boot wrote it to. If +U-Boot trimmed VOUT, the chip stays at the trimmed voltage +through handoff. ``CLEAR_FAULTS`` state is preserved unless an +operator explicitly issued one. + +Phase 6: Linux runtime +~~~~~~~~~~~~~~~~~~~~~~ + +Linux's ``drivers/hwmon/pmbus/pmbus_core.c`` probes the chip, +exposes telemetry under ``/sys/class/hwmon``, and takes over +runtime voltage management through its regulator subsystem. +The hwmon framework polls periodically; U-Boot does not. + +Operation paths through the regulator uclass +-------------------------------------------- + +After the first probe completes, calls into the regulator uclass +for a PMBus chip flow through the shared helper. + +Read VOUT:: + + regulator_get_value(dev) + -> dm_regulator_ops->get_value + -> pmbus_regulator_get_value(dev) + pmbus_regulator_select_page(priv) + pmbus_read_byte(priv->i2c_dev, VOUT_MODE, &mode) + pmbus_read_word(priv->i2c_dev, READ_VOUT, &raw) + pmbus_reg2data(priv->info, PSC_VOLTAGE_OUT, raw, mode) + -> reg2data_linear16 (mode = 0) + -> reg2data_direct (chip configured for DIRECT) + return engineering value (microvolts) + +Write VOUT:: + + regulator_set_value(dev, uV) + -> dm_regulator_ops->set_value + -> pmbus_regulator_set_value(dev, uV) + pmbus_regulator_select_page(priv) + pmbus_read_byte(VOUT_MODE) + check (mode == LINEAR) [LINEAR16 only today] + raw = pmbus_data2reg_linear16(uV, mode) + dm_i2c_write(VOUT_COMMAND, raw) + +Read / write enable bit:: + + regulator_get_enable(dev) + -> pmbus_regulator_get_enable(dev) + pmbus_read_byte(OPERATION) & PB_OPERATION_ON + + regulator_set_enable(dev, on) + -> pmbus_regulator_set_enable(dev, on) + read OPERATION, set or clear PB_OPERATION_ON, write back + +Bus traffic per call: + +* ``get_value`` : 1 byte read (VOUT_MODE) + 1 word read (READ_VOUT) + + 1 byte write (PAGE) when ``page > 0`` +* ``set_value`` : 1 byte read (VOUT_MODE) + 1 word write (VOUT_COMMAND) + + 1 byte write (PAGE) when ``page > 0`` +* ``get_enable`` : 1 byte read (OPERATION) +* ``set_enable`` : 1 byte read (OPERATION) + 1 byte write (OPERATION) + +Common board hook patterns +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Boot time rail snapshot:: + + static int my_board_pmbus_snapshot(void) + { + struct udevice *reg; + + if (regulator_get_by_platname("MY_RAIL", ®)) + return 0; + printf("MY_RAIL: VOUT = %d uV, enabled = %d\n", + regulator_get_value(reg), + regulator_get_enable(reg)); + return 0; + } + EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, my_board_pmbus_snapshot); + +The first call to ``regulator_get_value()`` triggers the chip +driver's ``.probe``, which seeds the chip match and vendor +extension registries. Subsequent ``pmbus`` CLI commands work +without further setup. + +Pre kernel rail trim (AVS):: + + int board_late_init(void) + { + struct udevice *reg; + int target_uV = compute_avs_target(); + + if (regulator_get_by_platname("VDD_CORE", ®)) + return 0; + return regulator_set_value_force(reg, target_uV); + } + +Use ``regulator_set_value_force()`` when the target may sit +outside the DT declared ``regulator-min-microvolt`` / +``regulator-max-microvolt`` range; force bypasses the bounds +check. + +Adding a new PMBus chip from scratch +------------------------------------ + +Use this path when the chip has no Linux driver yet, or when you want +to validate the U-Boot port against the datasheet alone. + +1. Confirm PMBus 1.x compliance level. Locate in the chip + datasheet: + + which PMBus standard command codes the chip implements + (``READ_VIN``, ``READ_VOUT``, ``STATUS_WORD``, ``MFR_ID`` ...), + which numeric format(s) it uses for VOUT (LINEAR16 with the + exponent in ``VOUT_MODE``, DIRECT with chip specific m/b/R, or + VID with one of the documented VRM tables), + which numeric format it uses for VIN, IIN, IOUT, TEMPERATURE + (most commonly LINEAR11; some MPS / MPS derivative chips use + DIRECT instead), + how many output rails it exposes (single page parts vs. + multi rail PMBus pages). + +2. Declare a ``struct pmbus_driver_info``. Wire each sensor + class to one ``enum pmbus_data_format``, plus the m/b/R triple if + the format is DIRECT:: + + static struct pmbus_driver_info chipname_info = { + .pages = 1, + .format[PSC_VOLTAGE_IN] = pmbus_fmt_direct, + .format[PSC_VOLTAGE_OUT] = pmbus_fmt_linear, + .format[PSC_CURRENT_OUT] = pmbus_fmt_direct, + .format[PSC_TEMPERATURE] = pmbus_fmt_direct, + .m[PSC_VOLTAGE_IN] = 4, .R[PSC_VOLTAGE_IN] = 1, + .m[PSC_CURRENT_OUT] = 16, .R[PSC_CURRENT_OUT] = 0, + .m[PSC_TEMPERATURE] = 1, .R[PSC_TEMPERATURE] = 0, + }; + +3. Bind to a DT compatible. Use the lowercase ``vendor,chip`` + tuple Linux uses (see "DT alignment with Linux" below). Add the + driver under ``drivers/power/regulator/`` matching the existing + skeleton (``fan53555.c``, ``pca9450.c``). + +4. Rely on the DT binding from the Linux kernel which is imported into + U-Boot under ``dts/upstream/Bindings/`` (for PMBus chips, + ``dts/upstream/Bindings/hwmon/pmbus/``). + +5. Smoke test. With the chip wired up in DT:: + + => regulator dev <name> + => regulator value + => regulator info + + Numbers should match the bench measurement to within the chip's + advertised LSB. + +Porting an existing Linux PMBus driver to U-Boot +------------------------------------------------ + +When the chip already has a ``linux/drivers/hwmon/pmbus/<chip>.c``, +that driver is the authoritative reference for format, coefficients, +and quirks. Take what carries; leave what does not. + +What carries verbatim +~~~~~~~~~~~~~~~~~~~~~ + +* Numeric formats (``format[PSC_*]``). +* DIRECT coefficients (``m[]``, ``b[]``, ``R[]``). +* Per page count and per page functionality bits (``pages``, + ``func[]``). +* VOUT_MODE driven per chip identify hook (e.g. MPQ8785's + switch between LINEAR16 and VID coerced DIRECT m=64 R=1). +* Vendor register addresses for chip specific quirks (fault + history, scale-loop, page mapping). + +What does not carry +~~~~~~~~~~~~~~~~~~~~~~~ + +* ``hwmon_device_register()`` and the attribute groups it consumes. +* ``struct pmbus_data`` / ``update_lock`` / ``last_updated`` + U-Boot has no caching layer. +* ALERT# IRQ wiring; U-Boot is single threaded boot code. +* Fan control hooks (``read_fan_*``, ``set_pwm_*``). +* Virtual register handling (``PMBUS_VIRT_READ_VIN_*`` etc.); those + are entirely a hwmon publication aid. +* ``module_i2c_driver(...)`` and ``MODULE_*`` macros; U-Boot uses + ``U_BOOT_DRIVER(...)``. + +Worked example: porting MPQ8785 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Linux's ``drivers/hwmon/pmbus/mpq8785.c`` is 193 LOC; the U-Boot +equivalent is ~150 LOC. + +The ``mpq8785_info`` struct transcribes verbatim:: + + .pages = 1, + .format[PSC_VOLTAGE_IN] = direct, .m[PSC_VOLTAGE_IN] = 4, .R[PSC_VOLTAGE_IN] = 1, + .format[PSC_CURRENT_OUT] = direct, .m[PSC_CURRENT_OUT] = 16, .R[PSC_CURRENT_OUT] = 0, + .format[PSC_TEMPERATURE] = direct, .m[PSC_TEMPERATURE] = 1, .R[PSC_TEMPERATURE] = 0, + +The VOUT format is decided at probe time from VOUT_MODE bits[7:5] : +mode 0 means LINEAR16, mode 1 or 2 means DIRECT m=64 R=1 (the chip's +"VID" mode is coerced to DIRECT by the driver). Translate Linux's +``mpq8785_identify()`` 1:1. + +The per chip quirks that carry over: + +* MPS NVM string byte order: chip stores ``S P M`` for the human + string ``MPS``. ``pmbus_read_string()`` accepts a ``reverse_bytes`` + flag for this case. +* ``mps,vout-fb-divider-ratio-permille`` DT property maps to + ``VOUT_SCALE_LOOP`` write at probe time. + +The quirks that do not carry over: + +* The ``PMBUS_VIRT_*`` virtual sensor wiring. Drop entirely. +* The ``hwmon_chip_info`` attribute group registration. +* The ``MODULE_AUTHOR`` / ``MODULE_LICENSE`` declarations. + +Using the generic ``compatible = "pmbus"`` driver +------------------------------------------------- + +When a board carries a PMBus chip without a per chip U-Boot driver, +the catch all ``drivers/power/regulator/pmbus_generic.c`` (Layer 3b) +binds against ``compatible = "pmbus"``. It auto detects format via +``VOUT_MODE`` and ``PMBUS_QUERY`` (where the chip supports it) and +provides telemetry + voltage set/get against the standard PMBus 1.x +subset. + +Decision tree: + +1. Try the generic driver first. Add the regulator node to the + board DT with ``compatible = "pmbus"`` plus the standard + regulator properties. Boot, run ``regulator value``, compare + against bench measurement. +2. Switch to a per chip driver only when the generic one is + wrong: telemetry shows wrong values (chip uses DIRECT with + non default coefficients), an alert can't be decoded (chip has + vendor specific status bits), AVS is needed (the boot path has + to actively trim VOUT before kernel handoff), or the chip has an + ADDR-pin auto promotion / VID coercion / vendor register quirk. + +DT alignment with Linux +----------------------- + +The same ``.dts`` file should work under both U-Boot (BL33) and Linux +post handoff. To make that possible: + +* Reuse the upstream Linux compatible for every PMBus chip. Look + in ``linux/Documentation/devicetree/bindings/hwmon/pmbus/`` and + ``linux/Documentation/devicetree/bindings/regulator/``. The + ``<vendor>,<chip>`` tuple from the kernel binding goes into U-Boot's + ``of_match_table`` unchanged. +* Reuse Linux property names verbatim: ``regulator-name``, + ``regulator-min-microvolt``, ``regulator-max-microvolt``, + ``regulator-boot-on``, ``regulator-always-on``, + ``mps,vout-fb-divider-ratio-permille``, etc. +* The DT binding is the kernel's, imported under + ``dts/upstream/Bindings/`` (PMBus chips live in + ``dts/upstream/Bindings/hwmon/pmbus/``). + +Multi rail/multi page chips (e.g. ISL68137 with seven outputs) +declare each rail as a child regulator node with ``reg = <page>``; +each child binds as a UCLASS_REGULATOR with that PMBus PAGE setting +applied at every read/write. + +Common pitfalls +--------------- + +These have all bitten contributors during nbxv3 bring up; record them +here so the next port doesn't repeat them. + +* VOUT_MODE/DIRECT format confusion. Most generic PMBus call + sites assume LINEAR16. Several MPS chips report VOUT in DIRECT + format with chip specific m/b/R after a single VOUT_MODE read, + the same chip read at the same address produces different + numbers depending on the format the driver applies. Always read + ``VOUT_MODE`` at probe time and switch the decoder accordingly. + Linux's per chip ``identify()`` callbacks document the exact + rules; copy them rather than guessing. +* SMBus block read protocol. Some I2C controllers strict check + block read transactions: the master must read the length byte + first, then reissue the read for the payload. Over reading a + fixed length and ignoring the length byte works on lenient + controllers but errors on strict ones. ``pmbus_read_string()`` + does the two stage read; use it. +* I2C bus number stability. ``uclass_get_device_by_seq()`` + uses the DT alias index (``i2c0`` -> ``UCLASS_I2C`` seq 0) when + aliases are declared, otherwise falls back to probe order which + varies with which controllers are enabled in the defconfig. + Always declare DT aliases for I2C buses you reference by index. +* ADDR-pin auto addressessing. Some chips (notably MPS parts) decode + their PMBus 7-bit address from an external resistor divider on + ADDR_VBOOT. The "default" address in the datasheet is the + factory fused slot; a board with a different divider or a die + with a different revision can land in another window. If the + driver hardcodes the default and the board side scan finds the + chip in another window, auto promote the working address rather + than failing the probe. +* MFR string byte order. Most PMBus chips return ``MFR_ID`` + characters in human order. Some MPS personalities reverse them. + Pass ``reverse_bytes=true`` to ``pmbus_read_string()`` for those; + spec compliant chips pass false. + +References +---------- + +* Linux PMBus core: ``linux/drivers/hwmon/pmbus/pmbus_core.c``, + decoder reference; ignore the hwmon publication and caching layers. +* Linux PMBus header: ``linux/drivers/hwmon/pmbus/pmbus.h``; API + surface reference; many constants and the ``struct + pmbus_driver_info`` shape are mirrored verbatim into U-Boot's + ``include/pmbus.h``. +* Linux DT bindings: + ``linux/Documentation/devicetree/bindings/hwmon/pmbus/``. diff --git a/doc/develop/pytest/test_fit.rst b/doc/develop/pytest/test_fit.rst new file mode 100644 index 00000000000..3a2359f1e89 --- /dev/null +++ b/doc/develop/pytest/test_fit.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +test_fit +======== + +.. automodule:: test_fit + :synopsis: + :member-order: bysource + :members: + :undoc-members: diff --git a/doc/develop/pytest/usage.rst b/doc/develop/pytest/usage.rst index e9296fd1f44..a9b8b8bd610 100644 --- a/doc/develop/pytest/usage.rst +++ b/doc/develop/pytest/usage.rst @@ -411,7 +411,7 @@ The board can be switched off now. Examples '''''''' -https://source.denx.de/u-boot/u-boot-test-hooks contains some working example hook +https://git.u-boot-project.org/u-boot/u-boot-test-hooks contains some working example hook scripts, and may be useful as a reference when implementing hook scripts for your platform. These scripts are not considered part of U-Boot itself. @@ -546,11 +546,11 @@ following annotation for a test requires ``CONFIG_EFI_LOADER=y``: 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: +either of ``CONFIG_NET_LEGACY`` or ``CONFIG_NET_LWIP`` is set: .. code-block:: python - @pytest.mark.buildconfigspec('net', 'net_lwip') + @pytest.mark.buildconfigspec('net_legacy', 'net_lwip') The ``notbuildconfigspec()`` annotation can be used to require a configuration option not to be set. The following annotation requires ``CONFIG_RISCV=n``: diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index 69678f2897a..ee77e8827df 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -1,4 +1,4 @@ -.. |next_ver| replace:: v2026.07 +.. |next_ver| replace:: v2026.10 Release Cycle ============= @@ -53,15 +53,15 @@ Examples:: Current Status -------------- -* U-Boot v2026.04 was released on Monday, 06 April 2026. +* U-Boot v2026.07 was released on Monday, 06 July 2026. * The Merge Window for the next release (|next_ver|) is **open** until the -rc1 - release on Monday, 27 April 2026. + release on Monday, 27 July 2026. -* The next branch is now **closed** until the -rc2 release on Monday, 11 - May 2026. +* The next branch is now **closed** until the -rc2 release on Monday, 10 + August 2026. -* Release "|next_ver|" is scheduled for Monday, 06 July 2026. +* Release "|next_ver|" is scheduled for Monday, 05 October 2026. Future Releases --------------- @@ -71,32 +71,36 @@ Future Releases .. For the next scheduled release, release candidates were made on: -.. * U-Boot |next_ver|-rc1 was released on Mon 11 May 2026. +.. * U-Boot |next_ver|-rc1 was released on Mon 27 July 2026. -.. * U-Boot |next_ver|-rc2 was released on Mon 25 May 2026. +.. * U-Boot |next_ver|-rc2 was released on Mon 10 August 2026. -.. * U-Boot |next_ver|-rc3 was released on Mon 08 June 2026. +.. * U-Boot |next_ver|-rc3 was released on Mon 24 August 2026. -.. * U-Boot |next_ver|-rc4 was released on Mon 22 June 2026. +.. * U-Boot |next_ver|-rc4 was released on Mon 07 September 2026. + +.. * U-Boot |next_ver|-rc5 was released on Mon 21 September 2026. Please note that the following dates are planned only and may be deviated from as needed. -* "v2026.07": end of MW = Mon, Apr 27, 2026; release = Mon, Jul 06, 2026 - * "v2026.10": end of MW = Mon, Jul 27, 2026; release = Mon, Oct 05, 2026 * "v2027.01": end of MW = Mon, Oct 26, 2026; release = Mon, Jan 04, 2027 * "v2027.04": end of MW = Mon, Jan 25, 2027; release = Mon, Apr 05, 2027 +* "v2027.07": end of MW = Mon, Apr 26, 2027; release = Mon, Jul 05, 2027 + Previous Releases ----------------- Note: these statistics are generated by our fork of `gitdm -<https://source.denx.de/u-boot/gitdm>`_, which was originally created by +<https://git.u-boot-project.org/u-boot/gitdm>`_, which was originally created by Jonathan Corbet. +* :doc:`statistics/u-boot-stats-v2026.07` which was released on 06 July 2026. + * :doc:`statistics/u-boot-stats-v2026.04` which was released on 06 April 2026. * :doc:`statistics/u-boot-stats-v2026.01` which was released on 05 January 2026. diff --git a/doc/develop/security.rst b/doc/develop/security.rst index 84b130646f3..ed652ec756e 100644 --- a/doc/develop/security.rst +++ b/doc/develop/security.rst @@ -11,7 +11,7 @@ Contact ------- The preferred initial point of contact is to send email to -`[email protected]` and use `scripts/get_maintainers.pl` to also include any +`[email protected]` and use `scripts/get_maintainers.pl` to also include any relevant custodians. In addition, Tom Rini should be contacted at diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst index e29fa175727..8172dc55183 100644 --- a/doc/develop/sending_patches.rst +++ b/doc/develop/sending_patches.rst @@ -5,7 +5,7 @@ Sending patches *Before you begin* to implement any new ideas or concepts it is always a good idea to present your plans on the `U-Boot mailing list -<https://lists.denx.de/listinfo/u-boot>`_. U-Boot supports a huge amount of +<https://lists.u-boot-project.org/listinfo/u-boot>`_. U-Boot supports a huge amount of very different systems, and it is often impossible for the individual developer to oversee the consequences of a specific change to all architectures. Discussing concepts early can help you to avoid spending effort on code which, @@ -17,20 +17,77 @@ A good introduction how to prepare for submitting patches can be found in the LWN article `How to Get Your Change Into the Linux Kernel <http://lwn.net/Articles/139918/>`_ as the same rules apply to U-Boot, too. +.. _b4_contrib: + +Using b4 +-------- + +Use the `b4 <https://b4.docs.kernel.org/en/latest/>`__ tool to prepare and send +your patches. b4 has become the preferred tool to sending patches for many Linux +kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that +targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` +for recipient discovery. + +Start a topical series with ``b4 prep`` and keep the commits organised with +``git rebase -i``. ``b4 prep --edit-cover`` opens an editor for the cover letter, +while ``b4 prep --auto-to-cc`` collects reviewers and maintainers from both the +configuration file and ``scripts/get_maintainer.pl``. + +.. code-block:: bash + + b4 prep -n mmc-fixes + git rebase -i origin/master + b4 prep --edit-cover + b4 prep --auto-to-cc + +Run the style checks before sending. ``b4 prep --check`` wraps the existing +tooling so you see the output from ``scripts/checkpatch.pl`` alongside b4's own +validation. You can always invoke ``scripts/checkpatch.pl`` directly for +additional runs. + +.. code-block:: bash + + b4 prep --check + +When the series is ready, use ``b4 send``. Begin with ``--dry-run`` to review the +generated emails and ``--reflect`` to copy yourself for records before +dispatching to ``[email protected]``. + +.. code-block:: bash + + b4 send --dry-run + b4 send --reflect + b4 send + +After reviews arrive, collect Acked-by/Tested-by tags with ``b4 trailers -u`` and +fold them into your commits before resending the updated series. + +.. code-block:: bash + + b4 trailers -u + git rebase -i origin/master + b4 send + Using patman ------------ You can use a tool called patman to prepare, check and send patches. It creates change logs, cover letters and patch notes. It also simplifies the process of -sending multiple versions of a series. +sending multiple versions of a series. patman is driven by tags in your commit +messages, and can collect Reviewed-by and other tags from patchwork when you +send a new version. It can optionally keep a local database of all your series, +tracking each version and their review / applied status over time, so you can +easily track upstreaming progress. -See more details at :doc:`patman`. +patman now lives outside the U-Boot tree; install it with +``pip install patch-manager``. See the +`patman documentation <https://deinde.dev/patman>`_ for details. General Patch Submission Rules ------------------------------ -* All patches must be sent to the `[email protected] - <https://lists.denx.de/listinfo/u-boot>`_ mailing list. +* All patches must be sent to the `[email protected] + <https://lists.u-boot-project.org/listinfo/u-boot>`_ mailing list. * If your patch affects the code maintained by one of the :ref:`custodians`, CC them when emailing your patch. The easiest way to make sure you don't forget @@ -77,7 +134,7 @@ General Patch Submission Rules patches is by using the ``git format-patch`` command. For a patch that is fixing a bug or regression of some sort, please use the ``master`` branch of the mainline U-Boot git repository located at - https://source.denx.de/u-boot/u-boot.git as reference. For new features, if + https://git.u-boot-project.org/u-boot/u-boot.git as reference. For new features, if the ``next`` branch has been opened (which happens with the release of ``-rc2``) that branch should be used, otherwise ``master`` is acceptable. @@ -88,7 +145,7 @@ General Patch Submission Rules If you believe you need to use a mailing list for testing (instead of any regular mail address you own), we have a special test list for such purposes. It would be best to subscribe to the list for the duration of your tests to - avoid repeated moderation - see https://lists.denx.de/listinfo/test + avoid repeated moderation - see https://lists.u-boot-project.org/listinfo/test * Choose a meaningful Subject: - keep in mind that the Subject will also be visible as headline of your commit message. Make sure the subject does not diff --git a/doc/develop/statistics/u-boot-stats-v2026.07.rst b/doc/develop/statistics/u-boot-stats-v2026.07.rst new file mode 100644 index 00000000000..724419a444a --- /dev/null +++ b/doc/develop/statistics/u-boot-stats-v2026.07.rst @@ -0,0 +1,884 @@ +:orphan: + +Release Statistics for U-Boot v2026.07 +====================================== + +* Processed 1328 changesets from 212 developers + +* 25 employers found + +* A total of 255173 lines added, 91237 removed (delta 163936) + +.. table:: Developers with the most changesets + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + David Lechner 139 (10.5%) + Tom Rini 96 (7.2%) + Simon Glass 94 (7.1%) + Marek Vasut 72 (5.4%) + Peng Fan 56 (4.2%) + Heinrich Schuchardt 42 (3.2%) + Julien Stephan 32 (2.4%) + Michal Simek 27 (2.0%) + Jonas Karlman 24 (1.8%) + Dario Binacchi 19 (1.4%) + Ye Li 17 (1.3%) + Quentin Schulz 16 (1.2%) + Mikhail Kshevetskiy 15 (1.1%) + Svyatoslav Ryhel 15 (1.1%) + Francois Berder 14 (1.1%) + Raymond Mao 13 (1.0%) + Neha Malcom Francis 12 (0.9%) + Janne Grunau 12 (0.9%) + Kory Maincent 12 (0.9%) + Richard Genoud 12 (0.9%) + Casey Connolly 11 (0.8%) + Emanuele Ghidoli 11 (0.8%) + Rasmus Villemoes 11 (0.8%) + Francesco Dolcini 11 (0.8%) + Balaji Selvanathan 11 (0.8%) + Alice Guo 10 (0.8%) + Michael Walle 10 (0.8%) + Hrushikesh Salunke 10 (0.8%) + Sparsh Kumar 10 (0.8%) + Luca Weiss 9 (0.7%) + Vincent Stehlé 9 (0.7%) + Johan Jonker 9 (0.7%) + Pranav Tilak 9 (0.7%) + Angelo Dureghello 9 (0.7%) + Alexey Charkov 8 (0.6%) + Aswin Murugan 8 (0.6%) + Torsten Duwe 8 (0.6%) + Patrice Chotard 8 (0.6%) + Mathew McBride 8 (0.6%) + Varadarajan Narayanan 8 (0.6%) + Max Merchel 8 (0.6%) + Christian Marangi 8 (0.6%) + Alexander Feilke 7 (0.5%) + Chris-QJ Chen 7 (0.5%) + Hal Feng 7 (0.5%) + Javier Martinez Canillas 7 (0.5%) + Heiko Schocher 6 (0.5%) + Markus Schneider-Pargmann (TI) 6 (0.5%) + Noah.Shen 6 (0.5%) + Pranav Sanwal 6 (0.5%) + Padmarao Begari 6 (0.5%) + Dan Carpenter 6 (0.5%) + Wojciech Dubowik 6 (0.5%) + Rafał Miłecki 6 (0.5%) + Brian Ruley 6 (0.5%) + Tanmay Kathpalia 5 (0.4%) + Wadim Egorov 5 (0.4%) + Franz Schnyder 5 (0.4%) + Jamie Gibbons 5 (0.4%) + Prashant Kamble 5 (0.4%) + Anshul Dalal 5 (0.4%) + Ludwig Nussel 5 (0.4%) + E Shattow 5 (0.4%) + Adrian Freihofer 5 (0.4%) + Aristo Chen 4 (0.3%) + Shiji Yang 4 (0.3%) + Christian DREHER 4 (0.3%) + Randolph Sapp 4 (0.3%) + Andre Przywara 4 (0.3%) + Ferass El Hafidi 4 (0.3%) + Daniel Palmer 4 (0.3%) + Chunguang Li 4 (0.3%) + Paresh Bhagat 4 (0.3%) + Ion Agorria 4 (0.3%) + Niko Mauno 4 (0.3%) + Vignesh Raghavendra 4 (0.3%) + Neil Armstrong 3 (0.2%) + Sam Day 3 (0.2%) + Denis Mukhin 3 (0.2%) + Sumit Garg 3 (0.2%) + Christian Pötzsch 3 (0.2%) + Lucien.Jheng 3 (0.2%) + Siddharth Vadapalli 3 (0.2%) + Paul HENRYS 3 (0.2%) + Vitor Soares 3 (0.2%) + Michele Bisogno 3 (0.2%) + Primoz Fiser 3 (0.2%) + Sam Shih 3 (0.2%) + Ssunk 3 (0.2%) + Ngo Luong Thanh Tra 3 (0.2%) + Ioana Ciornei 3 (0.2%) + Markus Niebel 3 (0.2%) + Jonas Schwöbel 3 (0.2%) + Lukas Stockmann 3 (0.2%) + Brian Sune 3 (0.2%) + Alif Zakuan Yuslaimi 3 (0.2%) + Ilias Apalodimas 2 (0.2%) + Peter Robinson 2 (0.2%) + João Marcos Costa 2 (0.2%) + Mateusz Furdyna 2 (0.2%) + Zixun LI 2 (0.2%) + Gurumoorthy Santhakumar 2 (0.2%) + Francesco Valla 2 (0.2%) + Yann Gautier 2 (0.2%) + Peter Collingbourne 2 (0.2%) + Vincent Jardin 2 (0.2%) + Ernest Van Hoecke 2 (0.2%) + Weijie Gao 2 (0.2%) + Shiva Tripathi 2 (0.2%) + Paul Kocialkowski 2 (0.2%) + Macpaul Lin 2 (0.2%) + Gregor Herburger 2 (0.2%) + Philip Molloy 2 (0.2%) + Simona Toaca 2 (0.2%) + Flaviu Nistor 2 (0.2%) + Chen Huei Lok 2 (0.2%) + Jeffrey Yu 2 (0.2%) + Sean Anderson 2 (0.2%) + Paul Gerber 2 (0.2%) + Boon Khai Ng 2 (0.2%) + Kavin Gunasekara 2 (0.2%) + Fabio Estevam 2 (0.2%) + Shantur Rathore 2 (0.2%) + Dominik Haller 2 (0.2%) + Bo-Chen Chen 2 (0.2%) + Finley Xiao 2 (0.2%) + Walter Schweizer 2 (0.2%) + Julien Masson 2 (0.2%) + Dinesh Maniyam 2 (0.2%) + Vagrant Cascadian 2 (0.2%) + Mattijs Korpershoek 1 (0.1%) + Andrew Goodbody 1 (0.1%) + Quentin Strydom 1 (0.1%) + Piyush Paliwal 1 (0.1%) + Heiko Stuebner 1 (0.1%) + Colin Pinnell McAllister 1 (0.1%) + Petr Hodina 1 (0.1%) + Udit Kumar 1 (0.1%) + Federico Amedeo Izzo 1 (0.1%) + Frank Böwingloh 1 (0.1%) + Frieder Schrempf 1 (0.1%) + Andrea della Porta 1 (0.1%) + Giovanni Santini 1 (0.1%) + Tony Dinh 1 (0.1%) + Nguyen Tran 1 (0.1%) + Jan Čermák 1 (0.1%) + Lionel Debieve 1 (0.1%) + Liel Harel 1 (0.1%) + Suhaas Joshi 1 (0.1%) + Moteen Shah 1 (0.1%) + Harsimran Singh Tungal 1 (0.1%) + Mark Kettenis 1 (0.1%) + Tze Yee Ng 1 (0.1%) + Raphaël Gallais-Pou 1 (0.1%) + Austin Shirley 1 (0.1%) + Alexander Sverdlin 1 (0.1%) + Brad Klingerman 1 (0.1%) + Charles Perry 1 (0.1%) + Sebastian Josue Alba Vives 1 (0.1%) + Julian Braha 1 (0.1%) + yan wang 1 (0.1%) + Johannes Krottmayer 1 (0.1%) + Yixun Lan 1 (0.1%) + Jernej Skrabec 1 (0.1%) + Lukas Schmid 1 (0.1%) + Chanhong Jung 1 (0.1%) + Christoph Niedermaier 1 (0.1%) + Meiker Gao 1 (0.1%) + ht.lin 1 (0.1%) + Maximilian Brune 1 (0.1%) + Ajit Singh 1 (0.1%) + Antony Kurniawan Soemardi 1 (0.1%) + Eugen Hristev 1 (0.1%) + Levi Shafter 1 (0.1%) + Michael Zimmermann 1 (0.1%) + Rafał Hibner 1 (0.1%) + Kuan-Wei Chiu 1 (0.1%) + Nora Schiffer 1 (0.1%) + Philippe Reynes 1 (0.1%) + Michael Opdenacker 1 (0.1%) + Matwey V. Kornilov 1 (0.1%) + Hugo Villeneuve 1 (0.1%) + Javier Viguera 1 (0.1%) + Kamlesh Gurudasani 1 (0.1%) + Cathy Xu 1 (0.1%) + Neil Berkman 1 (0.1%) + Tomas Alvarez Vanoli 1 (0.1%) + Krzysztof Kozlowski 1 (0.1%) + Javen Xu 1 (0.1%) + Miquel Raynal 1 (0.1%) + Manorit Chawdhry 1 (0.1%) + Ozan Durgut 1 (0.1%) + Abbarapu Venkatesh Yadav 1 (0.1%) + Han Xu 1 (0.1%) + Irving-CH Lin 1 (0.1%) + Caleb Ethridge 1 (0.1%) + Anton Moryakov 1 (0.1%) + Nikita Shubin 1 (0.1%) + Anurag Dutta 1 (0.1%) + Dimitrios Siganos 1 (0.1%) + Tommy Shih 1 (0.1%) + Nick Hu 1 (0.1%) + Andreas Schwab 1 (0.1%) + Ye Zhang 1 (0.1%) + Xuhui Lin 1 (0.1%) + Martin Schwan 1 (0.1%) + Sébastien Szymanski 1 (0.1%) + Ronald Wahl 1 (0.1%) + Christoph Reiter 1 (0.1%) + Jean-Marie Verdun 1 (0.1%) + Tien Fong Chee 1 (0.1%) + Naresh Kumar Ravulapalli 1 (0.1%) + ==================================== ===== + + +.. table:: Developers with the most changed lines + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Tom Rini 147099 (48.3%) + Marek Vasut 20546 (6.8%) + Simon Glass 18934 (6.2%) + Neha Malcom Francis 18915 (6.2%) + David Lechner 10414 (3.4%) + Johan Jonker 7693 (2.5%) + Peng Fan 7101 (2.3%) + Chris-QJ Chen 5103 (1.7%) + Christian Marangi 3770 (1.2%) + Michael Walle 3248 (1.1%) + Brian Sune 3146 (1.0%) + Janne Grunau 2820 (0.9%) + Primoz Fiser 2644 (0.9%) + Ernest Van Hoecke 2485 (0.8%) + Emanuele Ghidoli 2468 (0.8%) + Bo-Chen Chen 2457 (0.8%) + Finley Xiao 2132 (0.7%) + Raymond Mao 2119 (0.7%) + Alice Guo 2052 (0.7%) + Paresh Bhagat 2012 (0.7%) + Sparsh Kumar 1680 (0.6%) + Julien Masson 1589 (0.5%) + Ye Li 1554 (0.5%) + Kory Maincent 1483 (0.5%) + Dan Carpenter 1470 (0.5%) + Franz Schnyder 1460 (0.5%) + Alexander Feilke 1412 (0.5%) + Quentin Schulz 1278 (0.4%) + Balaji Selvanathan 1217 (0.4%) + Cathy Xu 1125 (0.4%) + Dario Binacchi 1094 (0.4%) + Julien Stephan 1066 (0.4%) + Jonas Karlman 1025 (0.3%) + Nguyen Tran 1012 (0.3%) + Andreas Schwab 997 (0.3%) + Brian Ruley 984 (0.3%) + Lucien.Jheng 790 (0.3%) + Heinrich Schuchardt 739 (0.2%) + Tommy Shih 647 (0.2%) + Svyatoslav Ryhel 641 (0.2%) + Torsten Duwe 591 (0.2%) + Irving-CH Lin 580 (0.2%) + Aswin Murugan 578 (0.2%) + Hrushikesh Salunke 562 (0.2%) + Richard Genoud 547 (0.2%) + Casey Connolly 538 (0.2%) + Luca Weiss 518 (0.2%) + Michal Simek 499 (0.2%) + Mathew McBride 474 (0.2%) + Ye Zhang 473 (0.2%) + Pranav Sanwal 439 (0.1%) + Markus Niebel 384 (0.1%) + Jamie Gibbons 347 (0.1%) + Rasmus Villemoes 343 (0.1%) + Max Merchel 332 (0.1%) + Varadarajan Narayanan 303 (0.1%) + Alexey Charkov 268 (0.1%) + Padmarao Begari 255 (0.1%) + Wojciech Dubowik 249 (0.1%) + Tanmay Kathpalia 216 (0.1%) + Tien Fong Chee 216 (0.1%) + Shantur Rathore 208 (0.1%) + Paul Gerber 206 (0.1%) + Mikhail Kshevetskiy 186 (0.1%) + Markus Schneider-Pargmann (TI) 177 (0.1%) + Francesco Dolcini 171 (0.1%) + Vincent Stehlé 165 (0.1%) + Tze Yee Ng 156 (0.1%) + Anshul Dalal 136 (0.0%) + Javier Martinez Canillas 129 (0.0%) + Noah.Shen 128 (0.0%) + Adrian Freihofer 121 (0.0%) + Sean Anderson 120 (0.0%) + Martin Schwan 114 (0.0%) + Heiko Schocher 112 (0.0%) + Pranav Tilak 111 (0.0%) + Christian Pötzsch 105 (0.0%) + Miquel Raynal 101 (0.0%) + Paul HENRYS 96 (0.0%) + Mateusz Furdyna 92 (0.0%) + Shiva Tripathi 88 (0.0%) + Andre Przywara 85 (0.0%) + Johannes Krottmayer 84 (0.0%) + Angelo Dureghello 78 (0.0%) + Niko Mauno 78 (0.0%) + Christian DREHER 74 (0.0%) + Hal Feng 73 (0.0%) + Daniel Palmer 72 (0.0%) + Randolph Sapp 69 (0.0%) + Francois Berder 68 (0.0%) + Ion Agorria 67 (0.0%) + Lukas Stockmann 59 (0.0%) + Paul Kocialkowski 59 (0.0%) + Michele Bisogno 58 (0.0%) + Federico Amedeo Izzo 56 (0.0%) + Philip Molloy 54 (0.0%) + Sumit Garg 53 (0.0%) + Manorit Chawdhry 50 (0.0%) + E Shattow 49 (0.0%) + Chunguang Li 48 (0.0%) + Peter Collingbourne 48 (0.0%) + Alif Zakuan Yuslaimi 47 (0.0%) + Ngo Luong Thanh Tra 45 (0.0%) + Prashant Kamble 41 (0.0%) + Dinesh Maniyam 40 (0.0%) + Gregor Herburger 38 (0.0%) + Jonas Schwöbel 36 (0.0%) + Ioana Ciornei 34 (0.0%) + Rafał Miłecki 33 (0.0%) + Ssunk 29 (0.0%) + Jeffrey Yu 26 (0.0%) + Vitor Soares 25 (0.0%) + Vincent Jardin 25 (0.0%) + Patrice Chotard 23 (0.0%) + Aristo Chen 23 (0.0%) + Wadim Egorov 22 (0.0%) + Siddharth Vadapalli 22 (0.0%) + Sam Shih 22 (0.0%) + Weijie Gao 22 (0.0%) + Neil Armstrong 21 (0.0%) + Suhaas Joshi 21 (0.0%) + Eugen Hristev 21 (0.0%) + Ozan Durgut 21 (0.0%) + Nora Schiffer 20 (0.0%) + Shiji Yang 19 (0.0%) + Zixun LI 19 (0.0%) + Krzysztof Kozlowski 19 (0.0%) + Christoph Reiter 19 (0.0%) + João Marcos Costa 18 (0.0%) + Boon Khai Ng 17 (0.0%) + Ludwig Nussel 15 (0.0%) + Vignesh Raghavendra 15 (0.0%) + Macpaul Lin 15 (0.0%) + Meiker Gao 14 (0.0%) + Kavin Gunasekara 13 (0.0%) + Dominik Haller 12 (0.0%) + Austin Shirley 12 (0.0%) + Ferass El Hafidi 11 (0.0%) + Charles Perry 11 (0.0%) + Chanhong Jung 11 (0.0%) + Sam Day 10 (0.0%) + Yann Gautier 10 (0.0%) + Udit Kumar 10 (0.0%) + yan wang 10 (0.0%) + Dimitrios Siganos 10 (0.0%) + Nick Hu 10 (0.0%) + Denis Mukhin 9 (0.0%) + Walter Schweizer 9 (0.0%) + Christoph Niedermaier 8 (0.0%) + Javier Viguera 8 (0.0%) + Neil Berkman 8 (0.0%) + Piyush Paliwal 7 (0.0%) + Abbarapu Venkatesh Yadav 7 (0.0%) + Peter Robinson 6 (0.0%) + Gurumoorthy Santhakumar 6 (0.0%) + Flaviu Nistor 6 (0.0%) + Yixun Lan 6 (0.0%) + Hugo Villeneuve 6 (0.0%) + Kamlesh Gurudasani 6 (0.0%) + Fabio Estevam 5 (0.0%) + Mattijs Korpershoek 5 (0.0%) + Colin Pinnell McAllister 5 (0.0%) + Raphaël Gallais-Pou 5 (0.0%) + Alexander Sverdlin 5 (0.0%) + Antony Kurniawan Soemardi 5 (0.0%) + Anurag Dutta 5 (0.0%) + Ilias Apalodimas 4 (0.0%) + Andrew Goodbody 4 (0.0%) + Liel Harel 4 (0.0%) + Sebastian Josue Alba Vives 4 (0.0%) + Jean-Marie Verdun 4 (0.0%) + Simona Toaca 3 (0.0%) + Chen Huei Lok 3 (0.0%) + Jan Čermák 3 (0.0%) + Harsimran Singh Tungal 3 (0.0%) + Kuan-Wei Chiu 3 (0.0%) + Han Xu 3 (0.0%) + Caleb Ethridge 3 (0.0%) + Anton Moryakov 3 (0.0%) + Francesco Valla 2 (0.0%) + Vagrant Cascadian 2 (0.0%) + Ajit Singh 2 (0.0%) + Levi Shafter 2 (0.0%) + Michael Zimmermann 2 (0.0%) + Matwey V. Kornilov 2 (0.0%) + Nikita Shubin 2 (0.0%) + Quentin Strydom 1 (0.0%) + Heiko Stuebner 1 (0.0%) + Petr Hodina 1 (0.0%) + Frank Böwingloh 1 (0.0%) + Frieder Schrempf 1 (0.0%) + Andrea della Porta 1 (0.0%) + Giovanni Santini 1 (0.0%) + Tony Dinh 1 (0.0%) + Lionel Debieve 1 (0.0%) + Moteen Shah 1 (0.0%) + Mark Kettenis 1 (0.0%) + Brad Klingerman 1 (0.0%) + Julian Braha 1 (0.0%) + Jernej Skrabec 1 (0.0%) + Lukas Schmid 1 (0.0%) + ht.lin 1 (0.0%) + Maximilian Brune 1 (0.0%) + Rafał Hibner 1 (0.0%) + Philippe Reynes 1 (0.0%) + Michael Opdenacker 1 (0.0%) + Tomas Alvarez Vanoli 1 (0.0%) + Javen Xu 1 (0.0%) + Xuhui Lin 1 (0.0%) + Sébastien Szymanski 1 (0.0%) + Ronald Wahl 1 (0.0%) + Naresh Kumar Ravulapalli 1 (0.0%) + ==================================== ===== + + +.. table:: Developers with the most lines removed + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Simon Glass 16011 (17.5%) + Johan Jonker 7611 (8.3%) + Michael Walle 2998 (3.3%) + Janne Grunau 2599 (2.8%) + Ernest Van Hoecke 2348 (2.6%) + Franz Schnyder 1428 (1.6%) + Andreas Schwab 981 (1.1%) + Quentin Schulz 936 (1.0%) + Mathew McBride 319 (0.3%) + Francesco Dolcini 141 (0.2%) + Max Merchel 135 (0.1%) + Svyatoslav Ryhel 115 (0.1%) + Tanmay Kathpalia 101 (0.1%) + Zixun LI 18 (0.0%) + Aristo Chen 16 (0.0%) + Lukas Stockmann 15 (0.0%) + Weijie Gao 14 (0.0%) + Meiker Gao 14 (0.0%) + Wadim Egorov 12 (0.0%) + Rafał Miłecki 11 (0.0%) + João Marcos Costa 11 (0.0%) + Nick Hu 10 (0.0%) + Javier Viguera 7 (0.0%) + Siddharth Vadapalli 6 (0.0%) + Chanhong Jung 5 (0.0%) + Alexander Sverdlin 1 (0.0%) + ==================================== ===== + + +.. table:: Developers with the most signoffs (total 321) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Peng Fan 59 (18.4%) + David Lechner 45 (14.0%) + Casey Connolly 40 (12.5%) + Michal Simek 26 (8.1%) + Neil Armstrong 20 (6.2%) + Siddharth Vadapalli 10 (3.1%) + Mattijs Korpershoek 10 (3.1%) + Ilias Apalodimas 9 (2.8%) + Alice Guo 8 (2.5%) + Max Merchel 7 (2.2%) + Svyatoslav Ryhel 7 (2.2%) + Heiko Schocher 7 (2.2%) + Heiko Stuebner 4 (1.2%) + Macpaul Lin 4 (1.2%) + Anshul Dalal 4 (1.2%) + Jonas Karlman 4 (1.2%) + Ye Li 4 (1.2%) + Tom Rini 4 (1.2%) + Weijie Gao 3 (0.9%) + Walter Schweizer 3 (0.9%) + Adam Lackorzynski 2 (0.6%) + Meet Patel 2 (0.6%) + Shawn Guo 2 (0.6%) + Udit Kumar 2 (0.6%) + Julien Stephan 2 (0.6%) + Marek Vasut 2 (0.6%) + Simon Glass 1 (0.3%) + Michael Walle 1 (0.3%) + Ernest Van Hoecke 1 (0.3%) + Francesco Dolcini 1 (0.3%) + ht.lin 1 (0.3%) + AngeloGioacchino Del Regno 1 (0.3%) + Jerome Forissier 1 (0.3%) + Huy Bui 1 (0.3%) + Patrick Delaunay 1 (0.3%) + Keerthy 1 (0.3%) + Takuma Fujiwara 1 (0.3%) + Steffen Doster 1 (0.3%) + John Toomey 1 (0.3%) + Harini Katakam 1 (0.3%) + Venkatesh Yadav Abbarapu 1 (0.3%) + Mahammed Sadik Shaik 1 (0.3%) + Jimmy Ho 1 (0.3%) + Elaine Zhang 1 (0.3%) + Chen Huei Lok 1 (0.3%) + Yann Gautier 1 (0.3%) + Sumit Garg 1 (0.3%) + Andre Przywara 1 (0.3%) + Alexey Charkov 1 (0.3%) + Aswin Murugan 1 (0.3%) + Torsten Duwe 1 (0.3%) + Heinrich Schuchardt 1 (0.3%) + Balaji Selvanathan 1 (0.3%) + Alexander Feilke 1 (0.3%) + Paresh Bhagat 1 (0.3%) + Bo-Chen Chen 1 (0.3%) + Brian Sune 1 (0.3%) + ==================================== ===== + + +.. table:: Developers with the most reviews (total 791) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Julien Stephan 100 (12.6%) + Simon Glass 90 (11.4%) + Tom Rini 53 (6.7%) + Peng Fan 50 (6.3%) + Ilias Apalodimas 46 (5.8%) + Kever Yang 41 (5.2%) + Macpaul Lin 34 (4.3%) + Neil Armstrong 33 (4.2%) + Quentin Schulz 33 (4.2%) + Marek Vasut 24 (3.0%) + Sumit Garg 23 (2.9%) + Heinrich Schuchardt 22 (2.8%) + Mattijs Korpershoek 17 (2.1%) + Jerome Forissier 17 (2.1%) + Patrice Chotard 16 (2.0%) + Casey Connolly 15 (1.9%) + Peter Robinson 14 (1.8%) + Tien Fong Chee 11 (1.4%) + Heiko Schocher 9 (1.1%) + Leo Yu-Chi Liang 8 (1.0%) + Varadarajan Narayanan 8 (1.0%) + Francesco Dolcini 7 (0.9%) + João Marcos Costa 7 (0.9%) + Miquel Raynal 7 (0.9%) + Udit Kumar 6 (0.8%) + Anshul Dalal 5 (0.6%) + Andre Przywara 5 (0.6%) + Conor Dooley 5 (0.6%) + Paul Kocialkowski 5 (0.6%) + Raymond Mao 4 (0.5%) + Neha Malcom Francis 4 (0.5%) + Jonas Karlman 3 (0.4%) + Alexander Sverdlin 3 (0.4%) + Michael Trimarchi 3 (0.4%) + Greg Malysa 3 (0.4%) + E Shattow 3 (0.4%) + Kory Maincent 3 (0.4%) + Patrick Delaunay 2 (0.3%) + Jernej Skrabec 2 (0.3%) + Matthias Brugger 2 (0.3%) + Stefan Roese 2 (0.3%) + Yannic Moog 2 (0.3%) + Teresa Remmet 2 (0.3%) + Bryan Brattlof 2 (0.3%) + David Zang 2 (0.3%) + Raphaël Gallais-Pou 2 (0.3%) + Hal Feng 2 (0.3%) + Rasmus Villemoes 2 (0.3%) + Svyatoslav Ryhel 1 (0.1%) + Weijie Gao 1 (0.1%) + AngeloGioacchino Del Regno 1 (0.1%) + Manorit Chawdhry 1 (0.1%) + Kuan-Wei Chiu 1 (0.1%) + Thomas Petazzoni 1 (0.1%) + Andy Shevchenko 1 (0.1%) + Romain Naour 1 (0.1%) + Sebastian Reichel 1 (0.1%) + Bin Meng 1 (0.1%) + Ivan T. Ivanov 1 (0.1%) + Manikandan Muralidharan 1 (0.1%) + Javier Tia 1 (0.1%) + Alexander Dahl 1 (0.1%) + Dhruva Gole 1 (0.1%) + Christian Taedcke 1 (0.1%) + Wolfgang Wallner 1 (0.1%) + Linus Walleij 1 (0.1%) + Daniel Schwierzeck 1 (0.1%) + Tianrui Wei 1 (0.1%) + Shawn Lin 1 (0.1%) + Christopher Obbard 1 (0.1%) + Benjamin Hahn 1 (0.1%) + Radhey Shyam Pandey 1 (0.1%) + Tomas Melin 1 (0.1%) + Frieder Schrempf 1 (0.1%) + Tony Dinh 1 (0.1%) + Sam Day 1 (0.1%) + Sean Anderson 1 (0.1%) + Markus Schneider-Pargmann (TI) 1 (0.1%) + Lucien.Jheng 1 (0.1%) + Primoz Fiser 1 (0.1%) + ==================================== ===== + + +.. table:: Developers with the most test credits (total 94) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Julien Stephan 21 (22.3%) + Pedro Falcato 9 (9.6%) + Ilias Apalodimas 7 (7.4%) + Michal Simek 7 (7.4%) + Udit Kumar 6 (6.4%) + Anshul Dalal 6 (6.4%) + Dario Binacchi 6 (6.4%) + Wei Lu 4 (4.3%) + Aaron Griffith 4 (4.3%) + Neil Armstrong 3 (3.2%) + Peter Robinson 2 (2.1%) + Yannic Moog 2 (2.1%) + Quentin Schulz 1 (1.1%) + Marek Vasut 1 (1.1%) + Heinrich Schuchardt 1 (1.1%) + Mattijs Korpershoek 1 (1.1%) + Francesco Dolcini 1 (1.1%) + Andre Przywara 1 (1.1%) + Weijie Gao 1 (1.1%) + Kuan-Wei Chiu 1 (1.1%) + Wolfgang Wallner 1 (1.1%) + Ernest Van Hoecke 1 (1.1%) + Alexey Charkov 1 (1.1%) + Stefan Bosch 1 (1.1%) + Sughosh Ganu 1 (1.1%) + Ferass El Hafidi 1 (1.1%) + Angelo Dureghello 1 (1.1%) + Padmarao Begari 1 (1.1%) + Emanuele Ghidoli 1 (1.1%) + ==================================== ===== + + +.. table:: Developers who gave the most tested-by credits (total 94) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + David Lechner 21 (22.3%) + Raymond Mao 12 (12.8%) + Torsten Duwe 8 (8.5%) + Kory Maincent 7 (7.4%) + Neha Malcom Francis 6 (6.4%) + Ye Li 5 (5.3%) + Peng Fan 4 (4.3%) + Rasmus Villemoes 4 (4.3%) + Jonas Karlman 3 (3.2%) + Michal Simek 2 (2.1%) + Heinrich Schuchardt 2 (2.1%) + Simon Glass 2 (2.1%) + Siddharth Vadapalli 2 (2.1%) + Shantur Rathore 2 (2.1%) + Neil Armstrong 1 (1.1%) + Quentin Schulz 1 (1.1%) + Marek Vasut 1 (1.1%) + Sam Day 1 (1.1%) + ht.lin 1 (1.1%) + Wadim Egorov 1 (1.1%) + Andrea della Porta 1 (1.1%) + Xuhui Lin 1 (1.1%) + Liel Harel 1 (1.1%) + Abbarapu Venkatesh Yadav 1 (1.1%) + Ngo Luong Thanh Tra 1 (1.1%) + Francois Berder 1 (1.1%) + Daniel Palmer 1 (1.1%) + Ye Zhang 1 (1.1%) + ==================================== ===== + + +.. table:: Developers with the most report credits (total 15) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Simon Glass 3 (20.0%) + Julien Stephan 1 (6.7%) + Weijie Gao 1 (6.7%) + Tom Rini 1 (6.7%) + Yann Gautier 1 (6.7%) + Franz Schnyder 1 (6.7%) + Rudy Andram 1 (6.7%) + Mariusz Madej 1 (6.7%) + Anas Cherni 1 (6.7%) + Philippe Simons 1 (6.7%) + Yuya Hamamachi 1 (6.7%) + Christoph Niedermaier 1 (6.7%) + Suhaas Joshi 1 (6.7%) + ==================================== ===== + + +.. table:: Developers who gave the most report credits (total 15) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + David Lechner 3 (20.0%) + Heinrich Schuchardt 3 (20.0%) + Marek Vasut 2 (13.3%) + Rasmus Villemoes 1 (6.7%) + Michal Simek 1 (6.7%) + Quentin Schulz 1 (6.7%) + Anshul Dalal 1 (6.7%) + Patrice Chotard 1 (6.7%) + Jernej Skrabec 1 (6.7%) + Mateusz Furdyna 1 (6.7%) + ==================================== ===== + + +.. table:: Top changeset contributors by employer + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + (Unknown) 506 (38.1%) + BayLibre SAS 179 (13.5%) + Canonical 98 (7.4%) + Konsulko Group 96 (7.2%) + NXP 93 (7.0%) + Renesas Electronics 64 (4.8%) + Texas Instruments 60 (4.5%) + AMD 48 (3.6%) + Toradex 32 (2.4%) + Bootlin 27 (2.0%) + Linaro 23 (1.7%) + Amarula Solutions 19 (1.4%) + ARM 16 (1.2%) + Siemens 16 (1.2%) + ST Microelectronics 11 (0.8%) + SUSE 10 (0.8%) + Phytec 8 (0.6%) + Red Hat 7 (0.5%) + Rockchip 4 (0.3%) + Analog Devices 3 (0.2%) + Debian.org 2 (0.2%) + linutronix 2 (0.2%) + Nokia 2 (0.2%) + Digi International 1 (0.1%) + Gentoo 1 (0.1%) + ==================================== ===== + + +.. table:: Top lines changed by employer + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Konsulko Group 147099 (48.3%) + (Unknown) 52846 (17.4%) + Texas Instruments 23592 (7.8%) + Renesas Electronics 19393 (6.4%) + Canonical 18957 (6.2%) + BayLibre SAS 13246 (4.4%) + NXP 10795 (3.5%) + Toradex 6609 (2.2%) + Rockchip 2606 (0.9%) + Bootlin 2149 (0.7%) + Linaro 2037 (0.7%) + SUSE 1589 (0.5%) + AMD 1304 (0.4%) + Amarula Solutions 1094 (0.4%) + ARM 266 (0.1%) + Siemens 209 (0.1%) + Phytec 148 (0.0%) + Red Hat 129 (0.0%) + Nokia 92 (0.0%) + Analog Devices 57 (0.0%) + linutronix 38 (0.0%) + ST Microelectronics 34 (0.0%) + Digi International 8 (0.0%) + Gentoo 6 (0.0%) + Debian.org 2 (0.0%) + ==================================== ===== + + +.. table:: Employers with the most signoffs (total 321) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + NXP 71 (22.1%) + Linaro 69 (21.5%) + (Unknown) 62 (19.3%) + BayLibre SAS 47 (14.6%) + AMD 29 (9.0%) + Texas Instruments 20 (6.2%) + Konsulko Group 4 (1.2%) + ARM 4 (1.2%) + Renesas Electronics 3 (0.9%) + Siemens 3 (0.9%) + Canonical 2 (0.6%) + Toradex 2 (0.6%) + ST Microelectronics 2 (0.6%) + Rockchip 1 (0.3%) + SUSE 1 (0.3%) + Collabora Ltd. 1 (0.3%) + ==================================== ===== + + +.. table:: Employers with the most hackers (total 213) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + (Unknown) 134 (62.9%) + Texas Instruments 15 (7.0%) + NXP 7 (3.3%) + Linaro 5 (2.3%) + Siemens 5 (2.3%) + Toradex 5 (2.3%) + BayLibre SAS 4 (1.9%) + AMD 4 (1.9%) + ARM 4 (1.9%) + Bootlin 4 (1.9%) + ST Microelectronics 3 (1.4%) + Rockchip 3 (1.4%) + SUSE 3 (1.4%) + Phytec 3 (1.4%) + Renesas Electronics 2 (0.9%) + Canonical 2 (0.9%) + Analog Devices 2 (0.9%) + Konsulko Group 1 (0.5%) + Amarula Solutions 1 (0.5%) + Red Hat 1 (0.5%) + Nokia 1 (0.5%) + linutronix 1 (0.5%) + Digi International 1 (0.5%) + Gentoo 1 (0.5%) + Debian.org 1 (0.5%) + ==================================== ===== diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst index 3a2b496fa00..1d19b49e82c 100644 --- a/doc/develop/testing.rst +++ b/doc/develop/testing.rst @@ -22,7 +22,7 @@ the quick ones, type this:: make qcheck -It is also possible to run just the tests for tools (patman, binman, etc.). +It is also possible to run just the tests for tools (binman, buildman, etc.). Such tests are included with those tools, i.e. no actual U-Boot unit tests are run. Type this:: diff --git a/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml b/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml index df976c7ae73..ae3b5e6092a 100644 --- a/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml +++ b/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml @@ -18,7 +18,7 @@ properties: oneOf: - description: SC57X Series Boards items: - - const: adi,sc573-ezkit + - const: adi,sc573-ezlite - const: adi,sc57x - description: SC58X Series Boards diff --git a/doc/device-tree-bindings/bootcount-syscon.txt b/doc/device-tree-bindings/bootcount-syscon.txt index ea27b246c8a..8e6060a711e 100644 --- a/doc/device-tree-bindings/bootcount-syscon.txt +++ b/doc/device-tree-bindings/bootcount-syscon.txt @@ -1,6 +1,6 @@ Bootcount Configuration This is the implementation of the feature as described in -https://docs.u-boot.org/en/latest/api/bootcount.html +https://docs.u-boot-project.org/en/latest/api/bootcount.html Required Properties: - compatible: must be "u-boot,bootcount-syscon". diff --git a/doc/device-tree-bindings/pinctrl/apple,pinctrl.yaml b/doc/device-tree-bindings/pinctrl/apple,pinctrl.yaml deleted file mode 100644 index d50571affd1..00000000000 --- a/doc/device-tree-bindings/pinctrl/apple,pinctrl.yaml +++ /dev/null @@ -1,106 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/pinctrl/apple,pinctrl.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Apple GPIO controller - -maintainers: - - Mark Kettenis <[email protected]> - -description: | - The Apple GPIO controller is a simple combined pin and GPIO - controller present on Apple ARM SoC platforms, including various - iPhone and iPad devices and the "Apple Silicon" Macs. - -properties: - compatible: - items: - - const: apple,t8103-pinctrl - - const: apple,pinctrl - - reg: - maxItems: 1 - - clocks: - maxItems: 1 - - gpio-controller: true - - '#gpio-cells': - const: 2 - - gpio-ranges: - maxItems: 1 - - interrupts: - description: One interrupt for each of the (up to 7) interrupt - groups supported by the controller sorted by interrupt group - number in ascending order. - minItems: 1 - maxItems: 7 - - interrupt-controller: true - -patternProperties: - '-pins$': - type: object - $ref: pinmux-node.yaml# - - properties: - pinmux: - description: - Values are constructed from pin number and alternate function - configuration number using the APPLE_PINMUX() helper macro - defined in include/dt-bindings/pinctrl/apple.h. - - required: - - pinmux - - additionalProperties: false - -required: - - compatible - - reg - - gpio-controller - - '#gpio-cells' - - gpio-ranges - -additionalProperties: false - -examples: - - | - #include <dt-bindings/interrupt-controller/apple-aic.h> - #include <dt-bindings/pinctrl/apple.h> - - soc { - #address-cells = <2>; - #size-cells = <2>; - - pinctrl: pinctrl@23c100000 { - compatible = "apple,t8103-pinctrl", "apple,pinctrl"; - reg = <0x2 0x3c100000 0x0 0x100000>; - clocks = <&gpio_clk>; - - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pinctrl 0 0 212>; - - interrupt-controller; - interrupt-parent = <&aic>; - interrupts = <AIC_IRQ 16 IRQ_TYPE_LEVEL_HIGH>, - <AIC_IRQ 17 IRQ_TYPE_LEVEL_HIGH>, - <AIC_IRQ 18 IRQ_TYPE_LEVEL_HIGH>, - <AIC_IRQ 19 IRQ_TYPE_LEVEL_HIGH>, - <AIC_IRQ 20 IRQ_TYPE_LEVEL_HIGH>, - <AIC_IRQ 21 IRQ_TYPE_LEVEL_HIGH>, - <AIC_IRQ 22 IRQ_TYPE_LEVEL_HIGH>; - - pcie_pins: pcie-pins { - pinmux = <APPLE_PINMUX(150, 1)>, - <APPLE_PINMUX(151, 1)>, - <APPLE_PINMUX(32, 1)>; - }; - }; - }; diff --git a/doc/device-tree-bindings/sysinfo/tq,eeprom-sysinfo.txt b/doc/device-tree-bindings/sysinfo/tq,eeprom-sysinfo.txt new file mode 100644 index 00000000000..678fff0e812 --- /dev/null +++ b/doc/device-tree-bindings/sysinfo/tq,eeprom-sysinfo.txt @@ -0,0 +1,36 @@ +TQ EEPROM Sysinfo Driver +------------------------ + +This binding describes a sysinfo provider which retrieves system +identification information from an I2C EEPROM device. + +Required properties: + +- compatible: "tq,eeprom-sysinfo" +- nvmem-cells: phandle referencing the nvmem cell +- nvmem-cell-names: string, should be "device_info" + +Example: + +&i2c1 { + eeprom@50 { + compatible = "atmel,24c64"; + reg = <0x50>; + + nvmem-layout { + compatible = "fixed-layout"; + #address-cells = <1>; + #size-cells = <1>; + + module_info: module-info@20 { + reg = <0x20 0x60>; + }; + }; + }; +}; + +sysinfo { + compatible = "tq,eeprom-sysinfo"; + nvmem-cells = <&module_info>; + nvmem-cell-names = "device_info"; +}; diff --git a/doc/git-mailrc b/doc/git-mailrc index 65626d89eac..f0ba30a5c74 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -5,7 +5,7 @@ # Then when sending patches, you can use: # git send-email --to u-boot --cc i2c ... -alias uboot [email protected] +alias uboot [email protected] alias u-boot uboot # Maintainer aliases. Use the same alias here as patchwork to keep diff --git a/doc/index.rst b/doc/index.rst index 5d732ff7a54..6fe8ca0788b 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -9,7 +9,7 @@ This is the top level of the U-Boot's documentation tree. U-Boot documentation, like the U-Boot itself, is very much a work in progress; that is especially true as we work to integrate our many scattered documents into a coherent whole. Please note that improvements to the -documentation are welcome; join the U-Boot list at http://lists.denx.de +documentation are welcome; join the U-Boot list at http://lists.u-boot-project.org if you want to help out. .. toctree:: diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1 index d6653ec4247..ed296730eeb 100644 --- a/doc/mkeficapsule.1 +++ b/doc/mkeficapsule.1 @@ -153,4 +153,4 @@ The directory in which all capsule files be placed Written by AKASHI Takahiro <[email protected]> .SH HOMEPAGE -http://www.u-boot.org/ +http://www.u-boot-project.org/ diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index c616c75fefc..20a99005d71 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -23,4 +23,4 @@ sphinxcontrib-jquery==4.1 sphinxcontrib-jsmath==1.0.1 sphinxcontrib-qthelp==2.0.0 sphinxcontrib-serializinghtml==2.0.0 -urllib3==2.6.3 +urllib3==2.7.0 diff --git a/doc/usage/cmd/bdinfo.rst b/doc/usage/cmd/bdinfo.rst index 46046e55e06..6226d14bd66 100644 --- a/doc/usage/cmd/bdinfo.rst +++ b/doc/usage/cmd/bdinfo.rst @@ -124,12 +124,12 @@ Build current eth name of the active network device - Only shown if CONFIG_NET=y or CONFIG_NET_LWIP=y. + Only shown if CONFIG_NET=y. IP addr network address, value of the environment variable *ipaddr* - Only shown if CONFIG_NET=y or CONFIG_NET_LWIP=y. + Only shown if CONFIG_NET=y. fdt_blob address of U-Boot's own device tree, NULL if none @@ -173,5 +173,4 @@ The bdinfo command is available if CONFIG_CMD_BDI=y. The options to bdinfo are only available if CONFIG_GETOPT=y. -The ``-e`` option is additionally only available if CONFIG_NET=y or -CONFIG_NET_LWIP=y. +The ``-e`` option is additionally only available if CONFIG_NET=y. diff --git a/doc/usage/cmd/config.rst b/doc/usage/cmd/config.rst new file mode 100644 index 00000000000..bd8aa65ddbc --- /dev/null +++ b/doc/usage/cmd/config.rst @@ -0,0 +1,40 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. index:: + single: config (command) + +config command +============== + +Synopsis +-------- + +:: + + config [<str>] + +Description +----------- + +The config command prints the `.config` file used when building U-Boot +to the console. Note that the `.config` file is usually several 1000 +lines long. + +If the optional argument is given, only lines containing that string +(case insensitively) are printed. That can be useful if one wants to +check whether a specific option is enabled, or just to limit the +output to the subsystem of interest. + +The `.config` file is stored inside the U-Boot binary in +gzip-compressed format. + +Examples +-------- + +.. code-block:: bash + + # Print the entire .config + config + + # Print all lines related to pinctrl + config pinctrl diff --git a/doc/usage/cmd/dm.rst b/doc/usage/cmd/dm.rst index 196b22d1376..ac1c437bd9c 100644 --- a/doc/usage/cmd/dm.rst +++ b/doc/usage/cmd/dm.rst @@ -409,7 +409,8 @@ This example shows the abridged sandbox output:: regulator 1 [ ] sandbox_buck | | |-- buck2 regulator 2 [ ] sandbox_ldo | | |-- ldo1 regulator 3 [ ] sandbox_ldo | | |-- ldo2 - regulator 4 [ ] sandbox_buck | | `-- no_match_by_nodename + regulator 4 [ ] sandbox_buck | | |-- no_match_by_nodename + regulator 5 [ ] sandbox_ldo | | `-- ldo3 pmic 1 [ ] mc34708_pmic | `-- pmic@41 bootcount 0 [ + ] bootcount-rtc |-- bootcount@0 bootcount 1 [ ] bootcount-i2c-eeprom |-- bootcount diff --git a/doc/usage/cmd/part.rst b/doc/usage/cmd/part.rst index b91f6541f7f..a0e7be08a9a 100644 --- a/doc/usage/cmd/part.rst +++ b/doc/usage/cmd/part.rst @@ -52,7 +52,7 @@ The 'part list' command prints or sets an environment variable to the list of pa an optional environment variable to store the list of partitions value into. The 'part start' command sets an environment variable to the start of the partition (in blocks), -part can be either partition number or partition name. +part can be either partition number, partition UUID or partition name. interface interface for accessing the block device (mmc, sata, scsi, usb, ....) @@ -64,7 +64,7 @@ part can be either partition number or partition name. a variable to store the current start of the partition value into. The 'part size' command sets an environment variable to the size of the partition (in blocks), -part can be either partition number or partition name. +part can be either partition number, partition UUID or partition name. interface interface for accessing the block device (mmc, sata, scsi, usb, ....) @@ -76,7 +76,7 @@ part can be either partition number or partition name. a variable to store the current size of the partition value into. The 'part number' command sets an environment variable to the partition number using the partition name, -part must be specified as partition name. +part must be specified as partition UUID or partition name. interface interface for accessing the block device (mmc, sata, scsi, usb, ....) diff --git a/doc/usage/cmd/reset.rst b/doc/usage/cmd/reset.rst index 126db21cdb8..78c9c8873bc 100644 --- a/doc/usage/cmd/reset.rst +++ b/doc/usage/cmd/reset.rst @@ -20,7 +20,7 @@ Perform reset of the CPU. By default does COLD reset, which resets CPU, DDR and peripherals, on some boards also resets external PMIC. -w - Do warm WARM, reset CPU but keep peripheral/DDR/PMIC active. + Do WARM reset: reset CPU but keep peripheral/DDR/PMIC active. Return value diff --git a/doc/usage/cmd/sntp.rst b/doc/usage/cmd/sntp.rst index 2046828130d..433884f18b2 100644 --- a/doc/usage/cmd/sntp.rst +++ b/doc/usage/cmd/sntp.rst @@ -24,7 +24,7 @@ the server's IP address to be given on the command line or via the `ntpserverip` environment variable. The address of the NTP server does not need to be given if the DHCP server -provides one. The legacy network stack (`CONFIG_NET=y`) can only use the +provides one. The legacy network stack (`CONFIG_NET_LEGACY=y`) can only use the first NTP server provided in the `ntp-servers` DHCP option. When the network stack is lwIP (`CONFIG_NET_LWIP=y`) and DNS resolution diff --git a/doc/usage/cmd/wdt.rst b/doc/usage/cmd/wdt.rst index 711b74d20da..28abf98def9 100644 --- a/doc/usage/cmd/wdt.rst +++ b/doc/usage/cmd/wdt.rst @@ -16,7 +16,7 @@ Synopsis wdt start <timeout_ms> [flags] wdt stop wdt reset - wdt expirer [flags] + wdt expire [flags] Description ----------- diff --git a/doc/usage/cmd/wget.rst b/doc/usage/cmd/wget.rst index e6c42f967b9..f661d739a19 100644 --- a/doc/usage/cmd/wget.rst +++ b/doc/usage/cmd/wget.rst @@ -26,7 +26,7 @@ In order to use HTTPS you will need to compile wget with lwIP support. Legacy syntax ~~~~~~~~~~~~~ -The legacy syntax is supported by the legacy network stack (CONFIG_NET=y) +The legacy syntax is supported by the legacy network stack (CONFIG_NET_LEGACY=y) as well as by the lwIP base network stack (CONFIG_NET_LWIP=y). It supports HTTP only. diff --git a/doc/usage/fit/dm-verity.rst b/doc/usage/fit/dm-verity.rst new file mode 100644 index 00000000000..800a18fceae --- /dev/null +++ b/doc/usage/fit/dm-verity.rst @@ -0,0 +1,304 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +FIT dm-verity Boot Parameters +============================= + +Introduction +------------ + +Linux's dm-verity device-mapper target provides transparent integrity +checking of block devices using a Merkle tree. It is commonly used to +protect read-only root filesystems such as SquashFS images. + +When a FIT image packages the root filesystem as a loadable sub-image of +type ``filesystem`` (``IH_TYPE_FILESYSTEM``), the verity metadata can be +stored alongside the image data in a ``dm-verity`` subnode. U-Boot reads +this metadata at boot time and generates the kernel command-line parameters +that Linux needs to activate the verity target, eliminating the need for +an initramfs or userspace helper to set up dm-verity. + +This feature is enabled by ``CONFIG_FIT_VERITY`` (see ``boot/Kconfig``). + +Prerequisites +------------- + +* **Linux uImage.FIT block driver** – the kernel must include the FIT block + driver that exposes loadable sub-images as ``/dev/fit0``, ``/dev/fit1``, + etc. The driver assigns device numbers in the order loadables appear in + the FIT configuration. + +* **dm-verity support in the kernel** – ``CONFIG_DM_VERITY`` must be + enabled so the kernel can process the ``dm-mod.create=`` parameter. + +* **CONFIG_FIT_VERITY** enabled in U-Boot. + +How it works +------------ + +The implementation is split into a **build** phase and an **apply** phase, +both of which run automatically within the ``bootm`` state machine. No boot +method needs to call verity functions explicitly. + +**Build phase** (``BOOTM_STATE_FINDOTHER`` → ``boot_get_loadable()``) + +1. After all loadable sub-images have been loaded, + ``fit_verity_build_cmdline()`` iterates the configuration's + ``loadables`` list. + +2. For each loadable that is an ``IH_TYPE_FILESYSTEM`` image **and** + contains a ``dm-verity`` child node, a dm-verity target specification is + built by the helper ``fit_verity_build_target()``. + +3. The dm-verity target references ``/dev/fitN``, where *N* is the + zero-based index of the loadable in the configuration. This matches the + numbering used by the Linux FIT block driver. + +4. The resulting fragments are stored in ``struct bootm_headers``: + + ``images->dm_mod_create`` + The full dm-verity target table. Multiple targets are separated by ``;``. + + ``images->dm_mod_waitfor`` + Comma-separated list of ``/dev/fitN`` devices so the kernel waits for + the underlying FIT block devices to appear before activating + device-mapper. + +**Apply phase** (``BOOTM_STATE_OS_PREP``) + +5. Just before ``bootm_process_cmdline_env()`` processes the ``bootargs`` + environment variable, ``fit_verity_apply_bootargs()`` appends the + ``dm-mod.create=`` and ``dm-mod.waitfor=`` parameters. + +**Bootmeth integration** + + Because the fragments are stored in ``struct bootm_headers``, a boot + method can check ``fit_verity_active(images)`` between bootm state + invocations. A typical pattern splits ``bootm_run_states()`` into two + calls -- one for ``START|FINDOS|FINDOTHER|LOADOS`` and one for + ``OS_PREP|OS_GO`` -- and inspects ``fit_verity_active()`` in + between to decide whether to add a ``root=`` parameter pointing at the + dm-verity device. + +FIT image source (.its) example +------------------------------- + +Below is a minimal ``.its`` file showing a kernel and a dm-verity-protected +root filesystem packaged as a FIT. Only the three user-provided properties +(``algo``, ``data-block-size``, ``hash-block-size``) are included; ``mkimage`` +computes and fills in ``digest``, ``salt``, ``num-data-blocks``, and +``hash-start-block`` automatically (see `Generating verity metadata`_ below):: + + /dts-v1/; + + / { + description = "Kernel + dm-verity rootfs"; + #address-cells = <1>; + + images { + kernel { + description = "Linux kernel"; + data = /incbin/("./Image.gz"); + type = "kernel"; + arch = "arm64"; + os = "linux"; + compression = "gzip"; + load = <0x44000000>; + entry = <0x44000000>; + hash-1 { + algo = "sha256"; + }; + }; + + fdt { + description = "Device tree blob"; + data = /incbin/("./board.dtb"); + type = "flat_dt"; + arch = "arm64"; + compression = "none"; + hash-1 { + algo = "sha256"; + }; + }; + + rootfs { + description = "SquashFS root filesystem"; + data = /incbin/("./rootfs.squashfs"); + type = "filesystem"; + arch = "arm64"; + compression = "none"; + hash-1 { + algo = "sha256"; + }; + + dm-verity { + algo = "sha256"; + data-block-size = <4096>; + hash-block-size = <4096>; + }; + }; + }; + + configurations { + default = "config-1"; + config-1 { + description = "Boot with dm-verity rootfs"; + kernel = "kernel"; + fdt = "fdt"; + loadables = "rootfs"; + }; + }; + }; + +With this configuration U-Boot produces a kernel command line similar to:: + + dm-mod.create="rootfs,,, ro,0 <data_sectors> verity 1 \ + /dev/fit0 /dev/fit0 4096 4096 3762 3762 sha256 \ + 8e6791637f93cbb81fc45299e203cbe85ca2e47a38f5051bddeece92d7b1c9f9 \ + aa7b11f8db8fe2e5bfd4eca1d18a22b5de7ea39d2e1b93bb7272ce0c6ca3cc8e" \ + dm-mod.waitfor=/dev/fit0 + +dm-verity subnode properties +---------------------------- + +User-provided properties (required in the ``.its``): + +.. list-table:: + :header-rows: 1 + :widths: 20 15 65 + + * - Property + - Type + - Description + * - ``algo`` + - string + - Hash algorithm name, e.g. ``"sha256"``. + * - ``data-block-size`` + - u32 + - Data block size in bytes (>= 512, typically 4096). + * - ``hash-block-size`` + - u32 + - Hash block size in bytes (>= 512, typically 4096). + +Computed properties (filled in by ``mkimage``): + +.. list-table:: + :header-rows: 1 + :widths: 20 15 65 + + * - Property + - Type + - Description + * - ``num-data-blocks`` + - u32 + - Number of data blocks in the filesystem image (computed from the + image size and ``data-block-size``). + * - ``hash-start-block`` + - u32 + - Offset in ``hash-block-size``-sized blocks from the start of the + sub-image to the root block of the hash tree. + * - ``digest`` + - byte array + - Root hash of the Merkle tree, stored as raw bytes. Length must match + the output size of ``algo``. + * - ``salt`` + - byte array + - Salt used when computing the Merkle tree, stored as raw bytes. + +These values are the same ones produced by ``veritysetup format`` and can +typically be obtained from its output. +The ``digest`` and ``salt`` byte arrays correspond to the hex-encoded +``Root hash`` and ``Salt`` printed by ``veritysetup format``. + +Optional boolean properties (when present, they are collected and appended +as dm-verity optional parameters with hyphens converted to underscores): + +.. list-table:: + :header-rows: 1 + :widths: 30 70 + + * - Property + - Description + * - ``restart-on-corruption`` + - Restart the system on data corruption. + * - ``panic-on-corruption`` + - Panic the system on data corruption. + * - ``restart-on-error`` + - Restart the system on I/O error. + * - ``panic-on-error`` + - Panic the system on I/O error. + * - ``check-at-most-once`` + - Verify data blocks only on first read. + + +Generating verity metadata +-------------------------- + +``mkimage`` automates the entire process. When it encounters a +``dm-verity`` subnode, it: + +1. Writes the embedded image data to a temporary file. +2. Runs ``veritysetup format`` with the user-supplied algorithm and + block sizes. +3. Parses ``Root hash`` and ``Salt`` from ``veritysetup`` stdout. +4. Reads the expanded content (original data + Merkle hash tree) back + into an in-memory buffer and removes the temporary file. The + external-data section written to the .itb file uses this buffer in + place of the original ``data`` property. +5. Writes the computed ``digest``, ``salt``, ``num-data-blocks``, and + ``hash-start-block`` properties into the ``dm-verity`` subnode. + +Images with ``dm-verity`` subnodes **must** use external data layout +(``mkimage -E``). ``mkimage`` will abort with an error if ``-E`` is +not specified. + +Usage:: + + # Create the filesystem image + mksquashfs rootfs/ rootfs.squashfs -comp xz + + # Build the FIT (dm-verity is computed automatically); align each + # external-data section to the block size of the underlying storage + # (see the alignment note below). + mkimage -E -B 0x1000 -f image.its image.itb + +``veritysetup`` (from the cryptsetup_ package) must be installed on +the build host. + +.. _cryptsetup: https://gitlab.com/cryptsetup/cryptsetup + +.. note:: + + ``veritysetup format`` is invoked with ``--no-superblock``, so no + on-disk superblock is written between the data and hash regions. + The Merkle hash tree is appended directly to the image data within + the FIT external data section. ``hash-start-block`` is therefore + computed as ``data_size / hash-block-size`` (the offset of the hash + region in units of ``hash-block-size``). When ``data-block-size`` + equals ``hash-block-size`` this happens to equal ``num-data-blocks``. + +.. note:: + + The Linux ``fitblk`` driver currently requires each ``filesystem`` + sub-image to start and end on block boundaries of the underlying + block device (typically 512 bytes, sometimes 4 KiB for eMMC or NVMe + with 4 KiB native sectors). Use ``mkimage -B <align>`` to pad + external-data sections to that boundary; ``-B 0x1000`` is a safe + default for the storage in common use. + + This alignment requirement comes from the kernel-side ``fitblk`` + driver to avoid unaligned-access fix-up overhead in block I/O, and + is **independent** of the dm-verity ``data-block-size`` and + ``hash-block-size`` properties -- those describe the block sizes + used by the device-mapper verity target itself, not storage + alignment. + +Kconfig +------- + +``CONFIG_FIT_VERITY`` + Depends on ``CONFIG_FIT`` and ``CONFIG_OF_LIBFDT``. + When enabled, ``fit_verity_build_cmdline()`` and + ``fit_verity_apply_bootargs()`` are compiled into the boot path. + When disabled, the functions are static inlines returning 0, so there + is no code-size impact. Works with both the ``bootm`` command and + BOOTSTD boot methods. diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst index 6c78d8584ed..d17582b1d64 100644 --- a/doc/usage/fit/index.rst +++ b/doc/usage/fit/index.rst @@ -11,6 +11,7 @@ images that it reads and boots. Documentation about FIT is available in :maxdepth: 1 beaglebone_vboot + dm-verity howto kernel_fdt kernel_fdts_compressed diff --git a/doc/usage/spl_boot.rst b/doc/usage/spl_boot.rst index 93419f158af..64b8083e007 100644 --- a/doc/usage/spl_boot.rst +++ b/doc/usage/spl_boot.rst @@ -253,7 +253,7 @@ Ethernet a TFTP server and binary name. The binary is downloaded via the TFTP protocol. Required configuration settings include: - * CONFIG_SPL_NET=y or CONFIG_TPL_NET=y + * CONFIG_SPL_NET=y * CONFIG_SPL_ETH_DEVICE=y or CONFIG_DM_USB_GADGET=y |