On Wed, Nov 18, 2020 at 12:52 AM Christian Mauderer
<christian.maude...@embedded-brains.de> wrote:
>
> Am 17.11.20 um 18:41 schrieb Gedare Bloom:
> > On Tue, Nov 17, 2020 at 4:09 AM Christian Mauderer
> > <christian.maude...@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")
>
thanks
> >> +
> >> + ./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?
>
I see. In this case, it would be more clear to say "those structures
have" since it is not entirely clear what "they" refers back to.
> >
> >> +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.
>
It starts with a ticket ;)
> 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.
>
Yes. We do have an existing networking manual, but I don't know its state.
> 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.
>
I'm not aware of another GSoD. We'll have to keep an eye out for it.
> >> +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@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> --------------------------------------------
> embedded brains GmbH
> Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
