Help me understand this better.

From what I have read online, since arm just licenses their ISA and each vendor’s CPU design can differ vastly from one another unlike x86 which is standard and only between amd and Intel. So the Linux support is hit or miss for arm CPUs and is dependent on vendor.

How is RISC-V better at this?. Now since it is open source, there may not be even some standard ISA like arm-v8. Isn’t it even fragmented and harder to support all different type CPUs?

  • winterayars@sh.itjust.works
    link
    fedilink
    arrow-up
    10
    ·
    edit-2
    3 months ago

    There’s also the fact that Arm doesn’t really work with arbitrary PC style hardware. Unless this got fixed (and there have been some pushes) you have to pretty much hard code the device configuration so you can’t just (for example) pull a failed graphics card and swap a new one and expect the computer to boot. This isn’t a problem for phone (or to an extent: laptop) makers because they’re happy to hard code that info. For a desktop, though, there’s a different expectation.

    RiscV does support this, i believe, so in that sense it fits the PC model better.

    • acockworkorange
      link
      fedilink
      arrow-up
      2
      ·
      3 months ago

      I don’t follow. Isn’t the OS’s job to discover hardware? How is the CPU instruction architecture come into play here?

      • winterayars@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        3 months ago

        See the start of this post talking about device tree models vs boot time hardware discovery.

        There’s no reason an arm chip/device couldn’t support hardware discovery, but by and large they don’t for a variety of reasons that can mostly be boiled down to “they don’t want to”. There’s nothing about RISC-V that makes it intrinsically more suited to “PC style” hardware detection but the fact that it’s open hardware (instead of Apple and Qualcomm’s extremely locked down proprietary nonsense) means it’ll probably happen a lot sooner.