Experimental Port of Debian To OpenRISC

Via Phoronix comes news that Debian has been ported to the OpenRISC architecture by Christian Svensson. Quoting his mailing list post: "Some people know that I've been working on porting Glibc and doing some toolchain work. My evil master plan was to make a Debian port, and today I'm a happy hacker indeed! ... If anyone want to try this on real hardware (would be very cool to see how this runs IRL), ping me on IRC [#openrisc on freenode] and I'll set you up with instructions how to use debootstrap - just point to a repo with the debs and you're all set, the wonders of binary distributions." For those who don't know, OpenRISC is the completely open source RISC processor intended as the crown jewel of the Opencores project. A working port of glibc and a GNU/Linux distribution is a huge step toward making use of OpenRISC practical. There's a screencast of the system in action, and source on Github (at posting time, it was a month out of date from the looks of it). Christian Svensson's Github account also has repos for the rest of the toolchain.

Comments

OpenRISC hardware?

[Anonymous Coward]

Without knowing anything about it I'm guessing that or1ksim is a hardware emulator of some kind. What "IRL"hardware can I buy?

Re:OpenRISC hardware?

[Rufty]

Well, these, but they look more OpenWRT than Debian.

Re:OpenRISC hardware?

[Anonymous Coward]

OpenRISC has been implemented as an ASIC, mainly in embedded systems, so you can't do out an buy an OpenRISC motherboard (yet). Apart from that, your option is to implement it with an FPGA.

nice!

[dmitrygr]

very very cool porting debian userspace to a new arch is a fun exercise

Re:Here's a question

[gman003]

FPGAs, I assume.

You don't need your own plant.

[pavon]

You don't need a multi-billion dollar plant to make the processors. You just need to pay someone who does. You can get small quantities of ASICs made for around $2-5k by taking advantage of programs that put many designs from different people on the same wafer.

Re:You don't need your own plant.

[unixisc]

Actually, since this is a CPU that exists only on FPGAs programmed w/ its code, that would be the platform on which it could run while its volumes are low and there is little demand, until such time that the support platforms that it needs, as well as the software is up and out there. You'd only do ASICs once the FPGAs hit economics of scale, and when it's no longer possible to shave costs from the processor when it hits mass production. Given the volume needed to get a fab running - I have no idea how expensive it is now at the less than 25nm nodes, it would make more sense for a company to just buy the FPGAs it needs from the Alteras/Xilinxs/Amtels of the world. If and when it hits volume, they could then take the designs and spin out ASICs or discrete CPUs and run w/ them

The other advantage of sticking w/ FPGAs for a while is that it gives them time to discover and iron out any bugs in the design. Also, once the CPU itself is fabbed, the FPGA based model can continue to run in case any bugs or other manufacturing issues hit the CPU. Once those things are over, the transition from FPGA to CPU based sales can be completed

Re:You don't need your own plant.

[pavon]

You can now deal directly with TSMC for this, or go through third parties like MOSIS and CMP. AFAIK none of the groups that do this publish their rates, and I haven't done this myself, so my numbers come from forums like this one, rounding up the lower numbers that I have commonly seen.

Open source chips

[unixisc]

Point is that since the chip's HDL models are available, w/o any legal restrictions, theoretically, any company w/ a multi-billion dollar fab can take the design, tape and fab it out using those models. In practice, such a company would have to hire its own design, device, process and product engineers to actually produce such a chip. But their designers would essentially have to tweak the designs to the process to meet certain spec parameters, not to build the CPU at gate level from scratch.

This is sort of the point w/ open source hardware, just like w/ open source software. Open source software doesn't actually have to be good or even necessarily work - it just has to be open, but getting it to work and work well is one of the long term visions that the model is supposed to support. This is even truer about open source hardware. Theoretically, any number of fabs can take the OpenRISC HDLs and try spinning out chips based on that. In reality, anyone who really wants to do a good job there would have to hire the engineers needed to actually make it work.

One thing I wonder about at hardware level - let's say the HDL code has been tweaked for process variations: does that have to be published, as per the GPL? I can see that being a showstopper - why should any fab publicly publish internal process defects or issues, which could be used by competitors to calculate their real costs? I would imagine that to be the main reason why no foundry company has chosen to take OpenRISC and make a CPU w/ its HDL code - why take that risk?

Re:Open source chips

[Darinbob]

Another good advantage of OpenRISC is that it is open for students to examine and use and experiment with. There are some other CPU designs that are available but they tend to be much smaller or not as full featured.

Re:Here's a question

[wiredlogic]

You can easily get a 32-bit processor running at 50-100MHz on current low end parts. Linux runs perfectly well at such speeds. A modern compositing Xorg desktop will likely be bog slow but a console will run just fine. These aren't supposed to be used as general purpose desktop replacements.

Re:Here's a question

[Darinbob]

Include it as a part of your design. Ie, embedded systems in software may be able to use Linux or BSD as the kernel and then have their own user space applications or patches into the kernel. So OpenRISC is the same idea except in hardware. This is relatively common for example with customer system on chip designs: stick in an ARM core, add some standard peripherals you need, and add custom blocks for a particular application. If you've got volume then make an ASIC out of it all and the cost per chip is very small. If you have less volume and customers don't mind the price, then stick the entire thing onto an FPGA. There are many applications for this sort of thing.

Current company I'm at has a custom ASIC with ARM core on it without needing a multi-billion dollar plant. Previous company used a discrete PowerPC but also a set of much more expensive FPGAs on the side; it could have been interesting to have the front-end CPU inside an FPGA instead, with more flexibility, tighter integration, faster data paths, fewer parts, etc.

RE Open source chips

[olof_k]

Hi, Having worked on the OpenRISC project for ~4 years I thought I could share some insights here, as the licensing question pops up all the time. The RTL for OpenRISC and most of the peripheral controllers that are used are licensed under LGPL, not GPL. While we all know that this is a software license with some concepts that don't translate well to hardware, the consensus is that LGPL means that you are obliged to shared modifications of the LGPL-licensed core, while GPL-licensed RTL would require the whole SoC to be GPL.

This is a view that we in the OpenRISC community share with the Open Source Hardware developers at CERN and other groups. This has also been tried by IP lawyers for a large company that wanted to use OpenRISC about ten years ago.

As for ASIC implementations it could be worth mentioning that there are ASICs running or1200 (the original LPGL-licensed OpenRISC implementation) in Samsung Digital TVs, in some of the Allwinner SoCs, Zigbee ASICs and other places, so it has been done many times over the years