[PATCH rtems-docs 1/2] user/bsps: Add imxrt
Christian Mauderer
christian.mauderer at embedded-brains.de
Wed Nov 18 07:52:27 UTC 2020
Am 17.11.20 um 18:41 schrieb Gedare Bloom:
> On Tue, Nov 17, 2020 at 4:09 AM Christian Mauderer
> <christian.mauderer at embedded-brains.de> wrote:
>>
>> Update #4180
>> ---
>> user/bsps/arm/imxrt.rst | 174 ++++++++++++++++++++++++++++++++++++++++
>> user/bsps/bsps-arm.rst | 1 +
>> 2 files changed, 175 insertions(+)
>> create mode 100644 user/bsps/arm/imxrt.rst
>>
>> diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
>> new file mode 100644
>> index 0000000..41c6bff
>> --- /dev/null
>> +++ b/user/bsps/arm/imxrt.rst
>> @@ -0,0 +1,174 @@
>> +.. SPDX-License-Identifier: CC-BY-SA-4.0
>> +
>> +.. Copyright (C) 2020 embedded brains GmbH
>> +.. Copyright (C) 2020 Christian Mauderer
>> +
>> +imxrt (NXP i.MXRT)
>> +==================
>> +
>> +This BSP offers only one variant, the `imxrt1052`. This variant supports the
>> +i.MXRT 1052 processor on a IMXRT1050-EVKB (tested with rev A1). You can also
>> +configure it to work with custom boards.
>> +
>> +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::
> one colon: I think?
>
That's the start for the literal block below. Restructured Text allows
three syntax variants for that. From Wikipedia:
::
some literal text
This may also be used inline at the end of a paragraph, like so::
some more literal text
.. code:: python
print("A literal block directive explicitly marked as python code")
>> +
>> + ./waf bsp_defaults --rtems-bsps=arm/imxrt1052 > config.ini
>> +
>> +Boot Process
>> +------------
>> +
>> +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-rtems6-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.
>> +
>> +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 then the IMXRT1050-EVKB, they have to be adapted. To do that
> s/then/than
Thanks.
> s/they have/it has
I thought that multiple structures for multiple headers have to be
adapted. Would it really be correct to use "it" for 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` for details about the contents.
>> +
>> +FDT
>> +---
>> +
>> +The BSP used a FDT based initialization. The FDT is linked into the application.
>> +You can find the default FDT used in the BSP in
>> +`bsps/arm/imxrt/dts/imxrt1050-evkb.dts`. To use your own FDT compile it and
>> +convert it into a C file with (replace `YOUR.dts` and simmilar with your FDT
>> +source names)::
>> +
>> + sh> export BSP_DIR="${RTEMS_SRC_DIR}/bsps/arm/imxrt/"
>> + sh> arm-rtems6-cpp -P -x assembler-with-cpp \
>> + -I "${BSP_DIR}/include/" \
>> + -include "YOUR.dts" /dev/null | \
>> + dtc -@ -O dtb -o "YOUR.dtb" -b 0 -p 1024
>> + sh> rtems-bin2c -C -N imxrt_dtb "YOUR.dtb" "YOUR.c"
>> +
>> +Make sure that your new c file is compiled and linked into the application.
>> +
>> +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.
>> +
>> +Limitations:
>> +
>> +* Only a basic SPI driver is implemented. This is mostly a driver limitation and
>> + not a hardware one.
>> +
>> +Network Interface Driver
>> +------------------------
>> +
>> +The network interface driver is provided by the `libbsd`. It is initialized
> We probably need a libbsd (or update of the networking) manual soon.
>
Yes, I agree. I'm just not sure how to start that.
Most likely someone has to start with some (good) structure that can be
extended step for step. I'm a bit uncertain how that structure could
look like.
Alternatively: Do you know whether there is a new Google Season of Docs
planned? Maybe we could try to get a technical writer who is officially
tasked to annoy all of us to give him input for that via that program.
>> +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.
>> +
>> +Caveats
>> +-------
>> +
>> +The clock configuration support is quite rudimentary. The same is true for
>> +SDRAM. It mostly relies on the DCD and on a static clock configuration that is
>> +taken from the NXP SDK example projects.
>> +
>> +The MPU settings are currently quite permissive. Some stronger rules might could
>> +improve the security.
> I'd prefer we avoid statements regarding security here. Just delete
> the last sentence.
OK.
>
>> +
>> +There is no power management support.
>> diff --git a/user/bsps/bsps-arm.rst b/user/bsps/bsps-arm.rst
>> index 295ed82..a63dd5f 100644
>> --- a/user/bsps/bsps-arm.rst
>> +++ b/user/bsps/bsps-arm.rst
>> @@ -14,6 +14,7 @@ arm (ARM)
>> .. include:: arm/edb7312.rst
>> .. include:: arm/gumstix.rst
>> .. include:: arm/imx.rst
>> +.. include:: arm/imxrt.rst
>> .. include:: arm/lm3s69xx.rst
>> .. include:: arm/lpc176x.rst
>> .. include:: arm/imx.rst
>> --
>> 2.26.2
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
--------------------------------------------
embedded brains GmbH
Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list