[HN Gopher] Armbian Updates: OMV support, boot improvents, Rockc...
       ___________________________________________________________________
        
       Armbian Updates: OMV support, boot improvents, Rockchip
       optimizations
        
       Author : transpute
       Score  : 63 points
       Date   : 2025-05-12 07:51 UTC (15 hours ago)
        
 (HTM) web link (www.armbian.com)
 (TXT) w3m dump (www.armbian.com)
        
       | proxysna wrote:
       | Armbian is an exceptional project, even if the support might be
       | uneven in some places, being able to roll out the same OS across
       | almost every SBC i have is an absolute game changer. If there is
       | support, Armbian is worth trying 100% of the time.
       | 
       | Edit: Also if you don't like/want Ubuntu/Debian their build
       | documentation is pretty great.
        
         | dima55 wrote:
         | Their website doesn't answer the obvious question: what is it,
         | and how is it different from vanilla debian? Do you know?
        
           | qwertox wrote:
           | Vanilla Debian will not run on your nice and shiny Radxa
           | Rocks 5B or Banana Pi whatever.
        
             | dima55 wrote:
             | Why not? What's missing?
        
               | qwertox wrote:
               | Different boot process, U-Boot needs to be compiled for
               | the exact board, drivers for the specialized components
               | are needed, DTB (on ARM systems, the kernel doesn't probe
               | hardware the same way a PC does) and other reasons.
        
               | RetroTechie wrote:
               | _> Different boot process, U-Boot needs to be compiled
               | for the exact board_
               | 
               | Why? That sounds dumb. And (assuming you're correct), how
               | does Armbian deal with that / get around it?
        
               | ajb wrote:
               | It's basically the same in the x86 world : your bios is
               | customised to the board
               | 
               | The sad part is that on ARM the kernel is usually _also_
               | custom compiled for the board. So what happens is that
               | Armbian ship a different image for each board.
               | 
               | If you go and look in
               | https://github.com/torvalds/linux/tree/master/arch/arm
               | you see a zillion "mach-xxx" directories for different
               | SoC architectures, even if they all use Arm.
               | 
               | Device-tree is a partial solution, but no-one seems to
               | have an incentive to finish the job and let a single
               | image run on any (sufficiently recent) arm board. It's
               | difficult for the community to fix because most people
               | have only their own board. Someone would need to pay for
               | a CI rig with every board, and some kernel devs to do the
               | work of building a single kernel to run across
               | everything. (I think that's originally what Linaro was
               | for - not sure why they didn't finish the job)
        
               | qwertox wrote:
               | Right, the x86 BIOS/UEFI is baked into the motherboard
               | firmware and handles early hardware init in a mostly
               | standardized way. But with ARM boards, there's no
               | universal firmware, it usually needs to be part of the
               | image you download for that specific board.
        
               | yjftsjthsd-h wrote:
               | > Why? That sounds dumb.
               | 
               | Good, you understand the situation perfectly.
               | 
               | > And (assuming you're correct), how does Armbian deal
               | with that / get around it?
               | 
               | You'll notice that if you try to download it from
               | https://www.armbian.com/download/ , nearly every board
               | has a different download image; this is because every one
               | of those images embeds its own boot chain. There _are_
               | efforts (in some projects, I 'm not aware of armbian
               | doing this) to build some amount of early bootloader per-
               | board (often uboot), and just make the install steps
               | something like "install this per-board thing, _then_
               | install the real OS using a standard image " but that's
               | less common and doesn't work super well when that initial
               | bootloader has to go on the same storage device as the
               | main OS.
        
               | dima55 wrote:
               | I believe that's common on ARM devices. But "vanilla
               | debian" generally refers to userspace, and that should
               | just work. Is this "armbian" thing quite literally
               | "kernel + bootloader + vanilla debian"? The website
               | doesn't say that in any obvious place
        
               | puzzlingcaptcha wrote:
               | Pretty much, plus their little configuration utility for
               | loading dtb overlays among other things.
        
         | FlyingSnake wrote:
         | How does Armbian compare to DietPi?
         | 
         | FWIW: I'm running dietPi on my OG Pi Zero W and it doesn't even
         | hit 30% resource usage.
        
       | chris37879 wrote:
       | I just stumbled across armbian recently and I must say I really
       | like it.
       | 
       | I wanted to use UEFI, but my orangepi cm5 modules don't seem to
       | have the SPI chip needed to store the UEFI there, so I'd have to
       | load it on a partition and lose out on some features like
       | persisting variables across boot.
       | 
       | The arm ecosystem really needs to settle on some sort of
       | universal boot loader / firmware layer and stop just hacking up
       | the linux kernel and not contributing back to it.
        
         | Nexxxeh wrote:
         | I'm not an Arm dev and am just a consumer so I may be
         | misunderstanding, but isn't Arm SystemReady pretty much the
         | thing that's intended to solve the problem you're talking about
         | (among others)?
         | 
         | https://developer.arm.com/documentation/107981/0302/SystemRe...
        
           | robotnikman wrote:
           | It is, but it seems like only servers are adopting it at the
           | moment. Or high end ARM workstations. I can't think of any
           | consumer devices or SBC's off the top of my head that support
           | it.
        
       ___________________________________________________________________
       (page generated 2025-05-12 23:01 UTC)