RISC-V, what do you think about ?

[ataradov]

Maybe it can be different on microcontrollers though I find their arguments that a handler in ROM will perform well convincing.

Well, this thing is a microcontroller. Attempts at pushing the same exact core/system architecture for all applications will fail, for sure.

And I'm specifically comparing it to Cortex-M7, which achieve similar performance, but are much nicer to work with.

This this is a lot of fun, but "fun" is not what you want when working on real projects. In this stage, I simply don't see why anyone would use this.

Also, code security is unclear. Who would use a micro where you can dump the firmware from external device?

[ataradov]

Ok, I'm reading about PLIC, and this thing is incredibly complicated. This does not play well with the whole simplicity goal.

I understand that PLIC comes from RISC V spec, and that spec is probably not very well suited for MCUs, but still.

So far the amount of code that need to be written just to make stupid timer work is mind boggling.

And I still don't get how UART interrupts will work. Now I do. Ext interrupts are not external to the device, but external to the interrupt controller, this includes all peripheral interrupts. Now it is time for some sleep

[benSTmax]

Ok, I'm reading about PLIC, and this thing is incredibly complicated. This does not play well with the whole simplicity goal.

I got the same feeling when reading about interrupt subsystems for MIPS or PowerPC micros. Read it a few more times and it will get through. You can also try to read about the MIPS or PowerPC interrupts and you'll see the similarities. MIPS uses priorities and sub-priorities while RISC-V PLIC's priorities and thresholds behave in pretty much the same way. The difference between MIPS and RISC-V PLIC being the latter is also able to "merge" more interrupts. MIPS can only do single or multi vector interrupts. It cannot merge the multiple interrupts in more than one vector.  Sometimes, I find I need to re-read the same part over and over again to get into author's shoes and understand the concept it tries to explain.
  We're too used with patterns ...

I understand that PLIC comes from RISC V spec, and that spec is probably not very well suited for MCUs, but still.

Adding more pictures or some potential real-life examples will certainly help. Seeing David Patterson's name in the spec I can see why the RISC-V specs are resembling so much the MIPS ones.
I guess the difference here can be made only by silicon companies providing RISC-V based MCUs and also known for fairly good documentation. They would try to explain it better for the customers.

Ext interrupts are not external to the device, but external to the interrupt controller, this includes all peripheral interrupts. Now it is time for some sleep

Again, a lot of resemblance to the ARM's NVIC, MIPS or PowerPC Interrupt controllers.

[brucehoult]

Ok, I'm reading about PLIC, and this thing is incredibly complicated. This does not play well with the whole simplicity goal.

I understand that PLIC comes from RISC V spec, and that spec is probably not very well suited for MCUs, but still.

So far the amount of code that need to be written just to make stupid timer work is mind boggling.

And I still don't get how UART interrupts will work. Now I do. Ext interrupts are not external to the device, but external to the interrupt controller, this includes all peripheral interrupts. Now it is time for some sleep

You might want to start from 25:00 in this (or the whole thing):

[ataradov]

Ok, here is a very minimal, self contained, bare-metal example - https://github.com/ataradov/mcu-starter-projects/tree/master/fe310

[ataradov]

I'm also tempted to blow off the bootloader, since it is very slow. But I'd like to figure out the recovery strategy.

Are there any known tricks, easier than erasing the flash via external programmer? I guess something like pulling DQx to ground may do the trick?

[brucehoult]

I'm also tempted to blow off the bootloader, since it is very slow. But I'd like to figure out the recovery strategy.

I'm sure you're aware the delay in the bootloader is there to give time to hit reset again to recover to safe mode if you've loaded a disastrous app.

Are there any known tricks, easier than erasing the flash via external programmer? I guess something like pulling DQx to ground may do the trick?

I plan to look into writing to the flash from a running program. I'd like to do a little jit compiler, or a filesystem in the upper 8 MB of flash (which the standard config of openocd will not touch).

That requires turning off the memory-mapped reading of it temporarily, so your code has to either be safely and securely already in the cache (NOT easy to do, as there is no prefetch instruction), or else copied to the SRAM.

I don't think anyone (SiFive) has written code to do this yet. Talking to the flash via SPI to do the writing is straightforward enough -- I've read the flash chip manual -- I haven't tracked down how the memory mapping is set up (or disabled).

[ataradov]

I'm sure you're aware the delay in the bootloader is there to give time to hit reset again to recover to safe mode if you've loaded a disastrous app.

Well, yes. But there are better ways to deal with that. For example, many kits I've seen simply have a jumper to disconnect CS from the memory. I'm sure something similar will work here, but there is no easy way to disconnect CS. That's why I was looking at alternative ways to break the external flash in a way that ROM will just wait for the debugger.

[ataradov]

Ok, so I tried to short pin 2 (MISO) of the flash to the ground and device appears to be in a recoverable state.

So I tried to blow off the bootloader in flash and link my program at offset 0x20000000 (start of flash). It works fine, but there is still a huge delay before the first instruction of my program runs (1.5 seconds actually).

Do they mean to say that "helpful" delay is in the ROM? Or am I missing something here? Who needs a microcontroller that takes 1.5 seconds to "boot"?

[legacy]

1.5 second is a very long time 

[brucehoult]

Ok, so I tried to short pin 2 (MISO) of the flash to the ground and device appears to be in a recoverable state.

So I tried to blow off the bootloader in flash and link my program at offset 0x20000000 (start of flash). It works fine, but there is still a huge delay before the first instruction of my program runs (1.5 seconds actually).

Do they mean to say that "helpful" delay is in the ROM? Or am I missing something here? Who needs a microcontroller that takes 1.5 seconds to "boot"?

As documented in the HiFive and FE310 manuals, at boot it executes instructions starting at 0x1000 in mask ROM. Execution is as follows:

0x1000: j 0x20000 # start of OTP ROM
0x20000: j 0x21FF4
0x21FF4: fence
0x21FF8: lui t0, 0x20000000 #start of flash
0x21FFC: jr t0

I've checked those locations and they contain what the documentation says (except 0x21FFC which contains 0x28067 not 0x28057. 0x28067 is the correct opcode for a JALR zero,t0 while 0x28057 is a reserved major opcode, so that's a doc problem.

(Note: I had to run at 16 MHz to read the OTP. It misread (in different ways) at 256 MHz and 320 MHz. If this is known it should be documented)

I took the documentation to mean that the start delay is caused by the bootloader code at 0x20000000. If not, then the only other option is before we get to 0x1000.

[ataradov]

I've checked those locations and they contain what the documentation says (except 0x21FFC which contains 0x28067 not 0x28057. 0x28067 is the correct opcode for a JALR zero,t0 while 0x28057 is a reserved major opcode, so that's a doc problem.

Am I reading this correctly, and there is no actual code anywhere before the execution from flash? Only jumps? There must be some sort of flash initialization code and all that stuff.

I took the documentation to mean that the start delay is caused by the bootloader code at 0x20000000. If not, then the only other option is before we get to 0x1000.

Me too, and I think it was deliberately written this way. I'm pretty sure this delay before the green led comes on from the bootloader, is not caused by the bootloader itself. My board has no bootloader at this point, and delay is still there, I've moved turning on of the LED right after stack initialization, so it is as close to the beginning as it gets.

But I also feel like OTP ROM must do some initialization work. And I think that's were the delay is.

[brucehoult]

Am I reading this correctly, and there is no actual code anywhere before the execution from flash? Only jumps? There must be some sort of flash initialization code and all that stuff.

You'd think so.

The QSPI is so darned slow anyway that you could easily "memory map" it with no performance loss by trapping illegal addresses and having a ROM routine do the necessary SPI transaction. But even if hardware does that, you'd expect that hardware to need some setting up, get the SPI into the right mode etc.

But I also feel like OTP ROM must do some initialization work. And I think that's were the delay is.

The ROMs aren't all that big. Someone could dump and disassemble them.

[ataradov]

The QSPI is so darned slow anyway that you could easily "memory map" it with no performance loss by trapping illegal addresses and having a ROM routine do the necessary SPI transaction.

I really hope this is not the case, otherwise the whole thing is a joke.

And when done right, QSPI is actually not that much slower than on-chip Flash. A lot of Cortex-M7 devices have execute in place capability from QSPI and it works just fine.

But even if hardware does that, you'd expect that hardware to need some setting up, get the SPI into the right mode etc.

Exactly. I though that's what ROM code is doing.

The ROMs aren't all that big. Someone could dump and disassemble them.

With the whole thing being open, I'd expect ROM to be open as well. But I could not find it on a quick search.

[brucehoult]

The QSPI is so darned slow anyway that you could easily "memory map" it with no performance loss by trapping illegal addresses and having a ROM routine do the necessary SPI transaction.

I really hope this is not the case, otherwise the whole thing is a joke.

From the datasheet: "The IS25LP128 Serial Flash memory offers ... Clock frequencies of up to 133MHz allow for equivalent clock rates of up to 532MHz (133MHz x 4) allowing more than 66Mbytes/s of throughput."

"FAST READ DATA QPI OPERATION (FRD QPI, 0Bh)
The QPI FAST READ (FRD QPI) instruction is used to read memory data at up to a 133MHz clock.
The FAST READ instruction code (2 clocks) is followed by three address bytes (A23-A0—6clocks) and mode
bits, dummy byte (4clocks)"

And then the data comes back at 4 bits per clock.

So reading a 32 bit word for a "load word" instruction takes 2 + 6 + 4 + 8 = 20 clocks = 150.4 ns at 133 MHz. That's enough time for 38 instructions at 256 MHz, more at 320. Less the time to enter/exit a trap of course.

But the flash doesn't seem to be being run that fast, at least at the moment, as I said elsewhere I measured 144 CPU clocks (562.5 ns @256 MHz) for each additional byte read after the first one. That's about what you'd expect from standard SPI run at 50 MHz, not QSPI at 133.

[ataradov]

So reading a 32 bit word for a "load word" instruction takes 2 + 6 + 4 + 8 = 20 clocks = 150.4 ns at 133 MHz. That's enough time for 38 instructions at 256 MHz, more at 320. Less the time to enter/exit a trap of course.

But with cache and reading one page at a time, it is not that bad.

Flash in fast MCUs also needs a lot of wait states. SAM V71 needs 5 wait states with code running at 300 MHz.

But the flash doesn't seem to be being run that fast, at least at the moment, as I said elsewhere I measured 144 CPU clocks (562.5 ns @256 MHz) for each additional byte read after the first one. That's about what you'd expect from standard SPI run at 50 MHz, not QSPI at 133.

The flash right now is way underclocked. I even made a comment about this in my simple code. I'm not sure why and I have not had time to investigate and try to make it faster.

[brucehoult]

From Megan at SiFive:

 We recently added some helpful functions for setting the clock sources: https://github.com/sifive/freedom-e-sdk/blob/master/bsp/drivers/fe300prci/fe300prci_driver.h. But the SDK doesn't actually use them.

In the Freedom E SDK, the "init.c" code switches over to the PLL clock source (with the HFROSC as the input), and the code there sets the SPI clock divider high out of paranoia since we know we are running out of SPI, and sets the UART appropriately so printf will just work. We're not expecting to do anything with OTP in general, so we didn't make the corresponding change to the OTP's clock divider.

The PLL code is in init rather than in main so that it can be applied for the benchmark codes, which don't allow us to change main.

The majority of the time before code execution at 0x1000 is the internal "reset stretcher" logic inside the chip. When you release the reset button, this circuit inside the chip is tuned to wait 1-2s before deasserting the reset to the AON block. This is to give time for the LFROSC which AON is running off of to be nice and stable. Once the AON block is running, it spends a few of its slow (32kHz) cycles taking the rest of the chip out of reset. (note that actually on the FE310 the LFROSC isn't used, there is an external LFOSC).

Once the CPU is out of reset, it starts running at 0x1000. It is running off its HFROSC source which is not particularly accurate, at 12-20MHz or so. So all the code sources that we might start fetching from at reset (mask ROM, OTP, and mem-mapped SPI) have their clock divider settings with this in mind.

[ataradov]

So 1-2 second delay actually happens? That's not ideal to say the least.

[ataradov]

Also, the whole PLL initialization thing was reduced to this:

  SPI0_REG(SPI_REG_SCKDIV) = 8; // TODO: This seems excessive

  PRCI_PLLDIV_REG = PLL_FINAL_DIV_BY_1(1) | PLL_FINAL_DIV(0);
  PRCI_PLLCFG_REG = PLL_REFSEL(0) | PLL_BYPASS(1) | PLL_R(1) | PLL_F(32-1) | PLL_Q(1);
  PRCI_PLLCFG_REG &= ~PLL_BYPASS(1);

  uint32_t start_time = CLINT_MTIME_LO_REG;
  while ((CLINT_MTIME_LO_REG - start_time) < 4);

  while (0 == (PRCI_PLLCFG_REG & PLL_LOCK(1)));

  PRCI_PLLCFG_REG |= PLL_SEL(1);

I don't understand why you need a library to do this.

[brucehoult]

So 1-2 second delay actually happens? That's not ideal to say the least.

That's true.

It's the first production silicon, first evaluation board for not only this particular tiny company (about ten people), but for the architecture as a whole. I'm completely prepared to understand if they play it conservative to make sure that they have something that works, not something that doesn't work.

A hardware two second boot delay is not ideal and of course there are applications where you would not want to deploy this board in production as a result. None of the applications I've ever used an Arduino in, as it happens, but your applications may be different. The most critical thing I've used an Arduino for is my home heating control system. I turn it on mid autumn and it runs until the middle of spring. I'm pretty sure it's never restarted mid-season unless I decided to tweak the code and flash a new version.

Everything else is in your hands to make it less conservative if you want. Push the CPU. Increase the SPI clock and enable QSPI (or even "DDR", as I see). Find the limits.

Looks like we're stuck with the two second boot delay for now though. I'll live.

[ataradov]

It's the first production silicon, first evaluation board for not only this particular tiny company (about ten people), but for the architecture as a whole. I'm completely prepared to understand if they play it conservative to make sure that they have something that works, not something that doesn't work.

I'll live as well. In its current form, there is no way anyone will put this into a real product. There are too few peripherals, too many pins occupied for no good reason, peripheral feature set and selection is very limited. And too many power supplies. It is a fun toy, though.

And they really need NVIC for the MCU market. Interrupts are very-very slow at the moment. I'm consistently getting complaints from people about 15 cycles on Cortex-M cores.

[brucehoult]

I'll live as well. In its current form, there is no way anyone will put this into a real product.
complaints from people about 15 cycles on Cortex-M cores.

From Krste Asanovic, SiFIve Co-Founder & Chief Architect:

HiFive1 is a development board for our FE line of custom SoCs, and the current FE310 parts are engineering samples (that's why ES is stamped on package). We can quickly and cheaply customize a production FE310 variant to have the features you need. The reset stretcher is indeed configurable and hardware vectored interrupts are also available in custom SoC designs.