summaryrefslogtreecommitdiffstats
path: root/user/bsps
diff options
context:
space:
mode:
Diffstat (limited to 'user/bsps')
-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
6 files changed, 183 insertions, 21 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