summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
12 hoursMerge patch series "fs: btrfs: add support for readdir"HEADmasterTom Rini
Alexey Charkov <[email protected]> says: Btrfs in U-boot currently uses a custom callback for ls and doesn't expose the standard opendir/readdir/closedir interface, making it harder to use in generic code. One area where this would be useful is in discovering BLS type 1 entries [1] on a Btrfs filesystem. Add support for the standard interface, and implement ls in terms of it. [1] https://lore.kernel.org/u-boot/[email protected]/ Link: https://lore.kernel.org/r/[email protected]
12 hoursfs: btrfs: use fs_ls_generic() and drop custom implementationAlexey Charkov
Now that generic callbacks for opendir/readdir/closedir are implemented, the custom btrfs_ls() implementation is no longer needed, along with the btrfs_iter_dir() callback iterator. Use fs_ls_generic() instead. Signed-off-by: Alexey Charkov <[email protected]> Reviewed-by: Qu Wenruo <[email protected]>
12 hoursfs: btrfs: implement opendir(), readdir() and closedir()Alexey Charkov
Add support for generic directory iteration with opendir(), readdir() and closedir() in the btrfs filesystem driver. Signed-off-by: Alexey Charkov <[email protected]> Reviewed-by: Qu Wenruo <[email protected]>
44 hoursMerge tag 'ubi-updates-for-2026.10-rc1' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-ubi ubi updates for 2026.10-rc1 - fs: ubifs: fix ubifs_finddir() from Patrick Fixes: 0cab29ff467e ("fs: ubifs: Fix and rework error handling in ubifs_finddir") fix test -e - cmd: ubi: rework from Weijie - env: ubi: add support to create environment volume if it does not exist - cmd: ubi: allow creating volume with all free spaces in ubi_create_vol - cmd: ubi: export more APIs to public - cmd: ubi: reorganize command messages - cmd: ubi: change all positive error return value to negative - cmd: ubi: change the type of parameter dynamic to bool - cmd: ubifs: mark string parameters with const - cmd: ubi: use void * for buf parameter in ubi_volume_read - cmd: ubi: mark read-only function parameters with const - ubi: remove unnecessary extern directive from function prototypes
3 daysMerge patch series "pinctrl: add support of Airoha SoCs"Tom Rini
Mikhail Kshevetskiy <[email protected]> says: This patch series add pin controller and gpio driver support for EN7523/ AN7581/AN7583 SoCs. The driver based on official linux airoha pinctrl and gpio driver with Matheus Sampaio Queiroga changes. The original Matheus Sampaio Queiroga driver can be taken from the repo: https://sirherobrine23.com.br/airoha_en7523/kernel/src/branch/airoha_en7523_pinctrl Additionally in the EN7523 case the patches removes existing gpio dts nodes and replaces them with pinctrl node. It should not be very dangerous, because: * No official EN7523 gpio support present in U-Boot * Legacy Linux EN7523 GPIO driver is mostly abandoned * The same driver is planned for upstream linux/openwrt This patchset includes bitfield.h patches created for Linux kernel by Geert Uytterhoeven. It suits U-Boot fine. I preserve original author and original commit messages. Please note me, if there is a better way. The patches were tested on EN7523/AN7581/AN7583 boards. Link: https://lore.kernel.org/r/[email protected]
3 dayspinctrl: add more pinconf/pinctrl definitionsMikhail Kshevetskiy
These pinconf/pinctrl definitions will be used by the next patches. The definitions was taken from public headers of linux-7.0. It's used by several linux pinctrl drivers, so it might be helpful for U-Boot as well. Pinconf definitions are placed near the corresponding U-Boot definitions in file include/dm/pinctrl.h. Pin/group/function definitions stored within the same path as in linux (include/linux/pinctrl/pinctrl.h). Signed-off-by: Mikhail Kshevetskiy <[email protected]> Reviewed-by: David Lechner <[email protected]>
3 daysbitfield: Add non-constant field_{prep, get}() helpersGeert Uytterhoeven
The existing FIELD_{GET,PREP}() macros are limited to compile-time constants. However, it is very common to prepare or extract bitfield elements where the bitfield mask is not a compile-time constant. To avoid this limitation, the AT91 clock driver and several other drivers already have their own non-const field_{prep,get}() macros. Make them available for general use by adding them to <linux/bitfield.h>, and improve them slightly: 1. Avoid evaluating macro parameters more than once, 2. Replace "ffs() - 1" by "__ffs()", 3. Support 64-bit use on 32-bit architectures, 4. Wire field_{get,prep}() to FIELD_{GET,PREP}() when mask is actually constant. This is deliberately not merged into the existing FIELD_{GET,PREP}() macros, as people expressed the desire to keep stricter variants for increased safety, or for performance critical paths. Yury: use __mask within new macros. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Acked-by: Crt Mori <[email protected]> Acked-by: Nuno Sá <[email protected]> Acked-by: Richard Genoud <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Yury Norov (NVIDIA) <[email protected]> Signed-off-by: Yury Norov (NVIDIA) <[email protected]> [Linux commit: c1c6ab80b25c8db1e2ef5ae3ac8075d2c242ae13] Signed-off-by: Mikhail Kshevetskiy <[email protected]> Reviewed-by: David Lechner <[email protected]> Reviewed-by: Simon Glass <[email protected]>
3 daysbitfield: Add less-checking __FIELD_{GET,PREP}()Geert Uytterhoeven
The BUILD_BUG_ON_MSG() check against "~0ull" works only with "unsigned (long) long" _mask types. For constant masks, that condition is usually met, as GENMASK() yields an UL value. The few places where the constant mask is stored in an intermediate variable were fixed by changing the variable type to u64. However, for non-constant masks, smaller unsigned types should be valid, too, but currently lead to "result of comparison of constant 18446744073709551615 with expression of type ... is always false"-warnings with clang and W=1. Hence refactor the __BF_FIELD_CHECK() helper, and factor out __FIELD_{GET,PREP}(). The later lack the single problematic check, but are otherwise identical to FIELD_{GET,PREP}(), and are intended to be used in the fully non-const variants later. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Yury Norov (NVIDIA) <[email protected]> [Linux commit: 2a6c045640c38a407a39cd40c3c4d8dd2fd89aa8] Signed-off-by: Mikhail Kshevetskiy <[email protected]> Reviewed-by: David Lechner <[email protected]> Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Scott Wood <[email protected]> Acked-by: Gerald Van Baren <[email protected]> Reviewed-by: Andre Przywara <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
3 daysbitops: import BITS_PER_TYPE() macro from linuxMikhail Kshevetskiy
This macro will be used by include/linux/bitfield.h header. Signed-off-by: Mikhail Kshevetskiy <[email protected]> Reviewed-by: David Lechner <[email protected]> Reviewed-by: Simon Glass <[email protected]>
3 dayscmd: ubi: export more APIs to publicWeijie Gao
Export the following functions to public: - ubi_detach(): this is paired with ubi_part(). One may call this function to completely clean up the ubi subsystem after using ubi_part(). - ubi_{create,find,remove}_vol: this is a set of functions for volume management. The original ubi_remove_vol is renamed to __ubi_remove_vol to allow the new ubi_remove_vol() being used as a wrapper for __ubi_remove_vol() with volume name. Also, comments are added for all exported functions. Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Weijie Gao <[email protected]>
3 dayscmd: ubifs: mark string parameters with constWeijie Gao
File name and volume name should be const as they will not be modified in these functions. Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Weijie Gao <[email protected]>
3 dayscmd: ubi: use void * for buf parameter in ubi_volume_readWeijie Gao
Use void * to avoid explicit type casting as what ubi_volume_write has done already. Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Weijie Gao <[email protected]>
3 dayscmd: ubi: mark read-only function parameters with constWeijie Gao
Parameters like part/volume name and buffer for writing are not being modified by the callee functions and should be marked const. Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Weijie Gao <[email protected]>
3 daysubi: remove unnecessary extern directive from function prototypesWeijie Gao
The extern directive is unnecessary for function declaration and should be removed. Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Weijie Gao <[email protected]>
4 daysMerge branch 'next'Tom Rini
5 daysls1028ardb: Move environment variables to .env fileAristo Chen
Move the bulk of the board environment from CFG_EXTRA_ENV_SETTINGS in ls1028ardb.h to board/nxp/ls1028a/ls1028ardb.env. Because the board directory is shared with ls1028aqds, the file is selected through CONFIG_ENV_SOURCE_FILE rather than the SYS_BOARD default. The distro_bootcmd machinery cannot be expressed in a .env file. The BOOTENV macro expands to environment text with embedded NUL separators, and the board overrides three distro variables (boot_scripts, boot_a_script and scan_dev_for_boot_part) that must follow BOOTENV to take effect. BOOTENV and those three overrides therefore remain in CFG_EXTRA_ENV_SETTINGS, which is concatenated after the .env text, while every other variable moves to the .env file. The resulting default environment is functionally unchanged for both the ls1028ardb_tfa and ls1028ardb_tfa_SECURE_BOOT defconfigs. This was verified with an order aware comparison of the default environment before and after the change. The only difference is that three accidental double spaces in xspi_bootcmd, sd_bootcmd and emmc_bootcmd collapse to single spaces, because the preprocessor normalises whitespace in the now unquoted text, which does not affect command parsing. Signed-off-by: Aristo Chen <[email protected]> Signed-off-by: Peng Fan <[email protected]>
8 daysdrivers: sysreset: revert support for args in requestQuentin Schulz
This reverts: - commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl option is available") - commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not supported") - commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") - commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation") - commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs") - commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take arguments") There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") due to commit 02ef1859b44f ("configs: Resync with savedefconfig"), but the conflict resolution was trivial. The args support for the sysreset uclass contains a logic bug. The first sysreset device implementing the request_arg callback will consume the args, not support the specified arg and thus return -EPROTONOSUPPORT which will stop the iteration over all sysreset devices. This is an issue if one has multiple sysreset devices and each with support for different (valid) args. If a sysreset device implements a -dummy argument and another -foo and a user calls reset -dummy from the U-Boot CLI, it'll depend on which sysreset device will be attempted first. If it is the one implementing -foo, it'll return it doesn't support the argument with -EPROTONOSUPPORT in which case the device implementing -dummy will never be attempted and instead we'll do a cold reset which is very likely not what's expected from the user. Casey suggested[1] we revert this and start from scratch again with a different implementation instead. [1] https://lore.kernel.org/u-boot/[email protected]/ Acked-by: Casey Connolly <[email protected]> Signed-off-by: Quentin Schulz <[email protected]>
8 daystest: bootdev: scan with a broken high-priority deviceDenis Mukhin
Add bootdev_hunt_fallthrough() test to verify that 'bootflow scan -l' falls back to a lower-priority bootdev when a higher-priority hunter fails. Introduce a simple 'sandbox-bootdev' device for the test. The new bootdev can be configured to produce an error at the hunting stage. Introduce new host_set_flags_by_label() API and a flags field to 'host_sb_plat' to simulate a bootdev hunter failure for the test. Adjust boot{dev,flow} tests which depend on bootdev hunters. Signed-off-by: Denis Mukhin <[email protected]> Reviewed-by: Simon Glass <[email protected]>
12 daysMerge patch series "arm: aspeed: add initial AST2700 SoC support"Tom Rini
Ryan Chen <[email protected]> says: AST2700 is the 8th generation of Integrated Remote Management Processor introduced by ASPEED Technology Inc. It is a Board Management Controller (BMC) SoC family with a dual-die architecture: SoC0 ("CPU" die with four ARM Cortex-A35 application cores) and SoC1 ("IO" die with peripherals) each SoC have its own SCU PLLs, clock dividers and reset domains. Link: https://lore.kernel.org/r/[email protected]
12 daystreewide: Staticize and constify acpi opsMarek Vasut
Set the acpi_ops structure as static const where applicable. The The structure is not accessible from outside of drivers and is not going to be modified at runtime. The structure may be unused in a couple of drivers depending on their configuration, mark those sites with __maybe_unused . Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Simon Glass <[email protected]>
12 dayscros_ec: Convert dm_cros_ec_get_ops into an inline function and constify ↵Marek Vasut
dm_cros_ec_ops Convert dm_cros_ec_get_ops into an inline function to improve compiler code coverage, and constify struct dm_cros_ec_ops in a few places. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Simon Glass <[email protected]>
12 daysarm: aspeed: add ASPEED AST2700 SoC family supportRyan Chen
Add initial support for the ASPEED AST2700, an arm64 (Cortex-A35) Baseboard Management Controller (BMC) SoC. AST2700 is Aspeed's 8th generation BMC and uses a dual-die architecture: SoC0 (the "CPU" die) hosts the four Cortex-A35 cores and its own SCU at 0x12c02000, while SoC1 (the "IO" die) hosts the peripherals and its own SCU at 0x14c02000. This commit adds: - ASPEED_AST2700 Kconfig option and the ast2700 mach subdir (mach Makefile, ast2700/Kconfig, board/aspeed/evb_ast2700/*) - arm64 MMU map covering the SoC device window and the DRAM region at 0x4_0000_0000 (up to 8 GiB) - lowlevel_init.S for early CPU bring-up - cpu-info: print SoC ID (AST2700/2720/2750 A0/A1/A2 variants) and reset cause (cold reset, EXT reset, WDT reset) - board_common: dram_init via UCLASS_RAM, AHBC timeout init - platform: env_get_location() that selects SPI/eMMC based on the IO-die HW strap; arch_misc_init() that exposes ${boot_device} and ${verify} to the boot script - SCU0/SCU1 register layout header (scu_ast2700.h) - configs/evb-ast2700_defconfig and include/configs/evb_ast2700.h for the AST2700 EVB board The defconfig depends on ast2700-evb.dts, which is introduced in a subsequent patch; this commit must be applied with the remaining series for evb-ast2700_defconfig to build. Signed-off-by: Ryan Chen <[email protected]>
2026-06-26clk: clk-divider: add clk_register_divider_table()Brian Ruley
The existing clk_register_divider() only supports linear or power-of-two divider mappings. Some hardware (e.g. i.MX6 PLL5 post_div and video_div) uses non-linear register-value-to-divisor mappings that require a lookup table. Add clk_register_divider_table() which accepts a clk_div_table, and reimplement clk_register_divider() as a wrapper passing table=NULL. Signed-off-by: Brian Ruley <[email protected]>
2026-06-26board: toradex: add initial support for aquila imx95Franz Schnyder
Add initial U-Boot support for Aquila iMX95 SoM. Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95 Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit Signed-off-by: Franz Schnyder <[email protected]> Reviewed-by: Francesco Dolcini <[email protected]>
2026-06-26mx6sabre: Move environment variables to .env filesAristo Chen
Move the shared environment from CFG_EXTRA_ENV_SETTINGS in mx6sabre_common.h to a common text environment fragment in include/env/nxp/mx6sabre_common.env. The mx6sabresd and mx6sabreauto board environments include this fragment and add their own console setting, which is the only board specific difference between them. The eMMC firmware update variables remain guarded by CONFIG_SUPPORT_EMMC_BOOT inside the fragment. The now unused CONSOLE_DEV defines and the linux/stringify.h include are dropped. The generated default environment is unchanged for both boards. This was verified by comparing the output of scripts/get_default_envs.sh before and after the change, which produced identical results. Signed-off-by: Aristo Chen <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2026-06-26mx6ullevk: Move environment variables to .env fileAristo Chen
Move the board environment from CFG_EXTRA_ENV_SETTINGS in the config header to board/nxp/mx6ullevk/mx6ullevk.env for better maintainability. The file is named after CONFIG_SYS_BOARD so it is selected automatically without setting CONFIG_ENV_SOURCE_FILE. Drop the now unused linux/stringify.h include. The generated default environment is unchanged. This was verified by comparing the output of scripts/get_default_envs.sh before and after the change, which produced identical results. Signed-off-by: Aristo Chen <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2026-06-26mx7ulp_evk: Move environment variables to .env fileAristo Chen
Move the board environment from CFG_EXTRA_ENV_SETTINGS in the config header to board/nxp/mx7ulp_evk/mx7ulp_evk.env for better maintainability. The file is named after CONFIG_SYS_BOARD so it is selected automatically without setting CONFIG_ENV_SOURCE_FILE. The generated default environment is unchanged. This was verified by comparing the output of scripts/get_default_envs.sh before and after the change, which produced identical results. Signed-off-by: Aristo Chen <[email protected]> Reviewed-by: Peng Fan <[email protected]>
2026-06-24treewide: move bi_dram[] from bd to gdIlias Apalodimas
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. Reviewed-by: Anshul Dalal <[email protected]> Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385 Tested-by: Anshul Dalal <[email protected]> Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]> Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
2026-06-24arm: mediatek: mt7988: fix gd->bd->bi_dram[0].sizeDavid Lechner
Use board_get_usable_ram_top() instead of get_effective_memsize() to set gd->ram_top to something <= 4GiB. Both board_get_usable_ram_top() and get_effective_memsize() are used to set gd->ram_top in setup_dest_addr(). However, get_effective_memsize() also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is undesirable. Prior to commit bddd6bbef3dc ("arm: mediatek: mt7988: drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in a board-specific dram_init_banksize() implementation. When that was removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong value because of CFG_MAX_MEM_MAPPED. Rather than continue to use an old-style CFG_ option and the potentially confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see which order the functions that set it are called), we can just use board_get_usable_ram_top() to set gd->ram_top to the correct value instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek ARM SoCs. The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed. The config header and Kconfig option are also removed since that was the last CFG_ option. Reported-by: Rudy Andram <[email protected]> Closes: https://lore.kernel.org/u-boot/[email protected]/ Fixes: bddd6bbef3dc ("arm: mediatek: mt7988: drop dram_init_banksize()") Link: https://patch.msgid.link/[email protected] Signed-off-by: David Lechner <[email protected]>
2026-06-24arm: mediatek: mt7987: fix gd->bd->bi_dram[0].sizeDavid Lechner
Use board_get_usable_ram_top() instead of get_effective_memsize() to set gd->ram_top to something <= 4GiB. Both board_get_usable_ram_top() and get_effective_memsize() are used to set gd->ram_top in setup_dest_addr(). However, get_effective_memsize() also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is undesirable. Prior to commit 56183fb025c2 ("arm: mediatek: mt7987: drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in a board-specific dram_init_banksize() implementation. When that was removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong value because of CFG_MAX_MEM_MAPPED. Rather than continue to use an old-style CFG_ option and the potentially confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see which order the functions that set it are called), we can just use board_get_usable_ram_top() to set gd->ram_top to the correct value instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek ARM SoCs. On mt7987, there is already an implementation of board_get_usable_ram_top() for other reasons, so it is modified to also limit ram_top to 4GiB (mt7987 is currently the only thing that sets CONFIG_MTK_TZ_MOVABLE=y so it is safe to change this here without unintentional side-effects). The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed. The config header and Kconfig option are also removed since that was the last CFG_ option. Fixes: 56183fb025c2 ("arm: mediatek: mt7987: drop dram_init_banksize()") Link: https://patch.msgid.link/[email protected] Signed-off-by: David Lechner <[email protected]>
2026-06-23global_data: fix type for gd_malloc_ptr()Alexander Stein
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 <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2026-06-23net: lwip: introduce net_lwip_eth_stop() functionDavid Lechner
Add a introduce net_lwip_eth_stop() function and use that to stop the network interface after each command that uses the network. This makes the behavior the same as the legacy net code and avoids potential issues with the network interface being left in an active state after a command finishes. The start/stop is reference-counted since there is at least one command (dhcp) that calls another command (tftp) to avoid starting and stopping the network interface multiple times in a single command. Signed-off-by: David Lechner <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>
2026-06-22Merge tag 'v2026.07-rc5' into nextTom Rini
Prepare v2026.07-rc5
2026-06-21bootdev: fix typosDenis Mukhin
Signed-off-by: Denis Mukhin <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2026-06-17Merge patch series "arm: omap: Add back omap4 support"Tom Rini
Bastien Curutchet <[email protected]> says: 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 Link: https://lore.kernel.org/r/[email protected]
2026-06-17configs: omap4: remove unused boot target devicesBastien Curutchet
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 Signed-off-by: Bastien Curutchet <[email protected]>
2026-06-16arm: dts: renesas: Enable DBSC5 on R-Car R8A78000 X5H Cortex-M33 RSIP portMarek Vasut
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 <[email protected]>
2026-06-16ram: renesas: dbsc5: Add Renesas R-Car Gen5 DBSC5 driverMarek Vasut
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 <[email protected]>
2026-06-15Merge patch series "various memory related fixups"Tom Rini
[email protected] <[email protected]> says: From: Randolph Sapp <[email protected]> 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. [1] https://lore.kernel.org/all/[email protected]/ [2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2 Link: https://lore.kernel.org/r/[email protected]
2026-06-15memory: reserve from start_addr_sp to initial_relocaddrRandolph Sapp
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. Signed-off-by: Randolph Sapp <[email protected]> Reviewed-by: Simon Glass <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]>
2026-06-15boot: image-fdt: free old dtb reservationsRandolph Sapp
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 <[email protected]> Acked-by: Ilias Apalodimas <[email protected]> Reviewed-by: Simon Glass <[email protected]> Fixes: tag with a 12-char hash: Fixes: 5a6aa7d59133 ("boot: fdt: Handle already reserved memory in
2026-06-12include: configs: am335x_evm: Enable vidconsoleMarkus Schneider-Pargmann (TI)
Enable vidconsole for the am335x-evm board. Reviewed-by: Kory Maincent <[email protected]> Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
2026-06-11Merge patch series "This series introduces initial U-Boot support for ↵Tom Rini
mach-axiado AX3005 SCM3005 board, a quad-core ARM Cortex-A53 (ARMv8/ARM64) platform." Siu Ming Tong <[email protected]> says: Patch 1 adds the device tree files: an SoC-level DTSI describing GIC-v3, Cadence/Zynq UART, a fixed reference clock, and spin-table secondary CPU boot, plus a board-level DTS setting the console to uart3 at 115200 baud with 2 GB DRAM at 0x80000000. Patch 2 adds mach-axiado to support Axiado SoC-based boards, Kconfig plumbing (AXIADO_AX3005 and TARGET_SCM3005), defconfig, board source with ft_board_setup() and a MAINTAINERS entry. Tested on SCM3005 EVK hardware Link: https://lore.kernel.org/r/[email protected]
2026-06-10grm: axiado: Add AX3005 based SCM3005 board supportSiu Ming Tong
Introduce mach-axiado to support Axiado SoC-based boards. This adds the platform Kconfig and build infrastructure, along with initial SCM3005 board support using the AX3005 SoC. Introduces AXIADO_AX3005, which selects ARM64, driver model, GIC-v3, and Zynq UART. TARGET_SCM3005 selects ARCH_AXIADO, allowing future SoC variants to share the platform configuration. Secondary cores use spin-table boot. ft_board_setup() corrects the cpu-release-addr in the FDT, which arch_fixup_fdt() overwrites with the post-relocation address. Add U-Boot board support for the Axiado AX3005 based targets, a quad-core ARM Cortex-A53 (ARMv8) platform. Tested-by: Siu Ming Tong <[email protected]> Signed-off-by: Karthikeyan Mitran <[email protected]> Signed-off-by: Siu Ming Tong <[email protected]>
2026-06-10treewide: prefer __func__ over __FUNCTION__ and __PRETTY_FUNCTION__Aristo Chen
__FUNCTION__ and __PRETTY_FUNCTION__ are gcc extensions that predate the C99 __func__ identifier. scripts/checkpatch.pl emits a warning for any new use of __FUNCTION__ and recommends __func__ instead. In C (unlike C++) __PRETTY_FUNCTION__ is identical to __func__ because C function names do not carry signature information, so the distinction has no behavioural effect here. The majority of the tree already uses __func__, but a handful of older files in arch/, board/, boot/, drivers/, examples/ and include/ still carry the gcc spellings (55 occurrences of __FUNCTION__ across 19 files plus one __PRETTY_FUNCTION__ in drivers/usb/musb-new/omap2430.c). Convert them all to the C99 form so the tree is consistent and new patches in these areas do not have to follow an outdated local style. Ten "Unnecessary ftrace-like logging - prefer using ftrace" warnings remain on the printf("%s\n", __func__) and dbg("%s\n", __func__) function-entry traces in drivers/net/rtl8169.c (behind DEBUG_RTL8169* preprocessor guards) and drivers/usb/host/ohci-hcd.c. checkpatch matches the literal "%s\n", __func__ shape regardless of the wrapper, so silencing those warnings would require changing the debug message text or removing the traces entirely. Signed-off-by: Aristo Chen <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2026-06-10board: freebox: add Nodebox 10G board supportVincent Jardin
Add board support for the Freebox Nodebox 10G based on the Marvell Armada 8040 SoC. This board features: - Quad-core ARMv8 AP806 with dual CP110 companions - eMMC storage via Xenon SDHCI controller - 1G SGMII Ethernet on CP0 lane 5 - I2C buses for peripheral access - NS16550 UART console at 115200 baud The implementation includes: - Device tree for the Nodebox 10G hardware - Dedicated board directory (board/freebox/nbx10g/) - Board-specific Kconfig and defconfig The U-Boot comphy bindings (phy-type/phy-speed) differ from the mainline Linux PHY framework bindings used by phy-mvebu-cp110-comphy, so U-Boot and the kernel each have their own device tree. Signed-off-by: Vincent Jardin <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2026-06-10arm: mvebu: Add Allied Telesis x220Chris Packham
Add the Allied Telesis x220 board. There are a number of other variants with the same CPU block that are sold under some different brand names but the x220 was first. The x220 uses the AlleyCat3 switch chip with integrated ARMv7 CPU. Because of this it is reliant on a binary blob for the DDR training. In upstream u-boot this is replaced by an empty file. Signed-off-by: Chris Packham <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2026-06-08Merge tag 'v2026.07-rc4' into nextTom Rini
Prepare v2026.07-rc4
2026-06-08rockchip: Switch rk3229 boards to upstream devicetreeJohan Jonker
Switch rk3229 boards to upstream devicetree. Signed-off-by: Johan Jonker <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2026-06-08rockchip: Switch rk3128 boards to upstream devicetreeJohan Jonker
Switch rk3128 boards to upstream devicetree. Signed-off-by: Johan Jonker <[email protected]> Reviewed-by: Kever Yang <[email protected]>