I started down this path and realized that the patches are applied to downloaded linux kernel source. Normally, the kernel source is "cleaned" even if the build fails. I then found the sakura pi github page and the page has more recent commit than the Rock-s0, incorporates the kernel.dtsi while adhering the the u-boot requirements for rockpi's. U-boot for Rockpi. I'd like to base my build on the more up-to-date code. The easist way to do this is set CLEAN_LEVEL="" but I'm running into issues with the patches in GitHub: Sakura-Pi failing to apply. Essentially, I would iike to have the patches apply, not necessarily build and have the files generated by the patches remain. I have a large dtb file, extracted from Sovol's OEM firmware, that I would like to copy/paste into the generated *.dtb file, rename the *csc file and the defconfig file, and then generate a patch against clean source. Conceptually, this should work and I'm suprised it is this difficult to generate a new board for an existing family. Alternatively, a script could generate a file from a highlited portion of a patch and generate a file. Or is is possbile to run ./compile.sh a step at a time? It would be helpful in this setting, very instructive about the process and would narrow down build failures. Am I on the right path? Any step-by-step examples and or links to helpful scripts?

As champions of open source development in the embedded community, Collabora will be at Booth 4-404 with an impressive lineup of live demonstrations spanning graphics, machine learning, continuous testing, and real-world applications. View the full article

Hi, would this image work on x96q?

I have to be upfront: I'm not a developer. I'm an ops/observability engineer who knows how to use software to get things done. I know a bit of Go — not much — and I have no formal background in software design. What I do know is what I need, and what was missing. So I built it. Take the code with that in mind. The problem I run a Kobol Helios64 as my home NAS — a five-bay ARM board that's been sitting in a sweet spot between "serious hardware" and "abandoned by its software ecosystem." I tried the usual NAS UIs. They were either too heavy, too opinionated about owning the underlying OS, or simply unmaintained. None of them gave me a clean window into my ZFS pools without dragging in a container runtime, a Node.js server, or a Python daemon alongside them. I wanted something simple: observe and manage my storage from a browser, on a machine that stays close to a vanilla Armbian or FreeBSD install. No agents, no frameworks, no surprises. What I built dumpstore — a lightweight ZFS management UI written in Go. link: https://github.com/langerma/dumpstore It's a single compiled binary with a bunge of html/js/css/ansible playbooks. No database. No Node. No container runtime. Ansible handles writes (dataset creation, snapshots, user/group management, ACLs) Current features: Pool overview — health, usage, vdev tree, fragmentation Live I/O statistics per pool (SSE-pushed, no polling) S.M.A.R.T. data per disk — temperature, power-on hours, reallocated sectors Dataset browser — collapsible tree, compression, quota, mountpoint Dataset create / edit / delete Snapshot management — list, create (recursive), delete User & group management — create, edit, delete; system users protected ACL management — POSIX and NFSv4, recursive apply supported Prometheus /metrics endpoint (because of course) Runs on Linux (systemd) and FreeBSD (rc.d) Builds with make build && sudo make install — that's it What it is not: a full TrueNAS replacement. SMB/NFS share management, a file browser, and ZFS send/receive are on the roadmap — but I'm building deliberately, one thing at a time. Why Armbian specifically The Helios64 is the reason this exists. If you're running Armbian on a Helios64, an older ARM server, or any ZFS box where you care about what's actually installed — this was built for you. Feedback welcome Since I'm not a developer by trade, I'm sure there are things I've done in a way that makes experienced Go or software folks cringe. Issues, PRs, and honest feedback are very welcome. The code is small enough to be auditable — main.go plus a handful of internal packages. Markus Langer

Thank you very much. Unfortunately, Trixie won't start. BootROM - 1.73 Booting from MMC BootROM: Bad header at offset 00000200 … BootROM: Bad header at offset 02E00000 BootROM: Bad h Trying Uart