arch/arm/imxrt: Add imxrt118x architecture and imxrt1180-evk board configurations - #20114
Conversation
3e980e6 to
cdd0d6f
Compare
github-actions
Bot
added
Area: Build system
Arch: arm
|
And also the topmost patch is actually not related to this port. It was just something I came across while debugging some uart/dma issues. Need to test & submit that separately |
|
|
Hi Jukka, Thanks for your contribution. It’s looking very good, and you’ve integrated it nicely into the existing i.MX RT family. I’ve added a few comments, but overall, the implementation looks solid. Unfortunately, I don’t currently have time to test the code on a board myself. When I have the opportunity, I can try it on an https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMXRT1186. Do you have a FRDM-IMXRT1186 board yourself as well? Otherwise I can maybe ask around to get you a sample. |
cdd0d6f to
905d4ba
Compare
|
Thanks @PetervdPerk-NXP for your comments! I'll fix those things when moving forward. For the "bootloader" I wasn't sure where to place that. I will clean it up / split it somehow, and place the functionality under arch as you suggested! I started debugging the usb on M7, and I believe I found a bug in the cache management in imxrt_usb. Have you had issues with that? The fix is now mangled together with 118x specific fixes in e6411a2 Basically, I think it is doing a cache invalidation with wrong address; I believe dtd->buffer0 shouldn't be used to invalidate the cache, but it should be done with the original buffer pointer stored in priv (the same way it is done in imx93 driver). Have you had issues with imxrt USB + write back cached memory? With up_invalidate_dcache done only after the transfer using the original start pointer, the usb is working for me in both m33 (currently xcache off) and in m7 (dcache on with writeback). There are some really unneeded fixes as well (added DEBUGASSERTS, and making many times sure that buffers are properly allocated...), but the main issue is really how the cache gets invalidated, not using the buffer0 in the middle of transfer, but only after the transfer using the original start pointer so that it doesn't invalidate past the receive buffer. |
|
Funny thing is, that there are now a lot of nxstyle errors from old code; the nxstyle itself has changed, I believe. |
905d4ba to
c8640f3
Compare
I've had some DMA related issues with USB before on the i.MXRT106X family but I couldn't reproduce it easily and never happened on i.MXRT117X but that uses write-through cache, so indeed that bug could've been in there for like forever.
Indeed it seems that they hardened the checks on switch statements had it with this simple fix as well PR #20117 |
c8640f3 to
ac56ed5
Compare
aa5b733 to
44388bd
Compare
0ec9315 to
5f85c13
Compare
…form - Initialize the internal secure element, if configured - Initialize the TRDC, if configured - Disable the TCM enabling code when compiling for other than Cortex-M7 chip. This needs to be skipped for M33 core on imx118x Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add the definitions for the Inter-Peripheral Crossbar Switch for iMXRT118x Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
beb142a
c3a5f3d to
beb142a
Compare
|
I believe the issue is really trying to download and use the SPSDK from within CI. But we only need very simple AHAB container, so I generated a pure C tool with claude, to generate the container. This can be used for m33 images when there are no other images/containers present - to just generate proper headers and sha256 checksum. Let's see if this resolves the issue. The workflow can be refined later, if someone can find a simpler/proper official tool. The mkimage, which is used by imx93, is such and generates exactly the same family ahab containers, but it is of course a separate tool and has built-in support for specific chips - not for imxrt family. |
beb142a to
ca0af0e
Compare
- Add imxrt118x compatible IOMUX definitions, named as IOMUX_VER3. This is the same IP as what is used for example for IMX9. Instead of directly copying the support from imx9, pack the padconfig into the same 32-bit value used for GPIO for easy use. - Add imxrt118x compatible rgpio driver. This is the same GPIO block as what has been used in imx9. Instead of directly copying the support from IMX9, add pin muxing directly into GPIO driver as well, to keep the usage compatible with existing IMXRT boards. Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Small additions to existing drivers to support more UARTs - Properly invalidate the cache over DMA RX buffer initially Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Move/make sure that ep0buf is in usb dma capable memory. Especially if .data/.bss are in TCM, the buffers need to be placed in another section. If the section .dmamemory doesn't exist, they will end up in .data like before - change "#ifdef CONFIG_ARCH_FAMILY_IMXRT117x" into "#if defined(CONFIG_ARCH_FAMILY_IMXRT117x) || defined(CONFIG_ARCH_FAMILY_IMXRT118x)" - In imxrt_epcomplete dtd->buffer0 must NOT be used to compute the data buffer's cache-maintenance address range. The hardware advances buffer0 (and its "current offset" low-order bits) as the transfer progresses, so by completion time it points *past* the start of the buffer (at start + xfer_len), not at the buffer itself. Instead, use the original privreq->req.buf when the transfer is complete. Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add a few !defined(CONFIG_ARCH_FAMILY_IMXRT118x) gates similar to 1176 to buid the common drivers also for 118x variants. Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Add driver supporting the DMA3 and DMA4 in iMXRT118x chips. The driver is first copied from imx93, and then changed just the relevant parts (function names, clocking and irq handling) to match the imx118x configuration. - Add the DMA channel numbering in hardware/rt118x/imxrt118x_dmamux.h from RM by claude. Assisted-by: Claude Code:claude-opus-4-7 Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add a function which can be called from M33 core on imx118x to start executing on M7 core. The function: - Configures the M7 clock root - Releases M7 from reset - Asks the secure element to release the M7 (ENABLE_APC) - Enables the M7 clock The function is compiled in when a configuration flag CONFIG_IMXRT_CM7_BOOT=y Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
We must enable the MPU on IMXRT118x to be able to keep writeback dcache on. Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
…urations This adds the initial board configurattions for building NuttX for imxrt1189-evk. Also add a script building the NXP container image for bootloaders (m33 images) The board boots on Cortex-M33 core, for which there are two m33 targets: nsh-m33 and bl. - "bl" target does basic initialization of ELE and TRDC and just releases the M7 to run at 0x20080000. - "nsh-m33" target just boots nuttx into nsh shell on m33 - The "nsh" target is for M7 core. It can be flashed at 0x20080000, and it boots to nsh shell with a proper bootloader on m33 (the bl target does this). Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
…80-evk Add the documentation for the new supported board configurations and for the architecture, Assisted-by: Claude Code:claude-opus-4-7 Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add support for loading the secure element firmware. Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
ca0af0e to
c2126a3
Compare
… creation Add a standalone tool to create AHAB container for imxrt118x. This can generate a trivial unsigned image without appending ELE. The tool can be used to create bootable images for m33. To do anything more complicated, the user needs to use the official SPSDK tool from NXP. Assisted-by: Claude Code:claude-opus-5-0 Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
c2126a3 to
0e9e454
Compare
|
That was it; the SPSDK was not usable by CI, too much python dependencies and such. Now it passes, I made some small cleanups still. The "mkahab" tool code is entirely generated; I only checked that it does the correct thing and does no evil, but didn't bother to clean it up much; it is just a tool after all. |
|
All imxrt builds pass cleanly, but now some STM32 builds are broken. This is unrelated to this PR, it is seen in other PRs as well. I'll come back to this early next week, right now I can't study that CI breakage. |
I'm curious how Zephyr-Rtos handles the ELE firmware for both imx93 and imxrt1180. Since it's also apache 2.0 same limitations/rules should apply. |
6 participants
Summary
I have started working on imxrt1180-evk support. This PR adds architecture support under arch/imxrt and boards.
Some drivers have been ported from imx9 (trdc, ele, dma), some copied and later modified from imx9 (clock configuration), some using imxrt drivers directly (peripherals: usb, lpuart, spi,, i2c...).
There are three board configurations available:
imxrt1180-evk:bl: bootloader on m33
imxrt1180-evk:nsh: nsh image for m7 core.
imxrt1180-evk:nsh-m33: Plain nuttx nsh image on m33
Impact
Doesn't (shouldn't) impact existing targets. Only adds support for new board
Testing
Very little testing so far. Both configurations ("m33 bl + m7 nsh" & "m33 nsh") boot and appear stable.
What seems to work:
What almost works:
Compiles, not tested:
Update:
Tested both "nsh-m33" and "bl+nsh" configurations with ostest. Also tested USB CDCACM on both m33 and m7 nsh images.
Ostest reports:
m7_testing.txt
m33_testing.txt