list.h: synchronize hlist_for_each_entry* iterators with linux

All the way back in 2013, the linux kernel updated the four
hlist_for_each_entry* iterators to require one less auxiliary
variable:

  commit b67bfe0d42cac56c512dd5da4b1b347a23f4b70a
  Author: Sasha Levin <sasha.levin@oracle.com>
  Date:   Wed Feb 27 17:06:00 2013 -0800

      hlist: drop the node parameter from iterators

Currently, there is only one "user" of any of these, namely in
fs/ubifs/super.c, but that actually uses the "new-style" form, and
is (obviously, or it wouldn't have built) inside #ifndef __UBOOT__.

Before adding actual users of these, import the version as of linux
v6.1-rc1, including the hlist_entry_safe() helper used by the new
versions.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Tim Harvey <tharvey@gateworks.com> # imx8mm-venice-*

cyclic: drop redundant cyclic_ready flag

We're already relying on gd->cyclic being NULL before cyclic_init() is
called - i.e., we're relying on all of gd being zeroed before entering
any C code. And when we do populate gd->cyclic, its ->cyclic_ready
member is automatically set to true. So we can actually just rely on
testing gd->cyclic itself.

The only wrinkle is that cyclic_uninit() actually did set
->cyclic_ready to false. However, since it doesn't free gd->cyclic,
the cyclic infrastructure is actually still ready (i.e., the list_head
is properly initialized as an empty list).

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Tim Harvey <tharvey@gateworks.com> # imx8mm-venice-*

cyclic: use a flag in gd->flags for recursion protection

As a preparation for future patches, use a flag in gd->flags rather
than a separate member in (the singleton) struct cyclic_drv to keep
track of whether we're already inside cyclic_run().

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Tim Harvey <tharvey@gateworks.com> # imx8mm-venice-*

Merge branch '2022-10-31-FWU-add-FWU-multi-bank-update-feature-support'

To quote the author:
The patchset adds support for the FWU Multi Bank Update[1]
feature. Certain aspects of the Dependable Boot[2] specification have
also been implemented.

The FWU multi bank update feature is used for supporting multiple
sets(also called banks) of firmware image(s), allowing the platform to
boot from a different bank, in case it fails to boot from the active
bank. This functionality is supported by keeping the relevant
information in a structure called metadata, which provides information
on the images. Among other parameters, the metadata structure contains
information on the currect active bank that is being used to boot
image(s).

Functionality is being added to work with the UEFI capsule driver in
u-boot. The metadata is read to gather information on the update bank,
which is the bank to which the firmware images would be flashed to. On
a successful completion of the update of all components, the active
bank field in the metadata is updated, to reflect the bank from which
the platform will boot on the subsequent boots.

Currently, the feature is being enabled on the STM32MP157C-DK2 and
Synquacer boards. The DK2 board boots a FIP image from a uSD card
partitioned with the GPT partioning scheme, while the Synquacer board
boots a FIP image from a MTD partitioned SPI NOR flash device.

This feature also requires changes in a previous stage of
bootloader, which parses the metadata and selects the bank to boot the
image(s) from. Support has being added in tf-a(BL2 stage) for the
STM32MP157C-DK2 board to boot the active bank images. These changes
have been merged to the upstream tf-a repository.

The patch for adding a python test for the feature has been developed,
and was sent in the version 5 of the patches[3]. However, the test
script depends on adding support for the feature on MTD SPI NOR
devices, and that is being done as part of the Synquacer
patches. Hence these set of patches do not have the test script for
the feature. That will be added through the patches for adding support
for the feauture on Synquacer platform.

[1] - https://developer.arm.com/documentation/den0118/a
[2] - https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
[3] - https://lists.denx.de/pipermail/u-boot/2022-June/485992.html

FWU: doc: Add documentation for the FWU feature

Add documentation for the FWU Multi Bank Update feature. The document
describes the steps needed for setting up the platform for the
feature, as well as steps for enabling the feature on the platform.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

mkeficapsule: Add support for setting OEM flags in capsule header

Add support for setting OEM flags in the capsule header. As per the
UEFI specification, bits 0-15 of the flags member of the capsule
header can be defined per capsule GUID.

The oemflags will be used for the FWU Multi Bank update feature, as
specified by the Dependable Boot specification[1]. Bit
15 of the flags member will be used to determine if the
acceptance/rejection of the updated images is to be done by the
firmware or an external component like the OS.

[1] - https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

mkeficapsule: Add support for generating empty capsules

The Dependable Boot specification[1] describes the structure of the
firmware accept and revert capsules. These are empty capsules which
are used for signalling the acceptance or rejection of the updated
firmware by the OS. Add support for generating these empty capsules.

[1] - https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

test: dm: Add test cases for FWU Metadata uclass

Add test cases for accessing the FWU Metadata on the sandbox
platform. The sandbox platform also uses the metadata access driver
for GPT partitioned block devices.

The FWU feature will be tested on the sandbox64 variant with a raw
capsule. Remove the FIT capsule testing from sandbox64 defconfig --
the FIT capsule test will be run on the sandbox_flattree variant.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

FWU: cmd: Add a command to read FWU metadata

Add a command to read the metadata as specified in the FWU
specification and print the fields of the metadata.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

FWU: Add support for the FWU Multi Bank Update feature

The FWU Multi Bank Update feature supports updating firmware images
to one of multiple sets(also called banks) of images. The firmware
images are clubbed together in banks, with the system booting images
from the active bank. Information on the images such as which bank
they belong to is stored as part of the metadata structure, which is
stored on the same storage media as the firmware images on a dedicated
partition.

At the time of update, the metadata is read to identify the bank to
which the images need to be flashed(update bank). On a successful
update, the metadata is modified to set the updated bank as active
bank to subsequently boot from.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

FWU: Add boot time checks as highlighted by the FWU specification

The FWU Multi Bank Update specification requires the Update Agent to
carry out certain checks at the time of platform boot. The Update
Agent is the component which is responsible for updating the firmware
components and maintaining and keeping the metadata in sync.

The spec requires that the Update Agent perform the following checks
at the time of boot
* Sanity check of both the metadata copies maintained by the platform.
* Get the boot index passed to U-Boot by the prior stage bootloader
  and use this value for metadata bookkeeping.
* Check if the system is booting in Trial State. If the system boots
  in the Trial State for more than a specified number of boot counts,
  change the Active Bank to be booting the platform from.

Call these checks through the main loop event at the time of platform
boot.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

event: Add an event for main_loop

Add an event type EVT_MAIN_LOOP that can be used for registering
events that need to be run after the platform has been initialised and
before the main_loop function is called.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

FWU: STM32MP1: Add support to read boot index from backup register

The FWU Multi Bank Update feature allows the platform to boot the
firmware images from one of the partitions(banks). The first stage
bootloader(fsbl) passes the value of the boot index, i.e. the bank
from which the firmware images were booted from to U-Boot. On the
STM32MP157C-DK2 board, this value is passed through one of the SoC's
backup register. Add a function to read the boot index value from the
backup register.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

FWU: Add helper functions for accessing FWU metadata

Add weak functions for getting the update index value and dfu
alternate number needed for FWU Multi Bank update
functionality.

The current implementation for getting the update index value is for
platforms with 2 banks. If a platform supports more than 2 banks, it
can implement it's own function. The function to get the dfu alternate
number has been added for platforms with GPT partitioned storage
devices. Platforms with other storage partition scheme need to
implement their own function.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

stm32mp1: Add image information for capsule updates

Enabling capsule update functionality on the platform requires
populating information on the images that are to be updated using the
functionality. Do so for the DK2 board.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

stm32mp1: Add a node for the FWU metadata device

The FWU metadata structure is accessed through the driver model
interface. On the stm32mp157c dk2 and ev1 boards, the FWU metadata is
stored on the uSD card. Add the fwu-mdata node on the u-boot specifc
dtsi file for accessing the metadata structure.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

FWU: Add FWU metadata access driver for GPT partitioned block devices

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, on a separate
partition. Add a driver for reading from and writing to the metadata
when the updatable images and the metadata are stored on a block
device which is formatted with GPT based partition scheme.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

FWU: Add FWU metadata structure and driver for accessing metadata

In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, which is stored on
a dedicated partition. Add the metadata structure, and a driver model
uclass which provides functions to access the metadata. These are
generic API's, and implementations can be added based on parameters
like how the metadata partition is accessed and what type of storage
device houses the metadata.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

dt/bindings: Add bindings for GPT based FWU Metadata storage device

Add bindings needed for accessing the FWU metadata partitions. These
include the compatible string which point to the access method and the
actual device which stores the FWU metadata.

The current patch adds basic bindings needed for accessing the
metadata structure on GPT partitioned block devices.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Merge branch '2022-10-31-vbe-implement-the-full-firmware-flow'

To quote Simon:
This series provides an implementation of VBE from TPL through to U-Boot
proper, using VBE to load the relevant firmware stages. It buils a single
image.bin file containing all the phases:

   TPL - initial phase, loads VPL using binman symbols
   VPL - main firmware phase, loads SPL using VBE parameters
   SPL - loads U-Boot proper using VBE parameters
   U-Boot - final firmware phase, where OS booting is processed

This series does not include the OS-booting phase. That will be the
subject of a future series.

The implementation is entirely handled by sandbox. It should be possible
to enable this on a real board without much effort, but that is also the
subject of a future series.

vbe: Add a test for the VBE flow into U-Boot proper

Add a test which checks that VBE boots correctly from TPL through to
U-Boot proper.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Add a command to show the VBE state

Add a VBE comment which shows the current state. Currently this is just
the phases which booted via VBE.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Record which phases loaded using VBE

We expect VPL and SPL to load using VBE. Add a record of this so we can
check it in U-Boot proper.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Use a manual test

Use a manual test for the VBE test, so we can make the pytest and the
C unit test work together properly.

Signed-off-by: Simon Glass <sjg@chromium.org>

vpl: Allow signature verification

Add the required Kconfig option so that signatures can be verified when
loading a configuration.

Signed-off-by: Simon Glass <sjg@chromium.org>

sandbox: Add an image for VPL

Use binman to build an image which includes all the U-Boot phases so that
a full VBE boot can take place with just that image.bin file. Attach the
image file to mmc2 so it can be loaded.

VBE is used to load images in two phases:

   - In VPL, VBE decides which SPL image to load
   - In SPL, VBE decides which U-Boot image to load

The latter should really be determined by VPL, since it does the full
signature verification on the selected configuration. However, we have
separate configurations for SPL and U-Boot proper, so for now we keep it
simple and have SPL do its own verification. This will need to be
tidied up later.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Add info about the VBE device to the fwupd node

At present we put the driver in the /chosen node in U-Boot. This is a bit
strange, since U-Boot doesn't normally use that node itself. It is better
to put it under the bootstd node.

To make this work we need to copy create the node under /chosen when
fixing up the device tree. Copy over all the properties so that fwupd
knows what to do.

Update the sandbox device tree accordingly.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Add Kconfig options for VPL

Enable the various features needed in VPL, by adding Kconfig options.

Update the defconfig for sandbox_vpl so that the build for each phase
includes what is needed. Drop LZMA for now and make sure partition support
is omitted in SPL, since it is not needed.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Drop the U-Boot prefix from the version

We don't need the U-Boot prefix on the version and in fact it is harmful
since pytest gets confused seeing the U-Boot banner bring displayed when
the version is printed.

Drop the prefix from the string.

We could produce an entirely new string from the component parts, but this
adds to the rodata size and would break the use of version_string as the
only thing which holds this information.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Move OS implementation into a separate file

Move this into its own file so it can be built only by U-Boot proper.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Support reading the next SPL phase via VBE

Add an SPL loader to obtain the next-phase binary from a FIT provided
by the VBE driver.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Support selecting operations by SPL phase

VBE supports booting firmware during the SPL phases, i.e. so that VPL can
start SPL and SPL can start U-Boot.

It also supports booting an OS, when in U-Boot.

As a first step towards these features, add functions to indicate the
current VBE phase. The firmware selection is done in VPL and the OS
selection is done in U-Boot proper.

Signed-off-by: Simon Glass <sjg@chromium.org>

sandbox: Support obtaining the next phase from an image

At present sandbox runs the next phase from discrete executables, so for
example u-boot-tpl runs u-boot-vpl to get to the next phase.

In some cases the phases are all built into a single firmware image, as is
done for real boards. Add support for this to sandbox.

Make it higher priority so that it takes precedence over the existing
method.

Signed-off-by: Simon Glass <sjg@chromium.org>

spl: Allow multiple loaders of the same time

At present we only support a single loader of each time. Extra ones are
ignored. This means that only one BOOT_DEVICE_BOARD can be used in the SPL
image.

This is inconvenient since we sometimes want to provide several
board-specific drivers, albeit at different priorties. Add support for
this.

This should have no functional change for existing boards.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Use a warning for a failed requests

Optional requests should present a warning rather than an error. Update
the log call.

Signed-off-by: Simon Glass <sjg@chromium.org>

vbe: Rename vbe_fixup to vbe_request

The vbe_fixup file handles device tree fixups, but these are called OS
requests in VBE. Rename the file to reflect its wider purpose.

Signed-off-by: Simon Glass <sjg@chromium.org>

image: Allow loading a FIT image for a particular phase

Add support for filtering out FIT images by phase. Rather than adding yet
another argument to this already overloaded function, use a composite
value, where the phase is only added in if needed.

The FIT config is still selected (and verified) as normal, but the images
are selected based on the phase.

Tests for this come in a little later, as part of the updated VPL test.

Signed-off-by: Simon Glass <sjg@chromium.org>

image: Add the concept of a phase to FIT

We want to be able to mark an image as related to a phase, so we can
easily load all the images for SPL or for U-Boot proper.

Add this to the FIT specification, along with some access functions.

Signed-off-by: Simon Glass <sjg@chromium.org>

sandbox: Add a way to specify the sandbox executable

At present the sandbox executable is assumed to be arg[0] but this only
works for a single jump (e.g. from SPL to U-Boot). Add a new arg to solve
this issue, along with a detailed comment.

Signed-off-by: Simon Glass <sjg@chromium.org>

sandbox: Generalise SPL booting

At present sandbox only supports jumping to a file, to get to the next
U-Boot phase. We want to support other methods, so update the code to
use an enum for the method. Also use the

Use board_boot_order() to set the order, so we can add more options.
Also add the MMC methods into the BOOT_DEVICE enum so that booting
from MMC can be supported.

Signed-off-by: Simon Glass <sjg@chromium.org>

image: Move comment for fit_conf_find_compat()

Move this comment to the header file, where the APIs should be defined.

Signed-off-by: Simon Glass <sjg@chromium.org>

sandbox: Drop message about writing sandbox state

This happens every time sandbox moves to the next phase so is not very
interesting. Display the message only when debugging.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

dm: mmc: Allow sandbox emulator to build without writes

When MMC_WRITE is disabled this driver produced a build error. Fix this.

Also update a comment while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

dm: blk: mmc: Tidy up some Makefile rules for SPL

Use the correct SPL_TPL_ variable so that these features can be enabled in
TPL and VPL as needed.

Disable it by default in TPL to avoid any code-size increase. No boards
are actually using it since the Makefile rules don't allow including
drivers/block/ with TPL_DM enabled. It can be manually enabled as needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

bloblist: Drop debugging

Disable debugging by default since this implementation is stable now.

Signed-off-by: Simon Glass <sjg@chromium.org>

usb: Update the test to cover reading and writing

Add test coverage for blk_write() as well.

The blk_erase() is not tested for now as the USB stor interface does not
support erase.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: blk: Add udevice functions

At present we have functions called blk_dread(), etc., which take a
struct blk_desc * to refer to the block device. Add some functions which
use udevice instead, since this is more in keeping with how driver model
is supposed to work.

Update one of the tests to use this.

Note that it would be nice to update the functions in disk-uclass.c to use
these new functions. However they are not quite the same. For example,
disk_blk_read() adds the partition offset to 'start' when calling the
cache read/fill functions, but does not with part_blk_read(), which does
the addition itself. So as designed the code is duplicated.

Signed-off-by: Simon Glass <sjg@chromium.org>

disk: Rename block_dev to desc

The use of 'block_dev' in this context is confusing, since it is not a
pointer to a device, just to some information about it. Rename this to
'desc', as is more commonly used, since it is a block descriptor.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <xypron.glplk@gmx.de>

disk: Rename block functions

Use the uclass type as the first part of the function name, to be
consistent with the methods in other block drivers.

Signed-off-by: Simon Glass <sjg@chromium.org>

bootstd: Add a way to set up a bootflow

Add a function to init a bootflow, to reduce code duplication.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Support tests which can only be run manually

At present we normally write tests either in Python or in C. But most
Python tests end up doing a lot of checks which would be better done in C.
Checks done in C are orders of magnitude faster and it is possible to get
full access to U-Boot's internal workings, rather than just relying on
the command line.

The model is to have a Python test set up some things and then use C code
(in a unit test) to check that they were done correctly. But we don't want
those checks to happen as part of normal test running, since each C unit
tests is dependent on the associate Python tests, so cannot run without
it.

To acheive this, add a new UT_TESTF_MANUAL flag to use with the C 'check'
tests, so that they can be skipped by default when the 'ut' command is
used. Require that tests have a name ending with '_norun', so that pytest
knows to skip them.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Update tests to use the skip feature

Some tests currently return 0 when they want to be skipped. Update them to
return -EAGAIN instead, so they are counted as skipped.

A few tests are in two parts, with the latter part being skipped in
certain situations. Split these into two and use the correct condition for
the second part.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Report skippped tests

At present it is possible for a test to skip itself by returning -EAGAIN
but this is not recorded. An existing example is in test_pre_run() with
the "Console recording disabled" check.

Keep a track of skipped tests and report the total at the end.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

binman: Support writing symbols into ELF files

In some cases the ELF version of SPL builds may be packaged, rather
than a binary .bin file. Add support for this.

Signed-off-by: Simon Glass <sjg@chromium.org>

binman: Handle writing ELF symbols in the Entry class

This feature is used by several etypes and we plan to add more that use
it. Make symbol writing a feature of the base class to reduce the code
duplication.

Signed-off-by: Simon Glass <sjg@chromium.org>

binman: Split out looking up a symbol into a function

Move this code into its own function so it can be used from tests.

Signed-off-by: Simon Glass <sjg@chromium.org>

binman: Allow obtaining a symbol value

Provide a function to obtain the integer value of an ELF symbol. This will
be used

Signed-off-by: Simon Glass <sjg@chromium.org>

spl: Add a separate silence option for SPL

Add an option to allow silent console to be controlled separately in SPL,
so that boot progress can be shown. Disable it by default for sandbox
since it is useful to see what is going on there.

Signed-off-by: Simon Glass <sjg@chromium.org>

spl: Refactor controls for console output

The expression in boot_from_devices() is fairly long and appears to be an
artefact from before we could easily call printf(...) and have the call be
nop'd out. So update it to just check CONFIG_SILENT_CONSOLE.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>

spl: Use binman suffix allow symbols of any SPL etype

At present we use symbols for the u-boot-spl entry, but this is not always
what we want. For example, sandbox actually jumps to a u-boot-spl-elf
entry, since sandbox executables are ELF files.

We already handle this with U-Boot by using the '-any' suffix. Add it for
SPL as well.

Signed-off-by: Simon Glass <sjg@chromium.org>

disk: Drop debug messages in part_efi

This is monstrously verbose when something goes wrong. It should work by
recording the problem and reporting it (once) at the command level. At
present it sometimes outputs hundreds of lines of CRC mismatches.

For now, just silence it all.

  GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712
  find_valid_gpt: *** ERROR: Invalid GPT ***
  find_valid_gpt: ***        Using Backup GPT ***
  GUID Partition Table Entry Array CRC is wrong: 0xaebfebf2 != 0xc916f712
  find_valid_gpt: *** ERROR: Invalid GPT ***
  find_valid_gpt: ***        Using Backup GPT ***
  ...

While we are error, remove the '*** ERROR: ' text as it is already clear
that this is unexpected

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Rename CONFIG_SYS_TEXT_BASE to CONFIG_TEXT_BASE

The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().

Rename it to resolve this problem.

Signed-off-by: Simon Glass <sjg@chromium.org>

Merge branch '2022-10-31-broadcom-updates'

- Update / add a large number of Broadcom BCA SoCs.

timer: bcmbca: use arm global timer for bcm63138 SoC

As STI timer is renamed to ARM A9 global timer, change BCM63138 to use
the new global timer config symbol name.

This patch applies on top of the my previous patch [1].

[1]: https://lists.denx.de/pipermail/u-boot/2022-August/491060.html

Signed-off-by: William Zhang <william.zhang@broadcom.com>

timer: sti: convert sti-timer to arm a9 global timer

STI timer is actually ARM Cortex A9 global timer. Convert the driver to
use generic global timer name and make it consistent with Linux kernel
global timer driver. This also allows any A9 based device to use this
driver.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

arm: bcmbca: replace ARCH_BCM6753 symbols in Kconfig with BCM6855

As CONFIG_ARCH_BCM6753 is replaced with CONFIG_BCM6855, update the
driver Kconfig to use the new config symbol.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: remove bcm6753 support under CONFIG_ARCH_BCM6753

BCM6753 is essentially same as the main chip BCM6855 but with different
SKU number. Now that BCM6855 is supported under CONFIG_ARCH_BCMBCA and
CONFIG_BCM6855, remove the original ARCH_BCM6753 support and migrate its
configuration and dts settings. This includes:
- Remove the bcm96753ref board folder. It is replaced by the
generic bcmbca board folder.
- Merge the 6753.dtsi setting to the new 6855.dtsi file. Update
96753ref board dts with the new compatible string.
- Delete broadcom_bcm96763ref.h and merge its setting to the new
bcm96855.h file.
- Delete bcm96753ref_ram_defconfig and use a basic config version of
bcm96855_defconfig

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: add bcm6855 SoC support under CONFIG_ARCH_BCMBCA

BCM6855 is a Broadcom ARM A7 based PON Gateway SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family. Like other
broadband SoC, this patch adds it under CONFIG_BCM6855 chip config and
CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and ARM PL101 uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: replace ARCH_BCM6858 symbols in Kconfig with BCM6858

As CONFIG_ARCH_BCM6858 is replaced with CONFIG_BCM6858, update the
driver Kconfig to use the new config symbol.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: remove bcm6858 support under CONFIG_ARCH_BCM6858

Now that BCM6858 is supported under CONFIG_ARCH_BCMBCA and
CONFIG_BCM6858, remove the original ARCH_BCM6858 support and migrate its
configuration and dts settings. This includes:
- Remove the bcm968580xref board folder. It is replaced by the generic
bcmbca board folder.
- Update bcm968580xref board dts with the new compatible string.
- Delete broadcom_bcm968580xref.h and merge its setting to the new
bcm96858.h file.
- Remove bcm968580xref_ram_defconfig as a basic config version of
bcm96858_defconfig is now added.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: add bcm6858 SoC support under CONFIG_ARCH_BCMBCA

BCM6858 is a Broadcom B53 based PON Gateway SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family. Like other broadband
SoC, this patch adds it under CONFIG_BCM6858 chip config and
CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and the
original dts is updated with the one from linux next git repository.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: replace ARCH_BCM68360 symbols in Kconfig with BCM6856

As CONFIG_ARCH_BCM68360 is replaced with CONFIG_BCM6856, update the
driver Kconfig to use the new config symbol.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: remove bcm68360 support under CONFIG_ARCH_BCM68360

BCM68360 is a variant within the BCM6856 chip family. Now that BCM6856
is supported under CONFIG_ARCH_BCMBCA and CONFIG_BCM6856, remove the
original ARCH_BCM68360 support and migrate its configuration and dts
settings. This includes:
  - Remove the bcm968360bg board folder. It is replaced by the generic
    bcmbca board folder.
  - Merge the 68360.dtsi setting to the new 6856.dtsi file. Update board
    dts with the new compatible string.
  - Merge broadcom_bcm968360bg.h setting to the new bcm96856.h file.
  - Remove bcm968360bg_ram_defconfig as a basic config version of
    bcm96856_defconfig is now added.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: add bcm6856 SoC support under CONFIG_ARCH_BCMBCA

BCM6856 is a Broadcom B53 based PON Gateway SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family. Like other Broadband
SoC, this patch adds it under CONFIG_BCM6856 chip config and
CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and Broadcom uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from
linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: make reset_cpu function weak

BCM63158 carries the CONFIG_SYSRESET from the original configuration. It
provide reset_cpu function already so need to define weak version of the
dummy reset_cpu for other BCMBCA SoCs to avoid linking error.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

MAINTAINERS: Add BCM63158 maintainer to BCMBCA entry

Since ARCH_BCM63158 SoC support is merged into ARCH_BCMBCA, add BCM63158
maintainer Philippe to bcmbca maintainer list.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: replace ARCH_BCM63158 symbols in Kconfig with BCM63158

As CONFIG_ARCH_BCM63158 is replaced with CONFIG_BCM63158, update the
Kconfig to use the new config symbol.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: remove bcm63158 support under CONFIG_ARCH_BCM63158

Now that BCM63158 is supported under CONFIG_ARCH_BCMBCA and
CONFIG_BCM63158, remove the original ARCH_BCM63158 support and migrate
configuration settings.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: add bcm63158 SoC support under CONFIG_ARCH_BCMBCA

BCM63158 is a Broadcom B53 based DSL Gateway SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family. Like other
Broadband SoC, this patch adds it under CONFIG_BCM63158 chip
config and CONFIG_ARCH_BCMBCA platform config.

This initial support includes a bare-bone implementation and dts with
CPU subsystem, memory and ARM PL011 uart. This SoC is supported in the
linux-next git repository so the dts and dtsi files are copied from
linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: add bcm4908 SoC support

BCM4908 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added
under ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux git repository so the dts and dtsi
files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

arm: bcmbca: add bcm6813 SoC support

BCM6813 is a Broadcom B53 based PON and WLAN AP router SoC. It is part
of the BCA (Broadband Carrier Access origin) chipset family so it's
added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

arm: bcmbca: add bcm4912 SoC support

BCM4912 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts
and dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

arm: bcmbca: add bcm63146 SoC support

BCM63146 is a Broadcom B53 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

arm: bcmbca: add bcm63138 SoC support

BCM63138 is an ARM A9 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory, ARM A9 global timer
and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

This patch applies on top of the my previous patch [1].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/490570.html

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>

arm: bcmbca: add bcm63148 SoC support

BCM63148 is an Broadcom B15 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

arm: bcmbca: add bcm6756 SoC support

BCM6756 is an ARM A7 based WLAN Gateway and Access Point Broadband SoC.
It is part of the BCA(Broadband Carrier Access origin) chipset family so
it's added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

arm: bcmbca: add bcm6878 SoC support

BCM6878 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011
uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

arm: bcmbca: add bcm6846 SoC support

BCM6846 is an ARM A7 based PON Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

arm: bcmbca: add bcm63178 SoC support

BCM63178 is an ARM A7 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux with minor fix-up that needs to be
upstreamed to linux as well.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

Signed-off-by: William Zhang <william.zhang@broadcom.com>

buildman: Handle the MAINTAINERS 'N' tag

This is needed for some soon-to-be-applied patches. Scan the configs/
directory to see if any of the files match.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com>
Suggested-by: Tom Rini <trini@konsulko.com>

Merge tag 'video-20221030' of https://source.denx.de/u-boot/custodians/u-boot-video

 - fix [hv]sync active vs back porch in dw_mipi_dsi
 - simplefb rotation support
 - support splash as raw image from MMC
 - enhancements to Truetype console (multiple fonts and sizes)
 - drop old LCD support

video: Rename CONFIG_DM_VIDEO to CONFIG_VIDEO

Now that all the old code is gone, rename this option. Driver model
migration is now complete.

Signed-off-by: Simon Glass <sjg@chromium.org>

pci: Drop test for DM_VIDEO

This is not needed anymore, since there is no other option.

Signed-off-by: Simon Glass <sjg@chromium.org>

video: Make all video options depend on DM_VIDEO

Rather than sprinkly this file with 'depends' statements, make all options
depend on DM_VIDEO.

Signed-off-by: Simon Glass <sjg@chromium.org>

video: Drop SPLASHIMAGE_CALLBACK

This is not used anymore. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

video: Drop common LCD implementation

This code is no-longer used. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

video: Drop use of the lcd header file

This file is being removed so drop remaining references to it.

Signed-off-by: Simon Glass <sjg@chromium.org>

video: Drop CONFIG_LCD

This option is not used anymore. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

video: Drop CONFIG_VIDEO

This option is not used anymore. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

video: Drop CONFIG_VIDEO

This option is not used anymore. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>