aboutsummaryrefslogtreecommitdiff
path: root/docs/system/arm
diff options
context:
space:
mode:
authorPeter Maydell <peter.maydell@linaro.org>2024-10-29 12:54:44 +0000
committerPeter Maydell <peter.maydell@linaro.org>2024-10-29 15:04:46 +0000
commit6a98e614e5cc3ae9aa15a6bdf30fbdb4472bf2ff (patch)
treece57e521586c18d16ffc25508cf79aff19929dfc /docs/system/arm
parent23a26bfeea5a9c831067cb0c4529d7c067b79564 (diff)
downloadqemu-6a98e614e5cc3ae9aa15a6bdf30fbdb4472bf2ff.zip
qemu-6a98e614e5cc3ae9aa15a6bdf30fbdb4472bf2ff.tar.gz
qemu-6a98e614e5cc3ae9aa15a6bdf30fbdb4472bf2ff.tar.bz2
docs/system/arm: Split fby35 out from aspeed.rst
The fby35 machine is not implemented in hw/arm/aspeed.c, but its documentation is currently stuck at the end of aspeed.rst, formatted in a way that it gets its own heading in the top-level list of boards in target-arm.html. We don't have any other boards that we document like this; split it out into its own rst file. This improves consistency with other board docs and means we can have the entry in the target-arm list be in the correct alphabetical order. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-id: 20241018141332.942844-4-peter.maydell@linaro.org
Diffstat (limited to 'docs/system/arm')
-rw-r--r--docs/system/arm/aspeed.rst48
-rw-r--r--docs/system/arm/fby35.rst47
2 files changed, 47 insertions, 48 deletions
diff --git a/docs/system/arm/aspeed.rst b/docs/system/arm/aspeed.rst
index 968ba88..63910d3 100644
--- a/docs/system/arm/aspeed.rst
+++ b/docs/system/arm/aspeed.rst
@@ -257,51 +257,3 @@ To boot a kernel directly from a Zephyr build tree:
$ qemu-system-arm -M ast1030-evb -nographic \
-kernel zephyr.elf
-
-Facebook Yosemite v3.5 Platform and CraterLake Server (``fby35``)
-==================================================================
-
-Facebook has a series of multi-node compute server designs named
-Yosemite. The most recent version released was
-`Yosemite v3 <https://www.opencompute.org/documents/ocp-yosemite-v3-platform-design-specification-1v16-pdf>`__.
-
-Yosemite v3.5 is an iteration on this design, and is very similar: there's a
-baseboard with a BMC, and 4 server slots. The new server board design termed
-"CraterLake" includes a Bridge IC (BIC), with room for expansion boards to
-include various compute accelerators (video, inferencing, etc). At the moment,
-only the first server slot's BIC is included.
-
-Yosemite v3.5 is itself a sled which fits into a 40U chassis, and 3 sleds
-can be fit into a chassis. See `here <https://www.opencompute.org/products/423/wiwynn-yosemite-v3-server>`__
-for an example.
-
-In this generation, the BMC is an AST2600 and each BIC is an AST1030. The BMC
-runs `OpenBMC <https://github.com/facebook/openbmc>`__, and the BIC runs
-`OpenBIC <https://github.com/facebook/openbic>`__.
-
-Firmware images can be retrieved from the Github releases or built from the
-source code, see the README's for instructions on that. This image uses the
-"fby35" machine recipe from OpenBMC, and the "yv35-cl" target from OpenBIC.
-Some reference images can also be found here:
-
-.. code-block:: bash
-
- $ wget https://github.com/facebook/openbmc/releases/download/openbmc-e2294ff5d31d/fby35.mtd
- $ wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf
-
-Since this machine has multiple SoC's, each with their own serial console, the
-recommended way to run it is to allocate a pseudoterminal for each serial
-console and let the monitor use stdio. Also, starting in a paused state is
-useful because it allows you to attach to the pseudoterminals before the boot
-process starts.
-
-.. code-block:: bash
-
- $ qemu-system-arm -machine fby35 \
- -drive file=fby35.mtd,format=raw,if=mtd \
- -device loader,file=Y35BCL.elf,addr=0,cpu-num=2 \
- -serial pty -serial pty -serial mon:stdio \
- -display none -S
- $ screen /dev/tty0 # In a separate TMUX pane, terminal window, etc.
- $ screen /dev/tty1
- $ (qemu) c # Start the boot process once screen is setup.
diff --git a/docs/system/arm/fby35.rst b/docs/system/arm/fby35.rst
new file mode 100644
index 0000000..742b887
--- /dev/null
+++ b/docs/system/arm/fby35.rst
@@ -0,0 +1,47 @@
+Facebook Yosemite v3.5 Platform and CraterLake Server (``fby35``)
+==================================================================
+
+Facebook has a series of multi-node compute server designs named
+Yosemite. The most recent version released was
+`Yosemite v3 <https://www.opencompute.org/documents/ocp-yosemite-v3-platform-design-specification-1v16-pdf>`__.
+
+Yosemite v3.5 is an iteration on this design, and is very similar: there's a
+baseboard with a BMC, and 4 server slots. The new server board design termed
+"CraterLake" includes a Bridge IC (BIC), with room for expansion boards to
+include various compute accelerators (video, inferencing, etc). At the moment,
+only the first server slot's BIC is included.
+
+Yosemite v3.5 is itself a sled which fits into a 40U chassis, and 3 sleds
+can be fit into a chassis. See `here <https://www.opencompute.org/products/423/wiwynn-yosemite-v3-server>`__
+for an example.
+
+In this generation, the BMC is an AST2600 and each BIC is an AST1030. The BMC
+runs `OpenBMC <https://github.com/facebook/openbmc>`__, and the BIC runs
+`OpenBIC <https://github.com/facebook/openbic>`__.
+
+Firmware images can be retrieved from the Github releases or built from the
+source code, see the README's for instructions on that. This image uses the
+"fby35" machine recipe from OpenBMC, and the "yv35-cl" target from OpenBIC.
+Some reference images can also be found here:
+
+.. code-block:: bash
+
+ $ wget https://github.com/facebook/openbmc/releases/download/openbmc-e2294ff5d31d/fby35.mtd
+ $ wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf
+
+Since this machine has multiple SoC's, each with their own serial console, the
+recommended way to run it is to allocate a pseudoterminal for each serial
+console and let the monitor use stdio. Also, starting in a paused state is
+useful because it allows you to attach to the pseudoterminals before the boot
+process starts.
+
+.. code-block:: bash
+
+ $ qemu-system-arm -machine fby35 \
+ -drive file=fby35.mtd,format=raw,if=mtd \
+ -device loader,file=Y35BCL.elf,addr=0,cpu-num=2 \
+ -serial pty -serial pty -serial mon:stdio \
+ -display none -S
+ $ screen /dev/tty0 # In a separate TMUX pane, terminal window, etc.
+ $ screen /dev/tty1
+ $ (qemu) c # Start the boot process once screen is setup.