| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
mt7623: revive Banana Pi R2 (u-boot 2026.07, kernel 6.18 + edge 7.1) Bring the MT7623n Banana Pi R2 back onto the current Armbian toolchain and mainline kernels, dormant since the 2024 CSC bring-up. u-boot / boot: - bump boot sources to v2026.07 (mainline) and rebase the board's enable-boot-from-ext4 patch onto it (defconfig tail + mt7623.h env). - eMMC boot is a known limitation: modern mainline u-boot boots from SD but hangs in early board_init_f on eMMC. v2024.07 and v2026.07 fail identically while only the old vendor u-boot ever booted eMMC, so it's a toolchain/ build-env difference, not a u-boot regression. SD is the supported path. kernel: - current -> 6.18 (was 6.6); add a new edge -> 7.1 target. - enable CONFIG_PINCTRL_MT2701: the mt7623 pinctrl DT node binds this driver; without it the board hangs after "clk: Disabling unused clocks". networking: - drop the pre-baked bridge/br0 preconfig; let users configure the DSA switch. - match bare 'wan'/'lan' DSA port names (not just wanX/lanX) in the default networkd netplan so the switch ports get DHCP out of the box. Verified on hardware: wan + lan0 both lease, routable, gateway/internet/DNS ok. board: - add current+edge targets and adopt igorpecovnik as maintainer. Signed-off-by: Igor Pecovnik <igor@armbian.com> | 19 天前 | |
Add board: EASY EAI Nano RV1126 | 1 个月前 | |
u-boot: v2026.07: update board_helios4 btrfs zstd copy to short-extent fix helios4 pins BOOTPATCHDIR=v2026.07/board_helios4 (mvebu-helios4.inc) and applies only that directory, so its copy of general-fix-btrfs-zstd-decompression.patch shadows the shared v2026.07 one. The board copy was created by 98de73533 (move to v2026.07) before the short-extent fix 70c5d7458 landed in the shared copy, so helios4 kept the old "ret < dlen -> -1" check and never received the fix. Sync it to the short-extent version; same rationale as the v2026.04 pool change in this PR. Build-verified (helios4 edge, armhf). Assisted-by: Claude:claude-opus-4.8 | 1 个月前 | |
helios64: bump u-boot v2026.04 -> v2026.07 Switch BOOTBRANCH/BOOTPATCHDIR to the v2026.07 tag and adapt the self-contained helios64 patch set: - drop 1000-exception-include-string.patch: upstream carries the same fix since 8f83a459667 ("cmd/exception: missing include string.h") - refresh hunk context of 1001-helios64-enable-target.patch and cmd-fileenv-read-string-from-file-into-env.patch (line offsets and the "if NET" guard after the CMD_XXD block in cmd/Kconfig); the added lines are unchanged - general-fix-btrfs-zstd-decompression.patch and the overlay files (defconfig, board/, include/configs, u-boot.dtsi, upstream dts) apply unchanged All patches apply to v2026.07 with zero fuzz and zero offset. Assisted-by: Claude:claude-fable-5.1 | 3 天前 | |
khadas-vim3l: u-boot: bump to v2026.07 + fancy - move dt/u-boot-dt/defconfig/boot-order-patch (as-is) - fancy: LwIP, mbedTLS, wget | 7 天前 | |
Introduce RK3562 family and KICKPI K3B | 2 天前 | |
Add board: EmbedFire LubanCat 4 (RK3588S) Community supported config for the EmbedFire LubanCat 4 SBC, rockchip-rk3588 family, mainline U-Boot and mainline kernel: - config/boards/lubancat-4.csc: modeled after lubancat-5io, mainline U-Boot v2026.04 via binman (tpl-blob-atf-mainline scenario), KERNEL_TARGET current,edge - patch/u-boot/v2026.04/board_lubancat-4: add board to mainline U-Boot v2026.04 (defconfig, -u-boot.dtsi and device tree; derived from ROCK 5A and verified against the EBF410116V1R2 schematic) - patch/kernel/archive/rockchip64-{6.18,7.1,7.2}/dt: ship mainline device tree rk3588s-lubancat-4.dts, merged upstream with Linux 7.3 (commit 6d9430d58714, "arm64: dts: rockchip: Add EmbedFire LubanCat 4 board"); label references verified against all three kernel versions. Obsolete once these branches reach 7.3. Verified on hardware with rockchip64 edge (7.1) and U-Boot v2026.04: boot from eMMC and SD card, Gigabit Ethernet, UART2 debug console. | 17 天前 | |
luckfox-rk3308b-nova: bump U-Boot to v2026.07-rc4 The board was merged on U-Boot v2025.04. Move it to v2026.07-rc4. Two of the six board patches - the dw_mmc fixes dwmci_control_clken() CDONE acknowledge and dwmci_setup_bus() same-frequency skip - have since landed upstream, so drop them. The remaining four (board defconfig/DTS, the evb_rk3308 download-key saradc device-name fix, the 1-bit DT bus-width honoring, and RockUSB-on-download-key) apply cleanly to v2026.07-rc4. Tested on hardware: SPL -> U-Boot v2026.07-rc4 boots and brings up both the current (6.18) and edge (7.1) kernels; the SARADC recovery key and RockUSB download mode both work. Signed-off-by: crackerjacques <jack@supremeoverlordjabs.co> | 2 个月前 | |
odroidhc4: u-boot: bump to v2026.07, drop upstreamed patch | 1 个月前 | |
odroidn2: bump u-boot to v2026.07 (#10630) * odroidn2: move u-boot board patches v2026.04 -> v2026.07 Pure rename, no content changes; prepares the bump of odroidn2 to u-boot tag:v2026.07. The v2026.04 patch pool stays for other boards. * odroidn2: bump u-boot to tag:v2026.07 Move ODROID-N2/N2+ from v2026.04 to the v2026.07 release. Board patches (meson_gx_mmc f_max cap to 24 MHz, USB/NVMe/SCSI-first boot order) apply cleanly to v2026.07; the f_max cap is still required since upstream keeps 40 MHz. The shared v2026.07 pool already carries the btrfs zstd decompression fix and cmd-fileenv. | 5 天前 | |
Qidi X6: update to u-boot 2026.07 | 1 个月前 | |
radxa-e24c: u-boot: rework u-boot v2026.07 for Radxa E24C - use mainline u-boot for both vendor and mainline BRANCH'es - as the vendor u-boot really doesn't work - vendor u-boot won't bringup `ppll` clock unless NVMe is present - make fancy u-boot, with flashing leds in preboot, lwip, mbedtls, etc - fix family to rk35xx as it's not a 3588 - drop `ROCKCHIP_MASKROM_IMAGE` and `u-boot-rockchip-usb471.bin` et al as that is now handled by EXT=rkusboot - set SRC_CMDLINE for use with extlinux/EXT=u-boot-menu - use newer blobs | 27 天前 | |
rockpi-4a: bump u-boot to v2026.07 with btrfs root and working SPI (#10260) * rockpi-4a: bump u-boot to v2026.07 v2026.07 gains upstream btrfs support in u-boot, enabling a btrfs root to boot. The board uses the binman-atf-mainline scenario and the uboot-btrfs extension (as both Helios boards do) to build CONFIG_CMD_BTRFS into u-boot. * rockpi-4a: package binman SPI image instead of rkspi_loader.img v2026.07 rock-pi-4-rk3399_defconfig sets CONFIG_SYS_SPI_U_BOOT_OFFS=0xE0000, while the generic rockchip64 rkspi_loader.img places u-boot.itb at 0x60000 - SPL would never find the FIT. Ship binman's ready-made u-boot-rockchip-spi.bin instead and skip the generic SPI postprocess; the family write_uboot_platform and write_uboot_platform_mtd already handle u-boot-rockchip[-spi].bin. * rockpi-4a: cap SPI NOR frequency to a usable rate The upstream device trees declare spi-max-frequency = <108000000> for the SPI NOR (kernel commit fa16d7a820e4). The XT25F32 on this board cannot sustain it. In u-boot the rate is programmed verbatim and the JEDEC id reads back as ff ff ff - the chip is not detected. The u-boot overlay caps it to 24 MHz, where sf probe reports 'Detected xt25f32' and reads are byte-stable. In Linux the Rockchip SPI controller (GPLL/16 = 37.125 MHz input) clamps 108 to 50 MHz and divides by /2 = 18.56 MHz, where bulk transfers corrupt: the JEDEC id read still succeeds (an mtd device appears) but flashcp fails verification, so writing a bootloader to SPI is unreliable. The kernel DT is restored to the pre-fa16d7a 10 MHz, selecting /4 = 9.28 MHz, which is stable. Hardware-verified on ROCK Pi 4A (edge, kernel 7.1): with both caps, flashcp writes and verifies the u-boot SPI image (RC=0), and the board boots from SPI ('Trying to boot from SPI' -> u-boot 2026.07 -> btrfs root). * rockpi-4a: cap SPI NOR frequency on the current kernel too The edge (7.1) DT cap in 721c386e fixed the SPI regression there, but the current (6.18) kernel still inherits the upstream 108 MHz from fa16d7a820e4. Add the same one-line DTS cap under rockchip64-6.18. Hardware-verified diskless (netboot, NFS root) on 6.18.39, same board and chip (XT25F32), only the DT frequency changed: at 108 MHz an mtd_debug write + read-back mismatches 5/5 with the error offset moving between runs; with the 10 MHz cap it verifies clean 5/5. * rockpi-4a: cap SPI NOR frequency on the rockchip64-7.2 kernel too The rockchip64-7.2 device tree still inherits the 108 MHz spi-max-frequency from fa16d7a820e4, same as 6.18 and 7.1. Without the cap here the SPI NOR regression returns as soon as the board's edge target advances from 7.1 to 7.2, and the fix is silently lost. Add the identical 10 MHz cap so it carries forward. The patch is byte-identical to the 6.18 and 7.1 versions and applies cleanly to the current rockchip64-7.2 source (arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts). --------- Signed-off-by: Igor Velkov <325961+iav@users.noreply.github.com> | 1 个月前 | |
youyeetoo-yy3568: switch to mainline U-Boot v2026.07 | 1 个月前 | |
Revert "aml-c400-plus: migrate to modern U-Boot v2026.07 and improve boot chain" This reverts commit 0ce56fc9bbe4d459ec3341f31c472a9e2d5db52a. Signed-off-by: Igor Pecovnik <igor@armbian.com> | 2 天前 | |
Revert "aml-c400-plus: migrate to modern U-Boot v2026.07 and improve boot chain" This reverts commit 0ce56fc9bbe4d459ec3341f31c472a9e2d5db52a. Signed-off-by: Igor Pecovnik <igor@armbian.com> | 2 天前 | |
mixtile-core3588e: u-boot: bump to v2026.07 + fancy - `1001-fdt_fixup_ethernet-add-logs.patch` is already in v2026.07's root, just drop - move dt/u-boot-dt/defconfig (as-is) - drop ramboot/471/472 bins as it's handled by `EXT=rkusboot` now - fancy: LwIP, mbedTLS, wget | 7 天前 | |
Revert "aml-c400-plus: migrate to modern U-Boot v2026.07 and improve boot chain" This reverts commit 0ce56fc9bbe4d459ec3341f31c472a9e2d5db52a. Signed-off-by: Igor Pecovnik <igor@armbian.com> | 2 天前 | |
odroidm1: bump u-boot to v2026.07 Move odroidm1 from the v2026.01 rockchip u-boot pool to v2026.07, picking up newer u-boot (incl. rk3568 "include all addressable DRAM in memory map" and refreshed upstream DTS). odroidm1 rides the shared tag pool (no board_odroidm1 dir; all board config is done via hooks in the board file). The v2026.07 pool already carries cmd-fileenv (odroidm1 enables CONFIG_CMD_FILEENV) but lacked two patches odroidm1 needs, carried forward from the v2026.01 pool: - the btrfs zstd-decompression fix (odroidm1 enables CONFIG_CMD_BTRFS and boots zstd-compressed btrfs); - the PCIe cold-boot LTSSM retry bump (10 -> 25), without which NVMe may fail to enumerate on a cold boot on rk3568/rk3588. Both only touch code paths their boards exercise; a no-op for pool boards that read neither btrfs nor PCIe. u-boot patching: 5 total, 5 applied, 0 with problems; package builds clean (linux-u-boot-odroidm1-edge 2026.07). Assisted-by: Claude:claude-opus-4.8 | 1 个月前 | |
u-boot: v2026.07: prepare patching folder for v2026.07 | 2 个月前 | |
u-boot: v2026.07: prepare patching folder for v2026.07 | 2 个月前 | |
u-boot: v2026.07: fix btrfs zstd short-extent decompression The carried-forward zstd decompression fix rejected any frame that decompressed to fewer bytes than the destination (ram_bytes), returning -1 instead of the actual length. BTRFS stores short files with a zero-padded tail; decompress_zlib() and decompress_lzo() return the real short length and let the read path zero-fill the remainder. Match that: error only on a real zstd error, cap the result at dlen (never copy sector padding past ram_bytes out of the temp buffer), and return the actual decompressed length. This diverges the v2026.07 copy from the v2026.04 pool copy; the same fix should be backported there. Assisted-by: Claude:claude-fable-5 | 1 个月前 | |
u-boot: v2026.07: prepare patching folder for v2026.07 | 2 个月前 | |
u-boot/rk3588: carry the SCMI CPU clock raise into v2026.07 The clusters still come out of reset on the 24 MHz oscillator in v2026.07, so boards moved to that tag (turing-rk1, nanopct6, mekotronics-r58x-pro) crawl through early boot again. The v2026.04 patch applies with a two line offset, so copy it over unchanged. Signed-off-by: SuperKali <hello@superkali.me> | 13 天前 | |
recomputer-rk3576-devkit: edge: u-boot: full mainline u-boot with DT/defconfig +fancy - `.dts` is copy from rockchip64-7.1 - except for pwm-related stuff, which is not even in mainline Linux, much less u-boot - `recomputer-rk3576_defconfig` is similar to other rk3576 boards, except: - enable all/most SPI Flash drivers - disable UFS support - enable PCA953X driver (so LEDs/USB can be GPIO'ed via the extender) - enable FUSB302 driver - `-u-boot.dtsi` just pulls in the generic dtsi + sfc0/flash0 bootph - v2026.07 top-level patch to add support for `Zbit ZB25LQ128` flash chip - stores environment in SPI at offset 0xc00000 size 0x20000 - fw_printenv/fw_setenv userspace vs SPI environment - preboot flashes R/G/B LED (tri-color user LED) - use updated DDR/BL31 rkbin blobs for mainline u-boot | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 19 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 3 天前 | ||
| 7 天前 | ||
| 2 天前 | ||
| 17 天前 | ||
| 2 个月前 | ||
| 1 个月前 | ||
| 5 天前 | ||
| 1 个月前 | ||
| 27 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 2 天前 | ||
| 2 天前 | ||
| 7 天前 | ||
| 2 天前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 13 天前 | ||
| 1 个月前 |