Merge branch 'next'

doc/develop/binman_tests.rst

@@ -431,11 +431,11 @@ error message produced by Binman. Sometimes you need to add several tests, each
 with their own broken image description, in order to check all the error cases.
 
 Sometimes you need to capture the console output of Binman, to check it is
-correct. You can to this with ``test_util.capture_sys_output()``, for example:
+correct. You can to this with ``terminal.capture()``, for example:
 
 .. code-block:: python
 
-    with test_util.capture_sys_output() as (_, stderr):
+    with terminal.capture() as (_, stderr):
         self._DoTestFile('071_gbb.dts', force_missing_bintools='futility',
                          entry_args=entry_args)
     err = stderr.getvalue()
@@ -572,7 +572,7 @@ In the above example, here are some possible steps:
 
        def testNxpImx8ImageMkimageMissing(self):
            """Test that binman can produce an iMX8 image"""
-           with test_util.capture_sys_output() as (_, stderr):
+           with terminal.capture() as (_, stderr):
                self._DoTestFile('339_nxp_imx8.dts',
                                 force_missing_bintools='mkimage')
            err = stderr.getvalue()

doc/develop/bootstd/index.rst

@@ -12,5 +12,6 @@ Standard Boot
    qfw
    android
    cros
+   rauc
    script
    sandbox

doc/develop/bootstd/overview.rst

@@ -443,6 +443,7 @@ Bootmeth drivers are provided for booting from various media:
    - :doc:`extlinux / syslinux <extlinux>` boot from a storage device
    - :doc:`extlinux / syslinux <extlinux>` boot from a network (PXE)
    - :doc:`sandbox <sandbox>` used only for testing
+   - :doc:`RAUC distro <rauc>`: A/B system with RAUC from MMC
    - :doc:`U-Boot scripts <script>` from disk, network or SPI flash
    - :doc:`QFW <qfw>`: QEMU firmware interface
    - :doc:`VBE </develop/vbe>`: Verified Boot for Embedded

doc/develop/bootstd/rauc.rst

@@ -0,0 +1,56 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+RAUC Bootmeth
+=============
+
+This bootmeth provides a way to locate and run an A/B system with RAUC as its
+update client. The booted distro must supply a script on an MMC device
+containing the final boot instructions necessary.
+
+This bootmeth assumes a symmetric A/B partition layout, with a separate boot
+partition containing the kernel image and another partition for the root
+filesystem each. The partition numbers must be specified with
+``CONFIG_BOOTMETH_RAUC_PARTITIONS``. The content must be a list of pairs, with
+the following syntax: ``1,2 3,4``, where 1 and 3 are the slots' boot partition
+and 2 and 4 the slots' root partition.
+
+Each pair of boot and rootfs partition form a "slot". The default order in which
+available slots are tried is set through ``CONFIG_BOOTMETH_RAUC_BOOT_ORDER``,
+with the left one tried first.
+
+The default number of boot tries of each slot is set by
+``CONFIG_BOOTMETH_RAUC_DEFAULT_TRIES``.
+
+In case no valid slot can be found and/or all slots have zero tries left, the
+boot order and slot tries are reset to their default values, if
+``CONFIG_BOOTMETH_RAUC_RESET_ALL_ZERO_TRIES`` is enabled. This prevents a system
+from locking up in the bootloader and tries booting again after a specified
+number of tries.
+
+The boot script must be located in each boot partition. The bootmeth searches
+for "boot.scr.uimg" first, then "boot.scr" if not found.
+
+When the bootflow is booted, the bootmeth sets these environment variables:
+
+devtype
+    device type (e.g. "mmc")
+
+devnum
+    device number, corresponding to the device 'sequence' number
+    ``dev_seq(dev)``
+
+distro_bootpart
+    partition number of the boot partition on the device (numbered from 1)
+
+distro_rootpart
+    partition number of the rootfs partition on the device (numbered from 1)
+
+raucargs
+    kernel command line arguments needed for RAUC to detect the currently booted
+    slot
+
+The script file must be a FIT or a legacy uImage. It is loaded into memory and
+executed.
+
+The compatible string "u-boot,distro-rauc" is used for the driver. It is present
+if ``CONFIG_BOOTMETH_RAUC`` is enabled.

doc/develop/expo.rst

@@ -65,6 +65,8 @@ item is highlighted.
 
 A `textline object` contains a label and an editable string.
 
+A `box object` is a rectangle with a given line width. It is not filled.
+
 All components have a name. This is mostly for debugging, so it is easy to see
 what object is referred to, although the name is also used for saving values.
 Of course the ID numbers can help as well, but they are less easy to
@@ -105,6 +107,37 @@ refer to objects which have been created. So a menu item is just a collection
 of IDs of text and image objects. When adding a menu item you must create these
 objects first, then create the menu item, passing in the relevant IDs.
 
+Position and alignment
+~~~~~~~~~~~~~~~~~~~~~~
+
+Objects are typically positioned automatically, when scene_arrange() is called.
+However it is possible to position objects manually. The scene_obj_set_pos()
+sets the coordinates of the top left of the object.
+
+All objects have a bounding box. Typically this is calculated by looking at the
+object contents, in `scene_calc_arrange()`. The calculated dimensions of each
+object are stored in the object's `dims` field.
+
+It is possible to adjust the size of an object with `scene_obj_set_size()` or
+even set the bounding box, with `scene_obj_set_bbox()`. The `SCENEOF_SIZE_VALID`
+flag tracks whether the width/height should be maintained when the position
+changes.
+
+If the bounding box is larger than the object needs, the object can be aligned
+to different edges within the box. Objects can be left- or right-aligned,
+or centred. For text objects this applies to each line of text. Normally objects
+are drawn starting at the top of their bounding box, but they can be aligned
+vertically to the bottom, or centred vertically within the box.
+
+Where the width of a text object's bounding box is smaller than the space needed
+to show the next, the text is word-wrapped onto multiple lines, assuming there
+is enough vertical space. Newline characters in the next cause a new line to be
+started. The measurement information is created by the Truetype console driver
+and stored in an alist in `struct scene_txt_generic`.
+
+When the object is drawn the `ofs` field indicates the x and y offset to use,
+from the top left of the bounding box. These values are affected by alignment.
+
 Creating an expo
 ----------------
 
@@ -527,6 +560,7 @@ Future ideas
 Some ideas for future work:
 
 - Default menu item and a timeout
+- Complete the text editor
 - Image formats other than BMP
 - Use of ANSI sequences to control a serial terminal
 - Colour selection

doc/develop/index.rst

@@ -46,6 +46,7 @@ Implementation
    cedit
    event
    global_data
+   lmb
    logging
    makefiles
    menus

doc/develop/lmb.rst

@@ -0,0 +1,166 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Logical Memory Blocks (LMB)
+===========================
+
+U-Boot has support for reserving chunks of memory which is primarily
+used for loading images to the DRAM memory, before these are booted,
+or written to non-volatile storage medium. This functionality is
+provided through the Logical Memory Blocks (LMB) module.
+
+Introduction
+------------
+
+The LMB module manages allocation requests for memory region not
+occupied by the U-Boot image. Allocation requests that are made
+through malloc() and similar functions result in memory getting
+allocated from the heap region, which is part of the U-Boot
+image. Typically, the heap memory is a few MiB in size. Loading an
+image like the linux kernel might require lot more memory than what
+the heap can provide. Such allocations are usually handled through the
+LMB module.
+
+The U-Boot image typically gets relocated to the top of the usable
+DRAM memory region. A typical memory layout looks as follows::
+
+
+
+
+
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+       ---            +--------------+  <--- U-Boot ram top
+        |             |              |
+        |             |    Text      |
+        |             +--------------+
+        |             |              |
+        |             |    Data      |
+        |             +--------------+
+        |             |              |
+        |             |    BSS       |
+  U-Boot Image        +--------------+
+        |             |              |
+        |             |    Heap      |
+        |             |              |
+        |             +--------------+
+        |             |              |
+        |             |              |
+        |             |    Stack     |
+        |             |              |
+        |             |              |
+       ---            +--------------+
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      |              |
+                      +--------------+  <--- ram start
+
+
+
+The region of memory below the U-Boot image is the one controlled by
+the LMB module.
+
+
+Types of LMB Allocations
+------------------------
+
+There are two classes of allocation requests that get made to the LMB
+module. One type of allocation requests are requesting memory of a
+particular number of bytes. This type of allocation is similar to that
+done using the malloc type of function calls. The other type of
+allocations, are requests made for a specific memory address. The
+second type of allocations are usually made for loading images to a
+particular memory address.
+
+
+LMB design Pre 2025.01
+----------------------
+
+The earlier versions of U-Boot (pre 2025.01 release)
+had a local memory map based LMB implementation whereby it was
+possible to declare the LMB map inside a function or a C file. This
+design resulted in temporary, non-global LMB maps, which also allowed
+for re-use of memory. This meant that it was possible to use a region
+of memory to load some image, and subsequently the same region of
+memory could be used for loading a different image. A typical example
+of this usage would be loading an image to a memory address, followed
+by writing that image to some non-volatile storage medium. Once this
+is done, the same address can be used for loading a different image
+and then writing it to it's non-volatile storage
+destination. Typically, environment variables like `loadaddr`,
+`kernel_addr_r`, `ramdisk_addr_r` are used for loading images to
+memory regions.
+
+
+Current LMB implementation
+--------------------------
+
+Changes were made in the 2025.01 release to make the LMB memory map
+global and persistent. With this, the LMB memory map is the same
+across all of U-Boot, and also persists as long as U-Boot is
+active. Even with this change, there has been consistency as far as
+re-use of memory is concerned to maintain backward compatibility. It
+is allowed for re-requesting the same region of memory if the memory
+region has a particular attribute (LMB_NONE).
+
+As part of the platform boot, DRAM memory available for use in U-Boot
+gets added to the LMB memory map. Any allocation requests made
+subsequently will be made from this memory added as part of the board
+init.
+
+
+Allocation API
+--------------
+
+Any request for non-heap memory can be made through the LMB allocation
+API.
+
+.. code-block:: c
+
+	int lmb_alloc_mem(enum lmb_mem_type type, u64 align,
+			  phys_addr_t *addr, phys_size_t size,
+			  u32 flags);
+
+Correspondingly, the allocated memory can be free'd
+
+.. code-block:: c
+
+	long lmb_free(phys_addr_t base, phys_size_t size, u32 flags);
+
+For a detailed API description, please refer to the header file.
+
+
+UEFI allocations with LMB as the backend
+----------------------------------------
+
+The UEFI specification describes boot-time API's for allocation of
+memory. These API's use the same memory that is being used by the LMB
+module. Pre 2025.01 release, there wasn't any synchronisation between
+the EFI sub-system and the LMB module about the memory that was
+getting allocated by each of these modules. This was the primary
+reason for making the LMB memory map global and persistent. With this
+change, the EFI memory allocation API's have also been changed to use
+the LMB module as the backend for the allocation requests. Any other
+sub-system which might wish to use the same memory region for it's use
+can then use the LMB as the backend for the memory allocations and
+it's associated book-keeping.
+
+
+API documentation
+-----------------
+
+.. kernel-doc:: include/lmb.h
+

doc/develop/makefiles.rst

@@ -1430,10 +1430,13 @@ When kbuild executes, the following steps are followed (roughly):
 	A central rule exists to create `$(obj)/%.dtb` from `$(src)/%.dts`;
 	architecture Makefiles do no need to explicitly write out that rule.
 
+        The device tree can now be padded by the specified number of bytes
+        by setting CONFIG_SYS_DTC_PAD_BYTES instead of explicitly setting
+        DTC_FLAGS with the -p option.
+
 	Example::
 
 		targets += $(dtb-y)
-		DTC_FLAGS ?= -p 1024
 
 7.9 Preprocessing linker scripts
 --------------------------------