
RISC-V port merged into Linux 4.15 - rwmj
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/2-u-c3kyZlc
======
nickik
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.

~~~
pjc50
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.

~~~
ansible
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.

~~~
throwaway613834
For those of us who don't know what is involved in power management, would you
mind giving a quick explanation of what it involves and why it's painful? What
power is there even to manage unless you want to put the computer to sleep or
shut it down? Or are those the sole things your are referring to?

~~~
cjbprime
Not the OP, but there are many (tens of) "power domains" on the system, and if
you care about power/battery life then you want to power each of them down
when they're unused, automatically, even while the rest of the system stays
running. i.e. why pay the battery life cost for powering a USB hub when there
are no USB devices plugged in, or for a DSP when there's no sound being played
right now.

But the calculation of when it's safe to power down any of the power domains
can be very complicated -- you can't turn off a power supply unless everything
that depends on it is unused, so there's a subtle and board-dependent
graph/dependency problem to solve.

~~~
klodolph
Piggybacking on this—what can make it worse is that some chips might not
properly power back on reliably, in spite of the manufacturer's claims.

------
mmjaa
I'd really like to jump on the RISC-V bandwagon. Does anyone have any
recommendations for hardware that would be .. somewhat .. future-proof for
hacking/experimenting on this platform? I'd love to have a board or two akin
to the rPi-Zero in form-factor, if such a thing were available ..

~~~
srcmap
Also, is there any (low cost?) FPGA board that is capable of running RISC-V +
Linux?

That would be a fun thing to to do.

~~~
kbeckmann
Found this blog with someone who bought an FPGA devkit[1] for £260 and managed
to boot Linux on it[2].

[1] [https://rwmj.wordpress.com/2016/07/25/risc-v-on-an-fpga-
pt-1...](https://rwmj.wordpress.com/2016/07/25/risc-v-on-an-fpga-pt-1/)

[2] [https://rwmj.wordpress.com/2016/07/26/risc-v-on-an-fpga-
pt-4...](https://rwmj.wordpress.com/2016/07/26/risc-v-on-an-fpga-pt-4/)

------
phantom_oracle
Can someone explain what having RISC-V support in the kernel means for Linux
OSes ?

Also, how is this different to:
[https://wiki.debian.org/RISC-V](https://wiki.debian.org/RISC-V) ?

~~~
davidlt
Stable ABI. We have done ~Fedora 25 in late 2016 -
[https://fedoraproject.org/wiki/Architectures/RISC-V](https://fedoraproject.org/wiki/Architectures/RISC-V)
and you can even boot that in your browser -
[https://bellard.org/jslinux/](https://bellard.org/jslinux/)

ABIs have changed after we did this. We get the first long-term stable ABI
with 4.15 kernel and glibc 2.27 (hopefully). At that point Fedora, Debian, and
others can reboot efforts.

~~~
phkahler
That was great work and it made RISC-V look that much more viable to me. To
think that thousands of programs are ready to go whenever the hardware arrives
is really amazing. It's unfortunate that some of it has to be repeated after
the ABI changes, but that seems a small price to pay in the grand scheme of
things. But then I'm not the one who did it or has to redo it ;-) Anyway,
great job guys!

------
ramshorns
Here's an archive mirror that works without JavaScript:
[https://archive.fo/kVvQZ](https://archive.fo/kVvQZ)

------
thisispete
RISC is good.
[https://www.youtube.com/watch?v=wPrUmViN_5c](https://www.youtube.com/watch?v=wPrUmViN_5c)

------
acoye
With Google's new war on Intel's ME this is not a coincidence.

~~~
_chris_
Actually it is.

~~~
acoye
Yes you are right, no causation just a funny correlation.

