search

GaloisInc / BESSPIN-CloudGFE

The AWS cloud deployment of the BESSPIN GFE platform.
Apache License 2.0
2 stars 2 forks source link

AWSteria: Please use the same memory layout as the GFE #73

Closed jrtc27 closed 4 years ago

jrtc27 commented 4 years ago

I notice that 9b54dd222d2417e765c5bd32a0b85169ce9f5abc adds a SoC_Map.bsv that is very different from the GFE. There are several reasons why I would urge you to please use the same memory layout as the GFE:

  1. Our CHERI-Flute changes the SoC_Map interface to use types that are amenable to our AXI library. Using a different SoC_Map therefore introduces more work to port it. This is probably slightly unavoidable, but the closer it can be, the less busy-work it introduces.

  2. Our TagController relies on knowing the range of cached DRAM so it knows which part of memory to maintain tags for. The end of DRAM is also where the tags are stored, and since it blocks the core from storing to that region of memory, the device tree also needs to be amended to shrink the memory region. If we're going to be providing more than 1 GiB of DRAM then this is unavoidable, but we can at least ensure it starts at the same place, and if there's only going to be 1 GiB of DRAM then we should definitely have it be the same 1 GiB range.

  3. BBL needs to be configured with where in physical memory it will be loaded. If loading the kernel separately from BBL (which is something I would very much like to be supported by any loaders in AWSteria, and is something I regularly exercise with netbooting on the GFE, as having to re-link BBL every time you change the kernel is a pain), the kernel also needs to be configured with the address that BBL is expecting such that the external ELF loader puts it in the right place for BBL to jump to. BBL's address is currently always the start of cached DRAM, and the kernel's is always one superpage after that. Having to maintain multiple separate builds for all these configurations creates combinatorial explosion that is a headache to stay on top of. Moreover, using the same address everywhere allows the exact same files to be reused between the GFE and AWSteria, so if any bugs appear in AWSteria, the exact same kernel can be tested on the GFE to quickly narrow down where the bug is originating (and, similarly, I can validate kernels on the GFE before attempting to boot them on AWSteria). The Connectal-based approach is also using the same configuration, so that can provide another data point.

kiniry commented 4 years ago

FYI @rsnikhil and Bluespec team. CC @dhand-galois

rsnikhil commented 4 years ago

Yes. In the interest of taking small incremental steps from known-working-version to the next known-working-version, I started with the standard WindSoC (Flute on GitHub and standalone SoC) which has an SoC_Map corresponding to the original Spike conventions, and ISA tests that are compiled to that map. Once all the functionality is in, and stable, we can replace the SoC Map to the GFE version (or presumably "GFE consistent" version, because the GFE had things that may not be in CloudGFE and vice versa).

jrtc27 commented 4 years ago

Sure, that makes sense. Glad we're on the same page.

rsnikhil commented 4 years ago

AWSteria now uses the GFE Soc Map.