[lowrisc-dev] Memory-mapped SPI flash on Nexys4?
michaeljclark at mac.com
Thu Jul 28 14:17:19 BST 2016
Can you run out of the L1/L2 cache with write back disabled until you have configured DRAM? Is the cache big enough working space before DRAM has been configured to load a larger stage2 that can enumerate the hardware.
stage1 in ROM just needs to be big enough to turn on RAM and get stage 2 from EEPROM/Flash?
If you are aware of the cache associativity you can treat cache as a small piece of linear RAM assuming it defaults to up-to-date (doesn't try to fetch) and has write-back disabled through some cache control CSRs.
This way you don't waste SRAM (space) between cache and /some special boot memory/
This wisdom may be wrong however we do need to separate /technique/ from /format/ e.g. stage 3 being ELF with the RISC-V hardware descriptor (UTF-8 config string which is scalable to 128-bit or compiled binary derivative vs a binary table format that is limited to 32 and then later extended to 64-bit) passed via say the ELF auxiliary vector (a la bbl) vs say loading a complex and large UEFI COFF EXE (COFF is the precursor to ELF and is the basis of Windows EXE). This is at complete odds with System-V evolution from COFF to ELF which all the UNIX vendors, Linux and BSD derivatives settled upon. The reason being standardised shared library support.
The reason I'm thinking about ELF for the stage3 boot loader or kernel payload is it is the way bbl loads vmlinux as ELF (no silly 512 byte boot sector stuff) and it would be symmetrical with virtualised booting from of Linux or other OS kernels from a Linux or BSD Hypervisors such as KVM, Bhyve or Xen.
The symmetry is nice. kexecv essentially is execv in S mode instead of U mode with a different attribute in the auxiliary vector. AT_RISCV_CONFIG. It's a well known protocol.
SBI and config string and boot command line (argv) from EEPROM, Flash or NVRAM may be all that is needed with DRAM set up as Linux or the boot loader in flash can enumerate hardware. _start or main.
For nested virtualisation having a process/VM with access to sptbr and S mode CSRs. Google for project DUNE from Stanford. They put Linux processes into S mode instead of U mode with the main Linux running in root mode (H mode).
BIOS/UEFI etc were all designed pre-x86 virtualisation.
Food for thought.
PS. Sorry if this is a bit of a stream of consciousness, because it is.
Sent from my iPhone
> On 20/07/2016, at 5:34 AM, Jonathan Neuschäfer <j.neuschaefer at gmx.net> 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
>> 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
> 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
> 3. It detects the installed RAM modules and initializes the DRAM
> 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
>> 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.
More information about the lowrisc-dev