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

Wei Song ws327 at cam.ac.uk
Tue Jul 19 17:42:24 BST 2016

Hello Jonathan,

This is actually rather interesting.
May I ask which GSoC organization you are working right now and who is
your mentor?
Which hardware/software platform will you port coreboot to?
Any chance for porting on a lowRISC platform?

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?
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
3. What does x86 BIOS do? The BISO is actually running on flash?

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
Stefan, do you know how to do it? It seems like a hardware controller to
translate memory accesses to SPI transactions.

Best regards,

On 19/07/2016 17:12, Jonathan Neuschäfer wrote:
> Hello Wei,
> On Tue, Jul 19, 2016 at 12:16:09PM +0100, Wei Song wrote:
>> Hello Jonathan,
>> Sorry if I misunderstand something here.
>> Although SD card and Flash both use SPI interfaces, they are not
>> requested to use the same SPI interface.
> The misunderstanding was on my part: I thought that the SPI controller
> was connected to the flash.
>> To support Flash, a second Quad SPI interface can be added. Then there
>> should be no issue in using them at the same time.
>> As for choosing where the firmware and the Kernel is loaded from, they
>> can be loaded from flash as well if that is with benefits for some reason.
>> However, the future plan is to use CoreBoot, which I think providing
>> more flexibility.
> My GSoC project is more or less to bring coreboot to RISC-V hardware, so
> I'll try to give some background information:
> Generally, the job of coreboot is to:
>  - Initialize the RAM, if it hasn't happened already in hardware
>  - Initialize other resources that the OS can't initialize (on x86, the
>    PCI busses need to be enumerated)
>  - Load and run a "payload", which can be a kernel, a graphical boot
>    loader or something else. Payloads always reside in a structure
>    called CBFS (coreboot file system) on the boot medium (which is a
>    flash in most cases).
>    If the OS is loaded from external media, the payload needs to do that.
>    Some payloads supported by coreboot are: uboot, Grub, SeaBIOS (an
>    implmentation of the old x86 BIOS calls and MBR boot mechanism),
>    TianoCore (a UEFI implementation). None of those runs on RISC-V yet.
>  - On RISC-V, to implement the SBI, and to secure it against privilege
>    escalation of S-mode code into M-mode, if possible.
> My idea was that porting coreboot could be easier if the contents of the
> flash were memory-mapped, so that the first stage boot program could
> simply jump into the flash. This would be similar to x86 systems where
> the BIOS (be it coreboot or not) resides in the BIOS flash.
> I think any (software) code that goes into the bitstream (and later,
> mask ROM) should be kept simple, to avoid bugs: A bitstream can be
> recompiled, but an ASIC can't.
> Instead of memory-mapping the flash, it would also be possible to
> provide an explicit SPI controller, and, in the on-chip bootloader, read
> the first stage of coreboot into a buffer and run it there. I would
> prefer a memory-mapped flash though, because it's easier to handle,
> software wise. (Reading all of coreboot into DRAM would work on the
> Nexys 4, because RAM initialization is done it hardware, but it would
> likely be more difficult on a lowRISC ASIC.)
> Thanks for your attention,
> Jonathan Neuschäfer

More information about the lowrisc-dev mailing list