diff options
Diffstat (limited to '')
| -rw-r--r-- | user/bsps/arm/altera-cyclone-v.rst | 4 | ||||
| -rw-r--r-- | user/bsps/arm/beagle.rst | 13 | ||||
| -rw-r--r-- | user/bsps/arm/fvp.rst | 39 | ||||
| -rw-r--r-- | user/bsps/arm/imx.rst | 8 | ||||
| -rw-r--r-- | user/bsps/arm/imxrt.rst | 172 | ||||
| -rw-r--r-- | user/bsps/arm/lpc24xx.rst | 2 | ||||
| -rw-r--r-- | user/bsps/arm/raspberrypi.rst | 24 | ||||
| -rw-r--r-- | user/bsps/arm/realview-pbx-a9.rst | 2 | ||||
| -rw-r--r-- | user/bsps/arm/stm32h7.rst | 6 | ||||
| -rw-r--r-- | user/bsps/arm/xen.rst | 4 | ||||
| -rw-r--r-- | user/bsps/arm/xilinx-zynqmp-rpu.rst | 95 | ||||
| -rw-r--r-- | user/bsps/arm/xilinx-zynqmp.rst | 2 |
12 files changed, 292 insertions, 79 deletions
diff --git a/user/bsps/arm/altera-cyclone-v.rst b/user/bsps/arm/altera-cyclone-v.rst index 14c026c..12e563e 100644 --- a/user/bsps/arm/altera-cyclone-v.rst +++ b/user/bsps/arm/altera-cyclone-v.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2017, 2019 embedded brains GmbH +.. Copyright (C) 2017, 2019 embedded brains GmbH & Co. KG .. Copyright (C) 2017, 2019 Sebastian Huber altera-cyclone-v (Intel Cyclone V) @@ -27,7 +27,7 @@ image. Use the following commands: .. code-block:: none - arm-rtems5-objcopy -O binary app.exe app.bin + arm-rtems@rtems-ver-major@-objcopy -O binary app.exe app.bin gzip -9 -f -c app.bin > app.bin.gz mkimage -A arm -O linux -T kernel -a 0x00300000 -e 0x00300000 -n RTEMS -d app.bin.gz app.img diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst index 696b89d..55f75c0 100644 --- a/user/bsps/arm/beagle.rst +++ b/user/bsps/arm/beagle.rst @@ -32,7 +32,7 @@ To boot via uboot, the ELF must be converted to a U-Boot image like below: .. code-block:: none - arm-rtems5-objcopy hello.exe -O binary app.bin + arm-rtems@rtems-ver-major@-objcopy hello.exe -O binary app.bin gzip -9 app.bin mkimage -A arm -O linux -T kernel -a 0x80000000 -e 0x80000000 -n RTEMS -d app.bin.gz rtems-app.img @@ -77,7 +77,8 @@ overlay has to be provided. The overlay must add an additional attribute For example, -.. code-block:: +.. code-block:: none + /dts-v1/; / { @@ -109,7 +110,7 @@ For registering with a custom path, the ``bsp_register_spi()`` can be used. The function prototype is given below: -.. code-block:: C +.. code-block:: c rtems_status_code bsp_register_spi( const char *bus_path, @@ -153,7 +154,7 @@ The modification is: The resulting wiring is: -.. code-block:: +.. code-block:: none 1 === /--=== 2 3 === | === 4 @@ -166,7 +167,7 @@ The resulting wiring is: 17 === === 18 19 === === 20 -.. figure:: ../../images/user/bbb-p2-debug-mod.jpg +.. figure:: ../../../images/user/bbb-p2-debug-mod.jpg :width: 50% :align: center :alt: BeagleBone Black JTAG Hardware Modification @@ -198,7 +199,7 @@ Cortex M only debuggers (like the Segger J-Link Edu Mini) won't work. If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the following gdb start script can be used: -.. code-block:: +.. code-block:: none define reset echo -- Reset target and wait for U-Boot to start kernel.\n diff --git a/user/bsps/arm/fvp.rst b/user/bsps/arm/fvp.rst new file mode 100644 index 0000000..b938e30 --- /dev/null +++ b/user/bsps/arm/fvp.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2022 embedded brains GmbH & Co. KG + +fvp (Fixed Virtual Platform) +============================ + +The BSP for the +`Arm Fixed Virtual Platforms <https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platforms>`_ +offers one variant. You need a license from Arm to run the simulator. The +`fvp_cortex_r52` variant supports a simulation of the Cortex-R52 processor. +The BSP supports the SMP configuration. + +Run an Executable +----------------- + +To run an executable on a single Cortex-R52 processor use: + +.. code-block:: none + + FVP_BaseR_Cortex-R52x1 -C bp.vis.disable_visualisation=1 -a build/arm/fvp_cortex_r52/testsuites/samples/ticker.exe + +To run an executable on a four Cortex-R52 processors use: + +.. code-block:: none + + FVP_BaseR_Cortex-R52x4 -C bp.vis.disable_visualisation=1 -a build/arm/fvp_cortex_r52/testsuites/samples/ticker.exe + +Clock Driver +------------ + +The clock driver uses the `ARMv7-AR Generic Timer`. + +Console Driver +-------------- + +The console driver uses the +`semihosting <https://developer.arm.com/documentation/dui0471/g/Semihosting/Semihosting-operations?lang=en>`_ +``SYS_READC`` and ``SYS_WRITEC`` system calls. diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst index e2fd7f2..47ad503 100644 --- a/user/bsps/arm/imx.rst +++ b/user/bsps/arm/imx.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2017, 2019 embedded brains GmbH +.. Copyright (C) 2017, 2019 embedded brains GmbH & Co. KG .. Copyright (C) 2017, 2019 Sebastian Huber imx (NXP i.MX) @@ -15,7 +15,9 @@ U-Boot or barebox. Build Configuration Options --------------------------- -The following options are available at the configure command line. +The following options can be used in the BSP section of the waf +configuration INI file. The waf defaults can be used to inspect the +values. ``BSP_PRESS_KEY_FOR_RESET`` If defined to a non-zero value, then print a message and wait until pressed @@ -73,7 +75,7 @@ image. Use the following commands: .. code-block:: none - arm-rtems5-objcopy -O binary app.exe app.bin + arm-rtems@rtems-ver-major@-objcopy -O binary app.exe app.bin gzip -9 -f -c app.bin > app.bin.gz mkimage -A arm -O linux -T kernel -a 0x80200000 -e 0x80200000 -n RTEMS -d app.bin.gz app.img diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst index 6dacfd9..30b1437 100644 --- a/user/bsps/arm/imxrt.rst +++ b/user/bsps/arm/imxrt.rst @@ -1,29 +1,48 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2020 embedded brains GmbH +.. Copyright (C) 2020 embedded brains GmbH & Co. KG .. Copyright (C) 2020 Christian Mauderer imxrt (NXP i.MXRT) ================== -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. +This BSP offers multiple variants. The `imxrt1052` supports the i.MXRT 1052 +processor on a IMXRT1050-EVKB (tested with rev A1). Some possibilities to adapt +it to a custom board are described below. 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. +The `imxrt1166-cm7-saltshaker` supports an application specific board. Adapting +it to another i.MXRT1166 based board works similar like for the `imxrt1052` BSP. + Build Configuration Options --------------------------- Please see the documentation of the `IMXRT_*` and `BSP_*` configuration options for that. You can generate a default set of options with:: - ./waf bsp_defaults --rtems-bsps=arm/imxrt1052 > config.ini + ./waf bspdefaults --rtems-bsps=arm/imxrt1052 > config.ini -Boot Process ------------- +Adapting to a different board +----------------------------- + +This is only a short overview for the most important steps to adapt the BSP to +another board. Details for most steps follow further below. + +#. The device tree has to be adapted to fit the target hardware. +#. A matching clock configuration is necessary (simplest method is to generate + it with the NXP PinMux tool) +#. The `dcd_data` has to be adapted. That is used for example to initialize + SDRAM. +#. `imxrt_flexspi_config` has to be adapted to match the Flash connected to + FlexSPI (if that is used). +#. `BOARD_InitDEBUG_UARTPins` should be adapted to match the used system + console. + +Boot Process of IMXRT1050-EVKB +------------------------------ There are two possible boot processes supported: @@ -39,7 +58,7 @@ For programming the HyperFlash in case 1, you can use the on board debugger integrated into the IMXRT1050-EVKB. You can generate a flash image out of a compiled RTEMS application with for example:: - arm-rtems6-objcopy -O binary build/arm/imxrt1052/testsuites/samples/hello.exe hello.bin + arm-rtems@rtems-ver-major@-objcopy -O binary build/arm/imxrt1052/testsuites/samples/hello.exe hello.bin 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, @@ -82,34 +101,36 @@ ones that need different values): You can find the default definitions in `bsps/arm/imxrt/start/flash-*.c`. Take a look at the `i.MX RT1050 Processor Reference Manual, Rev. 4, 12/2019` chapter -`9.7 Program image` for details about the contents. +`9.7 Program image` or `i.MX RT1166 Processor Reference Manual, Rev. 0, 05/2021` +chapter `10.7 Program image` for details about the contents. FDT --- The BSP uses a FDT based initialization. The FDT is linked into the application. -You can find the default FDT used in the BSP in -`bsps/arm/imxrt/dts/imxrt1050-evkb.dts`. The FDT is split up into two parts. The -core part is put into an `dtsi` file and is installed together with normal -headers into `${PREFIX}/arm-rtems6/imxrt1052/lib/include`. You can use that to +You can find the default FDT used in the BSPs in `bsps/arm/imxrt/dts`. The FDT +is split up into two parts. The controller specific part is put into an `dtsi` +file. The board specific one is in the dts file. Both are installed together +with normal headers into +`${PREFIX}/arm-rtems@rtems-ver-major@/${BSP}/lib/include`. You can use that to create your own device tree based on that. Basically use something like:: /dts-v1/; - + #include <imxrt/imxrt1050-pinfunc.h> #include <imxrt/imxrt1050.dtsi> - + &lpuart1 { pinctrl-0 = <&pinctrl_lpuart1>; status = "okay"; }; - + &chosen { stdout-path = &lpuart1; }; - + /* put your further devices here */ - + &iomuxc { pinctrl_lpuart1: lpuart1grp { fsl,pins = < @@ -117,43 +138,25 @@ create your own device tree based on that. Basically use something like:: IMXRT_PAD_GPIO_AD_B0_13__LPUART1_RX 0x13000 >; }; - + /* put your further pinctrl groups here */ }; You can then convert your FDT into a C file with (replace `YOUR.dts` and similar -with your FDT source names):: +with your FDT source names): + +.. code-block:: none - sh> arm-rtems6-cpp -P -x assembler-with-cpp \ - -I ${PREFIX}/arm-rtems6/imxrt1052/lib/include \ - -include "YOUR.dts" /dev/null | \ - dtc -O dtb -o "YOUR.dtb" -b 0 -p 64 + sh> arm-rtems@rtems-ver-major@-cpp -P -x assembler-with-cpp \ + -I ${PREFIX}/arm-rtems@rtems-ver-major@/imxrt1052/lib/include \ + -include "YOUR.dts" /dev/null | \ + dtc -O dtb -o "YOUR.dtb" -b 0 -p 64 sh> rtems-bin2c -A 8 -C -N imxrt_dtb "YOUR.dtb" "YOUR.c" You'll get a C file which defines the `imxrt_dtb` array. Make sure that your new C file is compiled and linked into the application. It will overwrite the existing definition of the `imxrt_dtb` in RTEMS. -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 ------------ @@ -195,10 +198,38 @@ Note that the SPI-pins on the evaluation board are shared with the SD card. Populate R278, R279, R280, R281 on the IMXRT1050-EVKB (Rev A) to use the SPI pins on the Arduino connector. +By default, the native chip selects are used. If you want to use GPIOs as chip +select instead, you can use the `cs-gpios` and `num-cs` attributes just like on +a Linux SPI controller. A maximum of `IMXRT_LPSPI_MAX_CS` pins can be used. + +The hardware doesn't support selecting no native chip select during a transfer. +Therefore one native chip select has to be reserved as a dummy if you want to be +able to use GPIOs. The pin function for this chip select must not be configured +on any pin. Dummy will be the first of the first four chip selects that is not a +native one. Example configuration:: + + &lpspi4 { + status = "okay"; + pinctrl-0 = <&my_pinctrl_lpspi4>; + cs-gpios = <0>, <0>, <&gpio1 1 0>, <0>, <&gpio11 5 1>; + num-cs = <5>; + } + +In this case, CS2 will be the dummy chip select and no pin must be configured +with that function. CS0, CS1 and CS3 are just native chip selects and should be +used via pin functions. GPIO1.1 is used as a high active CS and GPIO11.5 a low +active one. + Limitations: * Only a basic SPI driver is implemented. This is mostly a driver limitation and not a hardware one. +* GPIO CS pins on i.MXRT10xx are not tested. The chip has a lot of errate so + they might not work. +* Switching from one mode (CPOL/CPHA) to another one can lead to single wrong + edges on the CLK line if GPIO CS pins are involved. Make sure to stuff a dummy + transfer with `SPI_NO_CS` set if you use multiple modes together with a GPIO + CS. Network Interface Driver ------------------------ @@ -222,13 +253,58 @@ the SDK. But please note that they are not tested and maybe won't work out of the box. Everything that works with interrupts most likely needs some special treatment. -Caveats -------- +The SDK files are imported to RTEMS from the NXP mcux-sdk git repository that +you can find here: https://github.com/nxp-mcuxpresso/mcux-sdk/ + +The directory structure has been preserved and all files are in a +`bsps/arm/imxrt/mcux-sdk` directory. All patches to the files are marked with +`#ifdef __rtems__` markers. + +The suggested method to import new or updated files is to apply all RTEMS +patches to the mcux-sdk repository, rebase them to the latest mcux-sdk release +and re-import the files. The new base revision should be mentioned in the commit +description to make future updates simpler. + +A import helper script (that might or might not work on newer releases of the +mcux-sdk) can be found here: +https://raw.githubusercontent.com/c-mauderer/nxp-mcux-sdk/d21c3e61eb8602b2cf8f45fed0afa50c6aee932f/export_to_RTEMS.py + +Clocks and SDRAM +---------------- The clock configuration support is quite rudimentary. The same is true for SDRAM. It mostly relies on the DCD and on a static clock configuration that is taken from the NXP SDK example projects. -The MPU settings are currently quite permissive. +If you need to adapt the DCD or clock config to support a different hardware, +you should generate these files using the NXP MCUXpresso Configuration Tools. +You can add the generated files to your application to overwrite the default +RTEMS ones or you can add them to RTEMS in a new BSP variant. + +As a special case, the imxrt1052 BSP will adapt it's PLL setting based on the +chip variant. The commercial variant of the i.MXRT1052 will use a core clock of +600MHz for the ARM core. The industrial variants only uses 528MHz. For other +chip or BSP variants, you should adapt the files generated with the MCUXpresso +Configuration Tools. + +Caveats +------- + +* The MPU settings are currently quite permissive. + +* There is no power management support. + +* On the i.MXRT1166, sleeping of the Cortex M7 can't be disabled even for + debugging purposes. That makes it hard for a debugger to access the + controller. To make debugging a bit easier, it's possible to overwrite the + idle thread with the following one in the application: + + .. code-block:: c -There is no power management support. + void * _CPU_Thread_Idle_body(uintptr_t ignored) + { + (void)ignored; + while (true) { + /* void */ + } + } diff --git a/user/bsps/arm/lpc24xx.rst b/user/bsps/arm/lpc24xx.rst index ecf1d84..f287dc8 100644 --- a/user/bsps/arm/lpc24xx.rst +++ b/user/bsps/arm/lpc24xx.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2017, 2019 embedded brains GmbH +.. Copyright (C) 2017, 2019 embedded brains GmbH & Co. KG .. Copyright (C) 2017, 2019 Sebastian Huber lpc24xx (NXP LPC17XX/LPC24XX/LPC40XX) diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst index 235134f..8f40e92 100644 --- a/user/bsps/arm/raspberrypi.rst +++ b/user/bsps/arm/raspberrypi.rst @@ -12,7 +12,7 @@ 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. Setup SD card ----------------- +------------- The Raspberry Pis have an unconventional booting mechanism. The GPU boots first, initializes itself, runs the bootloader and starts the CPU. @@ -20,13 +20,13 @@ 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 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/1.20200601/boot>`_. -You can remove the ``kernel*.img`` files if you want to, but don't touch -the other 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/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. @@ -41,7 +41,7 @@ To create the kernel image: .. code-block:: none - $ arm-rtems5-objcopy -Obinary hello.exe kernel.img + $ xsarm-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel.img Copy the kernel image to the SD card. @@ -54,7 +54,7 @@ Make sure you have these lines below, in your ``config.txt``. kernel=kernel.img SPI Driver ------------- +---------- SPI drivers are registered by the ``rpi_spi_init(bool bidirectional_mode)`` function. @@ -72,7 +72,7 @@ SPI drivers are registered by the ``rpi_spi_init(bool bidirectional_mode)`` func } I2C Driver ------------- +---------- I2C drivers are registered by the ``rpi_setup_i2c_bus()`` function. @@ -132,7 +132,7 @@ In a new terminal, run GDB using .. code-block:: none - $ arm-rtems5-gdb hello.exe + $ arm-rtems@rtems-ver-major@-gdb hello.exe This will open GDB and will load the symbol table from hello.exe. Issue the following commands in the GDB prompt. diff --git a/user/bsps/arm/realview-pbx-a9.rst b/user/bsps/arm/realview-pbx-a9.rst index 15d1fbf..bbe0269 100644 --- a/user/bsps/arm/realview-pbx-a9.rst +++ b/user/bsps/arm/realview-pbx-a9.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) +.. Copyright (C) 2020 embedded brains GmbH & Co. KG realview-pbx-a9 =============== diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst index ec7440f..cdf4d43 100644 --- a/user/bsps/arm/stm32h7.rst +++ b/user/bsps/arm/stm32h7.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2020 embedded brains GmbH +.. Copyright (C) 2020 embedded brains GmbH & Co. KG .. Copyright (C) 2022 Karel Gardas <karel@functional.vision> @@ -248,7 +248,7 @@ installed. Please go to its *bin* directory. E.g. $ cd plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.200.202202231230/tools/bin Now, you will need to edit provided *config.txt* file inside the -directory. Use your favorite editor. Open the file and scrolls +directory. Use your favorite editor. Open the file and scroll down to its end. You will see following comment: .. code-block:: none @@ -332,7 +332,7 @@ Generate default configuration for the board: .. code-block:: shell - $ ./waf bsp_defaults --rtems-bsps=arm/stm32h747i-disco > stm32h747i-disco.ini + $ ./waf bspdefaults --rtems-bsps=arm/stm32h747i-disco > stm32h747i-disco.ini Regenerate build specification cache (needs a couple of seconds)... To run basic hello world or ticker samples you do not need to modify diff --git a/user/bsps/arm/xen.rst b/user/bsps/arm/xen.rst index c7085ce..d7538f0 100644 --- a/user/bsps/arm/xen.rst +++ b/user/bsps/arm/xen.rst @@ -42,13 +42,13 @@ The ``ticker.exe`` file can be found in the BSP build tree at: .. code-block:: none - arm-rtems5/c/xen_virtual/testsuites/samples/ticker.exe + arm-rtems@rtems-ver-major@/c/xen_virtual/testsuites/samples/ticker.exe The ``ticker.exe`` elf file must be translated to a binary format. .. code-block:: none - arm-rtems5-objcopy -O binary ticker.exe ticker.bin + arm-rtems@rtems-ver-major@-objcopy -O binary ticker.exe ticker.bin Then place the ``ticker.bin`` file on the dom0 filesystem. diff --git a/user/bsps/arm/xilinx-zynqmp-rpu.rst b/user/bsps/arm/xilinx-zynqmp-rpu.rst new file mode 100644 index 0000000..0dfb77e --- /dev/null +++ b/user/bsps/arm/xilinx-zynqmp-rpu.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2024 On-Line Applications Research Corporation (OAR) + +.. _BSP_arm_xilinx_zynqmp_rpu: + +Xilinx ZynqMP RPU +================= + +This BSP supports the Cortex-R5 processor on the Xilinx Zynq UltraScale+ MPSoC +platform. Basic hardware initialization is performed by the Cortex-R5 FSBL and +the BSP. This BSP supports the GICv2 interrupt controller available to the +Cortex-R5 subsystem. Since the Cortex-R5 subsystem only varies in speed, this +BSP should be functional across all chip variants as well as on Xilinx's QEMU +branch. SMP operation is not currently supported. + +Clock Driver +------------ + +The clock driver uses one of the available triple timer counters (TTCs) as the +timer interrupt source. + +Console Driver +-------------- + +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. + +Boot on ZynqMP Hardware +----------------------- + +On the ZynqMP RPU, RTEMS can be started by Cortes-R5 u-boot, Cortex-A53 u-boot, +via JTAG, or directly as part of BOOT.bin. For quick turnaround during testing, +it is recommended to use Cortex-A53 u-boot to avoid repeated BOOT.bin +generation since the provided Cortex-R5 u-boot is highly limited and has no +network or MMC/SD access. + +Note that if the RPU image is started by the Cortex-A53 u-boot, the program +sections located at ZYNQMP_RPU_RAM_INT_0_ORIGIN and ZYNQMP_RPU_RAM_INT_1_ORIGIN +must be manually relocated from DDR to TCM since the TCMs are not directly +available to the Cortex-A53 cores at their Cortex-R5 internal addresses. This +can be accomplished by disabling dcache in u-boot and using u-boot's "cp" +command. Once this is done, the program can be started at 0x0 by using u-boot's +"cpu" command to first disable core 4 and then release it in split mode. + +Hardware Boot Image Generation +------------------------------ + +When generating BOOT.bin from components, the BIF file should include at least +entries for the Cortex-R5 FSBL ([bootloader,destination_cpu=r5-0]) and the +Cortex-R5 application ([destination_cpu=r5-0]). The Cortex-R5 application should +be either a u-boot or RTEMS ELF binary. The Cortex-R5 u-boot binary can be +obtained by building it from Xilinx's u-boot repository. The Cortex-R5 FSBL can +be obtained setting up an appropriate platform project in Xilinx's current +development system. + +Boot on QEMU +------------ +The executable image is booted by Qemu in ELF format. + +Running Executables on QEMU +--------------------------- + +Xilinx's qemu-devicetrees repository must be used in conjunction with the Xilinx +QEMU available via RSB. Executables generated by this BSP can be run using the +following command: + +.. code-block:: shell + + qemu-system-aarch64 -no-reboot -nographic -M arm-generic-fdt -serial null \ + -serial mon:stdio -device loader,file=example.exe,cpu-num=4 \ + -device loader,addr=0xff5e023c,data=0x80088fde,data-len=4 \ + -device loader,addr=0xff9a0000,data=0x80000218,data-len=4 \ + -hw-dtb /xlnx-qemu-devtrees-path/LATEST/SINGLE_ARCH/board-zynqmp-zcu102.dtb \ + -m 4096 -display none + +Debugging Executables on QEMU +----------------------------- + +Debugging the RPU cores under QEMU presents unique challenges due to requiring +the AArch64 QEMU to emulate the entire processing subsystem. Debugging requires +a multi-arch GDB which can be created by adding "--enable-targets=all" to the +normal GDB configure line and then building as normal. + +To attach to the RPU core once QEMU is started with "-s -S", The following steps +are required: + +.. code-block:: shell + + aarch64-rtems6-gdb + (gdb) tar ext :1234 + (gdb) add-inferior + (gdb) inferior 2 + (gdb) file example.exe + (gdb) attach 2 diff --git a/user/bsps/arm/xilinx-zynqmp.rst b/user/bsps/arm/xilinx-zynqmp.rst index 9a605bb..fa60470 100644 --- a/user/bsps/arm/xilinx-zynqmp.rst +++ b/user/bsps/arm/xilinx-zynqmp.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2019 embedded brains GmbH +.. Copyright (C) 2019 embedded brains GmbH & Co. KG xilinx-zynqmp ============= |