Microprocessor / IMX8MPLUS support

[golpan-rs]

Hey, @i509VCB!

I've got a bit of a pet project spooling up right now, and one of my (very lofty) long-term goals is to (try) to bring IMX8MPLUS support to embassy.

Right now I'm doing research on how exactly to properly slot my contributions into the embassy ecosystem.

I saw the discussion over on embassy-rs/embassy#4345 regarding the potential for a centralized HAL for NXP microcontrollers.

Since I have interest in integrating NXP microprocessors, this naturally leads me to wonder: Should I attempt to integrate my work into this WIP PAC you have going?

I'm split -- the nxp-pac idea is already experimental to-boot, so maybe it would be better for me to start out with the more "traditional" approach implementing imx8mplus-pac or imx8x-pac in an independent crate, and save integration into this project for a later time.

There is also the question of whether you are even targeting microprocessors with this, or if you just envision microcontroller support

I would definitely be interested in your input on all of this. Later, when I am much more confident in my ability to actually pull this off I will probably contact more embassy-rs community members proper about it. But your advice at this stage I suspect will be very helpful.

Thank you

P.S: Worth noting is this related archived project, though it targeted only the M7 cores of the IMX8MM platform:

https://github.com/afirago/imx8-rust/blob/master/imx8mm-hal/src/lib.rs

[i509VCB]

The microcontroller cores are something I have interest in working in embassy, but you say want the application core(s) to work. I wouldn't say no but I also see there is quite a bit of work involved. Maybe also worth a discussion in the embassy matrix chat?

It's certainly doable. iirc there are not any SVD files for the address space on the application cores (at least in mcux-soc-svd). That fact is going to make the process quite annoying (of course you could write chiptool definitions for blocks, but that could be a lot of manual work).

I don't recall if Cortex-A and R support was added to embassy-executor yet (there was a pull request to do that). I agree that imx8 support would definitely help with testing Cortex-A/R in the executor.

Surprisingly I saw some NXP presentation saying what chips the imxrt parts took IP from and there may have been an imx8 IP or two there?

[i509VCB]

A secondary comment is that if possible I'd also like Cortex-R support for embassy-nxp (similar issues with mcux-soc-svd), but does NXP have one that doesn't cost a fortune?

[golpan-rs]

but you say want the application core(s) to work

Indeed, deploying to those is my primary interest, with the M7 core being a "nice to have" for me -- essentially the exact inverse of your priorities, it would seem! 😆

It's certainly doable. iirc there are not any SVD files for the address space on the application cores (at least in mcux-soc-svd). That fact is going to make the process quite annoying (of course you could write chiptool definitions for blocks, but that could be a lot of manual work).

Ah, yes. To be honest, I was prepared to do this entirely manually, the fact that chiptool even exists is something I only recently learned. How would you feel about incomplete HAL implementations being contributed here? In my original plan, I wanted to implement the bare minimum to be able to run and flash very basic firmware (just as a starting point). So, by no means a comprehensive implementation of all the IP.

Plus, I have the advantage of a reference implementation; Looks like NXP themselves are now maintaining board support in Zephyr, so I have that in case of emergency. I recently actually managed to deploy Zephyr directly to one of the cores on my IMX8MPLUS devkit over J-Link. So in theory I've got enough going to at least hypothetically guarantee success with stuff like adding probe-rs support (which is probably where I'll be starting for now)

I don't recall if Cortex-A and R support was added to embassy-executor yet (there was a pull request to do that). I agree that imx8 support would definitely help with testing Cortex-A/R in the executor.

Great point, that may indeed be another hurdle to overcome, thank you for pointing it out.

Surprisingly I saw some NXP presentation saying what chips the imxrt parts took IP from and there may have been an imx8 IP or two there?

If you happen to know where I can find that document too, it could be very useful, good find!

I'd also like Cortex-R support for embassy-nxp [...] but does NXP have one that doesn't cost a fortune?

Ha! I doubt it, to be honest. Maybe there is a third-party devkit. I spent far more money than I'd like to admit on my IMX8MPLUS devkit before, weeks later, discovering there is an open source alternative at about 20% the price

Although the devkit I went with was probably the right choice for this project for various reasons....

[i509VCB]

I think it was in this, page 27
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/tech-days/287/1/AMF-AUT-T3894-Intro%20to%20the%20RT%20Family%20-%20Lydia%20Ziegler_rev.pdf

Looks like uart, i2c and SPI are from imx8q (not the part you mentioned of course).

[golpan-rs]

I forgot to reply to this point specifically, too:

Maybe also worth a discussion in the embassy matrix chat?

100%. Though I am very early stages in this. I'll probably bring it up there after I have a bit more experience with this ecosystem under my belt

Thank you for the input and information!