u-boot.git/configs, branch master

Merge tag 'u-boot-rockchip-2026.10-20260710' of https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip

2026-07-10T16:04:04Z

CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip/-/pipelines/597 - Add new rockchip custodian, - Remove inactive rockchip custodian, - Preemptively fix rk3528/rk356x DTS issue that will come with 7.1 upstream DTS sync, - Fix typo in doc, - Fix variable used before being set in rockchip_nfc, - Fix asm-operand-widths clang warning for RK3528, RK3576 and RK3588, - Work around HW undefined state for NVMEs on RK3588 Jaguar, - Added support for new devices: - LinkEase EasePi R1 - 9Tripod X3568 v4

board: rockchip: Add support for 9Tripod X3568 v4

2026-07-10T08:52:20Z

The 9Tripod X3568 v4 is an RK3568-based SBC, just like the RK3568-EVB. It always uses soldered connections between the X3568CV2/X3568CV3/X3568CV4 core board and the X3568bv4 I/O board. The differences between the core boards - PCB size, layout - CPU (RK3568B2/RK3568J) - Memory type (DDR4/LPDDR4/LPDDR4X) and size - eMMC size - DSI/EDP resistor values Although the components vary, they maintain full compatibility. The X3568 board has multiple hardware revisions, and we currently support v4 (I/O board). Specification: - SoC: RockChip RK3568 ARM64 (4 cores) - eMMC: 16-128 GB - RAM: 2-16 GB - Power: DC 12V 2A - Ethernet: 2x YT8521SC RGMII (10/100/1000 Mbps) - Wireless radio: 802.11b/g/n/ac/ax dual-band - LED: Power: AlwaysOn User: GPIO - Button: VOL+: SARADC/0 <35k µV> VOL-: SARADC/0 <450k µV> Power/Reset: PMIC RK809 - CAN CAN/1: 4-pin (PH 2.0) - PWM PWM/4: Backlight DSI/0 DSI/1 PWM/7: IR Receiver [may not install] - UART: UART/2: Debug TTL - 1500000 8N1 (1.25mm) UART/3: TTL (PH 2.0) UART/4: TTL (PH 2.0) UART/8: AP6275S Bluetooth UART/9: TTL (PH 2.0) - I2C: I2C/0: PMIC RK809 I2C/1: Touchscreen DSI/0 DSI/1 I2C/4: Camera I2C/5: RTC@51 PCF8563 - I2S: I2S/0: miniHDMI Sound I2S/1: RK809 Audio Codec I2S/3: AP6275S Bluetooth Sound - SDMMC: SDMMC/0: microSD (TF) slot SDMMC/2: AP6275S SDIO WiFi card - Camera: 1x CSI - Video: miniHDMI / DSI0 (MIPI/LVDS) / DSI1 (MIPI/EDP) - Audio: miniHDMI / MIC on-board / Speaker / SPDIF / 3.5mm Headphones / AP6275S Bluetooth - USB: USB 2.0 HOST x2 USB 2.0 HOST x3 (4-pin) USB 2.0 OTG x1 (shared with USB 3.0 OTG/HOST) [slot may not install] USB 3.0 HOST x1 USB 3.0 OTG/HOST x1 - SATA: 1x SATA 3.0 with Power/4-pin [slot may not install] - PCIe: 1x PCIe 3.0 x2 (x4 connector) [power/clock/slot may not install] Link: - https://appletsapi.52solution.com/media/X3568V4%E5%BC%80%E5%8F%91%E6%9D%BF%E7%A1%AC%E4%BB%B6%E6%89%8B%E5%86%8C.pdf - https://blog.gov.cooking/archives/research-ninetripod-x3568-v4-and-flash.html Signed-off-by: Coia Prant Reviewed-by: Quentin Schulz Link: https://patch.msgid.link/20260709185101.2149485-1-coiaprant@gmail.com Signed-off-by: Quentin Schulz

rockchip: rk3568: Add support for LinkEase EasePi R1

2026-07-09T18:11:03Z

LinkEase EasePi R1 [1] is a high-performance mini router. Specification: - Rockchip RK3568 - 2GB/4GB LPDDR4 RAM - 16GB on-board eMMC - 1x M.2 key for 2280 NVMe (PCIe 3.0) - 1x USB 3.0 Type-A - 1x USB 2.0 Type-C (for USB flashing) - 2x 1000 Base-T (native, RTL8211F) - 2x 2500 Base-T (PCIe, RTL8125B) - 1x HDMI 2.0 Output - 12v DC Jack - 1x Power key connected to PMIC - 2x LEDs (one static power supplied, one GPIO controlled) [1] https://doc.linkease.com/zh/guide/easepi-r1/hardware.html Signed-off-by: Liangbin Lian Link: https://patch.msgid.link/20260625125818.18914-2-jjm2473@gmail.com Signed-off-by: Quentin Schulz

Merge patch series "pinctrl: add support of Airoha SoCs"

2026-07-08T19:42:17Z

Mikhail Kshevetskiy 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/20260703115627.2317120-1-mikhail.kshevetskiy@iopsys.eu

configs: airoha: en7523: enable pinctrl/gpio support

2026-07-08T19:29:18Z

This enables EN7523 pin controller and gpio driver. Defconfig was minimized with 'make savedefconfig'. Signed-off-by: Mikhail Kshevetskiy Reviewed-by: David Lechner

configs: airoha: an7581: enable pinctrl/gpio support

2026-07-08T19:29:18Z

This enables AN7581 pin controller and gpio driver. Defconfig was minimized with 'make savedefconfig'. Signed-off-by: Mikhail Kshevetskiy Reviewed-by: David Lechner

Merge branch 'next'

2026-07-07T00:26:12Z

ls1028ardb: Move environment variables to .env file

2026-07-06T01:58:58Z

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 Signed-off-by: Peng Fan

drivers: sysreset: revert support for args in request

2026-07-03T19:45:58Z

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/77ff0f56-5c3b-42e7-bdd1-bf90296da900@linaro.org/ Acked-by: Casey Connolly Signed-off-by: Quentin Schulz

Merge patch series "arm: aspeed: add initial AST2700 SoC support"

2026-06-29T21:29:56Z

Ryan Chen 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/20260612-ast2700_clk-v4-0-9bea29cfdc39@aspeedtech.com