u-boot.git/arch/arm/mach-omap2, branch master

am335x: add support for loading u-boot from multiple offsets

2026-02-10T21:54:04Z

The am335x knows nothing about eMMC boot partitions, so in order to implement an update procedure of the bootloader which is robust against power failure or other interruptions, one must make use of the fact that ROM code on the am335x looks for a valid first stage bootloader at several different offsets. Updating that can then be implemented by (assume we put MLO at offsets 128K and 256K): (1) At least one of the two slots must contain a valid header, since we successfully booted. Pick the other one. (2) Overwrite the first sector of the slot chosen in step (a) with all zeroes. (3) Write everything but the first sector to the chosen slot. (4) Write the first sector (containing the magic signature that the boot ROM uses to identify a valid image) to the chosen slot. (5) Repeat steps (2)-(4) for the other slot. It's not possible to simply write the whole MLO in one go, especially not when updating the 128K slot, because an interruption after the first sector is written would make the ROM code believe the image is valid. But this only caters for SPL itself; regardless of where SPL was loaded from, it would go on to load U-Boot proper from SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. So in order to update the whole bootloader, we need to teach SPL to use a different offset for U-Boot proper depending on where SPL itself was loaded from (*). With that, the update procedure is just amended by a step (3a) Write U-Boot proper to the offset corresponding to the SPL slot being updated. We can know (*) because the ROM code sets a new bit in a certain "trace vector" before each successive attempt. Signed-off-by: Rasmus Villemoes

Merge patch series "Update linker scripts to ensure appended device tree is correctly aligned"

2026-01-20T18:07:25Z

Tom Rini 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/20260112101102.1417970-1-b-padhi@ti.com/ [2]: https://source.denx.de/u-boot/u-boot/-/issues/30 Link: https://lore.kernel.org/r/20260115222828.3931345-1-trini@konsulko.com

arm: Update linker scripts to ensure appended device tree is aligned

2026-01-20T18:06:41Z

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 # Zynq Reviewed-by: Ilias Apalodimas [trini: Also update arch/arm/cpu/armv8/u-boot.lds as Ilas requested] Signed-off-by: Tom Rini

ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

2026-01-20T16:18:43Z

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 Closes: https://lore.kernel.org/u-boot/DFJ950O0QM0D.380U0N16ZO19E@ti.com Fixes: 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c") Signed-off-by: Beleswar Padhi

kbuild: Bump the build system to 6.1

2026-01-02T16:28:14Z

Our last sync with the kernel was 5.1. We are so out of sync now, that tracking the patches and backporting them one by one makes little sense and it's going to take ages. This is an attempt to sync up Makefiles to 6.1. Unfortunately due to sheer amount of patches this is not easy to review, but that's what we decided during a community call for the bump to 5.1, so we are following the same guidelines here. Signed-off-by: Sughosh Ganu Signed-off-by: Ilias Apalodimas a #rebased on -next

arm: omap3: remove leftover from CM_T35 support removal

2025-12-05T16:34:52Z

Commit 76386d6195a1 ("arm: Remove cm_t35 board") removed support for the board that was built when TARGET_CM_T35 is selected, but removal of the symbol was forgotten, so let's fix this oversight. While at it, update the README for omap3 to remove the last mention of cm_t35. Fixes: 76386d6195a1 ("arm: Remove cm_t35 board") Signed-off-by: Quentin Schulz Reviewed-by: Tom Rini

global: Make ARCH_MISC_INIT a selected symbol

2025-07-11T17:33:25Z

This symbol is not something that the user should be enabling or disabling but rather the developer for a particular board should select it when required. This is mostly size neutral, however a few places do have changes. In the case of i.MX6ULL systems, it is always the case that arch_misc_init() could call setup_serial_number() and do useful work, but was not enabled widely, but now is. In the case of i.MX23/28 systems, we should be able to call mx28_fixup_vt() again here, so do so. Finally, some platforms were calling arch_misc_init() and then not doing anything and this results in removing the option. Acked-by: Peng Fan Signed-off-by: Tom Rini

Merge patch series "Hex value prefix case cleanup"

2025-06-14T15:10:48Z

E Shattow says: Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot. There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix or placeholder in documentation and error messages. External devicetree-rebasing dts/upstream and the generated code of xilinx/zynq are ignored for the series. Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de

arch: use lowercase hex prefix style

2025-06-14T15:09:40Z

Use consistent lowercase hex prefix style in arch/* Signed-off-by: E Shattow

spl: Rename jump_to_image_no_args()

2025-06-13T19:22:53Z

This function is currently a misnomer at times as we have cases where it passes arguments to the image. In preparation for making that be a more common case rename this function to jump_to_image(...). In order to do this, rename jump_to_image in board_init_r(...) to jumper so that we do not have a conflict. Signed-off-by: Simon Glass [trini: Reword the commit message, adding missing cases of jump_to_image_no_args()] Signed-off-by: Tom Rini