[lowrisc-dev] Memory-mapped SPI flash on Nexys4?

Wei Song ws327 at cam.ac.uk
Wed Jul 20 11:27:11 BST 2016

Hello Jonathan,

Thanks for the explanation. It seems pretty clear why a memory mapped
flash is needed now.
The good news is, I just find out that modern SPI Flash chips do support
an XIP (execution in place) mode which is dedicated for this purpose and
the Xilinx Quad SPI IP already support the XIP mode.
So I think I can add support to this memory mapped flash to lowRISC
early next month, hopefully you still get time to try?

Best regards,

On 19/07/2016 18:34, Jonathan Neuschäfer wrote:
> On Tue, Jul 19, 2016 at 05:42:24PM +0100, Wei Song wrote:
>> Hello Jonathan,
>> This is actually rather interesting.
>> May I ask which GSoC organization you are working right now and who is
>> your mentor?
> I'm working with Ron Minnich and Furquan Shaikh (CC'd) in the coreboot
> organization.
>> Which hardware/software platform will you port coreboot to?
> SPIKE, and probably lowRISC on the Nexys 4 DDR.
>> Any chance for porting on a lowRISC platform?
> Yes, that's my intention.
>> I think I can see the benefit of letting coreboot sitting in a flash,
>> but there are several questions:
>> 1. Does coreboot need heap and stack? I suppose yes. Then will heap and
>> stack be mapped to Flash as well? Would not this be potentially harmful
>> for flash?
> Yes, coreboot needs a stack (and a heap), which requires writable
> memory. I wouldn't map a flash writable, as writing means erasing a
> whole page (which is usually 512 bytes, if I am not mistaken) and
> rewriting it.
> For things like a stack it's useful to have a small amount of RAM inside
> the CPU, which can be used immediately after reset. DRAM can't usually
> be used directly after reset, because the DRAM controller has to
> configured to use the correct timings etc., so it should be SRAM.
> LowRISC on nexys4 already has 64KiB of Block RAM at 0x40000000.
>> 2. Does coreboot use cache or must be uncached? Whether this flash space
>> is still observable in OS or later stage bootloaders (I suppose Yes as
>> well).
> I think it doesn't matter whether the flash is cached or not, because it
> won't be preprogrammed during boot. The OS doesn't need to be able to
> access the flash, but it probably doesn't hurt, either.
>> 3. What does x86 BIOS do? The BISO is actually running on flash?
> Yes. Coreboot roughly performs the following steps on x86 (and other
> BIOSes probably do it similarly):
> 1. It starts executing in flash and switches into 32-bit mode
> 2. It sets up the CPU's cache as RAM, so it can have a stack and run C
>    code
> 3. It detects the installed RAM modules and initializes the DRAM
>    controller
> 4. It loads the so-called ramstage into RAM, and starts running in RAM
> 5. It loads the payload (bootloader or OS) into RAM and runs it
>> And there is question for me: Even if I would like to, how can I support
>> memory-mapped flash using a quad-spi (which is hard-wired on the
>> Nexys4-DDR).
>> Stefan, do you know how to do it? It seems like a hardware controller to
>> translate memory accesses to SPI transactions.
> Yes, that would be roughly how it works. Unfortunately I can't help much
> with hardware implementation questions, because of limited experience.
> Thanks,
> Jonathan

More information about the lowrisc-dev mailing list