test: video: Export the video-checking functions

We want to check the display contents in expo tests, so move the two
needed functions to a new header file.

Rename them to have a video_ prefix.

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

video: Add a way to write a partial string to the console

When writing multiple lines of text we need to be able to control which
text goes on each line. Add a new vidconsole_put_stringn() function to
help with this.

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

video: truetype: Support a limit on the width of a line

Expo needs to be able to word-wrap lines so that they are displayed as
the user expects. Add a limit on the width of each line and support this
in the measurement algorithm.

Add a log category to truetype while we are here.

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

video: truetype: Support newlines in the measured string

It is useful to be able to embed newline characters in the string and
have the text measured into multiple lines. Add support for this.

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

video: truetype: Fill in the measured line

Create a measured line for the (single) line of text.

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

video: Begin support for measuring multiple lines of text

Update the vidconsole API so that measure() can measure multiple lines
of text. This will make it easier to implement multi-line fields in
expo.

Tidy up the function comments while we are here.

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

video: Add a test for font measurement

Add a simple test which measures a line of text using a Truetype font.

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

sandbox: Select white-on-black

Use white on black for the expo menu as it is easier on the eyes.

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

video: Make white-on-black a video-device property

The CONFIG_WHITE_ON_BLACK setting is hard-coded at build-time. It is
useful to be able to control this when showing menus.

Create a property to hold this information, using the CONFIG as the
initial value.

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

console: Support a format string for stderr output

Add a console_printf_select_stderr() function so that it is not
necessary for the caller to process the format string.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>

Merge patch series "Qualcomm: cleanup OF_LIVE fixup and fix RB1/2"

Caleb Connolly <caleb.connolly@linaro.org> says:

Introduce a new event to signal that the live tree has been built,
allowing boards to perform fixups on the tree before devices are bound.
Crucially this allows for devices to be enabled or disabled, but also
allows for properties that are parsed during the bind stage to be
modified (such as dr_mode for dwc3).

With this in place, mach-snapdragon is switched over to use the event
and some hacky U-Boot specific DT overrides (which had to be undone
prior to booting an image) are removed in favour of fixing up the
livetree (which is not passed on to further boot stages).

Finally, some minor fixes are made for the QCM2290 RB1 board, the sdcard
is enabled and it now uses USB host mode in U-Boot like it's bigger
sibling the RB2.

Link: https://lore.kernel.org/r/20250411-livetree-fixup-v2-0-1236823377bb@linaro.org

pinctrl: qcom: qcm2290: fix off by 1 in pin_count

There are 134 pins not 133, oops! This fixes the sdcard on the RB1 as
the pins now all get configured correctly.

Fixes: 0ecb8cfcb930 ("pinctrl: qcom: add qcm2290 pinctrl driver")
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

clk/qcom: qcm2290: show clock name in set_rate()

The device name is always clk_qcom... Not very useful.

Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

mach-snapdragon: of_fixup: set dr_mode for RB1/2 boards

The RB1 and RB2 have a single USB controller which is manually muxed
between a type-c port and an internal USB hub via a DIP switch. OTG is
supported in Linux, but the DWC3 driver in U-Boot can only handle a
single mode, and defaults to peripheral mode.

We did hack around this on the RB2, but the RB1 got left out.

Now that we can fix up the live tree before devices are bound, drop the
DTS hacks and do the fixup at runtime instead.

Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

mach-snapdragon: of_fixup: update comment

we don't rewrite the volume buttons any more.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

mach-snapdragon: of_fixup: remove confusing log message

The debug log here had the logic completely backwards, even though the
code is actually correct. Remove it since it's extraneous anyway.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

mach-snapdragon: of_fixup: skip disabled USB nodes

There's no need to waste time fixing up nodes that aren't used on this
device. Skip them.

Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

mach-snapdragon: use EVT_OF_LIVE_INIT to apply DT fixups

This will now apply fixups prior to devices being bound, which makes it
possible to enable/disable devices and adjust more properties that might
be read before devices probe.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

event: signal when livetree has been built

OF_LIVE offers a variety of benefits, one of them being that the live
tree can be modified without caring about the underlying FDT. This is
particularly valuable for working around U-Boot limitations like lacking
USB superspeed support on Qualcomm platforms, no runtime OTG, or
peripherals like the sdcard being broken (and displaying potentially
worrying error messages).

Add an event to signal when the live tree has been built so that we can
apply fixups to it directly before devices are bound.

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>

Merge tag 'dm-pull-mayday' of git://git.denx.de/u-boot-dm

Support for calculating video damage

Merge tag 'efi-2025-07-rc2' of https://source.denx.de/u-boot/custodians/u-boot-efi

Pull request efi-2025-07-rc2

CI:

* https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/26025

Documentation:

* ti: update bash code-block directives to prompt
* ti: k3: add language for code-block directive
* correct uthread inline documentation

UEFI:

* correctly handle EFI FIT images without initrd
* pass kernel load address not entry point for EFI FIT images

Other:

* boot:let BOOTSTAGE_RECORD_COUNT default to 50

video: Enable VIDEO_DAMAGE for drivers that need it

Some drivers call video_set_flush_dcache() to indicate that they want to
have the dcache flushed for the frame buffer. These drivers benefit from
our new video damage control, because we can reduce the amount of memory
that gets flushed significantly.

This patch enables video damage control for all device drivers that call
video_set_flush_dcache() to make sure they benefit from it.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
[Alper: Add to VIDEO_TIDSS, imply instead of select]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

video: Always compile cache flushing code

The dcache flushing code path was conditional on ARM && !DCACHE config
options. However, dcaches exist on other platforms as well and may need
clearing if their driver requires it.

Simplify the compile logic and always enable the dcache flush logic in
the video core. That way, drivers can always rely on it to call the arch
specific callbacks.

This will increase code size for non-ARM platforms with CONFIG_VIDEO=y
slightly.

Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-13-alpernebiyasak@gmail.com/
Added workaround for CONFIG_SYS_CACHELINE_SIZE for ibex-ast2700:
Signed-off-by: Simon Glass <sjg@chromium.org>

video: Use VIDEO_DAMAGE for VIDEO_COPY

CONFIG_VIDEO_COPY implemented a range-based copying mechanism: If we
print a single character, it will always copy the full range of bytes
from the top left corner of the character to the lower right onto the
uncached frame buffer. This includes pretty much the full line contents
of the printed character.

Since we now have proper damage tracking, let's make use of that to reduce
the amount of data we need to copy. With this patch applied, we will only
copy the tiny rectangle surrounding characters when we print them,
speeding up the video console.

After this, changes to the main frame buffer are not immediately copied
to the copy frame buffer, but postponed until the next video device
sync. So issue an explicit sync before inspecting the copy frame buffer
contents for the video tests.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
[Alper: Rebase for fontdata->height/w, fill_part(), fix memmove(dev),
        drop from defconfig, use damage.xstart/yend, use IS_ENABLED(),
        call video_sync() before copy_fb check, update video_copy test]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-12-alpernebiyasak@gmail.com/

video: Only dcache flush damaged lines

Now that we have a damage area tells us which parts of the frame buffer
actually need updating, let's only dcache flush those on video_sync()
calls. With this optimization in place, frame buffer updates - especially
on large screen such as 4k displays - speed up significantly.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
[Alper: Use damage.xstart/yend, IS_ENABLED()]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-11-alpernebiyasak@gmail.com/

efi_loader: GOP: Add damage notification on BLT

Now that we have a damage tracking API, let's populate damage done by
UEFI payloads when they BLT data onto the screen.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[Alper: Add struct comment for new member]
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-10-alpernebiyasak@gmail.com/

video: Add damage notification on bmp display

Let's report the video damage when we draw a bitmap on the screen. This
way we can later lazily flush only relevant regions to hardware.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-9-alpernebiyasak@gmail.com/

video: test: Test video damage tracking via vidconsole

With VIDEO_DAMAGE, the video uclass tracks updated regions of the frame
buffer in order to avoid unnecessary work during a video sync. Enable
the config in sandbox and add a test for it, by printing strings at a
few locations and checking the tracked region.

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Adjust test avoid temporary failures in this patch:
Signed-off-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-8-alpernebiyasak@gmail.com/

vidconsole: Add damage notifications to all vidconsole drivers

Now that we have a damage tracking API, let's populate damage done by
vidconsole drivers. We try to declare as little memory as damaged as
possible.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
[Alper: Rebase for met->baseline, fontdata->height/width, make rotated
        console_putc_xy() damages pass tests, edit patch message]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-7-alpernebiyasak@gmail.com/

dm: video: Add damage notification on display fills

Let's report the video damage when we fill parts of the screen. This
way we can later lazily flush only relevant regions to hardware.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
[Alper: Move from video_clear() to video_fill(), video_fill_part()]
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-6-alpernebiyasak@gmail.com/

dm: video: Add damage tracking API

We are going to introduce image damage tracking to fasten up screen
refresh on large displays. This patch adds damage tracking for up to
one rectangle of the screen which is typically enough to hold blt or
text print updates. Callers into this API and a reduced dcache flush
code path will follow in later patches.

Signed-off-by: Alexander Graf <agraf@csgraf.de>
Reported-by: Da Xue <da@libre.computer>
[Alper: Use xstart/yend, document new fields, return void from
        video_damage(), declare priv, drop headers, use IS_ENABLED()]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-5-alpernebiyasak@gmail.com/
Reviewed-by: Simon Glass <sjg@chromium.org>

video: test: Test partial updates of hardware frame buffer

With VIDEO_COPY enabled, only the modified parts of the frame buffer are
intended to be copied to the hardware. Add a test that checks this, by
overwriting contents we prepared without telling the video uclass and
then checking if the overwritten contents have been redrawn on the next
sync.

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-4-alpernebiyasak@gmail.com/

video: test: Support checking copy frame buffer contents

The video tests have a helper function to generate a pseudo-digest of
frame buffer contents, but it only does so for the main one. There is
another check that the copy frame buffer is the same as that. But
neither is enough to test if only the modified regions are copied to the
copy frame buffer, since we will want the two to be different in very
specific ways.

Add a boolean argument to the existing helper function to indicate which
frame buffer we want to inspect, and update the existing callers.

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-3-alpernebiyasak@gmail.com/

video: test: Split copy frame buffer check into a function

While checking frame buffer contents, the video tests also check if the
copy frame buffer contents match the main frame buffer. To test if only
the modified regions are updated after a sync, we will need to create
situations where the two are mismatched. Split this check into another
function that we can skip calling, since we won't want it to error on
those mismatched cases.

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-2-alpernebiyasak@gmail.com/

boot: let BOOTSTAGE_RECORD_COUNT default to 50

BOOTSTAGE_RECORD_COUNT=30 is too small to record booting a FIT image
with EFI kernel, initrd, dtb as seen on the StarFive VisionFive 2
board.

Increase the default for BOOTSTAGE_RECORD_COUNT to 50.

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

bootm: pass kernel load address not entry point for IH_OS_EFI

The EFI sub-system needs the load address and not the entry point
to boot the binary passed from the bootm command. The entry point
is derived from the PE-COFF header of the binary.

Fixes: ecc7fdaa9ef1 ("bootm: Add a bootm command for type IH_OS_EFI")
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

doc: ti: k3: add language for code-block directive

The code-block directive supports the optional language property which
enables syntax highlighting for the block[1].

This patch adds the relevant language property for code-blocks in k3
docs.

[1]:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-code-block

Signed-off-by: Anshul Dalal <anshuld@ti.com>

doc: ti: update bash code-block directives to prompt

The code-block directive requires addition of the prompt symbol for each
line, using the prompt directive instead allows for auto insertion of
the symbol per line[1].

For the readers, the character added by the prompt directive is
un-selectable i.e the entire line can be more easily selected for copy
pasting etc. Whereas with code-block, the prompt symbol like "$" is also
selectable which is usually not the intent.

This is mostly a QoL addition + making the docs consistent since k3.rst
makes use of prompt directives which these board docs include from.

[1]: https://pypi.org/project/sphinx-prompt/

Signed-off-by: Anshul Dalal <anshuld@ti.com>

efi_loader: fix typo initd_sz to initrd_sz

Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

efi_loader: bootbin: do not load an initrd if none is provided

Do not try to create an initrd device path nor try to register
an initrd with the EFI_LOAD_FILE2_PROTOCOL if none is provided.

Handle initrd installation in efi_binary_run_dp with
efi_install_initrd, imitating what is done for the fdt.

Fixes: 36835a9105c ("efi_loader: binary_run: register an initrd")
Reported-by: Weizhao Ouyang <o451686892@gmail.com>
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Tested-by: Weizhao Ouyang <o451686892@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

uthread: doc: fix inline documentation

Fix Sphinx warnings:

 $ make htmldocs
 [...]
 ./include/uthread.h:56: warning: cannot understand function prototype: 'enum uthread_mutex_state '
 ./include/uthread.h:64: warning: cannot understand function prototype: 'struct uthread_mutex '
 ./include/uthread.h:56: warning: cannot understand function prototype: 'enum uthread_mutex_state '
 ./include/uthread.h:64: warning: cannot understand function prototype: 'struct uthread_mutex '

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reported-by: Tom Rini <trini@konsulko.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

mtd: mtdpart: Support MTDPART_SIZ_FULL in fixed-partitions

Flash partitions may specify MTDPART_SIZ_FULL (=0) as the size of the
partition to indicate "the remainder of the flash". Make this work with
device-tree "fixed-partitions" as well.

This makes MTD partitioning compatible with the Linux kernel, see:
  https://github.com/torvalds/linux/blob/master/include/linux/mtd/partitions.h#L29
  https://github.com/torvalds/linux/blob/master/drivers/mtd/mtdpart.c#L123

Previously, this could only be done through MTDPARTS so this change allows
boards like topic_miami to migrate from `mtdparts`/`mtdids` to devicetree
partitions.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>

clk: fix crash on clk_set_rate clean rate cache

It's currently possible to make the bootloader crash on calling
clk_set_rate caused by the loop in clk_clean_rate_cache.

The loop assume that every child of the clock node are also clock
device but this is not always the case. For example it's common for a
clock to bind to a reset device or also expose a syscon if the clock
register map is also used to apply special configuration.

In such case, on accessing a device as a clock, the bootloader crash. To
correctly handle this, check if the child device is actually a clock and
ignore otherwise.

Fixes: 6b7fd3128f71 ("clk: fix set_rate to clean up cached rates for the hierarchy")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>

common: board: fix build condition of noncached memory initcall

CONFIG_SYS_NONCACHED_MEMORY is defined as hex, not bool. It should be
replaced with CONFIG_SYS_HAS_NONCACHED_MEMORY when switched from #ifdef to
CONFIG_IS_ENABLED().

Fixes: 6c171f7a184 (common: board: make initcalls static)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> # rock5b
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

Revert "mtd: spi-nor: Remove recently added SST special case"

SST(sst26wf016) flashes have multiple erase block sizes, including
8 KB, 32 KB, and 64 KB. Since a 64 KB sector erase cannot be performed
on all blocks, the 4 KB sector erase command should be used instead.
Enabling the SPI_FLASH_USE_4K_SECTORS configuration allows the use of
4 KB sector erases, but it may increase the erase operation time for large
memory flashes.

This reverts commit 34cd4a72fb2d113e2754c0d643618a8e3fa549ab

MEMORY ORGANIZATION:
The SST26WF016B/016BA SQI memory array is organized
in uniform, 4 KByte erasable sectors with the following
erasable blocks: eight 8 KByte parameter, two
32 KByte overlay, and thirty 64 KByte overlay blocks.
See Figure 3-1.

Top of Memory Block
┌──────────┐
│  8 KByte │
├──────────┤
│  8 KByte │
├──────────┤
│  8 KByte │
├──────────┤
│  8 KByte │
├──────────┤
│ 32 KByte │
├──────────┤
│ 64 KByte │
├──────────┤
│ 64 KByte │
├──────────┤
│ 64 KByte │
├──────────┤
│ 32 KByte │
├──────────┤
│  8 KByte │
├──────────┤
│  8 KByte │
├──────────┤
│  8 KByte │
├──────────┤
│  8 KByte │
└──────────┘
Bottom of Memory Block

      ┌────────────────────────────────┐
      │            64 KByte            │
      ├────────────────────────────────┤
      │            64 KByte            │
      └────────────────────────────────┘

      Expanded View:
      ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
      │ 4 KB │ │ 4 KB │ │ 4 KB │ │ 4 KB │
      ├──────┤ ├──────┤ ├──────┤ ├──────┤
      │  . .  .  (continues) . .  .   │
      └──────┘ └──────┘ └──────┘ └──────┘

2 Sectors for 8 KByte blocks
8 Sectors for 32 KByte blocks
16 Sectors for 64 KByte blocks

Link: https://ww1.microchip.com/downloads/en/DeviceDoc/20005013D.pdf
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

drivers: spi: Fix data loss issue in QSPI

QSPI driver performs chip select operation before every read/write
access. During this operation, driver needs to enable and disable
the QSPI controller. This may cause data loss if there is inadvertent
halting of any ongoing read/write operation. To avoid this scenario,
waiting for the QSPI status to be idle before next read/write
operation is implemented.

Signed-off-by: Naresh Kumar Ravulapalli <nareshkumar.ravulapalli@altera.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>

Merge patch series "Add support for Infineon S28HL256T and S28HL02GT"

Takahiro Kuwano <Takahiro.Kuwano@infineon.com> says:

Those are 3.0V, 256Mb/2Gb NOR Flash devices with Octal interface.
Same fanctionalities with 1.8V version that are already supported.

Link: https://lore.kernel.org/r/cover.1743575001.git.Takahiro.Kuwano@infineon.com

mtd: spi-nor-ids: Add support for S28HL02GT

Infineon S28HL02GT is 3.0V, 2Gb Flash device with Octal interface.
It has the same functionalities with S28HS02GT.

Link: https://www.infineon.com/dgdl/Infineon-S28HS02GT_S28HS04GT_S28HL02GT_S28HL04GT_2Gb_4Gb_SEMPER_Flash_Octal_interface_1.8V_3.0V-DataSheet-v01_00-EN.pdf?fileId=8ac78c8c7e7124d1017f0631e33714d9
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: spi-nor-ids: Add support for S28HL256T

Infineon S28HL256T is 3.0V, 256Mb Flash device with Octal interface.
It has the same functionalities with S28HS256T.

Link:https://www.infineon.com/dgdl/Infineon-S28HS256T_S28HL256T_256Mb_SEMPER_Flash_Octal_interface_1_8V_3-DataSheet-v02_00-EN.pdf?fileId=8ac78c8c8fc2dd9c018fc66787aa0657

Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

mtd: spi-nor: Use CONFIG_IS_ENABLED for CONFIG_SPI_FLASH_BAR defines

At the moment a mixture of ifdef(CONFIG_IS_ENABLED) and
CONFIG_IS_ENABLED(SPI_FLASH_BAR) is used in the spi-nor framework.
This leads to misbehaviour in the SPL as there is no Kconfig option
CONFIG_SPL_SPI_FLASH_BAR. This commit standardizes the use of
CONFIG_SPI_FLASH to get SPLs that load U-Boot proper from the
SPI flash to work again.

Fixes: 9bb02f7 (mtd: spi-nor: Fix the spi_nor_read() when config SPI_STACKED_PARALLEL is enabled)
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>

mtd: spi-nor: Add NO_CHIP_ERASE flag for mt35xu01g/2g

Since the opcode SPINOR_OP_CHIP_ERASE (0xc7) is not supported
for the mt35xu01g/2g flashes, the NO_CHIP_ERASE flag has been added
to enable sector erase functionality instead.

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>

Docker, CI: Add vexpress_fvp / vexpress_fvp_bloblist support

This adds the vexpress_fvp and vexpress_fvp_bloblist platforms to the
list of platforms we test via emulator in CI. In order to do this we
need to first have our container runtime have TF-A builds for the
vexpress_fvp platform, both with and without transfer list support as
well as installing "telnet" so that we can access console. In the CI
files we check for the existence of /opt/tf-a/${TEST_PY_BD} and if
found, copy bl1.bin and fip.bin to /tmp and set the variables so that we
can later run FVP to run.

Note that we currently disable the hostfs (semihosting) tests as they
trigger a bug in FVP. This has been reported upstream, and can be
enabled when fixed.

Reviewed-by: Harrison Mutai <harrison.mutai@arm.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

Prepare v2025.07-rc1

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

mtd: mtdparts: calculate mtd partition offset before calculating size

The mtd partition offset must be calculated first as it will be
referenced when calculating the mtd partition size.

Change-Id: Iccfd101b0a9597ac240c25670da638a82af28980
Fixes: 1ca97ee9039 (mtd: mtdpart: Support MTD_SIZE_REMAINING with unallocated memory area)
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Reported-by: Francesco Dolcini <francesco@dolcini.it>

mkimage: fix option parsing segfault

getopt_long() expects a NULL-terminated list of structures. The current
list in mkimage does not have a zero-filled structure at the end, which
can cause getopt_long() to walk past the end of the array when passing
an unknown option, causing a segmentation fault.

As a reproducer, the following command causes a segmentation fault
(tested in Debian 12):

    mkimage --foobar

Signed-off-by: Carlos López <carlos.lopezr4096@gmail.com>

lmb: use a different bit position for LMB_NOMAP

The LMB memory region attributes flags are used to specify the
behaviour of the memory regions with respect to allocations -- for
e.g. it is allowed to re-allocate a memory region already reserved
with the LMB_NONE flag. The flags use values with different bit
positions through the BIT() macro. Move the LMB_NOMAP value to bit
position 1, and also move the other flags accordingly. Using bit
position 0 for LMB_NOMAP results in the logic in
lmb_print_region_flags() to break, which prints an incorrect value for
the regions with LMB_NOMAP atribute.

Fixes: 3d56c06551d ("lmb: Move enum lmb_flags to a u32")
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>

cmd: Kconfig: Fix typos

fix the following typos
- from "categorys" to "categories"
- from "indivdually" to "individually"

Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

cros_ec_sandbox.c: Drop spi.h include

As this driver needs to use the special sandbox <asm/malloc.h> header
rather than normal malloc, it must be careful of the includes it brings
in. It does not need <spi.h> for anything, so drop it.

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

net: ti: am65-cpsw-nuss: invoke phy_config() in driver's .start callback

Currently, the phy_config() API is invoked by the driver only once since it
has been probed. While this works in general, it doesn't allow the driver
to bring the PHY back to its default reset state. As a result, the driver
might not be able to recover the PHY from a bad state. To address this,
move phy_config() into the driver's start callback (am65_cpsw_start()).

Apart from providing the means to recover the PHY in the event of failure,
the implementation is in line with the idea of "reset and configure" that
is already followed by am65_cpsw_start() when it comes to programming the
CPSW MAC.

Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>

Merge patch series "Apple RTKit improvements"

Mark Kettenis <kettenis@openbsd.org> says:

This is a collection of improvements for the Apple RTKit code
that we have been carrying downstream for some time now.

Link: https://lore.kernel.org/r/20250420115808.94272-1-kettenis@openbsd.org

arm: apple: rtkit: Support allocating OSLog out of SRAM in helper

The new OSLog region in MTP (firmware 13.3+) persists on handoff to
Linux. To avoid having to come up with some weird DART handoff or DAPF
tricks, let's just steal some of the coprocessor's dedicated SRAM. This
keeps it happy and Linux doesn't need any special handoff then.

Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

arm: apple: rtkit: Add endpoint field to buffers

To be used for special-case oslog support in rtkit-helper.

Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

arm: apple: rtkit: Add OSLog buffer support

This will work for u-boot itself, but needs a special workaround in the
MTP driver for Linux handoff to work.

Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

arm: apple: rtkit: Add a generic RTKit helper driver

This driver handles the MTP ASC coprocessor, which does not need any
special handling on the RTKit side and communicates out-of-band.

Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

arm: apple: rtkit: Add default buffer handlers

For devices without specific buffer methods, just assume we can give
them raw memory pointers when they request a buffer.

Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

arm: apple: rtkit: Add support for AP power & syslogs

This is required for MTP to work properly

Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>

Merge tag 'u-boot-imx-master-20250428' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/25974

- Fix power-domain ref counting regression.
- Fix i.MX8MP USB clock regression.
- Fix i.MX8MM osc_32k regression in SPL.
- Finish converting clock-osc-24 back to osc_24 on i.MX.
- Several imx8mp capricorn updates.
- Update Stefano Babic's email address.
- Fix fsl_qspi bug by moving AHB read buffer config after LUT.
- Fix verdin imx95 sku 0089 pid4.

Merge patch series "bloblist: fix the overriding of fdt from bloblist"

This series from Raymond Mao <raymond.mao@linaro.org> fixes some cases
of passing the device tree to U-Boot via standard passage and then
ensures that we set the environment variable of the device tree
correctly in this case.

Link: https://lore.kernel.org/r/20250331224011.2734284-1-raymond.mao@linaro.org

Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi

We have improvements to the reliability of H6 and H616 DRAM
initialisation, hopefully avoiding those occasional size misdetections
many people reported before.
Also there is some modernisation of the USB PHY code, to use DT provided
regulators and GPIOs, instead of relying on this being badly duplicated
in Kconfig. This also happens to fix broken USB operations for older
boards (using the A20 SoCs, for instance), which were clashing over
grabbing some GPIOs, leading to a driver bailout.  There is also some
rework of the H6/H616 SPL clock code, to prepare it for being reused by
the upcoming Allwinner A523 support. This drops the usage of C structs
to model MMIO register frames, and replaces them by using an addition of
the base address with a macro defined offset.  Also in preparation for
A523 there is one fix and one addition for the FEL code, to prepare for
the GICv3 interrupt controller that the new SoC uses. And since this is
a simple fix, and was ready, there is also the watchdog driver for that
new SoC. Finally tossing in an easy fix to some H616 defconfig files to
enable eMMC.

I also use the opportunity to enable proper page table protection
(observing read-only and no-execute attributes), support for which the
arm64 port recently gained. I didn't spot any issues on my arm64 board
tests, but it can be easily disabled or backed out again in case any
issues arise.

Full support for the two new SoC series (A133 and A523) we are working
on is not quite ready yet, but might follow still a bit later if
progress permits.

CI passed, and boot-tested on at least one board with a H616, H6, A64,
H3, A20, T113s.

sunxi: clock: H6: remove struct sunxi_prcm_reg

With the SPL clock code and the DRAM init routine we converted all users
of the H6 class "struct sunxi_prcm_reg" over to use #define'd register
offsets now.

Drop the whole definition of this struct now, since it's not needed
anymore, for all H6 and H616 boards.
This removes the entire fragile and questionable definition, and allows
new SoCs to share the code more easily.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: H6/H616: dram: remove usage of struct sunxi_prcm_reg

The Allwinner H6 and H616 DRAM initialisation code uses a complex C
struct, modelling the PRCM clock register frame. For those SoCs, this
struct contains 20 registers, but the DRAM code only uses two of them.

Since we want to get rid of this struct, drop the usage of the struct in
the H6 and H616 DRAM code, by using #define'd register names and their
offset, and then adding those names to the base pointer.

This removes one more user of the PRCM clock register struct.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: clock: H6: drop usage of struct sunxi_prcm_reg

U-Boot drivers often revert to using C structures for modelling hardware
register frames. This creates some problems:
- A "struct" is a C language construct to group several variables
  together. The details of the layout of this struct are partly subject
  to the compiler's discretion (padding and alignment).
- The "packed" attribute would force a certain layout, but we are not
  using it.
- The actual source of information from the data sheet is the register
  offset. Here we create an artificial struct, carefully tuning the
  layout (with a lot of reserved members) to match that offset. To help
  with correctness, we put the desired information as a *comment*,
  though this is purely for the human reader, and has no effect on the
  generated layout. This sounds all very backwards.
- Using a struct suggests we can assign a pointer and then access the
  register content via the members. But this is not the case, instead
  every MMIO register access must go through specific accessor functions,
  to meet the ordering and access size guarantees the hardware requires.
- We share those structs in code shared across multiple SoC families,
  though most SoCs define their own version of the struct. Members must
  match in their name, across every SoC, otherwise compilation will fail.
  We work around this with even more #ifdefs in the shared code.
- Some SoCs have an *almost* identical layout, but differ in a few
  registers. This requires hard to maintain #ifdef's in the struct
  definition.
- Some of the register frames are huge: the H6 CCU device defines 127
  registers. We use 15 of them. Still the whole frame would need to be
  described, which is very tedious, but for no reason.
- Adding a new SoC often forces people to decide whether to share an
  existing struct, or to create a new copy. For some cases (say like 80%
  similarity) this works out badly either way.

The Linux kernel heavily frowns upon those register structs, and instead
uses a much simpler solution: #define REG_NAME  <offset>
This easily maps to the actual information from the data sheet, and can
much simpler be shared across multiple SoCs, as it allows to have all
SoC versions visible, so we can use C "if" statements instead of #ifdef's.
Also it requires to just define the registers we need, and we can use
alternative locations for some registers much more easily.

Drop the usage of "struct sunxi_prcm_reg" in the H6 SPL clock code, by
defining the respective register names and their offsets, then adding
them to the base pointer.
We cannot drop the struct definition quite yet, as it's also used in
other drivers, still.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: clock: H6: remove struct sunxi_ccm_reg

With the SPL clock code, the MMC driver, and the DRAM init routine we
converted all users of the H6 class "struct sunxi_ccm_reg" over to use
 #define'd register offsets now.

Drop the whole definition of this struct now, since it's not needed
anymore, for all H6 and H616 boards.
This removes the entire fragile and questionable definition, and allows
new SoCs to share the code more easily.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: H6: dram: remove usage of struct sunxi_ccm_reg

The Allwinner H6 DRAM initialisation code uses a complex C struct,
modelling the clock device's register frame. For this SoC, the struct
contains 127 registers, but the DRAM code only uses four of them.

Since we want to get rid of this struct, drop the usage of the struct in
the H6 DRAM code, by using #define'd register names and their offset, and
then adding those names to the base pointer.

This removes one more user of the clock register struct.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: H616: dram: remove usage of struct sunxi_ccm_reg

The Allwinner H616 DRAM initialisation code uses a complex C struct,
modelling the clock device's register frame. For this SoC, the struct
contains 127 registers, but the DRAM code only uses four of them.

Since we want to get rid of this struct, drop the usage of the struct in
the H616 DRAM code, by using #define'd register names and their offset,
and then adding those names to the base pointer.

This removes one more user of the clock register struct.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: mmc: remove usage of struct sunxi_ccm_reg

The Allwinner MMC code uses a complex C struct, modelling the clock
device's register frame. We rely on sharing the member names across all
Allwinner SoCs, which is fragile.

Drop the usage of the struct in the MMC code, by using #define'd
register names and their offset, and then adding those names to the base
pointer. This requires to define those offsets for all SoCs, but since we
only use between four and six clock registers in the MMC code, this is
easily done.

This removes one common user of the clock register struct.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: clock: H6: drop usage of struct sunxi_ccm_reg

U-Boot drivers often revert to using C structures for modelling hardware
register frames. This creates some problems:
- A "struct" is a C language construct to group several variables
  together. The details of the layout of this struct are partly subject
  to the compiler's discretion (padding and alignment).
- The "packed" attribute would force a certain layout, but we are not
  using it.
- The actual source of information from the data sheet is the register
  offset. Here we create an artificial struct, carefully tuning the
  layout (with a lot of reserved members) to match that offset. To help
  with correctness, we put the desired information as a *comment*,
  though this is purely for the human reader, and has no effect on the
  generated layout. This sounds all very backwards.
- Using a struct suggests we can assign a pointer and then access the
  register content via the members. But this is not the case, instead
  every MMIO register access must go through specific accessor functions,
  to meet the ordering and access size guarantees the hardware requires.
- We share those structs in code shared across multiple SoC families,
  though most SoCs define their own version of the struct. Members must
  match in their name, across every SoC, otherwise compilation will fail.
  We work around this with even more #ifdefs in the shared code.
- Some SoCs have an *almost* identical layout, but differ in a few
  registers. This requires hard to maintain #ifdef's in the struct
  definition.
- Some of the register frames are huge: the H6 CCU device defines 127
  registers. We use 15 of them. Still the whole frame would need to be
  described, which is very tedious, but for no reason.
- Adding a new SoC often forces people to decide whether to share an
  existing struct, or to create a new copy. For some cases (say like 80%
  similarity) this works out badly either way.

The Linux kernel heavily frowns upon those register structs, and instead
uses a much simpler solution: #define REG_NAME <offset>
This easily maps to the actual information from the data sheet, and can
much simpler be shared across multiple SoCs, as it allows to have all
SoC versions visible, so we can use C "if" statements instead of #ifdef's.
Also it requires to just define the registers we need, and we can use
alternative locations for some registers much more easily.

Drop the usage of "struct sunxi_ccm_reg" in the H6 SPL clock code, by
defining the respective register names and their offsets, then adding
them to the base pointer.
We cannot drop the struct definition quite yet, as it's also used in
other drivers, still.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: armv8: FEL: save and restore SP_IRQ

Thanks for Jernej's JTAG debugging effort, it turns out that the BROM
expects SP_IRQ to be saved and restored, when we want to enter back into
FEL after the SPL's AArch64 stint.
Save and restore SP_IRQ as part of the FEL state handling. The banked
MRS/MSR access to SP_IRQ, without actually being in IRQ mode, was
introduced with the ARMv7 virtualisation extensions. The Arm Cortex-A8
cores used in the A10/A13s or older F1C100s SoCs would not support that,
but this code here is purely in the ARMv8/AArch64 code path, so it's
safe to use unconditionally.

Reported-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: armv8: FEL: save and restore GICv3 registers

To be able to return to the BootROM FEL USB debug code, we must restore
the core's state as accurately as possible after the SPL has been run.
Since the BootROM runs in AArch32, but the SPL uses AArch64, this requires
a core reset, which clears the core's state.
So far we were saving and restoring the required registers like SCTLR
and VBAR, but could ignore the interrupt controller's state (GICC), since
that lives in MMIO registers, unaffected by a core reset.
Newer Allwinner SoCs now feature a GICv3 interrupt controller, which keeps
some GIC state in architected system registers, and those are cleared
when we switch back to AArch32.

To enable FEL operation on the Allwinner A523 SoC,
Add AArch32 assembly code to save and restore the ICC_PMR and ICC_IGRPEN1
system registers. The other GICv3 sysregs are either not relevant for the
BROM operation, or haven't been changed from their reset defaults by the
BROM anyway.

This enables FEL operation on the Allwinner A523 family of SoCs.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

watchdog: sunxi: add A523 support

The Allwinner A523 SoC moved the watchdog into a separate MMIO frame,
and also shifted the registers a bit: the control, config, and mode
register are located four bytes earlier.

Add the new compatible string, and connect it to the new struct
describing the new register layout.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefan Roese <sr@denx.de>

sunxi: Kconfig: Remove obsolete USBx_* pin symbols

Now that the USB PHY driver uses the device tree to get the VBUS detect
and USB ID GPIOs, these Kconfig symbols are unused. Remove them from
their Kconfig definition, and also from all defconfig files.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

phy: sun4i-usb: Determine USB OTG detection pin from devicetree

So far Allwinner boards controlled the USB OTG ID detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_id_det-gpios property.

Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.

This removes the need to name that GPIO in the defconfig file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

phy: sun4i-usb: Determine VBUS detection pin from devicetree

So far Allwinner boards controlled the USB VBUS detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_vbus_det-gpios property.

Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.

This removes the need to name that GPIO in the defconfig file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

gpio: axp: Remove virtual VBUS enable GPIO

Now that this functionality is modeled using the device tree and
regulator uclass, the named GPIO is not referenced anywhere. Remove
it, along with the rest of the support for AXP virtual GPIOs.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: Remove obsolete USBx_VBUS_PIN Kconfig symbols

Now that the USB PHY driver uses the device tree to get VBUS supply
regulators, these Kconfig symbols are unused. Remove them.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

phy: sun4i-usb: Control supplies via the regulator uclass

The device tree binding for the PHY provides VBUS supplies as regulator
references. Now that all boards have the appropriate regulator uclass
drivers enabled, the PHY driver can switch to using them. This replaces
direct GPIO usage, which in some cases needed a special DM-incompatible
"virtual" GPIO from the PMIC.

The following boards provided a value for CONFIG_USB0_VBUS_PIN, but are
missing the "usb0_vbus-supply" property in their device tree. None of
them have the MUSB controller enabled in host or OTG mode, so they
should see no impact:
 - Ainol_AW1_defconfig / sun7i-a20-ainol-aw1
 - Ampe_A76_defconfig / sun5i-a13-ampe-a76
 - CHIP_pro_defconfig / sun5i-gr8-chip-pro
 - Cubieboard4_defconfig / sun9i-a80-cubieboard4
 - Merrii_A80_Optimus_defconfig / sun9i-a80-optimus
 - Sunchip_CX-A99_defconfig / sun9i-a80-cx-a99
 - Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078
 - Yones_Toptech_BS1078_V2_defconfig /
   sun6i-a31s-yones-toptech-bs1078-v2
 - iNet_3F_defconfig / sun4i-a10-inet-3f
 - iNet_3W_defconfig / sun4i-a10-inet-3w
 - iNet_86VS_defconfig / sun5i-a13-inet-86vs
 - iNet_D978_rev2_defconfig / sun8i-a33-inet-d978-rev2
 - icnova-a20-swac_defconfig / sun7i-a20-icnova-swac
 - sun8i_a23_evb_defconfig / sun8i-a23-evb

Similarly, the following boards set CONFIG_USB1_VBUS_PIN, but do not
have "usb1_vbus-supply" in their device tree. Neither of them have USB
enabled at all, so again there should be no impact:
 - Cubieboard4_defconfig / sun9i-a80-cubieboard4 (also for USB3)
 - sun8i_a23_evb_defconfig / sun8i-a23-evb

The following boards use a different pin for USB1 VBUS between their
defconfig and their device tree. Depending on which is correct, they
may be broken:
 - Linksprite_pcDuino3_Nano_defconfig (PH11) /
   sun7i-a20-pcduino3-nano (PD2)
 - icnova-a20-swac_defconfig (PG10) / sun7i-a20-icnova-swac (PH6)

Finally, this board has conflicting pins given for its USB2 VBUS:
 - Lamobo_R1_defconfig (PH3) / sun7i-a20-lamobo-r1 (PH12)

Signed-off-by: Samuel Holland <samuel@sholland.org>
[Andre: use regulator_set_enable_if_allowed()]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: Enable PMIC drivevbus regulator support for USB supplies

On many boards, the USB ports are powered by the PMIC's "drivevbus"
regulator. In preparation for switching the USB PHY driver to use the
regulator uclass instead of a virtual GPIO pin, ensure these boards
have AXP PMIC regulator support enabled.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

power: regulator: Add a driver for the AXP PMIC drivevbus

AXP PMICs have a pin which can either report the USB VBUS state, or
driving a regulator that supplies USB VBUS. Add a regulator driver for
controlling this pin. The selection between input and output is done via
the x-powers,drive-vbus-en pin on the PMIC (parent) node.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: enable MMU_PGPROT proper page table protection

Select the new MMU_PGPROT Kconfig symbol for all Allwinner board builds,
to use a write-protected .rodata, non-executable .data and .rodata
sections, and non-writable .text sections.

This might trigger runtime exceptions in misbehaving drivers, which
should then be fixed.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: h616: defconfigs: enable eMMC

Now that eMMC is working properly on H616 devices, it became apparent
that some boards were missing the right defconfig bits to enable eMMC
access.

Add the eMMC device number to the Tanix TX1 and the X96 Mate defconfig,
also the eMMC boot option to the TX1. Oddly enough the X96 Mate had
just this bit already.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

sunxi: h6/h616: Reuse common DRAM infrastructure

H616 rank and size detection code is superior to the H6. Nevertheless,
they are structurally the same. Split functions from H616 into new file
and reuse them in H6 DRAM driver too. This should also fix some bugs for
H6 too, like incorrect DRAM size detection.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
[Andre: back out panic if test fails to allow 2^11 columns]
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

sunxi: h6: dram: split dram_para struct

This change is same as in commit 78aa00c38e86 ("sunxi: H616: dram: split
struct dram_para"), but for H6. This is needed in order to extract
common code between H6 and H616 later.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>

sunxi: H6: DRAM: Constify function parameters

Constify parameters for two reasons:
- Allow more compile time optimizations
- It will allow later sharing of common code with H616 (when it will be
  rearranged some more)

Commit does same kind of changes as commit 457e2cd665bd ("sunxi: H616:
dram: const-ify DRAM function parameters")

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>

env: point fdt address to the fdt in a bloblist

Point fdt_addr to the fdt embedded in the bloblist since fdt_addr
is a default address for bootefi, bootm and booti to look for the
device tree when launching the kernel.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>

bloblist: fix the overriding of fdt from bloblist

When a bloblist is valid and contains fdt, it explicitly means
a previous boot stage is passing transfer list compliant with
Firmware Handoff specification, thus the fdt from bloblist should
not be overridden with the ones from board or env variables.

Fixes: 70fe23859437 ("fdt: Allow the devicetree to come from a bloblist")
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge tag 'u-boot-stm32-20250428' of https://source.denx.de/u-boot/custodians/u-boot-stm

CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/25970
- Add OF_UPSTREAM flag support for STi, STM32 MCU and MPU platforms.
- Add ETZPC as system bus for STM32MP1 platforms
- Add RIFSC as sytem bus for STM32MP2 platforms
- Update STM32MP2 board/machine support:
  - update cmd_stm32key.
  - update cmd_stm32prog.
  - update STM32MP25 configs.
  - add leds and buttons support.
  - add boot_mode support (USB/PXE/MMC/NOR/NAND).
  - add bootcmd support.
  - enable MMC support.

siemens: imx8qxp: remove unused config file

include/configs/giedi.h is not longer used after siemens imx8qxp
cleanup series, so remove it.

Signed-off-by: Heiko Schocher <hs@denx.de>

arm: imx8qxp: capricorn: move env offset settings

move the ENV_OFFSET settings from common config settings file
configs/imx8qxp_capricorn.config to defconfig file for the
cxg3 board, as other imx8qxp based boards from siemens has
the environment on other offsets.

Signed-off-by: Heiko Schocher <hs@denx.de>

siemens: capricorn: defconfig updates

add ahab command as secure boot is used on this boards,
and enable watchdog, so U-Boot triggers it.

Signed-off-by: Walter Schweizer <walter.schweizer@siemens.com>
for respelling commit subject and  message:
Signed-off-by: Heiko Schocher <hs@denx.de>

siemens: capricorn: enable text based default environment

enable text based default U-Boot Environment by enabling
CONFIG_ENV_SOURCE_FILE

and adding default environment file:

board/siemens/capricorn/capricorn_cxg3.env

Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Walter Schweizer <walter.schweizer@siemens.com>