Jump to content

rpardini

Members
  • Posts

    45
  • Joined

  • Last visited

Everything posted by rpardini

  1. rpardini

    Odroid M1

    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.
  2. rpardini

    Odroid M1

    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.
  3. 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
  4. Nope, can't confirm... mentioned image no longer exists... And the VIM3L is hard at work, testing the 5.19-rcX builds!
  5. 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?
  6. 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
  7. 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.
  8. 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)
  9. rpardini

    Odroid M1

    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)
  10. rpardini

    rpardini

  11. @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. 😉
  12. rpardini

    Odroid M1

    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.
  13. rpardini

    Odroid M1

    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.
  14. rpardini

    Odroid M1

    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...
  15. rpardini

    Odroid M1

    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.
  16. 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!
  17. rpardini

    Odroid M1

    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.
  18. 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.
  19. 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.
  20. rpardini

    Odroid M1

    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
  21. Ok, a weekend later, here's armbian-next v64. https://github.com/armbian/build/commits/armbian-next - do `git pull --rebase` and build away and report problems here 😉 Builds are green. https://github.com/rpardini/armbian-release/actions/runs/2289642908 Images are up for download: https://github.com/rpardini/armbian-release/releases/tag/20220508d (a few novelties there. eg, ODROID-M1) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- No fun in that @Igor😉 -- I've fixed the Makefiles for cubie-i and clearfog u-boot so they build. Those were exactly the same problem as from xu4: 2017/2018 u-boot, that original Makefile wanted "armv5" target which does not exist anymore in newer gccs. https://github.com/armbian/build/commit/0a3fc81b5e519a11ac41c1d196b076a91ce38a1b Most of those boards are actually armv7a, so I patched and they built. If they _work_, we'll only know if some of you download the above images and try it out (cubie, clearfog, odroidxu4 at least). Thanks! Many other changes/fixes and a few breaking ones, like removal of LIB_TAG/.ignore_changes for @lanefu I've not tested desktop building so here's when @Rich Neese comes in, let me know. Thanks for all the tests!
  22. rpardini

    Odroid M1

    I've some images, but they're really quite far from usable right now. Vendor kernel 4.19 I can't get HDMI to work. Everything else works. I'm using it to build Armbian itself and works great with NVMe and the 8gb RAM. Mainline 5.18-rcX has working HDMI, but no NaNeng PHY, so no PCIe/NVMe, no USB3, and no SATA. tobetter is working, also work in quartz64a and other rk3586/8 will benefit this. nand-sata-install will not work with this unless I find a way to flash uboot to SPI (and this remove petitboot, but there is no official petitboot recovery from HK yet) and mainline u-boot is even further away, so little chance of that.
  23. @Igor Hmm this will be a challenge. Are you sure you can't download the bundles, or is some other error? Send me a log file please? I'll find a way, if the bundle can't be downloaded, to revert to fetching from origin, so Google mirror can be used. I guess folks in China and others might need that as well. Also if I ever get around to the gitbundle caching storing in docker layer in GCHR.IO, we could have a workflow that publishes ready-to-go, 300mb gitbundles for each version (5.15 / 5.17 etc) and solve this once and for all. I've thought and studied a lot about this problem, and there' s another possible, although very different, solution: using a single, shared `.git` tree with all remotes and all branches, huge, possibly seeded by bundle, for all kernels, and then for each built kernel, a separate working copy. See https://git-scm.com/docs/git-worktree -- this would be even more complex to manage than already, but would be more efficient when building say more than 2/3 kernels, and much more efficient when building many different versions (eg 4.19 / 5.15 / 5.17). But that is maybe for armbian-next-next. Thanks, will investigate, I am still building in Impish and is somehow working... Those are very interesting. I will investigate. I've small patches to make compatible with newer gcc for some other families, like xu4, so I have hope. Ooops, this was not supposed to be included in armbian-next, was trying to reproduce some boards that used to work 1/2 years ago but no longer boot. I do think BRANCH=classic, generally 5.10.y, is a good idea, but armbian-next is not the place for this. Yeah. I've too many manual merges and at a certain point I lost track. The fact that our docker support uses a "docker" config file that itself re-launches the build inside docker is very confusing. The template-copying style of this is also hard to maintain... At a certain point I thought to rewrite, never did, and merges were sloppy. I will review. My bad. Regarding kernel-drivers.sh, this is one of my main to-do items. I've good progress on 'fasthash' (which is required for kernel-drivers) so this is getting close to doable. Will keep you posted. @balbes150 thanks for your tests and posting the logs. These errors were a bit unrelated and came from master, "nala" package which was added by "desktop" sources, and desktop sources were included in CLI builds in master. Dunno if really intended... Since I rebase irregularly sometimes this was fixed fast in master but -next lagged quite a bit. I've disabled this in armbian-next (sources only added for desktop builds again) but will lead to discussions, since it was already accepted into master, and armbian-next already breaks a lot of other stuff. Those kind of changes are marked *breaking change* in the commits in armbian-next when I can identify them. There's quite a few. ------------------ To all here: thanks a lot for the tests and reporting the problems. I have already started a huge rebase against master, fixing a few things and doing a few CI runs to catch the more obvious problems. Also rebasing showed frozen kernel tags, armbian-next has all that is needed to do that externally now, so also working some long overdue features. Will post when it's pushed!
  24. People, I feel bad about hijacking this thread with armbian-next stuff. Could someone with forum-fu move armbian-next related posts to its own thread? Maybe in a contributor-only forum?
  25. Thanks, a pesky short-circuit bug was leftover in sunxi_common at the end of family_tweaks_bsp. Fixed. Please pull and try again... Will be possible (and default) soon. Real Logs are now produced inside the WORKDIR (in .tmp) in text + ANSI colors format, and during cleanup, processed and aggregated into a single file HTML. This has brought joy to some and hatred to others. Sorry to offend your sensibilities... But do expand on "don't play nice with my tools", which tools? We wanna play nice. Yes. `PRESERVE_WORKDIR=yes` won't cleanup the workdir in .tmp -- this leaves over a gigabyte of stuff but should be safe. Also `PRESERVE_SDCARD_MOUNT=yes` will preserve $SDCARD, $MOUNT (and thus $LOOP) -- take much care in this case, things are left mounted and you can easily shoot yourself in the foot (eg, destroy your host) if use this and is not careful. Other interesting things you might like - `SHOW_LOGS=yes` shows the output of run commands - `SHOW_COMMAND=yes` shows the invocation of each said command Thanks for trying and reporting!
×
×
  • Create New...