Does Freedom E300 supports “Quad” read access against the external QSPI flash chip?
I observed signals of the QSPI flash on HiFive1 board. All read access against an application code stored in the flash are single (0x03, read command) only. Also, I check the Chisel code of SPI (SPIFlash.scala). It seems they are configured as a single SPI operation.
regards,
They are configured as single out of reset (to enable booting from a wide variety of SPI devices, at reset the HW uses a conservative access type). You can configure the QSPI interface from your SW. The Freedom E300 Platform manual describes how to change the command which is used for read accesses.
Is how to disable (and later re-enable) the memory mapping documented?
I’d like to play with loading code into SRAM and then program a few pages of the upper part of the flash as a simple file system – maybe even JIT compile some new code and then run it from flash later.
I can figure out myself how to do the writing to flash, given the port addresses and the flash data sheet (which I have).
See Chapter 13 of https://dev.sifive.com/documentation/freedom-e300-platform-reference-manual/. Register SPI_FCTRL has a bit EN which defaults to 1, meaning by default the SPIFlash memory mapped interface is enabled. If you set this bit to 0, then the memory mapped interface is disabled and you can use the register interface to drive the SPIFlash interface. You can also change the command that the Flash interface will use once you re-enable the memory mapped interface using the SPI_FFMT register.
Ahhhh. I already read the HIFive manual, the E3-Coreplex manual, the E310-G000 manual… One more 
I tried quad mode (0xEB) with HiFive1 board, but not works well. I also tried dual read mode (both 0xBB and 0x3B) . The dual mode works well. It seems the current QSPI interface design does not support sending address in quad mode. HiFive1 uses IS25LP128 that only supports 0xEB (both address and data are quad).
I also tested dual and quad mode with ArtyDevKit which has Micron N25Q128A. And confirmed the operation with quad read (0x6B, 1-1-4) mode. I use the following code to set the quad mode.
SPI0_REG(SPI_REG_FFMT) =
SPI_INSN_CMD_EN |
SPI_INSN_ADDR_LEN(3) |
SPI_INSN_PAD_CNT(8) |
SPI_INSN_CMD_PROTO(0) |
SPI_INSN_ADDR_PROTO(0) |
SPI_INSN_DATA_PROTO(2) |
SPI_INSN_CMD_CODE(0x6b) |
SPI_INSN_PAD_CODE(0x00);
Do you have any plan to support quad read (0xEB, 1-4-4) mode?
The SPI controller on the HiFive1 is identical to the one on the Arty devkit, so it should support quad mode in the same way. How are you setting SPI_REG_FFMT for quad reads (0xEB)? Note that IS25LP128 expects 6 dummy cycles by default when using command 0xEB.
I tested several dummy cycles. Access cycles are looks good. The problem is that DQ3 is always high during the address cycle. Thus it read out data of wrong address.
At first I was confused, too.
I think there should be a list of terminology somewhere on this site or documents.
Here are my understandings;
For example the E310-G000 SoC manual only includes implementation-specific specifications of E300 Platform architecture.
Hi Seiji,
Thanks for reporting this. We have verified that there is an issue which can cause the behavior you are seeing on DQ3. We are still working internally to understand the full extent of the issue and will update this thread once we have more information.
Hi All, Following up on this there are 2 issues related to our SPI controller:
Issue 1:
Issue: The output enable signal for DQ[3] is not driven properly.
Devices affected: FE310-G000, FPGA bit files we made available before 5/2
Symptoms: Address and write data using DQ[3] for transmission will not
function properly. Reads using DQ[3] are unaffected.
Workaround:
Do not use opcode 0xEB in the Extended SPI protocol. In some devices, this
command is also referred to as QUAD INPUT/OUTPUT FAST READ.
Do not use the Native Quad SPI Protocol. In some devices, this command is
also referred to as FAST READ.
Issue 2:
Issue: Certain frame lengths do not work properly.
Device affected: FE310-G000, FPGA bit files we made available before 5/2
Symptoms: Certain frame lengths do not work, and will result in the master
sending one extra clock pulse. The slave device may then become out of
sync.
Workaround:
The following frame lengths are supported and can be used. Do not use
other frame lengths.
These will be officially documented as errata in future documentation related to the FE310-G000. The FPGA bitstreams will be updated with new versions of the SPI controller soon.
Thanks again for reporting this.
I have another question about the SiFive QSPIFlash interface. The IO and MMAP modes of QSPIFlash interface seems exclusive. So that an XIP application in Flash cannot write data to the same Flash by switching the mode from MMAP to IO. This will crash the application since the CPU cannot fetch the subsequent instruction from memory mapped Flash anymore after the IO mode change. Is this correct?
That is correct.
You need to copy any necessary code and data into the SRAM before disabling the MMAP for the flash.
You could in theory also use code already in the instruction cache (loaded from flash), but it’s not easy to arrange this without actually running the code in some kind of dummy mode as there are no cache prefetch instructions. It would also be very bad if any of the cached code had a conflict and was evicted!
Thanks. Can we use the data scratch pad to store and run the code?
Or we attach another Flash memory at the second SPI interface as for data storage.
You can use the data scratchpad to store and run the code. This is the ideal thing to do if your program fits in the scratchpad. So you can run a program with SPI flash which copies the small program into Scrachpad and jump to it there.
I see. Thanks Megan.