diff options
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/board_best_practices.rst | 2 | ||||
| -rw-r--r-- | doc/develop/bootstd/android.rst | 39 | ||||
| -rw-r--r-- | doc/develop/bootstd/cros.rst | 33 | ||||
| -rw-r--r-- | doc/develop/bootstd/extlinux.rst | 29 | ||||
| -rw-r--r-- | doc/develop/bootstd/index.rst | 16 | ||||
| -rw-r--r-- | doc/develop/bootstd/overview.rst (renamed from doc/develop/bootstd.rst) | 99 | ||||
| -rw-r--r-- | doc/develop/bootstd/pxelinux.rst | 27 | ||||
| -rw-r--r-- | doc/develop/bootstd/qfw.rst | 20 | ||||
| -rw-r--r-- | doc/develop/bootstd/sandbox.rst | 17 | ||||
| -rw-r--r-- | doc/develop/bootstd/script.rst | 52 | ||||
| -rw-r--r-- | doc/develop/codingstyle.rst | 8 | ||||
| -rw-r--r-- | doc/develop/cyclic.rst | 26 | ||||
| -rw-r--r-- | doc/develop/devicetree/control.rst | 8 | ||||
| -rw-r--r-- | doc/develop/gdb.rst | 171 | ||||
| -rw-r--r-- | doc/develop/index.rst | 3 | ||||
| -rw-r--r-- | doc/develop/qconfig.rst | 14 | ||||
| -rw-r--r-- | doc/develop/release_cycle.rst | 26 | ||||
| -rw-r--r-- | doc/develop/spl.rst | 2 | ||||
| -rw-r--r-- | doc/develop/statistics/u-boot-stats-v2024.07.rst | 890 | ||||
| -rw-r--r-- | doc/develop/tests_writing.rst | 1 | ||||
| -rw-r--r-- | doc/develop/uefi/fwu_updates.rst | 20 | ||||
| -rw-r--r-- | doc/develop/uefi/uefi.rst | 20 |
22 files changed, 1443 insertions, 80 deletions
diff --git a/doc/develop/board_best_practices.rst b/doc/develop/board_best_practices.rst index f44401eab7d..09632c80ce7 100644 --- a/doc/develop/board_best_practices.rst +++ b/doc/develop/board_best_practices.rst @@ -7,7 +7,7 @@ In addition to the regular best practices such as using :doc:`checkpatch` and following the :doc:`docstyle` and the :doc:`codingstyle` there are some things which are specific to creating a new board port. -* Implement :doc:`bootstd` to ensure that most operating systems will be +* Implement :doc:`bootstd/index` to ensure that most operating systems will be supported by the platform. * The platform defconfig file must be generated via `make savedefconfig`. diff --git a/doc/develop/bootstd/android.rst b/doc/develop/bootstd/android.rst new file mode 100644 index 00000000000..41701d5bdff --- /dev/null +++ b/doc/develop/bootstd/android.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +Android Bootmeth +================ + +Android provides a mechanism for booting its Operating System from eMMC storage, +described on `source.android.com <https://source.android.com/docs/core/architecture/bootloader>`_. + +Android has strong requirements about partitioning layout which are described +`here <https://source.android.com/docs/core/architecture/partitions>`_. +Because multiple partitions are required, this bootmeth only operates on whole mmc +devices which have a valid partition table. + +When invoked on a bootdev, this bootmeth searches for the ``misc`` partition in order +to read the *boot mode*, which can be one of following: + +Normal + Boot the regular Android Operating System. + +Recovery + Boot a slimmed down Recovery Operating System. Can be used + to factory reset the device or to apply system updates. + +Bootloader + Stay in U-Boot and wait for fastboot commands from the host. + +After the *boot mode* has been determined, this bootmeth will read the *slot suffix* +from the ``misc`` partition. For details about slots, see +`the AOSP documentation <https://source.android.com/docs/core/ota/ab#slots>`_. + +When both the *boot mode* and the *slot suffix* are known, the bootflow is created. + +When the bootflow is booted, the bootmeth reads the kernel, the boot arguments and +the vendor ramdisk. +It then boots the kernel using bootm. The relevant devicetree blob is extracted +from the ``boot`` partition based on the ``adtb_idx`` environment variable. + +The compatible string "u-boot,android" is used for the driver. It is present +if `CONFIG_BOOTMETH_ANDROID` is enabled. diff --git a/doc/develop/bootstd/cros.rst b/doc/develop/bootstd/cros.rst new file mode 100644 index 00000000000..85af10588c1 --- /dev/null +++ b/doc/develop/bootstd/cros.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +ChromiumOS Bootmeth +=================== + +ChromiumOS provides a mechanism for booting its Operating System from a block +device, described +`here <https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot/>`_. + +U-Boot includes support for reading the associated data structures from the +device and identifying a bootable ChromiumOS image. This structure includes the +kernel itself, boot arguments (kernel command line), as well as the x86 setup +block (for x86 only). + +When invoked on a bootdev, this bootmeth searches for kernel partitions with +the appropriate GUID (Globally Unique Identifier). When found, the information +is loaded and a bootflow is created. + +When the bootflow is booted, the bootmeth reads the kernel and boot arguments. +It then boots the kernel using zboot (on x86) or bootm (on ARM). The boot +arguments are adjusted to replace `%U` with the UUID of the selected kernel +partition. This results in the correct root disk being used, which is the next +partition after the kernel partition. + +For ARM, a :doc:`/usage/fit/index` is used. The `CONFIG_FIT_BEST_MATCH` option +must be enabled for U-Boot to select the correct devicetree to boot with. + +Note that a ChromiumOS image typically has two copies of the Operating System, +each with its own kernel and root disk. There is no initial ramdisk (initrd). +This means that this bootmeth typically locates two separate images. + +The compatible string "u-boot,cros" is used for the driver. It is present +if `CONFIG_BOOTMETH_CROS` is enabled. diff --git a/doc/develop/bootstd/extlinux.rst b/doc/develop/bootstd/extlinux.rst new file mode 100644 index 00000000000..bf27dc57aaa --- /dev/null +++ b/doc/develop/bootstd/extlinux.rst @@ -0,0 +1,29 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +Extlinux Bootmeth +================= + +`Extlinux <https://uapi-group.org/specifications/specs/boot_loader_specification>`_ +(sometimes called syslinux) allows U-Boot to provide a menu of available +operating systems from which the user can choose. + +U-Boot includes a parser for the `extlinux.conf` file. It consists primarily of +a list of named operating systems along with the kernel, initial ramdisk and +other settings. The file is stored in the `extlinux/` subdirectory, possibly +under the `boot/` subdirectory. This list of prefixes (``{"/", "/boot"}`` by +default) can be selected with the `filename-prefixes` property in the bootstd +device. + +Note that the :doc:`pxelinux` uses the same file format, but in a +network context. + +When invoked on a bootdev, this bootmeth searches for the file and creates a +bootflow if found. + +When the bootflow is booted, the bootmeth calls ``pxe_setup_ctx()`` to set up +the context, then ``pxe_process()`` to process the file. Depending on the +contents, this may boot an operating system or provide a list of options to +the user, perhaps with a timeout. + +The compatible string "u-boot,extlinux" is used for the driver. It is present +if `CONFIG_BOOTMETH_EXTLINUX` is enabled. diff --git a/doc/develop/bootstd/index.rst b/doc/develop/bootstd/index.rst new file mode 100644 index 00000000000..4c4e26ccdb7 --- /dev/null +++ b/doc/develop/bootstd/index.rst @@ -0,0 +1,16 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +Standard Boot +============= + +.. toctree:: + :maxdepth: 2 + + overview + extlinux + pxelinux + qfw + android + cros + script + sandbox diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd/overview.rst index a07a72581e7..c6f003851b2 100644 --- a/doc/develop/bootstd.rst +++ b/doc/develop/bootstd/overview.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+: -U-Boot Standard Boot -==================== +Standard Boot Overview +====================== Introduction ------------ @@ -17,7 +17,7 @@ introduces the following concepts: For Linux, the distro (Linux distribution, e.g. Debian, Fedora) is responsible for creating a bootflow for each kernel combination that it wants to offer. These bootflows are stored on media so they can be discovered by U-Boot. This -feature is typically called `distro boot` (see :doc:`distro`) because it is +feature is typically called `distro boot` (see :doc:`../distro`) because it is a way for distributions to boot on any hardware. Traditionally U-Boot has relied on scripts to implement this feature. See @@ -32,14 +32,14 @@ way to boot with U-Boot. The feature is extensible to different Operating Systems (such as Chromium OS) and devices (beyond just block and network devices). It supports EFI boot and EFI bootmgr too. -Finally, standard boot supports the operation of :doc:`vbe`. +Finally, standard boot supports the operation of :doc:`../vbe`. Bootflow -------- A bootflow is a file that describes how to boot a distro. Conceptually there can be different formats for that file but at present U-Boot only supports the -BootLoaderSpec_ format. which looks something like this:: +BootLoaderSpec_ format which looks something like this:: menu autoboot Welcome to Fedora-Workstation-armhfp-31-1.9. Automatic boot in # second{,s}. Press a key for options. menu title Fedora-Workstation-armhfp-31-1.9 Boot Options. @@ -52,7 +52,7 @@ BootLoaderSpec_ format. which looks something like this:: initrd /initramfs-5.3.7-301.fc31.armv7hl.img As you can see it specifies a kernel, a ramdisk (initrd) and a directory from -which to load devicetree files. The details are described in distro_bootcmd_. +which to load Device Tree files. The details are described in distro_bootcmd_. The bootflow is provided by the distro. It is not part of U-Boot. U-Boot's job is simply to interpret the file and carry out the instructions. This allows @@ -85,7 +85,7 @@ Bootmeth -------- Once the list of filesystems is provided, how does U-Boot find the bootflow -files in these filesystems. That is the job of bootmeth. Each boot method has +files in these filesystems? That is the job of bootmeth. Each boot method has its own way of doing this. For example, the distro bootmeth simply looks through the provided filesystem @@ -95,6 +95,7 @@ bootflows. Note: it is possible to have a bootmeth that uses a partition or a whole device directly, but it is more common to use a filesystem. +For example, the Android bootmeth uses a whole device. Note that some bootmeths are 'global', meaning that they select the bootdev themselves. Examples include VBE and EFI boot manager. In this case, they @@ -106,7 +107,7 @@ they scan a lot of devices. Boot process ------------ -U-Boot tries to use the 'lazy init' approach whereever possible and distro boot +U-Boot tries to use the 'lazy init' approach wherever possible and distro boot is no exception. The algorithm is:: while (get next bootdev) @@ -174,13 +175,13 @@ the same way as setting this variable. Bootdev uclass -------------- -The bootdev uclass provides an simple API call to obtain a bootflows from a +The bootdev uclass provides a simple API call to obtain a bootflow from a device:: int bootdev_get_bootflow(struct udevice *dev, struct bootflow_iter *iter, struct bootflow *bflow); -This takes a iterator which indicates the bootdev, partition and bootmeth to +This takes an iterator which indicates the bootdev, partition and bootmeth to use. It returns a bootflow. This is the core of the bootdev implementation. The bootdev drivers that implement this differ depending on the media they are reading from, but each is responsible for returning a valid bootflow if @@ -188,7 +189,7 @@ available. A helper called `bootdev_find_in_blk()` makes it fairly easy to implement this function for each media device uclass, in a few lines of code. For many types -ot bootdevs, the `get_bootflow` member can be NULL, indicating that the default +of bootdevs, the `get_bootflow` member can be NULL, indicating that the default handler is used. This is called `default_get_bootflow()` and it only works with block devices. @@ -196,7 +197,7 @@ block devices. Bootdev drivers --------------- -A bootdev driver is typically fairly simple. Here is one for mmc:: +A bootdev driver is typically fairly simple. Here is one for MMC:: static int mmc_bootdev_bind(struct udevice *dev) { @@ -277,6 +278,9 @@ script_offset_f script_size_f Size of the script to load, e.g. 0x2000 +vendor_boot_comp_addr_r + Address to which to load the vendor_boot Android image, e.g. 0xe0000000 + Some variables are set by script bootmeth: devtype @@ -328,7 +332,7 @@ or:: Here, `eth_bootdev` is the name of the Ethernet bootdev driver and `dev` -is the ethernet device. This function is safe to call even if standard boot is +is the Ethernet device. This function is safe to call even if standard boot is not enabled, since it does nothing in that case. It can be added to all uclasses which implement suitable media. @@ -340,7 +344,7 @@ Standard boot requires a single instance of the bootstd device to make things work. This includes global information about the state of standard boot. See `struct bootstd_priv` for this structure, accessed with `bootstd_get_priv()`. -Within the devicetree, if you add bootmeth devices, they should be children of +Within the Device Tree, if you add bootmeth devices, they should be children of the bootstd device. See `arch/sandbox/dts/test.dts` for an example of this. @@ -349,12 +353,12 @@ the bootstd device. See `arch/sandbox/dts/test.dts` for an example of this. Automatic devices ----------------- -It is possible to define all the required devices in the devicetree manually, +It is possible to define all the required devices in the Device Tree manually, but it is not necessary. The bootstd uclass includes a `dm_scan_other()` function which creates the bootstd device if not found. If no bootmeth devices are found at all, it creates one for each available bootmeth driver. -If your devicetree has any bootmeth device it must have all of them that you +If your Device Tree has any bootmeth device it must have all of them that you want to use, since no bootmeth devices will be created automatically in that case. @@ -363,8 +367,8 @@ Using devicetree ---------------- If a bootdev is complicated or needs configuration information, it can be -added to the devicetree as a child of the media device. For example, imagine a -bootdev which reads a bootflow from SPI flash. The devicetree fragment might +added to the Device Tree as a child of the media device. For example, imagine a +bootdev which reads a bootflow from SPI flash. The Device Tree fragment might look like this:: spi@0 { @@ -398,7 +402,7 @@ Standard boot is enabled with `CONFIG_BOOTSTD`. Each bootmeth has its own CONFIG option also. For example, `CONFIG_BOOTMETH_EXTLINUX` enables support for booting from a disk using an `extlinux.conf` file. -To enable all feature sof standard boot, use `CONFIG_BOOTSTD_FULL`. This +To enable all features of standard boot, use `CONFIG_BOOTSTD_FULL`. This includes the full set of commands, more error messages when things go wrong and bootmeth ordering with the bootmeths environment variable. @@ -406,19 +410,39 @@ You should probably also enable `CONFIG_BOOTSTD_DEFAULTS`, which provides several filesystem and network features (if `CONFIG_NET` is enabled) so that a good selection of boot options is available. +Some devicetree properties are supported in the bootstd node when +`CONFIG_BOOTSTD_FULL` is enabled: + + filename-prefixes + List of prefixes to use when searching for files on block devices. This + defaults to {"/", "/boot/"} if not provided. + + bootdev-order + Lists the bootdev ordering to use. Note that the deprecated + `boot_targets` environment variable overrides this, if present. + + theme (subnode) + Sets the theme to use for menus. See :doc:`/develop/expo`. Available bootmeth drivers -------------------------- -Bootmeth drivers are provided for: +Bootmeth drivers are provided for booting from various media: - - extlinux / syslinux boot from a disk - - extlinux boot from a network (PXE) - - U-Boot scripts from disk, network or SPI flash + - :doc:`Android <android>` bootflow (boot image v4) + - :doc:`ChromiumOS <cros>` ChromiumOS boot from a disk - EFI boot using bootefi from disk - - VBE - EFI boot using boot manager + - :doc:`extlinux / syslinux <extlinux>` boot from a storage device + - :doc:`extlinux / syslinux <extlinux>` boot from a network (PXE) + - :doc:`sandbox <sandbox>` used only for testing + - :doc:`U-Boot scripts <script>` from disk, network or SPI flash + - :doc:`QFW <qfw>`: QEMU firmware interface + - :doc:`VBE </develop/vbe>`: Verified Boot for Embedded +Each driver is controlled by a Kconfig option. If no bootmeth driver is +selected by a compatible string in the devicetree, all available bootmeth +drivers are bound automatically. Command interface ----------------- @@ -427,16 +451,16 @@ Three commands are available: `bootdev` Allows listing of available bootdevs, selecting a particular one and - getting information about it. See :doc:`../usage/cmd/bootdev` + getting information about it. See :doc:`/usage/cmd/bootdev` `bootflow` Allows scanning one or more bootdevs for bootflows, listing available bootflows, selecting one, obtaining information about it and booting it. - See :doc:`../usage/cmd/bootflow` + See :doc:`/usage/cmd/bootflow` `bootmeth` Allow listing of available bootmethds and setting the order in which they - are tried. See :doc:`../usage/cmd/bootmeth` + are tried. See :doc:`/usage/cmd/bootmeth` .. _BootflowStates: @@ -492,9 +516,9 @@ Theory of operation This describes how standard boot progresses through to booting an operating system. -To start. all the necessary devices must be bound, including bootstd, which +To start, all the necessary devices must be bound, including bootstd, which provides the top-level `struct bootstd_priv` containing optional configuration -information. The bootstd device is also holds the various lists used while +information. The bootstd device also holds the various lists used while scanning. This step is normally handled automatically by driver model, as described in `Automatic Devices`_. @@ -504,7 +528,7 @@ those bootdevs. So, all up, we need a single bootstd device, one or more bootdev devices and one or more bootmeth devices. Once these are ready, typically a `bootflow scan` command is issued. This kicks -of the iteration process, which involves hunting for bootdevs and looking +off the iteration process, which involves hunting for bootdevs and looking through the bootdevs and their partitions one by one to find bootflows. Iteration is kicked off using `bootflow_scan_first()`. @@ -526,7 +550,7 @@ Then the iterator is set up to according to the parameters given: - If `label` indicates a numeric bootdev number (e.g. "2") then `BOOTFLOW_METHF_SINGLE_DEV` is set. In this case, moving to the next bootdev - simple stops, since there is only one. No hunters are used. + simply stops, since there is only one. No hunters are used. - If `label` indicates a particular media device (e.g. "mmc1") then `BOOTFLOWIF_SINGLE_MEDIA` is set. In this case, moving to the next bootdev processes just the children of the media device. Hunters are used, in this @@ -554,7 +578,7 @@ bootdev and disturb the original ordering. Next, the ordering of bootmeths is determined, by `bootmeth_setup_iter_order()`. By default the ordering is again by sequence number, i.e. the `/aliases` node, -or failing that the order in the devicetree. But the `bootmeth order` command +or failing that the order in the Device Tree. But the `bootmeth order` command or `bootmeths` environment variable can be used to set up an ordering. If that has been done, the ordering is in `struct bootstd_priv`, so that ordering is simply copied into the iterator. Either way, the `method_order` array it set up, @@ -652,12 +676,12 @@ valid bootflow is found early on. With `bootflow scan -b`, that causes the bootflow to be immediately booted. Assuming it is successful, the iteration never completes. -Also note that the iterator hold the **current** combination being considered. +Also note that the iterator holds the **current** combination being considered. So when `iter_incr()` is called, it increments to the next one and returns it, the new **current** combination. Note also the `err` field in `struct bootflow_iter`. This is normally 0 and has -thus has no effect on `iter_inc()`. But if it is non-zero, signalling an error, +thus no effect on `iter_inc()`. But if it is non-zero, signalling an error, it indicates to the iterator what it should do when called. It can force moving to the next partition, or bootdev, for example. The special values `BF_NO_MORE_PARTS` and `BF_NO_MORE_DEVICES` handle this. When `iter_incr` sees @@ -675,7 +699,7 @@ So what happens inside of `bootflow_check()`? It simply calls the uclass method `bootdev_get_bootflow()` to ask the bootdev to return a bootflow. It passes the iterator to the bootdev method, so that function knows what we are talking about. At first, the bootflow is set up in the state `BOOTFLOWST_BASE`, -with just the `method` and `dev` intiialised. But the bootdev may fill in more, +with just the `method` and `dev` initialised. But the bootdev may fill in more, e.g. updating the state, depending on what it finds. For global bootmeths the `bootmeth_get_bootflow()` function is called instead of `bootdev_get_bootflow()`. @@ -733,12 +757,12 @@ bootflow is handled by the bootmeth driver for that bootflow. In the case of extlinux boot, this parses and processes the `extlinux.conf` file that was read. See `extlinux_boot()` for how that works. The processing may involve reading additional files, which is handled by the `read_file()` method, which is -`extlinux_read_file()` in this case. All bootmethds should support reading +`extlinux_read_file()` in this case. All bootmeths should support reading files, since the bootflow is typically only the basic instructions and does not include the operating system itself, ramdisk, device tree, etc. The vast majority of the bootstd code is concerned with iterating through -partitions on bootdevs and using bootmethds to find bootflows. +partitions on bootdevs and using bootmeths to find bootflows. How about bootdevs which are not block devices? They are handled by the same methods as above, but with a different implementation. For example, the bootmeth @@ -786,6 +810,7 @@ To do Some things that need to be done to completely replace the distro-boot scripts: - implement extensions (devicetree overlays with add-on boards) +- implement legacy (boot image v2) android boot flow Other ideas: diff --git a/doc/develop/bootstd/pxelinux.rst b/doc/develop/bootstd/pxelinux.rst new file mode 100644 index 00000000000..c4b7fbb4c9c --- /dev/null +++ b/doc/develop/bootstd/pxelinux.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +PXE Bootmeth +============ + +PXE (Preboot eXecution-Environment) provides a way to boot an operating system +over a network interface. The PXE bootmeth supports PXELINUX and allows U-Boot to +provide a menu of possible Operating Systems from which the user can choose. + +U-Boot includes a parser for the `extlinux.conf` file described +`here <https://uapi-group.org/specifications/specs/boot_loader_specification>`_. +It consists primarily of a list of named operating systems along with the +kernel, initial ramdisk and other settings. The file is retrieved from a network +server using the TFTP protocol. + +When invoked on a bootdev, this bootmeth searches for the file and creates a +bootflow if found. See +`PXELINUX <https://wiki.syslinux.org/wiki/index.php?title=PXELINUX>`_ for +a full description of the search procedure. + +When the bootflow is booted, the bootmeth calls ``pxe_setup_ctx()`` to set up +the context, then ``pxe_process()`` to process the file. Depending on the +contents, this may boot an Operating System or provide a list of options to the +user, perhaps with a timeout. + +The compatible string "u-boot,extlinux-pxe" is used for the driver. It is +present if `CONFIG_BOOTMETH_EXTLINUX_PXE` is enabled. diff --git a/doc/develop/bootstd/qfw.rst b/doc/develop/bootstd/qfw.rst new file mode 100644 index 00000000000..70086ad1817 --- /dev/null +++ b/doc/develop/bootstd/qfw.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +QFW Bootmeth +============ + +`QEMU <hhttps://www.qemu.org/>`_ is a system emulator which is able to boot +Operating Systems. QEMU provides specific support for booting an OS image +provided on the QEMU command line. + +When invoked on a bootdev for UCLASS_QFW, this bootmeth reads the kernel +provided by the QEMU `-kernel` argument, the initial ramdisk provided by +`-initrd` and the boot arguments (command line) provided by `-append` into +memory ready for booting. + +When the bootflow is booted, the bootmeth tries the `booti` command first, then +falls back to the `bootz` command. U-Boot's 'control' devicetree is passed +through to the kernel. + +The compatible string "u-boot,qfw-bootmeth" is used for the driver. It is +present if `CONFIG_QFW` is enabled. diff --git a/doc/develop/bootstd/sandbox.rst b/doc/develop/bootstd/sandbox.rst new file mode 100644 index 00000000000..d501518c39a --- /dev/null +++ b/doc/develop/bootstd/sandbox.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +Sandbox Bootmeth +================ + +The sandbox bootmeth is only used for testing. It does not provide any facility +for booting an OS. While sandbox can do all the processing before the actual +boot, it is not connected in this bootmeth. + +When invoked on a bootdev, this bootmeth pretends to find a bootflow and creates +the associated structure. + +When the bootflow is booted, the bootmeth returns `-ENOTSUPP` indicating that it +is not supported. + +The compatible string "u-boot,sandbox-bootmeth" is used for the driver. It is present +if `CONFIG_BOOTMETH_SANDBOX` is enabled. diff --git a/doc/develop/bootstd/script.rst b/doc/develop/bootstd/script.rst new file mode 100644 index 00000000000..47f3684b86b --- /dev/null +++ b/doc/develop/bootstd/script.rst @@ -0,0 +1,52 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +Script Bootmeth +=============== + +This bootmeth provides a way to locate and run a script on a block or network +device. It can also support SPI flash. + +For a block device the file is read from the selected partition, which must use +a supported filesystem. The subdirectory to search in is defined by the bootstd +list of prefixes (``{"/", "/boot"}`` by default) and can be adjust with the +`filename-prefixes` property in the bootstd device. + +For a network device, the filename is obtained from the `boot_script_dhcp` +environment variable and the file is read using tftp. It must be in the +top-level directory of the tftp server. + +In either case (file or network), the bootmeth searches for the file and creates +a bootflow if found. The bootmeth searches for "boot.scr.uimg" first, then +"boot.scr" if not found. + +For SPI flash, a script is read from flash using the offset provided by the +"script_offset_f" environment variable. + +Some attempt is made to identify the Operating System: so far this only detects +an `Armbian <https://www.armbian.com>`_ +distro. For block devices, if a file called "boot.bmp" exists in the same +directory then it is used as the bootflow logo. + +When the bootflow is booted, the bootmeth sets these environment variables: + + devtype + device type (e.g. "usb", "mmc", "ethernet" or "spi_flash") + + devnum + device number, corresponding to the device 'sequence' number + ``dev_seq(dev)`` + + distro_bootpart + (block devices only) partition number on the device (numbered from 1) + + prefix + prefix used to find the file + + mmc_bootdev + device number (same as `devnum`), set for sunxi mmc devices only + +The script file must be a FIT or a legacy uImage. It is loaded into memory and +executed. + +The compatible string "u-boot,script" is used for the driver. It is present +if `CONFIG_BOOTMETH_SCRIPT` is enabled. diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst index f6248cdcb1e..fa3cd6aec82 100644 --- a/doc/develop/codingstyle.rst +++ b/doc/develop/codingstyle.rst @@ -110,9 +110,8 @@ Include files You should follow this ordering in U-Boot. In all cases, they should be listed in alphabetical order. First comes headers which are located directly in our -top-level include diretory. This excludes the common.h header file which is to -be removed. Second are headers within subdirectories, Finally directory-local -includes should be listed. See this example: +top-level include diretory. Second are headers within subdirectories, Finally +directory-local includes should be listed. See this example: .. code-block:: C @@ -129,9 +128,6 @@ For files that need to be compiled for the host (e.g. tools), you need to use ``#ifndef USE_HOSTCC`` to avoid including U-Boot specific include files. See common/image.c for an example. -If you encounter code which still uses <common.h> a patch to remove that and -replace it with any required include files directly is much appreciated. - If your file uses driver model, include <dm.h> in the C file. Do not include dm.h in a header file. Try to use forward declarations (e.g. ``struct udevice``) instead. diff --git a/doc/develop/cyclic.rst b/doc/develop/cyclic.rst index 67831496a70..893c269099a 100644 --- a/doc/develop/cyclic.rst +++ b/doc/develop/cyclic.rst @@ -19,20 +19,26 @@ Registering a cyclic function To register a cyclic function, use something like this:: - static void cyclic_demo(void *ctx) + struct donkey { + struct cyclic_info cyclic; + void (*say)(const char *s); + }; + + static void cyclic_demo(struct cyclic_info *c) { - /* Just a small dummy delay here */ - udelay(10); + struct donkey *donkey = container_of(c, struct donkey, cyclic); + + donkey->say("Are we there yet?"); } - - int board_init(void) + + int donkey_init(void) { - struct cyclic_info *cyclic; - + struct donkey *donkey; + + /* Initialize donkey ... */ + /* Register demo cyclic function */ - cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL); - if (!cyclic) - printf("Registering of cyclic_demo failed\n"); + cyclic_register(&donkey->cyclic, cyclic_demo, 10 * 1000, "cyclic_demo"); return 0; } diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index ca4fb0b5b10..211f7e4909c 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -96,12 +96,12 @@ sync the `dts/upstream/` subtree from the devicetree-rebasing repo whenever the next branch opens (refer: :doc:`../release_cycle`) with the latest mainline Linux kernel release. To sync the `dts/upstream/` subtree, run:: - ./dts/update-dts-subtree.sh pull <devicetree-rebasing-release-tag> + ./tools/update-subtree.sh pull dts <devicetree-rebasing-release-tag> If required it is also possible to cherry-pick fixes from the devicetree-rebasing repository prior to next sync, usage:: - ./dts/update-dts-subtree.sh pick <devicetree-rebasing-commit-id> + ./tools/update-subtree.sh pick dts <devicetree-rebasing-commit-id> Configuration @@ -116,8 +116,8 @@ However, if `dts/upstream/` hasn't yet received devicetree source file for your newly added board support then one option is that you can add the corresponding devicetree source file as `arch/<arch>/dts/<name>.dts`. To select that add `# CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=<name>` when -prompted by Kconfig. Another option is that you can use use the "pick" option of -`dts/update-dts-subtree.sh` mentioned above to bring in the commits that you +prompted by Kconfig. Another option is that you can use the "pick" option of +`tools/update-subtree.sh` mentioned above to bring in the commits that you need. This should include your CPU or SoC's devicetree file. On top of that any U-Boot diff --git a/doc/develop/gdb.rst b/doc/develop/gdb.rst new file mode 100644 index 00000000000..4e359c7f226 --- /dev/null +++ b/doc/develop/gdb.rst @@ -0,0 +1,171 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (c) 2024 Alexander Dahl + +Debugging U-Boot with GDB +========================= + +Using a JTAG adapter it is possible to debug a running U-Boot with GDB. +A common way is to connect a debug adapter to the JTAG connector of your +board, run a GDB server, connect GDB to the GDB server, and use GDB as usual. + +Similarly QEMU can provide a GDB server. + +Preparing build +--------------- + +Building U-Boot with with reduced optimization (-Og) and without link time +optimization is recommended for easier debugging:: + + CONFIG_CC_OPTIMIZE_FOR_DEBUG=y + CONFIG_LTO=n + +Otherwise build, install, and run U-Boot as usual. + +Using OpenOCD as GDB server +--------------------------- + +`OpenOCD <https://openocd.org/>`_ is an open source tool supporting hardware +debug probes, and providing a GDB server. It is readily available in major Linux +distributions or you can build it from source. + +Here is example of starting OpenOCD on Debian using a J-Link adapter and a +board with an AT91 SAMA5D2 SoC: + +.. code-block:: console + + $ openocd -f interface/jlink.cfg -f target/at91sama5d2.cfg -c 'adapter speed 4000' + Open On-Chip Debugger 0.12.0 + Licensed under GNU GPL v2 + For bug reports, read + http://openocd.org/doc/doxygen/bugs.html + Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'. + adapter speed: 4000 kHz + + Info : Listening on port 6666 for tcl connections + Info : Listening on port 4444 for telnet connections + Info : J-Link V10 compiled Jan 30 2023 11:28:07 + Info : Hardware version: 10.10 + Info : VTarget = 3.244 V + Info : clock speed 4000 kHz + Info : JTAG tap: at91sama5d2.cpu tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x5) + Info : at91sama5d2.cpu_a5.0: hardware has 3 breakpoints, 2 watchpoints + Info : at91sama5d2.cpu_a5.0: MPIDR level2 0, cluster 0, core 0, mono core, no SMT + Info : starting gdb server for at91sama5d2.cpu_a5.0 on 3333 + Info : Listening on port 3333 for gdb connections + +Notice that OpenOCD is listening on port 3333 for GDB connections. + +Using QEMU as GDB server +------------------------ + +When running U-Boot on QEMU you can used the '-gdb' parameter to provide a +GDB server: + + qemu-system-riscv64 -M virt -nographic -gdb tcp::3333 -kernel u-boot + +Running a GDB session +---------------------- + +You need a GDB suited for your target. This can be the GDB coming with your +toolchain or *gdb-multiarch* available in your Linux distribution. + +.. prompt:: bash $ + + gdb-multiarch u-boot + +In the above command-line *u-boot* is the U-boot binary in your build +directory. You may need to adjust the path when calling GDB. + +Connect to the GDB server like this: + +.. code-block:: console + + (gdb) target extended-remote :3333 + Remote debugging using :3333 + 0x27fa9ac6 in ?? () + (gdb) + +This is fine for debugging before U-Boot relocates itself. + +For debugging U-Boot after relocation you need to indicate the relocation +address to GDB. You can retrieve the relocation address from the U-Boot shell +with the command *bdinfo*: + +.. code-block:: console + + U-Boot> bdinfo + boot_params = 0x20000100 + DRAM bank = 0x00000000 + -> start = 0x20000000 + -> size = 0x08000000 + flashstart = 0x00000000 + flashsize = 0x00000000 + flashoffset = 0x00000000 + baudrate = 115200 bps + relocaddr = 0x27f7a000 + reloc off = 0x0607a000 + Build = 32-bit + current eth = ethernet@f8008000 + ethaddr = 00:50:c2:31:58:d4 + IP addr = <NULL> + fdt_blob = 0x27b36060 + new_fdt = 0x27b36060 + fdt_size = 0x00003e40 + lmb_dump_all: + memory.cnt = 0x1 / max = 0x10 + memory[0] [0x20000000-0x27ffffff], 0x08000000 bytes flags: 0 + reserved.cnt = 0x1 / max = 0x10 + reserved[0] [0x27b31d00-0x27ffffff], 0x004ce300 bytes flags: 0 + devicetree = separate + arch_number = 0x00000000 + TLB addr = 0x27ff0000 + irq_sp = 0x27b36050 + sp start = 0x27b36040 + Early malloc usage: cd8 / 2000 + +Look out for the line starting with *relocaddr* which has the address +you need, ``0x27f7a000`` in this case. + +On most architectures (not sandbox, x86, Xtensa) the global data pointer is +stored in a fixed register: + +============ ======== +Architecture Register +============ ======== +arc r25 +arm r9 +arm64 x18 +m68k d7 +microblaze r31 +mips k0 +nios2 gp +powerpc r2 +riscv gp +sh r13 +============ ======== + +On these architecture the relocation address cat be determined by +dereferencing the global data pointer stored in register, *r9* in the example: + +.. code-block:: console + + (gdb) p/x (*(struct global_data*)$r9)->relocaddr + $1 = 0x27f7a000 + +In the GDB shell discard the previously loaded symbol file and add it once +again with the relocation address like this: + +.. code-block:: console + + (gdb) symbol-file + Discard symbol table from `/home/adahl/build/u-boot/v2024.04.x/u-boot'? (y or n) y + No symbol file now. + (gdb) add-symbol-file u-boot 0x27f7a000 + add symbol table from file "u-boot" at + .text_addr = 0x27f7a000 + (y or n) y + Reading symbols from u-boot... + (gdb) + +You can now use GDB as usual, setting breakpoints, printing backtraces, +inspecting variables, stepping through the code, etc. diff --git a/doc/develop/index.rst b/doc/develop/index.rst index f82e148b101..c0107a783fc 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -29,7 +29,7 @@ Implementation directories bloblist - bootstd + bootstd/index ci_testing commands config_binding @@ -60,6 +60,7 @@ Debugging :maxdepth: 1 crash_dumps + gdb trace Packaging diff --git a/doc/develop/qconfig.rst b/doc/develop/qconfig.rst index 8efb1eb2685..123779eab17 100644 --- a/doc/develop/qconfig.rst +++ b/doc/develop/qconfig.rst @@ -85,6 +85,20 @@ example, to find boards which enabled CONFIG_SCSI but not CONFIG_BLK:: 3 matches pg_wcom_seli8_defconfig highbank_defconfig pg_wcom_expu1_defconfig +It is also possible to search for particular values. For example, this finds all +boards with an empty string for `CONFIG_DEFAULT_FDT_FILE`:: + + ./tools/qconfig.py -f DEFAULT_FDT_FILE=\"\" + 1092 matches + ... + +This finds boards which have a value for SYS_MAXARGS other than 64:: + + ./tools/qconfig.py -f ~SYS_MAXARGS=64 + cfg CONFIG_SYS_MAXARGS + 281 matches + ... + Finding implied CONFIGs ----------------------- diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index b392346eea8..e3c13b93afd 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -51,13 +51,13 @@ Examples:: Current Status -------------- -* U-Boot v2024.04 was released on Tue 02 April 2024. +* U-Boot v2024.07 was released on Mon 01 July 2024. -* The Merge Window for the next release (v2024.07) is **closed**. +* The Merge Window for the next release (v2024.10) is **closed**. -* The next branch is now **open**. +* The next branch is now **closed**. -* Release "v2024.07" is scheduled for 01 July 2024. +* Release "v2024.10" is scheduled for 07 October 2024. Future Releases --------------- @@ -67,27 +67,29 @@ Future Releases For the next scheduled release, release candidates were made on:: -* U-Boot v2024.07-rc1 was released on Mon 22 April 2024. +* U-Boot v2024.10-rc1 was released on Mon 22 July 2024. -* U-Boot v2024.07-rc2 was released on Mon 06 May 2024. +.. * U-Boot v2024.10-rc2 was released on Mon 05 August 2024. -* U-Boot v2024.07-rc3 was released on Mon 20 May 2024. +.. * U-Boot v2024.10-rc3 was released on Mon 19 August 2024. -* U-Boot v2024.07-rc4 was released on Mon 03 June 2024. +.. * U-Boot v2024.10-rc4 was released on Mon 02 September 2024. -* U-Boot v2024.07-rc5 was released on Mon 24 June 2024. +.. * U-Boot v2024.10-rc5 was released on Mon 16 September 2024. + +.. * U-Boot v2024.10-rc6 was released on Mon 30 September 2024. Please note that the following dates are planned only and may be deviated from as needed. -* "v2024.07": end of MW = Mon, Apr 22, 2024; release = Mon, Jul 01, 2024 - * "v2024.10": end of MW = Mon, Jul 22, 2024; release = Mon, Oct 07, 2024 * "v2025.01": end of MW = Mon, Oct 21, 2024; release = Mon, Jan 06, 2025 * "v2025.04": end of MW = Mon, Jan 27, 2025; release = Mon, Apr 07, 2025 +* "v2025.07": end of MW = Mon, Apr 21, 2025; release = Mon, Jul 07, 2025 + Previous Releases ----------------- @@ -95,6 +97,8 @@ Note: these statistics are generated by our fork of `gitdm <https://source.denx.de/u-boot/gitdm>`_, which was originally created by Jonathan Corbet. +* :doc:`statistics/u-boot-stats-v2024.07` which was released on 01 July 2024. + * :doc:`statistics/u-boot-stats-v2024.04` which was released on 02 April 2024. * :doc:`statistics/u-boot-stats-v2024.01` which was released on 08 January 2024. diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst index 0a3e572310a..4bb48e6b7b3 100644 --- a/doc/develop/spl.rst +++ b/doc/develop/spl.rst @@ -121,6 +121,8 @@ Use `spl_phase()` to find the current U-Boot phase, e.g. `PHASE_SPL`. You can also find the previous and next phase and get the phase name. +.. _fdtgrep_filter: + Device tree ----------- The U-Boot device tree is filtered by the fdtgrep tools during the build diff --git a/doc/develop/statistics/u-boot-stats-v2024.07.rst b/doc/develop/statistics/u-boot-stats-v2024.07.rst new file mode 100644 index 00000000000..b437e926659 --- /dev/null +++ b/doc/develop/statistics/u-boot-stats-v2024.07.rst @@ -0,0 +1,890 @@ +:orphan: + +Release Statistics for U-Boot v2024.07 +====================================== + +* Processed 1624 changesets from 191 developers + +* 28 employers found + +* A total of 2308875 lines added, 242831 removed (delta 2066044) + +.. table:: Developers with the most changesets + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Tom Rini 324 (20.0%) + Jonas Karlman 155 (9.5%) + Caleb Connolly 98 (6.0%) + Heinrich Schuchardt 84 (5.2%) + Quentin Schulz 59 (3.6%) + Marek Vasut 52 (3.2%) + Simon Glass 44 (2.7%) + Patrice Chotard 32 (2.0%) + Sumit Garg 31 (1.9%) + Svyatoslav Ryhel 31 (1.9%) + Michal Simek 26 (1.6%) + Ilias Apalodimas 23 (1.4%) + Neil Armstrong 23 (1.4%) + Jonathan Humphreys 22 (1.4%) + Andrew Davis 18 (1.1%) + Marek Behún 18 (1.1%) + Jagan Teki 17 (1.0%) + MD Danish Anwar 15 (0.9%) + Kongyang Liu 15 (0.9%) + Bryan Brattlof 14 (0.9%) + Janne Grunau 14 (0.9%) + Christophe Leroy 13 (0.8%) + Tim Harvey 13 (0.8%) + Apurva Nandan 12 (0.7%) + Wadim Egorov 11 (0.7%) + Andre Przywara 11 (0.7%) + Peng Fan 11 (0.7%) + Adam Ford 10 (0.6%) + Sam Protsenko 10 (0.6%) + Roger Quadros 10 (0.6%) + Igor Opaniuk 9 (0.6%) + Robert Marko 9 (0.6%) + Jonas Schwöbel 9 (0.6%) + Yang Xiwen 9 (0.6%) + Eugene Uriev 9 (0.6%) + Chris Morgan 8 (0.5%) + Judith Mendez 8 (0.5%) + Raymond Mao 8 (0.5%) + Alexander Dahl 7 (0.4%) + Fabio Estevam 7 (0.4%) + Jim Liu 7 (0.4%) + Venkatesh Yadav Abbarapu 7 (0.4%) + Mattijs Korpershoek 6 (0.4%) + Daniel Schultz 6 (0.4%) + Weizhao Ouyang 6 (0.4%) + Ye Li 6 (0.4%) + Conor Dooley 5 (0.3%) + Nishanth Menon 5 (0.3%) + Leo Yu-Chi Liang 5 (0.3%) + Bhargav Raviprakash 5 (0.3%) + Masahisa Kojima 5 (0.3%) + mwleeds@mailtundra.com 5 (0.3%) + Michał Barnaś 5 (0.3%) + Leonard Anderweit 5 (0.3%) + Chen-Yu Tsai 5 (0.3%) + Javier Martinez Canillas 4 (0.2%) + Francesco Dolcini 4 (0.2%) + Felipe Balbi 4 (0.2%) + Aniket Limaye 4 (0.2%) + Christopher Obbard 4 (0.2%) + Mathieu Othacehe 4 (0.2%) + Joao Paulo Goncalves 4 (0.2%) + Sughosh Ganu 4 (0.2%) + Volodymyr Babchuk 4 (0.2%) + Lukasz Majewski 4 (0.2%) + Jacky Chou 4 (0.2%) + Dan Carpenter 4 (0.2%) + Mihai Sain 4 (0.2%) + Arseniy Krasnov 3 (0.2%) + Fiona Klute 3 (0.2%) + Hanyuan Zhao 3 (0.2%) + Greg Malysa 3 (0.2%) + Nathan Barrett-Morrison 3 (0.2%) + Peter Robinson 3 (0.2%) + Lukas Funke 3 (0.2%) + Yannic Moog 3 (0.2%) + Udit Kumar 3 (0.2%) + Michael Walle 3 (0.2%) + Devarsh Thakkar 3 (0.2%) + Christophe Kerello 3 (0.2%) + Viacheslav Bocharov 3 (0.2%) + Emanuele Ghidoli 3 (0.2%) + Hari Nagalla 3 (0.2%) + Love Kumar 3 (0.2%) + Thomas Weißschuh 3 (0.2%) + Weijie Gao 3 (0.2%) + Dragan Simic 2 (0.1%) + Michael Trimarchi 2 (0.1%) + Patrick Delaunay 2 (0.1%) + Tony Dinh 2 (0.1%) + Sam Povilus 2 (0.1%) + H Bell 2 (0.1%) + Thinh Nguyen 2 (0.1%) + Benjamin Hahn 2 (0.1%) + Neha Malcom Francis 2 (0.1%) + Ian Roberts 2 (0.1%) + Sean Anderson 2 (0.1%) + Kamlesh Gurudasani 2 (0.1%) + Stefan Eichenberger 2 (0.1%) + Parth Pancholi 2 (0.1%) + Maksim Kiselev 2 (0.1%) + Christophe Roullier 2 (0.1%) + Hugo Dubois 2 (0.1%) + CASAUBON Jean Michel 2 (0.1%) + Ahelenia Ziemiańska 2 (0.1%) + Yasuharu Shibata 2 (0.1%) + Wan Yee Lau 2 (0.1%) + Vincent Stehlé 2 (0.1%) + Marcel Ziswiler 2 (0.1%) + Maxim Moskalets 2 (0.1%) + Sébastien Szymanski 2 (0.1%) + Tejas Bhumkar 2 (0.1%) + Bhupesh Sharma 2 (0.1%) + Colin McAllister 2 (0.1%) + Andy Yan 2 (0.1%) + Dasnavis Sabiya 2 (0.1%) + Stefan Bosch 2 (0.1%) + Frank Wunderlich 1 (0.1%) + Jiaxun Yang 1 (0.1%) + Ravi Minnikanti 1 (0.1%) + John Watts 1 (0.1%) + Heiko Schocher 1 (0.1%) + Thomas Perl 1 (0.1%) + Kristian Amlie 1 (0.1%) + Heiko Stuebner 1 (0.1%) + Anand Moon 1 (0.1%) + Alexander Sverdlin 1 (0.1%) + Aswath Govindraju 1 (0.1%) + Sam Day 1 (0.1%) + Boon Khai Ng 1 (0.1%) + William Zhang 1 (0.1%) + Jaehoon Chung 1 (0.1%) + Sam Edwards 1 (0.1%) + Linus Walleij 1 (0.1%) + Kishan Dudhatra 1 (0.1%) + Yu Chien Peter Lin 1 (0.1%) + Nitin Yadav 1 (0.1%) + Andrea Calabrese 1 (0.1%) + Lukasz Czechowski 1 (0.1%) + Finley Xiao 1 (0.1%) + Jason Zhu 1 (0.1%) + Maximilian Brune 1 (0.1%) + cmachida 1 (0.1%) + Hector Martin 1 (0.1%) + Anton Bambura 1 (0.1%) + Khem Raj 1 (0.1%) + Jianan Huang 1 (0.1%) + Charles Hardin 1 (0.1%) + Gireesh Hiremath 1 (0.1%) + Alexey Romanov 1 (0.1%) + Eugeniu Rosca 1 (0.1%) + Bruce Suen 1 (0.1%) + Kunihiko Hayashi 1 (0.1%) + Hugo Cornelis 1 (0.1%) + Vitor Soares 1 (0.1%) + Martyn Welch 1 (0.1%) + Manorit Chawdhry 1 (0.1%) + Jixiong Hu 1 (0.1%) + Pierre-Clément Tosi 1 (0.1%) + Hiago De Franco 1 (0.1%) + Petr Zejdl 1 (0.1%) + Łukasz Stelmach 1 (0.1%) + Ben Dooks 1 (0.1%) + Javier Viguera 1 (0.1%) + Josua Mayer 1 (0.1%) + James Hilliard 1 (0.1%) + Marjolaine Amate 1 (0.1%) + Vishal Sagar 1 (0.1%) + Manikanta Guntupalli 1 (0.1%) + Shubhangi Shrikrushna Mahalle 1 (0.1%) + Piotr Wojtaszczyk 1 (0.1%) + Kelly Hung 1 (0.1%) + Leon M. Busch-George 1 (0.1%) + Lukasz Wiecaszek 1 (0.1%) + Jit Loon Lim 1 (0.1%) + William Wu 1 (0.1%) + Ben Wolsieffer 1 (0.1%) + Elon Zhang 1 (0.1%) + Vignesh Raghavendra 1 (0.1%) + Maks Mishin 1 (0.1%) + Bob Wolff 1 (0.1%) + Romain Naour 1 (0.1%) + Dmitry Baryshkov 1 (0.1%) + Vishal Mahaveer 1 (0.1%) + Siddharth Vadapalli 1 (0.1%) + Ivan Orlov 1 (0.1%) + Nam Cao 1 (0.1%) + Massimiliano Minella 1 (0.1%) + BELOUARGA Mohamed 1 (0.1%) + Alexander Gendin 1 (0.1%) + Ivan Mikhaylov 1 (0.1%) + ==================================== ===== + + +.. table:: Developers with the most changed lines + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Tom Rini 2187616 (86.6%) + Jonas Karlman 69460 (2.8%) + Marek Vasut 53285 (2.1%) + Caleb Connolly 47393 (1.9%) + Apurva Nandan 26241 (1.0%) + Neil Armstrong 23816 (0.9%) + Tim Harvey 10971 (0.4%) + Christophe Leroy 10210 (0.4%) + Wadim Egorov 8248 (0.3%) + Bryan Brattlof 7039 (0.3%) + Tony Dinh 5540 (0.2%) + Marcel Ziswiler 5068 (0.2%) + Nathan Barrett-Morrison 4872 (0.2%) + Adam Ford 4867 (0.2%) + Sumit Garg 4743 (0.2%) + Andrew Davis 4066 (0.2%) + Quentin Schulz 3449 (0.1%) + Peng Fan 3071 (0.1%) + Sam Protsenko 3021 (0.1%) + Jit Loon Lim 2717 (0.1%) + MD Danish Anwar 2686 (0.1%) + Anand Moon 2526 (0.1%) + Svyatoslav Ryhel 2445 (0.1%) + Andy Yan 1978 (0.1%) + Peter Robinson 1907 (0.1%) + Boon Khai Ng 1709 (0.1%) + Arseniy Krasnov 1669 (0.1%) + Heinrich Schuchardt 1350 (0.1%) + Jagan Teki 1347 (0.1%) + Fabio Estevam 1209 (0.0%) + Ilias Apalodimas 1189 (0.0%) + Simon Glass 1137 (0.0%) + Roger Quadros 955 (0.0%) + Marek Behún 939 (0.0%) + Elon Zhang 889 (0.0%) + Kongyang Liu 846 (0.0%) + Mihai Sain 789 (0.0%) + Bhupesh Sharma 662 (0.0%) + Jonas Schwöbel 620 (0.0%) + Javier Martinez Canillas 597 (0.0%) + Michael Walle 505 (0.0%) + Eugene Uriev 501 (0.0%) + Christophe Kerello 479 (0.0%) + Chris Morgan 452 (0.0%) + Michal Simek 449 (0.0%) + Bhargav Raviprakash 388 (0.0%) + Janne Grunau 386 (0.0%) + Robert Marko 332 (0.0%) + Vignesh Raghavendra 332 (0.0%) + H Bell 291 (0.0%) + Yang Xiwen 278 (0.0%) + Bruce Suen 269 (0.0%) + Daniel Schultz 265 (0.0%) + Love Kumar 258 (0.0%) + Igor Opaniuk 219 (0.0%) + Raymond Mao 208 (0.0%) + Wan Yee Lau 206 (0.0%) + Sughosh Ganu 201 (0.0%) + Greg Malysa 200 (0.0%) + Patrice Chotard 199 (0.0%) + Masahisa Kojima 193 (0.0%) + Dasnavis Sabiya 189 (0.0%) + Neha Malcom Francis 183 (0.0%) + Jonathan Humphreys 173 (0.0%) + Anton Bambura 167 (0.0%) + Kelly Hung 164 (0.0%) + Andre Przywara 163 (0.0%) + Kamlesh Gurudasani 163 (0.0%) + Volodymyr Babchuk 147 (0.0%) + Parth Pancholi 146 (0.0%) + Piotr Wojtaszczyk 144 (0.0%) + Judith Mendez 131 (0.0%) + Joao Paulo Goncalves 131 (0.0%) + Leonard Anderweit 117 (0.0%) + BELOUARGA Mohamed 114 (0.0%) + Finley Xiao 109 (0.0%) + Jianan Huang 99 (0.0%) + Venkatesh Yadav Abbarapu 95 (0.0%) + Chen-Yu Tsai 92 (0.0%) + Mathieu Othacehe 92 (0.0%) + Michał Barnaś 86 (0.0%) + Lukasz Majewski 74 (0.0%) + Alexander Dahl 67 (0.0%) + Nishanth Menon 66 (0.0%) + Conor Dooley 64 (0.0%) + Francesco Dolcini 64 (0.0%) + Maksim Kiselev 64 (0.0%) + Linus Walleij 64 (0.0%) + Weizhao Ouyang 63 (0.0%) + Yannic Moog 61 (0.0%) + Weijie Gao 60 (0.0%) + Ben Dooks 60 (0.0%) + Leo Yu-Chi Liang 59 (0.0%) + Fiona Klute 56 (0.0%) + Alexey Romanov 56 (0.0%) + Jim Liu 55 (0.0%) + Devarsh Thakkar 53 (0.0%) + Colin McAllister 53 (0.0%) + Maxim Moskalets 51 (0.0%) + Josua Mayer 50 (0.0%) + Ivan Mikhaylov 50 (0.0%) + Ian Roberts 47 (0.0%) + Christophe Roullier 44 (0.0%) + Vincent Stehlé 44 (0.0%) + Nam Cao 43 (0.0%) + Ben Wolsieffer 42 (0.0%) + Felipe Balbi 41 (0.0%) + Vishal Sagar 40 (0.0%) + Hanyuan Zhao 38 (0.0%) + Hugo Dubois 37 (0.0%) + Christopher Obbard 34 (0.0%) + Aniket Limaye 33 (0.0%) + Romain Naour 33 (0.0%) + Heiko Stuebner 31 (0.0%) + Emanuele Ghidoli 30 (0.0%) + Stefan Bosch 30 (0.0%) + mwleeds@mailtundra.com 28 (0.0%) + Michael Trimarchi 23 (0.0%) + Thomas Weißschuh 22 (0.0%) + Thinh Nguyen 21 (0.0%) + Nitin Yadav 19 (0.0%) + Jixiong Hu 18 (0.0%) + Marjolaine Amate 18 (0.0%) + Dan Carpenter 17 (0.0%) + Stefan Eichenberger 17 (0.0%) + Sam Povilus 15 (0.0%) + Sébastien Szymanski 15 (0.0%) + Massimiliano Minella 15 (0.0%) + Mattijs Korpershoek 14 (0.0%) + Sean Anderson 14 (0.0%) + Lukas Funke 13 (0.0%) + Yasuharu Shibata 13 (0.0%) + Sam Edwards 13 (0.0%) + Kunihiko Hayashi 13 (0.0%) + Jacky Chou 12 (0.0%) + Vitor Soares 12 (0.0%) + Ye Li 11 (0.0%) + Udit Kumar 11 (0.0%) + Hiago De Franco 11 (0.0%) + Hari Nagalla 10 (0.0%) + Maximilian Brune 10 (0.0%) + Leon M. Busch-George 10 (0.0%) + Viacheslav Bocharov 9 (0.0%) + Benjamin Hahn 9 (0.0%) + cmachida 9 (0.0%) + James Hilliard 9 (0.0%) + Lukasz Wiecaszek 9 (0.0%) + Charles Hardin 8 (0.0%) + Petr Zejdl 8 (0.0%) + Vishal Mahaveer 8 (0.0%) + Sam Day 7 (0.0%) + Manorit Chawdhry 7 (0.0%) + Łukasz Stelmach 7 (0.0%) + Andrea Calabrese 6 (0.0%) + Siddharth Vadapalli 6 (0.0%) + CASAUBON Jean Michel 5 (0.0%) + Ahelenia Ziemiańska 5 (0.0%) + Ravi Minnikanti 5 (0.0%) + Hugo Cornelis 5 (0.0%) + Bob Wolff 5 (0.0%) + Alexander Gendin 5 (0.0%) + Dragan Simic 4 (0.0%) + Aswath Govindraju 4 (0.0%) + Kishan Dudhatra 4 (0.0%) + Khem Raj 4 (0.0%) + Tejas Bhumkar 3 (0.0%) + Heiko Schocher 3 (0.0%) + Lukasz Czechowski 3 (0.0%) + Jason Zhu 3 (0.0%) + Maks Mishin 3 (0.0%) + Patrick Delaunay 2 (0.0%) + Jiaxun Yang 2 (0.0%) + William Zhang 2 (0.0%) + Eugeniu Rosca 2 (0.0%) + Pierre-Clément Tosi 2 (0.0%) + Javier Viguera 2 (0.0%) + Manikanta Guntupalli 2 (0.0%) + Dmitry Baryshkov 2 (0.0%) + Frank Wunderlich 1 (0.0%) + John Watts 1 (0.0%) + Thomas Perl 1 (0.0%) + Kristian Amlie 1 (0.0%) + Alexander Sverdlin 1 (0.0%) + Jaehoon Chung 1 (0.0%) + Yu Chien Peter Lin 1 (0.0%) + Hector Martin 1 (0.0%) + Gireesh Hiremath 1 (0.0%) + Martyn Welch 1 (0.0%) + Shubhangi Shrikrushna Mahalle 1 (0.0%) + William Wu 1 (0.0%) + Ivan Orlov 1 (0.0%) + ==================================== ===== + + +.. table:: Developers with the most lines removed + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Jonas Karlman 59892 (24.7%) + Marek Vasut 51731 (21.3%) + Neil Armstrong 19240 (7.9%) + Tim Harvey 10397 (4.3%) + Tony Dinh 5465 (2.3%) + Marcel Ziswiler 5061 (2.1%) + Adam Ford 4818 (2.0%) + Andrew Davis 3493 (1.4%) + Peng Fan 2778 (1.1%) + Anand Moon 2523 (1.0%) + Sam Protsenko 2273 (0.9%) + Peter Robinson 1907 (0.8%) + Fabio Estevam 1185 (0.5%) + Sumit Garg 845 (0.3%) + Javier Martinez Canillas 582 (0.2%) + Michael Walle 494 (0.2%) + Chen-Yu Tsai 80 (0.0%) + Igor Opaniuk 72 (0.0%) + Linus Walleij 61 (0.0%) + Francesco Dolcini 36 (0.0%) + Sam Edwards 12 (0.0%) + Ben Wolsieffer 11 (0.0%) + Hiago De Franco 11 (0.0%) + Kunihiko Hayashi 10 (0.0%) + Colin McAllister 7 (0.0%) + Heiko Schocher 3 (0.0%) + Dan Carpenter 2 (0.0%) + Dragan Simic 2 (0.0%) + Jiaxun Yang 1 (0.0%) + William Zhang 1 (0.0%) + ==================================== ===== + + +.. table:: Developers with the most signoffs (total 231) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Caleb Connolly 41 (17.7%) + Mattijs Korpershoek 19 (8.2%) + Michal Simek 15 (6.5%) + Dario Binacchi 11 (4.8%) + Chris Morgan 10 (4.3%) + Ilias Apalodimas 10 (4.3%) + Svyatoslav Ryhel 10 (4.3%) + Hari Nagalla 8 (3.5%) + Minkyu Kang 7 (3.0%) + Alexander Sverdlin 6 (2.6%) + Ian Roberts 6 (2.6%) + Greg Malysa 5 (2.2%) + Nathan Barrett-Morrison 5 (2.2%) + Manorit Chawdhry 4 (1.7%) + Dasnavis Sabiya 4 (1.7%) + Christophe Leroy 4 (1.7%) + Apurva Nandan 4 (1.7%) + Neil Armstrong 3 (1.3%) + Francesco Dolcini 3 (1.3%) + Vasileios Bimpikas 3 (1.3%) + Utsav Agarwal 3 (1.3%) + Arturs Artamonovs 3 (1.3%) + Neha Malcom Francis 3 (1.3%) + Janne Grunau 3 (1.3%) + Heinrich Schuchardt 3 (1.3%) + Jonas Karlman 2 (0.9%) + Marek Vasut 2 (0.9%) + Sumit Garg 2 (0.9%) + Dhruva Gole 2 (0.9%) + Kever Yang 2 (0.9%) + Ravi Gunasekaran 2 (0.9%) + Parvathi Bhogaraju 2 (0.9%) + Jayesh Choudhary 2 (0.9%) + Bo-Cun Chen 2 (0.9%) + Daniel Schultz 2 (0.9%) + Jonas Schwöbel 2 (0.9%) + Bryan Brattlof 2 (0.9%) + Peng Fan 1 (0.4%) + Fabio Estevam 1 (0.4%) + Stefan Roese 1 (0.4%) + Greg Kroah-Hartman 1 (0.4%) + Angelo Dureghello 1 (0.4%) + Anatolij Gustschin 1 (0.4%) + Vaishnav Achath 1 (0.4%) + Ashok Reddy Soma 1 (0.4%) + Dong Huang 1 (0.4%) + Shubhangi Shrikrushna Mahalle 1 (0.4%) + Felipe Balbi 1 (0.4%) + Judith Mendez 1 (0.4%) + Patrice Chotard 1 (0.4%) + Quentin Schulz 1 (0.4%) + ==================================== ===== + + +.. table:: Developers with the most reviews (total 1025) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Kever Yang 223 (21.8%) + Neil Armstrong 71 (6.9%) + Sumit Garg 70 (6.8%) + Dragan Simic 45 (4.4%) + Ilias Apalodimas 42 (4.1%) + Heinrich Schuchardt 35 (3.4%) + Patrick Delaunay 33 (3.2%) + Quentin Schulz 32 (3.1%) + Mattijs Korpershoek 31 (3.0%) + Leo Yu-Chi Liang 31 (3.0%) + Marek Vasut 28 (2.7%) + Jaehoon Chung 28 (2.7%) + Patrice Chotard 22 (2.1%) + Caleb Connolly 21 (2.0%) + Tom Rini 21 (2.0%) + Stefan Roese 20 (2.0%) + Neha Malcom Francis 17 (1.7%) + Simon Glass 16 (1.6%) + Peter Robinson 13 (1.3%) + Igor Opaniuk 13 (1.3%) + Thierry Reding 12 (1.2%) + Neal Gompa 11 (1.1%) + Heiko Schocher 9 (0.9%) + Michael Trimarchi 9 (0.9%) + Roger Quadros 9 (0.9%) + Tony Dinh 8 (0.8%) + Christopher Obbard 8 (0.8%) + Jonas Karlman 6 (0.6%) + Dhruva Gole 6 (0.6%) + E Shattow 6 (0.6%) + Christophe ROULLIER 6 (0.6%) + Richard Henderson 6 (0.6%) + Nishanth Menon 6 (0.6%) + Ravi Gunasekaran 5 (0.5%) + Teresa Remmet 5 (0.5%) + Mark Kettenis 5 (0.5%) + Paul Barker 5 (0.5%) + Udit Kumar 5 (0.5%) + Sean Anderson 5 (0.5%) + Fabio Estevam 4 (0.4%) + Sam Protsenko 4 (0.4%) + Enric Balletbo i Serra 4 (0.4%) + Laurent Pinchart 4 (0.4%) + Bryan Brattlof 3 (0.3%) + Andrew Davis 3 (0.3%) + Sam Edwards 3 (0.3%) + Dan Carpenter 3 (0.3%) + William Zhang 3 (0.3%) + Chris Packham 3 (0.3%) + Nikhil M Jain 3 (0.3%) + Tianling Shen 3 (0.3%) + Anatolij Gustschin 2 (0.2%) + CASAUBON Jean Michel 2 (0.2%) + Ian Ray 2 (0.2%) + Oleksandr Suvorov 2 (0.2%) + Bin Meng 2 (0.2%) + Tien Fong Chee 2 (0.2%) + Minkyu Kang 1 (0.1%) + Tim Harvey 1 (0.1%) + Adam Ford 1 (0.1%) + Linus Walleij 1 (0.1%) + Eddie James 1 (0.1%) + Guillaume La Roque 1 (0.1%) + Julien Masson 1 (0.1%) + Miquel Raynal 1 (0.1%) + Tim Lunn 1 (0.1%) + Cédric Le Goater 1 (0.1%) + Biju Das 1 (0.1%) + Holger Brunck 1 (0.1%) + Otavio Salvador 1 (0.1%) + Chia-Wei Wang 1 (0.1%) + Keerthy 1 (0.1%) + Philipp Tomsich 1 (0.1%) + Gao Xiang 1 (0.1%) + Frieder Schrempf 1 (0.1%) + Dmitrii Merkurev 1 (0.1%) + Marc Zyngier 1 (0.1%) + Ramon Fried 1 (0.1%) + Jai Luthra 1 (0.1%) + Alexander Dahl 1 (0.1%) + Heiko Stuebner 1 (0.1%) + Hugo Dubois 1 (0.1%) + Weizhao Ouyang 1 (0.1%) + Andre Przywara 1 (0.1%) + Mathieu Othacehe 1 (0.1%) + Wadim Egorov 1 (0.1%) + ==================================== ===== + + +.. table:: Developers with the most test credits (total 166) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Sumit Garg 19 (11.4%) + Marcel Ziswiler 15 (9.0%) + Svyatoslav Ryhel 10 (6.0%) + Mattijs Korpershoek 9 (5.4%) + Ion Agorria 9 (5.4%) + Tim Harvey 7 (4.2%) + Adam Ford 7 (4.2%) + Andreas Westman Dorcsak 7 (4.2%) + Sam Edwards 6 (3.6%) + Agneli 6 (3.6%) + Robert Eckelmann 6 (3.6%) + Simon Glass 5 (3.0%) + Teresa Remmet 5 (3.0%) + Fabio Estevam 5 (3.0%) + Ilias Apalodimas 4 (2.4%) + Jonathan Humphreys 4 (2.4%) + Neil Armstrong 3 (1.8%) + Paul Barker 3 (1.8%) + Heiko Stuebner 3 (1.8%) + Christian Gmeiner 3 (1.8%) + Heinrich Schuchardt 2 (1.2%) + Caleb Connolly 2 (1.2%) + Tony Dinh 2 (1.2%) + Hiago De Franco 2 (1.2%) + Robert Nelson 2 (1.2%) + Leo Yu-Chi Liang 1 (0.6%) + Jaehoon Chung 1 (0.6%) + Patrice Chotard 1 (0.6%) + Dhruva Gole 1 (0.6%) + E Shattow 1 (0.6%) + Ravi Gunasekaran 1 (0.6%) + Bryan Brattlof 1 (0.6%) + Andrew Davis 1 (0.6%) + Tim Lunn 1 (0.6%) + Otavio Salvador 1 (0.6%) + Wadim Egorov 1 (0.6%) + Michal Simek 1 (0.6%) + Alexander Sverdlin 1 (0.6%) + Jonas Schwöbel 1 (0.6%) + Judith Mendez 1 (0.6%) + Michael Walle 1 (0.6%) + Patrick Bruenn 1 (0.6%) + Jethro Bull 1 (0.6%) + Kamlesh Gurudasani 1 (0.6%) + Robert Marko 1 (0.6%) + ==================================== ===== + + +.. table:: Developers who gave the most tested-by credits (total 166) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Svyatoslav Ryhel 36 (21.7%) + Caleb Connolly 23 (13.9%) + Sumit Garg 15 (9.0%) + Apurva Nandan 12 (7.2%) + Marek Vasut 10 (6.0%) + Ilias Apalodimas 6 (3.6%) + Quentin Schulz 6 (3.6%) + Tom Rini 6 (3.6%) + Neil Armstrong 5 (3.0%) + Andrew Davis 5 (3.0%) + Leonard Anderweit 5 (3.0%) + Jonas Schwöbel 4 (2.4%) + Fabio Estevam 3 (1.8%) + Heinrich Schuchardt 3 (1.8%) + Bryan Brattlof 3 (1.8%) + Alexander Sverdlin 2 (1.2%) + Dasnavis Sabiya 2 (1.2%) + Pierre-Clément Tosi 2 (1.2%) + Yasuharu Shibata 2 (1.2%) + Josua Mayer 2 (1.2%) + Masahisa Kojima 2 (1.2%) + Tim Harvey 1 (0.6%) + Simon Glass 1 (0.6%) + Tony Dinh 1 (0.6%) + Judith Mendez 1 (0.6%) + Igor Opaniuk 1 (0.6%) + Roger Quadros 1 (0.6%) + Nishanth Menon 1 (0.6%) + Anand Moon 1 (0.6%) + Sébastien Szymanski 1 (0.6%) + Maksim Kiselev 1 (0.6%) + Ben Dooks 1 (0.6%) + Yang Xiwen 1 (0.6%) + ==================================== ===== + + +.. table:: Developers with the most report credits (total 27) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + E Shattow 4 (14.8%) + Sumit Garg 2 (7.4%) + Jonas Karlman 2 (7.4%) + Laurent Pinchart 2 (7.4%) + Suman Anna 2 (7.4%) + Marek Vasut 1 (3.7%) + Andrew Davis 1 (3.7%) + Heinrich Schuchardt 1 (3.7%) + Tim Harvey 1 (3.7%) + Simon Glass 1 (3.7%) + Jonathan Humphreys 1 (3.7%) + Patrice Chotard 1 (3.7%) + Dhruva Gole 1 (3.7%) + Dan Carpenter 1 (3.7%) + Christophe Leroy 1 (3.7%) + Eugeniu Rosca 1 (3.7%) + Janusz Dziedzic 1 (3.7%) + David Virag 1 (3.7%) + Jan Kiszka 1 (3.7%) + Aniket Limaye 1 (3.7%) + ==================================== ===== + + +.. table:: Developers who gave the most report credits (total 27) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Heinrich Schuchardt 6 (22.2%) + Neha Malcom Francis 3 (11.1%) + Marek Vasut 2 (7.4%) + Caleb Connolly 2 (7.4%) + Tom Rini 2 (7.4%) + Fabio Estevam 2 (7.4%) + Bryan Brattlof 2 (7.4%) + Andrew Davis 1 (3.7%) + Ilias Apalodimas 1 (3.7%) + Quentin Schulz 1 (3.7%) + Yasuharu Shibata 1 (3.7%) + Nishanth Menon 1 (3.7%) + Sam Protsenko 1 (3.7%) + Felipe Balbi 1 (3.7%) + Alexander Gendin 1 (3.7%) + ==================================== ===== + + +.. table:: Top changeset contributors by employer + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + (Unknown) 645 (39.7%) + Konsulko Group 324 (20.0%) + Linaro 201 (12.4%) + Texas Instruments 119 (7.3%) + Google LLC 50 (3.1%) + AMD 43 (2.6%) + ST Microelectronics 39 (2.4%) + DENX Software Engineering 34 (2.1%) + Phytec 27 (1.7%) + Renesas Electronics 25 (1.5%) + Toradex 19 (1.2%) + NXP 17 (1.0%) + Edgeble AI Technologies Pvt. Ltd. 14 (0.9%) + ARM 13 (0.8%) + Intel 9 (0.6%) + Amarula Solutions 7 (0.4%) + BayLibre SAS 6 (0.4%) + Socionext Inc. 6 (0.4%) + Collabora Ltd. 5 (0.3%) + Red Hat 4 (0.2%) + linutronix 4 (0.2%) + Rockchip 4 (0.2%) + Weidmüller Interface GmbH & Co. KG 3 (0.2%) + Samsung 2 (0.1%) + Broadcom 1 (0.1%) + Digi International 1 (0.1%) + Marvell 1 (0.1%) + Siemens 1 (0.1%) + ==================================== ===== + + +.. table:: Top lines changed by employer + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + Konsulko Group 2187616 (86.6%) + (Unknown) 130949 (5.2%) + Linaro 80577 (3.2%) + Renesas Electronics 52143 (2.1%) + Texas Instruments 41420 (1.6%) + Phytec 8700 (0.3%) + Toradex 5479 (0.2%) + Intel 4682 (0.2%) + Edgeble AI Technologies Pvt. Ltd. 3856 (0.2%) + NXP 3082 (0.1%) + DENX Software Engineering 1283 (0.1%) + Google LLC 1225 (0.0%) + Rockchip 1002 (0.0%) + AMD 863 (0.0%) + ST Microelectronics 724 (0.0%) + Red Hat 597 (0.0%) + ARM 207 (0.0%) + Socionext Inc. 206 (0.0%) + linutronix 65 (0.0%) + Amarula Solutions 46 (0.0%) + Collabora Ltd. 35 (0.0%) + BayLibre SAS 14 (0.0%) + Weidmüller Interface GmbH & Co. KG 13 (0.0%) + Samsung 8 (0.0%) + Marvell 5 (0.0%) + Broadcom 2 (0.0%) + Digi International 2 (0.0%) + Siemens 1 (0.0%) + ==================================== ===== + + +.. table:: Employers with the most signoffs (total 231) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + (Unknown) 56 (24.2%) + Linaro 56 (24.2%) + Texas Instruments 33 (14.3%) + BayLibre SAS 19 (8.2%) + AMD 17 (7.4%) + Amarula Solutions 11 (4.8%) + Analog Devices 9 (3.9%) + Samsung 7 (3.0%) + Siemens 6 (2.6%) + DENX Software Engineering 4 (1.7%) + Toradex 3 (1.3%) + Canonical 3 (1.3%) + Phytec 2 (0.9%) + Rockchip 2 (0.9%) + Intel 1 (0.4%) + NXP 1 (0.4%) + ST Microelectronics 1 (0.4%) + ==================================== ===== + + +.. table:: Employers with the most hackers (total 195) + :widths: auto + + ==================================== ===== + Name Count + ==================================== ===== + (Unknown) 98 (50.3%) + Texas Instruments 20 (10.3%) + Linaro 10 (5.1%) + AMD 8 (4.1%) + Toradex 8 (4.1%) + Phytec 5 (2.6%) + Intel 5 (2.6%) + DENX Software Engineering 4 (2.1%) + Rockchip 4 (2.1%) + ST Microelectronics 4 (2.1%) + Amarula Solutions 3 (1.5%) + Google LLC 3 (1.5%) + Samsung 2 (1.0%) + NXP 2 (1.0%) + Edgeble AI Technologies Pvt. Ltd. 2 (1.0%) + ARM 2 (1.0%) + Socionext Inc. 2 (1.0%) + linutronix 2 (1.0%) + Collabora Ltd. 2 (1.0%) + BayLibre SAS 1 (0.5%) + Siemens 1 (0.5%) + Konsulko Group 1 (0.5%) + Renesas Electronics 1 (0.5%) + Red Hat 1 (0.5%) + Weidmüller Interface GmbH & Co. KG 1 (0.5%) + Marvell 1 (0.5%) + Broadcom 1 (0.5%) + Digi International 1 (0.5%) + ==================================== ===== + diff --git a/doc/develop/tests_writing.rst b/doc/develop/tests_writing.rst index bb1145da268..44b544fa78b 100644 --- a/doc/develop/tests_writing.rst +++ b/doc/develop/tests_writing.rst @@ -281,7 +281,6 @@ new one of those, you should add a new suite. Create a new file in test/ or a subdirectory and define a macro to register the suite. For example:: - #include <common.h> #include <console.h> #include <mapmem.h> #include <dm/test.h> diff --git a/doc/develop/uefi/fwu_updates.rst b/doc/develop/uefi/fwu_updates.rst index e4709d82b41..51e8a28efe1 100644 --- a/doc/develop/uefi/fwu_updates.rst +++ b/doc/develop/uefi/fwu_updates.rst @@ -46,6 +46,8 @@ The feature can be enabled by specifying the following configs:: CONFIG_FWU_NUM_BANKS=<val> CONFIG_FWU_NUM_IMAGES_PER_BANK=<val> + CONFIG_FWU_MDATA_V1=y or CONFIG_FWU_MDATA_V2=y + in the .config file By enabling the CONFIG_CMD_FWU_METADATA config option, the @@ -58,6 +60,14 @@ enable the FWU Multi Bank Update functionality. Please refer to the section :ref:`uefi_capsule_update_ref` for more details on generation of the UEFI capsule. +FWU Metadata +------------ + +U-Boot supports both versions(1 and 2) of the FWU metadata defined in +the two revisions of the specification. Support can be enabled for +either of the two versions through a config flag. The mkfwumdata tool +can generate metadata for both the supported versions. + Setting up the device for GPT partitioned storage ------------------------------------------------- @@ -94,12 +104,12 @@ of. Each GPT partition entry in the GPT header has two GUIDs:: * UniquePartitionGUID The PartitionTypeGUID value should correspond to the -``image_type_uuid`` field of the FWU metadata. This field is used to +``image_type_guid`` field of the FWU metadata. This field is used to identify a given type of updatable firmware image, e.g. U-Boot, OP-TEE, FIP etc. This GUID should also be used for specifying the `--guid` parameter when generating the capsule. -The UniquePartitionGUID value should correspond to the ``image_uuid`` +The UniquePartitionGUID value should correspond to the ``image_guid`` field in the FWU metadata. This GUID is used to identify images of a given image type in different banks. @@ -108,8 +118,8 @@ metadata partitions. This would be the PartitionTypeGUID for the metadata partitions. Similarly, the UEFI specification defines the ESP GUID to be be used. -When generating the metadata, the ``image_type_uuid`` and the -``image_uuid`` values should match the *PartitionTypeGUID* and the +When generating the metadata, the ``image_type_guid`` and the +``image_guid`` values should match the *PartitionTypeGUID* and the *UniquePartitionGUID* values respectively. Performing the Update @@ -181,5 +191,5 @@ empty capsule would be:: Links ----- -* [1] https://developer.arm.com/documentation/den0118/a/ - FWU Specification +* [1] https://developer.arm.com/documentation/den0118/ - FWU Specification * [2] https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf - Dependable Boot Specification diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index ea70dcbda86..d450b12bf80 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -580,10 +580,10 @@ and used by the steps highlighted below. } You can perform step-4 through the Kconfig symbol -CONFIG_EFI_CAPSULE_ESL_FILE. This symbol points to the esl file -generated in step-2. Once the symbol has been populated with the path -to the esl file, it will automatically get embedded into the -platform's dtb as part of U-Boot build. +CONFIG_EFI_CAPSULE_CRT_FILE. This symbol points to the signing key +generated in step-2. As part of U-Boot build, the ESL certificate file will +be generated from the signing key and automatically get embedded into the +platform's dtb. Anti-rollback Protection ************************ @@ -631,6 +631,18 @@ where version.dtso looks like:: The properties of image-type-id and image-index must match the value defined in the efi_fw_image array as image_type_id and image_index. +Porting Capsule Updates to new boards +************************************* + +It is important, when using a reference board as a starting point for a custom +board, that certain steps are taken to properly support Capsule Updates. + +Capsule GUIDs need to be unique for each firmware and board. That is, if two +firmwares are built from the same source but result in different binaries +because they are built for different boards, they should have different GUIDs. +Therefore it is important when creating support for a new board, new GUIDs are +defined in the board's header file. *DO NOT* reuse capsule GUIDs. + Executing the boot manager ~~~~~~~~~~~~~~~~~~~~~~~~~~ |