They did, jut not mainline. People forget these are embedded chips - they are intended to go inside of something and do one thing. These chips lack auto hardware discovery because the manufacturer assumes the customer will only turn on the hardware peripherals they need for their specific use case and build a static kernel image to meet that requirement. They ship a product that will likely see few, if any software updates and end up in a landfill.

It's because of the Raspberry Pi foundation we have this perception that embedded Arm chips are like general purpose desktop computers that run Linux desktops. The original Pi SoC was designed for TV set top boxes, STB's hence the loopy booting from GPU which was likely part of some obfuscated secure boot chain to thwart STB hackers. The Pi was a throw away hobby toy based on a chip Broadcom was going to scrap so they got a dumpster deal. It took a lot of effort for the community to fully reverse the Broadcom SoC and bring all the Pi hardware to mainline.

frankharv21 hours ago | | | parent | | on: 47755393
I agree with much of what you say. Adding a second display port was not something anybody needed.

Desktop computer was a reach. Even for BeagleBone.

I am surprised RK3566 and RK3568 still don't have good UEFI-EDK2 support.

RK3588 has great UEFI-EDK2 support. I wish somebody would backport RK356x and RK3399 boards....

The pace of development is too fast. We don't need more aarch64 CPU but better support. RISC-V adds to the mayhem.

Like we need that...

The Open Source Hardware Dream.

MisterTea7 hours ago | | | parent | | on: 47759220
RISC-V added the same problem to the mix Arm did: no standard platform to define what a system is, how hardware is detected, reported, and configured, or how to boot. Then again, RISC-V is just an open instruction set but they should have tried to assemble a forum and define a reference platform.