back to article Linux Foundation and pals – including Intel – back software ecosystem around RISC-V

Linux Foundation Europe and a number of big names in tech have banded together to drive development of a comprehensive software ecosystem that supports the open RISC-V processor instruction set architecture. Dubbed RISE, which is intended to be an acronym for RISC-V Software Ecosystem, the project brings together vendors that …

  1. 3arn0wl

    This article is 4 years late.

    Both Qualcomm and Samsung expressed their interest in RISC-V in 2017. Samsung had RISC-V cores in their tech by 2019, and Qualcomm by 2020.

    Linux was running on RISC-V by 2019 (and *BSD before that). There's been strenuous efforts to rebase apps for RISC-V, and there's a surprising number already available, if you look at the Alpine repositories.

    What's changed of course is the arrival of a number of RISC-V SBCs, at relatively low cost, that are capable enough to run Linux : we're watching the transition of RISC-V go from the developer's purview to the realm of the capable techie. It won't be long now until we see RISC-V in the hands of the average consumer, and it seems that the software community are both aware and excited by that.

    1. Anonymous Coward
      Anonymous Coward

      Re: This article is 4 years late.

      With the likes of Nvidia making massive inroads to the ARM server market and properly high performance and core count systems; they have finally realised that they cannot sit on the Xeon cash-cow any longer.

      Xeon has been a lame duck for some years now of course, and they've known it (sales figs back this up too).

      RISC-V is a route Intel (might) be able to do something different to Nvidia rather than a straight clone.

      I'm most interested in what AMD chooses to do on this front. Epyc is a powerhouse BUT ultimately has many of the same problems as Xeon on this front.

      1. 3arn0wl

        Re: This article is 4 years late.

        FWIW I'm interested in what Qualcomm in particular is planning, in the light of its ongoing spat with Arm, but I'm interested in what Samsung is thinking about doing too.

        I imagine that both companies are keeping a very close eye, both on RISC-V processors' performance, and the readiness of software.

        1. This post has been deleted by its author

      2. BillG
        Holmes

        Re: This article is 4 years late.

        But the attraction of RISC-V is that it is not only royalty-free, but also under the governance of its member organizations rather than a single proprietor that the architecture can be extended with custom extensions.

        I've already been involved with several RISC-V core design projects, 1) royalty-free and 2) custom instruction extensions are the two main technical reasons for it's growth. Who owns the architecture is less important than the first two. It's also a true RISC architecture and only has one ISA (each Arm core has two internal ISAs, a second ISA is dedicated for Thumb instructions). The list of technical advantages over Arm is extensive, the closer I look at the RISC-V internal architecture the more impressed I am.

        In my career I've never seen a CPU architecture gain acceptance so fast. This isn't a marathon, this is a sprint, the internal schedules for RISC-V to replace Arm are extremely aggressive. RISC-V is inevitable.

  2. Will Godfrey Silver badge
    Big Brother

    Cautious optimism

    Is it too much to hope that they will specify a simple boot system - write protected with a physical switch?

    1. Anonymous Coward
      IT Angle

      Re: Cautious optimism

      > Is it too much to hope that they will specify a simple boot system - write protected with a physical switch?

      I suspect these systems are designed with unnecessary complexity to prevent cloning

      1. ChoHag Silver badge

        Re: Cautious optimism

        It's not to prevent cloning, it's to protect copyright revenue.

        Massively reduced development costs (testing? What's that?) is an added bonus.

    2. StrangerHereMyself Silver badge

      Re: Cautious optimism

      And how about a Universal Boot Loader? For some reason I see all sorts of operating system implement their own instead of using something like U-Boot.

      1. Anonymous Coward
        Anonymous Coward

        Re: Cautious optimism

        [ OFW has entered the chat ]

        [ ... probably years too late ]

        But yes, some kind of "standard" (ymmv) bootloader, which OS devs can work with such that "installing" the operating system doesn't mean "copy a pre-configured image onto boot media"

  3. Roland6 Silver badge

    Intel feeling the pain?

    I wonder what the cost is of Intel maintaining its proprietary CPU architecture. Suspect it must be similar to developing and maintaining your own operating system.

    Hence Intel might be looking enviously at the ARM eco system which would seem to distribute the work and thus move faster. Plus Intel with a new fab or two in construction, will be wanting to build production orders…

    1. An_Old_Dog Silver badge

      Re: Intel feeling the pain? / Alternatively ...

      ... Intel may be wanting to sabotage RISC-V, seeing it as a threat to their proprietary CPUs. Being a big contributor gets you a big voice.

      1. 3arn0wl

        Re: Intel feeling the pain? / Alternatively ...

        Joining the RISC-V Foundation, donating US$1 billion, offering fabbing support and developing Horse Creek is an odd way to sabotage, wouldn't you agree?

        1. Bent Metal

          Re: Intel feeling the pain? / Alternatively ...

          "Embrace, Extend, Extinguish" has worked so well for the other half of WinTel... why couldn't it work nicely here, assuming Intel wrangle a suitably large vote in whatever future direction RISC-V takes?

      2. Richard 12 Silver badge

        Re: Intel feeling the pain? / Alternatively ...

        More likely to sabotage ARM.

        ARM make a huge amount of money at the low end, if RISC-V takes that away then Intel will have rather less to worry about.

    2. StrangerHereMyself Silver badge

      Re: Intel feeling the pain?

      I suspect that Intel is only joining the gang to keep tabs on its competitors. Maybe when their downfall becomes inevitable they'll turn out some half-baked alternative (like MIPS did) to try to stem the hemorrhaging.

  4. StrangerHereMyself Silver badge

    Unstoppable

    The move towards RISC-V is unstoppable and inevitable. It's not a question of "if" but "when" will RISC-V dominate embedded, server and desktop computing.

    The only possible snafu I see is that the U.S. government will eventually throw up roadblocks to prevent China and Russia from using RISC-V to keep up with Western information technology. Its independence and apolitical orientation may be a hindrance in that respect.

    1. Anonymous Coward
      Anonymous Coward

      Re: Unstoppable

      I find your excess of faith ... disturbing.

      1. StrangerHereMyself Silver badge

        Re: Unstoppable

        Haven't you learned anything from Linux? Linux certainly isn't the best Operating System out there, but there's an enormous demand for an open source, free and easily customizable operating system.

        Same with RISC-V. It may not be the best thing since sliced bread, but too many people, organizations, companies and even nation states have interests in a free and open ISA for it not to succeed.

  5. Henry Wertz 1 Gold badge

    Intel and ARM

    I assume Intel is probably interested in use for embedded controllers. The infamous Management Engine, the embedded controllers to do thermal management and power distribution (any CPU that has a base and a boost clock probably has some embedded controller managing that), wifi controllers, ethernet chips, etc. But who knows? They certainly have the resources to make a ridiculously fast but low-powered RISC-V CPU if they wanted to do so, to compete with the ARMs that are digging into the datacenter sales.

    ARM? Oh yeah, in years past the ARM Linux kernels were almost entirely model-specific; there was no standardization to what GPIO pins, what addresses devices were at on the various ARM busses, and no plug and play or ACPI-style data structures to find out (except the ARM Microsoft Surfaces, they used some PC-style ACPI tables since I suppose Windows on ARM could use them to find devices.). Like pre-plug-and-play ISA, the "board support package" kernel would just have I/O addresses, what interrupt the device uses, etc. hard-wired (but worse because NONE of the devices have standard addresses, on the ISA PC at least the keyboard, system timer, IDE controllers and a few other things had standard addresses, I used an ISA PC with Linux and devices with jumpers for IRQ and I/O port, I built the stuff as modules so I could feed the IRQ, I/O, and DMA channel as module parameters instead of having to stick junk into my kernel boot line.). Finally within the last 5 years or so, the Linux developers came up with a way to have a generic ARM kernel that'll boot on most systems... but it involved just putting this giant table of DTBs ("Device Tree Blobs") listing what addresses the devices are at on each and every older ARM board; the newer ARM boards finally started putting a DTB into the board firmware so bootloader and Linux can parse that to determine where the hardware is.

    They standardized on u-boot on ARM many years ago to load the Linux kernel, but the early boot process on ARM was not standardized at all either, on some systems (quoted from u-boots web page) "U-Boot takes some responsibilities of a classical firmware (like initial hardware setup, CPU errata workarounds or SMP bringup)" while on others "it's main purpose is a bootloader".

    So yes... it'll be very good for RISC-V to take care of this now rather than having years and years of systems that require model-specific kernels or a table that expands more and more every year as new boards come out, bootloader that may need to be way more than a bootloader depending on what board it's running on, and so on.

  6. Henry Wertz 1 Gold badge

    ISA Linux

    I just had to expound on this; I started out with entirely jumpered cards; then a mix of jumpered and a few like a sound blaster that could be autoconfigured (it had a choice of 2 or 3 IRQs, 2 or 3 I/O ports, etc., but jumperless so you could specify these settings or let the driver select them.) ISA PNP came on the scene, some cards supported many addresses and irq choices through it, some just had probably the same 2 or 3 choices some previous jumpered model had, just under isapnp control. So for about 6 months it was rough, Linux would assign cards some addresses then find it did not have any free resources for some device or other. But they got it nailed, load the jumpered cards first, load the pre-isa-pnp but autoconfigurable ones next, then isa pnp would build a table of all isa pnp cards so it could make sure the ones that only support a few choices have one free to use. Smooth sailing. I briefly (this was like 10 or 15 years ago) had a system I was using as a home firewall/fileserver croak, and realized I had enough old ISA cards to build a temporary replacement -- 2 IDE ports, 2 ethernet ports, VGA, I think a SCSI card, I think it had a sound card in there too because why not, all sharing that 8MB/sec bus. That ran a tad slow (my recollection was getting about 2MB/sec off the hard disk but about 0.8MB/sec serving them over the ethernet... I'm sure that was a 10mbps ethernet card so it would have only maxed out at about 1.2MB/sec anyway). But it was faster than having no access to the internet or file storage until some replacement parts arrived.

  7. Will Godfrey Silver badge
    Unhappy

    Guys, Please use more paragraphs!

    Trying to read the previous two posts was nearly driving me cross-eyed

    1. Henry Wertz 1 Gold badge

      Re: Guys, Please use more paragraphs!

      Indeed, I typed it out late, I see it now and I'm like "Damn what a wall of text". Especially on my phone. More paragraph breaks next time! 8-)

  8. Anonymous Coward
    Anonymous Coward

    Of course

    There would not have been an "arm" if Apple had not invested 15 million to help Acorn Risc Machines develop a low powered cpu. And after that they never used it but walked away with an irrevocable perpetual licence to use their architect, something or other. Oh just go and look the subject up.

    And now it is Intels turn to bung money at some cpu or other.

    And Microsoft are bunging money to make Linux work with/instead of Windows?

    And the thanks they get is a slagging from the Linux fetishists/freetards, because the last thing they want is for Linux and it's half baked "free" software to make it big on the desktop. Because they would then have nothing to feel "superior" about.

    So you freetards. carry on worshiping your Totem (Linus). That is the price you have to pay. Just like Melon suks fetishists.

    1. This post has been deleted by its author

  9. riva

    Better late than ever

    We need to shift away from x86 and into RISC already. Intel & Microsoft had something going with IA-64 by Intel and Microsoft shipping Windows, Office and Visual Studio on it, but Intel was more interested in taking x86 products forward in the consumer market. Now we must focus on ARM RISC instead.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like