3 ms·

> As usual, looks good on papier but no ecosystem and the current stack that it comes with is dead on arrival. There is no standard Arm ecosystem to boot on w

> As usual, looks good on papier but no ecosystem and the current stack that it comes with is dead on arrival. There is no standard Arm ecosystem to boot on which is the real issue - every board needs a custom kernel and booting. I blame Arm for never cooking up a PC like spec that defines hardware configuration, firmware and booting. This is why x86 is going to stick around for a while - its dead simple to bootstrap a random x86 machine (well, almost).

Retr0id 3y ago
I naively assumed that device trees had solved this problem, but clearly they haven't in practice. How come?
- Teknoman117 3y ago
  For one, you have to provide one specifically for your board to boot at all. There is no "common" one that'll get you to a shell on any board. The main issue is that most SoC vendors just dump a heavily hacked up Linux kernel source intended for Android on you, along with binary blobs (firmware, android hal services, etc.). The drivers aren't in the kernel per se, just enough of a stub for the proprietary blobs to talk to the hardware. So if the goal is to run a standard Linux distro on the board, you're pretty screwed unless you have the time and resources (or a community) to reverse engineer the android bsp into drivers for the mainline kernel. The thing that makes the RPi great is that there's actually an entity paying for this development to happen, along with the community. It's certainly far from the fastest ARM board, but even the decade old RPi 1 still gets kernel updates.
userbinator 3y ago
I blame Arm for never cooking up a PC like spec that defines hardware configuration, firmware and booting. ARM isn't to blame; it's that no one company was big enough to set the standard (and let others clone it) for ARM systems unlike what IBM did with the x86/PC, which is not surprising given how diverse ARM's cores are.
hakfoo 3y ago
I always wondered how we got there. The original ARM chips, as in the Archimedes era, obviously ran in things that broadly resembled the other desktop computing platforms of the era. They had to solve the same problems: deciding which device to boot from, how to initialize the attached grab-bag of peripherals. They also had a long series of models with varying capabilities and integration. So they must have something comparable to a BIOS/EFI/Open Firmware-- a standardized hardware enumeration and bringup process. Somehow that disappeared when ARM moved away from RISC OS "desktop computers" and went into the microcontroller world. Why? I figured it probably either had to do with licensing, or an assumption that an embedded ARM core in some random device would only ever be used with a particular bag of peripherals, so there was no need to rely on conventions.

Retr0id 3y ago

I naively assumed that device trees had solved this problem, but clearly they haven't in practice. How come?

Teknoman117 3y ago
For one, you have to provide one specifically for your board to boot at all. There is no "common" one that'll get you to a shell on any board. The main issue is that most SoC vendors just dump a heavily hacked up Linux kernel source intended for Android on you, along with binary blobs (firmware, android hal services, etc.). The drivers aren't in the kernel per se, just enough of a stub for the proprietary blobs to talk to the hardware. So if the goal is to run a standard Linux distro on the board, you're pretty screwed unless you have the time and resources (or a community) to reverse engineer the android bsp into drivers for the mainline kernel. The thing that makes the RPi great is that there's actually an entity paying for this development to happen, along with the community. It's certainly far from the fastest ARM board, but even the decade old RPi 1 still gets kernel updates.

userbinator 3y ago

I blame Arm for never cooking up a PC like spec that defines hardware configuration, firmware and booting. ARM isn't to blame; it's that no one company was big enough to set the standard (and let others clone it) for ARM systems unlike what IBM did with the x86/PC, which is not surprising given how diverse ARM's cores are.

hakfoo 3y ago

I always wondered how we got there. The original ARM chips, as in the Archimedes era, obviously ran in things that broadly resembled the other desktop computing platforms of the era. They had to solve the same problems: deciding which device to boot from, how to initialize the attached grab-bag of peripherals. They also had a long series of models with varying capabilities and integration. So they must have something comparable to a BIOS/EFI/Open Firmware-- a standardized hardware enumeration and bringup process. Somehow that disappeared when ARM moved away from RISC OS "desktop computers" and went into the microcontroller world. Why? I figured it probably either had to do with licensing, or an assumption that an embedded ARM core in some random device would only ever be used with a particular bag of peripherals, so there was no need to rely on conventions.