Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

sifive.com

Post reply on HN
Print view View original

81–90 of 97 posts

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#81

Post by i336_ »

pjc50 wrote: post #77
i336_ wrote: post #75

Earlier quoted context omitted.

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 import…

imx53 is sort of possible to play with: https://cache.freescale.com/files/32bit/doc/ref_manual/iMX53... 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.

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.

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#82

Post by i336_ »

pjc50 wrote: post #79
i336_ wrote: post #71

Earlier quoted context omitted.

> The whole of your second point is ridiculous conspiracy theory. Theory, yes. Conspiracy theory, emphatically not, sorry for the misunderstanding. I have no ill will towards the RISC-V ISA and no disagreement with SiFive's operations. Like others here I was just trying to figure out the huge disparity between the CPU clock speed and the onboard memory, in my case with sorely insufficient understanding of the field.…

> huge disparity between the CPU clock speed and the onboard memory I think that's RISC "working as intended"; the tradeoff was always supposed to be that you got to issue lots of simple instructions at high speed. I can't find what manufacturing process they're using (?nanometers) but it sounds like it's simply a "why not?" outcome of the design process that the chip is very fast. It doesn't have all that many perip…

>> huge disparity between the CPU clock speed and the onboard memory

> I think that's RISC "working as intended"; the tradeoff was always supposed to be that you got to issue lots of simple instructions at high speed.

I see.

> I can't find what manufacturing process they're using (?nanometers) but it sounds like it's simply a "why not?" outcome of the design process that the chip is very fast.

Heh.

> It doesn't have all that many peripherals either, by modern standards.

This looks to me to have all the hallmarks of a first-gen MVP. A very decent offering likely with some long-term support, but an MVP nonetheless.

> Edit: the answer is here - https://news.ycombinator.com/item?id=13067833 - other chips that have onboard Flash are necessarily slower. This doesn't, so it can be faster.

I noticed that, it's a fascinating design tradeoff they picked.

> SRAM just takes up a lot of space. Hard to tell without gate counts or die shots but the 16k+16k could easily be over half the die.

Wow, TIL

> EPOC is one of those extraordinary things that can be called a great technological achievement with a tiny dedicated fandom that nonetheless became a dead-end. Like Amiga, Concorde, BBC Domesday Project, etc. I do wish we could have snappier GUIs on our ten-times-faster systems.

Mmm. I consider it insane that the Web is as slow as it is, but it makes a sad sort of sense. I've been wondering about making a cut-down general-purpose information rendering engine with a carefully-designed graphical feature set that's really easy to optimize. Would be really cool.

EPOC was awesome: some hand-wavy testing showed me that the OPL environment was fast enough to support full-screen haptic scrolling of information. It would have totally worked in just a few simple lines of code. If only full-panel capacitative touch were viable in '98 ;)

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#83

Post by david-given »

TickleSteve wrote: post #64
david-given wrote: post #63

Earlier quoted context omitted.

This is the first time I've come across this concept (outside the ESP ecosystem); just to check I'm understanding this correctly, this means I can hook up a serial SRAM or equivalent device and the hardware will automatically demand-page arbitrary amounts of code out of it, right? What's the throughput like? Can this be used for data as well (which will need caching too)? Because this suddenly makes the device much m…

No, the QSPI device is simply memory mapped as in quite a lot (most) microcontrollers. The external QSPI FLASH just appears in the normal memory map, no demand-paging. Normally used for eXecute-In-Place code (XIP) when the code is too large for the internal FLASH. There is a performance trade-off, and external QSPI FLASH might run its bus at (for example) 50MHz, but thats still much slower than internal FLASH directl…

But SPI devices can't be memory mapped --- it's a serial protocol and they can't be attached to the bus. For this to work, something must be converting bus accesses into SPI requests. And then, at least assuming it's not doing an SPI read for every access, it needs to cache the result somewhere... but you've just said it's not doing demand paging?

I am now really confused.

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#84

Post by pawadu »

kristoffer wrote: post #74
pawadu wrote: post #66

Earlier quoted context omitted.

or we could continue using device trees, which are much more expressive and were actually designed for this purpose.

Device trees needs to be written to match the hardware, compiled and supplied to the kernel. So not really as nice as "boot this kernel on any hardware". Device trees are needed because manufacturers did not create self describing hardware.

> Device trees are needed because manufacturers did not create self describing hardware.

This is impossible to do beyond trivial components. Most devices are complex systems of interacting components.

Also, do you want the same lazy manufacturer that couldn't bother to create a device tree create a complete hardware description ROM and get it right in the first attempt?

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#85

Post by MagerValp »

ChuckMcM wrote: post #39
TD-Linux wrote: post #29

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…

You can bit bang a lot with 320Mhz cycle time :-). That said I wonder if we'll see a common standard emerge for an 'open' serial protocol. Sort of PCIe lite which runs at say 250Mhz over a pair of LVDS pins that you make into an AHB bus master in the memory matrix. That would really open up the peripheral market.

My experience is mainly from 8-bit CPUs, but unless you can afford one IRQ per bit, won't you just be busy waiting at 320 MHz instead? Performance tends to be less of a problem than the fact that you can't do anything else at the same time.

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#86

Post by kristoffer »

pawadu wrote: post #84
kristoffer wrote: post #74

Earlier quoted context omitted.

Device trees needs to be written to match the hardware, compiled and supplied to the kernel. So not really as nice as "boot this kernel on any hardware". Device trees are needed because manufacturers did not create self describing hardware.

> Device trees are needed because manufacturers did not create self describing hardware. This is impossible to do beyond trivial components. Most devices are complex systems of interacting components. Also, do you want the same lazy manufacturer that couldn't bother to create a device tree create a complete hardware description ROM and get it right in the first attempt?

So x86 has no non trivial components?

It would probably force the hw manufacturer to think through its design a little bit more, which would be a good thing. I've seen enough of these SoCs with "complex system of interacting components" to feel that a well thought out design that needs less static description of SoC/board/cpu level details would be beneficial.

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#87

Post by rwmj »

pawadu wrote: post #84
kristoffer wrote: post #74

Earlier quoted context omitted.

Device trees needs to be written to match the hardware, compiled and supplied to the kernel. So not really as nice as "boot this kernel on any hardware". Device trees are needed because manufacturers did not create self describing hardware.

> Device trees are needed because manufacturers did not create self describing hardware. This is impossible to do beyond trivial components. Most devices are complex systems of interacting components. Also, do you want the same lazy manufacturer that couldn't bother to create a device tree create a complete hardware description ROM and get it right in the first attempt?

In practice "self describing" doesn't mean the hardware completely describes everything about itself. It only needs to describe enough that the OS can load the right driver and the driver can locate the hardware address, interrupts and so on. After that the complexity resides in the driver itself. PCI has been doing this sort of thing successfully for two decades, so we know it's possible. ACPI has been doing the same thing for power management, clocks, power zones, suspend etc, again for something like two decades.

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#88

Post by cestith »

wyager wrote: post #24
fuzzythinker wrote: post #13

Earlier quoted context omitted.

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.

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.

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.

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#89

Post by cestith »

cmrdporcupine wrote: post #17

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.

You seem to be a more likely customer of their U500 platform, at over 1 GHz, 64 bit, cache-coherent multicore, DDR3/4 controller, USB 3.0, PCIe 3.0, and gigabit Ethernet. That one's also on a 28nm, process rather than 180nm. That should run Linux or an equivalent like the Raspberry Pi 3 or the Pine64 can. They don't seem to have an SBC ready for market with that chip yet.

This is their embedded / tinker / maker single-board computer based around their E300 platform with on-board SRAM. It's more like an Arduino or a Pi Zero.

Re: HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit

#90

Post by H3g3m0n »

ChuckMcM wrote: post #39
TD-Linux wrote: post #29

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…

You can bit bang a lot with 320Mhz cycle time :-). That said I wonder if we'll see a common standard emerge for an 'open' serial protocol. Sort of PCIe lite which runs at say 250Mhz over a pair of LVDS pins that you make into an AHB bus master in the memory matrix. That would really open up the peripheral market.

Is there really a need? Most serial protocols can really be considered 'open'.

For low bandwidth there is RS232/UART/JTAG. Then there is I²C/SPI for networked. I²C ranges from 100kbit/s to 2.3Mbit/s. And SPI goes to 10Mbps/30Mbps.

For higher bandwidth stuff there is whatever you want over USB, Bluetooth, 802.11BLAH Wifi. Etc... Afaik USB can be considered 'open', you might need to 'register' for a certification/vendor id/logo but from what I understand if you don't want those you don't need to bother. There are also http://pid.codes/ and other organisations that are giving away free pids.

There is the Wishbone bus. https://en.wikipedia.org/wiki/Wishbone_(computer_bus)

But that's got quite a few pins. It allows for on chip networking as well as external stuff. Also RapidIO (which has heaps of pins).

There is a RISC-V debugging standard, but I think that's protocol agnostic.

Post reply on HN