HiFive1: A RISC-V-based, Open-Source, Arduino-Compatible Development Kit • Hacker News Board

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

#91

Post by pawadu » Thu, Dec 01, 2016, 9:31 AM UTC

rwmj wrote: post #87

pawadu wrote: post #84

Earlier quoted context omitted.

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

In theory, maybe. But have you seen the corresponding code in the linux kernel when they try to probe a partially known component and at the same time go around all kinds of bugs and errors and differences in silicon revisions? All those magic numbers and timeouts and dependencies that no one really can explain?

Configurations pages are a thing of the past, nowadays they should at best be used for confirmation and sanity checks. Device trees are the future and have already improved and simplified hardware management a lot (specially on ARM).

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

#92

Post by makomk » Thu, Dec 01, 2016, 11:42 AM UTC

david-given wrote: post #83

TickleSteve wrote: post #64

Earlier quoted context omitted.

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.

It's got a standard two-way associative cache in front of the SPI interface, much like you might have between RAM and the external bus in a normal CPU. If availabkle, demand paging would be the next step after the data wasn't found there either - a slower, higher-level concept that's handled in software rather than hardware.

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

#93

Post by microcolonel » Fri, Dec 02, 2016, 1:42 AM UTC

rwmj wrote: post #80

rwmj wrote: post #33

Earlier quoted context omitted.

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).

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

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.

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

#94

Post by mSparks » Sun, Dec 04, 2016, 11:49 PM UTC

mwcampbell wrote: post #37

mSparks wrote: post #28

Earlier quoted context omitted.

72/120MHz isn't really enough to do "decent" audio/signal processing with low distortion. You can probably get it to work with a lot of effort and optimisation, but there'll be very little room to do anything with it afterwards. Afaik AC97 chips run at around 24MHz, are dedicated to the job, and even they stop at 20 bit resolution and sticking the data onto a data bus. Getting better than that is "hard", which is why…

The Teensy audio adapter [1] uses a dedicated DAC, the SGTL5000. That frees up the MCU to do more DSP. [1]: http://pjrc.com/store/teensy3_audio.html

I should have been more specific.

Radio signals below 50 kHz are capable of penetrating ocean depths to approximately 200 metres, the longer the wavelength, the deeper. The British, German, Indian, Russian, Swedish, United States [3] and possibly other navies communicate with submarines on these frequencies.

->That requires min 100khz sample rate.

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

#95

Post by TickleSteve » Mon, Dec 05, 2016, 11:57 AM UTC

david-given wrote: post #83

TickleSteve wrote: post #64

Earlier quoted context omitted.

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.

There is a hardware block within the processor that converts memory-bus accesses into SPI accesses (for devices supporting the SPIFI standard for example). This makes the whole SPI device appear to be memory-mapped (for read accesses).

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

#96

Post by guomanmin » Tue, Dec 06, 2016, 8:44 PM UTC

Participate in Atlassian Research

My name is Angela and I do research for Bitbucket. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.

  We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.   

If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!

Cheers,   Angela Guo aguo@atlassian.com

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

#97

Post by guomanmin » Tue, Dec 06, 2016, 9:29 PM UTC

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…

Participate in Atlassian Research

My name is Angela and I do research for Bitbucket. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.    We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.   

If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!

Cheers,   Angela Guo aguo@atlassian.com