> Nobody is compiling an entire Linux distro on something like a Raspberry Pi 3.
The RISC-V mainboard for the Framework is 4-core 1.5 GHz with 8 GB of RAM. That's leagues better than the hardware that people were compiling Linux on in the 90s and early 2000s.
Unfortunately software has gotten so much worse that hardware improvements simply can't keep up. That's also why Linux doesn't enable certain mitigations by default.
The U74-MC on that board’s JH7110 SoC is two 64-bit dual-issue cores at 1.5 GHz, so it’s fair to compare it with the four 64-bit dual-issue cores at 1.2 or 1.4 GHz on the RPi3’s Cortex-A53, or for that matter with something like a 1.0 to 1.4 GHz dual-socket Pentium III system from the early oughts (which would use the P6 32-bit dual-issue microarchitecture from the Pentium Pro).
They're targeting them, though. I used to use the Rasberry Pi Zero line for embedding into projects, even though it is much, much more difficult to get than the Pi Pico, because the Zero series can run Linux, opening up a lot more software.
I've switched to SBCs based on the Bouffalo Lab BL808 and more recently Sophgo SG2000 SoCs, which are in the same form factor and price range as the Pi Pico, but run full Linux. They're nowhere near as fast or capable as a desktop, laptop, or even phone/tablet processor, but they're much faster than the RP2040 and much easier to port to. I even compile target applications on them, although not the Linux kernel itself.
I love my little $5 duos! 64 MB RAM is actually enough to run emacs and gcc right on the board itself for programs you write yourself -- it's as much RAM as we had on PCs and Macs, as standard, as recently as 1998 or so, and that was on 200 or 300 MHz machines, slower than a 1 GHz Duo (even allowing for them being mild superscalar/OoO). Not to mention my SPARC ELC and SGO Indy, both of which have 64 MB RAM (and 33 and 166 MHz CPUs respectively. Those used to be serious machines!
With the standard Buildroot image you need to statically link things, but you don't have to build specially in many cases .. for example just copy qemu-arm-static, qemu-x86_64-static etc over from a standard RISC-V distro and they run fine on the Duo.
In the early development phase, you'd compile the OS on a big non-RISCV desktop PC and target those little SBC boards, then flash it onto them and boot and test. In the prototype phase, you get the real hardware, but will probably still compile from something else. By the time the real hardware is ready to be released to the public, the OS for it will probably already be finished and ship with it.
Cross-compilation is much more hassle than native, especially with GCC. It's feasible for individual apps, but I would not want to set that up for an entire Linux distro.
Sure, but a new architecture is big risk reward. I expect the first companies to start selling consumer risc-v products will have a big budget to set up a datacenter, to remotely flash racks of their devices and run automated tests as their big team develops the risc-v linux distro it will run. Perhaps a nintendo switch 3? Samsung smartphone? Quallcomm smart toaster? Who knows. But it will probably be some big company on https://riscv.org/members/ who has an axe to grind with ARMs licencing fees, and is willing to go to this hassle.
Your comment seemed to be claiming that cross-compiling an entire operating system was infeasible. My comment was that it's exactly what big companies do.
Those are all SBCs, and slow ones at that. Nobody is compiling an entire Linux distro on something like a Raspberry Pi 3.