4 ms·

Why not? What's missing?

by dima55 1y ago

qwertox 1y ago
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 1y ago
  > 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 1y ago
    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 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 1y ago
      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.
      - moondev 1y ago
        https://developer.arm.com/Architectures/Unified%20Extensible%20Firmware%20Interface https://developer.arm.com/Architectures/Unified%20Extensible...
  - yjftsjthsd-h 1y ago
    > 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/ 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 1y ago
  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 1y ago
    Pretty much, plus their little configuration utility for loading dtb overlays among other things.
pabs3 1y ago
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.

Why not? What's missing?

by dima55 1y ago

Why not? What's missing?

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 1y ago
> 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 1y ago
  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 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 1y ago
    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.
    - moondev 1y ago
      https://developer.arm.com/Architectures/Unified%20Extensible%20Firmware%20Interface https://developer.arm.com/Architectures/Unified%20Extensible...
- yjftsjthsd-h 1y ago
  > 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/ 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 1y ago
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 1y ago
  Pretty much, plus their little configuration utility for loading dtb overlays among other things.

pabs3 1y ago

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.