| Age | Commit message (Collapse) | Author |
|---|
|
Kuan-Wei Chiu <[email protected]> says:
Add support for the QEMU 'virt' machine on the m68k architecture. The
QEMU virt machine models a generic system utilizing Goldfish virtual
peripherals and is capable of emulating various classic 68k CPUs.
Currently, U-Boot's m68k architecture support focuses on ColdFire
variants. This series expands support to include the classic M680x0
architecture, implementing the necessary exception vectors, startup
code, and a bootinfo parser compatible with the QEMU interface.
Drivers for Goldfish peripherals (TTY, Timer, RTC) and the QEMU
Virtual System Controller (sysreset) are also added to enable serial
console, timekeeping, and system reset functionality.
The implementation has been verified on QEMU targeting the M68040 CPU,
confirming successful hardware initialization and boot to the U-Boot
command shell. Additionally, the CI configuration was verified locally
using gitlab-ci-local "qemu_m68k_virt test.py", resulting in
PASS qemu_m68k_virt test.py.
Link: https://lore.kernel.org/r/[email protected]
[trini: Re-sort MAINTAINERS entries]
Signed-off-by: Tom Rini <[email protected]>
|
|
Add support for the QEMU 'virt' machine on the m68k architecture. This
board emulates a generic machine based on the Motorola 68040 CPU
equipped with Goldfish virtual peripherals.
Introduce the necessary board configuration and initialization
infrastructure. The implementation includes logic to parse the QEMU
bootinfo interface, enabling dynamic detection of system RAM size to
adapt to the virtual machine's configuration.
Enable the Goldfish TTY driver for serial console output. Additionally,
enable Goldfish RTC and timer drivers to support real-time clock
functionality and nanosecond-resolution delays. Include comprehensive
documentation covering build instructions and usage examples.
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Tested-by: Daniel Palmer <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add support for the Motorola 68040 architecture. Currently, m68k
support in U-Boot is primarily focused on ColdFire variants. Introduce
the necessary infrastructure to support the classic M680x0 series,
specifically targeting the M68040 as emulated by QEMU.
The implementation includes exception vectors, early startup code, and
minimal CPU initialization and relocation stubs. It also defines the
standard m68k boot information structure used for passing hardware
information to the operating system. To ensure compatibility, ColdFire-
specific library objects such as cache and interrupt handling are
excluded from the build when M68040 is selected.
Additionally, apply a specific workaround during the early memory
reservation stage. Use a manual loop to clear global data instead of
the standard memset() function, as utilizing memset() at this point was
observed to cause a hang on the QEMU platform.
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Acked-by: Angelo Dureghello <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
device for non SPLs"
This series from Dominik Haller <[email protected]> provides a way for
TI K3 platforms to determine their boot device outside of SPL and then
adds support for the PHYTEC phyCORE-AM68x/TDA4x SoM.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add support for the PHYTEC phyCORE-AM68x/TDA4x (J721S2 family) SoM.
Supported features:
- 4GB LPDDR4 RAM
- eMMC
- SD-Card
- Ethernet
- OSPI
- AVS
- debug UART
Signed-off-by: Dominik Haller <[email protected]>
Reviewed-by: Wadim Egorov <[email protected]>
|
|
Introduce get_boot_device() to obtain the booting device. Make it also
available for non SPL builds so u-boot can also know the device it
is booting from.
Signed-off-by: Dominik Haller <[email protected]>
|
|
Add a framebuffer node to the DTSI in order to ensure that display
continues to work, as since v6.19 of devicetree-rebasing sources, it
uses Samsung's DECON (Display Enhancement CONtroller) for display, which
is, as of yet, not supported in U-Boot.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
Add a framebuffer node to the DTSI in order to ensure that display
continues to work, as since v6.19 of devicetree-rebasing sources, it
uses Samsung's DECON (Display Enhancement CONtroller) for display, which
is, as of yet, not supported in U-Boot.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
Add a framebuffer node to the DTSI in order to ensure that display
continues to work, as since v6.19 of devicetree-rebasing sources, it
uses Samsung's DECON (Display Enhancement CONtroller) for display, which
is, as of yet, not supported in U-Boot.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Signed-off-by: Minkyu Kang <[email protected]>
|
|
With the support for common speed grade configuration added in commit
65a6b83a9b7f ("mach-k3: refactor A53 speed grade clock-rate fixup"),
this patch extends the support to AM64x SoCs.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Following the 'commit 95b5a7de30f6 ("FWU: STM32MP1: Add support to
read boot index from backup register")', this patch enables reading
the boot index from backup registers on STM32MP2 platforms.
Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
Add bootph-all property in ltdc node in stm32mp257f-ev1-u-boot.dtsi
to fix the following issue :
Video device 'display-controller@48010000' cannot allocate frame buffer
memory - ensure the device is set up beforen
stm32_rifsc bus@42080000: display-controller@48010000 failed to bind on
bus (-28)
stm32_rifsc bus@42080000: Some child failed to bind (-28)
initcall_run_r(): initcall initr_dm() failed
ERROR ### Please RESET the board ###
Fixes: 29ab19c2bead ("Subtree merge tag 'v6.18-dts' of dts repo [1] into dts/upstream")
Reviewed-by: Patrick Delaunay <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
|
|
Add SCMI clocks. These clocks are used as parent clocks and are
referenced by their rcc's node position in clk-stm32mp13.c
Fixes: fdb1bffe2827 ("clk: scmi: Postpone clock name resolution")
Reviewed-by: Patrick Delaunay <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
|
|
It can be useful in xPL to access symbols from binman, such as the
offset/position and size of a binman entry.
Place these binman symbols together at the end of the xPL binary for
ARMv8, similar to ARM and RISC-V.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
As of v2026.01, no platforms contain any rel.dyn sections in their xPL
phase images. Their inclusion in linker scripts initially was an
oversight as part of taking the full U-Boot linker scripts and modifying
them down. Then in commit 8b0ebe054bb3 ("arm: Update linker scripts to
ensure appended device tree is aligned") these sections were used to
force correct alignment for the device tree. This however, lead to a
different problem.
That problem is that when we do not have a separate BSS section in SPL
we instead would overlay the BSS with the rel.dyn section, in the common
linker script case. This in turn lead to creating an incorrectly sized
BSS "pad" file sometimes (depending on arbitrary changes within the rest
of the binary itself). This in turn lead to the dtb being in the wrong
location in the binary and not found at run time.
This commit fixes a few things:
- Remove the rel.dyn section from all ARM SPL linker scripts.
- In turn, this moves the dtb alignment statement in to another section.
- For ast2600 which uses CONFIG_POSITION_INDEPENDENT we need to keep the
symbols however.
Tested-by: Fabio Estevam <[email protected]>
Reported-by: Fabio Estevam <[email protected]>
Co-developed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Chia-Wei, Wang <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
drivers"
Markus Schneider-Pargmann (TI.com) <[email protected]> says:
musb currently uses a wrapper driver that binds on the parent device of
the actual musb devices to manage the differentiation between gadget and
host modes. However in the upstream devicetree this parent devicetree
node can not be used to match the wrapper driver.
To be able to probe the musb devices in host/gadget mode directly, this
series introduces support for returning -ENODEV in bind functions
resulting in iterating the remaining drivers potentially binding to
other drivers that match the compatible.
Link: https://lore.kernel.org/r/20260127-topic-musb-probing-v2026-01-v4-0-ea3201e0f809@baylibre.com
|
|
Add a test for binding of multiple drivers with the same compatible. If
one of the drivers returns -ENODEV the other one needs to be bound.
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq
- Rename freescale to nxp
- Add CPLD support via IFC to the ls1021a-iot board
- Use scmi_clk_state_in_v2 in sandbox
|
|
This patch renames the board directory from board/freescale to
board/nxp because NXP now provides Board Support Packages (BSPs) and
tools for the former Freescale i.MX and other i.MX products.
All relevant references have been updated accordingly. This change does
not affect functionality.
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
|
|
Since the commit 1e24e84db41a ("tiny-printf: Handle formatting of %p
with an extra Kconfig"), SPL_USE_TINY_PRINTF_POINTER_SUPPORT has been
made mandatory in order to use %p which would earlier have defaulted to
a 'long' print.
Without this config symbol, k3_sysfw_dfu_download fails to set the
correct value for the DFU string with:
sprintf(dfu_str, "sysfw.itb ram 0x%p 0x%x", addr,
CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
The value we get "sysfw.itb ram 0x? 0x41c29d40" causes a boot failure.
Therefore this patch sets SPL_USE_TINY_PRINTF_POINTER_SUPPORT for all K3
devices since the size impact is less than 100 bytes.
Signed-off-by: Anshul Dalal <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This reverts commit 380ddb473c6bdf87e66c0fb93e256d1e233c6f5b.
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") we now require the correct, 8 byte alignment
of a device tree in order to work with it ourselves. This has exposed a
number of issues. In the case of using arch/arm/cpu/u-boot-spl.lds for
an xPL phase and having the BSS be overlayed with the dynamic
relocations sections (here, .rel.dyn) we had missed adding the comment
about our asm memset requirements. Then, when adjusting ALIGN statements
we later missed this one. In turn, when we use objcopy to create our
binary image we end up in the situation where
where the BSS must start out 8 byte aligned as
well as end 8 byte aligned because for appended device tree the
requirement is that the whole BSS (which we add as padding to the
binary) must be 8 byte aligned. Otherwise we end up with the situation
where __bss_end (where we look for the device tree at run time) is
aligned but the size of the BSS we add
Fixes: 7828a1eeb2a1 ("arm: remove redundant section alignments")
Fixes: 52caad0d14a3 ("ARM: Align image end to 8 bytes to fit DT alignment")
Reported-by: Fabio Estevam <[email protected]>
Tested-by: Fabio Estevam <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
---
Cc: Ilias Apalodimas <[email protected]>
Cc: Marek Vasut <[email protected]>
|
|
Some boards feature an "odd" DRAM size, where the total RAM is 1.5GB or
3GB. Our existing DRAM size detection routines can only detect power-of-2
sized configuration, and on those boards the DRAM size is overestimated,
so this typically breaks the boot quite early.
There doesn't seem to be an easy explicit way to detect those odd-sized
chips, but we can test whether the later part of the memory behaves like
memory, by verifying that a written pattern can be read back.
Experiments show that there is no aliasing effect here, as all locations
in the unimplemented range always return some fixed pattern, and cannot
be changed.
Also so far all those boards use a factor of 3 of some lower power-of-2
number, or 3/4th of some higher number. The size detection routine
discovers the higher number, so we can check for some memory cells beyond
75% of the detected size to be legit.
Add a routine the inverts all bits at a given location in memory, and
reads that back to prove that the new value was stored.
Then test the memory cell at exactly 3/4th of the detected size, and cap
the size of the memory to 75% when this test fails. For good measure
also make sure that memory just below the assumed memory end really
works.
This enables boards which ship with such odd memory sizes.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
|
|
Sparrow Hawk
The 9FGV0441 PCIe clock generator can operate in autonomous mode, which
is the default mode. U-Boot currently does not have a driver for this
PCIe clock generator, but Linux 6.17 DT does describe the clock generator
in Sparrow Hawk board DT and this DT is included in U-Boot since commit
eea470fd7f6a ("Subtree merge tag 'v6.17-dts' of dts repo [1] into dts/upstream").
Reinstate basic PCIe clock description which matches the behavior of
Linux DT before Linux 6.17.y release in in U-Boot DT extras to allow
PCIe to be used on Sparrow Hawk board in U-Boot until the 9FGV0441
driver gets implemented or ported from Linux.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Greg Malysa <[email protected]> says:
This series adds the final pieces to enable mainline U-Boot to build and
boot all Analog Devices SC5xx SoCs and supports the associated carrier
board options. At this point it should be viable for new users for these
platforms to start with the latest version of U-Boot rather than our
vendor fork, however some features (such as OSPI support and falcon
boot) remain unavailable until we are able to unify our implementations
with the mainline implementations.
Link: https://lore.kernel.org/r/[email protected]
[trini: Rebuild CI containers to have new tools]
Signed-off-by: Tom Rini <[email protected]>
|
|
This adds support for the Analog Devices SC594 SOM and configurations
for using it with both the SOMCRR-EZKIT and SOMCRR-EZLITE.
Signed-off-by: Vasileios Bimpikas <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Caleb Ethridge <[email protected]>
Signed-off-by: Philip Molloy <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
|
|
This adds support for the Analog Devices SC598-SOM and configurations
for using it with both the SOMCRR-EZKIT and SOMCRR-EZLITE. This adds
dtsis for both Rev D (including older revisions) and Rev E SOMs, which
are not compatible due to BOM changes. Although no new Rev D SOMs are
produced as of 2025, many are in circulation, so the RevD dtsi is
included to facilitate use for existing customers.
Signed-off-by: Vasileios Bimpikas <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Caleb Ethridge <[email protected]>
Signed-off-by: Philip Molloy <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
|
|
This adds support for the Analog Devices SC584-EZKIT.
Signed-off-by: Vasileios Bimpikas <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Caleb Ethridge <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
|
|
This adds support for the Analog Devices SC589-EZKIT and SC589-mini.
Signed-off-by: Vasileios Bimpikas <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Caleb Ethridge <[email protected]>
Signed-off-by: Philip Molloy <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
|
|
This adds support for the Analog Devices SC573 EZKIT.
Signed-off-by: Vasileios Bimpikas <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
Signed-off-by: Arturs Artamonovs <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Caleb Ethridge <[email protected]>
Signed-off-by: Philip Molloy <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
|
|
Binman is optionally supported for Analog Devices sc5xx SoCs if Yocto is
not being used to create and assemble system images. The spl LDR is
generated locally but other artifacts such as kernel FIT image and root
file system are built externally and must be supplied to binman if used.
Binman is enabled by selecting the SC5XX_USE_BINMAN config symbol and
the image structure is included in the shared sc5xx device tree.
Signed-off-by: Greg Malysa <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
|
|
Support for the SOM-CRR variants introduces library level changes that
are not modelled in the device tree. As a result they cannot both be
selected at the same time, so this updates the dependency in Kconfig to
prevent them from being enabled together.
Reported-by: Philip Molloy <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
|
|
The symbol SC_BOOT_MODE was named incorrectly and inconsistently with
its usage. The selected boot mode is set only by hardware and cannot be
adjusted through software (apart from the use of FORCE_BMODE to instruct
the boot rom to ignore the hardware setting when loading uboot proper,
but this cannot change how SPL is loaded).
This symbol actually controlled the BCODE (easily confused with BMODE,
shorthand for boot mode), so this renames it to SC_BCODE and updates the
help text to reflect its actual usage: the BCODE is an SoC- and boot
mode-specific setting that affects how the boot rom configures QSPI or
OSPI in order to read an LDR file from the associated peripheral.
Reported-by: Philip Molloy <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
|
|
Add Kconfig symbols to parameterize the SPI flash layout used in a
default-ish configuration. This adds more flexibility to the default ADI
environment, enabling customers with boards based on but not identical
to an ezkit to reuse more of the infrastructure. Furthermore it allows
for yocto (the expected default) or binman (to be introduced in this
series) to configure or use the flash layout based on a single
definition of all of the parameters when creating an image.
Signed-off-by: Greg Malysa <[email protected]>
Signed-off-by: Utsav Agarwal <[email protected]>
|
|
With commit 5663b137e682 ("arm: Remove edminiv2 board") the last
ARCH_ORION5X platform was removed. Remove the rest of the architecture
code which is now unused.
Reviewed-by: Tony Dinh <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
correctly aligned"
Tom Rini <[email protected]> says:
This series builds on top of what Beleswar Padhi did in [1]. While
there's still discussion about the mkimage related parts, the linker
portion appears to the reliable path forward. An alternative that I had
mentioned before, and was part of previous discussions on this topic[2]
is in the end I believe not reliable enough. While we can take an output
file and pad it to where we think it needs to be, ultimately the linker
needs to place the symbol where we want it and if that isn't where we
pad to, we have a different problem. So what this series does (but each
commit message elaborates on the arch-specific linker scripts being
inconsistent) is make sure the linker script will place the required
symbol at 8-byte alignment, and then also use an ASSERT to fail the
build if this would not be true due to some unforseen event.
[1]: https://lore.kernel.org/u-boot/[email protected]/
[2]: https://source.denx.de/u-boot/u-boot/-/issues/30
Link: https://lore.kernel.org/r/[email protected]
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Rewrite the '.rel.dyn' (u-boot.lds) to follow modern practices, and
include the 8-byte alignment at the end of the section.
- Expands the '.dynamic' section (u-boot-64.lds) to be more readable
when adding a second statement to the section.
- Aligns the final section before _end (for U-Boot) or _image_binary_end
or __bss_end (for xPL phases) by 8-bytes by adding '. = ALIGN(8);' to
the final section before the symbol or changing an existing ALIGN(4)
statement.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _image_binary_end (for xPL phases) by
8-bytes by adding '. = ALIGN(8);' to the final section before the
symbol.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end (for U-Boot) or _image_binary_end
(for xPL phases) by 8-bytes by adding '. = ALIGN(8);' to the final
section before the symbol.
- Remove a now-spurious '. = ALIGN(x);' statement that was intended to
provide the above alignments.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end by 8-bytes by adding '. =
ALIGN(8);' or changing an existing ALIGN(4) statement.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end 8-bytes by adding '. = ALIGN(8);'
to the final section before the symbol.
- Remove a now-spurious '. = ALIGN(x);' statement that was intended to
provide the above alignments.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end (for U-Boot) or _image_binary_end
(for xPL phases) by 8-bytes by adding '. = ALIGN(8);' to the final
section before the symbol. For SPL we need this in two places to cover
all build configurations.
- Remove now-spurious '. = ALIGN(x);' statements that were intended to
provide the above alignments.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Reviewed-by: Daniel Schwierzeck <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Aligns the final section before _end (for U-Boot) or _image_binary_end
(for xPL phases) by 8-bytes by adjusting the ALIGN(4) statement to be
ALIGN(8) in the final section before the symbol.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Tested-by: Michal Simek <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Remove part of what Marek Vasut did in commit 9ed99e2eeadb ("m68k:
Assure end of U-Boot is at 8-byte aligned offset") as we now better
understand what can trigger failure and check for it.
- Rewrite the '.dynsym' section to follow modern practices, and include
the 8-byte alignment at the end of the section.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
Signed-off-by: Tom Rini <[email protected]>
|
|
With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
device tree is not 8-byte aligned. In commit 85f586035d75 ("ARM: OMAP2+:
Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
that we must have ALIGN(x) statements inside of a section to ensure that
padding is included and not simply that the linker address counter is
incremented. To that end, this patch:
- Expands some linker sections to be more readable when adding a second
statement to the section.
- Aligns the final section before _end (for U-Boot) or
_image_binary_end or __bss_end (for xPL phases) by 8-bytes by adding
'. = ALIGN(8);' to the final section before the symbol.
- Ensure that we do have alignment by adding an ASSERT so that when not
aligned we fail to link (and explain why).
- Remove now-spurious '. = ALIGN(x);' statements that were intended to
provide the above alignments.
Tested-by: Michal Simek <[email protected]> # Zynq
Reviewed-by: Ilias Apalodimas <[email protected]>
[trini: Also update arch/arm/cpu/armv8/u-boot.lds as Ilas requested]
Signed-off-by: Tom Rini <[email protected]>
|
|
The OMAP2 SPL linker script (also used for K3 platforms) currently uses
a 4-byte alignment directive after the __u_boot_list section. This
alignment directive only advances the location counter without padding
the actual binary output.
When objcopy extracts u-boot-spl-nodtb.bin, it includes only actual
data, stopping at the last byte of __u_boot_list (e.g., 0x41c359fc),
not an aligned address (e.g., 0x41c35a00). So, when the FIT image
containing device trees is concatenated to the SPL binary, it gets
appended at this unaligned file size, causing libfdt validation failure.
To fix this, move the alignment directive into the __u_boot_list section
itself and make it 8-byte aligned as per DT spec. This forces the linker
to include padding as part of the section data, ensuring objcopy
includes the padding bytes in the binary and the appended FIT image
starts at an 8-byte aligned boundary.
Reported-by: Anshul Dalal <[email protected]>
Closes: https://lore.kernel.org/u-boot/[email protected]
Fixes: 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c")
Signed-off-by: Beleswar Padhi <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze
AMD/Xilinx/FPGA changes for v2026.04-rc1 v2
microblaze:
- Fix spl_boot_list order
versal2:
- Fix EMMC distro boot setup
- Align distro boot variables with memory layout
zynqmp-phy:
- Sync with Linux kernel driver
zynqmp:
- Add verify_auth command
- DT sync
- Add placing variables to FAT/EXT4
- Enable PCIe driver by default
pcie - xilinx-nwl:
- Fix Link down crash
ufs:
- Align clock/reset with DT binding
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYIAB0WIQSXAixArPbWpRanWW+rB/7wTvUR9QUCaW3p3wAKCRCrB/7wTvUR
# 9VkwAP4jPRALpM34VpTimNe/iwigIx8hAHxbvkUU0oJ/DW6W8AEAhCSL+ydgreuv
# kKCyNiOF1sm8IrOh4TdtMIFn37d4Dwg=
# =AkKK
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 19 Jan 2026 02:22:55 AM CST
# gpg: using EDDSA key 97022C40ACF6D6A516A7596FAB07FEF04EF511F5
# gpg: Can't check signature: No public key
|
|
On my AN7581 board, the same change in the Airoha ATF-2.10 source code
causes instability in eMMC reading. After the patch, in about 9 of 10
cases, ATF BL2 is unable to read FIP image from the eMMC flash. Thus
BL31 and U-Boot are unable to start.
Lets revert commit 7cb79f8d3d55 ("arm: dts: an7581: set r_smpl for MMC
in U-Boot") until the issue will be investigated.
Signed-off-by: Mikhail Kshevetskiy <[email protected]>
|
|
Extend spl_boot_list[] only when SPL has support for it.
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/d1c1d677b2eb4266290d31dbdf2e6e44c77a75ff.1768557507.git.michal.simek@amd.com
|
|
On GDET enabled part, need to call voltage change start and finish
APIs when adjust the voltage more than 100mv. Otherwise GDET will be
triggered and system is reset
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
