Ilias Apalodimas [Wed, 17 Jun 2026 07:48:23 +0000 (10:48 +0300)]
common: Add an option to relocate on ram top
Right now we only relocate u-boot to the top of the first
memory bank unless the board specific code overwrites it.
This is problematic when loading big binaries as it
fragments the contiguous memory space for no apparent reason.
On certain platforms, it is currently not possible to relocate U-Boot
above the 32bit boundary, due to various dependencies on content located
below the 32bit boundary. One such example is ethernet, where the packet
buffer built into U-Boot binary is placed below the 32bit boundary and
allows loading of data via ethernet even above 32bit boundary due to
memory copy from the packet buffer to the destination location.
A previous patch moves the bi_dram[] info from bd to gd and make
the memory bank information available early. So move the
dram_init_banksize() INITCALL before the relocation address calculation
and use it to derive the address.
Also add a Kconfig option and allow the common code to relocate U-Boot
to the top of the last discovered bank.
It's worth noting that this patch changes when dram_init_banksize()
is called. It's now called much earlier in the board init process.
That is a significant ordering change for every board with a custom
dram_init_banksize(), and it is unconditional (not gated on RELOC_ADDR_TOP).
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> # Radxa ROCK 5B Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Ilias Apalodimas [Wed, 17 Jun 2026 07:48:22 +0000 (10:48 +0300)]
rpi: Add a local get_effective_memsize()
We are about to change the place we call dram_init_banksize().
The goal is to have all the information we need to pick a proper
relocation address in gd->dram[].
However, the RPI boards, and specifically the tested rpi4, seems
to hang if we relocate anywhere above the address returned from
bcm2835_mbox_call_prop().
So store that address and return it on get_effective_memsize()
which is used to calculate ram_top.
Ilias Apalodimas [Wed, 17 Jun 2026 07:48:20 +0000 (10:48 +0300)]
common: move ram_base calculation to independent INITCALL()
Currently, ram_base is calculated within setup_dest_addr().
However, upcoming patches that enable U-Boot relocation to the highest
DRAM bank require ram_base to be initialized earlier.
The default dram_init_banksize() definition relies on ram_base
to calculate the start of the first bank. But following patches
will move that function to execute immediately before setup_dest_addr().
So let's split the ram_base initialization in its own INITCALL.
Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Anshul Dalal <anshuld@ti.com> Tested-by: Michal Simek <michal.simek@amd.com> # Versal Gen 2 Vek385 Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Ilias Apalodimas [Wed, 17 Jun 2026 07:48:19 +0000 (10:48 +0300)]
treewide: move bi_dram[] from bd to gd
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Kuan-Wei Chiu [Mon, 8 Jun 2026 15:47:49 +0000 (15:47 +0000)]
rtc: goldfish: Return error when device address is invalid
goldfish_rtc_of_to_plat() currently returns success even when
dev_read_addr() fails to find a valid address. This leaves plat->reg
unset (or 0) and defers the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs. This
aligns the driver with the recent fix introduced in the goldfish
serial driver by Naveen Kumar Chaudhary. [1]
Kuan-Wei Chiu [Mon, 8 Jun 2026 15:47:48 +0000 (15:47 +0000)]
timer: goldfish: Return error when device address is invalid
goldfish_timer_of_to_plat() currently returns success even when
dev_read_addr() fails to find a valid address. This leaves plat->reg
unset and defers the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs. This
aligns the driver with the recent fix introduced in the goldfish
serial driver by Naveen Kumar Chaudhary. [1]
serial: goldfish: return error when device address is invalid
goldfish_serial_of_to_plat() returns success even when dev_read_addr()
fails to find a valid address. This leaves plat->reg unset and defers
the failure to probe().
Return -EINVAL immediately when the address is FDT_ADDR_T_NONE so the
failure is reported at the of_to_plat stage where it belongs.
serial: cortina: check RX FIFO status before reading data
ca_serial_getc() reads from the URX_DATA register unconditionally
without first checking whether the RX FIFO contains valid data. When
the FIFO is empty, this returns whatever stale value is in the
register, which the DM serial framework interprets as a valid
character.
The DM serial framework expects getc() to return -EAGAIN when no data
is available, so it can handle retries and call schedule() to service
the watchdog between attempts.
Add a check of the UINFO register's UINFO_RX_FIFO_EMPTY bit before
reading URX_DATA, returning -EAGAIN when no data is pending. This
is consistent with how ca_serial_putc() already checks
UINFO_TX_FIFO_FULL before writing.
Alexander Stein [Fri, 5 Jun 2026 13:44:46 +0000 (15:44 +0200)]
global_data: fix type for gd_malloc_ptr()
With commit 92aa3ec321b5 ("global_data: Reduce size of early-malloc vars")
the type changes from (unsigned) long to int. But the type for default
if SYS_MALLOC_F_LEN is unset was not changed. Remove the suffix.
Fixes the warning:
common/spl/spl.c:800:23: warning: format '%x' expects argument of type
'unsigned int', but argument 2 has type 'long int' [-Wformat=]
Fixes: 92aa3ec321b5 ("global_data: Reduce size of early-malloc vars") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* bootdev: fix typos
* board: renesas: Document Renesas RZ/N1D and RZ/N1S as arm
* board: renesas: Document Renesas Geist board support
* board: renesas: Document Renesas Gray Hawk board support
* board: renesas: Document Renesas Ironhide board support
* android: fastboot: Document halt behaviour
UEFI:
* fix memory leak in efi_var_collect()
* set revision field in block IO protocol
* fix guid comparison in efi_selftest_loaded_image.c
* fix use-after-free in efi_selftest_memory.c
Vincent Stehlé [Thu, 11 Jun 2026 06:59:50 +0000 (08:59 +0200)]
efi_selftest: fix use-after-free
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed57 ("efi_selftest: check fdt is marked as runtime data") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Vincent Stehlé [Tue, 9 Jun 2026 08:07:04 +0000 (10:07 +0200)]
lib/efi_loader: fix block io revision
The Revision field of the EFI_BLOCK_IO_PROTOCOL structure must be set to
one of the two valid values [1], but this is not initialized in the
efi_loader; fix it.
Link: https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#efi-block-io-protocol Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Vincent Stehlé [Mon, 15 Jun 2026 10:56:15 +0000 (12:56 +0200)]
efi_selftest: fix guid comparison
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0de0 ("efi_selftest: test for loaded image protocol") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Cc: Alexander Graf <agraf@csgraf.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Peng Fan [Thu, 18 Jun 2026 06:48:48 +0000 (14:48 +0800)]
usb: tcpm: fix inverted poll condition in tcpm_pd_transmit()
The read_poll_timeout() macro breaks out of its loop when the condition
evaluates to true. The current code uses "!tx_complete" as the
condition, which means it exits immediately when tx_complete is false
(i.e., transmission has NOT completed yet), rather than waiting for
completion.
Fix the condition to "tx_complete" so that the poll loop waits until
the TCPC signals transmission success/failure/discard before
proceeding.
Without this fix, tcpm_pd_transmit() returns before the TCPC has
finished transmitting, causing the PD state machine to proceed with
stale tx_status values.
Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Wed, 17 Jun 2026 20:25:13 +0000 (14:25 -0600)]
Merge patch series "Fixes, cleanup and a test for the SPL FIT "full" loader"
Francesco Valla <francesco@valla.it> says:
This patch set contains a collection of small fixes and cleanups for the
"full" FIT loader that can be used for the SPL. The main beneficiary is
the falcon boot flow, but the same loader can be used also for U-Boot
proper.
Patch 1 was part of another set, but I decided to put it here for a
better separation between plumbing (here) and new features (there). I
kept the Reviewed-by tag collected from Simon in that occasion.
Patch 6 introduces a new unit test covering most of the code that is
being cleaned up.
The set was tested on a i.MX93 FRDM, both with and without signature and
to boot both U-Boot proper and the Linux kernel directly (i.e., falcon
boot).
Francesco Valla [Thu, 4 Jun 2026 20:41:39 +0000 (22:41 +0200)]
spl: fit: use CONFIG_IS_ENABLED whenever possible
Replace #ifdef directives with the CONFIG_IS_ENABLED() for better
coverage and cleaner code. In the mean time, convert the last
IS_ENABLED() to CONFIG_IS_ENABLED().
Signed-off-by: Francesco Valla <francesco@valla.it>
Francesco Valla [Thu, 4 Jun 2026 20:41:38 +0000 (22:41 +0200)]
spl: fit: drop the 'standalone' load attempt
The 'standalone =' config property has been deprecated for ~5 years [1],
with the loud warn about the deprecation lasting much more than the
foreseen couple of releases.
Remove the attempt to load the primary image through this property to
save some boot time and code complexity.
Francesco Valla [Thu, 4 Jun 2026 20:41:37 +0000 (22:41 +0200)]
spl: fit: rework the FDT load hack
U-Boot proper expects its FDT to be right after its binary image; the
"full" FIT image loader thus adopts an hack to relocate it, ignoring
the specified load address.
Rework the current form of the hack to:
- support the 'sandbox' environment with a sysmem-aware memcpy;
- use the ALIGN() macro instead of raw alignment logic;
- align the FDT to 8-byte boundary as per FDT specifications;
- fix the debug print (which was reporting the source address for the
relocation instead of the destination one).
Signed-off-by: Francesco Valla <francesco@valla.it>
Francesco Valla [Thu, 4 Jun 2026 20:41:36 +0000 (22:41 +0200)]
spl: fit: fix loadables load under sandbox
Align the fit_image_load() call done for the loadables to the ones for
other artifatcs (firmware, kernel, fdt), calling virt_to_phys() on the
pointer that contains the FIT location.
This is needed to support the 'sandbox' environment.
Signed-off-by: Francesco Valla <francesco@valla.it>
Francesco Valla [Thu, 4 Jun 2026 20:41:35 +0000 (22:41 +0200)]
boot: fit: fix FIT verification in SPL
Align the behavior of fit_image_verify() called in SPL to the one in
full U-Boot. In particular, this function is called when both
CONFIG_SPL_LOAD_FIT_FULL and CONFIG_SPL_FIT_SIGNATURE are set (which can
happen e.g. in case of secure falcon boot).
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Francesco Valla <francesco@valla.it>
Tom Rini [Wed, 17 Jun 2026 20:13:00 +0000 (14:13 -0600)]
Merge patch series "dtc: Resync fdt_check_full function"
Tom Rini <trini@konsulko.com> says:
As part of the resync to dtc version v1.7.2-35-g52f07dcca47c from the
Linux Kernel, we missed updating the fdt_check_full function because it
exists in its own file in upstream dtc and the kernel doesn't import it,
as reported by Anton Ivanov. This short series brings in the upstream
fdt_check.c file and then implements our size-saving option, but in the
modern way.
Tom Rini [Tue, 26 May 2026 20:19:28 +0000 (14:19 -0600)]
dtc: libfdt: Introduce a can_assume check in fdt_check_full
The current upstream method of having a function omit various tests is
to use the can_assume macro. Take the logic we had previously been using
and instead make it a can_assume(PERFECT) check within fdt_check_full
itself.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
In the upstream project, the function fdt_check_full has been moved from
fdt_ro.c to its own file, fdt_check.c. This file is not included in the
Linux kernel copy and so has not been synced over. As we do need and use
the fdt_check_full function, bring that file over as of the current
upstream we are synced to. Remove our copy of this function from
fdt_ro.c and add fdt_check.o and 1-liner fdt_check.c where needed. Note
that for now, this will increase size in some cases as upstream does not
have a size reduction method here.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 17 Jun 2026 15:55:31 +0000 (09:55 -0600)]
Merge patch series "armv8: mmu: fix region unmapping and optimise set_one_region()"
Casey Connolly <casey.connolly@linaro.org> says:
Currently trying to unmap a region results in slow and largely broken
behaviour as we unnecessarily split blocks and manually set thousands of
individual 4k pages instead of higher level blocks.
This series fixes the behaviour of set_one_region() so that it works
properly when called to unmap regions. See patch 4 for details.
Patches 1 & 2 improve the existing debug functionality, the pagetable
dumper will now print most explicitly unmapped regions (since they still
have their PA intact), as well as adding a new function which does a
very basic software TLB lookup to help with debugging.
Patch 3 de-duplicates some code by moving the loop that always surrounds
set_one_region() calls into its own function, this also helps with
readability in the calling functions.
Casey Connolly [Mon, 8 Jun 2026 17:13:51 +0000 (19:13 +0200)]
armv8: mmu: fix and optimise explicitly unmapping regions
As more platforms start ensuring they explicitly unmap reserved-memory
regions a few issues have appeared with how the existing dynamic mapping
code works. Fix these and get a small optimisation as well.
1. Teach pte_type() to actually respect the PTE_TYPE_VALID bit
2. Don't walk the TLB a second time if we call mmu_change_region_attr()
with PTE_TYPE_FAULT (since it would just be a slow nop)
3. Fix how set_one_region() decides to split blocks.
Today set_one_region() will always split blocks until it reaches the
smallest granule size (4k) and then update all of these pages. This
appears to be due to a big in how is_aligned() is implemented, since
it only evaluates to true if addr and size are both multiples of the
current granule size, so a mapping aligned to 2M which is 4M in size
will cleanly result in 2 blocks being set, but a mapping aligned to
2M which is 4M + 8k in size will result in blocks being split and 1026
individual pages being set.
While for the address it is correct to enforce that it is aligned to
the current granule size, we only need to check if the region size is
greater than the current granule size. This allows us to simplify our
second example above to only 4 entries being updated (assuming no blocks
have to be split) since we only need to update 2 blocks to map the first
4M, drastically improving the best-case performance.
In the case where the address is 4k aligned rather than 2M aligned we
will still be restricted to mapping 4k pages until we reach 2M alignment
where we could then map a larger 2M granule which previously would never
happen.
Casey Connolly [Mon, 8 Jun 2026 17:13:49 +0000 (19:13 +0200)]
armv8: mmu: teach the pagetable dumper to show explicit FAULT maps
When a region is explicitly unmapped (like with
mmu_change_region_attr(.... PTE_TYPE_FAULT)) the address translation
still remains but won't be used since the region is marked invalid.
Print these regions when we dump the pagetable to help with debugging.
Casey Connolly [Mon, 8 Jun 2026 17:13:48 +0000 (19:13 +0200)]
armv8: mmu: add a function to help debug TLB lookups
Implement a super basic software TLB walk which can look up a single
address in the TLB and print each stage of the translation. This is
helpful for debugging TLB issues and will be compiled out if unused.
Tom Rini [Wed, 17 Jun 2026 15:54:27 +0000 (09:54 -0600)]
Merge patch series "bootm: bound noload kernel decompression to the allocated buffer"
Aristo Chen <aristo.chen@canonical.com> says:
For a compressed kernel_noload image, bootm_load_os() allocates a
decompression buffer of ALIGN(image_len * 4, SZ_1M) and then passes
CONFIG_SYS_BOOTM_LEN (typically 128 MiB on arm64) to image_decomp() as
the output limit. The decompressors honour whatever limit they are
given, so a kernel that decompresses to more than four times its
compressed size runs past the end of the allocated buffer and silently
corrupts adjacent memory.
A 4x compression ratio is at the edge of what modern compressors
(zstd, xz) achieve on real kernels, and is trivially exceeded by
crafted, highly compressible payloads, so this is reachable both
accidentally and intentionally. The overflow can land on already-loaded
boot artefacts (FDT, ramdisk, loadables), U-Boot's own data, or
memory-mapped device registers; the existing post-decompression overlap
check in bootm_load_os() only catches overlap with the FIT itself.
Patch 1 plumbs the actual allocation size through to image_decomp() and
handle_decomp_error() via a single decomp_len variable, so
decompression stops at the buffer boundary and fails cleanly when the
image is too large. The non-noload code path is unchanged and continues
to use CONFIG_SYS_BOOTM_LEN. A clarifying note is printed when the
failure is gated by the per-image buffer, so the generic
"increase CONFIG_SYS_BOOTM_LEN" advice does not mislead.
Patch 2 raises the noload-decompression headroom from 4x to 8x. The 4x
factor is at the edge of what zstd and xz achieve on real kernels, so
well-compressed vendor kernels can fail to boot at runtime once the
bound is enforced. 8x covers them comfortably while remaining bounded.
Patch 3 adds two sandbox py-tests against the per-image buffer at the
final 8x value: one that exceeds the buffer and must be rejected, and
one that matches the buffer exactly and must succeed (guarding the
boundary).
Tested on sandbox: both new tests pass; the existing
test_fit_compressed_images_load (which covers the load-address path)
and the other tests in test/py/tests/test_fit.py continue to pass.
Aristo Chen [Fri, 5 Jun 2026 15:42:51 +0000 (15:42 +0000)]
test/py: test kernel_noload decompression buffer overflow
Add sandbox tests that exercise the per-image decompression buffer that
bootm_load_os() allocates for a compressed kernel_noload image
(ALIGN(image_len * 8, SZ_1M)).
The overflow test builds a FIT whose decompressed size far exceeds the
per-image buffer and asserts that 'bootm loados' rejects it with a
decompression error rather than overflowing.
The boundary test builds a FIT whose decompressed size equals the
per-image buffer exactly and asserts that 'bootm loados' succeeds,
guarding against an off-by-one rejection at the buffer limit.
Aristo Chen [Fri, 5 Jun 2026 15:42:50 +0000 (15:42 +0000)]
bootm: increase kernel_noload decompression headroom from 4x to 8x
For a compressed kernel_noload image, bootm_load_os() allocates a buffer
of ALIGN(image_len * 4, SZ_1M). The 4x factor is at the edge of what
modern compressors (zstd, xz) achieve on real kernels, so a
well-compressed vendor kernel can fail to boot at runtime with no
intervening warning.
Bump the headroom to 8x. The buffer is still bounded by the compressed
image size, and the SZ_1M alignment keeps the overhead below 1 MiB on
small kernels.
Suggested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Aristo Chen [Fri, 5 Jun 2026 15:42:49 +0000 (15:42 +0000)]
bootm: fix overflow of the noload kernel decompression buffer
For a compressed kernel_noload image, bootm_load_os() allocates a
decompression buffer sized to ALIGN(image_len * 4, SZ_1M), assuming the
kernel compresses by no more than a factor of four. It then passes
CONFIG_SYS_BOOTM_LEN, rather than the size of that buffer, to
image_decomp() as the output limit. The decompressors honour the limit
they are given, so a kernel that decompresses to more than four times
its compressed size is written past the end of the allocated buffer and
corrupts adjacent memory.
Pass the allocation size to image_decomp() and handle_decomp_error() so
decompression stops at the buffer boundary and fails cleanly when the
image is too large, instead of overflowing. The regular non-noload
paths are unchanged and continue to use CONFIG_SYS_BOOTM_LEN. When the
failure is triggered by the smaller per-image buffer, print a note so
that handle_decomp_error()'s generic advice to increase
CONFIG_SYS_BOOTM_LEN does not mislead the reader.
Fixes: 69544c4fd8b1 ("bootm: Support kernel_noload with compression") Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
This series aims to add back the omap4 support. This support was removed
by commit b0ee3fe642c ("arm: ti: Remove omap4 platform support") because
at that moment, none of the OMAP4-based boards had done the migration to
DM_I2C.
My use case is an old product based on the Variscite's omap4 system on
module. I needed to upgrade U-Boot on it for security reasons. I think
that this work could benefit to other people who may have same kind of
product to maintain.
Patch 1 to 3 remove the omap's clock driver dependency to the AM33xx
as it is also present in omap4 platforms. I tested these changes on the
beaglebone black to ensure I didn't break the AM33xx case.
Patch 4 & 5 revert the deletion of the omap4 support. The revert makes
checkpatch.pl angry. I fixed quite a lots of warnings already but it
remains two kinds of warnings:
- CamelCase on timings structure, I left the CamelCase because IMHO it's
more readable this way.
- #ifdef CONFIG_XYZ shouldn't be used anymore. I left one of this because
I didn't find a clean way to get rid of it.
Patch 6 adds support for the Variscite's system on module. This system on
module is supported by the Linux project through
ti/omap/omap4-var-som-om44.dtsi
board: variscite: add support for the omap4_var_som
OMAP4 support is present but there isn't any board using it.
Add minimal support for the Variscite OMAP4-SoM (debug console + boot
from SD card).
Use the ti/omap/omap4-var-stk-om44 device-tree from the Linux kernel. The
real representation of the SoM's hardware is located in
ti/omap/omap4-var-som-om44.dtsi included in it.
omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform
support") because the supported boards hadn't done the conversion to
CONFIG_DM_I2C in time. It still exists some omap4-based products and
they could benefit from the latest U-Boot support for obvious security
reasons.
Revert part of b0ee3fe642c to introduce back a minimal support for the
omap4 platform.
Fix the checkpatch's warning/errors induced by this revert. Following
warnings are still present:
| arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
| arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible
| arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: <tRPab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: <tRCD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: <tWR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: <tRASmin>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: <tRRD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: <tWTRx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: <tXSR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: <tXPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: <tRFCab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: <tRTPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: <tCKE>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: <tCKESR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: <tZQCS>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: <tZQCL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: <tZQINIT>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: <tDQSCKMAXx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: <tRASmax>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: <tFAW>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: <tRL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: <tRP_AB>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: <tRAS_MIN>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: <tWTR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: <tXP>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: <tRTP>
I didn't find an clean way to fix the "don't use #ifdef" warning as we
need to define the gpio_bank for the SPL build only.
For the CamelCase warnings, the incriminated attributes represent
timings, so IMHO, it is more readable with CamelCase.
This include file isn't used since the omap4 support has been dropped.
Since this support is about to be reintroduced, this file is going to be
used again. The upcoming support is minimal and doesn't include network,
therefore leaving PXE and DHCP in the BOOT_TARGET_DEVICES list would lead
to build errors.
Remove PXE and DHCP from the list of BOOT_TARGET_DEVICES.
Remove the LEGACY_MMC macros and the findfdt script that looks for
no-longer supported boards.
Remove the empty #ifdef XPL_BUILD
The clock controller driven by this driver exists on other OMAP platforms
than the AM33xx. Yet, it uses functions provided by
arch/arm/mach-omap2/am33xx/clock.c making it unusable by other OMAPs.
Replace am33xx-specific do_{enable/disable}_clocks() with new static
functions implemented locally.
Replace the am33xx-specific clock header with the one shared by all OMAP
platforms.
Lots of clock definitions are common to OMAP3, OMAP4 and OMAP5. So the
same macros are defined both in arch-am33xx/clock.h and in
arch-omap5/clock.h. Upcoming support for OMAP4 will again need the same
macros.
Group these common macro definitions into a common omap_clock header
shared across the OMAP2+ families.
Tom Rini [Tue, 16 Jun 2026 23:01:20 +0000 (17:01 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh
This is a DRAM controller driver for the R-Car X5H and its enablement.
This makes the U-Boot on RSIP usable beyond U-Boot shell running on
Cortex-M33, as the U-Boot on RSIP can now load not only SCP firmware
into the SCP core STCM, but also TFA BL31, OPTEE-OS and U-Boot into DRAM
and start them on the Cortex-A720AE core. This is self-contained and
affects only the R-Car X5H and a bit of R-Car V4H, besides it went
through rounds of testing until now, therefore it is safe to include it
this late in the release cycle. I know this will make rc5 massive, sorry
about that.
Rasmus Villemoes [Thu, 11 Jun 2026 14:08:57 +0000 (16:08 +0200)]
Makefile: let 'make clean' remove files created by DEVICE_TREE_DEBUG
Originally, 'make DEVICE_TREE_DEBUG=1' only generated extra output on
the console. But since 6cdd7597a2f ("kbuild: Produce diff between base
DT and U-Boot augmented DT if DEVICE_TREE_DEBUG=1"), that has also
left behind lots of files that clutter the repo and are hard to get
rid of manually.
Make sure that a 'make clean' will remove those files, and add them to
.gitignore.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Wed, 10 Jun 2026 18:20:59 +0000 (20:20 +0200)]
arm: dts: renesas: Enable DBSC5 on R-Car R8A78000 X5H Cortex-M33 RSIP port
Bind the DBSC5 DRAM controller driver on boot in board_early_init_r(),
which brings up the DBSC5 DRAM controller and its PHY and which enables
access to DRAM present on this system.
Add default boot command which loads additional bootloader components
from HF and UFS storage into SRAM and DRAM, and starts those components
on SCP and AP core 0. The system is then capable of reaching U-Boot on
the AP core 0. Specifically, the following components are loaded:
- SCP firmware, 384 kiB from HF offset 0x4c0000 to SCP STCM
- TFA BL31, 256 kiB from UFS0 offset 0x5000 * 4 kiB sectors to DRAM 0x8c200000
- TEE, 2 MiB from UFS0 offset 0x5200 * 4 kiB sectors to DRAM 0x8c400000
- U-Boot, 1 MiB from UFS0 offset 0x7200 * 4 kiB sectors to DRAM 0x8c300000
- IPL parameters table is generated at DRAM address 0x8c100000
Enable pstore command support to allow dumping kernel console from
pstore/ramoops, which is convenient for debugging. Use as follows:
=> pstore set 0x80000000 0x10000 0x400 0x8000 0 0 0
=> pstore display console
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add Renesas R-Car Gen5 DBSC5 DRAM controller driver. This driver is currently
capable of bringing LPDDR5X DRAM on Renesas R-Car X5H Ironhide board. Further
boards can be supported by supplying board specific DRAM configuration data
via dbsc5_get_board_data().
The driver reuses parts of previous DBSC5 driver, but due to hardware changes,
can not be fully integrated into existing DBSC and DRAM driver, therefore the
currentl DBSC and DRAM drivers are moved into R8A779G0 V4H specific files, and
the R8A78000 X5H files are added in parallel.
The Gen5 DBSC driver is meant to be used in RSIP context, while the Gen4 DBSC
driver is meant to be used in SPL, therefore the Kconfig conditionals have been
adjusted to match.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Wed, 10 Jun 2026 18:20:57 +0000 (20:20 +0200)]
ram: renesas: rtvram: Add support for Renesas R-Car Gen5
Add support for Renesas R-Car Gen5 R8A78000 SoC into RT-VRAM
initialization driver. The changes are only a slight adjustment
to the register programming, therefore reuse the existing RT-VRAM
driver and parametrize those changes using driver data.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Heiko Stuebner [Sat, 13 Jun 2026 17:24:44 +0000 (19:24 +0200)]
lmb: Add the Rockchip architecture as requiring DMA below 4G
Loading EFI parts like a Debian-Installer on Rockchip SoCs creates
interesting results, in that on some boards the Grub bootloader can't
find any partitions on a USB-Stick, or loading a kernel from Grub spews
EHCI fail timeout STS_IAA set
messages before failing and on others the loading something like efivars
from an eMMC creates read errors and making the MMC vanish from U-Boot.
This only affected boards with at least 4GB of RAM.
These boards have at least 256MB of memory placed above the actual 4GB
address space (due to the iomem being in between) and while kernel,
initramfs, dt are generally loaded to predefined addresses, additional
EFI parts (efivars, etc) are likely just loaded "somewhere" and it seems
this always landed in that higher up memory part.
Also in the Linux-kernel peripherals like EMMC, USB, etc already run
with a 32bit dma-mask set.
So far, I've seen this on RK3568 and RK3588, but as the same peripherals
are used on most Rockchip SoCs, it makes sense to limit this on all.
So add ARCH_ROCKCHIP to the default-y list of LMB_LIMIT_DMA_BELOW_RAM_TOP.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Tom Rini [Mon, 15 Jun 2026 18:50:04 +0000 (12:50 -0600)]
Merge patch series "Repair boards broken by the 6.1 kbuild bump"
Simon Glass <sjg@chromium.org> says:
Commit bd3f9ee679b4 added FORCE to several if_changed rules whose
recipes expand $^, so FORCE leaks in as a stray argument and the
command fails. Use $< to restore the Edison and i.MX23/28 images.
Simon Glass [Sat, 13 Jun 2026 13:05:13 +0000 (07:05 -0600)]
arm: mxs: Avoid passing FORCE to commands
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE
as a prerequisite to the if_changed rules here, but the commands use $^
so FORCE leaks in as a stray operand. The dd in cmd_mkalign_mxs fails
(silently, since its stderr is discarded) and the binary is never
aligned, stat in cmd_mkivt_mxs emits an error and cst receives a bogus
argument.
Use $< and $(real-prereqs) instead, which exclude FORCE.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sat, 13 Jun 2026 13:05:12 +0000 (07:05 -0600)]
x86: edison: Avoid passing FORCE to the align command
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE
as a prerequisite to the u-boot-align.bin rule, but cmd_mkalign_eds
expands $^, so FORCE leaks in as a stray operand. The dd then fails
(silently, since its stderr is discarded) and the following mv never
runs, so u-boot.bin never gains its 4096-byte zero prefix. The mask ROM
enters U-Boot 0x1000 (4KB) into the image and the board never starts,
sitting in BootROM download mode (DnX).
Use $< instead of $^, which excludes FORCE and restores the prefix.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tom Rini [Mon, 15 Jun 2026 17:04:48 +0000 (11:04 -0600)]
Merge patch series "various memory related fixups"
rs@ti.com <rs@ti.com> says:
From: Randolph Sapp <rs@ti.com>
Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support
[1]. This does a lot of general setup required for the device, but these
modifications themselves aren't device specific. For those specifically
interested in PocketBeagle2 support and don't care about these details, my
development branch is public [2].
That first patch may provoke some opinions, but honestly if that warning was
still present I wouldn't have spent a week poking holes in both the EFI and LMB
allocations systems. Please let me know if there is a specific usecase that it
breaks though.
Randolph Sapp [Thu, 4 Jun 2026 15:50:38 +0000 (10:50 -0500)]
memory: reserve from start_addr_sp to initial_relocaddr
Add a new global data struct member called initial_relocaddr. This
stores the original value of relocaddr, directly from setup_dest_addr.
This is specifically to avoid any adjustments made by other init
functions.
Reserve the memory from gd->start_addr_sp - CONFIG_STACK_SIZE to
gd->initial_relocaddr instead of gd->ram_top. This allows platform
specific relocation addresses to work without unnecessarily painting
over a large range.
Randolph Sapp [Thu, 4 Jun 2026 15:50:37 +0000 (10:50 -0500)]
test: boot: add a fdt reserved region check
Add a image_fdt suite and a check for boot_fdt_add_mem_rsv_regions. This
will ensure the user is properly informed of any reservation failures.
It will also validate that reservations are cleaned up correctly when
switching FDTs.
Randolph Sapp [Thu, 4 Jun 2026 15:50:36 +0000 (10:50 -0500)]
test_ut: add a ut_ubman fixture to clean up tests
Add a ut_ubman fixture to clean up after certain problematic tests
without negatively affecting the current assert based testing.
Currently this catches "bootstd bootflow_cmd_boot" and "bootstd
bootflow_scan_boot" ut_subtests, as these will change the sandbox state
a little too much to be recoverable from.
Signed-off-by: Randolph Sapp <rs@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Randolph Sapp [Thu, 4 Jun 2026 15:50:35 +0000 (10:50 -0500)]
boot: image-fdt: free old dtb reservations
Add a free flag and an initial call to free allocations covered by the
global FDT. This assumes that all calls to boot_fdt_add_mem_rsv_regions
occur before the transition to the new device tree, thus we can access
the currently active device tree through the global data pointer.
This allows us to clearly indicate to the user when a device tree
reservation fails. How we handle this can still use some improvement.
Right now we'll keep the default behavior and try to boot anyway.
Fixes: 5a6aa7d5913 ("boot: fdt: Handle already reserved memory in boot_fdt_reserve_region()") Signed-off-by: Randolph Sapp <rs@ti.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Fixes: tag with a 12-char hash: Fixes: 5a6aa7d59133 ("boot: fdt: Handle already reserved memory in
The boot selection rules state that a slot is bootable if it is not
corrupted and either has tries remaining or has already booted
successfully. However, slots that have tries_remaining == 0 and
successful_boot == 1 will be disregarded when picking the slot to
attempt.
Updates the selection logic so slots marked successful remain eligible
even when their tries counter is zero. Debug message now also includes
the successful_boot value.
Francois Berder [Sun, 24 May 2026 19:25:47 +0000 (21:25 +0200)]
fastboot: Fix blk_dwrite error checking
blk_dwrite() returns the number of blocks written.
The code was only checking if the return value was different
than 0. Hence, partial writes were considered successful.
Fix blk_dwrite error handling by checking that all blocks
are written.
Marek Vasut [Sun, 14 Jun 2026 01:52:21 +0000 (03:52 +0200)]
arm64: renesas: Initialize GIC600 fully on R-Car S4/V4H/V4M
ARM GIC-600 IP complies with ARM GICv3 architecture, but among others,
implements a power control register in the Redistributor frame. This
register must be programmed to mark the frame as powered on, before
accessing other registers in the frame.
Before the switch to generic lowlevel_init function, this did not pose
a problem as the previous custom lowlevel_init did not access the GICR
registers. The generic function does and that does lead to a hang early
in SPL. Enable the GIC600 initialization variant to mitigate the hang.
Fixes: 37997a214ed1 ("arm: renesas: Use stock lowlevel_init function and remove s_init") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Sun, 14 Jun 2026 01:52:08 +0000 (03:52 +0200)]
arm64: renesas: Fold mach_cpu_init into board_init_f on R-Car S4/V4H/V4M SPL
The mach_cpu_init() function is not invoked in SPL. Instead of
having two functions, fold mach_cpu_init() into board_init_f(),
which is called very early in the boot process and assures that
the CPG and APMU setup will be invoked before DM is brought up.
Fixes: 37997a214ed1 ("arm: renesas: Use stock lowlevel_init function and remove s_init") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Anton Ivanov [Tue, 2 Jun 2026 18:27:52 +0000 (19:27 +0100)]
fdt: Check return value of fdt_get_name() calls
fdt_get_name() can return NULL and set len to a negative error code.
fdt_find_regions() does not check for this, leading to a potential NULL
pointer dereference and a buffer out-of-bounds write during signature
verification of an untrusted FIT. fdt_next_region(), fdt_check_full(),
and display_fdt_by_regions() also lack validation.
Add NULL checks and propagate the error code from fdt_get_name()
to the caller.
Signed-off-by: Anton Ivanov <anton@binarly.io> Reviewed-by: Simon Glass <sjg@chromium.org>
Marek Vasut [Thu, 11 Jun 2026 18:05:58 +0000 (20:05 +0200)]
arm: renesas: Make R-Car Gen5 u-boot-elf.shdr compatible with SDK flash_writer
The SDK 4.32 flash_writer tool, built from the SDK IPL source, requires
SREC S7 "Start address (termination)" record [1] at the end of the SREC
file that is sent to it during installation of content into storage,
otherwise the tool waits for the S7 record indefinitelly and the payload
does not get installed into storage.
Specifically, the tool considers SREC S3 and S7 records as mandatory,
S0, S5, S6 as ignored, and any other records as unsupported.
Configure srec_cat such that it explicitly generates the trailing S7
record, and also that it never generates the ignored S5 Count record.
This fixes installation of u-boot-elf.shdr using the flash_writer tool,
which can not finish successfully without the trailing S7 record.
Marek Vasut [Thu, 11 Jun 2026 18:04:26 +0000 (20:04 +0200)]
arm: renesas: Build u-boot-elf.shdr for R-Car X5H Cortex-M33 RSIP port
Currently, the default build target for all R-Car Gen3/4/5 is the
u-boot-elf.srec, which depends on u-boot.bin and other vital build
artifacts, which get built as prerequisites. The R-Car Gen5 RSIP
port benefits from u-boot-elf.shdr being built as well, because the
u-boot-elf.shdr contains header used by the BootROM to load and
start U-Boot on the RSIP core. Because u-boot-elf.shdr depends on
u-boot-elf.srec, switch the default build target for R-Car Gen5
RSIP port to u-boot-elf.shdr. This way, both u-boot-elf.shdr and
u-boot-elf.srec are built for R-Car Gen5 RSIP port.
Anton Ivanov [Thu, 4 Jun 2026 10:39:50 +0000 (11:39 +0100)]
image-fit: Validate external data offset and size
fit_image_get_data() uses the data-position, data-offset, and
data-size FIT properties without bounds checking. A crafted FIT
image can specify values that cause out-of-bounds read during
signature verification of an untrusted FIT.
Validate that the external data offset and size are non-negative,
and that the data region fits within the FIT image bounds.
Signed-off-by: Anton Ivanov <anton@binarly.io> Reviewed-by: Simon Glass <sjg@chromium.org>
Anton Ivanov [Tue, 2 Jun 2026 18:31:30 +0000 (19:31 +0100)]
image-fit: Limit recursion depth in fdt_check_no_at()
fdt_check_no_at() recurses into every subnode without a depth
limit. A deeply nested FIT image can exhaust the stack and crash
U-Boot during signature verification of an untrusted FIT.
Add a depth check using FDT_MAX_DEPTH to bound the recursion.
Anton Ivanov [Tue, 2 Jun 2026 18:30:17 +0000 (19:30 +0100)]
fdt_region: Check return value of fdt_get_property_by_offset() calls
fdt_get_property_by_offset() returns NULL for FDT with version
less than 0x10. fdt_find_regions() dereferences the result without
checking, leading to a NULL pointer dereference during signature
verification of an untrusted FIT. fdt_add_alias_regions() and
fdt_next_region() also lack validation.
Add NULL checks before accessing the returned property pointer.
Also add a missing NULL check for fdt_string() in
fdt_add_alias_regions() and fdt_next_region().
Anton Ivanov [Tue, 2 Jun 2026 18:29:25 +0000 (19:29 +0100)]
image-fit-sig: Validate hashed-strings region size
fit_config_check_sig() reads the hashed-strings property and uses
its size value without validation when building the region list for
signature verification. A crafted FIT image can specify an arbitrary
size, causing the hash calculation to read beyond the end of the FIT
image. The property length is also not checked, so a truncated
hashed-strings property causes strings[1] to be read past the end of
the property. This may result in the out-of-bounds read during signature
verification of an untrusted FIT.
Validate both the property length and that the declared strings region
fits within bounds before adding it to the region list.
- Patches 1-3: Fixes for am335x-evm to boot and support the LCD panel
with the current u-boot devicetree.
- Patches 4-17: Make upstream devicetree working with uboot. This
adds tick-timer, adds compatibility of the board code for different
USB probing, makes SPL smaller and updates the defconfig.
The series has been tested on am335x-evm. Note that I don't have all
other boards built with the am335x_*evm_*defconfig, so tests are
appreciated. buildman reports builds are working.
configs: am335x_evm_defconfig: Switch to upstream devicetree
The upstream devicetree uses simple-pm-bus, so CONFIG_POWER_DOMAIN is
required now. CONFIG_POWER_DOMAIN enables probing power domains, the PRM
power domain driver is requierd as well now.
CONFIG_PHANDLE_CHECK_SEQ is now needed as many device nodes are now
named for example mmc@0.
This switches all evm defconfig variants to use the upstream devicetree.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Support musb being probed by ti,musb-am33xx. The non-upstream DT probing
used a wrapper driver that probed ti-musb-peripheral and ti-musb-host.
This wrapper registered as UCLASS_MISC, which is why it is requested in
this board.c file.
With the new devicetree the wrapper that registers as UCLASS_MISC is
gone, instead the UCLASS_USB and UCLASS_USB_GADGET_GENERIC have to be
requested.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
Fix #else and #endif comments to match actual #if condition. Comments
incorrectly referenced CONFIG_USB_MUSB_* instead of CONFIG_AM335X_USB*
and CONFIG_XPL_BUILD.
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
Much of the config symbols between the evm boards are the same
independent of the actual board. This patch creates a hierarchy for the
am335x_evm configs:
Enable SPL inline optimization to shrink the size. After enabling
OF_UPSTREAM the size is otherwise too big. Enable it before enabling
OF_UPSTREAM to maintain bisect ability.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Enable LCD panel support on am335x-evm:
- CLK_CCF and CLK_TI_* for display clock tree
- DM_PWM and PWM_TI_ECAP for backlight control
- VIDEO and AM335X_LCD for display controller
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
projects / thirdparty / u-boot.git / log
