rpardini

There is no TF-A for 3528 yet. Use rkbin. Take a look at radxa-e24c.wip for inspiration. And sincerely: 3528 stuff barely landed. Kwiboo made it clear he still has a whole patchset to send, and that'll take a while to review. Being able to backport his stuff is non-trivial. Maybe just relax and wait for 6.20/7.0? Otherwise, send pull requests on GitHub where it is a bit easier to collaborate, not to mention more people can benefit.

Bump u-boot to 2026.01-rc4. Bump kernel to 6.19-rc1. Read the commits adding it to mainline. Add declare -g BOOTSCRIPT="boot-rockchip64-ttyS0.cmd:boot.cmd" declare -g SERIALCON="ttyS0" to board file.

From https://github.com/armbian/build/pull/5056#issuecomment-1529793978

Yes. We should add `pahole` as a dependency of the linux-headers package, otherwise during headers install, the `.config` is different from the image build, leading to all kinds of sad. While we might fix the future, unfortunately, installing pahole manually (and removing/re-installing the linux-headers package) is the only way forward for versions already out of the door.

Hey @Timo12357 this was identified before. Check https://github.com/armbian/build/pull/5766 Please check against beta/testing repo? Thanks

Thanks for reporting this, should be fixed in https://github.com/armbian/build/pull/5914

Some progress has been made, 6.6-rc5, new alsa-ucm-conf and firmware. Try the "Armbian Trixie - Gnome Desktop" image available at https://www.armbian.com/lenovo-x13s/ under "Other supported variants", that might work: filename is Armbian_23.8.6_Thinkpad-x13s_trixie_sc8280xp_6.6.0-rc5_gnome_desktop

@c0rnelius graciously submitted GitHub PR to upgrade u-boot that effectively removed the patch in question from the equation for the Radxa Zero. While it was nice to "boot USB first", since it enabled a few interesting scenarios (boot non-Armbian EFI OSes in USB disk), it's not worth having it if normal Armbian operation is impacted. I've advocated for this usb-first style to be default around u-boot 2022, but we're now moving to board-specific support (and removing completely in the case of the Zero) for 2023+.

Yeah that. Well, cpufrequtils and big.little clusters don't mix well as you probably noticed. cpufrequtils itself has been deprecated for well over a decade. Since cpufrequtils was being inflicted on otherwise perfectly working, DT-controlled boards, we've disabled it by default. Boards that are proven to require it can re-enable it directly on the board as you've already found out or in the Armbian board file via 'CPUFREQUTILS_ENABLE=true' All that said, the real, kernel-supported alternative, cpupower, requires kernel-tools build which is currently not provided by Armbian (nor is usbipd, perf, nor any other kernel userspace tool, due to the complexities of release-dependent building of parts of kernel which is normally userspace-agnostic).

Sorry what are you talking about? Which board? Why you mention me here? 😉

Please build with `SHARE_LOG=yes` and send us the URL so we can check. That's due to the pd-mapper and qrtr in userspace working. (Only for lunar, coming from ubuntu x13s ppa) Yep it has a hid bind loop that is work-arounded via some udev rules... it's strange. Mostly, yes. I'd say send your patches to steev, or add them to Armbian. Copy the x13s board file and change the DTB. If this works we can refactor/unify more later... Yeah take a look at the x13s board file, you'll find something really similar. I have not kept up to the rapid amount of changes after 6.3.y. I might try to update to 6.6, since that's gonna be LTS.