Jump to content

rpardini

Members
  • Posts

    132
  • Joined

  • Last visited

Reputation Activity

  1. Like
    rpardini got a reaction from Nexus in 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.
  2. Like
    rpardini got a reaction from Werner in 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. Like
    rpardini got a reaction from Willy Moto in rock-5b with vendor u-boot & vendor kernel; PR and test images   
    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. Like
    rpardini got a reaction from piter75 in rock-5b with vendor u-boot & vendor kernel; PR and test images   
    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
     
     
  5. Like
    rpardini got a reaction from Willy Moto in Asus thinker board 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!)
     
    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. 😉
     
     
     
  6. Like
    rpardini got a reaction from usual user in 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)
  7. Like
    rpardini got a reaction from Igor in Shallow Kernel Git trees via GitHub Actions   
    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)
  8. Like
    rpardini got a reaction from going in Shallow Kernel Git trees via GitHub Actions   
    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
     
  9. Like
    rpardini got a reaction from lanefu in 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. Like
    rpardini got a reaction from lanefu in Asus thinker board 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!)
     
    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. 😉
     
     
     
  11. Like
    rpardini got a reaction from TRS-80 in armbian-next development   
    Here's some info on armbian-next status:
    - In development since October/2021 (thus 7 months)
    - Currently sitting at 189 commits, almost all lib/**/*.sh files are changed.
    - More than 17 rounds of manual merges performed manually against master. Sometimes we have 1-2 weeks of delay, but it's mostly master-equivalent. Each round takes 2-5 hours of carefully reviewing every commit that landed on master and maybe rewriting it.
    - Huge changes around logging and error control. Errors now stop the build. Logs contain actionable information.
    - Rewritten kernel building and packaging. There's no more packaging patches or builddeb hacks. Kernel-headers support cross compiles across all arches. No more byteshift patch. Still needs tuning.
    - Completely changed git handling, specially for kernel. This still needs handling of previously git://, now http:// bundle downloading as reported above, and caching.
    - Patch hashing is half-rewritten, still needing work. Now same code can both actually patch and produce hashes, making it consistent. "fasthash"
    - apt-cacher-ng configuration for local usecase is now under Armbian control.
    - 100% working without any external/downloadable toolchains.
    - full support for building any arch under any other arch, including "reverse cross-compiles" and running of rkbin/fip x86-only binaries.
    - source code is now properly formatted according to shellfmt, and 90% of shellcheck warnings are squashed. A lot remains still.
    - 20x faster kernel rebuilds, 2-3x faster full builds due to consolidated make invocations, benefitting from bintree caching as well as ccache.
    - most compression points changed to zstd, yielding multicore (de-)compression and thus much faster image building during cache hits.
    - full support for DKMS modules, eg nvidia-drivers and ZFS, under any cross compile scenario.
    - data channel for metadata communication, config extraction, matrix generation etc by having stdout clean for machine data. logs to stderr.
    - per-build TMPDIR affecting and protecting all `mktemp` invocations
    - all traps rewritten under a cleanup/trap manager.
    - full HTML-based, single-file, full build log artifact. no more output/debug.
    - many others I forget.
     
    All that said, I've still a ton of stuff pending before this can 100% replace current master:
    - EXTRAWIFI-style manual patching of things is not idempotent nor proven working with "fashhash" and probably causes full kernel recompiles, negating previous benefits until fixed.
    - (server-based) Caching of warm/cold git bundles, to avoid people downloading 4gb+ of git sources.
    - kernel-headers will probably be unified with kernel-sources, since they contain mostly the same stuff.
    - extra-buildpkgs is not touched nor run, and safe to assume needs lots of work.
    - certain CI-only build ops like "rebuild roofs only" and "build all BSPs" and "build all u-boots" never run so probably won't work.

    Some few brave souls like @NicoD, @Rich Neese, and @going have actually tried armbian-next and every single try there's stuff to fix, thanks for trying and reporting.
    TL,DR: armbian-next is doing well, thanks. Work continues. It might not be ready for merge, will it ever be? I will keep it rebased as much as possible. There's no pressure. Try it out, and report. Thanks!

     
  12. Like
    rpardini got a reaction from TRS-80 in 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.
     
     
  13. Like
    rpardini got a reaction from TRS-80 in Armbian 22.05 (Jade) Release Thread   
    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!
     
     
  14. Like
    rpardini got a reaction from Igor in Armbian 22.05 (Jade) Release Thread   
    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!
     
     
  15. Like
    rpardini got a reaction from rvalle in 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
     
  16. Like
    rpardini got a reaction from Stan Pak in 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
     
  17. Like
    rpardini got a reaction from Neo2SHYAlien in 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
     
  18. Like
    rpardini reacted to schwar3kat in armbian-next development   
    I'm building from the armbian-next branch for testing and I'm finding the experience quite unfamiliar and a little annoying.   It does seem faster though.

    Orangepizeroplus (H5) built successfully for current, jammy and the image produced worked. I suspect that other flavors will build okay for testing.
    but it errored after building the image [] Error occurred [ code 23 at /root/build-armbian/rc/build/lib/functions/logging/runners.sh:134

    Orangepi-r1plus-lts (rockchip64 RK3328) built successfully for current, jammy.  No build errors.

    Orangepi-r1 (H2) build system failed near the end.  019.000.create_board_package.log
    --> 🛠1272: 1319406 - 1319406 - 1319406: ehBE: debug: Running family_tweaks_bsp [ sunxi ]
    --> 🧽 1272: 1319406 - 1319406 - 1319406: ehBE: trap: main_trap_handler [ ERR and 1 trap_manager_error_handled: ]
    The annoying 6.8 MiB html log file is a pain to parse. 

    I guess that the build system enhancement issues will be picked up and dealt with separately and should probably not have bugs logged by SBC testers, or should I be logging bugs?

    Can I switch off the time wasting and annoying markdown / html logging behaviour?
    I don't want caterpillars, butterflies ants, bunches of leaves and comic explosions that don't make anything clearer and are unnecessary annoyances that don't play nicely with my tools.
    LOG_ENABLE_EXTENSION=no, didn't do it.
    Is it possible to keep the split .tmp files on error / build fail?
  19. Like
    rpardini got a reaction from Werner in armbian-next development   
    Here's some info on armbian-next status:
    - In development since October/2021 (thus 7 months)
    - Currently sitting at 189 commits, almost all lib/**/*.sh files are changed.
    - More than 17 rounds of manual merges performed manually against master. Sometimes we have 1-2 weeks of delay, but it's mostly master-equivalent. Each round takes 2-5 hours of carefully reviewing every commit that landed on master and maybe rewriting it.
    - Huge changes around logging and error control. Errors now stop the build. Logs contain actionable information.
    - Rewritten kernel building and packaging. There's no more packaging patches or builddeb hacks. Kernel-headers support cross compiles across all arches. No more byteshift patch. Still needs tuning.
    - Completely changed git handling, specially for kernel. This still needs handling of previously git://, now http:// bundle downloading as reported above, and caching.
    - Patch hashing is half-rewritten, still needing work. Now same code can both actually patch and produce hashes, making it consistent. "fasthash"
    - apt-cacher-ng configuration for local usecase is now under Armbian control.
    - 100% working without any external/downloadable toolchains.
    - full support for building any arch under any other arch, including "reverse cross-compiles" and running of rkbin/fip x86-only binaries.
    - source code is now properly formatted according to shellfmt, and 90% of shellcheck warnings are squashed. A lot remains still.
    - 20x faster kernel rebuilds, 2-3x faster full builds due to consolidated make invocations, benefitting from bintree caching as well as ccache.
    - most compression points changed to zstd, yielding multicore (de-)compression and thus much faster image building during cache hits.
    - full support for DKMS modules, eg nvidia-drivers and ZFS, under any cross compile scenario.
    - data channel for metadata communication, config extraction, matrix generation etc by having stdout clean for machine data. logs to stderr.
    - per-build TMPDIR affecting and protecting all `mktemp` invocations
    - all traps rewritten under a cleanup/trap manager.
    - full HTML-based, single-file, full build log artifact. no more output/debug.
    - many others I forget.
     
    All that said, I've still a ton of stuff pending before this can 100% replace current master:
    - EXTRAWIFI-style manual patching of things is not idempotent nor proven working with "fashhash" and probably causes full kernel recompiles, negating previous benefits until fixed.
    - (server-based) Caching of warm/cold git bundles, to avoid people downloading 4gb+ of git sources.
    - kernel-headers will probably be unified with kernel-sources, since they contain mostly the same stuff.
    - extra-buildpkgs is not touched nor run, and safe to assume needs lots of work.
    - certain CI-only build ops like "rebuild roofs only" and "build all BSPs" and "build all u-boots" never run so probably won't work.

    Some few brave souls like @NicoD, @Rich Neese, and @going have actually tried armbian-next and every single try there's stuff to fix, thanks for trying and reporting.
    TL,DR: armbian-next is doing well, thanks. Work continues. It might not be ready for merge, will it ever be? I will keep it rebased as much as possible. There's no pressure. Try it out, and report. Thanks!

     
  20. Like
    rpardini reacted to Matthijs Kooijman in Improving / simplifying first-run services using systemd features   
    Hi all,
     
    While building a custom image that needs to do some things at the end of the first bootup and reboot, I ran into some issues with armbian-firstrun.service. It currently has Type=simple, which means dependencies will be started when armbian-firstrun is *started*, and there is no clean way to wait until after it has *finished*. Looking to fix this, I noticed some other things that could be improved in this area, such as using systemd's first-boot-complete.target and ConditionFirstBoot to more simply manage first-boot-only services.
     
    I'm considering implementing some changes and submitting them in a PR, but before I do that, I'd like to get some feedback on the approach and whether it seems worth investing time into. I considered creating a github issue about this, but given it is sort-of a feature request and the github new issue wizard seems intended to redirect away from github issues, I thought to instead post here. If a github issue seems more appropriate, I'll gladly repost there.
     
    In any case, to solve the particular problem I was having (a service that needs to run after the full first boot has completed, including resizing and firstrun script), here's three incremental changes that I would think would make sense (just 1. would be the minimal to solve this problem, 1. + 2. would solve it more generally, and 1. + 2. + .3 would simplify the code a bit maybe).

    1. Make armbian-firstrun.service `Type=oneshot`, so you can declare `After=armbian-firstrun.service` and `After=armbian-resize-filesystem.service`. This also means that system boot is delayed until this service is completed, but it does not prevent other boot services to run in parallel, so I would not consider this an issue (if it is, then removing the `Before=getty...` stuff could be considered, which is currently pointless anyway (you will not get a login prompt until armbian-firstrun.service is started, but it will not wait for completion). Note that using `Type=simple` in armbian-firstrun.service originates from https://github.com/armbian/build/commit/ee8d396fa639cd89e08fdd6646c32308f3b25f4f, but there is no rational for this choice.
    2. Give armbian-firstrun.service and armbian-resize-filesystem `Wants=first-boot-complete.target` and `Before=first-boot-complete.target` so `first-boot-complete.target` does not fire until `armbian-firstrun` is done, allowing others to just do `After=first-boot-complete.target` without having to explicitly reference specific services.
    3. Give armbian-firstrun.service and armbian-resize-filesystem `ConditionFirstBoot=yes` to let systemd ensure they are only called on the first boot. This allows removing the `systemctl disable` calls in these respective scripts as well, but needs the `/etc/machine-id` file to be removed (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900366#20), but that's probably a good idea anyway (to be regenerated on first boot, currently all machines using the same image have the same machine id).
     
    One thing (feature or seeming problem maybe) with using ConditionFirstBoot as suggested above, is that systemd ensures that if the first boot is interrupted, the first boot services are ran again on the subsequent boots, until they have all ran completely (to ensure they all had a chance to ran). This is implemented by (roughly) running ConditionFirstBoot services only if `/etc/machine-id` does not exist, and only writing it to disk *after* all `first-boot-complete.target` services have completed (also when they failed, I think). This means that if the boot is interrupted before *all* first-boot services are ran, all of them will be ran again on the next boot and needs these services to be ok with being ran twice (this is also currently the case when the boot is interrupted when either or both services are still running, except that if either service completes, then that particular service will not be retried, but others might be). See also https://man7.org/linux/man-pages/man5/machine-id.5.html
     
    As a related optimization, if 1. above is applied I think we could also add a `Before=ssh.service` to armbian-firstrun.service and remove the sshd restart from `armbian-firstrun`, so systemd just delays sshd startup until the keys are generated (but only if armbian-firstrun is active, so on subsequent boots sshd is started as normal).
     
    Also, regardless of all of the above, I see that the armbian-firstrun deletes the ssh host keys and then forces regenerating them by calling dpkg-reconfigure. However, it would seem safer to me to actually delete the ssh keys at the end of image generation somewhere (maybe in `post_debootstrap_tweaks()`?), to really rule out the possibility of machines all using the same (publicly known) keys from the image file.
     
    So, how do these sound?
  21. Like
    rpardini reacted to TRS-80 in The surprising (to me) state of F/LOSS graphics, as presented by Alyssa Rosenzweig   
    I came across these recently and found several interesting things within, so thought I would share them.
     
    I debated posting this in Development, but wanted anyone to be able to see and reply to the thread.
     
    Anyway some parts I felt were important enough that I actually took down some notes and quotations, which I will include.
     
    Open drivers for Arm GPUs
    This looks like it was presentation LVC21-318 at  Linaro Connect '21 on 2021-03-25.
     
    Video is available at above page, and also on ThemTube here.
     
    I found this a fascinating presentation.  Alyssa contrasts the (proprietary) 'before times' with current situation which is apparently quite different.  In fact, I was quite surprised to learn that:
     
     
    She then goes on to give 3 case studies, one of which was VideoCore, where I was more than a little surprised to learn that Broadcom at some point actually hired someone to work on their F/LOSS driver.  Now this was only after that guy was well into his own (night and weekend) reverse engineering effort, followed by a lot of public pressure, but still.  End result apparently is that this driver is now shipping in production RPi 4.
     
    Next case study was about Freedreno.  I will quote my favorite part from here:
     
     
    Of course being firmly in the camp with the 'looney Free Software types' myself, this comment warmed my heart quite a bit. 
     
    Finally she gives the Panfrost case study, where she points out that things are apparently moving away from the 'reverse-engineering underdog' model, and:
     
     
    And so reverse engineering is apparently no longer needed.
     
    Apparently this is the driver that ships in PineBook Pro for example.
     
    Of course I must admit to being more than a little bit (pleasantly!) surprised at all of this.  And also starting to soften my stance towards Broadcom (just a little though, lol). 
     
    If you are the least bit interested in any of this, I can highly recommend watching the full presentation.  It's only 19 minutes long, anyway, but I personally was riveted the entire time.
     
    The Open Graphics Stack
    I think this presentation was given at Embedded Linux Conference '21 on 2021-09-29.  So, about 6 months after the above.
     
    But honestly I came across it on ThemTube here.
     
    In the beginning, she makes a good point about the tension between embedded devices with perhaps 20 year life cycles, and devices with proprietary drivers which may be EoL in 5 years, and how this tension can be alleviated by using F/LOSS drivers.
     
    But what got my attention the most was:
     
     
    She then goes on about details of particular platforms (including x86, ARM, etc.) and then finally:
     
     
    Which is a quite bold (and again, pleasantly surprising) statement IMO, but then again I do consider her an authority on the subject.
     
    After that she goes into quite some detail about the nuts and bolts of all the various parts of the stack, which you may or may not be interested in watching as much.
     
     
  22. Like
    rpardini got a reaction from TRS-80 in Issue with SD Card after kernel upgrade / linux-image-current-meson64:arm64 21.08.1->21.08.6   
    sorry, no. I can't really say or fix anything about 21.08.x at this time. It's just too old of a codebase, and using vendor uboot, so with no future.
    Personally I boot the N2+ from SPI to USB3 pendrive (not cabled!) and have decent experience with 22.02, but can't say much about the eMMC + SD combo. 
    22.02 includes mainline uboot and kernel fixes for N2 which are essential to any sanity, but might still have some rough edges. Try the RC's!
    If you had working 21.08 at any point you're just lucky: I never had a stable N2 on 21.08, literally problems everywhere.
    Good luck!
     
     
  23. Like
    rpardini got a reaction from lanefu in Bring up for Odroid N2 (Meson G12B)   
    Yeah, valid to mention I did a big rework of current/5.10.y last year that has not been included in any release yet. The images we have up (from August?) do not include them and are very problematic.
    The rework fixes a ton of problems and usually brings 5.10.y/current stability, apart from reducing the impact of N2 on the other G12's.
    In the process, UHS speeds for SD were lost (they were implemented via vendor uboot 2015 hacks by HK), governor was set to performance.... all things that may have been fixed in latest versions of mainline u-boot; and Neil Armstrong has already pointed me to fixes for a bunch of things, so only more good things to come.
    Some users have built from master or tried my unofficial images and feedback was pretty good. If only HK would support us somehow or at least work in a more mainline-oriented way on their own branches....
    For next release I hope we can keep 5.10.y as current for some real users to try and after that I'll rework edge kernel to bring 5.15 / 5.16 goodness, uboot 2022.01 already is done by Igor, 100% mainline even for SPI boot (and even SATA boot on HC4).
    Right now my N2 is "in production" and has 55 days uptime with 5.10.83-meson64 and is a beast; I'd accept a second one for development, although I'm focused on the HC4 now.
     
     
  24. Like
    rpardini reacted to Igor in Armbian 22.02 (Pig) Release Thread   
    Fixed some UX troubles on the download pages, examples:  https://www.armbian.com/banana-pi-m2-plus/ https://www.armbian.com/rpi4b/ https://www.armbian.com/odroid-hc4/
     
    - download list is now completely automated, pulling from build config files https://github.com/armbian/build/blob/master/config/targets.conf
    - added option to advertise recommended targets at download pages https://armbian.atlassian.net/browse/AR-1057 by setting a property in a targets.conf
    - label supported / not supported for kernel is no more. instead label for CLI / Desktop / minimal
    - added "Closed bootloader" property
    - improved FAQ
    - enabled WIP builds for: RPi4, UEFI arm & x86
     
  25. Like
    rpardini got a reaction from TRS-80 in RFC: armbian-build architecture   
    Yes, but fear not, _fragments_ lives on in my branches. I will try to upstream it again eventually, maybe together with more useful features/refactoring based on it.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines