diff options
Diffstat (limited to 'user/bsps/aarch64')
-rw-r--r-- | user/bsps/aarch64/a53.rst | 8 | ||||
-rw-r--r-- | user/bsps/aarch64/a72.rst | 35 | ||||
-rw-r--r-- | user/bsps/aarch64/raspberrypi4.rst | 109 | ||||
-rw-r--r-- | user/bsps/aarch64/xilinx-versal.rst | 39 | ||||
-rw-r--r-- | user/bsps/aarch64/xilinx-zynqmp.rst | 281 |
5 files changed, 458 insertions, 14 deletions
diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst index 02891e0..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/a72.rst b/user/bsps/aarch64/a72.rst new file mode 100644 index 0000000..e8e4b3d --- /dev/null +++ b/user/bsps/aarch64/a72.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2020 On-Line Applications Research Corporation (OAR) + +.. _BSP_aarch64_qemu_a72_ilp32: +.. _BSP_aarch64_qemu_a72_lp64: + +Qemu A72 +======== + +This BSP supports two variants, `qemu_a72_ilp32` and `qemu_a72_lp64`. The basic +hardware initialization is performed by the BSP. These BSPs support the GICv3 +interrupt controller. + +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. + +Running Executables +------------------- + +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-a72 -m 4096 -kernel example.exe diff --git a/user/bsps/aarch64/raspberrypi4.rst b/user/bsps/aarch64/raspberrypi4.rst new file mode 100644 index 0000000..efb09b6 --- /dev/null +++ b/user/bsps/aarch64/raspberrypi4.rst @@ -0,0 +1,109 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2022 Mohd Noor Aman + +.. _BSP_aarch64_Raspberrypi_4: + +Raspberry Pi 4B +=============== + +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. ILP32 is not +supported. Raspberry pi 4B all variants and Raspberry Pi 400 are supported. The +default bootloader which is used by the Raspbian OS or other OS can be used to +boot RTEMS. SMP is currently not supported. + +Raspberry Pi 4B has 2 types of interrupt controller, GIC-400 (GICv2) and ARM +legacy generic controller. Both are supported. By default, raspberrypi 4B uses +ARM legacy generic controller. Set ``enable_gic=1`` in the ``config.txt`` file +to enable GIC. + +Clock Driver +------------ + +The clock driver uses the `ARM Generic Timer`. + +Console Driver +-------------- + +Raspberry pi 4B has 2 types of UARTs, ARM PL011 and Mini-uart. The PL011 is a +capable, broadly 16550-compatible UART, while the mini UART has a reduced +feature set. The console driver supports the default Qemu emulated ARM PL011 +PrimeCell UART as well as the physical ARM PL011 PrimeCell UART in the +raspberrypi hardware. Mini-uart is not supported. + +Preparing to boot +------------------ + +Raspberry Pi uses a different mechanism to boot when compared with any ARM SoC. +First the GPU initializes, loads the bootloader (Raspberry pi firmware) and then +looks for the kernel img. This whole process is done by the GPU (VideoCore IV) +till the kernel is loaded. More information can be found on the `Raspberry pi +documentation page +<https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#boot-sequence>`_. +By default the arm64 mode looks for the ``kernel8.img``. Any other kernel can be +loaded by adding ``kernel=<img_name>`` to the ``config.txt`` file. + +The Firmware files are required in order to boot RTEMS. The latest firmware can +be downloaded from the `Raspberry Pi Firmware Repository +<https://github.com/raspberrypi/firmware/>`_. USB boot is supported. All the +files (Firmwares and kernel) must be place in the FAT32 partition only. Add +``arm_64bit=1`` in the ``config.txt`` file in order to boot the BSP in 64bit +kernel mode. + + +UART Setup +^^^^^^^^^^ + +Connect your serial device to the GPIO15 and GPIO14. Add the following to the +``config.txt`` file in order to use the PL011 UART0 and thus disabling the +default Mini-uart. + +.. code-block:: none + + # if user wants to enable GIC, uncomment the next line + # enable_gic=1 + arm_64bit=1 + dtoverlay = disable-bt + enable_uart=1 + +.. note:: + The Raspberry Pi 4B and 400 have an additional four PL011 UARTs. They are not + supported. + +Generating kernel image +^^^^^^^^^^^^^^^^^^^^^^^ + +The following steps show how to run ``hello.exe`` on the BSP. Other executables +can be processed in a similar way. + +To create the kernel image: + +.. code-block:: shell + + $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img + +Copy the kernel image to the SD card. + +JTAG Setup +---------- + +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must configure +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi 4 +documentation refers to this as Alt4 functions of those pins. Alt5 does exist +too, which goes from GPIO4, 5, 6, 12 and 13. you can check this out from +`pinout.xyz <https://pinout.xyz/pinout/jtag#>`_ or `eLinux +<https://elinux.org/RPi_BCM2835_GPIOs>`_ + +One more thing to note on JTAG with Raspberry pi 4B is that, by default, All the +GPIO pins are pulled down, according to the `BCM2711 documentation +<https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf>`_. This +wasn't the case in the earlier models. So in order to let the data flow freely, +we will have to disable them. + +.. code-block:: none + + # Disable pull downs + gpio=22-27=np + + # Enable jtag pins (i.e. GPIO22-GPIO27) + enable_jtag_gpio=1 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..4de0115 100644 --- a/user/bsps/aarch64/xilinx-zynqmp.rst +++ b/user/bsps/aarch64/xilinx-zynqmp.rst @@ -4,19 +4,241 @@ .. _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: +.. _BSP_aarch64_qemu_xilinx_zynqmp_lp64_cfc400x: 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 family supports the following variants: -Boot via ELF +* `xilinx-zynqmp-ilp32-qemu` + +* `xilinx-zynqmp-lp64-qemu` + +* `xilinx-zynqmp-ilp32-zu3eg` + +* `xilinx-zynqmp-lp64-zu3eg` + +* `xilinx-zynqmp-lp64-cfc400x` + +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. + +This BSP family has been tested on the following hardware: + +* `Avnet UltraZed-EG SOM` + +* `Innoflight CFC-400X` + +* `Trenz TE0802` + +* `Xilinx ZCU102` + +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. + +Some systems such as the CFC-400X may require a bitstream to be loaded into the +FPGA portion of the chip to operate as expected. This bitstream must be loaded +before RTEMS begins operation since accesses to programmable logic (PL) memory +space can cause the CPU to hang if the FPGA is not initialized. This can be +performed as part of BOOT.bin or by a bootloader such as u-boot. Loading +bitstreams from RTEMS has not been tested on the ZynqMP platform and requires +additional libraries from Xilinx. + +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. + +Example: Booting a RTEMS image on the ZCU102 ZynqMP board +--------------------------------------------------------- + +This example will walk through the steps needed for booting RTEMS from a SD card +on the +`ZCU102 ZynqMP board. <https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-g.html>`_ +The reference for setting up a SD card and obtaining pre-built boot images is +`here. <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841858/Board+bring+up+using+pre-built+images>`_ + +Hardware Setup +^^^^^^^^^^^^^^ + +Set the dip switch SW6 according to the table below. This will allow the board +to boot from the SD card. Connect a Micro-USB cable to the USB UART interface +J83. This is a quad USB UART interface which will show up on the development +host computer as four different serial or tty devices. Use the first channel +for the console UART. It should be set to 115k baud. + ++---------------------------+ +| Dip Switch JW6 | ++------+------+------+------+ +| ON | OFF | OFF | OFF | ++------+------+------+------+ + +Prepare a SD card with a bootable partition +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The goal is to have a bootable SD card with a partition that is formatted with +the FAT file system. The file system will contain the boot artifacts including +BOOT.bin and the u-boot image. The RTEMS image will be placed on this volume. To +create the bootable SD card, follow the directions +`here. <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842385/How+to+format+SD+card+for+SD+boot>`_ + +Once you have the card formatted correctly, you need to place the files from +`this archive <https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2202763266/2021.2+Release#Downloads>`_ +on the FAT partition. The following file was used for this example: +`xilinx-vck190-v2021.2-final.bsp <https://www.xilinx.com/member/forms/download/xef.html?filename=xilinx-vck190-v2021.2-final.bsp>`_ + +In order to download these files, you need to have a Xilinx account login. As an +alternative, you can download a bootable image for Ubuntu 20.04 and write it to +an SD card using a utility such as `Balena Etcher <https://www.balena.io/etcher>`_ +or dd. The Ubuntu image is available `here. <https://ubuntu.com/download/xilinx>`_ +Download the image for the Zynq Ultrascale+ MPSoC Development boards, uncompress +it and write it to the SD card. This image creates multiple partitions, but we +only need to use the FAT partition with the boot artifacts on it. + +Verify that the board can boot from the SD card +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is worth booting the board from the SD card before trying to boot RTEMS. +Insert the card and power on the board. You should see the messages on the first +console indicating the various boot loader stages and eventually the Linux +kernel. The goal is to interrupt u-boot when given the chance to access the +u-boot command prompt. + +Build RTEMS with examples +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Build the RTEMS `xilinx-zynqmp-lp64-zu3eg` BSP. Use the ticker.exe sample which +can be found in the directory: + +.. code-block:: shell + + build/aarch64/xilinx-zynqmp-lp64-zu3eg/testsuites/samples + +Prepare the RTEMS image +^^^^^^^^^^^^^^^^^^^^^^^ + +Prepare your RTEMS image to boot from u-boot with the following commands: + +.. code-block:: shell + + $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary ticker.exe ticker.bin + $ gzip -9 ticker.bin + $ mkimage -A arm64 -O rtems -T kernel -a 0x10000000 -e 0x10000000 -n RTEMS -d ticker.bin.gz rtems.img + +Boot the RTEMS image +^^^^^^^^^^^^^^^^^^^^ +Copy the prepared RTEMS image to the SD card and insert the SD crd in the ZCU102 +board. Power on the board. When you see the prompt on the console to interupt +u-boot, hit a key to bring up the u-boot command prompt. On the u-boot command +prompt you can boot your RTEMS image: + +.. code-block:: shell + + Zynq-MP> fatload mmc 0:1 0x1000 rtems.img + Zynq-MP> bootm 0x1000 + +This is the entire boot sequence: + +.. code-block:: shell + + Pre-FSBL boot Started + Xilinx Zynq MP First Stage Boot Loader + Release 2020.2 Nov 18 2020 - 11:46:01 + NOTICE: ATF running on XCZU9EG/silicon v1/RTL5.1 at 0xfffea000 + NOTICE: BL31: v2.2(release):xilinx_rebase_v2.2_2020.1-10-ge6eea88b1 + NOTICE: BL31: Built : 12:28:45, Nov 17 2020 + + U-Boot 2020.01 (Jun 15 2021 - 14:24:32 +0000) + + Model: ZynqMP ZCU102 Rev1.0 + Board: Xilinx ZynqMP + DRAM: 4 GiB + PMUFW: v1.1 + EL Level: EL2 + Chip ID: zu9eg + NAND: 0 MiB + MMC: mmc@ff170000: 0 + In: serial@ff000000 + Out: serial@ff000000 + Err: serial@ff000000 + Bootmode: SD_MODE1 + Reset reason: SOFT + Net: + ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id + + Warning: ethernet@ff0e0000 (eth0) using random MAC address - 82:32:1d:80:d9:c9 + eth0: ethernet@ff0e0000 + Hit any key to stop autoboot: 0 + + ZynqMP> fatload mmc 0:1 0x1000 rtems.img + 46669 bytes read in 27 ms (1.6 MiB/s) + ZynqMP> bootm 0x1000 + ## Booting kernel from Legacy Image at 00001000 ... + Image Name: RTEMS + Image Type: AArch64 RTEMS Kernel Image (gzip compressed) + Data Size: 46605 Bytes = 45.5 KiB + Load Address: 10000000 + Entry Point: 10000000 + Verifying Checksum ... OK + Uncompressing Kernel Image + ## Transferring control to RTEMS (at address 10000000) ... + + *** BEGIN OF TEST CLOCK TICK *** + *** TEST VERSION: @rtems-version@.f381e9bab29278e4434b1a93e70d17a7562dc64c + *** TEST STATE: EXPECTED_PASS + *** TEST BUILD: RTEMS_POSIX_API RTEMS_SMP + *** TEST TOOLS: 10.3.1 20210409 (RTEMS 6, RSB ad54d1dd3cf8249d9d39deb1dd28b2f294df062d, Newlib eb03ac1) + TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988 + TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988 + TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988 + TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988 + TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988 + TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988 + TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988 + TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988 + TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988 + TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988 + TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988 + TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988 + TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988 + TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988 + + *** END OF TEST CLOCK TICK *** + + [ RTEMS shutdown ] + + +Follow up +^^^^^^^^^ + +This is just one possible way to boot the RTEMS image. For a development +environment you may wish to configure u-boot to boot the RTEMS image from a TFTP +server. For a production environment, you may wish to download, configure, and +build u-boot, or develop a BOOT.BIN image with the RTEMS application. + Clock Driver ------------ @@ -25,12 +247,49 @@ 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 writing to and reading 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 RGMII with CGEM3. + +When used with lwIP from the rtems-lwip integration repository, these BSP +variants support networking via CGEM0 and one of the other CGEM* instances +simultaneously. This is a limitation of the Xilinx driver, specifically +in code referring directly to XPAR_XEMACPS_0_BASEADDR. Attempting to use more +than two interfaces simultaneously may cause unexpected behavior. Attempting to +use a set of two interfaces that does not include CGEM0 may cause unexpected +behavior. + +The interfaces will not come up by default under lwIP and must be configured +manually. There are examples of this in the start_networking() implementation +in netstart.c as used by the network tests. + +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 |