Beginning work on BSP for i.MX RT 10xx (1052 specifically)

[Christian Mauderer]

On 09/02/2020 20:09, dufault at hda.com wrote:
> 
> 
>> On Feb 9, 2020, at 12:05 , Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>>>> I'm not sure if "variant" is the correct term.  I look forward to seeing what your approach is.
>>> Yes sorry. I didn't look up the established term. From what I can tell
>>> now, I don't think that there will be any conditional compiling
>>> necessary. That would mean that imx6ul and imx7 can use the same BSP.
>>> There are differences for the clocks but these are already covered by
>>> configure variables.
>>
>> I only had a brief look at the i.MX RT series:
>>
>> https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i.mx-rt-crossover-mcus:IMX-RT-SERIES
>>
>> They are Cortex-M based. I think for the RT series we need a new BSP family due to the different processor architecture (i.MX 6/7 is Cortex-A). In case device trees are available for these chips, then I would use them instead of hard coded values. Device driver code should be shared if possible. I don't want new copy and paste drivers.
> 
> Yes, they are Cortex-M and not Cortex-A.  My plan, before realizing EB was extending the "imx" driver, was to start in the "imx" tree to get started but probably move to an "imx-rt" BSP once I knew what could be shared and what couldn't.  I don't want new copy and paste drivers.

Please don't hold back on extending the imx BSP too. We should just try
to keep one another up to date. Like I said: I'll try to send all
patches to the list that are already ready as soon as possible. The only
difference is that it now will be more smaller patches instead of a
collection of bigger ones at the end. I'm sure we can manage to
coordinate that and it has the advantage that finally someone will
review patches ;-)

Note that beneath the imx BSP maybe the PowerPC BSPs could have drivers
too. NXP reused some of the Freescale PowerPC peripherals. At least in
the i.MX6, 7 and 8.

> 
> I haven't been using device trees, it's been background noise. I'll need to review.

What is the usual boot method on that platform? Is there an U-Boot that
loads a device tree? Would the RTEMS start right from the reset vector?

For the imx7 / imx6ul it's U-Boot or Barebox (U-Boot fork).

> 
> This brings me to a second important question regarding copy and paste: I installed the NXP MCUXpresso IDE to start reviewing the code available from NXP for the platform.
> 
> The plus:  The NXP code is BSD licensed.

Great.

> The minus: This IDE supports computer assisted copy and paste.

I agree: A big minus.

> - Any project I select that includes ethernet will install yet another copy of the ethernet driver C code.
> - Everything that's installed appears to be specific to the i.MX 1064, at least as far as the names are.  I decided to use the i.MX RT 1064 development board to get started.
> - I haven't located a download repository to bypass this nonsense and download the software in a reasonable layout.
> 
> I'd like to be able to pull down an NXP software repository for e.g. the i.MX RT family, import and label it, and then work from that, bugt I don't see that it's available.
> 
> It's hard for me to believe that this is how NXP internal SW development works.  This must be what's exported to be convenient for the pointers and clickers.
> 
> Does anyone know of a source of NXP code for recent platforms other than installing the IDE?

I know that for the i.MX8 there have been a lot of repositories on
Codeaurora. That includes something like the NXP fork of Linux and arm
trusted firmware for i.MX8. If you are lucky, the libraries you are
searching could be there too.

    https://source.codeaurora.org/

Otherwise: Maybe searching for some code snippets on github works?

Best regards

Christian

> 
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
> 
> This email is delivered through the public internet using protocols subject to interception and tampering.
>