-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VCU118 FPGA Updates + FireMarshal on Prototypes #849
Changes from all commits
f334d57
5a41c5d
2cfd930
be13781
985faa4
565ef2e
e159c4f
436c235
bbf4fc1
8ed61d6
b152bbd
9cee20e
1dd2698
325f65e
39c3756
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -47,8 +47,8 @@ After the harness is created, the ``BundleBridgeSource``'s must be connected to | |
This is done with harness binders and io binders (see ``fpga/src/main/scala/vcu118/HarnessBinders.scala`` and ``fpga/src/main/scala/vcu118/IOBinders.scala``). | ||
For more information on harness binders and io binders, refer to :ref:`Customization/IOBinders:IOBinders and HarnessBinders`. | ||
|
||
Introduction to the Bringup Platform | ||
------------------------------------ | ||
Introduction to the Bringup Design | ||
---------------------------------- | ||
|
||
An example of a more complicated design used for Chipyard test chips can be viewed in ``fpga/src/main/scala/vcu118/bringup/``. | ||
This example extends the default test harness and creates new ``Overlays`` to connect to a DUT (connected to the FMC port). | ||
|
@@ -58,3 +58,108 @@ The TSI Host Widget is used to interact with the DUT from the prototype over a S | |
.. Note:: Remember that since whenever a new test harness is created (or the config changes, or the config packages changes, or...), you need to modify the make invocation. | ||
For example, ``make SUB_PROJECT=vcu118 CONFIG=MyNewVCU118Config CONFIG_PACKAGE=this.is.my.scala.package bitstream``. | ||
See :ref:`Prototyping/General:Generating a Bitstream` for information on the various make variables. | ||
|
||
Running Linux on VCU118 Designs | ||
------------------------------- | ||
|
||
As mentioned above, the default VCU118 harness is setup with a UART and a SPI SDCard. | ||
These are utilized to both interact with the DUT (with the UART) and load in Linux (with the SDCard). | ||
The following steps describe how to build and run buildroot Linux on the prototype platform. | ||
|
||
Building Linux with FireMarshal | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
Since the prototype currently does not have a block device setup for it, we build Linux with the rootfs built into the binary (otherwise known as "initramfs" or "nodisk" version of Linux). | ||
To make building this type of Linux binary easy, we will use the FireMarshal platform (see :ref:`fire-marshal` for more information). | ||
|
||
1. Setup FireMarshal (see :ref:`fire-marshal` on the initial setup). | ||
2. By default, FireMarshal is setup to work with FireSim. | ||
Instead, we want to target the prototype platform. | ||
This is done by switching the FireMarshal "board" from "firechip" to "prototype" using ``marshal-config.yaml``: | ||
|
||
.. code-block:: shell | ||
|
||
# this assumes you do not have a `marshal-config.yaml` file already setup | ||
echo "board-dir : 'boards/prototype'" > $PATH_TO_FIREMARSHAL/marshal-config.yaml | ||
|
||
.. Note:: Refer to the FireMarshal docs on more ways to set the board differently through environment variables and more. | ||
|
||
3. Next, build the workload (a.k.a buildroot Linux) in FireMarshal with the ``nodisk`` option flag. | ||
For the rest of these steps, we will assume you are using the base ``br-base.json`` workload. | ||
This workload has basic support for GPIO and SPI drivers (in addition to the default UART driver) but you can build off it in different workloads (refer to FireMarshal docs on workload inheritance). | ||
|
||
.. code-block:: shell | ||
|
||
./marshal -v -d build br-base.json # here the -d indicates --nodisk or initramfs | ||
|
||
.. Note:: Using the "board" FireMarshal functionality allows any child workload depending on the ``br-base.json`` workload specification to target a "prototype" platform rather than FireChip platform. | ||
Thus, you can re-use existing workloads that depend on ``br-base.json`` on the prototype platform by just changing the "board"! | ||
|
||
4. The last step to generate the proper binary is to flatten it. | ||
This is done by using FireMarshal's ``install`` feature which will produce a ``*-flat`` binary in the ``$PATH_TO_FIREMARSHAL/images`` directory (in our case ``br-base-bin-nodisk-flat``) from the previously built Linux binary (``br-base-bin-nodisk``). | ||
|
||
.. code-block:: shell | ||
|
||
./marshal -v -d install -t prototype br-base.json | ||
|
||
Setting up the SDCard | ||
~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
These instructions assume that you have a spare uSDCard that can be loaded with Linux and other files using two partitions. | ||
The 1st partition will be used to store the Linux binary (created with FireMarshal or other means) while the 2nd partition will store a file system that can be accessed from the DUT. | ||
Additionally, these instructions assume you are using Linux with ``sudo`` privileges and ``gdisk``, but you can follow a similar set of steps on Mac (using ``gpt`` or another similar program). | ||
|
||
1. Wipe the GPT on the card using ``gdisk``. | ||
Use the `z` command to zap everything. | ||
For rest of these instructions, we assume the SDCard path is ``/dev/sdc`` (replace this with the path to your SDCard). | ||
|
||
.. code-block:: shell | ||
|
||
sudo gdisk /dev/sdc | ||
|
||
2. The VCU118 bootrom assumes that the Linux binary to load into memory will be located on sector 34 of the SDCard. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. would it be possible to give prompt examples? (..code-block:: shell ....) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that is a bit excessive and unnecessary. These instructions although are setup for |
||
Change the default partition alignment to `1` so you can write to sector `34`. | ||
Do this with the `l` command. | ||
|
||
3. Create the new GPT with `o`. | ||
Click yes on all the prompts. | ||
|
||
4. Create a 512MiB partition to store the Linux binary (this can be smaller but it must be larger than the size of the Linux binary). | ||
Use `n` and select sector 34, with size `+1048576` (corresponding to 512MiB). | ||
For the type, search for the `apfs` type and use the hex number given. | ||
|
||
5. Create a second partition to store any other files with the rest of the SDCard. | ||
Use `n` and use the defaults for starting sector and overall size (expand the 2nd partition to the rest of the SDCard space). | ||
For the type, search for the `hfs` and use the hex number given. | ||
|
||
6. Write the changes using `w`. | ||
|
||
7. Setup the filesystem on the 2nd partition. | ||
Note that the ``/dev/sdc2`` points to the 2nd partition. | ||
Use the following command: | ||
|
||
.. code-block:: shell | ||
|
||
sudo mkfs.hfs -v "PrototypeData" /dev/sdc2 | ||
|
||
Transfer and Run Linux from the SDCard | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
After you have a Linux boot binary and the SDCard is setup properly (1st partition at sector 34), you can transfer the binary to the 1st SDCard partition. | ||
In this example, we generated a ``br-base-bin-nodisk-flat`` from FireMarshal and we will load it using ``dd``. | ||
Note that ``sdc1`` points to the 1st partition (remember to change the ``sdc`` to your own SDCard path). | ||
|
||
.. code-block:: shell | ||
|
||
sudo dd if=$PATH_TO_FIREMARSHAL/br-base-bin-nodisk-flat of=/dev/sdc1 | ||
|
||
If you want to add files to the 2nd partition, you can also do this now. | ||
|
||
After loading the SDCard with Linux and potentially other files, you can program the FPGA and plug in the SDCard. | ||
To interact with Linux via the UART console, you can connect to the serial port (in this case called ``ttyUSB1``) using something like ``screen``: | ||
|
||
.. code-block:: shell | ||
|
||
screen -S FPGA_UART_CONSOLE /dev/ttyUSB1 115200 | ||
|
||
Once connected, you should see the binary being loaded as well as Linux output (in some cases you might need to reset the DUT). |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,10 +8,12 @@ | |
#define DEBUG | ||
#include "kprintf.h" | ||
|
||
#define MAX_CORES 8 | ||
|
||
// A sector is 512 bytes, so ((1 << 11) * 512) = 1 MiB | ||
#define PAYLOAD_SIZE (16 << 11) | ||
// Total payload in B | ||
#define PAYLOAD_SIZE_B (30 << 20) // default: 30MiB | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How much extra room is there here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Linux binary with FireMarshal is around 20-25MiB so 5MiB room. |
||
// A sector is 512 bytes, so (1 << 11) * 512B = 1 MiB | ||
#define SECTOR_SIZE_B 512 | ||
// Payload size in # of sectors | ||
#define PAYLOAD_SIZE (PAYLOAD_SIZE_B / SECTOR_SIZE_B) | ||
|
||
// The sector at which the BBL partition starts | ||
#define BBL_PARTITION_START_SECTOR 34 | ||
|
@@ -168,9 +170,11 @@ static int copy(void) | |
int rc = 0; | ||
|
||
dputs("CMD18"); | ||
|
||
kprintf("LOADING 0x%xB PAYLOAD\r\n", PAYLOAD_SIZE_B); | ||
kprintf("LOADING "); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we need both of these messages? The second loading seems redundant. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is a nice spinner that comes up next to the loading so I just left this. Technically I can put the spinner next to the |
||
|
||
// John: Let's go slow until we get this working | ||
// TODO: Speed up SPI freq. (breaks between these two values) | ||
abejgonzalez marked this conversation as resolved.
Show resolved
Hide resolved
|
||
//REG32(spi, SPI_REG_SCKDIV) = (F_CLK / 16666666UL); | ||
REG32(spi, SPI_REG_SCKDIV) = (F_CLK / 5000000UL); | ||
if (sd_cmd(0x52, BBL_PARTITION_START_SECTOR, 0xE1) != 0x00) { | ||
|
@@ -182,7 +186,7 @@ static int copy(void) | |
long n; | ||
|
||
crc = 0; | ||
n = 512; | ||
n = SECTOR_SIZE_B; | ||
while (sd_dummy() != 0xFE); | ||
do { | ||
uint8_t x = sd_dummy(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be an append? Or do we really want to overwrite?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file doesn't exist unless the user makes it. So this is assuming we create it from scratch.