RISC-V port merged into Linux 4.15

https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/2-u-c3kyZlc

by rwmj • 9 years ago

296 72 9 years ago

groups.google.com

nickik2• 9 years ago

I love how once this exists in all the standard tools, anybody can just make a new chip and practically instantly run huge amounts of software on it and have the right base to add to it. A free ISA is a great interfacing point, innovation can go on above and below mostly independently, no licences or anything required. A good example of permission less innovation.

The road is long for RISC-V but I think the project is progressing about as fast as one can hope for. Thanks to everybody who helps with this.

madez3• 9 years ago

While it is true that a lot of software is available immediately, there is also software which is not. For example PC games are nearly always restricted to x86. Performance of common non-x86 hardware might not be enough to run the latest, demanding games, but. I don't see why games like Factorio, Stardew Valley, Lethal League, Don't Starve or Bastion couldn't run on less powerful hardware. Great games do not require demanding hardware.

One problem is that games are usually closed source and are rarely freed. Another problem is that there are no open graphics driver for common single board computers. The latter problem is being worked on by the amazing Mesa project. What can be done about the former?

I worry that games will be abandoned and never be freed. The copyright of movies eventually expires and they become a common good. What about closed binaries compiled for obsolete hardware and software?

cyphar3• 9 years ago

There are quite a few communities around creating free engines for games, such as OpenMW[1] (there are plenty more). With a free engine all of those problems can be resolved.

As for movie copyright, this is the true purpose of DRM -- to try to make copyright eternal by locking away the content behind strong-enough encryption and then licensing the keys. And of course, breaking DRM (even if the content itself is no longer protected by copyright) is a felony.

[1] https://openmw.org/en/

zanny2• 9 years ago

This is going to be one of the most embarassing chapters of world history in a few centuries.

"Oh yeah, all those old folk at the turn of the milennia had this thing called copyright and all their code was proprietary so we no longer can run or use 99% of software written between 1970 and 20XX".

"And there are these files where it was a felony to be able to access them!"

Wow those guys were sure dumb. Now all our information is open and shared and makes the world a better place and anyone can use it or improve it!

All I can is lets hope its only until a 20XX that we get over the facade of IP being worth the cost.

imtringued• 9 years ago

I have switched to opensource alternatives primarily because of the freedom to recompile it to different architectures.

Another problem is that there are no open graphics driver for common single board computers. The latter problem is being worked on by the amazing Mesa project. What can be done about the former?

Can you tell me more about this?

ekianjo• 9 years ago

I know its not ideal but x86 can run on arm via a x86 processor emulator, and then WINE to convert windows systems calls and directx calls to Linux and OpenGL. So nothing will really be lost as long as WINE lives on as a project.

pjc50• 9 years ago

What about the boot sequence and driver enumeration? How is this handled in RISC-V? This has traditionally been one of the major obstacles to ARM - you need different kernels for two ARM devices with nominally the same core because of initialisation differences.

Devicetree makes this better but not 100% as simple as the old "legacy" PC boot sequence was. Ironically these days PCs are quite hard to boot too with UEFI.

nickik2• 9 years ago

There are still many issues left and it will not be easy to figure out all these things. It will have many of the same problems as ARM but hopefully the community can work on these.

rwmj3• 9 years ago

For servers, they're looking at ARM SBSA as a model. There's already some starting work on UEFI for RISC-V (done by HPE).

jws• 9 years ago

PCs are quite hard to boot too with UEFI

Let's hope RISC-V can avoid something stunningly complex like ACPI while they are at it. You might be trying to write a secure OS of well reviewed code, then suddenly find that to reliably shut down a PC you need ACPI which drags in 100000 lines of code including an interpreter capable of accessing arbitrary physical addresses. (Or you just try all the shutdown mechanisms you've ever heard of and hope one of them nails the machine you are running on.)

I wonder if hardware is easy enough now that a platform could require that all optional hardware respond with a UUID during an enumeration phase. That would have been a burden back in early ISA days when things were as simple as a couple registers on a card, but maybe now it isn't. Then the OS can handle the ones it knows about and leave the rest alone.

ansible3• 9 years ago

Heh. Device Tree only deals with a fraction of the problem.

Here's what I think would help: (warning: lots of work!)

1. Large database of free peripherals and foundational blocks. Not just UARTs and SATA controllers, but also network interconnects (crossbar), SDRAM controllers, and all the other bits that go into a modern System-On-Chip (SoC). Power management is a huge pain in general, and is widely different among chip families even from the same vendor.

1.A. Obviously, the above implies a decent set of open-source drivers for multiple operating systems for the peripherals. At the very least, you need support for a bootloader, a real-time OS, and Linux. Preferably with no binary blobs.

2. A standard for enumeration of these on-chip peripherals. There should be a way to query the chip itself to see what is included in the SoC, what device addresses they have, what options are enabled (like how many interrupts), and how the peripheral lines (if any) are connected (IO mapping).

3. Some widely-accepted standard for storing the board configuration as well. This could just be a I2C EEPROM, but it has to have a listing of everything connected to the SoC and how. This I2C is mapped to these pins, and has this accelerometer connected at this I2C address. And all the hardware manufacturers (who produce the boards) have to be convinced this is a good idea to have this extra cost (and space) built into their products.

Only after all that would you have a fighting chance to boot a relatively generic kernel and have it actually run. And then have a fighting chance to have the ability for the end-user to upgrade the software after the manufacturer has ceased support.

The cross-platform situation with PCs is light-years ahead of where we are in the embedded space.

lloeki• 9 years ago

as simple as the old "legacy" PC boot sequence was.

Some of the Hackintosh folks know how much this can be false. As soon as you step out of real mode / VESA graphics, all bets are off, those ACPI tables can be a real PITA, and you may have to fix stuff by extracting, editing and recompiling your SSDT/DSDT, at which point you generally wonder how the stock ones worked at all in the first place: missing symbols, broken CPU state tables... (well, deep inside you know, Windows/Linux are doing a hell of a job doing their best at working around all that mess)

jjawssd2• 9 years ago

It is impressive to see a new architecture already have so much support for existing software with a relatively simple hardware support layer. It is already standing on the shoulders of giants with millions of man-hours invested in software development to bring it to its current state.

RISC-V port merged into Linux 4.15

Related Stories