rpardini

I've had great success with the new 6.1-rcX based images. Applying mmind's tree for the DTS only. Good chance we'll be able to merge this board with the rest of rockchip64 around the 6.2 timeframe, with zero patches if that DTS is merged. Keep in mind these images don't use Petitboot "the kexec stuff" itself but does use the u-boot included in SPI (which is part of Petitboot), and require the env to skip petitboot.

No, not all -- I took tobetter's tree from the start, and just stuck with it. I'm not "insisting" on it at all. I'm 100% open to: 1) replace with clean mainline patchset against 6.x (still separate kernel deb from rockchip64) 2) unite with rockchip64, when the rest of it is at 6.1+ too. this would require .config merge too and who knows what else. Don't hesitate to send me an -rc tag number and the patchset / .config and I'll drop it in there asap

Damn it, I can't get even one right. Do not worry, the u-boot building code is still alive in another branch. I just got no time to work it, and it's very messy not ready for release (eg is amd64 only). That said I squashed the rest into 👉 https://github.com/armbian/build/pull/4267 against master 👈 (not armbian-next) -- someone gotta build it and review though. It should even have working overlays... That's great news. Hopefully we can then move the 5.19 edge to current and add 6.1-rcX as edge, with a single patch? that'd be sweet.

IMPORTANT: I have NOT verified skip_spiboot = false can be set from Armbian yet. Caveat emptor!

Very good news about landed patches. Tobetter's posture: shortsighted. He's also contradicting himself, having worked on board DTs for Banana boards. Yeah, here's an edge 5.19 version, which is a snapshot/git format-patch of tobetter's 5.19 at some point, rebased to 5.19.4 and now rolled-forward by armbian to 5.19.12. It does not carry an u-boot anymore, and uses less crazy partitioning. All blobs are from HK's SPI. It now requires the SPI u-boot with skip_spiboot = true, https://wiki.odroid.com/odroid-m1/software/boot_sequence#bypassing_petitboot CLI: https://github.com/rpardini/armbian-release/releases/download/20221007a/Armbian_20221007a-rpardini_Odroidm1_jammy_edge_5.19.14.img.xz 👆☝️

This is most probably a bug on my side. I build with all repos and mirrors disabled (SKIP_ARMBIAN_REPO=yes) so everything is built locally, but clearly I've a bug when you don't have that option. Try with it and let me know... meanwhile I'll try to find and fix the bug.

Hi Nexus. It seems you're trying to build on arm64, but my code is using the u-boot + rkbins from HardKernel, which unfortunately only work on x86 / amd64. Also, you're better off building from "armbian/build" branch "armbian-next' instead of my "extensions" branch, which is very (very!) volatile.

Rock 5b test images, from armbian-next. Using vendor u-boot + patches, and vendor kernel, both straight from radxa's git XFCE desktop with "browsers" app group - https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66_xfce_desktop.img.xz CLI - https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66.img.xz PR: https://github.com/armbian/build/pull/3984 (against master) All work by @amazingfate I just gathered stuff and built images. Thanks to @monkaBlyat @lanefu @piter75 @amazingfate for tests / patches etc

Nope, can't confirm... mentioned image no longer exists... And the VIM3L is hard at work, testing the 5.19-rcX builds!

Yes. GitHub Actions workflow is setup to run everyday at 3am UTC. https://github.com/rpardini/armbian-git-shallow/blob/main/.github/workflows/main-latest.yml#L6 If you look at the GHA logs it is already working, everytime I push a commit but also everyday at 3am by itself: https://github.com/rpardini/armbian-git-shallow/actions 👍 ----- Apart from that, I am still investigating some vendor kernels (HardKernel, but also others) specially in 4.19 series, if I pre-seed the local copy with linux 4.19 shallow bundle, and then pull from that vendor's kernel tree, it comes down a lot (1.5Gb). I suspect that is because the vendor started his kernel Git from somewhere _way_ before 4.19-rc1, and there is a mismatch during git negotiation for the fetch, and ends up pulling a lot. @going I think you also regularly pull from "megous" repository that would be interesting to test too. ------ Another possible problem are developers/users in China which can't get to github.com for downloads. For this case we could publish, in addition to GH Releases, also to some other FTP or rsync that we already have @Igor?

The reference for why this was written: https://github.com/armbian/build/pull/3476#issuecomment-1042063299 (mricon is from the Linux Foundation, who appeared after our CI was banned from kernel.org due to too much shallow fetching) Also https://github.com/armbian/build/pull/3476#issuecomment-1042322996

Thanks for the attention guys. I guess I did not explain this correctly... The shallow_kernel_tree.sh script is run on GitHub Actions (not any user machine, ever), it downloads a lot of stuff (including a 2.4GB bundle, indeed), updates it, massages it into shallow, and publishes the output. The output is here: https://github.com/rpardini/armbian-git-shallow/releases/tag/latest Each kernel version gets a shallow bundle (file) around 250mb each. That output would then (later) be used by armbian/build to seed a kernel tree, downloading from GH CDNs via HTTPS, instead of pulling everything from kernel.org's (or mirrors) git server. After seeding, pulling from the git server is very fast / small download (a few megabytes). That way people or CI servers building Armbian will only download those 250mb + a few. Combining all this allows us to have a small, shallow git tree, that has the tags we need, and can be kept updated cheaply, without ever fetching/cloning it using shallow, and thus does not put any load on the git server.

Hello, I've finally gotten around to writing the GitHub Actions based Linux Kernel Shallow git trees exporter. It's very simple, a single shell script and GHA workflow. It prepares shallow bundle (and ready-to-go .tar too) everyday on a schedule and publishes to GitHub Releases. Please take a look https://github.com/rpardini/armbian-git-shallow - theres a README that shows how to use the bundles outside of Armbian. If this is a good idea, I'd move it to armbian/kernel-git-shallow in GitHub. And then I'd start using those in armbian-next first as a test ground. I mention I few people I know are interested in the subject @Igor and @going but of course everyone welcome to pitch in Thanks (PS: No idea why I'm required to tag a board for this post)

Ok here's a new version, 5.18-rc7 from tobetter's tree. Still very early days. tobetter is doing a fantastic job this time around, keeping his tree rebased properly this time. This version has working NVMe (!), panfrost somewhat works, some hangs when panfrost is used. eMMC does NOT work in my experience, it hangs the machine if trying to use it. use SD card. unzstd, burn to SD, boot either with or without holding the button. (it should NOT go into or through Petitboot either way, instead the SPL in SPI should find and boot uboot in the SD card, or with button boot all blobs from SD). https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst (4.x stuff still does not have HDMI, I've no idea why, it's otherwise stable, but I won't post it here since most people just assume it does not work at all if HDMI does not work)

@Excel I've an image. Unofficial. Unsupported. unzstd it, burn it to SD, put jumper J3 in Maskrom mode, UART at 1500000. https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Tinkerboard_jammy_edge_5.17.9.img.zst (WRONG! That is for the TB1!) UPDATE: https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Tinkerboard-2_jammy_edge_5.17.9.img.zst (correct for the TB2) Good luck! Sorry boss, I've all these images laying around and can't help myself. 😉

Cool stuff, thanks for the explanation. I've similar setup, although I don't use root LVM, and cloud-init meta is in /boot ext4 or /boot/efi (vfat). Partitioning is quite complex intermingled code between partitioning proper, calculating sizes, and setting up filesystems. I've added hooks to be able to "override it all" but haven't had time to make it better composable, much less in bash. But what I was asking about was the your original mention of "docker-shell" or something, for image build? kernel build? I've probably messed that up in -next.

Thanks for testing, I'll test some future build and report back when I'm confident it boots. I messed up some (unrelated to M1) initrd stuff in those builds.

Eh, no idea. Fragments of code handling docker are scattered all over the codebase, and haven't been properly handled yet in armbian-next. (1-line explanation: armbian-next has error control enabled, and command invocations that previously failed and were ignored now make the build stop). Would be great if you could explain the use case for what you're trying to do...

Should be doable, patch dirs are empty so just drop stuff in there. legacy == 4.19 from HK official repo. edge == 5.18-rcX from tobetter's repo. both with vendor u-boot so all moving targets, tobetter has finally taken to rebasing his branch.

Yes. I don't think it's even near being merge-able right now, small bugs but are showstoppers for most people, and I can't handle them all by myself in such timeframe, including handling all the Jammy fixes and a dozen rockchip kernels, extlinux, nand-sata-install, etc. And once merged a whole slew of things will show up (extras buildpkgs, prebuilt, rootfs caching, repo publishing, git bundle stuff, most of the GHA stuff that normal developers hardly ever run). The concepts behind armbian-next are almost fully realized, but the fruits still have to be collected. Otherwise it seems pointless... I will keep it rebased as much as possible, so the effort lives on, only without pressure. Before merge, documentation has to be written too, so that will take a while. work continues!

Don't try too hard. Most things don't make sense. 😉 Find the board file, then the family, and understand the hooks that are in place and when they're called. rpardini/extensions is my work branch. It's a huge mess. Don't waste your time... Everything you need for the M1 is already in armbian/build in branch 'armbian-next'. The ODROID-M1 uboot code is very convoluted right now since I'm using vendor uboot's "make.sh" in addition to Armbian's own. Also a custom partitioning scheme is required, also implemented in a hook in the board file. It can _only_ be built on x86 right now due to vendor's use of amd64-only rkbins there. So right now this is very not standard. If/when this board stabilizes I'll work on making it less messy.

Nah, Jammy has python2, it does not have python-is-python2 gimmick which just symlinks or update-alternatives. I'll have to hack around this manually.

Ahn, ok, this is recent addition for 1 runner that was failing uboot, I thought you meant GIT version. We'll have a hard time without python2 for those old uboots, so it's a symptom of shit to come. But thanks for the catch, I'll fix that ASAP, and probably more when I move builders to Jammy. I still couldn't find time to work on this.

Ok some images are up for testing. Both HKs' 4.19 and tobetter's 5.18-rcX were updated. Maybe something is fixed. Tobetter commits signal support for PCIe. For those who are brave: https://github.com/rpardini/armbian-release/releases/download/20220508d/Armbian_20220508d-rpardini_Odroidm1_jammy_legacy_4.19.219.img.zst (probably no HDMI) https://github.com/rpardini/armbian-release/releases/download/20220508d/Armbian_20220508d-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst (probably no PCIe/SATA/USB3) EDIT: old images removed. Look for later posts for newer ones unzstd them, burn to SD, insert SD, power on. recommend to use UART Have fun @Neo2SHYAlien @Stan Pak @N4IRS @Slartibartfast9536 @Igor