diff options
Diffstat (limited to 'user/bsps')
40 files changed, 3260 insertions, 134 deletions
diff --git a/user/bsps/aarch64/a53.rst b/user/bsps/aarch64/a53.rst new file mode 100644 index 0000000..9d8e1ce --- /dev/null +++ b/user/bsps/aarch64/a53.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2020 On-Line Applications Research Corporation (OAR) + +.. _BSP_aarch64_qemu_a53_ilp32: +.. _BSP_aarch64_qemu_a53_lp64: + +Qemu A53 +======== + +This BSP supports two variants, `qemu_a53_ilp32` and `qemu_a53_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: + +.. 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 new file mode 100644 index 0000000..4de0115 --- /dev/null +++ b/user/bsps/aarch64/xilinx-zynqmp.rst @@ -0,0 +1,295 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2020 On-Line Applications Research Corporation (OAR) + +.. _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 family supports the following variants: + +* `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 +------------ + +The clock driver uses the `ARM Generic Timer`. + +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. + +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 +--------------------------- + +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 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 489e756..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 @@ -67,23 +67,39 @@ Add the following to a file named uEnv.txt: I2C Driver ---------- -The Beagle has the `i2c-0` device registered at initialization. For registering -`i2c-1` and `i2c-2` ``bbb_register_i2c_1()`` and -``bbb_register_i2c_2()`` wrapper functions are respectively used. +The Beagle i2c initialization is based on the device tree. To initialize a i2c +device, the user has to enable the respective node in the device tree using +overlays. -For registering an I2C device with a custom path (say `/dev/i2c-3`) the -function ``am335x_i2c_bus_register()`` has to be used. +For registering an I2C device with a custom path (say `/dev/i2c-eeprom`) an +overlay has to be provided. The overlay must add an additional attribute +`rtems,path` with the custom path as value to the respective i2c node. -The function prototype is given below: +For example, + +.. code-block:: none + + /dts-v1/; + + / { + compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; + + fragment@0 { + target = <0xffffffff>; -.. code-block:: C + __overlay__ { + compatible = "rtems,bsp-i2c", "ti,omap4-i2c"; + status = "okay"; + rtems,path = "/dev/i2c-eeprom"; + }; + }; - int am335x_i2c_bus_register( - const char *bus_path, - uintptr_t register_base, - uint32_t input_clock, - rtems_vector_number irq - ); + __fixups__ { + i2c0 = "/fragment@0:target:0"; + }; + }; + +The above example registers a custom path `/dev/i2c-eeprom` for i2c0. SPI Driver ---------- @@ -94,10 +110,134 @@ 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, uintptr_t register_base, rtems_vector_number irq ); + +Debugging using libdebugger +--------------------------- + +RTEMS's ``libdebugger`` requires the ARM debug resources be enabled for it to +work. The TI SOC used on the ``beagleboneblack`` board provides no access for +software to the ARM defined debug enable signal ``DBGEN``. The signal is +negated on power up locking software out of the ARM debug hardware. The signal +can only be accessed via the JTAG interface. + +The ``beagleboneblack`` BSP provides a low level solution to enable the +``DBGEN`` signal via the JTAG interface if the board has the following +hardware modification installed. The modification requires the addition of two +small wire links soldered to the pads of the JTAG connect on the underside of +the board. A small length of fine wire, a fine tip soldering iron, some good +quality solder and a pair of fine tip pliers are required. If you are new to +soldering I suggest you find something to practice on first. + +The modification details and software driver can be found in the BSP in the +file ``bsps/arm/beagle/start/bspdebug.c``. The driver is automatically run +and the ``DBGEN`` is asserted via JTAG when ``libdebugger`` is started. + +The modification is: + +1. Locate P2 on the bottom side of the board. It is the JTAG connector + pads. If you look at the underside of the board with the SD card holder to + the right the pads are top center left. There are 20 pads in two + columns. The pads are numbered 1 at the top left then 2 top right, 3 is + second top on the left, 4 is second top to the right, then the pin number + increments as you move left then right down the pads. + +2. Connect P2 to P5. + +3. Connect P7 to P13. + +The resulting wiring is: + +.. code-block:: none + + 1 === /--=== 2 + 3 === | === 4 + 5 ===--/ === 6 + 7 ===--\ === 8 + 9 === | === 10 + 11 === | === 12 + 13 ===--/ === 14 + 15 === === 16 + 17 === === 18 + 19 === === 20 + +.. figure:: ../../../images/user/bbb-p2-debug-mod.jpg + :width: 50% + :align: center + :alt: BeagleBone Black JTAG Hardware Modification + + BeagleBone Black JTAG Hardware Modification + +If ``libdebugger`` fails to detect the registers open the ``bspdebug.c`` +source and change ``has_tdo`` to ``1``, save then rebuild and install the +BSP. This will turn on an internal feeback to check the JTAG logic. Discard +the edit once the hardware is working. + +Debugging Beagle Bone Black using a JTAG debugger and gdb +--------------------------------------------------------- + +Debugging a Beagle Bone Black (or variants) is also possible using a hardware +JTAG debugger. The JTAG is available via P2. The footprint is for an ARM 20 pin +cTI connector. That connector should be used, if it is necessary to have access +to commercially available adapters. + +For hand-made cables and adapters a standard 1.27mm pitch header and a 0.635mm +ribbon cable can be much cheaper. But note that even if it looks compatible, +it's not the same pin out as a ARM Cortex 20 pin connector! + +A lot of JTAG adapters that are working together with OpenOCD will work. There +are also commercially available systems (like Segger J-Link) that work well with +the Beagle. Note that the JTAG debugger has to be compatible with ARM Cortex A8. +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:: none + + define reset + echo -- Reset target and wait for U-Boot to start kernel.\n + monitor reset + # RTEMS U-Boot starts at this address. + tbreak *0x80000000 + # Linux starts here. + tbreak *0x82000000 + continue + + echo -- Disable watchdog.\n + set *(uint32_t*)0x44e35048=0xAAAA + while (*(uint32_t*)0x44e35034 != 0) + end + set *(uint32_t*)0x44e35048=0x5555 + while (*(uint32_t*)0x44e35034 != 0) + end + + echo -- Overwrite kernel with application to debug.\n + load + end + + target remote :2331 + +Note that you might have to replace the ``monitor reset`` by some other command +that resets the target using your specific debugger. You also have to replace +the ``target remote :2331`` to match the port of your gdb server. + +The script expects that the Beagle Bone Black starts some application from an SD +card or from eMMC. It defines a ``reset`` command that does the following: + + * reset the target + * let U-Boot run, initialize the base system, load an FDT and an application + * break at the application entry point + * disable the watchdog + * overwrite the application that has been loaded by U-Boot with the application + provided as an command line argument to gdb + +This method has the advantage that the application is executed in nearly the +same environment like it would be executed if loaded by U-Boot directly (except +for the watchdog). diff --git a/user/bsps/arm/bsp-csb337.rst b/user/bsps/arm/csb337.rst index 6f7d927..6f7d927 100644 --- a/user/bsps/arm/bsp-csb337.rst +++ b/user/bsps/arm/csb337.rst 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 bc93ae3..47ad503 100644 --- a/user/bsps/arm/imx.rst +++ b/user/bsps/arm/imx.rst @@ -1,20 +1,23 @@ .. 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) ============== This BSP offers only one variant, the `imx7`. This variant supports the i.MX -7Dual processor. The basic hardware initialization is not performed by the -BSP. A boot loader with device tree support must be used to start the BSP, -e.g. U-Boot. +7Dual processor and the i.MX 6UL/ULL processor family (with slightly different +clock settings). The basic hardware initialization is not performed by the BSP. +A boot loader with device tree support must be used to start the BSP, e.g. +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 @@ -40,9 +43,30 @@ The following options are available at the configure command line. ``IMX_CCM_UART_HZ`` The UART clock frequency in Hz (default is 24000000). +``IMX_CCM_ECSPI_HZ`` + The ECSPI clock frequency in Hz (default is 67500000). + ``IMX_CCM_AHB_HZ`` The AHB clock frequency in Hz (default is 135000000). +``IMX_CCM_SDHCI_HZ`` + The SDHCI clock frequency in Hz (default is 196363000). + +Clock settings for different boards +----------------------------------- + +The default clock settings are targeted for an i.MX 7Dual evaluation board using +U-Boot. Some other boards with different boot loaders need different settings: + + * Phytec phyCORE-i.MX 6ULL (system on module) with MCIMX6Y2CVM08AB and a + barebox bootloader (version ``2019.01.0-bsp-yocto-i.mx6ul-pd19.1.0``): + + * IMX_CCM_IPG_HZ=66000000 + * IMX_CCM_UART_HZ=80000000 + * IMX_CCM_AHB_HZ=66000000 + * IMX_CCM_SDHCI_HZ=198000000 + * IMX_CCM_ECSPI_HZ=60000000 + Boot via U-Boot --------------- @@ -51,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 @@ -65,6 +89,14 @@ The ``loadfdt`` command may be not defined in your U-Boot environment. Just replace it with the appropriate commands to load the device tree at ``${fdt_addr}``. +Boot via barebox +---------------- + +The same command like for U-Boot can be used to generate an application image. +In a default configuration barebox expects an fdt image called `oftree` and a +kernel image called `zImage` in the root folder of the bootable medium (e.g. an +SD card). + Clock Driver ------------ @@ -133,6 +165,34 @@ system controls: A value of zero for the time or count disables the interrupt coalescing in the corresponding direction. +On the Phytec phyCORE-i.MX 6ULL modules the PHY needs an initialization for the +clock. A special PHY driver handles that (``ksz8091rnb``). Add it to your libbsd +config like that: + +.. code-block:: c + + #define RTEMS_BSD_CONFIG_BSP_CONFIG + #define RTEMS_BSD_CONFIG_INIT + SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus); + #include <machine/rtems-bsd-config.h> + +On chips with two Ethernet controllers, the MDIO lines are shared between the +two controllers for a number of chips variants. This is currently supported with +some restrictions on the initialization order. For this configuration to work, +you have to make sure that the pins are assigned to the Ethernet controller that +is initialized first. The initialization order in `libbsd` depends on the order +of the Ethernet controllers in the device tree. So if (for example) `fec2` is +defined in the device tree sources before `fec1`, make sure that the MDIO lines +are routed to `fec2` and that the Ethernet PHYs are a sub-node of `fec2` in the +device tree. + +Note that the clock for the second Ethernet controller is not necessarily +enabled in the `CCM`. On the i.MX6UL/ULL, the clock will be enabled by the +startup code if the node that is compatible with `fsl,imx6ul-anatop` can be +found in the device tree. If you have trouble with the second Ethernet +controller make sure that the `ENET2_125M_EN` bit in the `CCM_ANALOG_PLL_ENET` +register is set as expected. + MMC/SDCard Driver ----------------- diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst new file mode 100644 index 0000000..30b1437 --- /dev/null +++ b/user/bsps/arm/imxrt.rst @@ -0,0 +1,310 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2020 embedded brains GmbH & Co. KG +.. Copyright (C) 2020 Christian Mauderer + +imxrt (NXP i.MXRT) +================== + +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 bspdefaults --rtems-bsps=arm/imxrt1052 > config.ini + +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: + +1) The ROM code loads a configuration from HyperFlash (connected to FlexSPI), + does some initialization (based on device configuration data (DCD)) and then + starts the application. This is the default case. `linkcmds.flexspi` is used + for this case. + +2) Some custom bootloader does the basic initialization, loads the application + to SDRAM and starts it from there. Select the `linkcmds.sdram` for this. + +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-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, +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 +SDRAM after the BSP started from flash did the basic initialization. + +Flash Image +----------- + +For booting from a HyperFlash (or other storage connected to FlexSPI), the ROM +code of the i.MXRT first reads some special flash header information from a +fixed location of the connected flash device. This consists of the Image vector +table (IVT), Boot data and Device configuration data (DCD). + +In RTEMS, these flash headers are generated using some C-structures. If you use +a board other than the IMXRT1050-EVKB, those structures have to be adapted. To +do that re-define the following variables in your application (you only need the +ones that need different values): + +.. code-block:: c + + #include <bsp/flash-headers.h> + const uint8_t imxrt_dcd_data[] = + { /* Your DCD data here */ }; + const ivt imxrt_image_vector_table = + { /* Your IVT here */ }; + const BOOT_DATA_T imxrt_boot_data = + { /* Your boot data here */ }; + const flexspi_nor_config_t imxrt_flexspi_config = + { /* Your FlexSPI config here */ }; + +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` 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 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 = < + IMXRT_PAD_GPIO_AD_B0_12__LPUART1_TX 0x8 + 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): + +.. code-block:: none + + 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. + +Clock Driver +------------ + +The clock driver uses the generic `ARMv7-M Clock`. + +IOMUX +----- + +The i.MXRT IOMUXC is initialized based on the FDT. For that, the `pinctrl-0` +fields of all devices with a status of `ok` or `okay` will be parsed. + +Console Driver +-------------- + +LPUART drivers are registered based on the FDT. The special `rtems,path` +attribute defines where the device file for the console is created. + +The `stdout-path` in the `chosen` node determines which LPUART is used for the +console. + +I2C Driver +---------- + +I2C drivers are registered based on the FDT. The special `rtems,path` attribute +defines where the device file for the I2C bus is created. + +Limitations: + +* Only basic I2C is implemented. This is mostly a driver limitation and not a + hardware one. + +SPI Driver +---------- + +SPI drivers are registered based on the FDT. The special `rtems,path` attribute +defines where the device file for the SPI bus is created. + +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 +------------------------ + +The network interface driver is provided by the `libbsd`. It is initialized +according to the device tree. + +Note on the hardware: The i.MXRT1050 EVKB maybe has a wrong termination of the +RXP, RXN, TXP and TXN lines. The resistors R126 through R129 maybe shouldn't be +populated because the used KSZ8081RNB already has an internal termination. +Ethernet does work on short distance anyway. But keep it in mind in case you +have problems. Source: +https://community.nxp.com/t5/i-MX-RT/Error-in-IMXRT1050-EVKB-and-1060-schematic-ethernet/m-p/835540#M1587 + +NXP SDK files +------------- + +A lot of peripherals are currently not yet supported by RTEMS drivers. The NXP +SDK offers drivers for these. For convenience, the BSP compiles the drivers from +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. + +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. + +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 + + 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 c26f4b5..8f40e92 100644 --- a/user/bsps/arm/raspberrypi.rst +++ b/user/bsps/arm/raspberrypi.rst @@ -5,13 +5,14 @@ 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. Setup SD card ----------------- +------------- The Raspberry Pis have an unconventional booting mechanism. The GPU boots first, initializes itself, runs the bootloader and starts the CPU. @@ -19,11 +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 files for the GPU to proceed. 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 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. @@ -38,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. @@ -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 ------------------ @@ -93,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 96710a0..bbe0269 100644 --- a/user/bsps/arm/realview-pbx-a9.rst +++ b/user/bsps/arm/realview-pbx-a9.rst @@ -1,8 +1,20 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2019 TBD +.. Copyright (C) 2020 embedded brains GmbH & Co. KG realview-pbx-a9 =============== -TODO. +The ``arm/realview_pbx_a9_qemu`` BSP is intended to be used with Qemu. The +Qemu ``realview-pbx-a9`` machine can be used to run SMP tests using for example +the Qemu ``-smp 4`` command line option. + +The command line to execute an ELF file :file:`app.exe` on this Qemu machine +is: + +.. code-block:: none + + export QEMU_AUDIO_DRV="none" + qemu-system-arm -net none -nographic -M realview-pbx-a9 -m 256M -kernel app.exe + +You do not need to specify a device tree blob. diff --git a/user/bsps/arm/bsp-stm32f4.rst b/user/bsps/arm/stm32f4.rst index 23e764e..23e764e 100644 --- a/user/bsps/arm/bsp-stm32f4.rst +++ b/user/bsps/arm/stm32f4.rst diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst new file mode 100644 index 0000000..cdf4d43 --- /dev/null +++ b/user/bsps/arm/stm32h7.rst @@ -0,0 +1,587 @@ +.. SPDX-License-Identifier: CC-BY-SA-4.0 + +.. Copyright (C) 2020 embedded brains GmbH & Co. KG + +.. Copyright (C) 2022 Karel Gardas <karel@functional.vision> + +stm32h7 +======= + +This BSP supports the +`STM32H7 Series <https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html>`_. + +The BSP is known to run on these boards on specified core with using specified BSP variant. + +.. table:: + + +----------------------------------------------------------------------------------+-----------+------------------------+ + | Board name | Core name | BSP variant name | + +==================================================================================+===========+========================+ + |`STM32H743I-EVAL 2 <https://www.st.com/en/evaluation-tools/stm32h743i-eval.html>`_| M7 | arm/stm32h7 | + +----------------------------------------------------------------------------------+-----------+------------------------+ + |`STM32H743ZI-Nucleo <https://www.st.com/en/evaluation-tools/nucleo-h743zi.html>`_ | M7 | arm/nucleo-h743zi | + +----------------------------------------------------------------------------------+-----------+------------------------+ + |`STM32H7B3I-DK <https://www.st.com/en/evaluation-tools/stm32h7b3i-dk.html>`_ | M7 | arm/stm32h7b3i-dk | + +----------------------------------------------------------------------------------+-----------+------------------------+ + |`STM32H757I-EVAL <https://www.st.com/en/evaluation-tools/stm32h757i-eval.html>`_ | M7 | arm/stm32h757i-eval | + | +-----------+------------------------+ + | | M4 | arm/stm32h757i-eval-m4 | + +----------------------------------------------------------------------------------+-----------+------------------------+ + |`STM32H747I-DISCO <https://www.st.com/en/evaluation-tools/stm32h747i-disco.html>`_| M7 | arm/stm32h747i-disco | + | +-----------+------------------------+ + | | M4 | arm/stm32h747i-disco-m4| + +----------------------------------------------------------------------------------+-----------+------------------------+ + + +Clock Driver +------------ + +The clock driver uses the `ARMv7-M Systick` module. The HSE (external +oscillator) value can also be different for different evaluation or custom +boards, so it is recommended to check the default values of the BSP. + +Console Driver +-------------- + +The console driver supports the on-chip UART and USART modules. Even +the MCU supports about 10 U(S)ARTs, only those supported by the chosen +board are enabled by default configuration. The board needs to support +some kind of connector-based connection to the U(S)ART in order for the +feature to be considered supported here. +.. +.. Leaving previous notes here as a comment. They may still be useful +.. and incorporated into the later version of the document. +.. +.. Different board variations use different GPIO pins and blocks for the default +.. communication UART and it is recommended to check whether the default +.. configuration provided is valid in the BSP. + +.. To specify that the BSP should be built for the STM32H743ZI-Nucleo board, +.. users can supply ``STM32H743ZI_NUCLEO = True`` to ``config.ini`` when +.. building the BSP. + +.. Alternatively, users can supply the configuration structs defined in ``hal.h`` +.. in the application for other boards. For the console driver, the +.. ``stm32h7_usartX_config`` structs are used to configure the GPIO pins and other +.. parameters. The default implementations can be found in +.. ``bsps/arm/stm32ht/console`` in the RTEMS sources. + +Network Interface Driver +------------------------ + +The network interface driver ``if_stmac`` is provided by the ``libbsd``. + +USB Host Driver +--------------- + +The USB host driver ``dwc_otg`` is provided by the ``libbsd``. + +SD/MMC Driver +------------- + +The SDMMC driver ``st_sdmmc`` is provided by the ``libbsd``. + +The default initialization is done for the STM32H743I-EVAL 2 board. + +To use different pins, you can create a ``HAL_SD_MspInit()`` function in your +application that overwrites the default one defined in ``RTEMS``. If you don't +have direction lines like on the evaluation board, you can just skip +initializing these pins. + +If you want to use a different number of data lines, another polarity for the +data direction pins, a different voltage or similar, you have to redefine +``st_sdmmc_get_config()`` (normally provided by ``libbsd``) in your application. + +Known limitations: + +* Currently 1.8V signaling is not implemented. Therefore higher speeds like used + for UHS cards are not available. All cards fall back to High Speed transfers. +* The driver uses the IDMA only. MDMA is currently not implemented. For SDMMC1 + that means that the memory buffers can only come from AXI SRAM, QSPI memory, + Flash or the FMC (SDRAM, ...). The internal SRAM1, SRAM2, SRAM3 and SRAM4 are + not supported. SDMMC2 should not have that limitation. See ST AN5200 "Getting + started with STM32H7 Series SDMMC host controller" for more details. + + +How to run RTEMS on the board +----------------------------- +Following few paragraphs save a purpose of simple HOWTO or a quick +starting guide for the users not versed in STM32 toolchain and their +boards workflow. + +Board hardware setup +^^^^^^^^^^^^^^^^^^^^ +Connect board with the host computer using micro-USB cable connected +to micro-USB connector on the board marked with 'ST-LINK V3E' in case of evaluation +and discovery boards or with 'USB PWR' in case of Nucleo board. + +STM32CubeIDE installation +^^^^^^^^^^^^^^^^^^^^^^^^^ +Download and install STM32CubeIDE from +https://www.st.com/en/development-tools/stm32cubeide.html. Install the +software into the user directory. On Linux install with 'sudo' command +to install as a root since as part of the installation USB permissions +rules for ST-Link GDB server are also installed. The reason for +installing into the user directory is that the IDE is based on +Eclipse, which provides +its own update method and this will not work well in case of read-only +access to the installation directory. In case of any troubles consult +installation manual provided by ST here https://www.st.com/resource/en/user_manual/um2563-stm32cubeide-installation-guide-stmicroelectronics.pdf. +Although we will not used full fledged IDE here, the package provides ST-Link GDB Server which will be used for uploading RTEMS binaries to the board +memory. + +STM32CubeProgrammer installation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Download and install STM32CubeProgrammer from +https://www.st.com/en/development-tools/stm32cubeprog.html. We will +use this software for board setup required for RTEMS and later when +something goes wrong to delete content of the MCU flash memory. The +software is also internally used by the ST-Link GDB Server from +STM32CubeIDE so it is crucial to have it installed. + +Board ST-Link firmware upgrade +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Download ST-Link board firmware upgrade package from +https://www.st.com/en/development-tools/stsw-link007.html. The +software is distributed in a form of Java jar file for Linux and Mac +OSX and in a form of Windows binary for MS Windows. Unpack it +somewhere and run it with + +.. code-block:: shell + + $ unzip en.stsw-link007-v3-9-3_v3.9.3.zip + $ cd stsw-link007/AllPlatforms + $ java -jar STLinkUpgrade.jar + +Click on *Open in update mode* button and then if *Version* and *Update +to Firmware* version information are different in shown version number/code, click on *Upgrade* +button and wait till upgrade finishes. + +.. note: On Linux you will need to have libusb library installed in + order to make upgrade process working. On Ubuntu 20.04 LTS you can do + that with following command. + +.. code-block:: shell + + $ sudo apt install libusb-1.0-0 + + +Dual core board setup for RTEMS +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Current RTEMS BSP supports +running MCU in a single-core mode only on either M7 core or M4 +core. That means that to not leave other core interfering with the +system we either need to upload short infinite loop code to it or we +may switch off the core completely. The second option is what is +described here. The board by default switches on and starts both +cores. Based on chosen BSP variant you may like to switch off other +core with using STMCubeProgrammer tool. +Go to the directory where you have installed STMCubeProgrammer +software and run it with + +.. code-block:: shell + + $ cd bin + $ ./STM32CubeProgrammer + + +.. important:: It is absolutely necessary you will do that from inside the bin + directory where STM32CubeProgrammer binary resides. If you don't, then + programmer UI will crash on attempt to connect to the board. Probable + reason is a bug in the programmer which is not able to correctly locate + its C dynamic library responsible for connecting to the ST-Link board + interface. Version 2.9.0 of the programmer is described here. Other + versions may behave a bit differently. + +When you start the programmer application, the UI window of the programmer will +appear. +Click on green *Connect* button in the right upper corner of +the UI. This will connect programmer to the board. +Then click on *OB* +icon in the left upper corner. Actually this is hidden menu item which you +can un-hide by clicking on menu icon (three horizontal stripes) in the +upper left corner. +When you click on *OB* or *Option bytes* in un-hidden state, then +click on *User Configuration* in the options list and when the user +configuration list opens +unselect preselected *BCM4* item inside it to switch off M4 core or +unselect preselected *BCM7* item to switch off M7 core from +starting up. The action needs to be saved by clicking on *Apply* button +below the option table. + +.. warning:: Be careful! Wrong setup in STM32H7 configuration may result in + *bricked* board. + +Do not forget to disconnect the programmer application from the board by clicking on green *Disconnect* button +in the upper right corner and then close the programmer UI. + +.. important:: If you keep programmer connected then you will not be able + to connect ST-Link GDB server to the board and upload RTEMS binary to + it. + + +STM32CubeIDE ST-Link GDB Server setup +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +In order to use STM provided ST-Link GDB server externally, that is +not from inside the IDE, we need to configure it. Please go to the +directory where you have installed STM32CubeIDE software. Look for +file containing *ST-LINK* string inside its name. Following shell +command sequence shows example about how to find it. + +.. code-block:: shell + + $ cd $HOME/sfw/stm32cubeide_1.8.0 + $ find . -name 'ST-LINK*' + ./plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.200.202202231230/tools/bin/ST-LINK_gdbserver.sh + ./plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.200.202202231230/tools/bin/ST-LINK_gdbserver + ./plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.100.202109301221/tools/bin/ST-LINK_gdbserver.sh + ./plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.100.202109301221/tools/bin/ST-LINK_gdbserver + +Notice that in this particular installation case we already have two +versions of GDB server installed. This is due to fact that version +1.8.0 of the IDE was later upgraded to 1.9.0 version. Anyway, we will choose +to use the latest one, or if there is only one, then the only one +installed. Please go to its *bin* directory. E.g. + +.. code-block:: shell + + $ 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 scroll +down to its end. You will see following comment: + +.. code-block:: none + + ############################################################### + # -cp <path> : Path to STM32CubeProgrammer + # Modify to correct path + # for STM32_Programmer_CLI executable + ############################################################### + -cp + +and here you will need to place path where your STM32CubeProgrammer is +installed directly behind the *-cp* parameter. E.g. + +.. code-block:: none + + ############################################################### + # -cp <path> : Path to STM32CubeProgrammer + # Modify to correct path + # for STM32_Programmer_CLI executable + ############################################################### + -cp /home/karel/sfw/stm32cubeide_1.8.0/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_2.0.200.202202231230/tools/bin + +Once you are done with it, you can save the file and close the +editor. Let's verify that GDB server is configured and running well by starting +it inside the shell. Please go inside the directory where +ST-LINK_gdbserver.sh is located and run it by: + +.. code-block:: shell + + $ ./ST-LINK_gdbserver.sh + +If everything is all right and if you have board still connected to +the host computer then you should see output like following: + +.. code-block:: shell + + $ ./ST-LINK_gdbserver.sh + + STMicroelectronics ST-LINK GDB server. Version 6.1.0 + Copyright (c) 2022, STMicroelectronics. All rights reserved. + + Starting server with the following options: + Persistent Mode : Enabled + LogFile Name : debug.log + Logging Level : 31 + Listen Port Number : 61234 + Status Refresh Delay : 15s + Verbose Mode : Disabled + SWD Debug : Enabled + + COM frequency = 24000 kHz + Target connection mode: Default + Reading ROM table for AP 0 @0xe00fefd0 + Hardware watchpoint supported by the target + ST-LINK Firmware version : V3J9M3 + Device ID: 0x450 + PC: 0x8028fa4 + ST-LINK device status: HALT_MODE + ST-LINK detects target voltage = 3.28 V + ST-LINK device status: HALT_MODE + ST-LINK device initialization OK + Stm32Device, pollAndNotify running... + SwvSrv state change: 0 -> 1 + Waiting for connection on port 61235... + Waiting for debugger connection... + Waiting for connection on port 61234... + +In output above you can see ST-Link GDB server waiting for debugger +connection. If this is the case in your case, then you can finish GDB server by hitting +*Ctrl-C* key combination. + +RTEMS BSP samples build and run +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +We will use STM32H747I-DISCO board as an example hereafter. If you use +different board please adjust configuration steps in BSP configuration +accordingly. You should use BSP variant name specified for your +particular board in the table above. + +Generate default configuration for the board: + +.. code-block:: shell + + $ ./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 +default BSP configuration here as the compilation of basic RTEMS demo samples is +enabled by default. Let's continue with configuration of +the RTEMS source by running following command. Please change the RTEMS +tools installation prefix to suite your installation. + +.. code-block:: shell + + $ ./waf configure --rtems-bsps=arm/stm32h747i-disco --rtems-config=./stm32h747i-disco.ini --rtems-tools=$HOME/workspace/rtems-tools + Setting top to : /home/rtems/workspace/rtems + Setting out to : /home/rtems/workspace/rtems/build + Configure board support package (BSP) : arm/stm32h747i-disco + Checking for program 'arm-rtems6-gcc' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-gcc + Checking for program 'arm-rtems6-g++' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-g++ + Checking for program 'arm-rtems6-ar' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-ar + Checking for program 'arm-rtems6-ld' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-ld + Checking for program 'ar' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-ar + Checking for program 'g++, c++' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-g++ + Checking for program 'ar' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-ar + Checking for program 'gas, gcc' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-gcc + Checking for program 'ar' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-ar + Checking for program 'gcc, cc' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-gcc + Checking for program 'ar' : /home/rtems/workspace/rtems-tools/bin/arm-rtems6-ar + Checking for asm flags '-MMD' : yes + Checking for c flags '-MMD' : yes + Checking for cxx flags '-MMD' : yes + 'configure' finished successfully (0.454s) + +Build the BSP including samples using *build* command: + +.. code-block:: shell + + $ ./waf build + +the command outputs a lot of information about files being compiled +and ends with output like: + +.. code-block:: shell + + Waf: Leaving directory `/home/rtems/workspace/rtems/build/arm/stm32h747i-disco' + 'build_arm/stm32h747i-disco' finished successfully (12.086s) + +As your RTEMS BSP including samples is compiled, we will proceed with +running the hello world sample on the board now. +Open 3 shell windows for the test on the host computer. Also make sure +board is connected to the computer and is running. It does not matter +if manufacturer's demo is running there or if you navigated to some +demo part and left it there. ST-Link GDB server always takes over the +board when connected to it. + +Start GDB server in the first window by switching to GDB server +directory and running the shell script. This is from testing machine +installation, the path to GDB server will probably look different in your +installation case. + +.. code-block:: shell + + $ cd sfw/stm32cubeide_1.8.0/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.200.202202231230/tools/bin + $ ./ST-LINK_gdbserver.sh + + STMicroelectronics ST-LINK GDB server. Version 6.1.0 + Copyright (c) 2022, STMicroelectronics. All rights reserved. + + Starting server with the following options: + Persistent Mode : Enabled + LogFile Name : debug.log + Logging Level : 31 + Listen Port Number : 61234 + Status Refresh Delay : 15s + Verbose Mode : Disabled + SWD Debug : Enabled + + COM frequency = 24000 kHz + Target connection mode: Default + Reading ROM table for AP 0 @0xe00fefd0 + Hardware watchpoint supported by the target + ST-LINK Firmware version : V3J9M3 + Device ID: 0x450 + PC: 0x8028fa4 + ST-LINK device status: HALT_MODE + ST-LINK detects target voltage = 3.28 V + ST-LINK device status: HALT_MODE + ST-LINK device initialization OK + Stm32Device, pollAndNotify running... + SwvSrv state change: 0 -> 1 + Waiting for connection on port 61235... + Waiting for debugger connection... + Waiting for connection on port 61234... + +In second shell window you will need to run your terminal program and +connect to the board virtual serial port. Following steps describes +how to do that on the Ubuntu 20.04. The recommended way here is to use minicom. Let's install it +first by: + +.. code-block:: shell + + $ sudo apt install minicom + +And run it with root privileges to be able to reach USB serial port +provided by board: + +.. code-block:: shell + + $ sudo minicom -s + +The minicom is invoked with configuration menu open. Go into the +*Serial port setup* and hit *a* key to select *Serial Device* +setup. Change */dev/modem* from there into */dev/ttyACM0* and hit +*Enter* key. Hit *f* key to change hardware flow control from *Yes* to +*No*. When you are done with it, you can hit *Enter* key to finish +this part of configuration and then scrolls in menu to *Exit* and hit +*Enter* key on it. The minicom will switch to terminal mode with just +provided configuration. + +In the third shell window navigate into the BSP build directory and start +RTEMS GDB with the hello.exe sample. + +.. code-block:: shell + + $ arm-rtems6-gdb build/arm/stm32h747i-disco/testsuites/samples/hello.exe + GNU gdb (GDB) 10.1.90.20210409-git + Copyright (C) 2021 Free Software Foundation, Inc. + License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> + This is free software: you are free to change and redistribute it. + There is NO WARRANTY, to the extent permitted by law. + Type "show copying" and "show warranty" for details. + This GDB was configured as "--host=x86_64-linux-gnu --target=arm-rtems6". + Type "show configuration" for configuration details. + For bug reporting instructions, please see: + <https://www.gnu.org/software/gdb/bugs/>. + Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + + For help, type "help". + Type "apropos word" to search for commands related to "word"... + Reading symbols from build/arm/stm32h747i-disco/testsuites/samples/hello.exe... + (gdb) + +Now, you need to connect GDB with the ST's GDB server by: + +.. code-block:: shell + + (gdb) target extended-remote :61234 + Remote debugging using :61234 + 0x08028fa4 in ?? () + (gdb) + +and finally you will need to load hello.exe binary into the board +memory by: + +.. code-block:: shell + + (gdb) load + Loading section .start, size 0x458 lma 0x24000000 + Loading section .text, size 0xfca8 lma 0x24000480 + Loading section .init, size 0xc lma 0x24010128 + Loading section .fini, size 0xfecc lma 0x24010134 + Loading section .rodata, size 0x1aab lma 0x24020000 + Loading section .ARM.exidx, size 0x8 lma 0x24021aac + Loading section .eh_frame, size 0x4 lma 0x24021ab4 + Loading section .init_array, size 0x4 lma 0x24021ab8 + Loading section .fini_array, size 0x4 lma 0x24021abc + Loading section .rtemsroset, size 0x540 lma 0x24021ac0 + Loading section .data, size 0x6a4 lma 0x24022000 + Start address 0x24000400, load size 140923 + Transfer rate: 684 KB/sec, 2562 bytes/write. + (gdb) + +If everything went fine, then you can run the RTEMS binary by using +*cont* GDB command. + +.. note:: Memory address values in the load output in the gdb shows + that we have loaded our application into the AXI + SRAM. Memory addresses will be different when loading into + different part of MCU memory. + +.. code-block:: shell + + (gdb) cont + Continuing. + +Note that this command should never finish. To see the actual output +from RTEMS switch to +the second shell window with minicom (or other terminal emulation +program) running and you should see hello output +there: + +.. code-block:: none + + *** BEGIN OF TEST HELLO WORLD *** + *** TEST VERSION: 6.0.0.50ce036cfbd9807a54af47eb60eadb6a33a9e82d + *** TEST STATE: EXPECTED_PASS + *** TEST BUILD: + *** TEST TOOLS: 10.3.1 20220224 (RTEMS 6, RSB 49e3dac17765fa82ce2f754da839638ee352f95c, Newlib 64b2081) + Hello World + + *** END OF TEST HELLO WORLD *** + + + [ RTEMS shutdown ] + RTEMS version: 6.0.0.50ce036cfbd9807a54af47eb60eadb6a33a9e82d + RTEMS tools: 10.3.1 20220224 (RTEMS 6, RSB 49e3dac17765fa82ce2f754da839638ee352f95c, Newlib 64b2081) + executing thread ID: 0x08a010001 + +Since default RTEMS BSP configuration resets the board after run +immediately you can also see output from the immediately started ST +demo: + +.. code-block:: none + + STM32H747I-DISCO_MB1248: Out Of the Box Demonstration V1.0.1 (Build Aug 22 2019 at 11:56:22) + STM32H747I-DISCO_MB1248: ST Menu Launcher V1.1.0 + CPU running at 400MHz, Peripherals at 100MHz/100Mz + +which is not a problem here at all. Later we can reconfigure BSP to +not reset board to prevent demo output here. + +How to load binary file into the QSPI NOR +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Connect the board to your host computer using micro-USB +cable. Start STM32CubeProgrammer and connect it to the board by +clicking on *Connect* button which is located in the right upper +corner of the programmer application UI. For accessing QSPI connected +memory you will need to configure programmer's external loader which +needs to match your target board. Click on *EL* icon (or *External +loaders*) in the left sidebar menu. Either go thorough the list of +external loaders or just search for your board by typing board +name (or part of the name) into the search bar located on top of the table view. When +you find your board, select it by selecting rectangle in the *Select* +table column. That's what is needed to make programmer ready to +program your board memory. +For uploading file to the board, you need to continue with clicking on +*Erase & programming* menu item in the left sidebar menu. It's second item +from the top. Now, let's select +your file to upload by clicking on *Browse* button and selecting the +file name from your host computer filesystem. The most important thing here is +to specify start address of flashing process. You need to do that by +typing start address into the *Start address* field. + +.. note:: Usually external memory connected to QSPI has 0x90000000 starting + address. + +When all is set you can click on *Start Programming* button. + +.. important:: Cube programmer is very picky about files it shows in the file list. The only recognized suffixes are: elf, bin, hex and + similar. Also do not try to fool programmer by renaming let's say text + file to bin file. It'll detect file type as ascii text and will not + show it in the list of files to flash. So bin file type is really for + media types like avi, jpeg, mpeg or for binary dumps from elf + files. If you need to save text file, convert it to hex file first. 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-zynq.rst b/user/bsps/arm/xilinx-zynq.rst index 909b23e..0ac4487 100644 --- a/user/bsps/arm/xilinx-zynq.rst +++ b/user/bsps/arm/xilinx-zynq.rst @@ -1,8 +1,146 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2019 TBD +.. Copyright (C) 2015, 2020 Chris Johns (chrisj@rtems.org) xilinx-zynq =========== -TODO. +This BSP supports the Xilinx Zynq range of devices. This family of +devices contain the same ARM hard IP and the different parts have +different sizes of programable logic. + +The BSP defaults may need to be adjusted using ``configure`` BSP +options to match the size of memory your board may have. + +Bootloader +---------- + +The bootloader initialises the Zynq device. The Xilinx tool provide an +interface to configure the hardware. This is includes the buses, +clocks, memory and UART board rate. The output of this is called +``ps7_init`` and it a C file. The Xilinx SDK builds a first stage boot +loader (FSBL) using this file. + +The U-Boot boot loader has it's own FSBL called ``MLO`` to initialise +the hardware. + +Clocks +------ + +An application can provide a function called: + +.. code-block:: none + + uint32_t a9mpcore_clock_periphclk(void); + +to return the peripheral clock. Normally this is half the CPU +clock. This function is declared ``weak`` so you can override the +default behaviour by providing it in your application. + +Console +------- + +The console driver for the UARTs will always be initialized to a +baud rate of 115200 with 8 bit characters, 1 stop bit and no parity +bits during start up. +Previous configurations programmed into the hardware by the Xilinx +tools or a bootloader will be overwritten. + +The settings for the console driver can be changed by the user +application through the termios API afterwards. + +Network +------- + +The Cadence network interface driver of LibBSD works on the Xilinx Zynq +platform. The hardware checksum support works on real hardware but does not +seem to be supported on Qemu therefore the default state is to disable +``IFCAP_TXCSUM`` and ``IFCAP_RXCSUM`` and this can be enabled from the shell +with: + +.. code-block:: none + + ifconfig cgem0 rxcsum txcsum + +or with an ``ioctl()`` call to the network interface driver with ``SIOCSIFCAP`` +and the mask ``IFCAP_TXCSUM`` and ``IFCAP_RXCSUM`` set. + +Debugging with xilinx_zynq_a9_qemu +---------------------------------- + +To debug an application add the QEMU options ``-s``. If you need to +debug an initialisation issue also add ``-S``. For example to debug a +networking application you could use: + +.. code-block:: none + + qemu-system-arm -M xilinx-zynq-a9 -m 256M -no-reboot -serial \ + null -serial mon:stdio -nographic \ + -net nic,model=cadence_gem -net vde,id=vde0,sock=/tmp/vde1 \ + -kernel myapp.exe \ + -s -S + +Start GDB with the same executable QEMU is running and connect to the +QEMU GDB server: + +.. code-block:: none + + (gdb) target remote :1234 + +If your application is crashing set a breakpoint on the fatal error +handler: + +.. code-block:: none + + (gdb) b bsp_fatal_extension + +Enter continue to run the application. Running QEMU loads the +executable and initialises the CPU. If the ``-S`` option is provided +the CPU is held in reset. Without the option the CPU runs starting +RTEMS. Either way you are connecting to set up target and all you need +to do is continue: + +.. code-block:: none + + (gdb) c + +If you have a crash and the breakpoint on ``bsp_fatal_extension`` is +hit, load the following a GDB script: + +.. code-block:: none + + define arm-crash + set $code = $arg0 + set $r0 = ((const rtems_exception_frame *) $code)->register_r0 + set $r1 = ((const rtems_exception_frame *) $code)->register_r1 + set $r2 = ((const rtems_exception_frame *) $code)->register_r2 + set $r3 = ((const rtems_exception_frame *) $code)->register_r3 + set $r4 = ((const rtems_exception_frame *) $code)->register_r4 + set $r5 = ((const rtems_exception_frame *) $code)->register_r5 + set $r6 = ((const rtems_exception_frame *) $code)->register_r6 + set $r7 = ((const rtems_exception_frame *) $code)->register_r7 + set $r8 = ((const rtems_exception_frame *) $code)->register_r8 + set $r9 = ((const rtems_exception_frame *) $code)->register_r9 + set $r10 = ((const rtems_exception_frame *) $code)->register_r10 + set $r11 = ((const rtems_exception_frame *) $code)->register_r11 + set $r12 = ((const rtems_exception_frame *) $code)->register_r12 + set $sp = ((const rtems_exception_frame *) $code)->register_sp + set $lr = ((const rtems_exception_frame *) $code)->register_lr + set $pc = ((const rtems_exception_frame *) $code)->register_pc + set $cpsr = ((const rtems_exception_frame *) $code)->register_cpsr + end + +Enter the command: + +.. code-block:: none + + (gdb) arm-crash code + + +Enter ``bt`` to see the stack back trace. + +The script moves the context back to the crash location. You should be +able to view variables and inspect the stack. + +The fatal error handler runs inside an exception context that is not +the one than generated the exception. 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 ============= diff --git a/user/bsps/bsps-aarch64.rst b/user/bsps/bsps-aarch64.rst index 4b2e749..f99843a 100644 --- a/user/bsps/bsps-aarch64.rst +++ b/user/bsps/bsps-aarch64.rst @@ -1,8 +1,12 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG aarch64 (AArch64) ***************** -There are no AArch64 BSPs yet. +.. include:: aarch64/a53.rst +.. include:: aarch64/a72.rst +.. include:: aarch64/xilinx-versal.rst +.. include:: aarch64/xilinx-zynqmp.rst +.. include:: aarch64/raspberrypi4.rst
\ No newline at end of file diff --git a/user/bsps/bsps-arm.rst b/user/bsps/bsps-arm.rst index feff637..bd335fa 100644 --- a/user/bsps/bsps-arm.rst +++ b/user/bsps/bsps-arm.rst @@ -1,29 +1,34 @@ .. 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 arm (ARM) ********* -.. include:: arm/altera-cyclone-v.rst -.. include:: arm/atsam.rst -.. include:: arm/beagle.rst -.. include:: arm/csb336.rst -.. include:: arm/csb337.rst -.. include:: arm/edb7312.rst -.. include:: arm/gumstix.rst -.. include:: arm/imx.rst -.. include:: arm/lm3s69xx.rst -.. include:: arm/lpc176x.rst -.. include:: arm/imx.rst -.. include:: arm/lpc32xx.rst -.. include:: arm/raspberrypi.rst -.. include:: arm/realview-pbx-a9.rst -.. include:: arm/rtl22xx.rst -.. include:: arm/smdk2410.rst -.. include:: arm/stm32f4.rst -.. include:: arm/tms570.rst -.. include:: arm/xen.rst -.. include:: arm/xilinx-zynq.rst -.. include:: arm/xilinx-zynqmp.rst +.. toctree:: + + arm/altera-cyclone-v.rst + arm/atsam.rst + arm/beagle.rst + arm/csb336.rst + arm/csb337.rst + arm/edb7312.rst + arm/fvp.rst + arm/gumstix.rst + arm/imx.rst + arm/imxrt.rst + arm/lm3s69xx.rst + arm/lpc176x.rst + arm/lpc24xx.rst + arm/raspberrypi.rst + arm/realview-pbx-a9.rst + arm/rtl22xx.rst + arm/smdk2410.rst + arm/stm32f4.rst + arm/stm32h7.rst + arm/tms570.rst + arm/xen.rst + arm/xilinx-zynq.rst + arm/xilinx-zynqmp.rst + arm/xilinx-zynqmp-rpu.rst diff --git a/user/bsps/bsps-bfin.rst b/user/bsps/bsps-bfin.rst index db7f721..eeb426e 100644 --- a/user/bsps/bsps-bfin.rst +++ b/user/bsps/bsps-bfin.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG bfin (Blackfin) *************** diff --git a/user/bsps/bsps-epiphany.rst b/user/bsps/bsps-epiphany.rst deleted file mode 100644 index 82b05e6..0000000 --- a/user/bsps/bsps-epiphany.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-4.0 - -.. Copyright (C) 2018 embedded brains GmbH - -epiphany (Epiphany) -******************* - -epiphany_sim -============ - -TODO. diff --git a/user/bsps/bsps-i386.rst b/user/bsps/bsps-i386.rst index a29edf6..81f5fd8 100644 --- a/user/bsps/bsps-i386.rst +++ b/user/bsps/bsps-i386.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG i386 **** @@ -8,4 +8,421 @@ i386 pc386 ===== -TODO. +This BSP supports a standard Intel/AMD PC on i386 and up CPUs. If run +on a Pentium or above, the TSC register is used for timing calibration +purposes rather than relying entirely on the i8254. +Partial support is implemented for more modern PCs which do not have a +complete complement of legacy peripherals. + +The BSP is able to utilize up to 3 GB of available RAM and up to 16 +CPUs. Hyper-threading is supported, but may not be detected by the +BSP successfully. + +.. note:: BSP capability to detect target hardware SMP details is + limited due to fact the SMP support is implemented based on + Intel Multi-Processor Specification (MPS). Final version of + the specification is version 1.4 which was released on July + 1, 1995. On most newer machines the MPS functionality was + more or less supplanted by more modern ACPI (Advanced + Configuration and Power Interface). Still, on some machine + SMP support may be fragile at least at the platform + detection and initialization state depending on the target + BIOS/ACPI/MPS compatibility implementation. + +There are several BSP variants provided which differ only in the target CPU +optimization. The most general is `pc386` which is tuned for i386. The `pc486` +variant is tuned for i486, `pc585` is tuned for Pentium, `pc586-sse` is tuned +for Pentium processor supporting SSE instructions. Finally `pc686` is tuned +for Pentium Pro processor, but generating only instructions for Pentium +and `pcp4` is tuned and generating instructions for Pentium4 processor +including SSE3 instructions. + + +Build Configuration Options +--------------------------- + +``BSP_PRESS_KEY_FOR_RESET`` + If defined to a non-zero value, then print a message and wait until + any key is pressed before resetting board when application + terminates (disabled by default). + +``BSP_RESET_BOARD_AT_EXIT`` + If defined to a non-zero value, then reset the board when the + application terminates (enabled by default). + +``BSP_PRINT_EXCEPTION_CONTEXT`` + If defined to a non-zero value, then print the exception context + when an unexpected exception occurs (enabled by default). + +``BSP_VERBOSE_FATAL_EXTENSION`` + If defined to a non-zero value, then print more information in case + of a fatal error (enabled by default). + +``BSP_ENABLE_VGA`` + Enables VGA console driver (enabled by default). + +``BSP_ENABLE_COM1_COM4`` + Enables support of COM1 thorough COM4 (enabled by default). + +``USE_COM1_AS_CONSOLE`` + Enforces usage of COM1 as a console device (disabled by default). + +``BSP_ENABLE_IDE`` + Enables legacy IDE driver (enabled by default). + +``IDE_USE_PRIMARY_INTERFACE`` + Allows RTEMS to use storage drive(s) connected to the primary IDE + interface. Disable if (i) the target hardware does not have primary + IDE interface or (ii) it does not have any drive attached to the + primary IDE interface or (iii) there is no need to use drive(s) + attached to the primary IDE interface at all (enabled by default). + +``IDE_USE_SECONDARY_INTERFACE`` + Allows RTEMS to use storage drive(s) connected to the secondary IDE + interface. Enable if (i) the target hardware does have secondary IDE + interface and (ii) there is at least one drive attached to the + secondary IDE interface and (iii) there is a need to use drive(s) + attached to the secondary IDE interface (disabled by default). + +``BSP_VIDEO_80x50`` + Sets the VGA display to 80x50 character mode (disabled by default). + +``CLOCK_DRIVER_USE_TSC`` + Enforces clock driver to use TSC register available on Pentium and + higher class CPUs. If disabled and ``CLOCK_DRIVER_USE_8243`` is + disabled too, then BSP will choose clock driver mechanism itself + during the runtime (disabled by default). + +``CLOCK_DRIVER_USE_8254`` + Enforces clock driver to use 8254 chip. If disabled and + ``CLOCK_DRIVER_USE_TSC`` is disabled too, then BSP will choose clock + driver mechanism itself during the runtime (disabled by default). + +``NUM_APP_DRV_GDT_DESCRIPTORS`` + Defines how many descriptors in GDT may be allocated for the + application or driver usage. + +``USE_CIRRUS_GD5446`` + Enables usage of Cirrus GD5446 graphic card for RTEMS frame-buffer + (disabled by default). + +``USE_VGA`` + Enables usage of generic VGA graphic card for RTEMS frame-buffer + (disabled by default). + +``USE_VBE_RM`` + Enables usage of graphic card implementing VESA BIOS Extensions for + RTEMS frame-buffer (enabled by default). + +``BSP_GDB_STUB`` + Enables GDB support for debugging over serial port (enabled by + default). + +Runtime Options +--------------- +The BSP supports several runtime options. They may be used by either setting +during boot by using target hardware bootloader or by using Qemu's +``-append`` command-line parameter in case BSP application is run +inside the Qemu emulator. + +.. option:: --console=<dev> + + specifies console + device. E.g. ``--console=/dev/com1``. COM device name may + also be followed by a baud rate like ``--console=/dev/com2,19200`` + +The pc386 BSP family uses 9600 as a default baud rate +for console over UART (/dev/comX) with 8 data bits, no parity and 1 stop bit. + +.. option:: --printk=<dev> + + specifies target device for printk/getk + calls. E.g. ``--printk=/dev/vgacons`` + +If the specified console device is not present then suitable fallback +device is selected based on the device order specified in `Console Drivers`. + +.. option:: --video=<mode> + + specifies required video mode. The options applies only to + the systems supporting VESA BIOS Extensions. Choices are + ``auto`` which selects graphic mode automatically or + ``none``/``off`` which disables initialization of the + graphic driver or direct specification of resolution + and/or color depth by + ``<resX>x<resY>[-<bpp>]``. E.g. ``--video=none`` disables + graphic driver. Using ``--video=1280x1024`` sets video + mode to 1280x1024 pixels mode while ``--video=800x600-32`` + sets video mode to 800x600 pixels with 32bit color depth. + +.. option:: --disable-com1-com4 + + disables usage of COM1 thorough COM4. + +.. option:: --gdb=<dev> + + specifies UART device for communication between BSP's + GDB stub and GDB running on a host system. Option accepts device + and baud rate like the ``--console`` option above. + E.g. ``--gdb=/dev/com2,115200`` instructs BSP to use COM2 device + for GDB stub/host communication with the speed of 115200 bauds. + +The default GDB stub/host is similar to console over UART, i.e., +9600 baud rate, 8 data bits, no parity and 1 stop bit. + +.. option:: --gdb-break + + halts BSP execution at a break point in the BSP initialization code + and waits for GDB connection. + +.. option:: --gdb-remote-debug + + outputs the GDB remote protocol data to printk. + +Testing with Qemu +----------------- + +To test with Qemu, we need to: + +- Build / install Qemu (most distributions should have it available on the + package manager). + +Booting RTEMS in Qemu +^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: none + + $ qemu-system-i386 -m 128 -no-reboot -append \ + "--video=off --console=/dev/com1" -nographic -kernel ./hello.exe + +This command boots ``hello.exe`` application located in current +directory and sets Qemu to provide 128MB RAM and to switch both Qemu's +and BSP's video off. + +Booting RTEMS in KVM accelerated Qemu +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +When the Qemu host hardware and OS support KVM, it is possible to use it +to accelerate BSP run by using ``-machine type=q35,accel=kvm`` Qemu option. +Depending on the Qemu host configuration it may or may not require +administrator privileges to run the command. + +.. code-block:: none + + $ sudo qemu-system-i386 -machine type=q35,accel=kvm -m 128 -no-reboot \ + -append "--video=off --console=/dev/com1" -nographic -kernel \ + ./dhrystone.exe + +This command boots ``dhrystone.exe`` application and sets Qemu to use +KVM acceleration. + + +Running on a PC hardware +---------------------- + +There are several ways how to start RTEMS BSP application on the real +PC hardware. + +Booting with GRUB boot-loader +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In case the target machine does already have Linux with GRUB boot +loader installed, then the most easy way to load and boot RTEMS is +to use GRUB. This may be done in following steps: + +(i) prepare RTEMS binary and save it either to Linux + partition/directory accessible from GRUB or to an USB stick. + +(ii) boot machine to GRUB menu. + +.. note:: Some Linux installations hide GRUB menu by default and + quickly continues with booting default Linux option. If this + is the case, then during the boot hold down 'Shift' key to + un-hide the menu. + +(iii) press ``c`` key to get into the GRUB's command-line mode. + +(iv) use ``ls`` command to observe drives and partitions on them. If + unsure, use 'ls' command with drive/partition description to show + the target file system content. E.g. ``ls (hd1,msdos1)/`` will list + files on the second drive, first partition which is formatted + using fat/vfat file-system. + +.. note:: Use `ls (hdX, partY)` without a slash at the end to show + information about the partition. + +(v) use ``multiboot`` command to load the RTEMS application binary for + boot. E.g. ``multiboot (hd1,msdos2)/rtems/ticker.exe`` will load + ticker.exe from the second drive, second partition with fat/vfat + file-system and its rtems directory. + +(vi) use ``boot`` command to boot loaded binary. + +.. note:: Advantage of using GRUB for booting RTEMS is the GRUB's + support for both classical BIOS and UEFI boot. This way + RTEMS may be booted even on UEFI only systems. + +Booting with PXE/iPXE +^^^^^^^^^^^^^^^^ +PXE booting is more complex than GRUB based booting and hence requires +more infrastructure configuration. The booting may be done in two +possible ways: + +(i) using iPXE booted from an USB stick or a hard drive + +It may be done using following steps: + +- Download iPXE ISO image from http://boot.ipxe.org/ipxe.iso +- Either record it to CD/DVD or copy it to an USB stick +- boot from the medium above on the target hardware +- wait for ``Press Ctrl-B for the iPXE command line...`` prompt and once + it appears press ``Ctrl-B`` key. +- use 'dhcp' command to configure network interface card +- use 'boot' command to boot RTEMS application from specified tftp + server. E.g. ``boot tftp://10.0.0.5/hello.exe`` will boot hello.exe + application from the tftp server on host with 10.0.0.5 IP address. + +Whole interaction may look as: + +.. code-block:: none + + Press Ctrl-B for the iPXE command line... + iPXE> dhcp + Configuring (net0 <mac address>)..... ok + iPXE> boot tftp://10.0.0.5/hello.exe + + +(ii) using built in network card's PXE BIOS to boot into iPXE + +This way is more complex and requires network infrastructure +configuration changes which description is out of the scope of this +documentation. Generic steps how to achieve this are: + +- use target hardware BIOS/SETUP to enable PXE booting on the board +- setup network router to announce tftp server and file on it as a + part of the router's BOOTP/DHCP protocol reply. You should use + http://boot.ipxe.org/undionly.kpxe as a payload for non-UEFI based + booting. Put that file into tftp server served/root directory. +- reboot target hardware and it should run network card PXE BIOS which + should obtain IP address from the network router and load + undionly.kpxe file from the tftp server. Once this is done, familiar + iPXE UI appears. Follow steps described in previous paragraph to + boot RTEMS application. + +.. note:: It is not possible to use UEFI based PXE booting. Neither + directly by the network card PXE BIOS nor indirectly by + booting into iPXE. UEFI booting in both cases is not + currently supported. + +Clock Drivers +------------- + +The BSP supports two clock drivers. If there is no build option used +(see `Build Configuration Options`) for selecting particular clock +driver, then the decision which is used is done during the runtime. + +- i8254 based driver. It is used on pre-Pentium CPUs by default. +- TSC register based driver. It is used on Pentium and later CPUs by + default. + +Console Drivers +--------------- + +The BSP console supports device drivers for a variety of devices +including VGA/keyboard and a number of serial ports. The default +console is selected based on which devices are present in the +following order of priority: + +- VGA with PS/2 keyboard +- COM1 thorough COM4 +- Any COM devices on the PCI bus including IO and memory mapped + +PCI-based UART devices are named ``/dev/pcicom<number>`` as they are +probed and found. The numbers sequence starts with 1. E.g. first PCI +UART device found is accessible with ``/dev/pcicom1`` name. + +Besides supporting generic devices above, the BSP also support +specific UART chips. The drivers for those are not initialized +automatically, but requires initialization from the application code: + +- Exar 17d15x (NS16550 compatible multiport PCI UART) + +Frame-Buffer Drivers +-------------------- + +The BSP supports several drivers implementing RTEMS frame-buffer +API. The default driver is for card(s) implementing VESA BIOS +Extensions. Others may be enabled by using appropriate build option +(see `Build Configuration Options`). Available drivers support: + +- generic VGA graphic card +- Cirrus Logic GD5446 +- generic graphic card supporting VESA BIOS Extensions + +Network Interface Drivers +------------------------- + +The network interface drivers are provided by the `libbsd`. + +USB Host Drivers +---------------- + +The USB host drivers are provided by the `libbsd`. + +RTC Drivers +----------- + +There are several real time clock devices supported by drivers in the +BSP. + +- Maxim DS1375 +- Mostek M48T08/M48T18 (Maxim/Dallas Semiconductor DS1643 compatible) +- Motorola MC146818A +- Renesas ICM7170 + +I2C Drivers +----------- +There are several drivers for various I2C bus connected peripherals +supported by the BSP. Supported peripherals are: + +- EEPROM +- Maxim DS1621 temperature sensor +- Semtech SC620 Octal LED Driver + +SPI Drivers +----------- +There are several devices which connect to serial peripheral interfaces +supported by the BSP. + +- M25P40 flash +- FM25L256 fram +- memory devices +- SD card + +Legacy Drivers +-------------- + +The BSP source code provides legacy drivers for storage and network +devices. +The usage of legacy drivers is discouraged and description of such use +is out of the scope of this documentation. Interested users should +consult BSP source code directly but use legacy driver only when it is +not possible to use similar driver provided by `libbsd`. + +Storage Drivers +^^^^^^^^^^^^^^^ +- IDE/ATA +- AM26LV160/M29W160D flash + +Network Drivers +^^^^^^^^^^^^^^^ +- 3Com 3c509 +- 3Com 3c90x (Etherlink XL family) +- Novell NE2000 +- Western Digital WD8003 +- Intel 82586 +- Intel EtherExpress PRO/100 +- Cirrus Logic CS8900 +- DEC/Intel 21140 +- SMC 91111 +- Opencores Ethernet Controller +- National Semiconductor SONIC DP83932 diff --git a/user/bsps/bsps-lm32.rst b/user/bsps/bsps-lm32.rst index 2db5b12..98ffb91 100644 --- a/user/bsps/bsps-lm32.rst +++ b/user/bsps/bsps-lm32.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG lm32 (LatticeMicro32) ********************* diff --git a/user/bsps/bsps-m68k.rst b/user/bsps/bsps-m68k.rst index 60882fb..a820d96 100644 --- a/user/bsps/bsps-m68k.rst +++ b/user/bsps/bsps-m68k.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG m68k (Motorola 68000 / ColdFire) ******************************** @@ -53,7 +53,19 @@ TODO. mcf5329 ======= -TODO. +Overview +-------- + +This BSP is heavily based on the MCF5235 BSP. The MCF5329EVB is a Motorola +evaluation board (Zoom) with a LogicPD MCF5329-10 SODIMM-144 card. The +development kit features the MCF5329 based Fire Engine, as well as a plug-in +system-on-module containing 32 MB of DDR-SDRAM. The board also includes 2 MB of +boot flash, 16 MB of NAND flash, a core frequency of 240MHz, an onboard 800x600 +LCD controller, FEC, USB, uarts, CAN bus, QSPI, I2C, and 10/100 Ethernet. + +You can find the link to MCF5329 Reference Manual below: + +* `MCF5329 Reference Manual <https://www.nxp.com/docs/en/reference-manual/MCF5329RM.pdf>`_ mrm332 ====== @@ -73,7 +85,181 @@ TODO. mvme162 ======= -TODO. +Overview +-------- + +The MVME162 family provides OEMs and solution developers an ideal platform for +embedded monitoring and control apllications it allows an OEM to minimize +engineering expenses while integrating value-added hardware and software +applications onto an off-the-shelf product. In order to provide the wide range +of solutions, the MVME162 allows a variety of MPU, memory, and interface +options such as floating-point, Ethernet, SCSI, and VME. The result is a +variation of the MVME162 which most closely fits the application requirement. + +There are a large number of model variations on this board. This was the first +user submitted BSP and continues to be a fairly popular simply because at one +point it was the highest selling VMEBus board of all time. + +Board Setup +----------- + +We will setup the RTEMS Lab Board initally to proceed further for the setup +of TFTP transfer. + +The env settings are: + +.. code-block:: none + + MPU Clock Speed =25Mhz + 162-Bug>env + Bug or System environment [B/S] = B? + Field Service Menu Enable [Y/N] = N? + Remote Start Method Switch [G/M/B/N] = B? + Probe System for Supported I/O Controllers [Y/N] = Y? + Negate VMEbus SYSFAIL* Always [Y/N] = N? + Local SCSI Bus Reset on Debugger Startup [Y/N] = N? + Local SCSI Bus Negotiations Type [A/S/N] = A? + Industry Pack Reset on Debugger Startup [Y/N] = Y? + Ignore CFGA Block on a Hard Disk Boot [Y/N] = Y? + Auto Boot Enable [Y/N] = N? + Auto Boot at power-up only [Y/N] = Y? + Auto Boot Controller LUN = 00? + Auto Boot Device LUN = 00? + Auto Boot Abort Delay = 15? + Auto Boot Default String [NULL for a empty string] = ? + ROM Boot Enable [Y/N] = N? + ROM Boot at power-up only [Y/N] = Y? + ROM Boot Enable search of VMEbus [Y/N] = N? + ROM Boot Abort Delay = 0? + ROM Boot Direct Starting Address = FF800000? + ROM Boot Direct Ending Address = FFDFFFFC? + Network Auto Boot Enable [Y/N] = N? + Network Auto Boot at power-up only [Y/N] = Y? + Network Auto Boot Controller LUN = 00? + Network Auto Boot Device LUN = 00? + Network Auto Boot Abort Delay = 5? + Network Auto Boot Configuration Parameters Pointer (NVRAM) = FFE0FF00? + Memory Search Starting Address = 00000000? + Memory Search Ending Address = 01000000? + Memory Search Increment Size = 00010000? + Memory Search Delay Enable [Y/N] = N? + Memory Search Delay Address = FFFFD20F? + Memory Size Enable [Y/N] = Y? + Memory Size Starting Address = 00000000? + Memory Size Ending Address = 01000000? + Base Address of Dynamic Memory = 00000000? + Size of Parity Memory = 00000000? + Size of ECC Memory Board #0 = 01000000? + Size of ECC Memory Board #1 = 00000000? + Base Address of Static Memory = FFE00000? + Size of Static Memory = 00020000? + Slave Enable #1 [Y/N] = Y? + Slave Starting Address #1 = 00000000? + Slave Ending Address #1 = 00FFFFFF? + Slave Address Translation Address #1 = 00000000? + Slave Address Translation Select #1 = 00000000? + Slave Control #1 = 03FF? + Slave Enable #2 [Y/N] = N? + Slave Starting Address #2 = 00000000? + Slave Ending Address #2 = 00000000? + Slave Address Translation Address #2 = 00000000? + Slave Address Translation Select #2 = 00000000? + Slave Control #2 = 0000? + Master Enable #1 [Y/N] = Y? + Master Starting Address #1 = 01000000? + Master Ending Address #1 = EFFFFFFF? + Master Control #1 = 0D? + Master Enable #2 [Y/N] = N? + Master Starting Address #2 = 00000000? + Master Ending Address #2 = 00000000? + Master Control #2 = 00? + Master Enable #3 [Y/N] = N? + Master Starting Address #3 = 00000000? + Master Ending Address #3 = 00000000? + Master Control #3 = 00? + Master Enable #4 [Y/N] = N? + Master Starting Address #4 = 00000000? + Master Ending Address #4 = 00000000? + Master Address Translation Address #4 = 00000000? + Master Address Translation Select #4 = 00000000? + Master Control #4 = 00? + Short I/O (VMEbus A16) Enable [Y/N] = Y? + Short I/O (VMEbus A16) Control = 01? + F-Page (VMEbus A24) Enable [Y/N] = Y? + F-Page (VMEbus A24) Control = 02? + ROM Access Time Code = 03? + FLASH Access Time Code = 02? + MCC Vector Base = 05? + VMEC2 Vector Base #1 = 06? + VMEC2 Vector Base #2 = 07? + VMEC2 GCSR Group Base Address = D2? + VMEC2 GCSR Board Base Address = 00? + VMEbus Global Time Out Code = 01? + Local Bus Time Out Code = 02? + VMEbus Access Time Out Code = 02? + IP A Base Address = 00000000? + IP B Base Address = 00000000? + IP C Base Address = 00000000? + IP D Base Address = 00000000? + IP D/C/B/A Memory Size = 00000000? + IP D/C/B/A General Control = 00000000? + IP D/C/B/A Interrupt 0 Control = 00000000? + IP D/C/B/A Interrupt 1 Control = 00000000? + +To setup the Server/Client IP Addresses for the TFTP Transfer, we will use the +NIOT command. NIOT (Network I/O Teach) is a 162-Bug's debugger command commonly +used to setup the Server/Client IP Addresses for the TFTP Transfer. + +The NIOT command goes something like this: + +.. code-block:: none + + 162-Bug>niot + Controller LUN =00? + Device LUN =00? + Node Control Memory Address =FFE10000? + Client IP Address =192.168.1.245? + Server IP Address =192.168.1.92? + Subnet IP Address Mask =255.255.255.0? + Broadcast IP Address =192.168.1.255? + Gateway IP Address =0.0.0.0? + Boot File Name ("NULL" for None) =/mvme162.img? + Argument File Name ("NULL" for None) =? + Boot File Load Address =00020000? + Boot File Execution Address =00020000? + Boot File Execution Delay =00000000? + Boot File Length =00000000? + Boot File Byte Offset =00000000? + BOOTP/RARP Request Retry =00? + TFTP/ARP Request Retry =00? + Trace Character Buffer Address =00000000? + BOOTP/RARP Request Control: Always/When-Needed (A/W)=A? + BOOTP/RARP Reply Update Control: Yes/No (Y/N) =Y? + +Downloading and Executing +-------------------------- +Download from the TFTP server using the 162-Bug's "NBO" +(Network Boot Operating System) command: + +.. code-block:: none + + 162-Bug>nbo + Network Booting from: VME162, Controller 0, Device 0 + Loading: /mvme162.img + + Client IP Address = 192.168.1.245 + Server IP Address = 192.168.1.92 + Gateway IP Address = 0.0.0.0 + Subnet IP Address Mask = 255.255.255.0 + Boot File Name = /mvme162.img + Argument File Name = + + Network Boot File load in progress... To abort hit <BREAK> + + Bytes Received =&356528, Bytes Loaded =&356528 + Bytes/Second =&89132, Elapsed Time =4 Second(s) + +The program will automatically run when download is complete. mvme167 ======= diff --git a/user/bsps/bsps-microblaze.rst b/user/bsps/bsps-microblaze.rst index dbb574f..6fe4891 100644 --- a/user/bsps/bsps-microblaze.rst +++ b/user/bsps/bsps-microblaze.rst @@ -1,8 +1,182 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG +.. Copyright (C) 2022 On-Line Applications Research Corporation (OAR) -microblaze (Microblaze) +microblaze (MicroBlaze) *********************** -There are no Microblaze BSPs yet. +KCU105 QEMU +=========== + +The basic hardware initialization is performed by the BSP. This BSP supports the +QEMU emulated Xilinx AXI Interrupt Controller v4.1. + +Boot via ELF +------------ + +The executable image is booted by QEMU in ELF format. + +Clock Driver +------------ + +The clock driver supports the QEMU emulated Xilinx AXI Timer v2.0. It is +implemented as a simple downcounter. If device tree support is enabled in the +build configuration, the clock driver will use the node that is compatible with +`xlnx,xps-timer-1.00.a` from the device tree to configure the clock. The +following device tree node properties are used to configure the clock driver: +``reg``, ``clock-frequency``, and ``interrupts``. + +Console Driver +-------------- + +The console driver supports the QEMU emulated Xilinx AXI UART Lite v2.0. It is +initialized to a baud rate of 115200. If device tree support is enabled in the +build configuration, the console driver will use the node that is compatible +with `xlnx,xps-uartlite-1.00.a` from the device tree to configure the console. +The following device tree node properties are used to configure the console +driver: ``reg``, ``status``, ``port-number``, and ``interrupts``. + +Network Driver +-------------- + +Support for networking is provided by the libbsd library. Network interface +configuration is extracted from the device tree binary which, by default, is +in `<bsp/microblaze-dtb.h> <https://git.rtems.org/rtems/tree/bsps/microblaze/microblaze_fpga/include/bsp/microblaze-dtb.h>`_. +The device tree source for the default device tree is at `dts/system.dts <https://git.rtems.org/rtems/tree/bsps/microblaze/microblaze_fpga/dts/system.dts>`_. + +To replace the default device tree with your own, assuming ``my_device_tree.dts`` +is the name of your device tree source file, first you must convert your device +tree to .dtb format. + +.. code-block:: none + + $ dtc -I dts -O dtb my_device_tree.dts > my_device_tree.dtb + +The device tree blob, ``my_device_tree.dtb``, can now be converted to a C file. +The name ``system_dtb`` is significant as it is the name expected by the BSP. + +.. code-block:: none + + $ rtems-bin2c -C -A 8 -N system_dtb my_device_tree.dtb my_dtb + +The ``BSP_MICROBLAZE_FPGA_DTB_HEADER_PATH`` BSP configuration option can then be +set to the path of the resulting source file, ``my_dtb.c``, in the waf INI file +to include it in the BSP build. + +.. code-block:: none + + BSP_MICROBLAZE_FPGA_DTB_HEADER_PATH = /path/to/my_dtb.c + + +QSPI NOR JFFS2 Driver +--------------------- + +The QSPI NOR JFFS2 driver supports the QEMU emulated n25q512a11 QSPI NOR flash +device. It is initialized to a page size of 256 bytes and a sector size of 64 +KiB. If device tree support is enabled in the build configuration, the QSPI NOR +JFFS2 driver will use the node that is compatible with `xlnx,xps-spi-2.00.a` +from the device tree to configure the QSPI NOR JFFS2 driver. The following +device tree node properties are used to configure the QSPI NOR JFFS2 driver: +``reg`` and ``interrupts``. + + +Running Executables +------------------- + +A ``.dtb`` (device tree blob) file should be provided to QEMU via the ``-hw-dtb`` +option. In the example command below, the device tree blob comes from the Xilinx +Petalinux KCU105 MicroBlaze BSP (https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools.html). + +Executables generated by this BSP can be run using the following command: + +.. code-block:: none + + $ qemu-system-microblazeel -no-reboot -nographic -M microblaze-fdt-plnx -m 256 \ + -serial mon:stdio -display none -hw-dtb system.dtb -kernel example.exe + +Debugging with QEMU +------------------- + +To debug an application, add the option ``-s`` to make QEMU listen for GDB +connections on port 1234. Add the ``-S`` option to also stop execution until +a connection is made. + +For example, to debug the hello sample and break at ``Init``, first start QEMU. + +.. code-block:: none + + $ qemu-system-microblazeel -no-reboot -nographic -M microblaze-fdt-plnx -m 256 \ + -serial mon:stdio -display none -hw-dtb system.dtb -kernel \ + build/microblaze/kcu105_qemu/testsuites/samples/hello.exe -s -S + +Then start GDB and connect to QEMU. + +.. code-block:: none + + $ microblaze-rtems@rtems-ver-major@-gdb build/microblaze/kcu105_qemu/testsuites/samples/hello.exe + (gdb) target remote localhost:1234 + (gdb) break Init + (gdb) continue + +KCU105 +====== + +The basic hardware initialization is performed by the BSP. This BSP supports the +Xilinx AXI Interrupt Controller v4.1. + +This BSP was tested using the Xilinx Kintex UltraScale FPGA KCU105 board +configured with the default Petalinux KCU105 MicroBlaze BSP. The defaults may +need to be adjusted using BSP configuration options to match the memory layout +and configuration of your board. + +Clock Driver +------------ + +The clock driver supports the Xilinx AXI Timer v2.0. It is implemented as a +simple downcounter. If device tree support is enabled in the +build configuration, the clock driver will use the node that is compatible with +`xlnx,xps-timer-1.00.a` from the device tree to configure the clock. The +following device tree node properties are used to configure the clock driver: +``reg``, ``clock-frequency``, and ``interrupts``. + +Console Driver +-------------- + +The console driver supports the Xilinx AXI UART Lite v2.0. It is initialized to +a baud rate of 115200. If device tree support is enabled in the build +configuration, the console driver will use the node that is compatible with +`xlnx,xps-uartlite-1.00.a` from the device tree to configure the console. The +following device tree node properties are used to configure the console driver: +``reg``, ``status``, ``port-number``, and ``interrupts``. + +Debugging +--------- + +The following debugging procedure was used for debugging RTEMS applications +running on the Xilinx KCU105 board using GDB. + +First send an FPGA bitstream to the board using OpenOCD. + +.. code-block:: none + + $ openocd -f board/kcu105.cfg -c "init; pld load 0 system.bit; exit" + +After the board has been programmed, start the Vivado ``hw_server`` application +to serve as the debug server. Leave it running in the background for the rest of +the process. + +.. code-block:: none + + $ tools/Xilinx/Vivado/2020.2/bin/hw_server + +With the debug server running, connect to the debug server with GDB, load the +application, and debug as usual. By default the GDB server listens on port 3002. + +.. code-block:: none + + $ microblaze-rtems@rtems-ver-major@-gdb example.exe + (gdb) target extended-remote localhost:3002 + (gdb) load + (gdb) break Init + (gdb) continue diff --git a/user/bsps/bsps-mips.rst b/user/bsps/bsps-mips.rst index 9f83811..f90732a 100644 --- a/user/bsps/bsps-mips.rst +++ b/user/bsps/bsps-mips.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG mips (MIPS) *********** diff --git a/user/bsps/bsps-moxie.rst b/user/bsps/bsps-moxie.rst index eab88cc..8548777 100644 --- a/user/bsps/bsps-moxie.rst +++ b/user/bsps/bsps-moxie.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG moxie ***** diff --git a/user/bsps/bsps-nios2.rst b/user/bsps/bsps-nios2.rst index ad21dd3..5280025 100644 --- a/user/bsps/bsps-nios2.rst +++ b/user/bsps/bsps-nios2.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG nios2 (Nios II) *************** diff --git a/user/bsps/bsps-or1k.rst b/user/bsps/bsps-or1k.rst index 6295c23..e7d9a10 100644 --- a/user/bsps/bsps-or1k.rst +++ b/user/bsps/bsps-or1k.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG or1k (OpenRISC 1000) ******************** diff --git a/user/bsps/bsps-powerpc.rst b/user/bsps/bsps-powerpc.rst index 80edfae..6b63936 100644 --- a/user/bsps/bsps-powerpc.rst +++ b/user/bsps/bsps-powerpc.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG powerpc (PowerPC) ***************** @@ -36,10 +36,10 @@ image. Use the following commands: .. code-block:: none - powerpc-rtems5-objcopy -O binary -R .comment -S ticker.exe rtems + powerpc-rtems@rtems-ver-major@-objcopy -O binary -R .comment -S ticker.exe rtems gzip -9 -f rtems - powerpc-rtems5-ld -o ticker.boot bootloader.o --just-symbols=ticker.exe -b binary rtems.gz -T ppcboot.lds -no-warn-mismatch - powerpc-rtems5-objcopy -O binary ticker.boot ticker.bin + powerpc-rtems@rtems-ver-major@-ld -o ticker.boot bootloader.o --just-symbols=ticker.exe -b binary rtems.gz -T ppcboot.lds -no-warn-mismatch + powerpc-rtems@rtems-ver-major@-objcopy -O binary ticker.boot ticker.bin mpc55xxevb ========== @@ -107,7 +107,7 @@ image. Use the following commands: .. code-block:: none - powerpc-rtems5-objcopy -O binary app.exe app.bin + powerpc-rtems@rtems-ver-major@-objcopy -O binary app.exe app.bin gzip -9 -f -c app.bin > app.bin.gz mkimage -A ppc -O linux -T kernel -a 0x4000 -e 0x4000 -n RTEMS -d app.bin.gz app.img diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst index 0799ad6..263796e 100644 --- a/user/bsps/bsps-riscv.rst +++ b/user/bsps/bsps-riscv.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG riscv (RISC-V) ************** @@ -8,7 +8,8 @@ riscv (RISC-V) riscv ===== -This BSP offers 13 variants: +**Each variant in this first group corresponds to a GCC multilib option with +different RISC-V standard extensions.** * rv32i @@ -26,31 +27,36 @@ This BSP offers 13 variants: * rv64imac -* rv64imac_medany - * rv64imafd -* rv64imafd_medany - * rv64imafdc -* rv64imafdc_medany +Each variant reflects an ISA with ABI and code model choice. All rv64 BSPs have +medany code model by default, while rv32 BSPs are medlow. The reason is that +RV32 medlow can access the entire 32-bit address space, while RV64 medlow can +only access addresses below 0x80000000. With RV64 medany, it's possible to +perform accesses above 0x80000000. The BSP must be started in machine mode. + +The reference platforms for the rv* variants include the QEMU `virt` and +`spike` machines and the Spike RISC-V ISA simulator. + +**The BSP also provides the following variants for specific hardware targets:** -* frdme310arty +* frdme310arty - The reference platform for this variant is the Arty FPGA board + with the SiFive Freedom E310 reference design. -Each variant corresponds to a GCC multilib. A particular variant reflects an -ISA with ABI and code model choice. +* mpfs64imafdc - The reference platform for this variant is the Microchip + PolarFire SoC Icicle Kit. -The basic hardware initialization is not performed by the BSP. A boot loader -with device tree support must be used to start the BSP, e.g. BBL. The BSP must -be started im machine mode. +* kendrytek210 - The reference platform for this variant is the Kendryte K210 + SoC on the Sipeed MAiX BiT or Maixduino board. -The reference platform for this BSP is the Qemu `virt` machine. 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 @@ -67,31 +73,51 @@ The following options are available at the configure command line. ``BSP_FDT_BLOB_SIZE_MAX`` The maximum size of the device tree blob in bytes (default is 65536). +``BSP_DTB_IS_SUPPORTED`` + If defined to a non-zero value, then the device tree blob is embedded in + the BSP. + +``BSP_DTB_HEADER_PATH`` + The path to the header file containing the device tree blob. + ``BSP_CONSOLE_BAUD`` - The default baud for console driver devices (default 115200). + The default baud for console driver devices (default is 115200). ``RISCV_MAXIMUM_EXTERNAL_INTERRUPTS`` The maximum number of external interrupts supported by the BSP (default - 64). + is 64). ``RISCV_ENABLE_HTIF_SUPPORT`` - Enables the HTIF support if defined to a non-zero value, otherwise it is - disabled (disabled by default). + Enable the Host/Target Interface (HTIF) support (enabled by default). ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` - The maximum number of NS16550 devices supported by the console driver (2 - by default). + The maximum number of NS16550 devices supported by the console driver + (default is 2). + +``RISCV_ENABLE_SIFIVE_UART_SUPPORT`` + Enable the SiFive console UART (disabled by default). ``RISCV_RAM_REGION_BEGIN`` - The begin of the RAM region for linker command file (default is 0x70000000 - for 64-bit with -mcmodel=medlow and 0x80000000 for all other). + The begin of the RAM region for linker command file + (default is 0x80000000). ``RISCV_RAM_REGION_SIZE`` The size of the RAM region for linker command file (default 64MiB). ``RISCV_ENABLE_FRDME310ARTY_SUPPORT`` Enables support sifive Freedom E310 Arty board if defined to a non-zero - value,otherwise it is disabled (disabled by default) + value,otherwise it is disabled (disabled by default). + +``RISCV_ENABLE_MPFS_SUPPORT`` + Enables support Microchip PolarFire SoC if defined to a non-zero + value, otherwise it is disabled (disabled by default). + +``RISCV_ENABLE_KENDRYTE_K210_SUPPORT`` + Enables support for the Kendtryte K210 SoC if defined to a non-zero + value, otherwise it is disabled (disabled by default). + +``RISCV_BOOT_HARTID`` + The boot hartid (processor number) of risc-v cpu by default 0. Interrupt Controller -------------------- @@ -109,20 +135,341 @@ The clock driver uses the CLINT timer. Console Driver -------------- -The console driver supports devices compatible to +The console driver supports devices compatible to: * "ucb,htif0" (depending on the ``RISCV_ENABLE_HTIF_SUPPORT`` BSP option), -* "ns16550a" (see ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` BSP option), and +* "ns16550a" (see ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` BSP option), -* "ns16750" (see ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` BSP option). +* "ns16750" (see ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` BSP option), and -* "sifive,uart0" (see ``RISCV_ENABLE_FRDME310ARTY_SUPPORT`` BSP option). +* "sifive,uart0" (see ``RISCV_ENABLE_SIFIVE_UART_SUPPORT`` BSP option). They are initialized according to the device tree. The console driver does not configure the pins or peripheral clocks. The console device is selected according to the device tree "/chosen/stdout-path" property value. +QEMU +---- + +All of the BSP variants that start with rv can be run on QEMU's virt +and spike machines. For instance, to run the ``rv64imafdc`` BSP with the +following "config.ini" file. + +.. code-block:: none + + [riscv/rv64imafdc] + +Run the following QEMU command. + +.. code-block:: shell + + $ qemu-system-riscv64 -M virt -nographic -bios $RTEMS_EXE + $ qemu-system-riscv64 -M spike -nographic -bios $RTEMS_EXE + +Spike +---- + +All of the BSP variants that start with rv can be run on Spike. For instance, +to run the ``rv64imafdc`` BSP with the following "config.ini" file. + +.. code-block:: none + + [riscv/rv64imafdc] + +Run the following Spike command. + +.. code-block:: shell + + $ spike --isa=rv64imafdc $RTEMS_EXE + +Unlike QEMU, Spike supports enabling/disabling a subset of the imafdc +extensions and has support for further RISC-V extensions as well. A fault will +be triggered if an executable built with rv64imafdc RISC-V's -march option run +on Spike with --isa=rv64i option. If no --isa option is specified, the default +is rv64imafdc. + +Microchip PolarFire SoC +----------------------- + +The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-bit RISC-V E51 +monitor core SoC from the Microchip. + +The ``mpfs64imafdc`` BSP variant supports the U54 cores but not the E51 because +the E51 monitor core is reserved for the first stage bootloader (Hart Software +Services). In order to boot from the first U54 core, ``RISCV_BOOT_HARTID`` is +set to 1 by default. + +The device tree blob is embedded in the ``mpfs64imafdc`` BSP variant by default +with the ``BSP_DTB_IS_SUPPORTED`` enabled and the DTB header path +``BSP_DTB_HEADER_PATH`` is set to bsp/mpfs-dtb.h. + +**SMP test procedure for the Microchip PolarFire Icicle Kit:** + +The "config.ini" file. + +.. code-block:: none + + [riscv/mpfs64imafdc] + BUILD_TESTS = True + RTEMS_POSIX_API=True + RTEMS_SMP = True + BSP_START_COPY_FDT_FROM_U_BOOT=False + BSP_VERBOSE_FATAL_EXTENSION = False + +Build RTEMS. + +.. code-block:: shell + + $ ./waf configure --prefix=$HOME/rtems-start/rtems/@rtems-ver-major@ + $ ./waf + +Convert .exe to .elf file. + +.. code-block:: shell + + $ riscv-rtems@rtems-ver-major@-objcopy build/riscv/mpfs64imafdc/testsuites/smptests/smp01.exe build/riscv/mpfs64imafdc/testsuites/smptests/smp01.elf + +Generate a payload for the `smp01.elf` using the `hss-payload-generator <https://github.com/polarfire-soc/hart-software-services/blob/master/tools/hss-payload-generator>`_. + +* Copy `smp01.elf` file to the HSS/tools/hss-payload-generator/test directory. + +* Go to hss-payload-generator source directory. + +.. code-block:: shell + + $ cd hart-software-services/tools/hss-payload-generator + +* Edit test/uboot.yaml file for the hart entry points and correct name of the + binary file. + +.. code-block:: none + + set-name: 'PolarFire-SoC-HSS::RTEMS' + hart-entry-points: {u54_1: '0x1000000000', u54_2: '0x1000000000', u54_3: '0x1000000000', u54_4: '0x1000000000'} + payloads: + test/smp01.elf: {exec-addr: '0x1000000000', owner-hart: u54_1, secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: prv_m, skip-opensbi: true} + +* Generate payload + +.. code-block:: shell + + $ ./hss-payload-generator -c test/uboot.yaml payload.bin + +Once the payload binary is generated, it should be copied to the eMMC/SD. + +`FPGA design with HSS programming file <https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md>`_. + +Program the eMMC/SD with the payload binary. + +* Power Cycle the Microchip PolarFire Icicle Kit and stop at the HSS. + +* type "mmc" and then "usbdmsc" on the HSS terminal(UART0). + +* Load the payload.bin from the Host PC. + +.. code-block:: shell + + $ sudo dd if=payload.bin of=/dev/sdb bs=512 + +Reset the Microchip PolarFire SoC Icicle Kit. + +Serial terminal UART1 displays the SMP example messages + +.. code-block:: none + + *** BEGIN OF TEST SMP 1 *** + *** TEST VERSION: 6.0.0.ef33f861e16de9bf4190a36e4d18062c7300986c + *** TEST STATE: EXPECTED_PASS + *** TEST BUILD: RTEMS_POSIX_API RTEMS_SMP + *** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB 3cb78b0b815ba05d17f5c6 + 5865d246a8333aa087, Newlib ea99f21) + + CPU 3 start task TA0 + CPU 2 running Task TA0 + CPU 3 start task TA1 + CPU 1 running Task TA1 + CPU 3 start task TA2 + CPU 0 running Task TA2 + + *** END OF TEST SMP 1 *** + +Kendryte K210 +------------- + +The Kendryte K210 SoC is a dual core 64-bit RISC-V SoC with an AI NPU, built in +SRAM, and a variety of peripherals. Currently just the console UART, interrupt +controller, and timer are supported. + +The device tree blob is embedded in the ``kendrytek210`` BSP variant by +default. When the kendrytek210 BSP variant is selected, +``BSP_DTB_IS_SUPPORTED`` enabled and the DTB header path +``BSP_DTB_HEADER_PATH`` is set to ``bsp/kendryte-k210-dtb.h``. + +The ``kendrytek210`` BSP variant has been tested on the following simulator and +boards: + +* Renode.io simulator using the Kendrtye k210 model +* Sipeed MAiX BiT board +* Sipeed Maixduino board +* Sipeed MAiX Dock board + +**Building the Kendryte K210 BSP** + +Configuration file ``config.ini``: + +.. code-block:: none + + [riscv/kendrytek210] + RTEMS_SMP = True + +Build RTEMS: + +.. code-block:: shell + + $ ./waf configure --prefix=$HOME/rtems-start/rtems/@rtems-ver-major@ + $ ./waf + +**Flash an executable to a supported K210 board** + +Binary images can be flashed to the Sipeed boards through the USB port using +the ``kflash.py`` utility available from the python pip utility. + +.. code-block:: shell + + $ riscv-rtems@rtems-ver-major@-objcopy -Obinary ticker.exe ticker.bin + $ kflash.py --uart /dev/ttyUSB0 ticker.bin + +After the image is flashed, the RTEMS image will automatically boot. It will +also run when the board is reset or powered through the USB cable. The USB port +provides the power and console UART. Plug the USB cable into a host PC and +bring up a terminal emulator at 115200 baud, 8 data bits, 1 stop bit, no +parity, and no flow control. On Linux the UART device is often +``/dev/ttyUSB0``. + +**Run a RTEMS application on the Renode.io simulator** + +RTEMS executables compiled with the kendrytek210 BSP can run on the renode.io +simulator using the built-in K210 model. The simulator currently supports the +console UART, interrupt controller, and timer. + +To install renode.io please refer to the `installation instructions <https://github.com/renode/renode#installation>`_. +Once installed, save the following file as `k210_rtems.resc`. + +.. code-block:: shell + + using sysbus + + $bin?=@ticker.exe + + mach create "K210" + + machine LoadPlatformDescription @platforms/cpus/kendryte_k210.repl + + showAnalyzer uart + + sysbus Tag <0x50440000 0x10000> "SYSCTL" + sysbus Tag <0x50440018 0x4> "pll_lock" 0xFFFFFFFF + sysbus Tag <0x5044000C 0x4> "pll1" + sysbus Tag <0x50440008 0x4> "pll0" + sysbus Tag <0x50440020 0x4> "clk_sel0" + sysbus Tag <0x50440028 0x4> "clk_en_cent" + sysbus Tag <0x5044002c 0x4> "clk_en_peri" + + macro reset + """ + sysbus LoadELF $bin + """ + runMacro $reset + +After saving the above file in in the same directory as your RTEMS ELF images, +start renode and load the `k210_rtems.resc` script to start the emulation. + +.. code-block:: shell + + (monitor) s @k210_rtems.resc + +You should see a renode UART window and the RTEMS ticker example output. If you +want to run a different RTEMS image, you can edit the file or enter the +following on the renode console. + +.. code-block:: shell + + (monitor) $bin=@smp08.exe + (monitor) s @k210_rtems.resc + +The above example will run the SMP08 example instead of ticker. + +**Generating the Device Tree Header** + +The kendrytek210 BSP uses a built in device tree blob. If additional peripheral +support is added to the BSP, the device tree may need to be updated. After +editing the device tree source, compile it to a device tree blob with the +following command: + +.. code-block:: shell + + $ dtc -O dtb -b 0 -o kendryte-k210.dtb kendryte-k210.dts + +The dtb file can then be converted to a C array using the rtems-bin2c tool. +The data for the device tree binary can then replace the existing device tree +binary data in the ``kendryte-k210-dtb.h`` header file. + +noel +==== + +This BSP supports the `NOEL-V <https://gaisler.com/noel-v>`_ systems from +Cobham Gaisler. The NOEL-V is a synthesizable VHDL model of a processor that +implements the RISC-V architecture. It is part of the open source `GRLIB +<https://gaisler.com/grlib>`_ IP Library. The following BSP variants correspond +to common NOEL-V configurations: + +* noel32im + +* noel32imafd + +* noel64imac + +* noel64imafd + +* noel64imafdc + +The start of the memory is set to 0x0 to match a standard NOEL-V system, but +can be changed using the ``RISCV_RAM_REGION_BEGIN`` configuration option. The +size of the memory is taken from the information available in the device tree. + +Reference Designs +----------------- + +The BSP has been tested with NOEL-V reference designs for `Digilent Arty A7 +<https://gaisler.com/noel-artya7>`_, `Microchip PolarFire Splash Kit +<https://gaisler.com/noel-pf>`_, and `Xilinx KCU105 +<https://gaisler.com/noel-xcku>`_. See the accompanying quickstart guide for +each reference design to determine which BSP configuration to use. + +Build Configuration Options +--------------------------- + +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_CONSOLE_USE_INTERRUPTS`` + Use the Termios interrupt mode in the console driver (true by default). + +``BSP_FDT_BLOB_SIZE_MAX`` + The maximum size of the device tree blob in bytes (262144 by default). + +``RISCV_CONSOLE_MAX_APBUART_DEVICES`` + The maximum number of APBUART devices supported by the console driver + (2 by default). + +``RISCV_RAM_REGION_BEGIN`` + The begin of the RAM region for linker command file (0x0 by default). + +``RISCV_MAXIMUM_EXTERNAL_INTERRUPTS`` + The maximum number of external interrupts supported by the BSP (64 by + default). + griscv ====== diff --git a/user/bsps/bsps-sh.rst b/user/bsps/bsps-sh.rst index b147251..8c245c4 100644 --- a/user/bsps/bsps-sh.rst +++ b/user/bsps/bsps-sh.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG sh (SuperH) *********** diff --git a/user/bsps/bsps-sparc.rst b/user/bsps/bsps-sparc.rst index d0316a9..325c7fa 100644 --- a/user/bsps/bsps-sparc.rst +++ b/user/bsps/bsps-sparc.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG .. Copyright (C) 2020 Chris Johns sparc (SPARC / LEON) @@ -20,11 +20,81 @@ TODO. leon2 ===== -TODO. +This BSP supports LEON2 systems, in particular the `Microchip AT697F +<https://www.microchip.com/en-us/product/AT697F>`_. The following +default build configurations are provided: + +* leon2 - A generic LEON2 system with memory at 0x4000000. + +* at697f - For the AT697F. Built with ``-mcpu=leon -mfix-at697f``. + +The BSP contains UART, timer, and interrupt controller drivers. +Drivers for PCI are available through the :ref:`driver manager <BSP_sparc_leon3_drv_mgr>`. .. _BSP_sparc_leon3: leon3 ===== -TODO. +This BSP supports the LEON3/4/5 systems from Cobham Gaisler. +The following default build configurations are provided: + +* leon3 - A generic `LEON3/4/5 <https://www.gaisler.com/leon5>`_ system with memory at 0x4000000. + +* ut700 - For the `UT700 <https://caes.com/product/ut700>`_. Built with ``-mcpu=leon3 -mfix-ut700``. + +* ut699 - For the `UT699 <https://caes.com/product/ut699>`_. Built with ``-mcpu=leon -mfix-ut699``. + +* gr712rc - For the `GR712RC <https://www.gaisler.com/gr712rc>`_. Built with ``-mcpu=leon3 -mfix-gr712rc``. + +* gr740 - For the `GR740 <https://www.gaisler.com/gr740>`_. Memory located at address 0x0. + +The BSP contains UART, timer, and interrupt controller drivers. Drivers for additional +peripherals are available through the driver manager. + +.. _BSP_sparc_leon3_drv_mgr: + +Driver Manager +-------------- + +The leon3 BSP includes an optional driver manager that handles drivers and +devices on the AMBA and PCI Plug & Play buses. The driver manager can either +be initialized manually by the user, or started automatically on startup by +setting the ``RTEMS_DRVMGR_STARTUP`` option. It can be configured to +automatically instantiate a driver for each hardware device found. + +Drivers for the following devices are provided and handled via the driver manager: + +* SpaceWire (GRSPW, GRSPW2, GRSPW2_DMA) +* SpaceWire Router (GRSPWROUTER) +* SpaceWire Time Distribution Protocol (SPWTDP) +* CAN - non-DMA (OCCAN) and DMA (GRCAN, GRCANFD) +- GPIO (GRGPIO) +- L2 Cache (L2CACHE) +- IOMMU (GRIOMMU) +- ADC/DAC (GRADCDAC) +- Timers (GPTIMER, GRTIMER) +- 1553 BC, RT and BM support (GR1553B) +- I2C Master (I2CMST) +- PCI (GRPCI2, GRPCI, PCIF) +- Memory Controller (MCTRL) +- Memory Scrubber (MEMSCRUB) +- Pulse Width Modulation Generator (GRPWM) +- CCSDS/ECSS Telemetry Encoder/Decoder (GRTM/GRTC) +- CSDS Time Manager (GRCTM) +- Ethernet (GRETH 10/100/1000) (requires network stack) +- Performance counters (L4STAT) +- Serial Peripheral Interface (AHBSTAT) +- AHB Status (AHBSTAT) + +Build Configuration Options +--------------------------- + +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. + +``CONSOLE_USE_INTERRUPTS`` + Use the Termios interrupt mode in the console driver (false by default). + +``RTEMS_DRVMGR_STARTUP`` + Enable the Driver Manager at startup (false by default). diff --git a/user/bsps/bsps-sparc64.rst b/user/bsps/bsps-sparc64.rst index e7be4ea..7b598b7 100644 --- a/user/bsps/bsps-sparc64.rst +++ b/user/bsps/bsps-sparc64.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG sparc64 (SPARC V9) ****************** diff --git a/user/bsps/bsps-v850.rst b/user/bsps/bsps-v850.rst index 39973db..220ccc0 100644 --- a/user/bsps/bsps-v850.rst +++ b/user/bsps/bsps-v850.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG v850 (V850) *********** diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst index eefffab..38d84e4 100644 --- a/user/bsps/bsps-x86_64.rst +++ b/user/bsps/bsps-x86_64.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 .. Copyright (C) 2018 Amaan Cheval <amaan.cheval@gmail.com> -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG x86_64 ****** @@ -20,7 +20,7 @@ in the RTEMS testsuite. Build Configuration Options --------------------------- -There are no options available to ``configure`` at build time, at the moment. +There are no BSP configuration options available at build time. Testing with QEMU ----------------- diff --git a/user/bsps/index.rst b/user/bsps/index.rst index 0c3b2f6..5c1b3b7 100644 --- a/user/bsps/index.rst +++ b/user/bsps/index.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 -.. Copyright (C) 2018 embedded brains GmbH +.. Copyright (C) 2018 embedded brains GmbH & Co. KG .. _BSPs: @@ -27,7 +27,6 @@ You can see the current BSP list in the RTEMS sources by asking RTEMS with: bsps-aarch64 bsps-arm bsps-bfin - bsps-epiphany bsps-i386 bsps-lm32 bsps-m68k |