Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by rpardini

  1. On 11/2/2022 at 9:03 AM, Shaun Maher said:

    Tamper with the installed image a little before attempting to boot it:

    • mkdir /mnt/nvme0n1p1
    • mount /dev/nvme0n1p1 /mnt/nvme0n1p1
    • rm /mnt/nvme0n1p1/boot/boot.scr (this file existing seems to the petitboot parser segfault)
    • rm /mnt/nvme0n1p1/boot/boot.ini  (for good measure)
    • Create a petitboot kboot.conf file with suitable settings:
      • echo "Armbian=/boot/Image initrd=/boot/uInitrd dtb=/boot/dtb/rockchip/rk3568-odroid-m1.dtb root=/dev/disk/by-label/armbi_root rootwait rootfstype=ext4 consoleblank=0 loglevel=5 splash=verbose earlycon console=ttyS2,1500000"  >/mnt/nvme0n1p1/etc/kboot.conf



    Yeah, you can convince Petitboot to `kexec` into Armbian's kernel. Probably can be done on other Petitboot boards too. By then, vendor's uboot, and vendor's kernel is already loaded, `kexec`'ing then into an Armbian mainline kernel. "It works" until it doesn't...

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





  3. 7 hours ago, usual user said:

    Out of curiosity I looked at your rk3568-odroid-m1.dtb. You still carry all the shortcomings and missing improvements that tobetter has not yet backported (like e.g. broken USB, missing SPI flash support, ...). with the posted "Add support for the Hardkernel ODROID-M1 board" series there is nothing left you need from tobetters tree. If you insist on using an outdated kernel version, all necessary backport patches can be inherited from the mainline tree. Generic mainline support is currently already more advanced than what the manufacturer offers.


    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

  4. 15 hours ago, usual user said:

    You've removed the only part I used from your image


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


    15 hours ago, usual user said:

    [For 6.1.0-rc1...] It also configures the hardkernel SPI flash partition layout, so fw_setenv is working for petitboot to set "skip_spiboot = false".


    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.


  5. 2 hours ago, usual user said:

    All outstanding DT patches just landed. Thus, the essential rk3568 SOC support  is available out-of-the-box with the release of 6.1.0-rc1. With the exception, of course, of the board DT. The board manufacturer has no plans for mainline support in the near future. There are some efforts by the community to take the initiative, but this is only second-hand support. Only the board developer can be the authoritative source because only he knows all the details of the design. For proper mainline support, it is the obligation of the board designer to deliver a board DT as an absolute minimum requirement. Everything else can then be taken over by the community, because it is no longer board-specific and can benefit from similar development of similar boards. This fact is demonstrated with this SBC, although no mainline SOC support has been contributed by the board manufacturer, my desktop OS deployment works perfectly


    Very good news about landed patches. 

    Tobetter's posture: shortsighted. He's also contradicting himself, having worked on board DTs for Banana boards. 


    2 hours ago, usual user said:

    or underpaid Armbian developers provide it for free


    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


  6. On 8/5/2022 at 10:20 PM, Nexus said:

    Any clue on what mirror to get this/where to find it (if that is actually the issue here)?


    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.

  7. On 7/13/2022 at 11:51 PM, Nexus said:

    Hello. Is anyone else having issues compiling desktop images for this platform? Attached are the 2 error logs that the compile script produces. I used build files from rpardini's repository; specifically the "extensions" branch. Is this the incorrect one? Thanks for any help.

    Logs produced


    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.

  8. 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






    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



  9. 21 hours ago, going said:

    But then the process of creating these archives in the build system is not necessary. It becomes a simple periodic manual work. Update this storage once a month


    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?



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


  11. 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



    (PS: No idea why I'm required to tag a board for this post)

  12. 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).




    (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)

  13. On 5/19/2022 at 6:17 PM, Excel said:

    armbian for Asus Thinker board 2 / 2s


    @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!)


    UPDATEhttps://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!



    On 5/19/2022 at 7:26 PM, Igor said:

    we should rather close this idea right now


    Sorry boss, I've all these images laying around and can't help myself. 😉




  14. On 5/12/2022 at 6:04 PM, rvalle said:

    I also use cloud-init for server customization


    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. 



  15. On 5/12/2022 at 5:59 PM, Neo2SHYAlien said:

    I tested with a new SD card still wont to boot at all.


    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.



  16. 3 hours ago, rvalle said:

    I get this from docker-shell


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

  17. 1 hour ago, rvalle said:

    I just want to build the image with a patch of mine too. See if we are lucky and get it to work.


    Should be doable, patch dirs are empty so just drop stuff in there.


    1 hour ago, rvalle said:

    Are you using Tobetter code from Hardkernel? We have a discussion over there because most modules are disabled in the kernel even if they have nothing to do with the actual silicon. He is looking into it, be aware.


    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.


  18. 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!



  19. 1 hour ago, rvalle said:

    I am trying to make sense of your code.


    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.



    1 hour ago, rvalle said:

    The code is in your rpardini/extensions branch, but was it from armbian-build/master


    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.



  20. On 4/25/2022 at 6:38 PM, Igor said:

    we should exit if HOST is less them Jammy, since Git is too old.

    23 minutes ago, Igor said:


    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.



    27 minutes ago, Igor said:

    Also office unblocked at kernel.org


    I still couldn't find time to work on this. 



  21. 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


  • Create New...