summaryrefslogtreecommitdiffstats
path: root/user
diff options
context:
space:
mode:
Diffstat (limited to 'user')
-rw-r--r--user/bsps/aarch64/a53.rst8
-rw-r--r--user/bsps/aarch64/xilinx-versal.rst39
-rw-r--r--user/bsps/aarch64/xilinx-zynqmp.rst74
-rw-r--r--user/bsps/arm/imxrt.rst31
-rw-r--r--user/bsps/arm/raspberrypi.rst51
-rw-r--r--user/bsps/bsps-aarch64.rst1
-rw-r--r--user/start/app.rst2
-rw-r--r--user/testing/configuration.rst84
-rw-r--r--user/testing/tftp.rst12
9 files changed, 270 insertions, 32 deletions
diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst
index 52e1509..9d8e1ce 100644
--- a/user/bsps/aarch64/a53.rst
+++ b/user/bsps/aarch64/a53.rst
@@ -29,7 +29,9 @@ The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART.
Running Executables
-------------------
-Executables generated by these BSPs can be run using the following command::
+Executables generated by these BSPs can be run using the following command:
-qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \
- -machine virt,gic-version=3 -cpu cortex-a53 -m 4096 -kernel example.exe
+.. code-block:: shell
+
+ qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \
+ -machine virt,gic-version=3 -cpu cortex-a53 -m 4096 -kernel example.exe
diff --git a/user/bsps/aarch64/xilinx-versal.rst b/user/bsps/aarch64/xilinx-versal.rst
new file mode 100644
index 0000000..51489f2
--- /dev/null
+++ b/user/bsps/aarch64/xilinx-versal.rst
@@ -0,0 +1,39 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2021 Gedare Bloom
+
+.. _BSP_aarch64_qemu_xilinx_versal_ilp32_qemu:
+.. _BSP_aarch64_qemu_xilinx_versal_lp64_qemu:
+
+Qemu Xilinx Versal
+==================
+
+This BSP supports two variants, `xilinx-versal-ilp32-qemu` and
+`xilinx-versal-lp64-qemu`. The basic hardware initialization is performed by the
+BSP. These BSPs support the GICv3 interrupt controller present in the Xilinx
+Versal Adaptive Compute Acceleration Platform (ACAP) systems. The BSPs
+currently only work when started in the secure mode.
+
+Boot via ELF
+------------
+The executable image is booted by Qemu in ELF format.
+
+Clock Driver
+------------
+
+The clock driver uses the `ARM Generic Timer`.
+
+Console Driver
+--------------
+
+The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART.
+There are some differences between the PL011 and the UART used by actual Versal
+ACAP hardware systems.
+
+Running Executables
+-------------------
+
+Executables generated by these BSPs can be run using the following command::
+
+qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \
+ -machine xlnx-versal-virt -m 4096 -kernel example.exe
diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst b/user/bsps/aarch64/xilinx-zynqmp.rst
index 7401e84..ca232de 100644
--- a/user/bsps/aarch64/xilinx-zynqmp.rst
+++ b/user/bsps/aarch64/xilinx-zynqmp.rst
@@ -4,19 +4,46 @@
.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_qemu:
.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_qemu:
+.. _BSP_aarch64_qemu_xilinx_zynqmp_ilp32_zu3eg:
+.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_zu3eg:
Qemu Xilinx ZynqMP
==================
-This BSP supports two variants, `xilinx-zynqmp-ilp32-qemu` and
-`xilinx-zynqmp-lp64-qemu`. The basic hardware initialization is performed by the
-BSP. These BSPs support the GICv2 interrupt controller present in all ZynqMP
-systems.
+This BSP supports four variants: `xilinx-zynqmp-ilp32-qemu`,
+`xilinx-zynqmp-lp64-qemu`, `xilinx-zynqmp-ilp32-zu3eg`, and
+`xilinx-zynqmp-lp64-zu3eg`. Platform-specific hardware initialization is
+performed by ARM Trusted Firmware (ATF). Other basic hardware initialization is
+performed by the BSP. These BSPs support the GICv2 interrupt controller present
+in all ZynqMP systems. The zu3eg BSPs have also been tested to be fully
+functional on zu2cg boards and should also work on any other ZynqMP chip variant
+since the Processing Subsystem (PS) does not vary among chip variants other than
+the number of CPU cores available.
-Boot via ELF
+Boot on QEMU
------------
The executable image is booted by Qemu in ELF format.
+Boot on ZynqMP Hardware
+-----------------------
+
+On ZynqMP hardware, RTEMS can be started at EL1, EL2, or EL3 by u-boot or
+directly as part of BOOT.bin. Regardless of the exception level at boot, RTEMS
+will drop to EL1 for execution. For quick turnaround during testing, it is
+recommended to use the u-boot BOOT.bin that comes with the PetaLinux prebuilts
+for the board in question.
+
+Hardware Boot Image Generation
+------------------------------
+
+RTEMS expects some hardware initialization to be performed by ATF and expects
+the services it provides to be present, so this must be included when generating
+a direct-boot RTEMS BOOT.bin.
+
+When booting via u-boot, RTEMS must be packaged into a u-boot image or booted
+as a raw binary since u-boot does not currently support ELF64 which is required
+for AArch64 ELF binaries.
+
Clock Driver
------------
@@ -25,12 +52,37 @@ The clock driver uses the `ARM Generic Timer`.
Console Driver
--------------
-The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART.
+The console driver supports the default Qemu emulated ARM PL011 PrimeCell UART
+as well as the physical ARM PL011 PrimeCell UART in the ZynqMP hardware.
+
+SDHCI Driver
+------------
+
+The ZynqMP bsp has an SDHCI driver which allows reading to and writing from SD
+cards. These can be tested in qemu using the "-sd" option. For example:
+
+.. code-block:: shell
+
+ qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \
+ -machine xlnx-zcu102 -m 4096 -kernel media01.exe -sd example.img
+
+The SD card image should have an MSDOS partition table with a single partition
+containing a FAT file system.
+
+Network Configuration
+---------------------
+
+When used with LibBSD, these BSP variants support networking via the four
+Cadence GEM instances present on all ZynqMP hardware variants. All interfaces
+are enabled by default, but only interfaces with operational MII busses will be
+recognized and usable in RTEMS. Most ZynqMP dev boards use CGEM3.
+
+Running Executables on QEMU
+---------------------------
-Running Executables
--------------------
+Executables generated by these BSPs can be run using the following command:
-Executables generated by these BSPs can be run using the following command::
+.. code-block:: shell
-qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \
- -machine xlnx-zcu102 -m 4096 -kernel example.exe
+ qemu-system-aarch64 -no-reboot -nographic -serial mon:stdio \
+ -machine xlnx-zcu102 -m 4096 -kernel example.exe
diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
index c60b51d..f8d9731 100644
--- a/user/bsps/arm/imxrt.rst
+++ b/user/bsps/arm/imxrt.rst
@@ -10,6 +10,10 @@ This BSP offers only one variant, the `imxrt1052`. This variant supports the
i.MXRT 1052 processor on a IMXRT1050-EVKB (tested with rev A1). You can also
configure it to work with custom boards.
+NOTE: The IMXRT1050-EVKB has an backlight controller that must not be enabled
+without load. Make sure to either attach a load, disable it by software or
+disable it by removing the 0-Ohm resistor on it's input.
+
Build Configuration Options
---------------------------
@@ -41,6 +45,11 @@ Then just copy the generated binary to the mass storage provided by the
debugger. Wait a bit till the mass storage vanishes and re-appears. After that,
reset the board and the newly programmed application will start.
+NOTE: It seems that there is a bug on at least some of the on board debuggers.
+They can't write more than 1MB to the HyperFlash. If your application is bigger
+than that (like quite some of the applications in libbsd), you should use an
+external debugger or find some alternative programming method.
+
For debugging: Create a special application with a `while(true)` loop at end of
`bsp_start_hook_1`. Load that application into flash. Then remove the loop
again, build your BSP for SDRAM and use a debugger to load the application into
@@ -121,7 +130,27 @@ with your FDT source names)::
dtc -O dtb -o "YOUR.dtb" -b 0 -p 64
sh> rtems-bin2c -C -N imxrt_dtb "YOUR.dtb" "YOUR.c"
-Make sure that your new c file is compiled and linked into the application.
+Make sure that your new C file is compiled and linked into the application.
+
+PLL Settings
+------------
+
+The commercial variant of the i.MXRT1052 on the evaluation board allows a clock
+up to 600MHz for the ARM core. For some industrial variants only up to 528MHz
+are specified. To make it possible to adapt to these variants the application
+can overwrite the following constant:
+
+.. code-block:: c
+
+ #include "fsl_clock_config.h"
+
+ const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
+ .loopDivider = 100,
+ .src = 0,
+ };
+
+With the default configuration of a 24MHz oscillator, the loopDivider has to be
+88 for the 528MHz.
Clock Driver
------------
diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst
index c26f4b5..235134f 100644
--- a/user/bsps/arm/raspberrypi.rst
+++ b/user/bsps/arm/raspberrypi.rst
@@ -5,8 +5,9 @@
raspberrypi
===========
-This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently.
-The support for `Raspberry Pi 3` is work under progress.
+The 'raspberrypi' BSP supports the single core models (Zero, Zero W, A+, B+),
+and the 'raspberrypi2' BSP supports the Raspberry Pi 2, Raspberry Pi 3 A+, and Raspberry Pi 3.
+The Raspberry Pi 4 is not supported currently.
The default bootloader on the Raspberry Pi which is used to boot Raspbian
or other OS can be also used to boot RTEMS. U-boot can also be used.
@@ -19,10 +20,12 @@ The bootloader looks for a kernel image, by default the kernel images must
have a name of the form ``kernel*.img`` but this can be changed by adding
`kernel=<img_name>` to ``config.txt``.
-You must provide the required files for the GPU to proceed. These files
+You must provide the required firmware files on the SD card for the GPU to proceed,
+and thereby to boot RTEMS.
+The BSP currently boots up with an older version of the official firmware. These files
can be downloaded from
-`the Raspberry Pi Firmware Repository <https://github.com/raspberrypi/firmware/tree/master/boot>`_.
-You can remove the ``kernel*.img`` files if you want too, but don't touch
+`the Raspberry Pi Firmware Repository <https://github.com/raspberrypi/firmware/tree/1.20200601/boot>`_.
+You can remove the ``kernel*.img`` files if you want to, but don't touch
the other files.
Copy these files in to a SD card with FAT filesystem.
@@ -46,10 +49,46 @@ Make sure you have these lines below, in your ``config.txt``.
.. code-block:: none
- enable_uart=1
+ dtoverlay=disable-bt
kernel_address=0x200000
kernel=kernel.img
+SPI Driver
+------------
+
+SPI drivers are registered by the ``rpi_spi_init(bool bidirectional_mode)`` function.
+
+.. code-block:: none
+
+ #include <assert.h>
+ #include <bsp.h>
+
+ void spi_init(void)
+ {
+ int rv;
+
+ rv = rpi_spi_init(false);
+ assert(rv == 0);
+ }
+
+I2C Driver
+------------
+
+I2C drivers are registered by the ``rpi_setup_i2c_bus()`` function.
+
+.. code-block:: none
+
+ #include <assert.h>
+ #include <bsp.h>
+
+ void i2c_init(void)
+ {
+ int rv;
+
+ rv = rpi_setup_i2c_bus();
+ assert(rv == 0);
+ }
+
Testing using QEMU
------------------
diff --git a/user/bsps/bsps-aarch64.rst b/user/bsps/bsps-aarch64.rst
index 566a750..933370f 100644
--- a/user/bsps/bsps-aarch64.rst
+++ b/user/bsps/bsps-aarch64.rst
@@ -7,4 +7,5 @@ aarch64 (AArch64)
.. include:: aarch64/a53.rst
.. include:: aarch64/a72.rst
+.. include:: aarch64/xilinx-versal.rst
.. include:: aarch64/xilinx-zynqmp.rst
diff --git a/user/start/app.rst b/user/start/app.rst
index 2bb0a9e..19ae3e1 100644
--- a/user/start/app.rst
+++ b/user/start/app.rst
@@ -209,7 +209,7 @@ Run the executable:
.. code-block:: none
- $HOME/quick-start/rtems/6/bin/rtems-run --rtems-bsps=erc32-sis build/sparc-rtems-erc32/hello.exe
+ $HOME/quick-start/rtems/6/bin/rtems-run --rtems-bsps=erc32-sis build/sparc-rtems6-erc32/hello.exe
The output will be something close to:
diff --git a/user/testing/configuration.rst b/user/testing/configuration.rst
index 9c65506..4d67482 100644
--- a/user/testing/configuration.rst
+++ b/user/testing/configuration.rst
@@ -1,6 +1,6 @@
.. SPDX-License-Identifier: CC-BY-SA-4.0
-.. Copyright (C) 2018 Chris Johns <chrisj@rtems.org>
+.. Copyright (C) 2018,2021 Chris Johns <chrisj@rtems.org>
Tester Configuration
--------------------
@@ -226,9 +226,10 @@ supported directives are:
- ``%execute``
- ``%gdb``
- ``%tftp``
+- ``%wait``
-.. _tester-config-console:
.. index:: Console, %console
+.. _tester-config-console:
Console
~~~~~~~
@@ -278,10 +279,12 @@ configuration script. If the ``%{console_stdio}`` is defined the console will
be ``stdio`` else the console will be the BSP console or ``%{bsp_tty_dev}``.
Telnet can be combined with the ``ser2net`` daemon to remotely access a
-target's physical serial UART interface.
+target's physical serial UART interface. The syntax is ``host:port``::
+
+ %define bsp_tty_dev 1.2.3.4:8989
-.. _tester-config-execute:
.. index:: Execute, %execute
+.. _tester-config-execute:
Execute
~~~~~~~
@@ -297,8 +300,8 @@ An example is::
%execute %{run_cmd} %{run_opts} %{test_executable} %{test_executable_opts}
-.. _tester-config-gdb:
.. index:: GDB, %gdb
+.. _tester-config-gdb:
GDB
~~~
@@ -313,8 +316,8 @@ An example is::
%gdb %{gdb_cmd} %{test_executable} %{gdb_script}
-.. _tester-config-tftp:
.. index:: TFTP, %tftp
+.. _tester-config-tftp:
TFTP
~~~~
@@ -328,3 +331,72 @@ board running the test.
An example is::
%tftp %{test_executable} %{tftp_port}
+
+The RTEMS Tester contains a TFTP server so an external TFTP is not
+needed. It is recommended a TFTP Proxy is set up to handle the TFTP
+sessions for your network. The internal TFTP server ignores the
+requrest file and serves the next executable. If the target requires
+the executable ne in a specific format provide a script via the
+``target_pretest_command`` option in your user configuration file.
+
+The RTEMS Tools provides a TFTP protocol proxy server. It takes a list
+of MAC addresses and proxies TFTP sessions for that MAC address to
+another IP address and port. A proxy provides the following benefits:
+
+1. The TFTP proxy server is the only software required to run as root
+
+2. All hardware targets can be configured to serve from a single
+ machine and the proxy can distribute the sessions out to developer
+ machines
+
+3. There is no need to provide a globally writable file system a
+ central TFTP server acceses
+
+If you have a central TFTP server refer to the ``%wait`` directive.
+
+.. index:: Wait, %wait
+.. _tester-config-wait:
+
+Wait
+~~~~
+
+The ``%wait`` directive waits the timeout period for a test to
+complete. The directive monitors the console output and resets the
+timeout timer if console output is seen. If the test runs for too long
+while outputing data an error is reported.
+
+The wait directive can be used in systems where there is an external
+mechanism being used to send the executable to the target hardware.
+
+An example is::
+
+ %wait
+
+Wait has no options. The timeouts are controlled in other ways.
+
+If you have an external system wide TFTP server with global access
+wait can used by providing a `` script that places the file in the
+location the TFTP server can see. This is done as the test start so if
+networking loading there is normally enough time to get the executable
+image in place before the transfer starts. The MVME2700
+(``powerpc/mvme2307``) is a BSP that supports the ``%wait`` directive.
+
+The following is an example user configuration file (see
+``--user-config``)::
+
+ #
+ # MVME2700 (mvme2307)
+ #
+ [mvme2307]
+ bsp_tty_dev = 1.2.3.4:5678
+ target_pretest_command = mk-mvme2307-img @EXE@ /tftp/cjohns/rtems.img
+ target_exe_filter = /\.exe/.exe.img/
+ target_on_command = pw-ctl 1.2.3.4 toggle-on 3 1
+ target_off_command = pw-ctl 1.2.3.4 off 3
+ target_reset_command = pw-ctl 1.2.3.4 toggle-on 3 1
+
+The script ``mk-mvme2307-img`` converts the RTEMS ELF executable into
+the PowerPC prep bootloader format and copies the file to the TFTP
+server's network wide location. The MVME2700 is configured to request
+``rtems.img`` from this location. The command ``pw-ctl`` is a command
+to control the power to the board.
diff --git a/user/testing/tftp.rst b/user/testing/tftp.rst
index ade8f9a..4cb16ef 100644
--- a/user/testing/tftp.rst
+++ b/user/testing/tftp.rst
@@ -10,10 +10,14 @@ TFTP and U-Boot
.. index:: TFTP, U-Boot, Testing
TFTP and U-Boot provides a simple way to test RTEMS on a network capable
-target. The RTEMS Tester starts a TFTP server for each test and the target's
-boot monitor, in this case U-Boot request a file, any file, which the TFTP
-server supplies. U-Boot loads the executable and boots it using a standard
-U-Boot script.
+target. The RTEMS Tester starts a TFTP server session for each test and the
+target's boot monitor, in this case U-Boot request a file, any file, which the
+TFTP server supplies. U-Boot loads the executable and boots it using a
+standard U-Boot script.
+
+The RTEMS Tester contains a TFTP server so no external TFTP server or
+configuration is required. If you have an external TFTP server and wish to use
+that resource the :ref:`tester-config-wait` directive can be used.
.. _fig-tester-tftp-u-boot: