Follow Slashdot stories on Twitter


Forgot your password?
Open Source Linux

Linux 3.1 Released With Support for the OpenRISC CPU 165

diegocg writes "Linux 3.1 has been released. The changes include support for the OpenRISC opensource CPU; performance improvements to the writeback throttling; some speedups in the slab allocator; a new iSCSI implementation; support for NFC chips; bad block management in the generic software RAID layer; a new 'cpupowerutils' utility for power management; filesystem barriers enabled by default in Ext3; Wii Controller support; and [the usual] new drivers and many small improvements."
This discussion has been archived. No new comments can be posted.

Linux 3.1 Released With Support for the OpenRISC CPU

Comments Filter:
  • There have been so many major improvements during the life of the 2 series. I wonder what finally through them over the line to go into the 3 series.

    • Basically, it's the beginning of the end.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        In January 2012 they will release Linux 3.11
        In March they will release Linux 95
        In May they will release Linux 98
        In July they will release Linux Me
        In September they will release Linux XP
        In November they will release Linux Vista
        In January 2013 they will release Linux 7....

        and then it will be the year of Linux on the Desktop!

        • The year of the Linux Desktop will have to officially begin on December 21, 2012. It comes immediately following the removal of the "Start Menu" from in Windows 9 and the ubiquity of Bluetooth monitors, TVs, keyboards and mice that transform our phones into full size computers.
    • Re:3 series (Score:4, Informative)

      by Tubal-Cain ( 1289912 ) on Monday October 24, 2011 @01:13PM (#37820288) Journal
      Linus got sick of 2.6.really_big_number
    • Re:3 series (Score:5, Informative)

      by sakdoctor ( 1087155 ) on Monday October 24, 2011 @01:20PM (#37820390) Homepage

      "So what are the big changes?

      "NOTHING. Absolutely nothing. Sure, we have the usual two thirds driver changes, and a lot of random fixes, but the point is that 3.0 is just about renumbering, we are very much not doing a KDE-4 or a Gnome-3 here. No breakage, no special scary new features, nothing at all like that. We've been doing time-based releases for many years now, this is in no way about features. If you want an excuse for the renumbering, you really should look at the time-based one ('20 years') instead.

      tl;dr - Nothing happened.

      • by Thing 1 ( 178996 )

        "NOTHING. Absolutely nothing."

        Linux (huh, good god), what is it good for?

    • by migla ( 1099771 )

      The model of incrementing the versions had long been incompatible (as far as getting reasonable numbers) with the changed development model. Since the development was now more like a steady stream of whatever features that happened to be developed instead of the old one where bunches of big features were released at once and less often, the mere silliness of a .39 release (as 2.6 had in practice become the "major" version (as opposed to major being 2 and minor being 6) with the aforementioned shift) and th

    • Linux entered its 3rd decade with 3.0.

      "This is a free minix-like kernel for i386(+) based AT-machines," began the Linux version 0.01 release notes in September of 1991 for the first release of the Linux kernel.

  • Where can I get one? (Score:2, Interesting)

    by Anonymous Coward

    Where can I get an OpenRISC CPU and a motherboard that will support it, and how much do they cost compared to Intel/AMD CPUs of similar performance?

    • by DarkOx ( 621550 )

      how much do they do they cost compared to Intel/AMD CPUs of similar performance?

      Depends on where you live and what 10 year old PCs go for at your local garage sales.

    • Were ARM motherboards (I assume you don't mean embedded stuff) available when Linux added support for it?

      For that matter, are any available now?

    • by Anonymous Coward

      You can't get one of similar performance to a modern Intel CPU. Think orders of magnitude slower.

    • Where can I get an OpenRISC CPU and a motherboard that will support it, and how much do they cost compared to Intel/AMD CPUs of similar performance?

      OpenRisc is a soft-cpu, defined in the Verilog language, suitable for implementing in many different types of FPGA's of varying price/performance/power.
      Here is one source for boards of all types:


      • Can I implement it on a Zynq-7000 []? How many gates does it consume (and so how many left over on the Zynq)?

        • I haven't tried the OpenRISC cpu but apparently it takes more gates than the MicroBlaze soft-cpu that Xilinx provides. BTW you can already run linux on the Microblaze in many Xilinx devices; see my github repo: []


          • Hey, you don't happen to know where I can get a PIC18F core that'll run on a Zynq-7000? I've got an embedded PIC board with code I'd like to try turning "soft", possibly as a peripheral to a soft CPU running Linux, on the Zynq as a "virtual HW" host. Once it's all in gates I want to try porting Linux and PIC code into straight circuits. Possible?

    • by Surt ( 22457 )

      You can't get one with even 10% of a modern intel/amd's performance, and they cost more.

    • by vlm ( 69642 ) on Monday October 24, 2011 @02:13PM (#37821148)

      Where can I get an OpenRISC CPU and a motherboard that will support it, []

      I have not bothered to research why its listed as supporting the Spartan-3A DSP 1800 and not the spartan3 dev board I have sitting at home, probably needs more gates? Or depends on some part of the DSP1800's innards? Or simply the dude who did it owned a DSP1800 as opposed to the board I have at home?

      and how much do they cost compared to Intel/AMD CPUs of similar performance?

      Which vegetable has similar price to an apple or an orange? Perhaps a potatoe?

      The thing with FPGAs is... how much do you wanna spend? I know there are simply gigantic FPGA arrays out there, so on one FPGA chip you could probably put a whole Beowulf cluster of a dozen of these things on one chip complete with the ethernet switch that interconnects them. So its kind of meaningless, like debating the weight of a soul.

      The goal of a FPGA system is not to be a generic processor, but to use the field programability... you use the embedded CPU for generic "who cares how fast" stuff like a user interface, or a TCP network stack, or a DHCP client. You do all the heavy lifting inside FPGA hardware itself. If you used this CPU for a FPGA based mythtv frontend, you would not write a H.264 decoder in the emulated RISC processor assembly language, you'd use a hardware one (or at least hardware accelerated one) inside the FPGA written in verilog or VHDL. If you're running benchmarks on the FPGA processor trying to optimize it, you're probably doing it Very wrong, or trying some insane level of optimization / price cutting.

    • by simula ( 1032230 )
      They are attempting to have an ASIC printed Q1 2012, but they could really use more donations []. Here is a link to details about the system on a chip []. It is really quite revolutionary in that it would be the first completely open source SOC (all the way from the instruction set to the hardware layout).
      • by nurb432 ( 527695 )

        I know they are still trying to get funded for the 'open' project, but didn't some 3rd party already do this about a year ago? Or did that end up just being vapor?

  • by steevven1 ( 1045978 ) on Monday October 24, 2011 @01:03PM (#37820124) Homepage
    Now they just need to fix support for Intel Sandy Bridge processors...
    • by Andy Dodd ( 701 )

      Y U NO FIX? requests are pretty useless without knowing what's broken.

      Even older versions of Linux (such as the kernels included with Ubuntu 11.04) work just fine on Sandy Bridge - I just upgraded and it's great.

      So whatever's broken for you is obviously some specific corner case which you haven't bothered to specify.

  • by the_humeister ( 922869 ) on Monday October 24, 2011 @01:05PM (#37820152)

    Against other open cores such as the SPARC cores?

  • 3.11 (Score:5, Funny)

    by leromarinvit ( 1462031 ) on Monday October 24, 2011 @01:06PM (#37820172)

    I for one am holding out for 3.11. I heard it will be for Workgroups!

  • Whoa, I didn't expect that.
    Some can argue it's unnecessary and that stuff, but I have a classic controller and it's damn good to use with my computer. (I actually use it more with it than my Wii......).

    What is that "barrier" for ext3, btw?

    • by dcowart ( 13321 )

      From the Changelog linked to in the article...

      1.3. Filesystem barriers enabled by default in Ext3
      Hard disks have a memory buffer were they temporally store the instructions and data issued from the OS while the disk processes it. The internal software of modern disks changes the order of the instructions to improve performance, which means that instructions may or may not be committed to the disk in the same order the OS issued them. This breaks many of the assumptions that filesystems need to reliably impl

    • by Meneth ( 872868 )
      WHY did they put this in the kernel? It's just a custom Bluetooth device. Afaik, the driver worked perfectly well in userspace. Also, as far as I can tell [], this new kernel driver doesn't do anything.
      • by iroll ( 717924 )

        This, >9000 times. I don't understand why this would need to be in the official kernel... if somebody really wants/needs it in the kernel, shouldn't they be compiling it in themselves? Why should people have to choose to exclude it?

        Doesn't this mean that future security audits have to include this wii driver? Do bloat-conscious or security-minded people have to cut this out?

        I'm not trying to be sarcastic, I'm genuinely curious, and I'm well aware of how wrong 'common sense' can be when one steps outsi

        • by tibit ( 1762298 )

          Since it is a modular driver, it will IIRC execute nothing at all until the module is pulled in by udev. So there's no need to audit much if you're not using the hardware in question. And if you have physical access to the server, there are ways of subverting it other than hooking up hardware that has security holes in the drivers. So no need for paranoia.

          • by harrkev ( 623093 )

            Since it is a modular driver, it will IIRC execute nothing at all until the module is pulled in by udev. So there's no need to audit much if you're not using the hardware in question. And if you have physical access to the server, there are ways of subverting it other than hooking up hardware that has security holes in the drivers. So no need for paranoia.

            Ummm. Isn't this sort of like saying "Don't worry about the screen door on this submarine. As long as nobody uses it, we are OK."

            • by tibit ( 1762298 )

              Nope. Not at all. You can't really randomly run into this issue without attaching a device first, and if you can do that you may as well own the server in other ways.

              • by harrkev ( 623093 )

                Maybe, but the point still stands: don't throw stuff in the kernel without a very good reason to do so.

                • by tibit ( 1762298 )

                  Since there's on the order of a 100 million wiimotes out there, I'd think just that is a good enough reason. There's plenty of drivers for way less popular hardware in the linux kernel! Less as in an order of magnitude or two less popular.

                • by Vairon ( 17314 )

                  There is a reason to do this. The hardware exists. People want to use that hardware with the Linux kernel. The inclusion of the wiimote driver within Linus' development linux kernel tree just means that driver has become good enough for Linus to redistribute it.

                • Dude it's and HID driver. Linux has more device drivers than any other OS and the standard kernel ships with all of them. If you need a really secure sever you should compile a custom kernel with only the needed drivers built in and disable module loading, and setup some sort of TPM or secureboot to load only that kernel. Plus putting it in the kernel makes sure it the controller has a fast response time.
            • Well, if it concerns you the module can be removed from the system completely. I would also expect the driver to not be built as part of RHEL or SLES distributions, seeing as how it probably has little to no use on a server platform.

            • Yes, if you're in a sub that doesn't have a screen door installed, then you don't have to worry if it can hold water out/air in, which is basically whats going on here.

              The code doesn't get pulled in without the hardware being detected. No hardware, no udev, no exploit. If the hardware is there, then you'll have a udev and an active driver, at which point you can do something about it, since you are aware of the hardware in your machines generally when you're that paranoid about security.

          • by sjames ( 1099 )

            Typically, the module will be deleted from the server since it isn't supposed to be used. That done, there's no need to further audit it.

        • by Vairon ( 17314 )

          This is how the Linux kernel development process works. If someone writes a Linux driver for a piece of hardware they can usually get that driver into the main kernel tree if they follow the proper process. The Linux Kernel Mailing List FAQ covers this here: [] It says that the driver must be tested successfully by other people. The code has be written against the latest kernel. Coding standards and best practices have to be followed. This driver has just as much right to be the

        • by k8to ( 9046 )

          How is this any different from an ethernet card driver you aren't using?

      • Try this link []

    • The Wii controller is a very nice set of sensors in a cheap package. Researchers have already done cool stuff with it.

      I'd say it's anything but unnecessary, even if most people likely won't use it.

      • by LWATCDR ( 28044 )

        True but I would love for Linux to add a standard interfaces for SPI, GPIO, and ican. That could help embedded developers a lot.

        • by mirix ( 1649853 )

          SPI and GPIO support exist (i2c too), it's just very hardware dependent and needs to be configured with board-specific bits at compile time.

          GPIO []
          SPI []

          Not exactly easy at first. There are userland extensions to all of the above too, which is fine for blinking LEDs and such, but has some limitations... spidev only has certain modes and data lengths, /SS lines are defined in board config (so kernel compile to change), things like that.

          • by LWATCDR ( 28044 )

            I knew that i2c was around but the dev board I used all had proprietary interfaces to the GPIO and SPI.

          • by LWATCDR ( 28044 )

            Sorry to double post but that is really handy. Now IAMFT I just need to write code to convert a Centronics port to GPIO and and bit banged SPI

  • Is there an FPGA big enough to implement the OpenRISC on it? Has anyone done that yet?

    • There have been FPGA's big enough to implement OpenRisc on now for at least 13-14 years. I designed an OpenRISC based system that included additional logic many times the size of the OpenRISC on an FPGA in 2002 and designed and manufactured an ASIC with most of the same logic in 2003. These repeated "Someone just built the first opensource chip/system/board/hardware etc" threads on Slashdot make me laugh. Does anyone do any research anymore?

  • They desperately need more funding to produce a ASIC version required for Linux support to mean much: []

Can anyone remember when the times were not hard, and money not scarce?