
HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit - mwcampbell
https://www.sifive.com/products/hifive1/
======
TD-Linux
I looked over the Chisel source code and the barebones datasheet [1]. This
chip has a couple of unique features:

1\. It doesn't have any onboard NVRAM (same limitation as the open-v).
However, it does have a directly memory mapped quad-SPI peripheral and icache,
which is a great alternative and might be better for applications that require
a large amount of data. Note that an icache would still be required even if it
had onboard NVRAM, because of its speed. You could also make swappable game
cartridges, for example.

2\. It has enough RAM and speed to run Opus.

3\. The rest of the peripheral set is pretty barebones, no analog like the
open-v has. No I2C or I2S without bitbanging, either.

4\. The boot ROM has peripheral information stored in it. You might be able to
have one binary that boots on different types of cores using this.

[1]
[https://dev.sifive.com/documentation/freedom-e300-platform-b...](https://dev.sifive.com/documentation/freedom-e300-platform-
brief/)

~~~
rwmj
I'm worried this leads to the zoo of random hardware that we see on ARM, which
makes supporting Linux distros on ARM such a PITA.

It would be better if the basic hardware — serial ports and such — was in a
standard location for all RISC-V machines, and all the rest of the hardware
was discoverable at runtime (like PCs, mostly).

~~~
rwmj
The parent comment has proven oddly controversial going down to 0 and up to +5
and back down again. So let me try to do better and clarify what I mean. For
context, I am maintaining Fedora on RISC-V:
[https://fedoraproject.org/wiki/Architectures/RISC-V](https://fedoraproject.org/wiki/Architectures/RISC-V)
.

On a PC, there is a serial port at a standard location. It's not
"discoverable", but every PC you care about has one at the same address, and
it's incredibly easy to use with a tiny bit of assembler. You can always print
messages, even in the earliest parts of early boot.

On non-PC platforms (I've used ARMv7, ARMv8, POWER) there's a zoo of serial
ports. There are at least a half dozen different bits of hardware, on
different ports, self-describing, not discoverable at all, or mentioned in
device tree in multiple different ways. Some even require PCI so needing ugly
hacks to output early boot messages.

Critically, if you get the wrong serial port, you _cannot see any boot
messages at all_. There's no way to tell what's going wrong.

So I think, for serial ports, the PC approach is definitely, clearly better.

For other hardware, it should just be self-describing. PCI and USB are the
model examples here. And in fact, why not just use those?

~~~
microcolonel
I agree on the serial port thing. That's one device which I think should be
architecture-standard. I can't imagine bringing up firmware or debugging a
kernel without a low-level system serial port. It also makes remote management
a lot easier, because the remote console can hook into that in a standard
fashion.

------
smilekzs
320 MHz core clock is very impressive, compare to <= 200 MHz typical of
Cortex-M3/4 impls. However at this freq, flash (instruction) readout becomes
the bottleneck. While Cortex-M chips typically include some on-chip flash
acceleration, this chip instead went for external flash + I-Cache. The new
Cortex-M7 chip STM32F7 has both flash accel and I-Cache. It remains to be seen
whether this chip can sustain real-world workloads at 320 MHz with 0 wait
state. Even at 200 MHz it has the potential to replace proprietary fixed-point
low-end DSP chips.

~~~
childintime
Modern non-volatile RAM technologies (like XPoint) would be perfect for chips
like this. Much faster than flash and usable as RAM.

------
ChuckMcM
I like that 3.3V and 5V I/O is supported, so many Arduino shields assume 5V
and so "compatible" boards like the ST Nucleo boards aren't actually
compatible.

------
andkon
For someone who has no idea what RISC-V is but loves making things with
Arduino, what new things could I do with this?

~~~
fuzzythinker
Agree, for some who has no idea what RISC-V is, which I'm guessing is more
than 50% of visitors, the "why" on the page needs to sell me on why RISC-V is
better or at least better for certain things.

~~~
wyager
If you aren't interested in architecture, there's probably no particular
reason for you to buy this at this point. RISC-V is just getting started, so
there aren't huge practical benefits yet. In the long run, we'd obviously
prefer to use open-source unencumbered hardware, which is the point of the
RISC-V project.

~~~
cestith
If RISC-V really takes off and you're a first mover writing the low-level
stuff for it then the early mover advantage is a good investment.

------
cmrdporcupine
320mhz clock speed but only 16KB of RAM.

RISC-V is appealing but if I'm stuck at 32KB or less of RAM I'd stick with the
Parallax Propeller which has 8 parallel 100mhz cores.

~~~
cr0sh
I'm not sure that's the whole story - specs read:

Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad

I'm wondering if it's possible to combine that or dice it in some way? On top
of that, the program resides in SPI flash (128 Mbit -> 16 meg).

EDIT: ok - the above makes no sense, so yes, on 16K on-board RAM (and the
other is for cache).

Short of more info, I'd be willing to bet that some of that flash can be set
aside (or used like) variable space (albeit at a slower speed), and the on-
board memory is more for high-speed stuff (and you'd have to swap things
in/out - though likely they'll have a library for all of that - maybe).

If all of that is true (or close to the truth) - well, I don't know if it
would be better than the propeller or whatnot, but it certainly looks
interesting...

EDIT:

Reading the infosheet on the processor:

[https://dev.sifive.com/documentation/freedom-e310g-0000-manu...](https://dev.sifive.com/documentation/freedom-e310g-0000-manual/)

It does seem like the flash can be used for data and program space - and it
appears like it can be read/written to from the cpu - so it's kinda like the
flash storage on the Arduino. I would imagine it can be used similar -
although slower - as variable memory (given a proper lib); and "paged" into
the faster on-board 16k RAM.

~~~
mwachs5
You're correct, you can access the 128MBit SPI Flash as any other read-only
memory mapped memory -- you can execute out of it or load data (you can also
write to it but need to use a seperate channel, it's not directly memory
mapped to write).

You're also correct on the sizes of the ICache and Scratchpad. You can execute
code which resides in the scratchpad, but can't store data in the I-Cache.

~~~
cmrdporcupine
Does the MCU expose address lines to wire in external RAM?

~~~
Sanddancer
No. The only external addressing is through QSPI0, and that only has one chip
select line hooked to it. They do make small amounts -- 512k -- of SPI RAM,
but that on its own would make the chip boot process interesting.

------
i336_
Two points: a short question and a longer theory about why only 16KB.

The question: how viable is an open-source, publicly-auditable secure boot
implementation? Not TPM theater or whatever, but a hardened hardware
configuration that could be used to implement _truly_ verifiable boot.

(If anyone from RISC-V is reading this, I think there is a very noteworthy
amount of money in building a _truly_ securely bootable reference design.
Hopefully lots of people have already told you that.)

\--

Next, regarding why only 16KB RAM...

I'm very interested in the potential of open source ISA, but admittedly
completely ignorant about chip design.

With this in mind, I have a theory that the manufacturers deliberately
provided a ridiculously low amount of RAM in order to make it impossible[1] to
run Linux on it and so keep it out of the mass market.

Considering the CPU is full 320MHz I don't think this is because they have
some other product up their sleeve. Rather, looking at the fact that this is
the first marketed product they have available that's an actual real chip
(!!), I would expect that either the chip itself and/or the chipset likely has
bugs in it. They've gone through many internal revisions, and now they feel
comfortable with putting the chipset out there for public testing to get
bugreports from the field.

My thinking is that applications that will play nice with 16KB of RAM will
stress the CPU out significantly less than full Linux would, similarly to how
doing basic tasks on a faulty x86 PC may work for years but compiling GCC will
find broken bits in RAM sooner or later.

There's also the fact that such projects are also generally quieter as a whole
than the thundering herd of people wanting to run Linux on things.

Don't forget, RISC-V has been nothing more than a bunch of VHDL for years,
running on "perfect" FPGAs that don't require you to think about low-level
electrical niggles and whatnot. If I'm understanding correctly, this is the
first time a real RISC-V chip run has been done (?) and made available to the
market.

Considering the success of ARM (or, more generically, the market sector of
"little PCBs that run Linux"), RISC-V needs to stay competitive and attractive
- and full Linux that constantly oopses in mm.c will make RISC-V look real bad
real fast. I definitely want the ISA to thrive, and if my assumptions are
correct capping the RAM makes an inelegant-yet-elegant sort of sense.

I expect RISC-V will be running Linux on real fabbed chips within the next two
years.

[1]: Well, _practically_ impossible. If you don't mind 300KB/s RAM (yes, KB/s,
not MB/s) there's always
[http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20...](http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit)
:D

~~~
pjc50
> how viable is an open-source, publicly-auditable secure boot implementation?

Depends if you trust your fab. I suppose you can take random samples and decap
them at considerable expense, but then the public has to trust the auditor.

> I think there is a very noteworthy amount of money in building a truly
> securely bootable reference design.

I disagree. I think there are two critical problems with this: firstly,
getting the community to agree on what they consider "truly secure", and
secondly getting enough people to buy a system that is (necessarily due to
small production runs) slower and more expensive than comparable Intel or even
ARM.

If you're willing to trust a manufacturer you can buy secure-bootable ARM
devices today with OTP key regions that boot Linux (e.g. iMX). So the market
for the proposed "open" system is _only_ people who are willing to trust you
but are paranoid enough to not trust one of the existing manufacturers.

~~~
i336_
All these points are very true; chains like these are unfortunately based on a
root of implicit trust.

I make some counter-arguments:

Secure boot forms the trust basis that the device is definitively running the
code you put on it without modification, so is arguably the most security-
sensitive aspect of the system, in some ways more critically so than the
kernel, network-facing daemons, etc. It is at least _as_ important as those
components.

I'm confident a publicly-auditable open-source secure boot implementation
would attract fairly reasonable academic interest from the security field and
be hacked on (from theoretical design down to implementational edge cases) by
the community until it was very very good.

That would help avoid this sort of thing - [http://www.cnx-
software.com/2016/10/06/hacking-arm-trustzone...](http://www.cnx-
software.com/2016/10/06/hacking-arm-trustzone-secure-boot-on-
amlogic-s905-soc/) \- which is currently only an issue because vendor
engineering teams are not perfect and there's no widespread collaboration.
(There is, of course, also the likely truth that there are similar
"vulnerabilities" in all commercial secure boot implementations. Think
TSA007.)

The one issue I will acknowledge is that if such a reference design existed
and was widely implemented, it would be a very good question as to which
manufacturers had "accidents" in the manufacturing process near the secure-
boot areas of the chips.

If I understand correctly, the other very major issue (which is kind of really
ironic considering what I've just said) is that you have to sign NDAs to
understand how the implementation works, and AFAIK even to just use it. So I
(a random tinkerer) can't configure a "really trustworthily secure" Linux
system, only a major manufacturer/system integrator/etc can. I understand this
situation but from the standpoint of paranoid individual security it's crazy -
security by obscurity, anyone?

If it is possible for me to play with OTP on iMX from a hobbyist perspective
without shelling out for some NDA'd SDK, I'm tentatively interested for what
it's worth.

~~~
pjc50
imx53 is sort of possible to play with:
[https://cache.freescale.com/files/32bit/doc/ref_manual/iMX53...](https://cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf)

Boot documentation is chapter 7. References "high assurance boot"
functionality in the onboard boot ROM, but doesn't give out docs for the ROM.
On the other hand, it's not a large ROM so you could just dump and reverse-
engineer it.

~~~
i336_
Interesting... but I find it really amusing that my propositions are to
reverse-engineer the secure boot system in order to take advantage of it, and
also the fact that the reverse-engineering process won't be that hard. For
what I assume is a security-by-obscurity design... reverse-engineering should
by definition be really hard I would think, at least at face value.

------
Klasiaster
So does it have a MMU? That would make it even more superior to Arduino
boards.

~~~
mwcampbell
It seems to me that an MMU is no good if the board doesn't have enough RAM to
run a general-purpose operating system, as opposed to a bare-metal program or
a real-time OS like a microcontroller usually uses.

~~~
wolfgke
> It seems to me that an MMU is no good if the board doesn't have enough RAM
> to run a general-purpose operating system, as opposed to a bare-metal
> program or a real-time OS like a microcontroller usually uses.

For a realtime operating system at least a Memory Protection Unit (to use the
word that ARM introduced for this limited form of an MMU) is very useful since
it can easily make the OS much more reliable if a process cannot write to
memory adresses of the kernel or other processes.

EDIT: Or is such an MPU implied by the support for "Privileged ISA
Specification v1.9.1"?

~~~
pjmlp
> is very useful since it can easily make the OS much more reliable if a
> process cannot write to memory adresses of the kernel or other processes.

If you make use of memory safe systems programming languages on bare metal,
like Ada, SPARK, Rust, Oberon-07 than it isn't usually an issue, since the
unsafe code will be quite constrained.

For example,
[http://www.astrobe.com/boards.htm](http://www.astrobe.com/boards.htm)

