i.MX RT 1170 support

[mciantyre]

imxrt-ral v0.5 includes support for both cores of the i.MX RT 1176. You can target the Cortex-M7 with the "imxrt1176_cm7" feature, and the Cortex-M4 with the "imxrt1176_cm4" feature. As of now, you're expected to build separate images for each core.

We addressed the limitations described in this description with new code generation solutions. See the linked PRs for more information.

We dropped any notion of resource management in imxrt-ral. Acquiring a peripheral instance is unsafe, since it's not clear how this should work in multi-core systems that deploy separate images for each core.

---

Here's some notes describing workarounds or unsolved issues I encountered when trying to add 1176 support to v0.4 of imxrt-ral.

Some peripherals have so many clusters and register arrays that imxrtral.py accidentally generates duplicate symbols. There's more info here. I'm working around this by changing how imxrtral.py generates names for clustered registers. Implementing true register cluster and array support in the RAL could be another approach.

The enumerated values for register fields may differ from the 10xx family. These differences are in the SVDs. Sometimes, they're "better" (more descriptive, easier to read) than what the 10xx SVDs provides.

use imxrt_ral as ral;

// 10xx enumerated values take the register field and add
// a suffix representing the raw bit value.
ral::modify_reg!(ral::lpspi, lpspi, CR, RST: RST_1);
ral::modify_reg!(ral::lpspi, lpspi, CR, RST: RST_0, DOZEN: DOZEN_0, DBGEN: DBGEN_1);

// 11xx. Notice how 'DOZEN_0' is replaced by 'ENABLED' in
// this equivalent snippet. Easier to see understand that
// 0 == "enabled"
ral::modify_reg!(ral::lpspi, lpspi, CR, RST: RESET);
ral::modify_reg!(ral::lpspi, lpspi, CR, RST: NOT_RESET, DOZEN: ENABLED, DBGEN: ENABLED);

And sometimes, they're worse.

// 10xx
ral::modify_reg!(ral::pit, pit, MCR, MDIS: MDIS_0);
// 11xx
ral::modify_reg!(ral::pit, pit, MCR, MDIS: t0301); // Wut?

If a HAL driver uses 10xx-flavored enumerated values, it won't simply build once we introduce the 11xx RAL. Raw bit values don't change, so we could say "don't use enumerated values" and give up readability. Otherwise, we might need a common symbol for these enumerated values, and I'm not yet sure what this looks like.

[mciantyre]

Right now, I'm not paying much attention to the RAL's fit in a multi-core system. In this prototype branch, there's two SVDs, one for each core, generating two RAL interfaces. Users would be expected to build one binary for each core. Users would need to make sure they're not takeing peripherals that are already taken in the other core, or use the "nosync" feature to disable that API.

I'm patching the SVDs if they might permit invalid cross-core peripheral access. See here for what (I think) is one example of this issue.

[teburd]

It's unfortunate that the RALs don't directly match up, I suppose some effort could be made to patch them up to make them align but that sounds like a pretty tedious task.

The cross core peripheral access... yeah this is tougher. A quick glance at the datasheet and I noticed it supports hardware semaphores (cool) and maybe even more relevant and cooler, the RDC which seems to limit things to one or both cores as needed which is maybe even more relevant.

RDC seems like one of those things that would need to be setup by the initially booting core as needed maybe along with a generated set of peripherals in the struct Peripherals based on some build time configuration.