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

[Sebastian Huber]

On 09/02/2020 17:36, Christian Mauderer wrote:
> On 09/02/2020 17:24, dufault at hda.com wrote:
>>
>>> On Feb 9, 2020, at 09:33 , Christian Mauderer <list at c-mauderer.de> wrote:
>>>
>>> Hello Peter,
>>>
>>> On 08/02/2020 21:16, Peter Dufault wrote:
>>>> I will begin working on a BSP for the i.MX RT 10xx family.  I require support for a 1052 but will be developing on a 1064 so those two variants will have some test coverage.
>>>>
>>>> I plan to start my work by making this a variant of the "imx" BSP.  That currently supports the "i.MX7D Applications Processor".
>>>>
>>>> I think that the network support provided by the "libbsd" "if_ffec" driver will work with the ENET interface on the i.MX RT.
>>>> I think that initial support will be a straight-forward collection of already working pieces.
>>>>
>>>> - If anyone has any warnings or "heads-up"s then let me know.
>>> Note that we (embedded brains) are currently working on the imx BSP too.
>>> Our target is imx6ul/ull support (for some Phytec modules). I'll try to
>>> clean up the patches that are already nearly ready and send them to the
>>> list as soon as possible. For the ones that are not ready yet I'll try
>>> to give early warnings. Would be good if you could do the same thing.
>> This sure is convenient.  Looking at the data sheet I see many of the same peripherals.
>> - The same 10/100 ENET module;
>> - The same ADC module, but apparently without the external trigger module on the imx6ul.
>> etc.  It looks like the imx6  uses the same "smart DMA" as the imx7, while the imx-rt uses the "enhanced DMA" which I think is what was on the MPC5554.  Again, I'm just starting to review the manuals.
> Yes, the i.mx6ul and 7 are quite similar. I don't think that big
> adaptions are necessary.
>
>>>> - I haven't been working with "device trees".  These are required for the "imx" BSP.  Is this the preferred direction for a BSP?
>>>  From my point of view it would be good to use the device tree for all
>>> targets that use a device tree for Linux or FreeBSD too. Especially if
>>> you want to use libbsd you can save a lot of necessary adaptions.
>>>
>>>> - If anyone has any suggestions for how to ultimately arrange things then let me know.  Right now, before I've gotten started, I plan to make this BSP a variant in the "imx" BSP and to try to either re-use existing "chip" library routines or add new ones.
>>> For the imx6 I still hope that no variant is necessary. But I planned to
>>> discuss this with Sebastian.
>> 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.