On prior products where we did not use a SOM - we could carefully select IMX pins and GPIO banks such that the coprocessor (M4, FreeRTOS) and main processor (A9, Linux) did not conflict, and we could have exclusive access to interrupts and the GPIO peripheral on each.
This is required even if we make use of the semaphore resource protection locks - because of the use of interrupts. We also have a decent bit of high speed GPIO.
Am I mistaken in seeing that this is essentially impossible on a Toradex IMX8MP module with WiFI due to the way that GPIO has been allocated to built in functions?
GPIO1: PMIC, ETH1 interrupt
GPIO2: WiFi Wakeup, power enable, ETH2 power enable
GPIO3: WiFi I2S
GPIO4: Sleep MOCI, ETH2 interrupt, WiFi I2S, ETH when FEC sleeping.
GPIO5: On Module I2C
I am referencing the imx8m-verdin.dtsi in upstream Linux.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Managing GPIO allocation and ensuring exclusive access for both the main processor and a coprocessor like the M4 running FreeRTOS on the i.MX 8M Plus SoM can indeed present challenges, especially when considering the predefined functions of some GPIOs as outlined in your message. The i.MX 8M Plus, like other complex SoCs, integrates multiple functionalities that are pinned out to optimize for common use cases, which can sometimes limit flexibility for specific custom applications.
However, it’s not entirely impossible to achieve the level of control and exclusivity you’re looking for, but it requires careful planning and possibly some compromises:
Dedicated vs. Shared GPIOs: As you’ve identified, certain GPIOs on the i.MX 8M Plus are allocated for specific functions (e.g., WiFi, Ethernet, PMIC). To avoid conflicts, you’ll need to identify GPIOs that are not dedicated to critical functions or those that can be reconfigured without impacting the module’s operation. This might involve disabling certain features if they are not required for your application.
Device Tree Configuration: Through careful configuration of the device tree, you can define which peripherals and GPIOs are active for both the Linux and FreeRTOS environments. This involves modifying the device tree to disable unused peripherals or reassign GPIOs as needed, ensuring that they are not claimed by Linux and can be exclusively accessed by the M4 core. Remember, any changes to the device tree to accommodate such configurations should be thoroughly tested to avoid conflicts.
Semaphore and Interrupt Management: While semaphore resource protection locks can help manage access to shared resources, managing interrupts for high-speed GPIO requires ensuring that both the Linux and FreeRTOS sides are correctly configured to handle or ignore these interrupts as appropriate. This might involve customizing the interrupt controller settings and ensuring that interrupt handlers do not inadvertently affect the operation of the other processor.
Alternative Interfaces: If the GPIO limitations prove too restrictive for your application’s needs, consider whether alternative interfaces could serve your requirements. For example, SPI, I2C, or UART interfaces might provide the necessary communication channels without the direct need for high-speed GPIO.
Consulting the SoC and Module Documentation: The i.MX 8M Plus reference manual and the Verdin module datasheet provide detailed information on pin multiplexing, GPIO capabilities, and peripheral configurations. These documents can be invaluable resources for planning your system architecture to avoid conflicts and optimize the use of available GPIOs.
In summary, while
Please, also check if these links can help you solve your problem:
Yes, we are using some SoC balls as GPIO lines to control internal devices or as interrupt sources. However, not all functionalities you listed are used as GPIO. For example, WiFi I2S lines or on-module I2C are not GPIO, so you can mux the default GPIO banks/bits for those pins to some other unused pins. Additionally, ETH2 lines are directly routed to the edge connector, so you are free to pinmux them arbitrarily if you don’t have a second ETH PHY on your carrier board.
Thank you for the helpful response! I was wondering about those, as the I2S entries look a bit incomplete in the upstream Linux Verdin IMX8MP DTS to do actual WiFi/BT I2S.
So, to confirm, we’d allocate I2S, even if unused, like:
to use interrupt from M7 you MUST disable the whole GPIO back from Linux side (in the device tree)
and so, GPIO3 and GPIO5 are the only banks that can be disabled (this is because of the poins used by Toradex INSIDE the SoM). I’ve already suggested Toradex to review the design and remap all these pins into a signle GPIO bank, so that more banks can be left to the user (especially GPIO1 that has individual interrupts too)
GPIO5 needs an additional step, because scl-gpios and sda-gpios must be disabled too
if you don’t need GPIO interupts, you can use more or less whatever you need
With all the above steps, at the moment I can go on (not happy, but I can go), but my test is not finished yet.
For example, WiFi I2S lines or on-module I2C are not GPIO
This is not 100% true. I have to hope that the I2C bus does not lock up on the module from what I’m hearing (although it’d be strange for a built-in interface to fail as such and I expect it to be reliable). We are also right up against the pin limit for GPIO3/5 and must use nonstandard interfaces.
In general, this is kinda an unfortunate design for the IMX line and I wonder if it could have been avoided by more careful planning for the SOC to SOM assignments. It’s especially bad that GPIO1 is planned out the way it was as it does have those individually assignable interrupts AND is it was the GPIO chosen for the reserved Verdin GPIOs clashing with critical interfaces run by Linux - so - you basically can’t design a pin compatible carrier board that makes effective use of the coprocessor.
Could you please explain - What exactly is not true?
The Verdin family was designed to accommodate different types of SoCs, making it challenging to anticipate all future customer requests regarding SoC to module pin mapping.
I recommend to take a look to our pinout designer tool for pin assignment planning.
The reason I say it’s not fully true is - I’m just going by the fact that the original device tree had the on-board I2C GPIO pinmuxes there for a defined reason - to allow for escaping I2C lock-outs. So - they are GPIO - if you use them for that feature. As I said - it probably isn’t an issue to worry about - but - as the FAE in the other thread said - it’s worth noting that you cannot use that as a feature if you disable it.
The Verdin family was designed to accommodate different types of SoCs, making it challenging to anticipate all future customer requests regarding SoC to module pin mapping.
I recommend to take a look to our pinout designer tool for pin assignment planning.
I am not having issues with planning. I believe understand the constraints well.
I do not understand why at the least, this small list of 2 GPIOs: ETHYPHY0 INT, PMIC_USDHC_VSELECT couldn’t find a different allocation for the IMX8M Plus. As it stands, these 2 GPIOs being allocated on GPIO1 mean that customers are not able to use the reserved “always-compatible” GPIO pins or take advantage of their individual pin interrupt capability on the co-processor without breaking their built-in Ethernet.
That decision was made by our Hardware Team located in Europe. While I can inquire about the reasoning behind this decision, the design has already been finalized, and I do not have the authority to make any changes. If you have any other questions, I would be happy to assist you with them.
I agree 100%.
Verdin family specifies which pin functionality is available on the SoM connector, and this should be as much as possible independent from the SoC. This is clear.
But, if Verdin connector has 20 GPIO (as an example), and iMX8M-Plus has 50 (random numbers), during the Plus SoM design there is some kind of freedom to decide which SoC GPIOs should be used internally to the SoM (not on the connector), and which ones should be connected to the connector on the GPIO pins of Verdin family.
And, the decision taken on the Plus has been a little bit “unfortunate”.
