date:20240612

With Labgrid we don't need to specify the various methods, except for
the console, which simply calls labgrid-client.

This allows supporting any boards in your lab, without adding per-board
configuration to these hooks.

Provide ellesmere files as an example.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Make use of the common script (only) to set bin_dir

 README.md| 33 
 bin/console.labgrid  | 42 
 bin/ellesmere/common-labgrid | 31 ++
 bin/ellesmere/conf.all   | 24 +
 bin/getrole.labgrid  | 25 +
 bin/release.labgrid  | 22 +++
 bin/release.none | 22 +++
 bin/u-boot-test-common   |  6 +-
 bin/u-boot-test-getrole  | 38 
 bin/u-boot-test-release  | 26 ++
 10 files changed, 268 insertions(+), 1 deletion(-)
 create mode 100644 bin/console.labgrid
 create mode 100755 bin/ellesmere/common-labgrid
 create mode 100644 bin/ellesmere/conf.all
 create mode 100644 bin/getrole.labgrid
 create mode 100644 bin/release.labgrid
 create mode 100644 bin/release.none
 create mode 100755 bin/u-boot-test-getrole
 create mode 100755 bin/u-boot-test-release

diff --git a/README.md b/README.md
index 290e4d0..660ffe2 100644
--- a/README.md
+++ b/README.md
@@ -199,6 +199,39 @@ scripts must be replicated once per board instance, or 
their actions somehow
 serialized, since they copy files into their own directories when executing, 
and
 hence parallel execution would cause incorrect operation.
 
+## Labgrid Integration
+
+Labgrid is a python library for embedded-board-control. It includes a client
+program which is used to integrate with the U-Boot pytests.
+
+Since Labgrid has all the information necessary to build and boot on a lab,
+there is no per-board configuration required. The various flash.xxx and
+recovery.xxx scripts are not used. To set it up:
+
+- In your bin/$hostname directory, create `common-labgrid` and set your 
crossbar
+  and environment information, for example:
+
+  export LG_CROSSBAR="ws://kea:20408/ws"
+  export LG_ENV="/vid/software/devel/ubtest/lab/env_rpi_try.cfg"
+
+  flash_impl=none
+  reset_impl=none
+  console_impl=labgrid
+  release_impl=labgrid
+  getrole_impl=labgrid
+
+The last five lines tell the hooks to use Labgrid for console and board release
+as well as a new 'getrole' hook which is only used by Labgrid. The flash and
+reset of boards is handled by entirely by Labgrid.
+
+Then create another file (in the same directory) called 'conf.all', 
containing::
+
+.. code-block:: bash
+
+. "${bin_dir}/${hostname}/common-labgrid"
+
+That should be all that is needed.
+
 ## Dependencies
 
 The example scripts depend on various external tools, the installation location
diff --git a/bin/console.labgrid b/bin/console.labgrid
new file mode 100644
index 000..9ce586f
--- /dev/null
+++ b/bin/console.labgrid
@@ -0,0 +1,42 @@
+# Copyright (c) 2024 Google LLC
+# Written by Simon Glass
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+# The variables here can come from one of two places:
+#
+# 1. When using the ub-xxx scripts (e.g. ub-int) they come from those scripts,
+#set by the get_args.sh script
+#
+# 2. When running from gitlab, the variables are all empty and so take the
+#default values below, except for ${strategy} which is set in the gitlab
+#script
+
+# On input:
+# strategy: Strategy arguments to use, e.g. "-s start". Normally this is
+# "-s uboot -e off" but it can be "-s start -e off" or even empty
+# verbose: Verbose argument to use, e.g. "-v"
+#
+# These variables are set by .gitlab-ci.yml or by
+
+exec labgrid-client -V do-bootstrap ${bootstrap:-1} -V do-build ${build:-1} \
+-V do-send ${send:-0} -V do-clean ${clean:-0} \
+-V process-limit ${

[u-boot-test-hooks PATCH v2 1/2] Create a common file for test scripts

The top part of each of the u-boot-test-* files is common. Put it in
a common script file to avoid duplication and to allow it to be
replaced for the Labgrid integration.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Make use of the common script (only) to set bin_dir

 bin/u-boot-test-common| 31 +++
 bin/u-boot-test-console   |  8 +---
 bin/u-boot-test-flash |  8 +---
 bin/u-boot-test-power-off |  8 +---
 bin/u-boot-test-power-on  |  8 +---
 bin/u-boot-test-reset |  8 +---
 6 files changed, 36 insertions(+), 35 deletions(-)
 create mode 100755 bin/u-boot-test-common

diff --git a/bin/u-boot-test-common b/bin/u-boot-test-common
new file mode 100755
index 000..fa3ad88
--- /dev/null
+++ b/bin/u-boot-test-common
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+# Copyright Google LLC
+# Written by Simon Glass 
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+set -e
+
+bin_dir="`dirname $0`"
+board_type="$1"
+board_ident="$2"
+hostname="`hostname`"
+
+. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
diff --git a/bin/u-boot-test-console b/bin/u-boot-test-console
index 0b6b4ac..8b7377a 100755
--- a/bin/u-boot-test-console
+++ b/bin/u-boot-test-console
@@ -20,12 +20,6 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
 
-set -e
-
-bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "$(dirname $0)/u-boot-test-common"
 
 . "${bin_dir}/console.${console_impl:-picocom}"
diff --git a/bin/u-boot-test-flash b/bin/u-boot-test-flash
index 8dcf198..bd89a50 100755
--- a/bin/u-boot-test-flash
+++ b/bin/u-boot-test-flash
@@ -20,12 +20,6 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
 
-set -e
-
-bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "$(dirname $0)/u-boot-test-common"
 
 . "${bin_dir}/flash.${flash_impl}"
diff --git a/bin/u-boot-test-power-off b/bin/u-boot-test-power-off
index b59436a..83b69c0 100755
--- a/bin/u-boot-test-power-off
+++ b/bin/u-boot-test-power-off
@@ -20,12 +20,6 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
 
-set -e
-
-bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "$(dirname $0)/u-boot-test-common"
 
 . "${bin_dir}/poweroff.${power_impl}"
diff --git a/bin/u-boot-test-power-on b/bin/u-boot-test-power-on
index ca87477..5a41c3e 100755
--- a/bin/u-boot-test-power-on
+++ b/bin/u-boot-test-power-on
@@ -20,12 +20,6 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
 
-set -e
-
-bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "$(dirname $0)/u-boot-test-common"
 
 . "${bin_dir}/poweron.${power_impl}"
diff --git a/bin/u-boot-test-reset b/bin/u-boot-test-reset
index a160e0c..77e3f40 100755
--- a/bin/u-boot-test-reset
+++ b/bin/u-boot-test-reset
@@ -20,12 +20,6 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
 
-set -e
-
-bin_dir="`dirname $0`"
-board_type="$1"
-board_ident="$2"
-hostname="`hostname`"
-. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
+. "$(dirname $0)/u-boot-test-common"
 
 . "${bin_dir}/reset.${reset_impl}"
-- 
2.34.1

[u-boot-test-hooks PATCH v2 0/2] Add support for Labgrid

This adds hooks for use with Labgrid. The only existing hook that really
does anything now is the 'console' one. There is also a new 'getrole'
hook which looks up a role to find various things about it, such as the
U-Boot board name.

Changes in v2:
- Make use of the common script (only) to set bin_dir
- Make use of the common script (only) to set bin_dir

Simon Glass (2):
  Create a common file for test scripts
  Provide some basic scripts for Labgrid integration

 README.md| 33 
 bin/console.labgrid  | 42 
 bin/ellesmere/common-labgrid | 31 ++
 bin/ellesmere/conf.all   | 24 +
 bin/getrole.labgrid  | 25 +
 bin/release.labgrid  | 22 +++
 bin/release.none | 22 +++
 bin/u-boot-test-common   | 35 ++
 bin/u-boot-test-console  |  8 +--
 bin/u-boot-test-flash|  8 +--
 bin/u-boot-test-getrole  | 38 
 bin/u-boot-test-power-off|  8 +--
 bin/u-boot-test-power-on |  8 +--
 bin/u-boot-test-release  | 26 ++
 bin/u-boot-test-reset|  8 +--
 15 files changed, 303 insertions(+), 35 deletions(-)
 create mode 100644 bin/console.labgrid
 create mode 100755 bin/ellesmere/common-labgrid
 create mode 100644 bin/ellesmere/conf.all
 create mode 100644 bin/getrole.labgrid
 create mode 100644 bin/release.labgrid
 create mode 100644 bin/release.none
 create mode 100755 bin/u-boot-test-common
 create mode 100755 bin/u-boot-test-getrole
 create mode 100755 bin/u-boot-test-release

-- 
2.34.1

Re: Where to put DTB file for UEFI support on ARM

2024-06-12 Thread Leith Bade

Hi E Shattow,

Thanks for the quick response.

On Thu, 13 Jun 2024 at 01:12, E Shattow  wrote:

>
> Correct, this is a limitation and the fix is not yet released with
> U-Boot;  It is now queued up for U-Boot -next, but only for EFI
> bootmanager (not the global EFI boot).
>

Do you have a link to the relevant commit/patches for me to try?


>
> >
> > What is the correct location for the .dtb file when using UEFI?
>
> In theory you could just load it from the target Linux OS root
> filesystem at /usr/lib/linux-image-... but when I try this there's no
> support to read that filesystem within EFI bootmanager;  the files
> referenced by EFI bootmanager are however accessible if on the EFI
> System Partition. Perhaps I am missing some option to support loading
> from partitions other than the EFI System Partition but I don't know
> how.
>

That is actually a useful suggestion. With the Ubuntu I have booting the
ESP is mounted at /boot/efi so it should be possible to get it to place the
DTB files on the FAT partition. However I don't think this will work with
the "off the shelf" USB Ubuntu/Debian installer images as I think the DTBs
are only in the rootfs not the ESP.


>
> >
> > Is there a recommended way of putting the kernel DTB into the NAND or NOR
> > chip when using UEFI? That way if the SD card gets wiped U-boot can still
> > boot the USB drive. I don't fully understand how the MTD partitions, FIT
> > files, UBI files all fit into the picture to have U-boot load the kernel
> > DTB from flash.
>
> U-Boot has its own internal FDT (firmware devicetree) which you note
> may or may not work well enough to boot Linux kernel and have a
> working OS userspace. It is ambiguous if a Linux OS kernel dtb of a
> specific board hardware target belongs in any of NAND or NOR flash
> since they tend to be tied to specific versions of the Linux kernel,
> as things are today. There's no consensus that I've read anywhere on
> how this should be done - again not specific to U-Boot.
>
> I can just say from experience that if it would be able to be loaded
> from the same rootfs that the Linux kernel resides then there is still
> the trouble of not knowing which exact Linux kernel version that the
> user will decide to load that boot cycle.
>

This does seem like a sensible idea as the DTS files do seem to be very
specific to the kernels/drivers they are built against, which is noticeable
when comparing the DTS files from the Mediatek SDK or OpenWRT to the
in-tree Linux file. I guess in the x86 world with ACPI things are far more
standardised.

The reason I had thought about bundling the DTS with the boot loader was
due to my familiarity of that x86 way of thinking where one firmware image
can boot multiple OS no problem.

I did some more reading up on FIT files and realised that it provides a way
to tell U-boot where to load the files. I wonder if it can be used for just
loading the device tree (and potentially any overlays) to the right place
for the EFI boot manager to find it.

So it seems like these are my potential options:
- put DTB file on EFS FAT partition - needs U-boot next patches and might
not work with USB installer stick, but should work once OS is installed.
However I am not sure if the partition should be pre-provisioned or if the
Ubuntu/Debian installers will reformat the partition or leave it alone.
- get U-boot EFI manager to read DTB file from rootfs or add script to do
that - might work with USB installer stick if this board's DTB is included
- put DTB file somewhere else and possibly use FIT to auto-load it. It
could be placed in NOR/NAND chip if that is used to boot, or maybe even one
of the eMMC boot partitions so that it is safe from installer reformatting

Thanks, Leith

On Thu, 13 Jun 2024 at 01:12, E Shattow  wrote:

> Hi Leith,
>
> On Wed, Jun 12, 2024 at 5:50 AM Leith Bade  wrote:
> >
> > Hi all,
> >
> > I have a BananaPi BPI-R3 board that I am setting up to boot Ubuntu or
> > Debian. After figuring out the required config options I have managed to
> > get Uboot to boot the Ubuntu USB installer, and also boot off an SD card
> > once I installed Ubuntu there.
> >
> > I set up the bootmeth/bootdev/bootflow stuff so that the auto boot menu
> > works nicely with SD card. For USB I have to drop to console and do
> manual
> > "usb start" etc, but good enough for running the installer. It was a bit
> > difficult as there seems to be a lot of older documentation or Google
> > results related to using UEFI before the bootflow stuff was added. Also
> it
> > took me a while to figure out that a board/mediatek/mt7986.env file is
> now
> > needed as some of the config options set #define values that are not
> > included in /include/configs/mt7986.h board headers - due to .env files
> > replacing those #defines. It would be nice to have a default .env file
> for
> > this board that sets sensible defaults for the various memory loading
> > addresses as it took a bit of effort to come up with all the hex values.

Re: [PATCH 00/42] labgrid: Provide an integration with Labgrid

Hi Tom,

On Wed, 12 Jun 2024 at 10:03, Tom Rini  wrote:
>
> On Wed, Jun 12, 2024 at 09:08:32AM +0300, Ilias Apalodimas wrote:
> > Hi Simon
> >
> > On Tue, 11 Jun 2024 at 23:02, Simon Glass  wrote:
> > >
> > > Labgrid provides access to a hardware lab in an automated way. It is
> > > possible to boot U-Boot on boards in the lab without physically touching
> > > them. It relies on relays, USB UARTs and SD muxes, among other things.
> > >
> > > By way of background, about 4 years ago I wrong a thing called Labman[1]
> > > which allowed my lab of about 30 devices to be operated remotely, using
> > > tbot for the console and build integration. While it worked OK and I
> > > used it for many bisects, I didn't take it any further.
> > >
> > > It turns out that there was already an existing program, called Labgrid,
> > > which I did not know about at time (thank you Tom for telling me). It is
> > > more rounded than Labman and has a number of advantages:
> > >
> > > - does not need udev rules, mostly
> > > - has several existing users who rely on it
> > > - supports multiple machines exporting their devices
> > >
> > > It lacks a 'lab check' feature and a few other things, but these can be
> > > remedied.
> > >
> > > On and off over the past several weeks I have been experimenting with
> > > Labgrid. I have managed to create an initial U-Boot integration (this
> > > series) by adding various features to Labgrid[2] and the U-Boot test
> > > hooks.
> > >
> > > I hope that this might inspire others to set up boards and run tests
> > > automatically, rather than relying on infrequent, manual test. Perhaps
> > > it may even be possible to have a number of labs available.
> > >
> > > Included in the integration are a number of simple scripts which make it
> > > easy to connect to boards and run tests:
> > >
> > > ub-int 
> > > Build and boot on a target, starting an interactive session
> > >
> > > ub-cli 
> > > Build and boot on a target, ensure U-Boot starts and provide an 
> > > interactive
> > > session from there
> > >
> > > ub-smoke 
> > > Smoke test U-Boot to check that it boots to a prompt on a target
> > >
> > > ub-bisect
> > > Bisect a git tree to locate a failure on a particular target
> > >
> > > ub-pyt  
> > > Run U-Boot pytests on a target
> > >
> > > Some of these help to provide the same tbot[4] workflow which I have
> > > relied on for several years, albeit much simpler versions.
> > >
> > > The goal here is to create some sort of script which can collect
> > > patches from the mailing list, apply them and test them on a selection
> > > of boards. I suspect that script already exists, so please let me know
> > > what you suggest.
> > >
> > > I hope you find this interesting and take a look!
> >
> > Thanks this is interesting!
> > I only got cc'ed on the cover letter and I'll slowly have a look on
> > the rest. A naive question -- I saw you did integrate this on gitlab
> > with your internal lab. How secure is this? Could we schedule weekly
> > builds that run on various remote labs and get results on actual
> > hardware? Or do we have to rely on users for that ?
>
> That's where this certainly gets a little tricky. Ideally, and part of
> why I've been hoping to get Labgrid going with our pytest suite, since
> it's good enough for kernelci (and people to be reasonably confident
> about allowing not-exactly-random-user-access), it should be good enough
> for us too. So my long term hope is that we can:
> - Have Labgrid based labs + something know to monitor trees+branches at
>   X location (like I know today some people poll and test my WIP
>   branches).
> - Have it be reasonably clear that if you maintain a lab for kernelci,
>   you can add testing U-Boot in too.
>
> In the medium term, I am hopeful we can at least expose this to all
> custodian trees on source.denx.de. And I'm saying "we" here as I have
> two much smaller labs also going, one with Labgrid, and both a much
> smaller set of targets currently.

That sounds good to me.

Regards,
Simon

Re: [PATCH 00/42] labgrid: Provide an integration with Labgrid

Hi Ilias,

On Wed, 12 Jun 2024 at 00:09, Ilias Apalodimas
 wrote:
>
> Hi Simon
>
> On Tue, 11 Jun 2024 at 23:02, Simon Glass  wrote:
> >
> > Labgrid provides access to a hardware lab in an automated way. It is
> > possible to boot U-Boot on boards in the lab without physically touching
> > them. It relies on relays, USB UARTs and SD muxes, among other things.
> >
> > By way of background, about 4 years ago I wrong a thing called Labman[1]
> > which allowed my lab of about 30 devices to be operated remotely, using
> > tbot for the console and build integration. While it worked OK and I
> > used it for many bisects, I didn't take it any further.
> >
> > It turns out that there was already an existing program, called Labgrid,
> > which I did not know about at time (thank you Tom for telling me). It is
> > more rounded than Labman and has a number of advantages:
> >
> > - does not need udev rules, mostly
> > - has several existing users who rely on it
> > - supports multiple machines exporting their devices
> >
> > It lacks a 'lab check' feature and a few other things, but these can be
> > remedied.
> >
> > On and off over the past several weeks I have been experimenting with
> > Labgrid. I have managed to create an initial U-Boot integration (this
> > series) by adding various features to Labgrid[2] and the U-Boot test
> > hooks.
> >
> > I hope that this might inspire others to set up boards and run tests
> > automatically, rather than relying on infrequent, manual test. Perhaps
> > it may even be possible to have a number of labs available.
> >
> > Included in the integration are a number of simple scripts which make it
> > easy to connect to boards and run tests:
> >
> > ub-int 
> > Build and boot on a target, starting an interactive session
> >
> > ub-cli 
> > Build and boot on a target, ensure U-Boot starts and provide an 
> > interactive
> > session from there
> >
> > ub-smoke 
> > Smoke test U-Boot to check that it boots to a prompt on a target
> >
> > ub-bisect
> > Bisect a git tree to locate a failure on a particular target
> >
> > ub-pyt  
> > Run U-Boot pytests on a target
> >
> > Some of these help to provide the same tbot[4] workflow which I have
> > relied on for several years, albeit much simpler versions.
> >
> > The goal here is to create some sort of script which can collect
> > patches from the mailing list, apply them and test them on a selection
> > of boards. I suspect that script already exists, so please let me know
> > what you suggest.
> >
> > I hope you find this interesting and take a look!
>
> Thanks this is interesting!

Thanks!

> I only got cc'ed on the cover letter and I'll slowly have a look on
> the rest. A naive question -- I saw you did integrate this on gitlab
> with your internal lab. How secure is this? Could we schedule weekly
> builds that run on various remote labs and get results on actual
> hardware? Or do we have to rely on users for that ?

I believe this could be done. My understanding is that any custodian
can push to a tree which runs on all available runners.

If you have any ideas on the script I mentioned, let me know!

Regards,
Simon


>
> Thanks
> /Ilias
>
> >
> > [1] https://github.com/sjg20/u-boot/tree/lab6a
> > [2] https://github.com/labgrid-project/labgrid/pull/1411
> > [3] https://github.com/sjg20/uboot-test-hooks/tree/labgrid
> > [4] https://tbot.tools/index.html
> >
> >
> > Simon Glass (42):
> >   trace: Update test to tolerate different trace-cmd version
> >   binman: efi: Correct entry docs
> >   binman: Regenerate nxp docs
> >   binman: ti: Regenerate entry docs
> >   binman: Update the entrydocs header
> >   buildman: Make mrproper an argument to _reconfigure()
> >   buildman: Make mrproper an argument to _config_and_build()
> >   buildman: Make mrproper an argument to run_commit()
> >   buildman: Avoid rebuilding when --mrproper is used
> >   buildman: Add a flag to force mrproper on failure
> >   buildman: Retry the build for current source
> >   buildman: Add a way to limit the number of buildmans
> >   dm: core: Enhance comments on bind_drivers_pass()
> >   initcall: Correct use of relocation offset
> >   am33xx: Provide a function to set up the debug UART
> >   sunxi: Mark scp as optional
> >   google: Disable TPMv2 on most Chromebooks
> >   meson: Correct driver declaration for meson_axg_gpio
> >   test: Allow signaling that U-Boot is ready
> >   test: Make bootstd init run only on sandbox
> >   test: Use a constant for the test timeout
> >   test: Pass stderr to stdout
> >   test: Release board after tests complete
> >   log: Allow tests to pass with CONFIG_LOGF_FUNC_PAD set
> >   test: Allow connecting to a running board
> >   test: Decode exceptions only with sandbox
> >   test: Avoid failing skipped tests
> >   test: dm: Show failing driver name
> >   test: Check help output
> >   test: Create a common function to get the config
> >   test: Introduce the concept of a role
> >   test: Move the receive code into a

Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable

On Wed, Jun 12, 2024 at 02:24:25PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 12 Jun 2024 at 11:22, Tom Rini  wrote:
> >
> > On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote:
> >
> > [snip]
> > > Also IMO there is only really one LMB list today. We create it at the
> > > start of bootm and then it is done when we boot. The file-loading
> > > stuff is what makes all this confusing...and with bootstd that is
> > > under control as well.
> > >
> > > At lot of this effort seems to be about dealing with random scripts
> > > which load things. We want to make sure we complain if something
> > > overlaps. But we should be making the bootstd case work nicely and
> > > doing things within that framework. Also EFI sort-of has its own
> > > thing, which it is very-much in control of.
> > >
> > > Overall I think this is a bit more subtle that just combining allocators.
> >
> > I think this gets to the main misunderstanding. The problem isn't
> > handling bootstd, or EFI boot, or even assorted scripts. Those are all
> > cases where things are otherwise (sufficiently) well-defined. The
> > problem is "security" and that a "carefully crafted payload" could do
> > something malicious. That's why we have to do all of this stuff sooner
> > rather than later in our boot process.
> 
> That's the first I have heard of this, actually, but a bit more detail
> would help. How does the payload get loaded? I'm just not sure about
> the overall goals. It seems that everyone else is already familiar -
> can someone please take the time to point me to the details?

Well, the short version I believe of the first CVE we got (and so
started abusing LMB) was along the lines of "load an image near where
the U-Boot stack is, smash things for fun and exploits".

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map

Hi Heinrich,

On Wed, 12 Jun 2024 at 00:11, Heinrich Schuchardt  wrote:
>
>
>
> Am 12. Juni 2024 04:42:00 MESZ schrieb Simon Glass :
> >Hi Tom,
> >
> >On Tue, 11 Jun 2024 at 16:54, Tom Rini  wrote:
> >>
> >> On Tue, Jun 11, 2024 at 04:22:25PM -0600, Simon Glass wrote:
> >> > Hi Tom,
> >> >
> >> > On Tue, 11 Jun 2024 at 15:01, Tom Rini  wrote:
> >> > >
> >> > > On Tue, Jun 11, 2024 at 12:52:19PM -0600, Simon Glass wrote:
> >> > > > Hi,
> >> > > >
> >> > > > On Tue, 11 Jun 2024 at 08:36, Tom Rini  wrote:
> >> > > > >
> >> > > > > On Tue, Jun 11, 2024 at 12:17:16PM +0200, Heinrich Schuchardt 
> >> > > > > wrote:
> >> > > > > > On 07.06.24 20:52, Sughosh Ganu wrote:
> >> > > > > > > There are events that would be used to notify other interested 
> >> > > > > > > modules
> >> > > > > > > of any changes in available and occupied memory. This would 
> >> > > > > > > happen
> >> > > > > > > when a module allocates or reserves memory, or frees up 
> >> > > > > > > memory. These
> >> > > > > > > changes in memory map should be notified to other interested 
> >> > > > > > > modules
> >> > > > > > > so that the allocated memory does not get overwritten. Add an 
> >> > > > > > > event
> >> > > > > > > handler in the EFI memory module to update the EFI memory map
> >> > > > > > > accordingly when such changes happen. As a consequence, any 
> >> > > > > > > subsequent
> >> > > > > > > memory request would honour the updated memory map and only 
> >> > > > > > > available
> >> > > > > > > memory would be allocated from.
> >> > > > > > >
> >> > > > > > > Signed-off-by: Sughosh Ganu 
> >> > > > > > > ---
> >> > > > > > >   lib/efi_loader/efi_memory.c | 70 
> >> > > > > > > ++---
> >> > > > > > >   1 file changed, 58 insertions(+), 12 deletions(-)
> >> > > > > > >
> >> > > > > > > diff --git a/lib/efi_loader/efi_memory.c 
> >> > > > > > > b/lib/efi_loader/efi_memory.c
> >> > > > > > > index 435e580fb3..93244161b0 100644
> >> > > > > > > --- a/lib/efi_loader/efi_memory.c
> >> > > > > > > +++ b/lib/efi_loader/efi_memory.c
> >> > > > > > > @@ -73,6 +73,10 @@ struct efi_pool_allocation {
> >> > > > > > >   #if CONFIG_IS_ENABLED(MEM_MAP_UPDATE_NOTIFY)
> >> > > > > > >   extern bool is_addr_in_ram(uintptr_t addr);
> >> > > > > > >
> >> > > > > > > +static efi_status_t __efi_add_memory_map_pg(u64 start, u64 
> >> > > > > > > pages,
> >> > > > > > > +   int memory_type,
> >> > > > > > > +   bool overlap_only_ram);
> >> > > > > > > +
> >> > > > > > >   static void efi_map_update_notify(u64 addr, u64 size, u8 op)
> >> > > > > > >   {
> >> > > > > > > struct event_efi_mem_map_update efi_map = {0};
> >> > > > > > > @@ -84,6 +88,34 @@ static void efi_map_update_notify(u64 addr, 
> >> > > > > > > u64 size, u8 op)
> >> > > > > > > if (is_addr_in_ram((uintptr_t)addr))
> >> > > > > > > event_notify(EVT_EFI_MEM_MAP_UPDATE, &efi_map, 
> >> > > > > > > sizeof(efi_map));
> >> > > > > > >   }
> >> > > > > > > +
> >> > > > > > > +static int lmb_mem_map_update_sync(void *ctx, struct event 
> >> > > > > > > *event)
> >> > > > > > > +{
> >> > > > > > > +   u8 op;
> >> > > > > > > +   u64 addr;
> >> > > > > > > +   u64 pages;
> >> > > > > > > +   efi_status_t status;
> >> > > > > > > +   struct event_lmb_map_update *lmb_map = 
> >> > > > > > > &event->data.lmb_map;
> >> > > > > > > +
> >> > > > > > > +   addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
> >> > > > > > > +   pages = efi_size_in_pages(lmb_map->size + (addr & 
> >> > > > > > > EFI_PAGE_MASK));
> >> > > > > > > +   op = lmb_map->op;
> >> > > > > > > +   addr &= ~EFI_PAGE_MASK;
> >> > > > > > > +
> >> > > > > > > +   if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
> >> > > > > > > +   log_debug("Invalid map update op received (%d)\n", 
> >> > > > > > > op);
> >> > > > > > > +   return -1;
> >> > > > > > > +   }
> >> > > > > > > +
> >> > > > > > > +   status = __efi_add_memory_map_pg(addr, pages,
> >> > > > > > > +op == MAP_OP_FREE ?
> >> > > > > > > +EFI_CONVENTIONAL_MEMORY :
> >> > > > > >
> >> > > > > > This is dangerous. LMB might turn memory that is marked as
> >> > > > > > EfiReservedMemory which the OS must respect into 
> >> > > > > > EfiBootServicesData
> >> > > > > > which the OS may discard.
> >> > > > > >
> >> > > > > > E.g. initr_lmb() is being called after efi_memory_init().
> >> > > > > >
> >> > > > > > Getting all cases of synchronization properly tested seems very 
> >> > > > > > hard to
> >> > > > > > me. Everything would be much easier if we had only a single 
> >> > > > > > memory
> >> > > > > > management system.
> >> > > > >
> >> > > > > Yes, Sughosh is working on the single memory reservation system for
> >> > > > > everyone to use. This pairs with the single memory allocation 
> >> > > > > system
> >> > > > > (malloc) that we have. Parts of the code base that

Re: [RFC PATCH 15/31] efi_memory: add an event handler to update memory map

Hi Ilias,

On Tue, 11 Jun 2024 at 23:49, Ilias Apalodimas
 wrote:
>
> [...]
>
> > > > > > > > > +   struct event_lmb_map_update *lmb_map = 
> > > > > > > > > &event->data.lmb_map;
> > > > > > > > > +
> > > > > > > > > +   addr = (uintptr_t)map_sysmem(lmb_map->base, 0);
> > > > > > > > > +   pages = efi_size_in_pages(lmb_map->size + (addr & 
> > > > > > > > > EFI_PAGE_MASK));
> > > > > > > > > +   op = lmb_map->op;
> > > > > > > > > +   addr &= ~EFI_PAGE_MASK;
> > > > > > > > > +
> > > > > > > > > +   if (op != MAP_OP_RESERVE && op != MAP_OP_FREE) {
> > > > > > > > > +   log_debug("Invalid map update op received 
> > > > > > > > > (%d)\n", op);
> > > > > > > > > +   return -1;
> > > > > > > > > +   }
> > > > > > > > > +
> > > > > > > > > +   status = __efi_add_memory_map_pg(addr, pages,
> > > > > > > > > +op == MAP_OP_FREE ?
> > > > > > > > > +EFI_CONVENTIONAL_MEMORY :
> > > > > > > >
> > > > > > > > This is dangerous. LMB might turn memory that is marked as
> > > > > > > > EfiReservedMemory which the OS must respect into 
> > > > > > > > EfiBootServicesData
> > > > > > > > which the OS may discard.
> > > > > > > >
> > > > > > > > E.g. initr_lmb() is being called after efi_memory_init().
> > > > > > > >
> > > > > > > > Getting all cases of synchronization properly tested seems very 
> > > > > > > > hard to
> > > > > > > > me. Everything would be much easier if we had only a single 
> > > > > > > > memory
> > > > > > > > management system.
> > > > > > >
> > > > > > > Yes, Sughosh is working on the single memory reservation system 
> > > > > > > for
> > > > > > > everyone to use. This pairs with the single memory allocation 
> > > > > > > system
> > > > > > > (malloc) that we have. Parts of the code base that aren't keeping 
> > > > > > > these
> > > > > > > systems up to date / obeying their results need to be corrected.
> > > > > >
> > > > > > The EFI allocations don't happen until boot time...so why do we need
> > > > > > to do this now? We can instead have an EFI function to scan LMB and
> > > > > > add to its memory map.
> > > > >
> > > > > We're talking about reservations, not allocations. So yes, when 
> > > > > someone
> > > > > is making their reservation, they need to make it. I don't understand
> > > > > your question.
> > > >
> > > > As I understand it, this is used to tell EFI about a memory reservation.
> > >
> > > This patch, or this series? This series isn't about EFI. This patch is,
> > > yes.
> > >
> > > > But the EFI code can scan the LMB reservations just before booting and
> > > > update its tables. I don't see a need to keep them in sync before the
> > > > boot actually happens.
> > >
> > > But that wouldn't work. If something needs to reserve a region it needs
> > > to do it when it starts using it. It's not about the EFI map for the OS,
> > > it's about making sure that U-Boot doesn't scribble over a now-reserved
> > > area.
> >
> > I'm not convinced of that yet. EFI does not do allocations until it
> > starts loading images,
>
> It does in some cases. E.g The efi variables allocate some pages when
> the subsystem starts, the TCG protocol allocates the EventLog once
> it's installed and I am pretty sure we have more.

Both of those seem wrong to me, though.

- EFI variables should use malloc() like other small amounts of data
- TCG should probably use a bloblist, but in any case I suspect it is
needed beyond EFI

>
> > and it uses LMB for those (or at least it does
> > with bootstd). I'm just trying to keep this all as simple as possible.
>
> Heinrich already pointed out a potential danger in the current design.
> If an EFI allocation happens *before* LMB comes up, we might end up
> updating the efi memory map with the wrong attributes. That would lead
> to the OS discarding memory areas that should be preserved and we
> won't figure that out until the OS boots and blows up.

Yes, I believe the EFI memory sort-out should happen when booting and
not before. It is a bit like creating a plate of spaghetti if we do
all this stuff randomly while trying to boot different things,
retrying, etc

Regards,
Simon

Re: [PATCH 5/9] fdt: Correct condition for bloblist existing

Hi Ilias,

On Wed, 12 Jun 2024 at 00:02, Ilias Apalodimas
 wrote:
>
> [...]
>
> > > > >> ---
> > > > >>
> > > > >>  lib/fdtdec.c | 12 ++--
> > > > >>  1 file changed, 10 insertions(+), 2 deletions(-)
> > > > >>
> > > > >> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > > > >> index b2c59ab3818..b141244e3b9 100644
> > > > >> --- a/lib/fdtdec.c
> > > > >> +++ b/lib/fdtdec.c
> > > > >> @@ -1669,8 +1669,16 @@ int fdtdec_setup(void)
> > > > >>  {
> > > > >> int ret = -ENOENT;
> > > > >>
> > > > >> -   /* If allowing a bloblist, check that first */
> > > > >> -   if (CONFIG_IS_ENABLED(BLOBLIST)) {
> > > > >> +   /*
> > > > >> +* If allowing a bloblist, check that first. This would be 
> > > > >> better
> > > > >> +* handled with an OF_BLOBLIST Kconfig, but that caused far 
> > > > >> too much
> > > > >> +* argument, so add a hack here, used e.g. by 
> > > > >> chromebook_coral
> > > > >
> > > > > I am a bit confused by this comment - It means you will not use 
> > > > > OF_BLOBLIST,
> > > > > but actually you are using it below. Is it a typo?
> > > >
> > > > Basically it would be cleaner to have a separate, phase-specific
> > > > Kconfig control as to whether the DT can come from the bloblist (I
> > > > can't remember the Kconfig name I suggested, nor the patch as it was
> > > > last year sometime). But for now I am adding this hack to get a few
> > > > boards working again.
> > >
> > > I am a bit confused.
> > > First of all the comment is innapropriate. We went through a lengthy
> > > discussion on BLOBLIST/OF_BLOSLIST etc and,  even Tom chimed in and we
> > > made up our minds. Why are you adding this comment now? Why do code
> > > comments have to illustrate your personal opinion -- which was
> > > rejected?
> >
> > I'm sorry for the tone of the comment. I am not trying to offend
> > anyone here and I'm happy to change the language.
>
> Yes please a comment explaining why that piece of code is there is far
> more intuitive.

OK, once we have agreed the below I can do that.

>
> >  As I probably
> > mentioned at the time, my accepted patch breaks my workflow and
> > several boards. I hope you can understand how frustrating that sort of
> > thing can be.
>
> Yes, I do and I am fine with a short-term patch that fixes issues, as
> long as its not too intrusive. There is a very thin line between quick
> and dirty fixes to spaghetti unreadable code. But we should have
> comments and/or commit messages indicating that this needs a proper
> fix

I spent a lot of time explaining this last time.

>
> > Also, now that I have my lab back up and running and I
> > would like these boards to work again on mainline!
> >
> > >
> > > Grepping for OF_BLOBLIST, I can't find any matches, so is the above if a 
> > > typo?
> >
> > Remember, it was a patch you rejected :-)
>
> I don't maintain any of that. I only gave some feedback along the
> lines of "bloblist was designed to be auto-discoverable, I don't see
> how adding an explicit Kconfig helps". IIRC we eventually followed
> what Tom suggested.

I'm not trying to point the finger here. So far the boards are broken
in mainline...I'm just trying to fix that,

>
> In any case, the amount of bike-shedding in the topic is too much. Do
> you mind explaining the problem in your workflow again? Perhaps we can
> find a solution that is integrated in bloblist_maybe_init() instead of
> injecting ifs on when a bloblist should or should not be searched for
> all over the place.

TPL (or SPL) sets up a bloblist with bits of info in it, but no DT
(which is in memory-mapped SPI flash)
U-Boot proper starts up, it wants to get the bloblist but not hang if
the bloblist doesn't have a DT

Regards,
Simon

Re: [PATCH 2/9] tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL

Hi Heinrich,

On Tue, 4 Jun 2024 at 22:15, Heinrich Schuchardt  wrote:
>
> On 6/5/24 05:25, Simon Glass wrote:
> > It does not make sense to enable all SHA algorithms unless they are
> > needed. It bloats the code and in this case, causes chromebook_link to
> > fail to build.
>
> Why would chromebook_link fail to build?

Because U-Boot suddenly grew a lot due to that commit. It broke out of
the bounds of its SPI-flash region.

> Is TPM used by U-Boot on that board at all?

Yes, but only for tests.

>
> >
> > Add a condition to TPM to correct this. Note that the original commit
> > combines refactoring and new features, which makes it hard to see what
> > is going on.
> >
> > Fixes: 97707f12fda tpm: Support boot measurements
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >   lib/Kconfig | 8 
> >   1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index 189e6eb31aa..70b32362ada 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -438,10 +438,10 @@ config TPM
> >   bool "Trusted Platform Module (TPM) Support"
> >   depends on DM
> >   imply DM_RNG
> > - select SHA1
> > - select SHA256
> > - select SHA384
> > - select SHA512
> > + select SHA1 if EFI_TCG2_PROTOCOL
> > + select SHA256 if EFI_TCG2_PROTOCOL
> > + select SHA384 if EFI_TCG2_PROTOCOL
> > + select SHA512 if EFI_TCG2_PROTOCOL
>
> You need to consider CONFIG_MEASURED_BOOT which allows measured boot in
> the non-UEFI case.
>
> Please, take into account
>
> lib/tpm-v1.c:20:
> #error "TPM_AUTH_SESSIONS require SHA1 to be configured, too"
>
> This #error should be replaced by a Kconfig constraint.
>
> I would prefer the select statements to be in lib/efi_loader/Kconfig
> under EFI_TCG2_PROTOCOL.
>
> @Ilias, Eddie:
>
> Why do we require SHA1 which is considered insecure?
>
> Shouldn't we change tpm2_supported_algorithms[] to include only
> algorithms selected in the configuration? This would allow replacing all
> the select statements in Simon's patch by imply.

I attempted that in v2.

>
> Best regards
>
> Heinrich
>
> >   help
> > This enables support for TPMs which can be used to provide security
> > features for your board. The TPM can be connected via LPC or I2C
>

Regards,
Simon

Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable

Hi Tom,

On Wed, 12 Jun 2024 at 11:22, Tom Rini  wrote:
>
> On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote:
>
> [snip]
> > Also IMO there is only really one LMB list today. We create it at the
> > start of bootm and then it is done when we boot. The file-loading
> > stuff is what makes all this confusing...and with bootstd that is
> > under control as well.
> >
> > At lot of this effort seems to be about dealing with random scripts
> > which load things. We want to make sure we complain if something
> > overlaps. But we should be making the bootstd case work nicely and
> > doing things within that framework. Also EFI sort-of has its own
> > thing, which it is very-much in control of.
> >
> > Overall I think this is a bit more subtle that just combining allocators.
>
> I think this gets to the main misunderstanding. The problem isn't
> handling bootstd, or EFI boot, or even assorted scripts. Those are all
> cases where things are otherwise (sufficiently) well-defined. The
> problem is "security" and that a "carefully crafted payload" could do
> something malicious. That's why we have to do all of this stuff sooner
> rather than later in our boot process.

That's the first I have heard of this, actually, but a bit more detail
would help. How does the payload get loaded? I'm just not sure about
the overall goals. It seems that everyone else is already familiar -
can someone please take the time to point me to the details?

Regards,
Simon

Re: [PATCH 14/20] CI: GitLab: Split build_world tasks

Hi Tom,

On Wed, 12 Jun 2024 at 11:07, Tom Rini  wrote:
>
> On Wed, Jun 12, 2024 at 05:14:46PM +0100, Jiaxun Yang wrote:
> >
> >
> > 在2024年6月12日六月 下午5:01，Tom Rini写道：
> > > On Tue, Jun 11, 2024 at 10:04:13PM +0100, Jiaxun Yang wrote:
> > >
> > >> Current build_world task runs for too long on public gitlab
> > >> runner.
> > >>
> > >> Split the job as what we've done to azure pipeline.
> > >>
> > >> Signed-off-by: Jiaxun Yang 
> > >> ---
> > >>  .gitlab-ci.yml | 103 
> > >> +
> > >>  1 file changed, 59 insertions(+), 44 deletions(-)
> > >
> > > I don't like this. The list in Azure is because of the time limits there
> > > and in turn we:
> > > a) Have to tweak it periodically to keep things from running too long
> > > b) Have to tweak it to ensure that we don't miss some new SoC/etc
> >
> > Then it will render running CI test on gitlab.com impossible again :-(
>
> Yeah, it's not something I'm the happiest with. Looking around a bit, I
> see a blog post that talks about dealing with dynamic variables, in
> Azure. So we could, I think, figure out some logic to have each build
> stage say what platforms it covers. And then have a final step that
> compares all of the platforms built vs the global list (just
> tools/buildman/buildman --dry-run -v) to make sure nothing was missed.
> With something like that, and assuming GitLab can do it too (it probably
> can), I'm OK with having the world build be broken down to 10 groups
> (maximum number of parallel jobs in Azure CI for free) since we'll know
> if we miss something too.
>
> So lets set this patch (and the doc update) aside for now, unless you
> want to look at the above. I'll look at the above soon.

Could we hook up one of our machines as a public runner somehow?

Regards,
Simon

Re: [PATCH 4/4] boot: bootflow_menu: fix crash for EFI BOOTMGR global bootmeth

On Wed, 12 Jun 2024 at 08:58, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> The global bootmeths don't set the dev in bootflow struct which means
> the dev_get_parent(bflow->dev) triggers a NULL-pointer dereference and
> crash U-Boot.
>
> So before trying to handle a bootflow, check that the associated
> bootmeth isn't global, otherwise skip it.
>
> Suggested-by: Simon Glass 
> Signed-off-by: Quentin Schulz 
> ---
>  boot/bootflow_menu.c | 7 +++
>  include/bootflow.h   | 3 ++-
>  2 files changed, 9 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass

Re: [PATCH 23/42] test: Release board after tests complete

Hi Tom,

On Wed, 12 Jun 2024 at 10:02, Tom Rini  wrote:
>
> On Tue, Jun 11, 2024 at 02:01:37PM -0600, Simon Glass wrote:
>
> > When a board is finished with, the lab may want to power it off, or
> > perform some other function. Add a new script which is called when tests
> > are complete.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  test/py/u_boot_console_exec_attach.py | 10 ++
> >  1 file changed, 10 insertions(+)
>
> Given that all of my wrapper scripts include a "turn it all on" and then
> catch for "turn everything off", this sounds very handy.

Yes I ruined some batteries due to lack of this.

I also added a way to tell Labgrid the end state to move to, which
also manages to turn off the board, unless something goes wrong in
Labgrid.

Regards,
Simon

Re: [PATCH 2/4] boot: fix typos in help text of Kconfig configs

On Wed, 12 Jun 2024 at 08:58, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> This fixes a handful of typos in various help texts in Kconfig configs.
>
> Signed-off-by: Quentin Schulz 
> ---
>  boot/Kconfig | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH 3/4] doc: bootstd: fix typos

On Wed, 12 Jun 2024 at 08:58, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> This fixes a few syntactic issues as well as typos and grammar.
>
> Signed-off-by: Quentin Schulz 
> ---
>  doc/develop/bootstd.rst | 50 
> -
>  1 file changed, 25 insertions(+), 25 deletions(-)
>

Thank you!

Reviewed-by: Simon Glass

Re: [PATCH 1/4] cmd: fix typo in CMD_BOOTMETH help text

On Wed, 12 Jun 2024 at 08:58, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> It's bootmeths and not bootmethds.
>
> Signed-off-by: Quentin Schulz 
> ---
>  cmd/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass

Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM

2024-06-12 Thread Michael Nazzareno Trimarchi

HI

On Wed, Jun 12, 2024 at 7:25 PM Tom Rini  wrote:
>
> On Wed, Jun 12, 2024 at 10:17:12AM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi Tom
> >
> > On Mon, Jun 3, 2024 at 5:08 PM Patrick Barsanti
> >  wrote:
> > >
> > > Always prioritizing u-boot includes causes problems when trying to migrate
> > > boards to OF_UPSTREAM that have different local devicetree files with
> > > respect to the upstream ones, if local DT headers are not dropped.
> > > At the same time if local and upstream files are the same, migrations
> > > can be, and have been, introduced without dropping local DT headers.
> > > This also causes problems whenever upstream DTS and DT headers are 
> > > patched.
> > >
> > > For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> > > breaks it, as there are some missing defines in a local DT header file
> > > (`imx6ul-clock.h`); the solution would be to drop it, which has not always
> > > been done in previous OF_UPSTREAM migration patches for other boards
> > > because most of the time the two are the same. This solution is also
> > > vulnerable to ABI breakage, although this has not yet happened since the
> > > introduction of OF_UPSTREAM support and is unlikely.
> > >
> > > Maintainers assure backwards compatibility for DT headers when syncing the
> > > upstream folder with the kernel.
> > > The problem is that, at the current state, all boards that have not 
> > > dropped
> > > their local headers when migrating to OF_UPSTREAM will break once the
> > > upstream devicetrees are patched, for example, to use any newly added
> > > define which is not present in the local DT header file, even if those
> > > changes are backwards compatible.
> > >
> > > This patch fixes these problems by prioritizing upstream includes when
> > > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when it is
> > > not.
> >
> > Do you have some comments here? We would like to move upstream dts for
> > imx6 boards
> > too
>
> I've been waiting for the people that wanted the commit message
> clarified to Ack/Review the patch. Did I just miss that? Sorry.
>

Agreed, let's wait for more feedback

Michael

> --
> Tom

[PATCH 2/3] doc: board: phytec: phycore-am64x: Fix Link to Documentation

We moved our documentation to another hoster and therefore the URL
changed. Point to the latest documentation instead of release versions
to not link out-dated documentation.

Signed-off-by: Daniel Schultz 
---
 doc/board/phytec/phycore-am64x.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/board/phytec/phycore-am64x.rst 
b/doc/board/phytec/phycore-am64x.rst
index a27ad01027b..c99d8f6dd58 100644
--- a/doc/board/phytec/phycore-am64x.rst
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -156,4 +156,4 @@ Further Information
 ---
 
 Please see :doc:`../ti/am64x_evm` chapter for further AM64 SoC related 
documentation
-and https://docs.phytec.com/phycore-am64x for vendor documentation.
+and https://docs.phytec.com/projects/yocto-phycore-am64x/en/latest/ for vendor 
documentation.
-- 
2.25.1

[PATCH 3/3] doc: board: phytec: phycore-am64: Fix phyBOARD Name

The Carrier-Board for the pyhCORE-AM64x is called phyBOARD-Electra.

Signed-off-by: Daniel Schultz 
---
 doc/board/phytec/phycore-am64x.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/board/phytec/phycore-am64x.rst 
b/doc/board/phytec/phycore-am64x.rst
index c99d8f6dd58..ad9f47d9dfd 100644
--- a/doc/board/phytec/phycore-am64x.rst
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -9,7 +9,7 @@ SoM (System on Module) featuring TI's AM64x 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 AM64x family.
 
-A development Kit, called `phyBOARD-Lyra 
`_
+A development Kit, called `phyBOARD-Electra 
`_
 is used as a carrier board reference design around the AM64x SoM.
 
 Quickstart
-- 
2.25.1

[PATCH 1/3] doc: board: phytec: phycore-am62x: Fix Link to Documentation

We moved our documentation to another hoster and therefore the URL
changed. Point to the latest documentation instead of release versions
to not link out-dated documentation.

Signed-off-by: Daniel Schultz 
---
 doc/board/phytec/phycore-am62x.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/board/phytec/phycore-am62x.rst 
b/doc/board/phytec/phycore-am62x.rst
index bc6d5246694..681ac536125 100644
--- a/doc/board/phytec/phycore-am62x.rst
+++ b/doc/board/phytec/phycore-am62x.rst
@@ -155,4 +155,4 @@ Further Information
 ---
 
 Please see :doc:`../ti/am62x_sk` chapter for further AM62 SoC related 
documentation
-and https://docs.phytec.com/phycore-am62x for vendor documentation.
+and https://docs.phytec.com/projects/yocto-phycore-am62x/en/latest/ for vendor 
documentation.
-- 
2.25.1

Re: [PATCH 00/42] labgrid: Provide an integration with Labgrid

On Wed, Jun 12, 2024 at 09:08:32AM +0300, Ilias Apalodimas wrote:
> Hi Simon
> 
> On Tue, 11 Jun 2024 at 23:02, Simon Glass  wrote:
> >
> > Labgrid provides access to a hardware lab in an automated way. It is
> > possible to boot U-Boot on boards in the lab without physically touching
> > them. It relies on relays, USB UARTs and SD muxes, among other things.
> >
> > By way of background, about 4 years ago I wrong a thing called Labman[1]
> > which allowed my lab of about 30 devices to be operated remotely, using
> > tbot for the console and build integration. While it worked OK and I
> > used it for many bisects, I didn't take it any further.
> >
> > It turns out that there was already an existing program, called Labgrid,
> > which I did not know about at time (thank you Tom for telling me). It is
> > more rounded than Labman and has a number of advantages:
> >
> > - does not need udev rules, mostly
> > - has several existing users who rely on it
> > - supports multiple machines exporting their devices
> >
> > It lacks a 'lab check' feature and a few other things, but these can be
> > remedied.
> >
> > On and off over the past several weeks I have been experimenting with
> > Labgrid. I have managed to create an initial U-Boot integration (this
> > series) by adding various features to Labgrid[2] and the U-Boot test
> > hooks.
> >
> > I hope that this might inspire others to set up boards and run tests
> > automatically, rather than relying on infrequent, manual test. Perhaps
> > it may even be possible to have a number of labs available.
> >
> > Included in the integration are a number of simple scripts which make it
> > easy to connect to boards and run tests:
> >
> > ub-int 
> > Build and boot on a target, starting an interactive session
> >
> > ub-cli 
> > Build and boot on a target, ensure U-Boot starts and provide an 
> > interactive
> > session from there
> >
> > ub-smoke 
> > Smoke test U-Boot to check that it boots to a prompt on a target
> >
> > ub-bisect
> > Bisect a git tree to locate a failure on a particular target
> >
> > ub-pyt  
> > Run U-Boot pytests on a target
> >
> > Some of these help to provide the same tbot[4] workflow which I have
> > relied on for several years, albeit much simpler versions.
> >
> > The goal here is to create some sort of script which can collect
> > patches from the mailing list, apply them and test them on a selection
> > of boards. I suspect that script already exists, so please let me know
> > what you suggest.
> >
> > I hope you find this interesting and take a look!
> 
> Thanks this is interesting!
> I only got cc'ed on the cover letter and I'll slowly have a look on
> the rest. A naive question -- I saw you did integrate this on gitlab
> with your internal lab. How secure is this? Could we schedule weekly
> builds that run on various remote labs and get results on actual
> hardware? Or do we have to rely on users for that ?

That's where this certainly gets a little tricky. Ideally, and part of
why I've been hoping to get Labgrid going with our pytest suite, since
it's good enough for kernelci (and people to be reasonably confident
about allowing not-exactly-random-user-access), it should be good enough
for us too. So my long term hope is that we can:
- Have Labgrid based labs + something know to monitor trees+branches at
  X location (like I know today some people poll and test my WIP
  branches).
- Have it be reasonably clear that if you maintain a lab for kernelci,
  you can add testing U-Boot in too.

In the medium term, I am hopeful we can at least expose this to all
custodian trees on source.denx.de. And I'm saying "we" here as I have
two much smaller labs also going, one with Labgrid, and both a much
smaller set of targets currently.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 00/13] *** Various fixes & improvements for phycore-AM6* SoMs ***


For all 13 patches,

Reviewed-by: Daniel Schultz 

On 10.06.24 15:33, Wadim Egorov wrote:

This patch set is for u-boot/next.
It includes various fixes and improvements for phyCORE-AM62x and
phyCORE-AM64x SoMs. Notable is the last patch which prepares for use
with future ECC memory fixups.

Nathan Morrisson (2):
   arch: arm: dts: k3-am625-phyboard-lyra: Add fixed partitions
   arch: arm: dts: k3-am642-phyboard-electra: Add fixed partitions

Wadim Egorov (11):
   board: phytec: common: k3: Copy fixed partitions to OS device tree
   board: phytec: phycore-am62x: Fix CONFIG_SPL_BOARD_INIT
   configs: phycore_am62x: Update environment location
   configs: phycore_am64x: Update environment location
   arm: dts: k3-am625-phyboard-lyra-rdk: Enable usb port in u-boot
   configs: phycore_am62x_a53_defconfig: Enable DFU boot
   board: phytec: phycore-am62x: Pull in k3_dfu.env
   configs: phycore_am6xx: Update MTD & SPI configs
   doc: board: phytec: phycore-am62x: Add USB DFU switch config
   doc: board: phytec: phycore-am6: Use mtd commands
   board: phytec: phycore-am62x: Use memory nodes in higher boot stages

  .../k3-am625-phyboard-lyra-rdk-u-boot.dtsi| 35 +
  .../k3-am642-phyboard-electra-rdk-u-boot.dtsi | 26 +
  board/phytec/common/k3/board.c| 10 +
  board/phytec/phycore_am62x/phycore-am62x.c| 31 ++-
  board/phytec/phycore_am62x/phycore_am62x.env  |  2 +
  configs/phycore_am62x_a53_defconfig   | 38 +--
  configs/phycore_am62x_r5_defconfig|  1 -
  configs/phycore_am64x_a53_defconfig   |  8 ++--
  configs/phycore_am64x_r5_defconfig|  1 -
  doc/board/phytec/phycore-am62x.rst| 12 --
  doc/board/phytec/phycore-am64x.rst|  8 ++--
  11 files changed, 155 insertions(+), 17 deletions(-)

Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM

On Wed, Jun 12, 2024 at 10:17:12AM +0200, Michael Nazzareno Trimarchi wrote:
> Hi Tom
> 
> On Mon, Jun 3, 2024 at 5:08 PM Patrick Barsanti
>  wrote:
> >
> > Always prioritizing u-boot includes causes problems when trying to migrate
> > boards to OF_UPSTREAM that have different local devicetree files with
> > respect to the upstream ones, if local DT headers are not dropped.
> > At the same time if local and upstream files are the same, migrations
> > can be, and have been, introduced without dropping local DT headers.
> > This also causes problems whenever upstream DTS and DT headers are patched.
> >
> > For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> > breaks it, as there are some missing defines in a local DT header file
> > (`imx6ul-clock.h`); the solution would be to drop it, which has not always
> > been done in previous OF_UPSTREAM migration patches for other boards
> > because most of the time the two are the same. This solution is also
> > vulnerable to ABI breakage, although this has not yet happened since the
> > introduction of OF_UPSTREAM support and is unlikely.
> >
> > Maintainers assure backwards compatibility for DT headers when syncing the
> > upstream folder with the kernel.
> > The problem is that, at the current state, all boards that have not dropped
> > their local headers when migrating to OF_UPSTREAM will break once the
> > upstream devicetrees are patched, for example, to use any newly added
> > define which is not present in the local DT header file, even if those
> > changes are backwards compatible.
> >
> > This patch fixes these problems by prioritizing upstream includes when
> > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when it is
> > not.
> 
> Do you have some comments here? We would like to move upstream dts for
> imx6 boards
> too

I've been waiting for the people that wanted the commit message
clarified to Ack/Review the patch. Did I just miss that? Sorry.

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 04/31] lmb: remove local instances of the lmb structure variable

On Tue, Jun 11, 2024 at 08:41:39PM -0600, Simon Glass wrote:

[snip]
> Also IMO there is only really one LMB list today. We create it at the
> start of bootm and then it is done when we boot. The file-loading
> stuff is what makes all this confusing...and with bootstd that is
> under control as well.
> 
> At lot of this effort seems to be about dealing with random scripts
> which load things. We want to make sure we complain if something
> overlaps. But we should be making the bootstd case work nicely and
> doing things within that framework. Also EFI sort-of has its own
> thing, which it is very-much in control of.
> 
> Overall I think this is a bit more subtle that just combining allocators.

I think this gets to the main misunderstanding. The problem isn't
handling bootstd, or EFI boot, or even assorted scripts. Those are all
cases where things are otherwise (sufficiently) well-defined. The
problem is "security" and that a "carefully crafted payload" could do
something malicious. That's why we have to do all of this stuff sooner
rather than later in our boot process.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH 14/20] CI: GitLab: Split build_world tasks

On Wed, Jun 12, 2024 at 05:14:46PM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年6月12日六月 下午5:01，Tom Rini写道：
> > On Tue, Jun 11, 2024 at 10:04:13PM +0100, Jiaxun Yang wrote:
> >
> >> Current build_world task runs for too long on public gitlab
> >> runner.
> >> 
> >> Split the job as what we've done to azure pipeline.
> >> 
> >> Signed-off-by: Jiaxun Yang 
> >> ---
> >>  .gitlab-ci.yml | 103 
> >> +
> >>  1 file changed, 59 insertions(+), 44 deletions(-)
> >
> > I don't like this. The list in Azure is because of the time limits there
> > and in turn we:
> > a) Have to tweak it periodically to keep things from running too long
> > b) Have to tweak it to ensure that we don't miss some new SoC/etc
> 
> Then it will render running CI test on gitlab.com impossible again :-(

Yeah, it's not something I'm the happiest with. Looking around a bit, I
see a blog post that talks about dealing with dynamic variables, in
Azure. So we could, I think, figure out some logic to have each build
stage say what platforms it covers. And then have a final step that
compares all of the platforms built vs the global list (just
tools/buildman/buildman --dry-run -v) to make sure nothing was missed.
With something like that, and assuming GitLab can do it too (it probably
can), I'm OK with having the world build be broken down to 10 groups
(maximum number of parallel jobs in Azure CI for free) since we'll know
if we miss something too.

So lets set this patch (and the doc update) aside for now, unless you
want to look at the above. I'll look at the above soon.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH 12/20] cyclic: Rise default CYCLIC_MAX_CPU_TIME_US to 5000

On Wed, Jun 12, 2024 at 05:13:37PM +0100, Jiaxun Yang wrote:
> 
> 
> 在2024年6月12日六月 下午5:00，Tom Rini写道：
> [...]
> >>  configs/octeon_nic23_defconfig | 1 -
> >>  2 files changed, 1 insertion(+), 2 deletions(-)
> >
> > This seems similar to:
> > https://patchwork.ozlabs.org/project/uboot/patch/20240524210817.1953298-1-rasmus.villem...@prevas.dk/
> >
> > at least for CI. And for outside CI, I'm OK with just having the value
> > be changed in the defconfig as needed. We do support using config
> > fragments, so keeping such changes locally isn't too hard.
> 
> So the default value is a little bit too hard even for some of the actual
> hardware.

Right, there's some platforms where it's too small and we should just
bump it up. I think for now the default is what we want it to be for
most platforms.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 13/14] configs: introduce configs needed for the J722S

On Wed, Jun 12, 2024 at 02:41:22PM +0530, Jayesh Choudhary wrote:

> Introduce the initial configs needed to support the J722S SoC family.
> 
> Signed-off-by: Vaishnav Achath 
> Signed-off-by: Jayesh Choudhary 
> ---
>  configs/j722s_evm_a53_defconfig | 172 
>  configs/j722s_evm_r5_defconfig  | 131 
>  include/configs/j722s_evm.h |  14 +++
>  3 files changed, 317 insertions(+)
>  create mode 100644 configs/j722s_evm_a53_defconfig
>  create mode 100644 configs/j722s_evm_r5_defconfig
>  create mode 100644 include/configs/j722s_evm.h
[snip]
> diff --git a/include/configs/j722s_evm.h b/include/configs/j722s_evm.h
> new file mode 100644
> index 00..10f2e2d3ed
> --- /dev/null
> +++ b/include/configs/j722s_evm.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Configuration header file for K3 J722S SoC family
> + *
> + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#ifndef __CONFIG_J722S_EVM_H
> +#define __CONFIG_J722S_EVM_H
> +
> +/* Now for the remaining common defines */
> +#include 
> +
> +#endif /* __CONFIG_J722S_EVM_H */

If there's any other feedback and you need to do a v3, instead of
#include  here just define CFG_SYS_SDRAM_BASE
as that's the only thing in the common header that new platforms should
need.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 16/20] CI: Dockerfile: Bump various software version

2024-06-12 Thread Jiaxun Yang




在2024年6月12日六月 下午5:02，Tom Rini写道：
[...]
>> --- a/tools/docker/Dockerfile
>> +++ b/tools/docker/Dockerfile
>> @@ -2,7 +2,7 @@
>>  # This Dockerfile is used to build an image containing basic stuff to be 
>> used
>>  # to build U-Boot and run our test suites.
>>  
>> -FROM ubuntu:jammy-20240227
>> +FROM ubuntu:noble
>>  MAINTAINER Tom Rini 
>>  LABEL Description=" This image is for building U-Boot inside a container"
>>  
>
> For reproducibility I keep us on date-tags and not just the raw
> release tag/latest. Also, I'm not yet ready to move us past Jammy
> without a big reason. Once 24.04.1 comes out, perhaps. So it's good to
> know at least this wasn't too much work to move forward. Also, we should
> keep the bumping of various tools to their own commit, each.

Ok, I'll add tag back.

My purpose to move CI to noble is to test against all new pieces of software.
I was hit by those issues when I was trying to run tests locally with my 
ArchLinux
PC, so I decided to fix them and bump CI to ensure we don't introduce more in 
future.

I think as we can pass all CI runs it's good to move forward :-)

Thanks
>
> -- 
> Tom
>
> 附件:
> * signature.asc

-- 
- Jiaxun

Re: [PATCH 14/20] CI: GitLab: Split build_world tasks

2024-06-12 Thread Jiaxun Yang




在2024年6月12日六月 下午5:01，Tom Rini写道：
> On Tue, Jun 11, 2024 at 10:04:13PM +0100, Jiaxun Yang wrote:
>
>> Current build_world task runs for too long on public gitlab
>> runner.
>> 
>> Split the job as what we've done to azure pipeline.
>> 
>> Signed-off-by: Jiaxun Yang 
>> ---
>>  .gitlab-ci.yml | 103 
>> +
>>  1 file changed, 59 insertions(+), 44 deletions(-)
>
> I don't like this. The list in Azure is because of the time limits there
> and in turn we:
> a) Have to tweak it periodically to keep things from running too long
> b) Have to tweak it to ensure that we don't miss some new SoC/etc

Then it will render running CI test on gitlab.com impossible again :-(

Thanks
>
> -- 
> Tom
>
> 附件:
> * signature.asc

-- 
- Jiaxun

Re: [PATCH 12/20] cyclic: Rise default CYCLIC_MAX_CPU_TIME_US to 5000

2024-06-12 Thread Jiaxun Yang




在2024年6月12日六月 下午5:00，Tom Rini写道：
[...]
>>  configs/octeon_nic23_defconfig | 1 -
>>  2 files changed, 1 insertion(+), 2 deletions(-)
>
> This seems similar to:
> https://patchwork.ozlabs.org/project/uboot/patch/20240524210817.1953298-1-rasmus.villem...@prevas.dk/
>
> at least for CI. And for outside CI, I'm OK with just having the value
> be changed in the defconfig as needed. We do support using config
> fragments, so keeping such changes locally isn't too hard.

So the default value is a little bit too hard even for some of the actual
hardware.

I think being permissive here can prevent people hit into the problem
only after enabling cyclic on their own board.

Thanks
>
> -- 
> Tom
>
> 附件:
> * signature.asc

-- 
- Jiaxun

Re: [PATCH 23/42] test: Release board after tests complete

On Tue, Jun 11, 2024 at 02:01:37PM -0600, Simon Glass wrote:

> When a board is finished with, the lab may want to power it off, or
> perform some other function. Add a new script which is called when tests
> are complete.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  test/py/u_boot_console_exec_attach.py | 10 ++
>  1 file changed, 10 insertions(+)

Given that all of my wrapper scripts include a "turn it all on" and then
catch for "turn everything off", this sounds very handy.

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 3/4] qemu-xtensa-dc233c: New board

On Tue, Jun 11, 2024 at 10:00:24PM +0100, Jiaxun Yang wrote:

> Signed-off-by: Jiaxun Yang 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 4/4] qemu-loongarch64: New board

On Tue, Jun 11, 2024 at 10:00:25PM +0100, Jiaxun Yang wrote:

> Signed-off-by: Jiaxun Yang 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 2/4] qemu-arm64be: New board

On Tue, Jun 11, 2024 at 10:00:23PM +0100, Jiaxun Yang wrote:

> Signed-off-by: Jiaxun Yang 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 1/4] qemu-vexpress*: Pass -audio none

On Tue, Jun 11, 2024 at 10:00:22PM +0100, Jiaxun Yang wrote:

> Those boards have build in sound card which cause
> problems on CI runner.
> 
> Pass -audio none to disable sound card backends.
> 
> Signed-off-by: Jiaxun Yang 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 16/20] CI: Dockerfile: Bump various software version

On Tue, Jun 11, 2024 at 10:04:15PM +0100, Jiaxun Yang wrote:

> Bump base OS to Ubuntu noble, grub to 2.12, QEMU to 9.0 (drop
> cherry-pick for m68k as it's already in 9.0) and other tools
> to latest version.
> 
> Remove unsupported python2.
> 
> Install some required python packages for buildman/binman.
> 
> Signed-off-by: Jiaxun Yang 
> ---
>  tools/docker/Dockerfile | 35 +--
>  1 file changed, 17 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
> index 5824d371f259..e3b2c2d57555 100644
> --- a/tools/docker/Dockerfile
> +++ b/tools/docker/Dockerfile
> @@ -2,7 +2,7 @@
>  # This Dockerfile is used to build an image containing basic stuff to be used
>  # to build U-Boot and run our test suites.
>  
> -FROM ubuntu:jammy-20240227
> +FROM ubuntu:noble
>  MAINTAINER Tom Rini 
>  LABEL Description=" This image is for building U-Boot inside a container"
>  

For reproducibility I keep us on date-tags and not just the raw
release tag/latest. Also, I'm not yet ready to move us past Jammy
without a big reason. Once 24.04.1 comes out, perhaps. So it's good to
know at least this wasn't too much work to move forward. Also, we should
keep the bumping of various tools to their own commit, each.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 14/20] CI: GitLab: Split build_world tasks

On Tue, Jun 11, 2024 at 10:04:13PM +0100, Jiaxun Yang wrote:

> Current build_world task runs for too long on public gitlab
> runner.
> 
> Split the job as what we've done to azure pipeline.
> 
> Signed-off-by: Jiaxun Yang 
> ---
>  .gitlab-ci.yml | 103 
> +
>  1 file changed, 59 insertions(+), 44 deletions(-)

I don't like this. The list in Azure is because of the time limits there
and in turn we:
a) Have to tweak it periodically to keep things from running too long
b) Have to tweak it to ensure that we don't miss some new SoC/etc

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH 13/20] CI: Ensure pip install is always performed in venv

On Tue, Jun 11, 2024 at 10:04:12PM +0100, Jiaxun Yang wrote:

> Since Ubuntu focal it's nolonger permitted to perform global
> pip install.
> 
> Ensure that pip install is always performed in venv.
> For buildman alone, all dependencies are already in docker
> so there is no need to perform pip install.
> 
> Signed-off-by: Jiaxun Yang 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 12/20] cyclic: Rise default CYCLIC_MAX_CPU_TIME_US to 5000

On Tue, Jun 11, 2024 at 10:04:11PM +0100, Jiaxun Yang wrote:

> The default value CYCLIC_MAX_CPU_TIME_US was 1000, which is
> a little bit too low for slower hardware and sandbox.
> 
> On my MIPS Boston FPGA board with interaptiv CPU, wdt_cyclic
> can easily take 3200 us to run.
> 
> On azure pipeline sandbox_clang, wdt_cyclic some times goes
> beyond 1300 us.
> 
> Raise default value to 5000, which is the value already taken
> by octeon_nic32. This is still sufficent to maintain system
> responsiveness.
> 
> Signed-off-by: Jiaxun Yang 
> ---
>  common/Kconfig | 2 +-
>  configs/octeon_nic23_defconfig | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)

This seems similar to:
https://patchwork.ozlabs.org/project/uboot/patch/20240524210817.1953298-1-rasmus.villem...@prevas.dk/

at least for CI. And for outside CI, I'm OK with just having the value
be changed in the defconfig as needed. We do support using config
fragments, so keeping such changes locally isn't too hard.

-- 
Tom


signature.asc
Description: PGP signature

Re: [u-boot-test-hooks PATCH 1/2] Create a common file for test scripts

On Tue, Jun 11, 2024 at 02:07:26PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 11 Jun 2024 at 10:07, Tom Rini  wrote:
> >
> > On Mon, Jun 10, 2024 at 04:27:42PM -0600, Simon Glass wrote:
> >
> > > The top part of each of the u-boot-test-* files is common. Put it in
> > > a common script file to avoid duplication and to allow it to be
> > > replaced for the Labgrid integration.
> > >
> > > Signed-off-by: Simon Glass 
> > [snip]
> > > +++ b/bin/u-boot-test-common
> > [snip]
> > > +bin_dir="`dirname $0`"
> >
> > So we always set bin_dir here...
> >
> > > +board_type="$1"
> > > +board_ident="$2"
> > > +hostname="`hostname`"
> > > +
> > > +. "${bin_dir}/${hostname}/conf.${board_type}_${board_ident}"
> > > diff --git a/bin/u-boot-test-console b/bin/u-boot-test-console
> > > index 0b6b4ac..ad90040 100755
> > > --- a/bin/u-boot-test-console
> > > +++ b/bin/u-boot-test-console
> > > @@ -20,12 +20,7 @@
> > >  # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > >  # DEALINGS IN THE SOFTWARE.
> > >
> > > -set -e
> > > -
> > >  bin_dir="`dirname $0`"
> >
> > But never remove it from the other files.
> 
> Yes that was my intent, but then I realised that it is used in
> u-boot-test-console, then wasn't sure it was a win...
> 
> Perhaps I could do this in each script?
> 
> . "$(dirname $0)/u-boot-test-common"
> 
> and that would allow removing bin_dir. The above is pretty clear.

If that works, yes, otherwise just drop it from the common file.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 00/20] New CI image and fixes

On Tue, Jun 11, 2024 at 10:03:59PM +0100, Jiaxun Yang wrote:

> Hi all,
> 
> This series build a new CI image based on Ubuntu focal with LoongArch64
> support, fixed various python scripts for python 3.12, fixed various
> problems popped up when testing againt latest software.
> 
> This change must be combined with test hook changes at [1].
> 
> Last two commits are for demonstration purpose and not for commit
> into repo.
> 
> CI runs passed at azure [2] and public gitlab.com runner [3].

Thanks for doing all of the python updates.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: dts: corstone1000: enable secondary cores for FVP

On Wed, Jun 12, 2024 at 11:04:21AM +0100, harsimransingh.tun...@arm.com wrote:
> From: Harsimran Singh Tungal 
> 
> Add the secondary cores nodes in the dts file
> 
> Signed-off-by: Harsimran Singh Tungal 
> Cc: Tom Rini 
> Cc: Rui Miguel Silva 
> ---
>  arch/arm/dts/corstone1000-fvp.dts | 25 +
>  arch/arm/dts/corstone1000.dtsi|  2 +-
>  2 files changed, 26 insertions(+), 1 deletion(-)

Can we move this to using OF_UPSTREAM instead? Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of

2024-06-12 Thread Vasileios Amoiridis

On Wed, 2024-06-12 at 17:32 +0200, Michal Simek wrote:
> 
> 
> On 6/12/24 17:11, Vasileios Amoiridis wrote:
> > On Wed, 2024-06-12 at 16:47 +0200, Michal Simek wrote:
> > > 
> > > 
> > > On 6/12/24 15:57, Vasileios Amoiridis wrote:
> > > > On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote:
> > > > > Hi Vasileios,
> > > > > 
> > > > > út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis
> > > > >  napsal:
> > > > > > 
> > > > > > From: Vasileios Amoiridis 
> > > > > > 
> > > > > > Changes in v2:
> > > > > >   - Remove duplication of custom hardcoded
> > > > > > env_locations[]
> > > > > > code.
> > > > > >   - Add implementation with general
> > > > > > arch_env_get_location(op,
> > > > > > prio)
> > > > > > 
> > > > > > v1:
> > > > > > https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/
> > > > > > 
> > > > > > Vasileios Amoiridis (1):
> > > > > >     xilinx: Add option to load environment from outside of
> > > > > > boot
> > > > > > media
> > > > > > 
> > > > > >    board/xilinx/versal-net/board.c | 47 ++-
> > > > > > -
> > > > > > 
> > > > > >    board/xilinx/versal/board.c | 47 ++-
> > > > > > -
> > > > > > 
> > > > > >    board/xilinx/zynq/board.c   | 49 +++
> > > > > > -
> > > > > > -
> > > > > >    board/xilinx/zynqmp/zynqmp.c    | 55 +--
> > > > > > -
> > > > > > -
> > > > > > 
> > > > > >    4 files changed, 101 insertions(+), 97 deletions(-)
> > > > > > 
> > > > > > --
> > > > > > 2.34.1
> > > > > > 
> > > > > 
> > > > > I have to remove this patch from my queue because it is
> > > > > actually
> > > > > breaking current behavior.
> > > > > CI is reporting an issue with it and I did a closer look and
> > > > > what
> > > > > is
> > > > > happening is that if one location has no valid
> > > > > data it goes and looks at another location from the list.
> > > > > 
> > > > 
> > > > But that is the desired behavior, if the environment is not in
> > > > one
> > > > location to check to the others.
> > > 
> > > That's how u-boot is written but if device doesn't exist or not
> > > accessible by
> > > u-boot it is clear that it shouldn't be used and then behavior is
> > > correct.
> > > 
> > 
> > Hmmm, how can a device be not-accessible by u-boot but u-boot still
> > tries to use it? How could that happen?
> 
> That Xilinx virtual defconfig are setup in a way that all drivers are
> enabled 
> via Kconfig but they are not present on all boards.

Ok, now I understand how that happens.
> If you look below in defconfig we are have that variables can be in
> NAND but 
> there is no NAND device on zc702 but still u-boot tries to reach nand
> and read 
> variables from it.
> 

So, the ideal scenario would be to U-Boot never try to access the
device? Because from what I see, is that since the device is not there,
U-Boot throws an error, and moves on.

> > 
> > Also, I think that this is a problem of the user, no? If for
> > example
> > you have configure ENV_IS_IN_NAND but there is no NAND device, then
> > with the patch you get a visible error that U-Boot tries to access
> > NAND which is not there.
> 
> For our platforms where you can burn boot.bin to any boot medium we
> had no 
> choice that's why code was written like that that variables are saved
> all the 
> time to boot medium.
> Also that I don't want to maintain other defconfigs for slightly
> different 
> configurations.
> On products customers should look at our all in one defconfig and
> disable things 
> which are not needed. And where variables are saved is definitely one
> of them.
> 

Well, that makes sense.

> > 
> > > If device exists and simple varibles are not yet saved there
> > > going to
> > > different
> > > device is IMHO problematic.
> > > 
> > 
> > Maybe I am still a bit confused, but I think that if you have
> > defined
> > ENV_IS_IN_QSPI and ENV_IS_IN_NAND but the environment is not there
> > then
> > the behavior that we see is actually correct. U-Boot tries:
> > 
> > a) Get env from QSPI but fails because env is not there,
> > b) Get env from NAND but fails because NAND is not there,
> > c) Get env from nowhere.
> > 
> > To me, this looks like the correct behavior. Isn't it?
> 
> This sequence is correct but what it is not correct is when you reach
> nowhere 
> and you run saveenv you can't really save variables even they can be
> saved to 
> QSPI. They can't be saved to NAND because it is not present on the
> board.
> 

This can be solved by using the env_select command (cmd/nvedit.c) no?

> The issue is that none write initial variable to QSPI that's why
> there will be 
> all the time bad CRC but location is correct.
> 
> 
> > > > 
> > > > > On Zynq it behaves like this.
> > > > > 
> > > > > MMC:   mmc@e010: 0
> > > > > prio 0
> > > > > Loading Environment from SPIFlash... SF: Detected n25q128a13
> > > > > with
> > > > > page
> > > > > size 256 Bytes, erase size 64 KiB, tota

Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of

2024-06-12 Thread Michal Simek





On 6/12/24 17:11, Vasileios Amoiridis wrote:

On Wed, 2024-06-12 at 16:47 +0200, Michal Simek wrote:



On 6/12/24 15:57, Vasileios Amoiridis wrote:

On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote:

Hi Vasileios,

út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis
 napsal:


From: Vasileios Amoiridis 

Changes in v2:
  - Remove duplication of custom hardcoded
env_locations[]
code.
  - Add implementation with general
arch_env_get_location(op,
prio)

v1:
https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/

Vasileios Amoiridis (1):
    xilinx: Add option to load environment from outside of boot
media

   board/xilinx/versal-net/board.c | 47 ++--

   board/xilinx/versal/board.c | 47 ++--

   board/xilinx/zynq/board.c   | 49 +++-
-
   board/xilinx/zynqmp/zynqmp.c    | 55 +---
-

   4 files changed, 101 insertions(+), 97 deletions(-)

--
2.34.1



I have to remove this patch from my queue because it is actually
breaking current behavior.
CI is reporting an issue with it and I did a closer look and what
is
happening is that if one location has no valid
data it goes and looks at another location from the list.



But that is the desired behavior, if the environment is not in one
location to check to the others.


That's how u-boot is written but if device doesn't exist or not
accessible by
u-boot it is clear that it shouldn't be used and then behavior is
correct.



Hmmm, how can a device be not-accessible by u-boot but u-boot still
tries to use it? How could that happen?


That Xilinx virtual defconfig are setup in a way that all drivers are enabled 
via Kconfig but they are not present on all boards.
If you look below in defconfig we are have that variables can be in NAND but 
there is no NAND device on zc702 but still u-boot tries to reach nand and read 
variables from it.




Also, I think that this is a problem of the user, no? If for example
you have configure ENV_IS_IN_NAND but there is no NAND device, then
with the patch you get a visible error that U-Boot tries to access
NAND which is not there.


For our platforms where you can burn boot.bin to any boot medium we had no 
choice that's why code was written like that that variables are saved all the 
time to boot medium.
Also that I don't want to maintain other defconfigs for slightly different 
configurations.
On products customers should look at our all in one defconfig and disable things 
which are not needed. And where variables are saved is definitely one of them.





If device exists and simple varibles are not yet saved there going to
different
device is IMHO problematic.



Maybe I am still a bit confused, but I think that if you have defined
ENV_IS_IN_QSPI and ENV_IS_IN_NAND but the environment is not there then
the behavior that we see is actually correct. U-Boot tries:

a) Get env from QSPI but fails because env is not there,
b) Get env from NAND but fails because NAND is not there,
c) Get env from nowhere.

To me, this looks like the correct behavior. Isn't it?


This sequence is correct but what it is not correct is when you reach nowhere 
and you run saveenv you can't really save variables even they can be saved to 
QSPI. They can't be saved to NAND because it is not present on the board.


The issue is that none write initial variable to QSPI that's why there will be 
all the time bad CRC but location is correct.






On Zynq it behaves like this.

MMC:   mmc@e010: 0
prio 0
Loading Environment from SPIFlash... SF: Detected n25q128a13 with
page
size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

prio 1
Loading Environment from NAND... *** Error - No Valid Environment
Area found
*** Warning - bad env area, using default environment

prio 2
Loading Environment from SPIFlash... *** Warning - bad CRC, using
default environment

prio 3
Loading Environment from nowhere... OK




This is the message that we get as well when this patch is not
added.


It means you are booting out of QSPI but qspi is not accessible by u-
boot. Correct?




Well, we are booting from QSPI but environment is in eMMC. In our
config, we have defined ENV_IS_IN_FAT and ENV_IS_NOWHERE but we have
not defined ENV_IS_IN_QSPI.


ok.



prio is my print to show where code is. Qemu boots out in QSPI
boot
mode and SPI is tried first and because
this is xilinx_zynq_virt defconfig drivers/env locations for
other
devices are present too. That's why it goes over the list
and it always ends in nowhere which never fails.

If this runs on real HW then the same behavior is visible and I
don't
think it is right.
I think this solution should be rethought.
In product current behavior from our code is not the best and
current
U-Boot implementation is not allowing
flexibility too. We are enabling redundant variables which can be
only
on the same device but not that you have
one copy

Re: Where to put DTB file for UEFI support on ARM

2024-06-12 Thread E Shattow

Hi Leith,

On Wed, Jun 12, 2024 at 5:50 AM Leith Bade  wrote:
>
> Hi all,
>
> I have a BananaPi BPI-R3 board that I am setting up to boot Ubuntu or
> Debian. After figuring out the required config options I have managed to
> get Uboot to boot the Ubuntu USB installer, and also boot off an SD card
> once I installed Ubuntu there.
>
> I set up the bootmeth/bootdev/bootflow stuff so that the auto boot menu
> works nicely with SD card. For USB I have to drop to console and do manual
> "usb start" etc, but good enough for running the installer. It was a bit
> difficult as there seems to be a lot of older documentation or Google
> results related to using UEFI before the bootflow stuff was added. Also it
> took me a while to figure out that a board/mediatek/mt7986.env file is now
> needed as some of the config options set #define values that are not
> included in /include/configs/mt7986.h board headers - due to .env files
> replacing those #defines. It would be nice to have a default .env file for
> this board that sets sensible defaults for the various memory loading
> addresses as it took a bit of effort to come up with all the hex values.
>
> However I am struggling to work out where to place the device tree DTB file
> for the Linux kernel. For this board I need a different DTB for
> U-boot (which is included in the u-boot.bin and fip.bin) and the kernel as
> U-boot's drivers do not like the Linux upstream device tree.
>
> I can see in the UEFI bootmeth code that it searches a location /dtb/ for a
> file named in the $fdtfile environment variable. I tried putting the .dtb
> file at /dtb/mt7986a-bananapi-bpi-r3.dtb on the SD card's FAT32 partition
> that Ubuntu created, however it doesn't seem to load this and the U-boot
> boots with the u-boot.bin DTB which means kernel doesn't start If I
> manually load the correct .dtb file to $fdt_addr_r then the correct DTB is
> used and the kernel starts.

Correct, this is a limitation and the fix is not yet released with
U-Boot;  It is now queued up for U-Boot -next, but only for EFI
bootmanager (not the global EFI boot).

>
> What is the correct location for the .dtb file when using UEFI?

In theory you could just load it from the target Linux OS root
filesystem at /usr/lib/linux-image-... but when I try this there's no
support to read that filesystem within EFI bootmanager;  the files
referenced by EFI bootmanager are however accessible if on the EFI
System Partition. Perhaps I am missing some option to support loading
from partitions other than the EFI System Partition but I don't know
how.

>
> Is there a recommended way of putting the kernel DTB into the NAND or NOR
> chip when using UEFI? That way if the SD card gets wiped U-boot can still
> boot the USB drive. I don't fully understand how the MTD partitions, FIT
> files, UBI files all fit into the picture to have U-boot load the kernel
> DTB from flash.

U-Boot has its own internal FDT (firmware devicetree) which you note
may or may not work well enough to boot Linux kernel and have a
working OS userspace. It is ambiguous if a Linux OS kernel dtb of a
specific board hardware target belongs in any of NAND or NOR flash
since they tend to be tied to specific versions of the Linux kernel,
as things are today. There's no consensus that I've read anywhere on
how this should be done - again not specific to U-Boot.

I can just say from experience that if it would be able to be loaded
from the same rootfs that the Linux kernel resides then there is still
the trouble of not knowing which exact Linux kernel version that the
user will decide to load that boot cycle.

>
> Thanks,
> Leith Bade
> le...@bade.nz

-E Shattow

Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of

2024-06-12 Thread Vasileios Amoiridis

On Wed, 2024-06-12 at 16:47 +0200, Michal Simek wrote:
> 
> 
> On 6/12/24 15:57, Vasileios Amoiridis wrote:
> > On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote:
> > > Hi Vasileios,
> > > 
> > > út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis
> > >  napsal:
> > > > 
> > > > From: Vasileios Amoiridis 
> > > > 
> > > > Changes in v2:
> > > >  - Remove duplication of custom hardcoded
> > > > env_locations[]
> > > > code.
> > > >  - Add implementation with general
> > > > arch_env_get_location(op,
> > > > prio)
> > > > 
> > > > v1:
> > > > https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/
> > > > 
> > > > Vasileios Amoiridis (1):
> > > >    xilinx: Add option to load environment from outside of boot
> > > > media
> > > > 
> > > >   board/xilinx/versal-net/board.c | 47 ++--
> > > > 
> > > >   board/xilinx/versal/board.c | 47 ++--
> > > > 
> > > >   board/xilinx/zynq/board.c   | 49 +++-
> > > > -
> > > >   board/xilinx/zynqmp/zynqmp.c    | 55 +---
> > > > -
> > > > 
> > > >   4 files changed, 101 insertions(+), 97 deletions(-)
> > > > 
> > > > --
> > > > 2.34.1
> > > > 
> > > 
> > > I have to remove this patch from my queue because it is actually
> > > breaking current behavior.
> > > CI is reporting an issue with it and I did a closer look and what
> > > is
> > > happening is that if one location has no valid
> > > data it goes and looks at another location from the list.
> > > 
> > 
> > But that is the desired behavior, if the environment is not in one
> > location to check to the others.
> 
> That's how u-boot is written but if device doesn't exist or not
> accessible by 
> u-boot it is clear that it shouldn't be used and then behavior is
> correct.
> 

Hmmm, how can a device be not-accessible by u-boot but u-boot still
tries to use it? How could that happen?

Also, I think that this is a problem of the user, no? If for example
you have configure ENV_IS_IN_NAND but there is no NAND device, then
with the patch you get a visible error that U-Boot tries to access
NAND which is not there.

> If device exists and simple varibles are not yet saved there going to
> different 
> device is IMHO problematic.
> 

Maybe I am still a bit confused, but I think that if you have defined
ENV_IS_IN_QSPI and ENV_IS_IN_NAND but the environment is not there then
the behavior that we see is actually correct. U-Boot tries:

a) Get env from QSPI but fails because env is not there,
b) Get env from NAND but fails because NAND is not there,
c) Get env from nowhere.

To me, this looks like the correct behavior. Isn't it?


> > 
> > > On Zynq it behaves like this.
> > > 
> > > MMC:   mmc@e010: 0
> > > prio 0
> > > Loading Environment from SPIFlash... SF: Detected n25q128a13 with
> > > page
> > > size 256 Bytes, erase size 64 KiB, total 16 MiB
> > > *** Warning - bad CRC, using default environment
> > > 
> > > prio 1
> > > Loading Environment from NAND... *** Error - No Valid Environment
> > > Area found
> > > *** Warning - bad env area, using default environment
> > > 
> > > prio 2
> > > Loading Environment from SPIFlash... *** Warning - bad CRC, using
> > > default environment
> > > 
> > > prio 3
> > > Loading Environment from nowhere... OK
> > > 
> > > 
> > 
> > This is the message that we get as well when this patch is not
> > added.
> 
> It means you are booting out of QSPI but qspi is not accessible by u-
> boot. Correct?
> 
> 

Well, we are booting from QSPI but environment is in eMMC. In our
config, we have defined ENV_IS_IN_FAT and ENV_IS_NOWHERE but we have
not defined ENV_IS_IN_QSPI. 

> > > prio is my print to show where code is. Qemu boots out in QSPI
> > > boot
> > > mode and SPI is tried first and because
> > > this is xilinx_zynq_virt defconfig drivers/env locations for
> > > other
> > > devices are present too. That's why it goes over the list
> > > and it always ends in nowhere which never fails.
> > > 
> > > If this runs on real HW then the same behavior is visible and I
> > > don't
> > > think it is right.
> > > I think this solution should be rethought.
> > > In product current behavior from our code is not the best and
> > > current
> > > U-Boot implementation is not allowing
> > > flexibility too. We are enabling redundant variables which can be
> > > only
> > > on the same device but not that you have
> > > one copy in QSPI and second in EMMC.
> > > That's why I think location should be pretty much read from DT.
> > > There is options/u-boot node where location of variables should
> > > be
> > > described and this should replace
> > > env_get_location().
> > 
> > You mean that there should be some type of new U-Boot node that
> > describes where the environment should be located and go and
> > search in this device?
> 
> Not sure if node or just dt property which points where that
> variables are stored.
> 
> 

This doesn't sound too difficult to do. S

[PATCH 2/4] boot: fix typos in help text of Kconfig configs

From: Quentin Schulz 

This fixes a handful of typos in various help texts in Kconfig configs.

Signed-off-by: Quentin Schulz 
---
 boot/Kconfig | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/boot/Kconfig b/boot/Kconfig
index 6f3096c15a6..de277d2ba50 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -423,7 +423,7 @@ config SPL_BOOTSTD
depends on SPL && SPL_DM && SPL_OF_CONTROL && SPL_BLK
default y if VPL
help
- This enables standard boot in SPL. This is neeeded so that VBE
+ This enables standard boot in SPL. This is needed so that VBE
  (Verified Boot for Embedded) can be used, since it depends on standard
  boot. It is enabled by default since the main purpose of VPL is to
  handle the firmware part of VBE.
@@ -433,7 +433,7 @@ config VPL_BOOTSTD
depends on VPL && VPL_DM && VPL_OF_CONTROL && VPL_BLK
default y
help
- This enables standard boot in SPL. This is neeeded so that VBE
+ This enables standard boot in SPL. This is needed so that VBE
  (Verified Boot for Embedded) can be used, since it depends on standard
  boot. It is enabled by default since the main purpose of VPL is to
  handle the firmware part of VBE.
@@ -449,7 +449,7 @@ config BOOTSTD_FULL
  - bootdev, bootmeth commands
  - extra features in the bootflow command
  - support for selecting the ordering of bootmeths ("bootmeth order")
- - support for selecting the ordering of bootdevs using the devicetree
+ - support for selecting the ordering of bootdevs using the Device Tree
as well as the "boot_targets" environment variable
 
 config BOOTSTD_DEFAULTS
@@ -481,7 +481,7 @@ config BOOTSTD_PROG
default y
help
  Enable this to provide a board_run_command() function which can boot
- a systen without using commands. If the boot fails, then U-Boot will
+ a system without using commands. If the boot fails, then U-Boot will
  panic.
 
  Note: This currently has many limitations and is not a useful booting
@@ -517,7 +517,7 @@ config BOOTMETH_EXTLINUX
  bootdevs look for a 'extlinux/extlinux.conf' on each filesystem
  they scan.
 
- The specification for this filed is here:
+ The specification for this file is here:
 

https://uapi-group.org/specifications/specs/boot_loader_specification/
 
@@ -576,7 +576,7 @@ config BOOTMETH_VBE
select EVENT
help
  Enables support for VBE boot. This is a standard boot method which
- supports selection of various firmware components, seleciton of an OS 
to
+ supports selection of various firmware components, selection of an OS 
to
  boot as well as updating these using fwupd.
 
 config BOOTMETH_DISTRO
@@ -593,7 +593,7 @@ config SPL_BOOTMETH_VBE
default y if VPL
help
  Enables support for VBE boot. This is a standard boot method which
- supports selection of various firmware components, seleciton of an OS 
to
+ supports selection of various firmware components, selection of an OS 
to
  boot as well as updating these using fwupd.
 
 config VPL_BOOTMETH_VBE
@@ -603,7 +603,7 @@ config VPL_BOOTMETH_VBE
default y
help
  Enables support for VBE boot. This is a standard boot method which
- supports selection of various firmware components, seleciton of an OS 
to
+ supports selection of various firmware components, selection of an OS 
to
  boot as well as updating these using fwupd.
 
 if BOOTMETH_VBE
@@ -748,7 +748,7 @@ if MEASURED_BOOT
bool "Measure the devicetree image"
default y if MEASURED_BOOT
help
- On some platforms, the devicetree is not static as it may contain
+ On some platforms, the Device Tree is not static as it may contain
  random MAC addresses or other such data that changes each boot.
  Therefore, it should not be measured into the TPM. In that case,
  disable the measurement here.
@@ -1303,7 +1303,7 @@ config AUTOBOOT_PROMPT
 
  Note that this define is used as the (only) argument to a
  printf() call, so it may contain '%' format specifications,
- provided that it also includes, sepearated by commas exactly
+ provided that it also includes, separated by commas exactly
  like in a printf statement, the required arguments. It is
  the responsibility of the user to select only such arguments
  that are valid in the given context.
@@ -1402,7 +1402,7 @@ config AUTOBOOT_STOP_STR_SHA256
help
  This option adds the feature to only stop the autobooting,
  and therefore boot into the U-Boot prompt, when the input
- string / password matches a values that is encypted via
+ string / password matches a val

[PATCH 3/4] doc: bootstd: fix typos

From: Quentin Schulz 

This fixes a few syntactic issues as well as typos and grammar.

Signed-off-by: Quentin Schulz 
---
 doc/develop/bootstd.rst | 50 -
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst
index a07a72581e7..34631089ae0 100644
--- a/doc/develop/bootstd.rst
+++ b/doc/develop/bootstd.rst
@@ -39,7 +39,7 @@ 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
@@ -106,7 +106,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 +174,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 +188,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 +196,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)
 {
@@ -328,7 +328,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 +340,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 +349,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 e

[PATCH 4/4] boot: bootflow_menu: fix crash for EFI BOOTMGR global bootmeth

From: Quentin Schulz 

The global bootmeths don't set the dev in bootflow struct which means
the dev_get_parent(bflow->dev) triggers a NULL-pointer dereference and
crash U-Boot.

So before trying to handle a bootflow, check that the associated
bootmeth isn't global, otherwise skip it.

Suggested-by: Simon Glass 
Signed-off-by: Quentin Schulz 
---
 boot/bootflow_menu.c | 7 +++
 include/bootflow.h   | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/boot/bootflow_menu.c b/boot/bootflow_menu.c
index 16f9cd8f8ca..70f1f728b72 100644
--- a/boot/bootflow_menu.c
+++ b/boot/bootflow_menu.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,6 +78,7 @@ int bootflow_menu_new(struct expo **expp)
last_bootdev = NULL;
for (ret = bootflow_first_glob(&bflow), i = 0; !ret && i < 36;
 ret = bootflow_next_glob(&bflow), i++) {
+   struct bootmeth_uc_plat *ucp;
char str[2], *label, *key;
uint preview_id;
bool add_gap;
@@ -84,6 +86,11 @@ int bootflow_menu_new(struct expo **expp)
if (bflow->state != BOOTFLOWST_READY)
continue;
 
+   /* No media to show for BOOTMETHF_GLOBAL bootmeths */
+   ucp = dev_get_uclass_plat(bflow->method);
+   if (ucp->flags & BOOTMETHF_GLOBAL)
+   continue;
+
*str = i < 10 ? '0' + i : 'A' + i - 10;
str[1] = '\0';
key = strdup(str);
diff --git a/include/bootflow.h b/include/bootflow.h
index 080ee850122..6affc5e1a4f 100644
--- a/include/bootflow.h
+++ b/include/bootflow.h
@@ -63,7 +63,8 @@ enum bootflow_flags_t {
  *
  * @bm_node: Points to siblings in the same bootdev
  * @glob_node: Points to siblings in the global list (all bootdev)
- * @dev: Bootdev device which produced this bootflow
+ * @dev: Bootdev device which produced this bootflow, NULL for flows created by
+ *  BOOTMETHF_GLOBAL bootmeths
  * @blk: Block device which contains this bootflow, NULL if this is a network
  * device or sandbox 'host' device
  * @part: Partition number (0 for whole device)

-- 
2.45.2

[PATCH 1/4] cmd: fix typo in CMD_BOOTMETH help text

From: Quentin Schulz 

It's bootmeths and not bootmethds.

Signed-off-by: Quentin Schulz 
---
 cmd/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index b026439c773..57929d4462d 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -308,7 +308,7 @@ config CMD_BOOTMETH
depends on BOOTSTD
default y if BOOTSTD_FULL
help
- Support listing available bootmethds (methods used to boot an
+ Support listing available bootmeths (methods used to boot an
  Operating System), as well as selecting the order that the bootmeths
  are used.
 

-- 
2.45.2

[PATCH 0/4] boot: fix crash in bootflow menu with EFI BOOTMGR support + typos

bootflow menu currently crashes U-Boot with a NULL pointer dereference
because bootflow->dev is NULL for global bootmeths (such as EFI BOOTMGR).
Therefore, let's check if the bootflow is associated with a global
bootmeth before trying to make it part of the menu.

While this makes U-Boot not crash anymore, bootflow menu doesn't work
for me (I have never had a happy path with it, but I haven't actually
tried it before today :) ) and this was basically just implemented
following Simon's suggestion sent over IRC. No clue if this is enough or
just a quick band-aid patch.

This also fixes typos in multiple places.

Signed-off-by: Quentin Schulz 
---
Quentin Schulz (4):
  cmd: fix typo in CMD_BOOTMETH help text
  boot: fix typos in help text of Kconfig configs
  doc: bootstd: fix typos
  boot: bootflow_menu: fix crash for EFI BOOTMGR global bootmeth

 boot/Kconfig| 22 +++---
 boot/bootflow_menu.c|  7 +++
 cmd/Kconfig |  2 +-
 doc/develop/bootstd.rst | 50 -
 include/bootflow.h  |  3 ++-
 5 files changed, 46 insertions(+), 38 deletions(-)
---
base-commit: 1ebd659cf020843fd8e8ef90d85a66941cbab6ec
change-id: 20240612-bootflow-efi-crash-c52449ef643e

Best regards,
-- 
Quentin Schulz

Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of

2024-06-12 Thread Michal Simek





On 6/12/24 15:57, Vasileios Amoiridis wrote:

On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote:

Hi Vasileios,

út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis
 napsal:


From: Vasileios Amoiridis 

Changes in v2:
     - Remove duplication of custom hardcoded env_locations[]
code.
     - Add implementation with general arch_env_get_location(op,
prio)

v1:
https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/

Vasileios Amoiridis (1):
   xilinx: Add option to load environment from outside of boot media

  board/xilinx/versal-net/board.c | 47 ++--
  board/xilinx/versal/board.c | 47 ++--
  board/xilinx/zynq/board.c   | 49 +++--
  board/xilinx/zynqmp/zynqmp.c    | 55 +

  4 files changed, 101 insertions(+), 97 deletions(-)

--
2.34.1



I have to remove this patch from my queue because it is actually
breaking current behavior.
CI is reporting an issue with it and I did a closer look and what is
happening is that if one location has no valid
data it goes and looks at another location from the list.



But that is the desired behavior, if the environment is not in one
location to check to the others.


That's how u-boot is written but if device doesn't exist or not accessible by 
u-boot it is clear that it shouldn't be used and then behavior is correct.


If device exists and simple varibles are not yet saved there going to different 
device is IMHO problematic.





On Zynq it behaves like this.

MMC:   mmc@e010: 0
prio 0
Loading Environment from SPIFlash... SF: Detected n25q128a13 with
page
size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

prio 1
Loading Environment from NAND... *** Error - No Valid Environment
Area found
*** Warning - bad env area, using default environment

prio 2
Loading Environment from SPIFlash... *** Warning - bad CRC, using
default environment

prio 3
Loading Environment from nowhere... OK




This is the message that we get as well when this patch is not added.


It means you are booting out of QSPI but qspi is not accessible by u-boot. 
Correct?



prio is my print to show where code is. Qemu boots out in QSPI boot
mode and SPI is tried first and because
this is xilinx_zynq_virt defconfig drivers/env locations for other
devices are present too. That's why it goes over the list
and it always ends in nowhere which never fails.

If this runs on real HW then the same behavior is visible and I don't
think it is right.
I think this solution should be rethought.
In product current behavior from our code is not the best and current
U-Boot implementation is not allowing
flexibility too. We are enabling redundant variables which can be
only
on the same device but not that you have
one copy in QSPI and second in EMMC.
That's why I think location should be pretty much read from DT.
There is options/u-boot node where location of variables should be
described and this should replace
env_get_location().


You mean that there should be some type of new U-Boot node that
describes where the environment should be located and go and
search in this device?


Not sure if node or just dt property which points where that variables are 
stored.



It is a lot of work that's why I think second solution is more
reasonable for you which is simply create new Kconfig symbol
to disable board env_get_location() implementation.

Thanks,
Michal



You mean to basically disable the board env_get_location() that
exists in board/xilinx/zynqmp/zynqmp.c for example?


yes. Something like this.

config BOARD_ENV_LOCATION
bool "Use board defined ENV location"
default y
...

if defined (BOARD_ENV_SETUP/LOCATION)
enum env_location env_get_location(enum env_operation op, int prio)
{
...
}
endif

M


--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs

[PATCH 2/2] rockchip: puma-rk3399: get closer to other Theobroma defconfigs

From: Quentin Schulz 

Disable support for unused OSes as Linux is the primary target.

Disable support for bootz as zImage isn't a format compatible with
Aarch64 machines so it should never be attempted to be booted.

Enable a bunch of commands:
 - erofs
 - gpio
 - squashfs

that could be useful and are also found in Jaguar and Tiger defconfigs.

Signed-off-by: Quentin Schulz 
---
 configs/puma-rk3399_defconfig | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 34a0b575991..3196b5e24b1 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -29,7 +29,12 @@ CONFIG_SPL_I2C=y
 CONFIG_SPL_POWER=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_TPL=y
-CONFIG_CMD_BOOTZ=y
+# CONFIG_BOOTM_NETBSD is not set
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_CMD_VBE is not set
+# CONFIG_BOOTM_VXWORKS is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
@@ -41,6 +46,8 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_EROFS=y
+CONFIG_CMD_SQUASHFS=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_OVERWRITE=y

-- 
2.45.2

[PATCH 1/2] rockchip: ringneck-px30: get closer to other Theobroma defconfigs

From: Quentin Schulz 

RK3588 Jaguar and Tiger, and RK3399 Puma use standard boot with the full
feature set, so let's do that as well for PX30 Ringneck.

Disable support for unused OSes as Linux is the primary target.

Enable a bunch of commands:
 - boot/bootd
 - erofs
 - gpio
 - iminfo
 - imxtract
 - itest
 - pmic
 - regulator
 - sleep
 - squashfs

that could be useful and are also found in Jaguar and Tiger defconfigs.

Signed-off-by: Quentin Schulz 
---
 configs/ringneck-px30_defconfig | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig
index dedf35d4347..a0c1fec0951 100644
--- a/configs/ringneck-px30_defconfig
+++ b/configs/ringneck-px30_defconfig
@@ -20,6 +20,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_BOOTSTD_FULL=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/px30-ringneck-haikou.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
@@ -34,12 +35,15 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_ATF=y
 # CONFIG_TPL_FRAMEWORK is not set
 # CONFIG_TPL_SYS_MALLOC_SIMPLE is not set
-# CONFIG_CMD_BOOTD is not set
+# CONFIG_BOOTM_NETBSD is not set
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_CMD_VBE is not set
+# CONFIG_BOOTM_VXWORKS is not set
 # CONFIG_CMD_ELF is not set
-# CONFIG_CMD_IMI is not set
-# CONFIG_CMD_XIMG is not set
 # CONFIG_CMD_LZMADEC is not set
 # CONFIG_CMD_UNZIP is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
 # CONFIG_CMD_LOADB is not set
@@ -47,9 +51,11 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-# CONFIG_CMD_ITEST is not set
 # CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_SLEEP is not set
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_EROFS=y
+CONFIG_CMD_SQUASHFS=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_ISO_PARTITION is not set
 CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64

-- 
2.45.2

[PATCH 0/2] rockchip: puma-rk3399/ringneck-px30: make closer to Jaguar/Tiger defconfigs

To ease maintenance, limit test scenarios and variations, let's enable a
few things:
 - full bootstd
 - a handful of CLI commands like gpio, squashfs, erofs, pmic,
   regulator, and the likes.

This also disables support for non-Linux OSes as Linux is the primary
target, we may revisit this in the future if necessary.

Also disables support for zImage on Puma since those aren't supported on
Aarch64, one is supposed to use Image.gz (or any other supported
compression format) with booti instead.

Signed-off-by: Quentin Schulz 
---
Quentin Schulz (2):
  rockchip: ringneck-px30: get closer to other Theobroma defconfigs
  rockchip: puma-rk3399: get closer to other Theobroma defconfigs

 configs/puma-rk3399_defconfig   |  9 -
 configs/ringneck-px30_defconfig | 16 +++-
 2 files changed, 19 insertions(+), 6 deletions(-)
---
base-commit: 787eaa9c8df2660c748358eb689de916f991e22e
change-id: 20240612-ringneck-bootd-ea9126a0e108

Best regards,
-- 
Quentin Schulz

Re: [U-boot] [PATCH 01/13] arch: arm: dts: k3-am625-phyboard-lyra: Add fixed partitions

2024-06-12 Thread Wadim Egorov





Am 11.06.24 um 10:08 schrieb Teresa Remmet:

Hello Wadim,

Am Montag, dem 10.06.2024 um 15:33 +0200 schrieb Wadim Egorov:


From: Nathan Morrisson 

Add a fixed partitions node to the AM62x device tree so that it can
be used to fixup the Linux device tree.


for which branch is this series?


This patch is for u-boot/next
Somehow it landed also on our internal list, sorry for that.




Regards,
Teresa



Signed-off-by: Nathan Morrisson 
Signed-off-by: Wadim Egorov 
---
  .../k3-am625-phyboard-lyra-rdk-u-boot.dtsi    | 26
+++
  1 file changed, 26 insertions(+)

diff --git a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
index 94162282068..7c76acc0d59 100644
--- a/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-phyboard-lyra-rdk-u-boot.dtsi
@@ -127,6 +127,32 @@
  
 flash@0 {

 bootph-all;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "ospi.tiboot3";
+   reg = <0x0 0x8>;
+   };
+   partition@8 {
+   label = "ospi.tispl";
+   reg = <0x08 0x20>;
+   };
+   partition@28 {
+   label = "ospi.u-boot";
+   reg = <0x28 0x40>;
+   };
+   partition@68 {
+   label = "ospi.env";
+   reg = <0x68 0x4>;
+   };
+   partition@6c {
+   label = "ospi.env.backup";
+   reg = <0x6c 0x4>;
+   };
+   };
 };
  };

Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of

2024-06-12 Thread Vasileios Amoiridis

On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote:
> Hi Vasileios,
> 
> út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis
>  napsal:
> > 
> > From: Vasileios Amoiridis 
> > 
> > Changes in v2:
> >     - Remove duplication of custom hardcoded env_locations[]
> > code.
> >     - Add implementation with general arch_env_get_location(op,
> > prio)
> > 
> > v1:
> > https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/
> > 
> > Vasileios Amoiridis (1):
> >   xilinx: Add option to load environment from outside of boot media
> > 
> >  board/xilinx/versal-net/board.c | 47 ++--
> >  board/xilinx/versal/board.c | 47 ++--
> >  board/xilinx/zynq/board.c   | 49 +++--
> >  board/xilinx/zynqmp/zynqmp.c    | 55 +
> > 
> >  4 files changed, 101 insertions(+), 97 deletions(-)
> > 
> > --
> > 2.34.1
> > 
> 
> I have to remove this patch from my queue because it is actually
> breaking current behavior.
> CI is reporting an issue with it and I did a closer look and what is
> happening is that if one location has no valid
> data it goes and looks at another location from the list.
> 

But that is the desired behavior, if the environment is not in one
location to check to the others.

> On Zynq it behaves like this.
> 
> MMC:   mmc@e010: 0
> prio 0
> Loading Environment from SPIFlash... SF: Detected n25q128a13 with
> page
> size 256 Bytes, erase size 64 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
> 
> prio 1
> Loading Environment from NAND... *** Error - No Valid Environment
> Area found
> *** Warning - bad env area, using default environment
> 
> prio 2
> Loading Environment from SPIFlash... *** Warning - bad CRC, using
> default environment
> 
> prio 3
> Loading Environment from nowhere... OK
> 
> 

This is the message that we get as well when this patch is not added.

> prio is my print to show where code is. Qemu boots out in QSPI boot
> mode and SPI is tried first and because
> this is xilinx_zynq_virt defconfig drivers/env locations for other
> devices are present too. That's why it goes over the list
> and it always ends in nowhere which never fails.
> 
> If this runs on real HW then the same behavior is visible and I don't
> think it is right.
> I think this solution should be rethought.
> In product current behavior from our code is not the best and current
> U-Boot implementation is not allowing
> flexibility too. We are enabling redundant variables which can be
> only
> on the same device but not that you have
> one copy in QSPI and second in EMMC.
> That's why I think location should be pretty much read from DT.
> There is options/u-boot node where location of variables should be
> described and this should replace
> env_get_location().

You mean that there should be some type of new U-Boot node that
describes where the environment should be located and go and
search in this device?

> It is a lot of work that's why I think second solution is more
> reasonable for you which is simply create new Kconfig symbol
> to disable board env_get_location() implementation.
> 
> Thanks,
> Michal
> 

You mean to basically disable the board env_get_location() that
exists in board/xilinx/zynqmp/zynqmp.c for example?

Cheers,
Vasilis

Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of

2024-06-12 Thread Michal Simek

Hi Vasileios,

út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis
 napsal:
>
> From: Vasileios Amoiridis 
>
> Changes in v2:
> - Remove duplication of custom hardcoded env_locations[] code.
> - Add implementation with general arch_env_get_location(op, prio)
>
> v1: 
> https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/
>
> Vasileios Amoiridis (1):
>   xilinx: Add option to load environment from outside of boot media
>
>  board/xilinx/versal-net/board.c | 47 ++--
>  board/xilinx/versal/board.c | 47 ++--
>  board/xilinx/zynq/board.c   | 49 +++--
>  board/xilinx/zynqmp/zynqmp.c| 55 +
>  4 files changed, 101 insertions(+), 97 deletions(-)
>
> --
> 2.34.1
>

I have to remove this patch from my queue because it is actually
breaking current behavior.
CI is reporting an issue with it and I did a closer look and what is
happening is that if one location has no valid
data it goes and looks at another location from the list.

On Zynq it behaves like this.

MMC:   mmc@e010: 0
prio 0
Loading Environment from SPIFlash... SF: Detected n25q128a13 with page
size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

prio 1
Loading Environment from NAND... *** Error - No Valid Environment Area found
*** Warning - bad env area, using default environment

prio 2
Loading Environment from SPIFlash... *** Warning - bad CRC, using
default environment

prio 3
Loading Environment from nowhere... OK

prio is my print to show where code is. Qemu boots out in QSPI boot
mode and SPI is tried first and because
this is xilinx_zynq_virt defconfig drivers/env locations for other
devices are present too. That's why it goes over the list
and it always ends in nowhere which never fails.

If this runs on real HW then the same behavior is visible and I don't
think it is right.
I think this solution should be rethought.
In product current behavior from our code is not the best and current
U-Boot implementation is not allowing
flexibility too. We are enabling redundant variables which can be only
on the same device but not that you have
one copy in QSPI and second in EMMC.
That's why I think location should be pretty much read from DT.
There is options/u-boot node where location of variables should be
described and this should replace
env_get_location().
It is a lot of work that's why I think second solution is more
reasonable for you which is simply create new Kconfig symbol
to disable board env_get_location() implementation.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Where to put DTB file for UEFI support on ARM

2024-06-12 Thread Leith Bade

Hi all,

I have a BananaPi BPI-R3 board that I am setting up to boot Ubuntu or
Debian. After figuring out the required config options I have managed to
get Uboot to boot the Ubuntu USB installer, and also boot off an SD card
once I installed Ubuntu there.

I set up the bootmeth/bootdev/bootflow stuff so that the auto boot menu
works nicely with SD card. For USB I have to drop to console and do manual
"usb start" etc, but good enough for running the installer. It was a bit
difficult as there seems to be a lot of older documentation or Google
results related to using UEFI before the bootflow stuff was added. Also it
took me a while to figure out that a board/mediatek/mt7986.env file is now
needed as some of the config options set #define values that are not
included in /include/configs/mt7986.h board headers - due to .env files
replacing those #defines. It would be nice to have a default .env file for
this board that sets sensible defaults for the various memory loading
addresses as it took a bit of effort to come up with all the hex values.

However I am struggling to work out where to place the device tree DTB file
for the Linux kernel. For this board I need a different DTB for
U-boot (which is included in the u-boot.bin and fip.bin) and the kernel as
U-boot's drivers do not like the Linux upstream device tree.

I can see in the UEFI bootmeth code that it searches a location /dtb/ for a
file named in the $fdtfile environment variable. I tried putting the .dtb
file at /dtb/mt7986a-bananapi-bpi-r3.dtb on the SD card's FAT32 partition
that Ubuntu created, however it doesn't seem to load this and the U-boot
boots with the u-boot.bin DTB which means kernel doesn't start If I
manually load the correct .dtb file to $fdt_addr_r then the correct DTB is
used and the kernel starts.

What is the correct location for the .dtb file when using UEFI?

Is there a recommended way of putting the kernel DTB into the NAND or NOR
chip when using UEFI? That way if the SD card gets wiped U-boot can still
boot the USB drive. I don't fully understand how the MTD partitions, FIT
files, UBI files all fit into the picture to have U-boot load the kernel
DTB from flash.

Thanks,
Leith Bade
le...@bade.nz

[PATCH] arm: dts: corstone1000: enable secondary cores for FVP

2024-06-12 Thread harsimransingh . tungal

From: Harsimran Singh Tungal 

Add the secondary cores nodes in the dts file

Signed-off-by: Harsimran Singh Tungal 
Cc: Tom Rini 
Cc: Rui Miguel Silva 
---
 arch/arm/dts/corstone1000-fvp.dts | 25 +
 arch/arm/dts/corstone1000.dtsi|  2 +-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/corstone1000-fvp.dts 
b/arch/arm/dts/corstone1000-fvp.dts
index 26b0f1b3ce..3076fb9f34 100644
--- a/arch/arm/dts/corstone1000-fvp.dts
+++ b/arch/arm/dts/corstone1000-fvp.dts
@@ -49,3 +49,28 @@
clock-names = "smclk", "apb_pclk";
};
 };
+
+&cpus {
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a35";
+   reg = <0x1>;
+   enable-method = "psci";
+   next-level-cache = <&L2_0>;
+   };
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a35";
+   reg = <0x2>;
+   enable-method = "psci";
+   next-level-cache = <&L2_0>;
+   };
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a35";
+   reg = <0x3>;
+   enable-method = "psci";
+   next-level-cache = <&L2_0>;
+   };
+};
+
diff --git a/arch/arm/dts/corstone1000.dtsi b/arch/arm/dts/corstone1000.dtsi
index 1e0ec075e4..5d9d95b21c 100644
--- a/arch/arm/dts/corstone1000.dtsi
+++ b/arch/arm/dts/corstone1000.dtsi
@@ -21,7 +21,7 @@
stdout-path = "serial0:115200n8";
};
 
-   cpus {
+   cpus: cpus {
#address-cells = <1>;
#size-cells = <0>;
 
-- 
2.25.1

[PATCH v2 12/14] arm: dts: Introduce J722S U-Boot dts files

Include the uboot device tree files needed to boot the board.

Co-developed-by: Vaishnav Achath 
Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
 arch/arm/dts/Makefile  |2 +
 arch/arm/dts/k3-j722s-binman.dtsi  |  172 ++
 arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi | 2795 
 arch/arm/dts/k3-j722s-evm-u-boot.dtsi  |   18 +
 arch/arm/dts/k3-j722s-r5-evm.dts   |   82 +
 5 files changed, 3069 insertions(+)
 create mode 100644 arch/arm/dts/k3-j722s-binman.dtsi
 create mode 100644 arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi
 create mode 100644 arch/arm/dts/k3-j722s-evm-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-j722s-r5-evm.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cef42ab53a..86d9f133ba 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1191,6 +1191,8 @@ dtb-$(CONFIG_SOC_K3_J721S2) += 
k3-am68-sk-r5-base-board.dtb\
 dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-r5-sk.dtb \
   k3-j784s4-r5-evm.dtb
 
+dtb-$(CONFIG_SOC_K3_J722S) += k3-j722s-r5-evm.dtb
+
 dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-r5-evm.dtb \
  k3-am642-r5-sk.dtb \
  k3-am642-r5-phycore-som-2gb.dtb
diff --git a/arch/arm/dts/k3-j722s-binman.dtsi 
b/arch/arm/dts/k3-j722s-binman.dtsi
new file mode 100644
index 00..28087a3b6f
--- /dev/null
+++ b/arch/arm/dts/k3-j722s-binman.dtsi
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#if IS_ENABLED(CONFIG_TARGET_J722S_R5_EVM)
+
+&binman {
+   tiboot3-j722s-hs-fs-evm.bin {
+   filename = "tiboot3-j722s-hs-fs-evm.bin";
+   symlink = "tiboot3.bin";
+
+   ti-secure-rom {
+   content = <&u_boot_spl_fs>, <&ti_fs_enc_fs>, 
<&combined_tifs_cfg_fs>,
+ <&combined_dm_cfg_fs>, <&sysfw_inner_cert_fs>;
+   combined;
+   dm-data;
+   sysfw-inner-cert;
+   keyfile = "custMpk.pem";
+   sw-rev = <1>;
+   content-sbl = <&u_boot_spl_fs>;
+   content-sysfw = <&ti_fs_enc_fs>;
+   content-sysfw-data = <&combined_tifs_cfg_fs>;
+   content-sysfw-inner-cert = <&sysfw_inner_cert_fs>;
+   content-dm-data = <&combined_dm_cfg_fs>;
+   load = <0x43c0>;
+   load-sysfw = <0x4>;
+   load-sysfw-data = <0x67000>;
+   load-dm-data = <0x43c7a800>;
+   };
+
+   u_boot_spl_fs: u-boot-spl {
+   no-expanded;
+   };
+
+   ti_fs_enc_fs: ti-fs-enc.bin {
+   filename = 
"ti-sysfw/ti-fs-firmware-j722s-hs-fs-enc.bin";
+   type = "blob-ext";
+   optional;
+   };
+
+   combined_tifs_cfg_fs: combined-tifs-cfg.bin {
+   filename = "combined-tifs-cfg.bin";
+   type = "blob-ext";
+   };
+
+   sysfw_inner_cert_fs: sysfw-inner-cert {
+   filename = 
"ti-sysfw/ti-fs-firmware-j722s-hs-fs-cert.bin";
+   type = "blob-ext";
+   optional;
+   };
+
+   combined_dm_cfg_fs: combined-dm-cfg.bin {
+   filename = "combined-dm-cfg.bin";
+   type = "blob-ext";
+   };
+   };
+};
+#endif /*CONFIG_TARGET_J722S_R5_EVM*/
+
+#if IS_ENABLED(CONFIG_TARGET_J722S_A53_EVM)
+
+#define SPL_J722S_EVM_DTB "spl/dts/ti/k3-j722s-evm.dtb"
+#define J722S_EVM_DTB "u-boot.dtb"
+
+&binman {
+   ti-dm {
+   filename = "ti-dm.bin";
+
+   blob-ext {
+   filename = 
"ti-dm/j722s/ipc_echo_testb_mcu1_0_release_strip.xer5f";
+   optional;
+   };
+   };
+
+   ti-spl {
+   insert-template = <&ti_spl_template>;
+
+   fit {
+   images {
+   dm {
+   ti-secure {
+   content = <&dm>;
+   keyfile = "custMpk.pem";
+   };
+
+   dm: ti-dm {
+   filename = "ti-dm.bin";
+   };
+   };
+
+   fdt-0 {
+   description = "k3-j722s-evm";
+   type = "flat_dt";
+   arch = "arm";
+

Re: [PATCH 42/42] CI: Allow running tests on sjg lab

2024-06-12 Thread Andrejs Cainikovs

On Tue, Jun 11, 2024 at 02:01:56PM -0600, Simon Glass wrote:
> Add a way to run tests on a real hardware lab. This is in the very early
> experimental stages. There are only 23 boards and 3 of those are broken!
> (bob, ff3399, samus). A fourth fails due to problems with the TPM tests.
> 
> To try this, assuming you have gitlab access, set SJG_LAB=1, e.g.:
> 
>git push -o ci.variable="SJG_LAB=1" dm HEAD:try
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  .gitlab-ci.yml | 151 +
>  1 file changed, 151 insertions(+)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 165f765a833..6c362340341 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -17,6 +17,7 @@ stages:
>- testsuites
>- test.py
>- world build
> +  - sjg-lab
>  
>  .buildman_and_testpy_template: &buildman_and_testpy_dfn
>stage: test.py
> @@ -482,3 +483,153 @@ coreboot test.py:
>  TEST_PY_TEST_SPEC: "not sleep"
>  TEST_PY_ID: "--id qemu"
><<: *buildman_and_testpy_dfn
> +
> +.lab_template: &lab_dfn
> +  stage: sjg-lab
> +  rules:
> +- when: always
> +  tags: [ 'lab' ]
> +  script:
> +- if [[ -z "${SJG_LAB}" ]]; then
> +exit 0;
> +  fi

Hi Simon,

Perhaps it would be better to move the check to rules:if?
I do know there's a lot of GitLab CI limitation when it comes to
variables, so not completely sure if this will work, but:

rules:
  - if: $SJG_LAB == "1"
when: always
  - when: manual

My concern is that every of these jobs you added will spin up a docker
image even if you don't want to.

/Andrejs

> +# Environment:
> +#   SRC  - source tree
> +#   OUT  - output directory for builds
> +- export SRC="$(pwd)"
> +- export OUT="${SRC}/build/${BOARD}"
> +- export PATH=$PATH:~/bin
> +- export PATH=$PATH:/vid/software/devel/ubtest/u-boot-test-hooks/bin
> +
> +# Load it on the device
> +- ret=0
> +- echo "role ${ROLE}"
> +- export strategy="-s uboot -e off"
> +# export verbose="-v"
> +- ${SRC}/test/py/test.py --role ${ROLE} --build-dir "${OUT}"
> +--capture=tee-sys -k "not bootstd"|| ret=$?
> +- U_BOOT_BOARD_IDENTITY="${ROLE}" u-boot-test-release || true
> +- if [[ $ret -ne 0 ]]; then
> +exit $ret;
> +  fi
> +  artifacts:
> +when: always
> +paths:
> +  - "build/${BOARD}/test-log.html"
> +  - "build/${BOARD}/multiplexed_log.css"
> +expire_in: 1 week
> +
> +rpi3:
> +  variables:
> +ROLE: rpi3
> +  <<: *lab_dfn
> +
> +opi_pc:
> +  variables:
> +ROLE: opi_pc
> +  <<: *lab_dfn
> +
> +pcduino3_nano:
> +  variables:
> +ROLE: pcduino3_nano
> +  <<: *lab_dfn
> +
> +samus:
> +  variables:
> +ROLE: samus
> +  <<: *lab_dfn
> +
> +link:
> +  variables:
> +ROLE: link
> +  <<: *lab_dfn
> +
> +jerry:
> +  variables:
> +ROLE: jerry
> +  <<: *lab_dfn
> +
> +minnowmax:
> +  variables:
> +ROLE: minnowmax
> +  <<: *lab_dfn
> +
> +opi_pc2:
> +  variables:
> +ROLE: opi_pc2
> +  <<: *lab_dfn
> +
> +bpi:
> +  variables:
> +ROLE: bpi
> +  <<: *lab_dfn
> +
> +rpi2:
> +  variables:
> +ROLE: rpi2
> +  <<: *lab_dfn
> +
> +bob:
> +  variables:
> +ROLE: bob
> +  <<: *lab_dfn
> +
> +ff3399:
> +  variables:
> +ROLE: ff3399
> +  <<: *lab_dfn
> +
> +coral:
> +  variables:
> +ROLE: coral
> +  <<: *lab_dfn
> +
> +rpi3z:
> +  variables:
> +ROLE: rpi3z
> +  <<: *lab_dfn
> +
> +bbb:
> +  variables:
> +ROLE: bbb
> +  <<: *lab_dfn
> +
> +kevin:
> +  variables:
> +ROLE: kevin
> +  <<: *lab_dfn
> +
> +pine64:
> +  variables:
> +ROLE: pine64
> +  <<: *lab_dfn
> +
> +c4:
> +  variables:
> +ROLE: c4
> +  <<: *lab_dfn
> +
> +rpi4:
> +  variables:
> +ROLE: rpi4
> +  <<: *lab_dfn
> +
> +rpi0:
> +  variables:
> +ROLE: rpi0
> +  <<: *lab_dfn
> +
> +snow:
> +  variables:
> +ROLE: snow
> +  <<: *lab_dfn
> +
> +pcduino3:
> +  variables:
> +ROLE: pcduino3
> +  <<: *lab_dfn
> +
> +nyan-big:
> +  variables:
> +ROLE: nyan-big
> +  <<: *lab_dfn
> -- 
> 2.34.1
>

Re: [PATCH 00/42] labgrid: Provide an integration with Labgrid

2024-06-12 Thread Ilias Apalodimas

Hi Simon

On Tue, 11 Jun 2024 at 23:02, Simon Glass  wrote:
>
> Labgrid provides access to a hardware lab in an automated way. It is
> possible to boot U-Boot on boards in the lab without physically touching
> them. It relies on relays, USB UARTs and SD muxes, among other things.
>
> By way of background, about 4 years ago I wrong a thing called Labman[1]
> which allowed my lab of about 30 devices to be operated remotely, using
> tbot for the console and build integration. While it worked OK and I
> used it for many bisects, I didn't take it any further.
>
> It turns out that there was already an existing program, called Labgrid,
> which I did not know about at time (thank you Tom for telling me). It is
> more rounded than Labman and has a number of advantages:
>
> - does not need udev rules, mostly
> - has several existing users who rely on it
> - supports multiple machines exporting their devices
>
> It lacks a 'lab check' feature and a few other things, but these can be
> remedied.
>
> On and off over the past several weeks I have been experimenting with
> Labgrid. I have managed to create an initial U-Boot integration (this
> series) by adding various features to Labgrid[2] and the U-Boot test
> hooks.
>
> I hope that this might inspire others to set up boards and run tests
> automatically, rather than relying on infrequent, manual test. Perhaps
> it may even be possible to have a number of labs available.
>
> Included in the integration are a number of simple scripts which make it
> easy to connect to boards and run tests:
>
> ub-int 
> Build and boot on a target, starting an interactive session
>
> ub-cli 
> Build and boot on a target, ensure U-Boot starts and provide an 
> interactive
> session from there
>
> ub-smoke 
> Smoke test U-Boot to check that it boots to a prompt on a target
>
> ub-bisect
> Bisect a git tree to locate a failure on a particular target
>
> ub-pyt  
> Run U-Boot pytests on a target
>
> Some of these help to provide the same tbot[4] workflow which I have
> relied on for several years, albeit much simpler versions.
>
> The goal here is to create some sort of script which can collect
> patches from the mailing list, apply them and test them on a selection
> of boards. I suspect that script already exists, so please let me know
> what you suggest.
>
> I hope you find this interesting and take a look!

Thanks this is interesting!
I only got cc'ed on the cover letter and I'll slowly have a look on
the rest. A naive question -- I saw you did integrate this on gitlab
with your internal lab. How secure is this? Could we schedule weekly
builds that run on various remote labs and get results on actual
hardware? Or do we have to rely on users for that ?

Thanks
/Ilias

>
> [1] https://github.com/sjg20/u-boot/tree/lab6a
> [2] https://github.com/labgrid-project/labgrid/pull/1411
> [3] https://github.com/sjg20/uboot-test-hooks/tree/labgrid
> [4] https://tbot.tools/index.html
>
>
> Simon Glass (42):
>   trace: Update test to tolerate different trace-cmd version
>   binman: efi: Correct entry docs
>   binman: Regenerate nxp docs
>   binman: ti: Regenerate entry docs
>   binman: Update the entrydocs header
>   buildman: Make mrproper an argument to _reconfigure()
>   buildman: Make mrproper an argument to _config_and_build()
>   buildman: Make mrproper an argument to run_commit()
>   buildman: Avoid rebuilding when --mrproper is used
>   buildman: Add a flag to force mrproper on failure
>   buildman: Retry the build for current source
>   buildman: Add a way to limit the number of buildmans
>   dm: core: Enhance comments on bind_drivers_pass()
>   initcall: Correct use of relocation offset
>   am33xx: Provide a function to set up the debug UART
>   sunxi: Mark scp as optional
>   google: Disable TPMv2 on most Chromebooks
>   meson: Correct driver declaration for meson_axg_gpio
>   test: Allow signaling that U-Boot is ready
>   test: Make bootstd init run only on sandbox
>   test: Use a constant for the test timeout
>   test: Pass stderr to stdout
>   test: Release board after tests complete
>   log: Allow tests to pass with CONFIG_LOGF_FUNC_PAD set
>   test: Allow connecting to a running board
>   test: Decode exceptions only with sandbox
>   test: Avoid failing skipped tests
>   test: dm: Show failing driver name
>   test: Check help output
>   test: Create a common function to get the config
>   test: Introduce the concept of a role
>   test: Move the receive code into a function
>   test: Separate out the exception handling
>   test: Detect dead connections
>   test: Tidy up remaining exceptions
>   test: Introduce lab mode
>   test: Improve handling of sending commands
>   test: Fix mulptiplex_log typo
>   test: Avoid double echo when starting up
>   test: Try to shut down the lab console gracefully
>   test: Add a section for closing the connection
>   CI: Allow running tests on sjg lab
>
>  .gitlab-ci.yml| 151 +
>  a

Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)

2024-06-12 Thread Rasmus Villemoes

On 12/06/2024 12.20, Claudius Heine wrote:
> Hi everyone,
> 
> in the past we used cgit, which provided cloning the u-boot repo via
> http, https, ssh and the git protocol.
> 
> When we migrated to gitlab, which doesn't support the git protocol, we
> implemented some additional service files to continue to support it for
> some of our git repositories.
> 
> We just noticed that cloning via the git protocol is currently broken,
> likely some changes in gitlab happened and we would need to recreate the
> symlinks on the server to point to the right repositories again.
> 
> Since that is another thing to maintain and keep up, we would like to
> just shut the git protocol down. AFAIK most projects moved to use https
> for cloning anyway, since there were not many reports of broken cloning.
> 
> What are your thoughts? Is it worth the effort to keep the git protocol up?

So I don't think you should necessarily keep the git:// working if it
means extra maintenance. I just checked a couple of my local copies of
u-boot.git (don't ask, it's many different customer projects) and it
seems to be more or less random if I added upstream with git:// or
https:// . I can certainly change those, and thanks for the heads up.

I'm just wondering if it's possible to have the server send some message
to the client when the git protocol is used, for some deprecation period
(6 months?), so a developer doing "git remote update" will get notified.
He would then also have a chance to propagate that to whatever local CI
he's responsible for, instead of only noticing when things do start
breaking.

Rasmus

[PATCH v2 2/2] board: ti: am64x: Set storage_interface and fw_dev_part ENVs

2024-06-12 Thread MD Danish Anwar

When ICSSG driver is enabled (CONFIG_TI_ICSSG_PRUETH=y) set
storage_interface and fw_dev_part env variables.

These variables need be set appropriately in order to load different
ICSSG firmwares needed for ICSSG driver. By default the storage
interface is mmc and the partition is 1:2. User can modify this based on
their needs.

Signed-off-by: MD Danish Anwar 
---
 board/ti/am64x/am64x.env | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index 9a8812d4ee..8ad805a613 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -39,3 +39,8 @@ usbboot=setenv boot usb;
run get_kern_usb;
run get_fdt_usb;
run run_kern;
+
+#if CONFIG_TI_ICSSG_PRUETH
+storage_interface=mmc
+fw_dev_part=1:2
+#endif
-- 
2.34.1

[PATCH v2 1/2] configs: am64x_evm_a53: Enable ICSSG Driver

2024-06-12 Thread MD Danish Anwar

Enable ICSSG driver, DP83869 phy driver, REMOTEPROC and PRU_REMOTEPROC
in am64x_evm_a53_defconfig. All these configs are needed for ICSSG
driver.

Signed-off-by: MD Danish Anwar 
---
 configs/am64x_evm_a53_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index e000549d6d..6063286798 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -126,8 +126,10 @@ CONFIG_SPI_FLASH_MTD=y
 CONFIG_MULTIPLEXER=y
 CONFIG_MUX_MMIO=y
 CONFIG_PHY_TI_DP83867=y
+CONFIG_PHY_TI_DP83869=y
 CONFIG_PHY_FIXED=y
 CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_TI_ICSSG_PRUETH=y
 CONFIG_PHY=y
 CONFIG_SPL_PHY=y
 CONFIG_PHY_CADENCE_TORRENT=y
@@ -143,6 +145,8 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_TPS65219=y
 CONFIG_K3_SYSTEM_CONTROLLER=y
 CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_REMOTEPROC_TI_PRU=y
+CONFIG_CMD_REMOTEPROC=y
 CONFIG_RESET_TI_SCI=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_EMULATION=y
@@ -150,6 +154,7 @@ CONFIG_DM_SERIAL=y
 CONFIG_SOC_DEVICE=y
 CONFIG_SOC_DEVICE_TI_K3=y
 CONFIG_SOC_TI=y
+CONFIG_TI_PRUSS=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_CADENCE_QSPI=y
-- 
2.34.1

[PATCH v2 0/2] Enable ICSSG Driver for AM64x

2024-06-12 Thread MD Danish Anwar

This series adds config changes and env changes to enable ICSSG Ethernet
Driver on AM64x.

Changes since v1:
*) Dropped the patch [0] as this needs to be fixed in driver as suggested
   by Andrew Davis 
*) Rebased on latest u-boot/next.

v1 https://lore.kernel.org/all/20240522063652.3759497-1-danishan...@ti.com/
[0] https://lore.kernel.org/all/cb53651f-a823-41b8-81e5-c3939bd33...@ti.com/

Thanks and Regards,
MD Danish Anwar 

MD Danish Anwar (2):
  configs: am64x_evm_a53: Enable ICSSG Driver
  board: ti: am64x: Set storage_interface and fw_dev_part ENVs

 board/ti/am64x/am64x.env| 5 +
 configs/am64x_evm_a53_defconfig | 5 +
 2 files changed, 10 insertions(+)


base-commit: 9cf83a7da95b70a37d0d2aba79439dc8a2944fe3
-- 
2.34.1

Re: Shutting down of the git-daemon (git protocol, https and ssh still remain)

Hi Claudius,

On 6/12/24 12:20 PM, Claudius Heine wrote:

Hi everyone,

in the past we used cgit, which provided cloning the u-boot repo via
http, https, ssh and the git protocol.

When we migrated to gitlab, which doesn't support the git protocol, we
implemented some additional service files to continue to support it for
some of our git repositories.

We just noticed that cloning via the git protocol is currently broken,
likely some changes in gitlab happened and we would need to recreate the
symlinks on the server to point to the right repositories again.

Since that is another thing to maintain and keep up, we would like to
just shut the git protocol down. AFAIK most projects moved to use https
for cloning anyway, since there were not many reports of broken cloning.

What are your thoughts? Is it worth the effort to keep the git protocol up?

On the side of OpenEmbedded-Core, HTTPS is being used since Langdale
(4.1) and the first dot release of Kirkstone (4.0.1) so only outdated
layers would be impacted (provided they aren't already, but since
there's a download cache system in Yocto, it's possible they're hitting
their own local cache instead of fetching it from your server(s)).

It's never nice to see things going/breaking compatibility because it
may break old builds which is always a nice trick up one's sleeve to
figure out when things started to go wrong in one's image. Also, while I
checked OE-Core, other third party/community maintained layer could be
impacted. I assume this is the case of meta-amarula-engicam[1] and
meta-allwinner-hx[2] for example.

I would suggest sending a mail to the different build systems mailing
lists, I assume https://lists.openembedded.org/g/openembedded-devel and
https://lists.yoctoproject.org/g/yocto for the OE-Core/YP side? Either
to ask for their opinion or notify them (and specifically third party
layers) it's going away or both.

[1]
https://github.com/amarula/meta-amarula-engicam/blob/master/recipes-bsp/u-boot/u-boot-common_2018.05.inc
[2]
https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-bsp/u-boot/u-boot-common.inc

Cheers,
Quentin

Shutting down of the git-daemon (git protocol, https and ssh still remain)

2024-06-12 Thread Claudius Heine


Hi everyone,

in the past we used cgit, which provided cloning the u-boot repo via 
http, https, ssh and the git protocol.


When we migrated to gitlab, which doesn't support the git protocol, we 
implemented some additional service files to continue to support it for 
some of our git repositories.


We just noticed that cloning via the git protocol is currently broken, 
likely some changes in gitlab happened and we would need to recreate the 
symlinks on the server to point to the right repositories again.


Since that is another thing to maintain and keep up, we would like to 
just shut the git protocol down. AFAIK most projects moved to use https 
for cloning anyway, since there were not many reports of broken cloning.


What are your thoughts? Is it worth the effort to keep the git protocol up?

regards,
Claudius


--
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de

Re: [PATCH 5/6] bootstd: Add a bootmeth for Android

2024-06-12 Thread Mattijs Korpershoek

Hi Simon,

Thank you for your review.

On mar., juin 11, 2024 at 12:52, Simon Glass  wrote:

> Hi Mattijs,
>
> On Thu, 6 Jun 2024 at 06:24, Mattijs Korpershoek
>  wrote:
>>
>> Android boot flow is a bit different than a regular Linux distro.
>> Android relies on multiple partitions in order to boot.
>>
>> A typical boot flow would be:
>> 1. Parse the Bootloader Control Block (BCB, misc partition)
>> 2. If BCB requested bootonce-bootloader, start fastboot and wait.
>> 3. If BCB requested recovery or normal android, run the following:
>> 3.a. Get slot (A/B) from BCB
>> 3.b. Run AVB (Android Verified Boot) on boot partitions
>> 3.c. Load boot and vendor_boot partitions
>> 3.d. Load device-tree, ramdisk and boot
>>
>> The AOSP documentation has more details at [1], [2], [3]
>>
>> This has been implemented via complex boot scripts such as [4].
>> However, these boot script are neither very maintainable nor generic.
>> Moreover, DISTRO_DEFAULTS is being deprecated [5].
>>
>> Add a generic Android bootflow implementation for bootstd.
>> For this initial version, only boot image v4 is supported.
>>
>> [1] https://source.android.com/docs/core/architecture/bootloader
>> [2] https://source.android.com/docs/core/architecture/partitions
>> [3] https://source.android.com/docs/core/architecture/partitions/generic-boot
>> [4] 
>> https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h
>> [5] https://lore.kernel.org/r/all/20230914165615.1058529-17-...@chromium.org/
>>
>> Signed-off-by: Mattijs Korpershoek 
>> ---
>>  MAINTAINERS |   7 +
>>  boot/Kconfig|  14 ++
>>  boot/Makefile   |   2 +
>>  boot/bootmeth_android.c | 522 
>> 
>>  boot/bootmeth_android.h |  27 +++
>>  doc/develop/bootstd.rst |   6 +
>>  6 files changed, 578 insertions(+)
>
> Reviewed-by: Simon Glass 
>
> nits below
>
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 66783d636e3d..6d2b87720565 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -939,6 +939,13 @@ F: include/bootstd.h
>>  F: net/eth_bootdevice.c
>>  F: test/boot/
>>
>> +BOOTMETH_ANDROID
>> +M: Mattijs Korpershoek 
>> +S: Maintained
>> +T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git
>> +F: boot/bootmeth_android.c
>> +F: boot/bootmeth_android.h
>> +
>>  BTRFS
>>  M: Marek Behún 
>>  R: Qu Wenruo 
>> diff --git a/boot/Kconfig b/boot/Kconfig
>> index 6f3096c15a6f..5fa6f3b8315d 100644
>> --- a/boot/Kconfig
>> +++ b/boot/Kconfig
>> @@ -494,6 +494,20 @@ config BOOTMETH_GLOBAL
>>   EFI bootmgr, since they take full control over which bootdevs are
>>   selected to boot.
>>
>> +config BOOTMETH_ANDROID
>> +   bool "Bootdev support for Android"
>> +   depends on X86 || ARM || SANDBOX
>> +   select ANDROID_AB
>> +   select ANDROID_BOOT_IMAGE
>> +   select CMD_BCB
>> +   select PARTITION_TYPE_GUID
>> +   select PARTITION_UUIDS
>> +   help
>> + Enables support for booting Android using bootdevs. Android 
>> requires
>
> using standard boot (or using bootstd).

Will do for v2.

>
>> + multiple partitions (misc, boot, vbmeta, ...) in storage for 
>> booting.
>> +
>> + Note that only MMC bootdevs are supported at present.
>
> Why is that limitation present? Can you please mention what is needed
> to remove it?

Mainly because we use AVB and AVB is hard-coded for MMC. Alistair
submitted changes to convert to generic block devices here:

https://lore.kernel.org/all/20220926220211.868968-1-ade...@google.com/

There were some review comments but I did not see any v2 on the list.

I will add a comment in the KConfig description.

>
>> +
>>  config BOOTMETH_CROS
>> bool "Bootdev support for Chromium OS"
>> depends on X86 || ARM || SANDBOX
>> diff --git a/boot/Makefile b/boot/Makefile
>> index 84ccfeaecec4..75d1cd46fabf 100644
>> --- a/boot/Makefile
>> +++ b/boot/Makefile
>> @@ -66,3 +66,5 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_REQUEST) += 
>> vbe_request.o
>>  obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE) += vbe_simple.o
>>  obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_FW) += vbe_simple_fw.o
>>  obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_VBE_SIMPLE_OS) += vbe_simple_os.o
>> +
>> +obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_ANDROID) += bootmeth_android.o
>> diff --git a/boot/bootmeth_android.c b/boot/bootmeth_android.c
>> new file mode 100644
>> index ..26d548d2fd6e
>> --- /dev/null
>> +++ b/boot/bootmeth_android.c
>> @@ -0,0 +1,522 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Bootmethod for Android
>
> This is my fault, but I think we should settle on Bootmeth throughout.

Yes, thank you for noticing. Will do for v2.

>
>> + *
>> + * Copyright (C) 2024 BayLibre, SAS
>> + * Written by Mattijs Korpershoek 
>> + */
>> +#define LOG_CATEGORY UCLASS_BOOTSTD
>> +
>> +#include 
>> +#include 
>> +#if CONFIG_IS_ENABLED(AVB_VERIFY)
>> +#include 
>
> Can you include that he

Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM

2024-06-12 Thread Michael Nazzareno Trimarchi

Hi Marek

On Wed, Jun 12, 2024 at 11:32 AM Marek Vasut  wrote:
>
> On 6/3/24 5:07 PM, Patrick Barsanti wrote:
> > Always prioritizing u-boot includes causes problems when trying to migrate
> > boards to OF_UPSTREAM that have different local devicetree files with
> > respect to the upstream ones, if local DT headers are not dropped.
> > At the same time if local and upstream files are the same, migrations
> > can be, and have been, introduced without dropping local DT headers.
> > This also causes problems whenever upstream DTS and DT headers are patched.
> >
> > For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> > breaks it, as there are some missing defines in a local DT header file
> > (`imx6ul-clock.h`); the solution would be to drop it, which has not always
> > been done in previous OF_UPSTREAM migration patches for other boards
> > because most of the time the two are the same. This solution is also
> > vulnerable to ABI breakage, although this has not yet happened since the
> > introduction of OF_UPSTREAM support and is unlikely.
> >
> > Maintainers assure backwards compatibility for DT headers when syncing the
> > upstream folder with the kernel.
>
> ... upstream directory ...
>
> > The problem is that, at the current state, all boards that have not dropped
> > their local headers when migrating to OF_UPSTREAM will break once the
> > upstream devicetrees are patched, for example, to use any newly added
> > define which is not present in the local DT header file, even if those
> > changes are backwards compatible.
>
> Why not simply remove the headers ?
>

If we remove the headers then other boards that are not migrated, can
have some problem
on building. We should consider not only new boards but even those
that ones are still not migrated.
I think that is already described here

> Add a WARNING if there are local duplicates .
>

Why should a WARNING help here? We would like to have some migration
plans but not break them.

Michael


> [...]

Re: [PATCH 18/42] meson: Correct driver declaration for meson_axg_gpio

2024-06-12 Thread Neil Armstrong


On 11/06/2024 22:01, Simon Glass wrote:

This should use the driver macros so that the driver appears in the
linker list. Fix this.

Fixes: 8587839f19d ("pinctrl: meson: add axg support")

Signed-off-by: Simon Glass 
---

  drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 2 +-
  drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
  drivers/pinctrl/meson/pinctrl-meson-axg.h | 2 +-
  drivers/pinctrl/meson/pinctrl-meson-g12a.c| 4 ++--
  4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c 
b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
index 52c726cf038..15ebd574ef1 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c
@@ -179,7 +179,7 @@ static const struct dm_gpio_ops meson_axg_gpio_ops = {
.direction_output = meson_gpio_direction_output,
  };
  
-const struct driver meson_axg_gpio_driver = {

+U_BOOT_DRIVER(meson_axg_gpio) = {
.name   = "meson-axg-gpio",
.id = UCLASS_GPIO,
.probe  = meson_gpio_probe,
diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c 
b/drivers/pinctrl/meson/pinctrl-meson-axg.c
index 94e09cd3f8a..ed3f92b2d75 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-axg.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
@@ -939,7 +939,7 @@ struct meson_pinctrl_data meson_axg_periphs_pinctrl_data = {
.num_groups = ARRAY_SIZE(meson_axg_periphs_groups),
.num_funcs  = ARRAY_SIZE(meson_axg_periphs_functions),
.num_banks  = ARRAY_SIZE(meson_axg_periphs_banks),
-   .gpio_driver= &meson_axg_gpio_driver,
+   .gpio_driver= DM_DRIVER_REF(meson_axg_gpio),
.pmx_data   = &meson_axg_periphs_pmx_banks_data,
  };
  
@@ -953,7 +953,7 @@ struct meson_pinctrl_data meson_axg_aobus_pinctrl_data = {

.num_groups = ARRAY_SIZE(meson_axg_aobus_groups),
.num_funcs  = ARRAY_SIZE(meson_axg_aobus_functions),
.num_banks  = ARRAY_SIZE(meson_axg_aobus_banks),
-   .gpio_driver= &meson_axg_gpio_driver,
+   .gpio_driver= DM_DRIVER_REF(meson_axg_gpio),
.pmx_data   = &meson_axg_aobus_pmx_banks_data,
  };
  
diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.h b/drivers/pinctrl/meson/pinctrl-meson-axg.h

index c8d2b3af036..a6581bab500 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-axg.h
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg.h
@@ -61,6 +61,6 @@ struct meson_pmx_axg_data {
}
  
  extern const struct pinctrl_ops meson_axg_pinctrl_ops;

-extern const struct driver meson_axg_gpio_driver;
+extern U_BOOT_DRIVER(meson_axg_gpio);
  
  #endif /* __PINCTRL_MESON_AXG_H__ */

diff --git a/drivers/pinctrl/meson/pinctrl-meson-g12a.c 
b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
index 24f47f82558..67114df6824 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-g12a.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
@@ -1253,7 +1253,7 @@ static struct meson_pinctrl_data 
meson_g12a_periphs_pinctrl_data = {
.num_groups = ARRAY_SIZE(meson_g12a_periphs_groups),
.num_funcs  = ARRAY_SIZE(meson_g12a_periphs_functions),
.num_banks  = ARRAY_SIZE(meson_g12a_periphs_banks),
-   .gpio_driver= &meson_axg_gpio_driver,
+   .gpio_driver= DM_DRIVER_REF(meson_axg_gpio),
.pmx_data   = &meson_g12a_periphs_pmx_banks_data,
  };
  
@@ -1267,7 +1267,7 @@ static struct meson_pinctrl_data meson_g12a_aobus_pinctrl_data = {

.num_groups = ARRAY_SIZE(meson_g12a_aobus_groups),
.num_funcs  = ARRAY_SIZE(meson_g12a_aobus_functions),
.num_banks  = ARRAY_SIZE(meson_g12a_aobus_banks),
-   .gpio_driver= &meson_axg_gpio_driver,
+   .gpio_driver= DM_DRIVER_REF(meson_axg_gpio),
.pmx_data   = &meson_g12a_aobus_pmx_banks_data,
  };
  


Reviewed-by: Neil Armstrong

Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM

2024-06-12 Thread Marek Vasut


On 6/3/24 5:07 PM, Patrick Barsanti wrote:

Always prioritizing u-boot includes causes problems when trying to migrate
boards to OF_UPSTREAM that have different local devicetree files with
respect to the upstream ones, if local DT headers are not dropped.
At the same time if local and upstream files are the same, migrations
can be, and have been, introduced without dropping local DT headers.
This also causes problems whenever upstream DTS and DT headers are patched.

For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
breaks it, as there are some missing defines in a local DT header file
(`imx6ul-clock.h`); the solution would be to drop it, which has not always
been done in previous OF_UPSTREAM migration patches for other boards
because most of the time the two are the same. This solution is also
vulnerable to ABI breakage, although this has not yet happened since the
introduction of OF_UPSTREAM support and is unlikely.

Maintainers assure backwards compatibility for DT headers when syncing the
upstream folder with the kernel.


... upstream directory ...


The problem is that, at the current state, all boards that have not dropped
their local headers when migrating to OF_UPSTREAM will break once the
upstream devicetrees are patched, for example, to use any newly added
define which is not present in the local DT header file, even if those
changes are backwards compatible.


Why not simply remove the headers ?

Add a WARNING if there are local duplicates .

[...]

[PATCH v2 14/14] doc: board: ti: Add J722S-EVM documentation

Introduce basic documentation for the J722S-EVM.

Signed-off-by: Jayesh Choudhary 
Reviewed-by: Neha Malcom Francis 
---
 doc/board/ti/j722s_evm.rst | 260 +
 doc/board/ti/k3.rst|   1 +
 2 files changed, 261 insertions(+)
 create mode 100644 doc/board/ti/j722s_evm.rst

diff --git a/doc/board/ti/j722s_evm.rst b/doc/board/ti/j722s_evm.rst
new file mode 100644
index 00..10b243908a
--- /dev/null
+++ b/doc/board/ti/j722s_evm.rst
@@ -0,0 +1,260 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Jayesh Choudhary 
+
+J722S-EVM Platform
+==
+
+The J722S is a family of  application processors built for Automotive and
+Linux Application development. J722S family of SoCs is a superset of the
+AM62P SoC family and shares similar memory map, thus the nodes are being
+reused from AM62P includes instead of duplicating the definitions.
+
+Some highlights of J722S SoC (in addition to AM62P SoC features) are:
+
+* Two Cortex-R5F for Functional Safety or general-purpose usage and
+  two C7x floating point vector DSP with Matrix Multiply Accelerator
+  for deep learning.
+
+* Vision Processing Accelerator (VPAC) with image signal processor
+  and Depth and Motion Processing Accelerator (DMPAC).
+
+* 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
+  NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
+  4xCSI-RX for Camera, 1 PCIe Gen3 controller, USB3.0 eCAP/eQEP,
+  ePWM, among other peripherals.
+
+For those interested, more details about this SoC can be found in the
+Technical Reference Manual here: https://www.ti.com/lit/zip/sprujb3
+
+Boot Flow:
+--
+
+The bootflow is exactly the same as all SoCs in the am62xxx extended SoC
+family. Below is the pictorial representation:
+
+.. image:: img/boot_diagram_k3_current.svg
+  :alt: Boot flow diagram
+
+- Here TIFS acts as master and provides all the critical services. R5/A53
+  requests TIFS to get these services done as shown in the above diagram.
+
+Sources:
+
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_boot_sources
+:end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure:
+
+
+0. Setup the environment variables:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_desc
+:end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_board_env_vars_desc
+:end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_defn
+:end-before: .. k3_rst_include_end_common_env_vars_defn
+
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR=j722s_evm_r5_defconfig
+ $ export UBOOT_CFG_CORTEXA=j722s_evm_a53_defconfig
+ $ export TFA_BOARD=lite
+ $ export OPTEE_PLATFORM=k3-am62x
+ $ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
+
+.. j722s_evm_rst_include_start_build_steps
+
+1. Trusted Firmware-A:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_tfa
+:end-before: .. k3_rst_include_end_build_steps_tfa
+
+
+2. OP-TEE:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_optee
+:end-before: .. k3_rst_include_end_build_steps_optee
+
+3. U-Boot:
+
+* 3.1 R5:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_spl_r5
+:end-before: .. k3_rst_include_end_build_steps_spl_r5
+
+* 3.2 A53:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_build_steps_uboot
+:end-before: .. k3_rst_include_end_build_steps_uboot
+.. j722s_evm_rst_include_end_build_steps
+
+Target Images
+--
+
+In order to boot we need tiboot3.bin, tispl.bin and u-boot.img.  Each SoC
+variant (HS-FS, HS-SE) requires a different source for these files.
+
+ - HS-FS
+
+* tiboot3-j722s-hs-fs-evm.bin from step 3.1
+* tispl.bin, u-boot.img from step 3.2
+
+ - HS-SE
+
+* tiboot3-j722s-hs-evm.bin from step 3.1
+* tispl.bin, u-boot.img from step 3.2
+
+Image formats:
+--
+
+- tiboot3.bin
+
+.. image:: img/multi_cert_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
+
+- tispl.bin
+
+.. image:: img/dm_tispl.bin.svg
+  :alt: tispl.bin image format
+
+A53 SPL DDR Memory Layout
+-
+
+.. j722s_evm_rst_include_start_ddr_mem_layout
+
+This provides an overview memory usage in A53 SPL stage.
+
+.. list-table::
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - Region
+ - Start Address
+ - End Address
+
+   * - EMPTY
+ - 0x8000
+ - 0x8008
+
+   * - TEXT BASE
+ - 0x8008
+ - 0x800d8000
+
+   * - EMPTY
+ - 0x800d8000
+ - 0x80477660
+
+   * - STACK
+ - 0x80477660
+ - 0x80477e60
+
+   * - GD
+ - 0x80477e60
+ - 0x80478000
+
+   * - MALLOC
+

[PATCH v2 13/14] configs: introduce configs needed for the J722S

Introduce the initial configs needed to support the J722S SoC family.

Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
 configs/j722s_evm_a53_defconfig | 172 
 configs/j722s_evm_r5_defconfig  | 131 
 include/configs/j722s_evm.h |  14 +++
 3 files changed, 317 insertions(+)
 create mode 100644 configs/j722s_evm_a53_defconfig
 create mode 100644 configs/j722s_evm_r5_defconfig
 create mode 100644 include/configs/j722s_evm.h

diff --git a/configs/j722s_evm_a53_defconfig b/configs/j722s_evm_a53_defconfig
new file mode 100644
index 00..da0e9f4d52
--- /dev/null
+++ b/configs/j722s_evm_a53_defconfig
@@ -0,0 +1,172 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_GPIO=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_J722S=y
+CONFIG_TARGET_J722S_A53_EVM=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
+CONFIG_SF_DEFAULT_SPEED=2500
+CONFIG_ENV_SIZE=0x4
+CONFIG_DM_GPIO=y
+CONFIG_SPL_DM_SPI=y
+CONFIG_DEFAULT_DEVICE_TREE="ti/k3-j722s-evm"
+CONFIG_SPL_TEXT_BASE=0x8008
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x80a0
+CONFIG_SPL_BSS_MAX_SIZE=0x8
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
+CONFIG_BOOTSTD_FULL=y
+CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_SPL_MAX_SIZE=0x58000
+CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_DMA=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
+CONFIG_SPL_I2C=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+# CONFIG_SPL_SPI_FLASH_TINY is not set
+CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
+CONFIG_SPL_THERMAL=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_CLK=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_REMOTEPROC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_UBI=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_UPSTREAM=y
+CONFIG_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_DEVICE_REMOVE=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_DFU_MMC=y
+CONFIG_DFU_MTD=y
+CONFIG_DFU_RAM=y
+CONFIG_DFU_SF=y
+CONFIG_SYS_DFU_DATA_BUF_SIZE=0x4
+CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0xC000
+CONFIG_FASTBOOT_BUF_SIZE=0x2F00
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_SPL_DM_GPIO_LOOKUP_LABEL=y
+CONFIG_DA8XX_GPIO=y
+CONFIG_DM_PCA953X=y
+CONFIG_SPL_DM_PCA953X=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_OMAP24XX=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SPL_I2C_EEPROM=y
+CONFIG_FS_LOADER=y
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_SPL_MMC_IO_VOLTAGE=y
+CONFIG_MMC_HS400_SUPPORT=y
+CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_SPI_NAND=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_SOFT_RESET=y
+CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_S28HX_T=y
+CONFIG_PHY_TI_DP83867=y
+CONFIG_TI_AM65_CPSW_NUSS=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_DM_REGULATOR=y
+CONFIG_SPL_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_SPL_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_SPL_DM_REGULATOR_GPIO=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_REMOTEPROC_TI_K3_DSP=y
+CONFIG_REMOTEPROC_TI_K3_R5F=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_DM_THERMAL=y
+CONFIG_USB=y
+CONFIG_DM_USB_GADGET=y
+CONFIG_SPL_DM_USB_GADGET=y
+CONFIG_SPL_USB_HOST=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GENERIC=y
+CONFIG_SPL_USB_DWC3_GENERIC=y

[PATCH v2 10/14] board: ti: Introduce basic board files for the J722S family

Introduce the basic files needed to support the TI J722S family of SoCs.

Co-developed-by: Vaishnav Achath 
Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
 board/ti/j722s/Kconfig  |   26 +
 board/ti/j722s/MAINTAINERS  |9 +
 board/ti/j722s/Makefile |7 +
 board/ti/j722s/board-cfg.yaml   |   36 +
 board/ti/j722s/evm.c|   29 +
 board/ti/j722s/j722s.env|   15 +
 board/ti/j722s/pm-cfg.yaml  |   12 +
 board/ti/j722s/rm-cfg.yaml  | 1119 +++
 board/ti/j722s/sec-cfg.yaml |  379 +++
 board/ti/j722s/tifs-rm-cfg.yaml |  981 +++
 10 files changed, 2613 insertions(+)
 create mode 100644 board/ti/j722s/Kconfig
 create mode 100644 board/ti/j722s/MAINTAINERS
 create mode 100644 board/ti/j722s/Makefile
 create mode 100644 board/ti/j722s/board-cfg.yaml
 create mode 100644 board/ti/j722s/evm.c
 create mode 100644 board/ti/j722s/j722s.env
 create mode 100644 board/ti/j722s/pm-cfg.yaml
 create mode 100644 board/ti/j722s/rm-cfg.yaml
 create mode 100644 board/ti/j722s/sec-cfg.yaml
 create mode 100644 board/ti/j722s/tifs-rm-cfg.yaml

diff --git a/board/ti/j722s/Kconfig b/board/ti/j722s/Kconfig
new file mode 100644
index 00..68c214e473
--- /dev/null
+++ b/board/ti/j722s/Kconfig
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+#
+
+if TARGET_J722S_R5_EVM || TARGET_J722S_A53_EVM
+
+config SYS_BOARD
+   default "j722s"
+
+config SYS_VENDOR
+   default "ti"
+
+config SYS_CONFIG_NAME
+   default "j722s_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
+
+if TARGET_J722S_R5_EVM
+
+config SPL_LDSCRIPT
+   default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+endif
diff --git a/board/ti/j722s/MAINTAINERS b/board/ti/j722s/MAINTAINERS
new file mode 100644
index 00..7908c30def
--- /dev/null
+++ b/board/ti/j722s/MAINTAINERS
@@ -0,0 +1,9 @@
+J722S BOARD
+M: Vaishnav Achath 
+M: Jayesh Choudhary 
+M: Tom Rini 
+S: Maintained
+F: board/ti/j722s/
+F: include/configs/j722s_evm.h
+F: configs/j722s_evm_r5_defconfig
+F: configs/j722s_evm_a53_defconfig
diff --git a/board/ti/j722s/Makefile b/board/ti/j722s/Makefile
new file mode 100644
index 00..20d2ec934b
--- /dev/null
+++ b/board/ti/j722s/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += evm.o
diff --git a/board/ti/j722s/board-cfg.yaml b/board/ti/j722s/board-cfg.yaml
new file mode 100644
index 00..f9a4c438ca
--- /dev/null
+++ b/board/ti/j722s/board-cfg.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+#
+# Board configuration for J722S
+#
+
+---
+
+board-cfg:
+rev:
+boardcfg_abi_maj: 0x0
+boardcfg_abi_min: 0x1
+control:
+subhdr:
+magic: 0xC1D3
+size: 7
+main_isolation_enable: 0x5A
+main_isolation_hostid: 0x2
+secproxy:
+subhdr:
+magic: 0x1207
+size: 7
+scaling_factor: 0x1
+scaling_profile: 0x1
+disable_main_nav_secure_proxy: 0
+msmc:
+subhdr:
+magic: 0xA5C3
+size: 5
+msmc_cache_size: 0x0
+debug_cfg:
+subhdr:
+magic: 0x020C
+size: 8
+trace_dst_enables: 0x00
+trace_src_enables: 0x00
diff --git a/board/ti/j722s/evm.c b/board/ti/j722s/evm.c
new file mode 100644
index 00..515aaa8187
--- /dev/null
+++ b/board/ti/j722s/evm.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Board specific initialization for J722S platforms
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int board_init(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   return fdtdec_setup_mem_size_base();
+}
+
+int dram_init_banksize(void)
+{
+   return fdtdec_setup_memory_banksize();
+}
diff --git a/board/ti/j722s/j722s.env b/board/ti/j722s/j722s.env
new file mode 100644
index 00..f8b6aff2c2
--- /dev/null
+++ b/board/ti/j722s/j722s.env
@@ -0,0 +1,15 @@
+#include 
+#include 
+
+name_kern=Image
+console=ttyS2,115200n8
+args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
+   ${mtdparts}
+run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+
+boot_targets=mmc1 mmc0 pxe dhcp
+boot=mmc
+mmcdev=1
+bootpart=1:2
+bootdir=/boot
+rd_spec=-
diff --git a/board/ti/j722s/pm-cfg.yaml b/board/ti/j722s/pm-cfg.yaml
new file mode 100644
index 00..46b3ad2010
--- /dev/null
+++ b/board/ti/j722s/pm-cfg.yaml
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+#
+# Power management configuration f

[PATCH v2 11/14] firmware: ti_sci_static_data: Add static DMA channel

Include the static DMA channel data for using DMA at SPL stage
for J722S SoC family.

Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
 drivers/firmware/ti_sci_static_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/ti_sci_static_data.h 
b/drivers/firmware/ti_sci_static_data.h
index 9662bd95f2..3370f80231 100644
--- a/drivers/firmware/ti_sci_static_data.h
+++ b/drivers/firmware/ti_sci_static_data.h
@@ -85,7 +85,7 @@ static struct ti_sci_resource_static_data rm_static_data[] = {
 #endif /* CONFIG_SOC_K3_J721S2 */
 
 #if IS_ENABLED(CONFIG_SOC_K3_AM625) || IS_ENABLED(CONFIG_SOC_K3_AM62A7) || \
-   IS_ENABLED(CONFIG_SOC_K3_AM62P5)
+   IS_ENABLED(CONFIG_SOC_K3_AM62P5) || IS_ENABLED(CONFIG_SOC_K3_J722S)
 static struct ti_sci_resource_static_data rm_static_data[] = {
/* BC channels */
{
-- 
2.25.1

[PATCH v2 09/14] arch: mach-k3: Introduce basic files to support J722S SoC family

Introduce the basic functions and definitions needed to properly
initialize TI J722S family of SoCs.

Co-developed-by: Vaishnav Achath 
Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
 arch/arm/mach-k3/Kconfig  |   7 +-
 arch/arm/mach-k3/Makefile |   1 +
 arch/arm/mach-k3/include/mach/hardware.h  |   4 +
 .../arm/mach-k3/include/mach/j722s_hardware.h |  83 +
 arch/arm/mach-k3/include/mach/j722s_spl.h |  49 +++
 arch/arm/mach-k3/include/mach/spl.h   |   4 +
 arch/arm/mach-k3/j722s/Kconfig|  33 ++
 arch/arm/mach-k3/j722s/Makefile   |   7 +
 arch/arm/mach-k3/j722s/j722s_fdt.c|  16 +
 arch/arm/mach-k3/j722s/j722s_init.c   | 287 ++
 10 files changed, 490 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-k3/include/mach/j722s_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/j722s_spl.h
 create mode 100644 arch/arm/mach-k3/j722s/Kconfig
 create mode 100644 arch/arm/mach-k3/j722s/Makefile
 create mode 100644 arch/arm/mach-k3/j722s/j722s_fdt.c
 create mode 100644 arch/arm/mach-k3/j722s/j722s_init.c

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 2bb970c2d4..f3f42b3921 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -25,6 +25,9 @@ config SOC_K3_J721E
 config SOC_K3_J721S2
bool "TI's K3 based J721S2 SoC Family Support"
 
+config SOC_K3_J722S
+   bool "TI's K3 based J722S SoC Family Support"
+
 config SOC_K3_J784S4
bool "TI's K3 based J784S4 SoC Family Support"
 
@@ -84,6 +87,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R
default 0x7000f290 if SOC_K3_AM62A7 && ARM64
default 0x43c4f290 if SOC_K3_AM62P5
+   default 0x43c7f290 if SOC_K3_J722S
help
  Address at which ROM stores the value which determines if SPL
  is booted up by primary boot media or secondary boot media.
@@ -122,7 +126,7 @@ config K3_EARLY_CONS_IDX
 
 config K3_ATF_LOAD_ADDR
hex "Load address of ATF image"
-   default 0x8000 if (SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_AM62P5)
+   default 0x8000 if (SOC_K3_AM625 || SOC_K3_AM62A7 || SOC_K3_AM62P5 
|| SOC_K3_J722S)
default 0x7000
help
  The load address for the ATF image. This value is used to build the
@@ -163,6 +167,7 @@ source "arch/arm/mach-k3/am62ax/Kconfig"
 source "arch/arm/mach-k3/am62px/Kconfig"
 source "arch/arm/mach-k3/j721e/Kconfig"
 source "arch/arm/mach-k3/j721s2/Kconfig"
+source "arch/arm/mach-k3/j722s/Kconfig"
 source "arch/arm/mach-k3/j784s4/Kconfig"
 
 endif
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 2b3ebd5c53..8c4f6786a5 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -14,4 +14,5 @@ obj-$(CONFIG_SOC_K3_AM642) += am64x/
 obj-$(CONFIG_SOC_K3_AM654) += am65x/
 obj-$(CONFIG_SOC_K3_J721E) += j721e/
 obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
+obj-$(CONFIG_SOC_K3_J722S) += j722s/
 obj-$(CONFIG_SOC_K3_J784S4) += j784s4/
diff --git a/arch/arm/mach-k3/include/mach/hardware.h 
b/arch/arm/mach-k3/include/mach/hardware.h
index 1024ee6872..b191d53a0f 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -36,6 +36,10 @@
 #include "j721s2_hardware.h"
 #endif
 
+#ifdef CONFIG_SOC_K3_J722S
+#include "j722s_hardware.h"
+#endif
+
 #ifdef CONFIG_SOC_K3_J784S4
 #include "j784s4_hardware.h"
 #endif
diff --git a/arch/arm/mach-k3/include/mach/j722s_hardware.h 
b/arch/arm/mach-k3/include/mach/j722s_hardware.h
new file mode 100644
index 00..8d0bec2206
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/j722s_hardware.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * K3: J722S SoC definitions, structures etc.
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef __ASM_ARCH_J722S_HARDWARE_H
+#define __ASM_ARCH_J722S_HARDWARE_H
+
+#include 
+#ifndef __ASSEMBLY__
+#include 
+#endif
+
+#define PADCFG_MMR0_BASE   0x0408
+#define PADCFG_MMR1_BASE   0x000f
+#define CTRL_MMR0_BASE 0x0010
+#define MCU_CTRL_MMR0_BASE 0x0450
+#define WKUP_CTRL_MMR0_BASE0x4300
+
+#define CTRLMMR_MAIN_DEVSTAT   (WKUP_CTRL_MMR0_BASE + 0x30)
+#define MAIN_DEVSTAT_PRIMARY_BOOTMODE_MASK GENMASK(6, 3)
+#define MAIN_DEVSTAT_PRIMARY_BOOTMODE_SHIFT3
+#define MAIN_DEVSTAT_PRIMARY_BOOTMODE_CFG_MASK GENMASK(9, 7)
+#define MAIN_DEVSTAT_PRIMARY_BOOTMODE_CFG_SHIFT7
+#define MAIN_DEVSTAT_BACKUP_BOOTMODE_MASK  GENMASK(12, 10)
+#define MAIN_DEVSTAT_BACKUP_BOOTMODE_SHIFT 10
+#define MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_MASK  BIT(13)
+#define MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_SHIFT 13
+
+/* Primary Bootmode MMC Config macros */
+#define MAIN_DEVSTAT_PRIMARY_MMC_POR

[PATCH v2 08/14] ram: k3-ddrss: Enable the am62ax's DDR controller for J722S

The J722S family of SoCs uses the same DDR controller as found on the
AM62A family. Enable this option when building for the J722S family.

Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
Reviewed-by: Neha Malcom Francis 
---
 drivers/ram/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index 9838a2798f..a64d2dff68 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -65,7 +65,7 @@ choice
default K3_J721E_DDRSS if SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_J784S4
default K3_AM64_DDRSS if SOC_K3_AM642
default K3_AM64_DDRSS if SOC_K3_AM625
-   default K3_AM62A_DDRSS if SOC_K3_AM62A7 || SOC_K3_AM62P5
+   default K3_AM62A_DDRSS if SOC_K3_AM62A7 || SOC_K3_AM62P5 || SOC_K3_J722S
 
 config K3_J721E_DDRSS
bool "Enable J721E DDRSS support"
-- 
2.25.1

[PATCH v2 07/14] arm: mach-k3: j722s: introduce clock and device files for wkup spl

Include the clock and lpsc tree files needed for the wkup spl to
initialize the proper PLLs and power domains to boot the SoC.

Reviewed-by: Bryan Brattlof 
Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
 arch/arm/mach-k3/r5/Makefile   |   1 +
 arch/arm/mach-k3/r5/j722s/Makefile |   6 +
 arch/arm/mach-k3/r5/j722s/clk-data.c   | 312 +
 arch/arm/mach-k3/r5/j722s/dev-data.c   |  69 ++
 drivers/clk/ti/clk-k3.c|   6 +
 drivers/power/domain/ti-power-domain.c |   6 +
 include/k3-clk.h   |   1 +
 include/k3-dev.h   |   1 +
 8 files changed, 402 insertions(+)
 create mode 100644 arch/arm/mach-k3/r5/j722s/Makefile
 create mode 100644 arch/arm/mach-k3/r5/j722s/clk-data.c
 create mode 100644 arch/arm/mach-k3/r5/j722s/dev-data.c

diff --git a/arch/arm/mach-k3/r5/Makefile b/arch/arm/mach-k3/r5/Makefile
index f1e61c8548..d3886caa06 100644
--- a/arch/arm/mach-k3/r5/Makefile
+++ b/arch/arm/mach-k3/r5/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_K3_AM62P5) += am62px/
 obj-$(CONFIG_SOC_K3_J721E) += j721e/
 obj-$(CONFIG_SOC_K3_J721E) += j7200/
 obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
+obj-$(CONFIG_SOC_K3_J722S) += j722s/
 obj-$(CONFIG_SOC_K3_J784S4) += j784s4/
 
 obj-y += common.o
diff --git a/arch/arm/mach-k3/r5/j722s/Makefile 
b/arch/arm/mach-k3/r5/j722s/Makefile
new file mode 100644
index 00..2a0dbf5f5a
--- /dev/null
+++ b/arch/arm/mach-k3/r5/j722s/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+
+obj-y += clk-data.o
+obj-y += dev-data.o
diff --git a/arch/arm/mach-k3/r5/j722s/clk-data.c 
b/arch/arm/mach-k3/r5/j722s/clk-data.c
new file mode 100644
index 00..b4f27af333
--- /dev/null
+++ b/arch/arm/mach-k3/r5/j722s/clk-data.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * J722S specific clock platform data
+ *
+ * This file is auto generated. Please do not hand edit and report any issues
+ * to Bryan Brattlof .
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include "k3-clk.h"
+
+static const char * const gluelogic_hfosc0_clkout_parents[] = {
+   NULL,
+   NULL,
+   "osc_24_mhz",
+   "osc_25_mhz",
+   "osc_26_mhz",
+   NULL,
+};
+
+static const char * const clk_32k_rc_sel_out0_parents[] = {
+   "gluelogic_rcosc_clk_1p0v_97p65k",
+   "gluelogic_hfosc0_clkout",
+   "gluelogic_rcosc_clk_1p0v_97p65k",
+   "gluelogic_lfosc0_clkout",
+};
+
+static const char * const main_emmcsd1_io_clklb_sel_out0_parents[] = {
+   "board_0_mmc1_clklb_out",
+   "board_0_mmc1_clk_out",
+};
+
+static const char * const main_ospi_loopback_clk_sel_out0_parents[] = {
+   "board_0_ospi0_dqs_out",
+   "board_0_ospi0_lbclko_out",
+};
+
+static const char * const main_usb0_refclk_sel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "postdiv4_16ff_main_0_hsdivout8_clk",
+};
+
+static const char * const sam62_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = 
{
+   "gluelogic_hfosc0_clkout",
+   "hsdiv4_16fft_main_0_hsdivout0_clk",
+};
+
+static const char * const sam62_pll_ctrl_wrap_mcu_0_sysclkout_clk_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "hsdiv4_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const clkout0_ctrl_out0_parents[] = {
+   "hsdiv4_16fft_main_2_hsdivout1_clk",
+   "hsdiv4_16fft_main_2_hsdivout1_clk",
+};
+
+static const char * const main_emmcsd0_refclk_sel_out0_parents[] = {
+   "postdiv4_16ff_main_0_hsdivout5_clk",
+   "hsdiv4_16fft_main_2_hsdivout2_clk",
+};
+
+static const char * const main_emmcsd1_refclk_sel_out0_parents[] = {
+   "postdiv4_16ff_main_0_hsdivout5_clk",
+   "hsdiv4_16fft_main_2_hsdivout2_clk",
+};
+
+static const char * const main_gtcclk_sel_out0_parents[] = {
+   "postdiv4_16ff_main_2_hsdivout5_clk",
+   "postdiv4_16ff_main_0_hsdivout6_clk",
+   "board_0_cp_gemac_cpts0_rft_clk_out",
+   NULL,
+   "board_0_mcu_ext_refclk0_out",
+   "board_0_ext_refclk1_out",
+   "sam62_pll_ctrl_wrap_mcu_0_chip_div1_clk_clk",
+   "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
+};
+
+static const char * const main_ospi_ref_clk_sel_out0_parents[] = {
+   "hsdiv4_16fft_main_0_hsdivout1_clk",
+   "postdiv1_16fft_main_1_hsdivout5_clk",
+};
+
+static const char * const main_timerclkn_sel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "clk_32k_rc_sel_out0",
+   "postdiv4_16ff_main_0_hsdivout7_clk",
+   "gluelogic_rcosc_clkout",
+   "board_0_mcu_ext_refclk0_out",
+   "board_0_ext_refclk1_out",
+   NULL,
+   "board_0_cp_gemac_cpts0_rft_clk_out",
+   "hsdiv4_16fft_main_1_hsdivout3_clk",
+   "postdiv4_16ff_main_2_hsdivout6_clk",
+   NULL,
+   NULL,
+   NULL,
+   NULL,
+   NULL,
+   NULL,
+};
+
+static const char * const wkup_clkout_sel

[PATCH v2 06/14] arm: mach-k3: r5: Makefile: Fix the order for entries

Add the entries in alphabetical order.

Signed-off-by: Jayesh Choudhary 
Reviewed-by: Neha Malcom Francis 
---
 arch/arm/mach-k3/r5/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-k3/r5/Makefile b/arch/arm/mach-k3/r5/Makefile
index 1cfc8e3ade..f1e61c8548 100644
--- a/arch/arm/mach-k3/r5/Makefile
+++ b/arch/arm/mach-k3/r5/Makefile
@@ -3,13 +3,13 @@
 # Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
 #  Andrew Davis 
 
+obj-$(CONFIG_SOC_K3_AM625) += am62x/
+obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
+obj-$(CONFIG_SOC_K3_AM62P5) += am62px/
 obj-$(CONFIG_SOC_K3_J721E) += j721e/
 obj-$(CONFIG_SOC_K3_J721E) += j7200/
 obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
-obj-$(CONFIG_SOC_K3_AM625) += am62x/
-obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
 obj-$(CONFIG_SOC_K3_J784S4) += j784s4/
-obj-$(CONFIG_SOC_K3_AM62P5) += am62px/
 
 obj-y += common.o
 obj-y += lowlevel_init.o
-- 
2.25.1

[PATCH v2 02/14] soc: ti: k3-socinfo: Fix SOC JTAG entry order

Add JTAG_ID_PARTNO_* in alphabetical order.

Signed-off-by: Jayesh Choudhary 
Reviewed-by: Neha Malcom Francis 
---
 drivers/soc/soc_ti_k3.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index b585e47d46..0838808515 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -23,33 +23,33 @@ static const char *get_family_string(u32 idreg)
soc = (idreg & JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
 
switch (soc) {
+   case JTAG_ID_PARTNO_AM62X:
+   family = "AM62X";
+   break;
+   case JTAG_ID_PARTNO_AM62AX:
+   family = "AM62AX";
+   break;
+   case JTAG_ID_PARTNO_AM62PX:
+   family = "AM62PX";
+   break;
+   case JTAG_ID_PARTNO_AM64X:
+   family = "AM64X";
+   break;
case JTAG_ID_PARTNO_AM65X:
family = "AM65X";
break;
-   case JTAG_ID_PARTNO_J721E:
-   family = "J721E";
-   break;
case JTAG_ID_PARTNO_J7200:
family = "J7200";
break;
-   case JTAG_ID_PARTNO_AM64X:
-   family = "AM64X";
+   case JTAG_ID_PARTNO_J721E:
+   family = "J721E";
break;
case JTAG_ID_PARTNO_J721S2:
family = "J721S2";
break;
-   case JTAG_ID_PARTNO_AM62X:
-   family = "AM62X";
-   break;
-   case JTAG_ID_PARTNO_AM62AX:
-   family = "AM62AX";
-   break;
case JTAG_ID_PARTNO_J784S4:
family = "J784S4";
break;
-   case JTAG_ID_PARTNO_AM62PX:
-   family = "AM62PX";
-   break;
default:
family = "Unknown Silicon";
};
-- 
2.25.1

[PATCH v2 05/14] power: domain: ti: Fix the order for platform data entries

Add the power domain platform data entries in alphabetical order.

Signed-off-by: Jayesh Choudhary 
Reviewed-by: Neha Malcom Francis 
---
 drivers/power/domain/ti-power-domain.c | 36 +-
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/power/domain/ti-power-domain.c 
b/drivers/power/domain/ti-power-domain.c
index b059dd3737..362fae86a2 100644
--- a/drivers/power/domain/ti-power-domain.c
+++ b/drivers/power/domain/ti-power-domain.c
@@ -71,6 +71,24 @@ static void lpsc_write(u32 val, struct ti_lpsc *lpsc, u32 
reg)
 }
 
 static const struct soc_attr ti_k3_soc_pd_data[] = {
+#if IS_ENABLED(CONFIG_SOC_K3_AM625)
+   {
+   .family = "AM62X",
+   .data = &am62x_pd_platdata,
+   },
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62A7)
+   {
+   .family = "AM62AX",
+   .data = &am62ax_pd_platdata,
+   },
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
+   {
+   .family = "AM62PX",
+   .data = &am62px_pd_platdata,
+   },
+#endif
 #if IS_ENABLED(CONFIG_SOC_K3_J721E)
{
.family = "J721E",
@@ -87,29 +105,11 @@ static const struct soc_attr ti_k3_soc_pd_data[] = {
.data = &j721s2_pd_platdata,
},
 #endif
-#if IS_ENABLED(CONFIG_SOC_K3_AM625)
-   {
-   .family = "AM62X",
-   .data = &am62x_pd_platdata,
-   },
-#endif
-#if IS_ENABLED(CONFIG_SOC_K3_AM62A7)
-   {
-   .family = "AM62AX",
-   .data = &am62ax_pd_platdata,
-   },
-#endif
 #if IS_ENABLED(CONFIG_SOC_K3_J784S4)
{
.family = "J784S4",
.data = &j784s4_pd_platdata,
},
-#endif
-#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
-   {
-   .family = "AM62PX",
-   .data = &am62px_pd_platdata,
-   },
 #endif
{ /* sentinel */ }
 };
-- 
2.25.1

[PATCH v2 00/14] Add basic U-Boot Support for J722S-EVM

Hello there,

This series add the U-Boot support for our new platform of K3-SOC
family - J722S-EVM which is a superset of AM62P. It shares the same
memory map and thus the nodes are being reused from AM62P includes
instead of duplicating the definitions.

Some highlights of J722S SoC (in addition to AM62P SoC features) are:

- Two Cortex-R5F for Functional Safety or general-purpose usage and
  two C7x floating point vector DSP with Matrix Multiply Accelerator
  for deep learning.
  
- Vision Processing Accelerator (VPAC) with image signal processor
  and Depth and Motion Processing Accelerator (DMPAC).

- 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
  NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
  4xCSI-RX for Camera, 1 PCIe Gen3 controller, USB3.0 eCAP/eQEP,
  ePWM, among other peripherals.
  
TRM: 
Schematics: 

Boot test log:


v1 patch:


Changelog v1->v2:
- Fix space tab inconsistency in [3/14]
- Break board_init_f into smaller logical functions as suggested by
  Neha[7]
- Add DT fixup as suggested by Andrew[8]
- Sync configs with savedefconfig to take care of redundant and invalid
  configs.
- Pick up R-by for rest of the patches.

RFC series that was posted before this:


Changes from RFC series to this series:
- Remove main_pktdma node and k3_sysreset node from
  k3-j722s-evm-u-boot.dtsi as suggested by Andrew[0]
  k3_sysreset will be taken care of in [1] which is not
  a real dependency for this series
- Fix documentation according to comments here[2]
- Pick up R-by for 2 patches from RFC series[3][4]
- Pick the binman change for optional DM[5]
- Move init code according to [6]


[0]: https://lore.kernel.org/all/d738eaaf-6f13-4502-98a1-ef1bfe82d...@ti.com/
[1]: https://lore.kernel.org/all/20240402160908.508974-3-...@ti.com/
[2]: https://lore.kernel.org/all/ac5780c5-f1ca-4138-a027-d3ed65911...@ti.com/
[3]: 
https://lore.kernel.org/all/20240404163641.6qmcierya6svc...@bryanbrattlof.com/
[4]: 
https://lore.kernel.org/all/20240404163714.p2wonpenkiz44...@bryanbrattlof.com/
[5]: https://lore.kernel.org/all/20240529074849.363281-1-n-fran...@ti.com/
[6]: https://lore.kernel.org/all/20240510202124.794448-1-...@ti.com/
[7]: 
https://patchwork.ozlabs.org/project/uboot/patch/20240529132448.459330-10-j-choudh...@ti.com/#3319318
[8]: 
https://patchwork.ozlabs.org/project/uboot/patch/20240529132448.459330-10-j-choudh...@ti.com/#3318999

Jayesh Choudhary (14):
  arm: mach-k3: Sort CONFIG_SOC* and K3_SOC_ID entries
  soc: ti: k3-socinfo: Fix SOC JTAG entry order
  soc: add info to identify the J722S SoC family
  clk: ti: clk-k3: use IS_ENABLED macro and fix the clock-data order
  power: domain: ti: Fix the order for platform data entries
  arm: mach-k3: r5: Makefile: Fix the order for entries
  arm: mach-k3: j722s: introduce clock and device files for wkup spl
  ram: k3-ddrss: Enable the am62ax's DDR controller for J722S
  arch: mach-k3: Introduce basic files to support J722S SoC family
  board: ti: Introduce basic board files for the J722S family
  firmware: ti_sci_static_data: Add static DMA channel
  arm: dts: Introduce J722S U-Boot dts files
  configs: introduce configs needed for the J722S
  doc: board: ti: Add J722S-EVM documentation

 arch/arm/dts/Makefile |2 +
 arch/arm/dts/k3-j722s-binman.dtsi |  172 +
 arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi| 2795 +
 arch/arm/dts/k3-j722s-evm-u-boot.dtsi |   18 +
 arch/arm/dts/k3-j722s-r5-evm.dts  |   82 +
 arch/arm/mach-k3/Kconfig  |7 +-
 arch/arm/mach-k3/Makefile |1 +
 arch/arm/mach-k3/include/mach/hardware.h  |   43 +-
 .../arm/mach-k3/include/mach/j722s_hardware.h |   83 +
 arch/arm/mach-k3/include/mach/j722s_spl.h |   49 +
 arch/arm/mach-k3/include/mach/spl.h   |4 +
 arch/arm/mach-k3/j722s/Kconfig|   33 +
 arch/arm/mach-k3/j722s/Makefile   |7 +
 arch/arm/mach-k3/j722s/j722s_fdt.c|   16 +
 arch/arm/mach-k3/j722s/j722s_init.c   |  287 ++
 arch/arm/mach-k3/r5/Makefile  |7 +-
 arch/arm/mach-k3/r5/j722s/Makefile|6 +
 arch/arm/mach-k3/r5/j722s/clk-data.c  |  312 ++
 arch/arm/mach-k3/r5/j722s/dev-data.c  |   69 +
 board/ti/j722s/Kconfig|   26 +
 board/ti/j722s/MAINTAINERS|9 +
 board/ti/j722s/Makefile   |7 +
 board/ti/j722s/board-cfg.yaml |   36 +
 board/ti/j722s/evm.c  |   29 +
 board/ti/j722s/j722s.env  |   15 +
 board/ti/j722s/pm-cfg.yaml|   12 +
 board/ti/j722s/

[PATCH v2 04/14] clk: ti: clk-k3: use IS_ENABLED macro and fix the clock-data order

Use IS_ENABLED macro for the platform clock-data list and add them
in alphabetical order.

Reviewed-by: Bryan Brattlof 
Signed-off-by: Jayesh Choudhary 
---
 drivers/clk/ti/clk-k3.c | 41 +
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/clk/ti/clk-k3.c b/drivers/clk/ti/clk-k3.c
index 41e5022ea0..9e17755c24 100644
--- a/drivers/clk/ti/clk-k3.c
+++ b/drivers/clk/ti/clk-k3.c
@@ -59,6 +59,24 @@ static void clk_add_map(struct ti_clk_data *data, struct clk 
*clk,
 }
 
 static const struct soc_attr ti_k3_soc_clk_data[] = {
+#if IS_ENABLED(CONFIG_SOC_K3_AM625)
+   {
+   .family = "AM62X",
+   .data = &am62x_clk_platdata,
+   },
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62A7)
+   {
+   .family = "AM62AX",
+   .data = &am62ax_clk_platdata,
+   },
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
+   {
+   .family = "AM62PX",
+   .data = &am62px_clk_platdata,
+   },
+#endif
 #if IS_ENABLED(CONFIG_SOC_K3_J721E)
{
.family = "J721E",
@@ -68,35 +86,18 @@ static const struct soc_attr ti_k3_soc_clk_data[] = {
.family = "J7200",
.data = &j7200_clk_platdata,
},
-#elif CONFIG_SOC_K3_J721S2
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_J721S2)
{
.family = "J721S2",
.data = &j721s2_clk_platdata,
},
 #endif
-#ifdef CONFIG_SOC_K3_AM625
-   {
-   .family = "AM62X",
-   .data = &am62x_clk_platdata,
-   },
-#endif
-#ifdef CONFIG_SOC_K3_AM62A7
-   {
-   .family = "AM62AX",
-   .data = &am62ax_clk_platdata,
-   },
-#endif
-#ifdef CONFIG_SOC_K3_J784S4
+#if IS_ENABLED(CONFIG_SOC_K3_J784S4)
{
.family = "J784S4",
.data = &j784s4_clk_platdata,
},
-#endif
-#ifdef CONFIG_SOC_K3_AM62P5
-   {
-   .family = "AM62PX",
-   .data = &am62px_clk_platdata,
-   },
 #endif
{ /* sentinel */ }
 };
-- 
2.25.1

[PATCH v2 03/14] soc: add info to identify the J722S SoC family

Include the part number for TI's j722s family of SoC
to identify it during boot.

Signed-off-by: Vaishnav Achath 
Signed-off-by: Jayesh Choudhary 
---
 arch/arm/mach-k3/include/mach/hardware.h | 2 ++
 drivers/soc/soc_ti_k3.c  | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-k3/include/mach/hardware.h 
b/arch/arm/mach-k3/include/mach/hardware.h
index c3aaded8dc..1024ee6872 100644
--- a/arch/arm/mach-k3/include/mach/hardware.h
+++ b/arch/arm/mach-k3/include/mach/hardware.h
@@ -55,6 +55,7 @@
 #define JTAG_ID_PARTNO_J7200   0xbb6d
 #define JTAG_ID_PARTNO_J721E   0xbb64
 #define JTAG_ID_PARTNO_J721S2  0xbb75
+#define JTAG_ID_PARTNO_J722S   0xbba0
 #define JTAG_ID_PARTNO_J784S4  0xbb80
 
 #define K3_SOC_ID(id, ID) \
@@ -72,6 +73,7 @@ K3_SOC_ID(am65x, AM65X)
 K3_SOC_ID(j7200, J7200)
 K3_SOC_ID(j721e, J721E)
 K3_SOC_ID(j721s2, J721S2)
+K3_SOC_ID(j722s, J722S)
 
 #define K3_SEC_MGR_SYS_STATUS  0x44234100
 #define SYS_STATUS_DEV_TYPE_SHIFT  0
diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index 0838808515..f948914d21 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -47,6 +47,9 @@ static const char *get_family_string(u32 idreg)
case JTAG_ID_PARTNO_J721S2:
family = "J721S2";
break;
+   case JTAG_ID_PARTNO_J722S:
+   family = "J722S";
+   break;
case JTAG_ID_PARTNO_J784S4:
family = "J784S4";
break;
-- 
2.25.1

[PATCH v2 01/14] arm: mach-k3: Sort CONFIG_SOC* and K3_SOC_ID entries