Support RT1180 family

[nilfit]

The 1180 family uses a different boot header than previous families. The header is generated to support the default configuration where hash and signature errors are ignored.

The XIP __pre_init strategy is still used, more for ease of getting something running than because of any known problems with the boot ROM's implementation of loading images to different memories.

The boot ROM for the 1180 does not appear to allow the entry point to lie outside the (loaded or execute-in-place) image, so a new .xip section is added after the vector table to put the address inside the image while keeping VMA=LMA. This could cause problems for tools that manipulate binaries based on section names.

There is not yet enough board support to enable examples/blink*, so I have used RTT to see that the application starts with a minimal crate outside the repo.

[mciantyre]

I fixed the clippy warnings on the main branch. I'll run some regression tests on my other i.MX RT targets. If those look good, I'll approve and merge.

Right now, I'm working without the 1180's reference manual, and I won't have time to cross-check these ideas against the SDK. You folks are far ahead of me in understanding this MCU, so I'll catch up later.

Is there anything else needed in this crate for the 1180? I'm happy to publish a release with this work.

[mciantyre]

imxrt-hal examples still executed on my 1010, 1060, and 1170 hardware.

[korken89]

Hi all,

From our side, (@nilfit and I), if possible we'd of course like someone to give it a go on the RT1180-EVK, but we're continuously testing it from our side as well.

The only issue we have right now is that RTT is working, however defmt is not. We're not 100% sure if it's an error here or somewhere else - so I'd recommend waiting with a release until we've figured this part out.

[nilfit]

The defmt issue was in the target description for probe-rs. Apparently RTT is interpreted as strings without any warning if the memory map does not contain the destination of some pointers in the RTT block.

I updated the PR because I rediscovered a note about the first 16k of OCRAM not being usable by applications.

[korken89]

Is the ocram size calculation correct now? It still states the entire RAM as size, should it be made 16k smaller?

[nilfit]

Good catch! It should be fixed now.

[mciantyre]

Ping me here or on Matrix when you're feeling confident for a release. Thanks for adding this!