wu-arch/chipyard
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse Source 
Co-authored-by: alonamid <alonamid@eecs.berkeley.edu>
This commit is contained in:
Abraham Gonzalez
2021-04-14 11:21:33 -07:00
committed by GitHub
parent 1dd2698e11
commit 325f65e4df
1 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/Prototyping/VCU118.rst
View File

@@ -84,7 +84,7 @@ To make building this type of Linux binary easy, we will use the FireMarshal pla
.. 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) with nodisk with FireMarshal.
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).
@@ -92,7 +92,7 @@ To make building this type of Linux binary easy, we will use the FireMarshal pla
./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 ``br-base.json`` to use the "prototype" ``br-base.json`` rather than the FireChip version.
.. 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.
@@ -107,7 +107,7 @@ 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).
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.
@@ -126,11 +126,11 @@ Additionally, these instructions assume you are using Linux with ``sudo`` privil
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.
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.
For the type, search for the `hfs` and use the hex number given.
6. Write the changes using `w`.
@@ -162,4 +162,4 @@ To interact with Linux via the UART console, you can connect to the serial port
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).
Once connected, you should see the binary being loaded as well as Linux output (in some cases you might need to reset the DUT).