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?

  • MNByChoice@midwest.social
    52·
    5 months ago

    RISC-V is better for Linux due to driver support. Vendors making hardware are more likely to use RISK-V for their controllers due to the costs. Modern computers are putting more functions under control of kernels that run on proprietary compute. (There exists a chart showing how little the Linux kernel directly controls.) As more of those devices run RISC-V, they will become more discoverable.
    Also, those that can design or program tge devices will have more transferrable skills. Leading to the best designs spreading, and all designs improving.

    Places in a computer with compute (non-exhaustive, not all candidates for RISC-V):
    BMC
    Soundcard (or subsystem on mainboard)
    Video card (GPU and the controller for the GPU)
    Storage drives
    Networking
    Drive interface controlling card
    Mainboard (not BMC)
    Keyboard
    Mouse
    Monitor
    UPS
    Printer

    Will it be perfect? Nope.
    A lot of the vendors will lock things up as well.

    • tetris11@lemmy.ml
      12·
      5 months ago

      There exists a chart showing how little the Linux kernel directly controls

      I’d be greatly interested in seeing this chart

        • tetris11@lemmy.ml
          4·
          5 months ago

          examples he gives are what you’d expect:

          • Linux doesnt control the bootloader
          • Linux doesn’t control power management

          Many systems on the chip that Linux doesn’t have control over, and could be compromised by a cross SoC attack

          • MNByChoice@midwest.social
            2·
            5 months ago

            Thank you for pulling the image out.

            This talk surprised me at the time. I was starting the eye opening experience of design hardware. Linux more orchestrates the hardware than controlling it.

            • tetris11@lemmy.ml
              2·
              5 months ago

              For me it opened my eyes to the idea that all you really need is some CPU time and a little RAM space to have a full-fledged performative system. Sure, there will be a large attack vector for remote spying, but if you just want to code and play games then it’s pretty amazing how little you need :-)

    • winterayars@sh.itjust.works
      10·
      5 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@mander.xyz
        2·
        5 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
          2·
          4 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.