On 09/02/2020 17:36, Christian Mauderer wrote:
On 09/02/2020 17:24, dufa...@hda.com wrote:
On Feb 9, 2020, at 09:33 , Christian Mauderer <l...@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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
