(评论)
(comments)

原始链接: https://news.ycombinator.com/item?id=43960577

这个Hacker News帖子讨论了Armbian,一个支持多种单板计算机(SBC)的操作系统。用户称赞它能够在各种硬件上运行相同的操作系统。一个关键问题是:Armbian与纯净Debian有何不同? 讨论强调,由于启动过程、专用驱动程序和设备树blob(DTB)的差异,纯净Debian并不原生支持许多SBC。Armbian通过提供包含必要的引导加载程序(U-Boot)、内核适配和驱动程序的板级镜像来解决这个问题。虽然“纯净Debian”通常指用户空间,但内核和引导加载程序也需要针对ARM硬件进行调整。一些用户认为ARM生态系统需要一个通用的引导加载程序/固件层来避免每个板卡都需要自定义内核。这不是一个简单的问题,但这将显著改善ARM的使用体验。

相关文章
  • (评论) 2025-05-08
  • (评论) 2025-05-13
  • (评论) 2025-05-13
  • (评论) 2025-05-10
  • (评论) 2025-05-08

  • 原文
    Hacker News new | past | comments | ask | show | jobs | submit login
    Armbian Updates: OMV support, boot improvents, Rockchip optimizations (armbian.com)
    73 points by transpute 2 days ago | hide | past | favorite | 17 comments










    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.



    Their website doesn't answer the obvious question: what is it, and how is it different from vanilla debian? Do you know?


    Vanilla Debian will not run on your nice and shiny Radxa Rocks 5B or Banana Pi whatever.


    Why not? What's missing?


    The hard work of upstreaming/mainlining all the hardware support code in the userspace drivers like mesa, the Linux kernel core/drivers, bootloaders like GRUB/u-boot, boot firmware like coreboot/Tianocore/u-boot.


    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.


    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


    Pretty much, plus their little configuration utility for loading dtb overlays among other things.


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



    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)



    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.


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



    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.



    Completely agree. I use it on my old PINE64 and it keeps on ticking.


    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.



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



    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.






    Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact



    Search:
    联系我们 contact @ memedata.com