Merge tag 'v2023.10-rc3' into next

Prepare v2023.10-rc3

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

6 files changed, 36 insertions, 9 deletions

diff --git a/doc/develop/board_best_practices.rst b/doc/develop/board_best_practices.rst
new file mode 100644
index 0000000000..f44401eab7
--- /dev/null
+++ b/doc/develop/board_best_practices.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+Best Practices for Board Ports
+==============================
+
+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
+  supported by the platform.
+
+* The platform defconfig file must be generated via `make savedefconfig`.
+
+* The Kconfig and Kbuild infrastructure supports using "fragments" that can be
+  used to apply changes on top of a defconfig file. These can be useful for
+  many things such as:
+
+  * Supporting different firmware locations (e.g. eMMC, SD, QSPI).
+
+  * Multiple board variants when runtime detection is not desired.
+
+  * Supporting different build types such as production and development.
+
+  Kconfig fragments should reside in the board directory itself rather than in
+  the top-level `configs/` directory.
diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst
index 7a2a69fdfc..ec31365357 100644
--- a/doc/develop/bootstd.rst
+++ b/doc/develop/bootstd.rst
@@ -306,7 +306,7 @@ media device::
 
 The bootdev device is typically created automatically in the media uclass'
 `post_bind()` method by calling `bootdev_setup_for_dev()` or
-`bootdev_setup_sibling_blk()`. The code typically something like this::
+`bootdev_setup_for_sibling_blk()`. The code typically something like this::
 
     /* dev is the Ethernet device */
     ret = bootdev_setup_for_dev(dev, "eth_bootdev");
@@ -316,7 +316,7 @@ The bootdev device is typically created automatically in the media uclass'
 or::
 
     /* blk is the block device (child of MMC device)
-    ret = bootdev_setup_sibling_blk(blk, "mmc_bootdev");
+    ret = bootdev_setup_for_sibling_blk(blk, "mmc_bootdev");
     if (ret)
         return log_msg_ret("bootdev", ret);
 
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 263d404b4c..5b230d0321 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -9,6 +9,7 @@ General
 .. toctree::
    :maxdepth: 1
 
+   board_best_practices
    codingstyle
    designprinciples
    docstyle
diff --git a/doc/develop/printf.rst b/doc/develop/printf.rst
index 7b9aea0687..99d05061b1 100644
--- a/doc/develop/printf.rst
+++ b/doc/develop/printf.rst
@@ -105,19 +105,19 @@ for the individual integer types.
 =================== ==================
 Type                Format specifier
 =================== ==================
-bool		    %d, %x
+bool                %d, %x
 char                %d, %x
 unsigned char       %u, %x
 short               %d, %x
 unsigned short      %u, %x
 int                 %d, %x
-unsigned int        %d, %x
+unsigned int        %u, %x
 long                %ld, %lx
 unsigned long       %lu, %lx
 long long           %lld, %llx
 unsigned long long  %llu, %llx
 off_t               %llu, %llx
-ptr_diff_t	    %td, %tx
+ptr_diff_t          %td, %tx
 fdt_addr_t          %pa, see pointers
 fdt_size_t          %pa, see pointers
 phys_addr_t         %pa, see pointers
diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
index 752e1304d3..50d33df421 100644
--- a/doc/develop/release_cycle.rst
+++ b/doc/develop/release_cycle.rst
@@ -68,7 +68,7 @@ For the next scheduled release, release candidates were made on::
 
 * U-Boot v2023.10-rc2 was released on Mon 07 August 2023.
 
-.. * U-Boot v2023.10-rc3 was released on Mon 21 August 2023.
+* U-Boot v2023.10-rc3 was released on Mon 21 August 2023.
 
 .. * U-Boot v2023.10-rc4 was released on Mon 04 September 2023.
 
diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst
index 9bbe1345d2..546862020b 100644
--- a/doc/develop/trace.rst
+++ b/doc/develop/trace.rst
@@ -139,7 +139,7 @@ There is a -f option available to select a function graph:
 
 .. code-block:: console
 
-    $ ./sandbox/tools/proftool -m sandbox/System.map -t trace -f funcgraph dump-ftrace >trace.dat
+    $ ./sandbox/tools/proftool -m sandbox/System.map -t trace -f funcgraph dump-ftrace -o trace.dat
 
 Again, you can use kernelshark or trace-cmd to look at the output. In this case
 you will see the time taken by each function shown against its exit record.
@@ -171,7 +171,7 @@ command:
 
 .. code-block:: console
 
-    $ ./sandbox/tools/proftool -m sandbox/System.map -t trace dump-flamegraph >trace.fg
+    $ ./sandbox/tools/proftool -m sandbox/System.map -t trace dump-flamegraph -o trace.fg
     $ flamegraph.pl trace.fg >trace.svg
 
 You can load the .svg file into a viewer. If you use Chrome (and some other
@@ -191,7 +191,7 @@ spend in each call stack:
 
 .. code-block:: console
 
-    $ ./sandbox/tools/proftool -m sandbox/System.map -t trace dump-flamegraph -f timing >trace.fg
+    $ ./sandbox/tools/proftool -m sandbox/System.map -t trace dump-flamegraph -f timing -o trace.fg
     $ flamegraph.pl trace.fg >trace.svg
 
 Note that trace collection does slow down execution so the timings will be