Using SCU_GPIO0_00 as a GPIO from A35 on Colibri-iMX8DualX

Technical Support
, , , ,
1

Hi,

I would like to use SODIMM pin 144 (aka SCU_GPIO0_00) as a standard GPIO on a iMX8DualX Colibri module.
I have configured it via dtb using IMX8QXP_SCU_GPIO0_00_LSIO_GPIO2_IO03 0x6000021 in corresponding pinctrl, but the GPIO seems to be connected to GND even if on my custom carrier board, it is floating.

After some research, it seems the SODIMM 144 is connected to SCU Debug UART. Seems confirmed by Build Custom i.MX 8/8X System Controller Firmware (SCFW) | Toradex Developer Center.
My understanding is that the SCU is driving the SODIMM 144 and so even if I can configure it as input, it will always be driven low.

My question is: is it possible to use this SODIMM pin as a standard GPIO and can it be done via dtb customization or did it requires to change the SCFW ?

Kind regards

2

Hi @ykrons, thanks for reaching out support!

You pointed out correctly. You can see here that pin 144 has indeed the possibility to work as GPIO: pads-imx8qxp.h « pinctrl « dt-bindings « include - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules.

To enable it you can see the following line on the device tree: https://github.com/toradex/device-trees/blob/toradex_5.4-2.3.x-imx/dts-arm64/imx8x-colibri.dtsi#L722
It confirms that the pin is connected to the SCU Debug UART and therefore you’d need to change the SCFW to enable it.

Would you need to use this specific pin for your application or could you foresee another pin? There are other GPIO’s that are enabled by default that you could use or maybe other pins that you can toggle only by device tree changing. Could you please share with us the device tree you implemented?

Finally, here you can find some device-tree documentation as reference: High performance, low power Embedded Computing Systems | Toradex Developer Center

Best regards,

EDIT: the information about the need to compile the SCFW is wrong. See Answer 6 on the thread for a correction.

3

Thanks for your feedback.

In fact, I’m already successfully using other GPIOs via dtb customization, but the first revision of our custom carrier board is already started and I try to evaluate the cost of a new revision of the carrier board compared to the cost of changing the SCFW.

I have quickly gone through Build Custom i.MX 8/8X System Controller Firmware (SCFW) | Toradex Developer Center and it seems you are highly discouraging to change the SCFW.
I can see how to change the SCFW, but I’m not able to get how difficult it is to include it in the final image.

Kind regards

4

Hi @ykrons ,

From our point of view it is simpler to use another GPIO instead. Of course we understand that since you already triggered the first revision of the carrier it is a bit unfortunate.

We can offer you also to schedule a call with some of our experts, they might be able to tell you what the changes in the SCFW would be and how much effort it would be to implement these changes.

Would that be an option for you?

Have a great day.

Best Regards
Kevin

5

Yes, it could be very nice to have a deeper view of the impact with one of your expert.

We are in early development, so there is a high probability to have another revision due to other problem, but if only this GPIO is the issue a software option can be great.

Regards

6

Hi @ykrons,

Thanks for the update. Actually we discussed with our team and this explanation on the device tree and on the page seems to be a bit misleading and I’m sorry that I contributed for this error. I’ve just compiled a new Colibri iMX8X image with the following change on the imx8x-colibri.dtsi file:

&iomuxc {
         pinctrl-names = "default";
         pinctrl-0 = <&pinctrl_hog0>, <&pinctrl_hog1>, <&pinctrl_hog2>,
-                     <&pinctrl_ext_io0>, <&pinctrl_lpspi2_cs2>;
+                    <&pinctrl_ext_io0>, <&pinctrl_lpspi2_cs2>, <&pinctrl_hog_scfw>;

With these changes, I’ve been able to drive the GPIO like follows:

root@colibri-imx8x-06995807:~# gpioget 2 3
0
root@colibri-imx8x-06995807:~# gpioset 2 3=1
root@colibri-imx8x-06995807:~# gpioget 2 3
1
root@colibri-imx8x-06995807:~# gpioset 2 3=0
root@colibri-imx8x-06995807:~# gpioget 2 3
0
root@colibri-imx8x-06995807:~# gpioinfo 2
gpiochip2 - 32 lines:
	line   0:  "SODIMM_23"       unused   input  active-high 
	line   1:      unnamed       unused   input  active-high 
	line   2:      unnamed       unused   input  active-high 
	line   3: "SODIMM_144"       unused   input  active-high

The pin mux is already available on the iomuxc node and therefore you just need to add it to the pinctrl. The test was validated by a Multimeter connected to the pin output on the Evaluation Board. Therefore, there is no need to change the SCFW for this pin to work as a GPIO in the end.

7

Hi @gclaudino.tx ,

Thanks a lot for the update.
Following your instructions, I’m able to drive the SODIMM 144 properly.
However I have enabled the pull-up, so I’m expecting to read “1” when the IO is floating and in that case I get “0”.
pinconf-pins gives 0x20000020 setting for pin 129 (IMX8QXP_SCU_GPIO0_00), so I think the IO is properly configured with the pull-up.

Did I miss something to properly configure the pull-up?

Kind regards

8

Hi @ykrons,

Can you please share the resulting files with us so that we can check the pin set after all the changes you’ve made to enable it and also check the resulting device tree?

You can upload them here directly or use share.toradex.com.

Best regards,

9

Hi,

I have sent you the link to download pinconf-pins output and the dtb file used.

Here is exactly the behavior I have:

# while sleep 1; do gpioget 2 3; done
1
1
1
0 < Here I just have touched the gpio with a probe, but the probe is still floating.
0
0 < Here I have released fully the gpio (no more probe) and the signal remains low
0

Kind regards

10

Hi @ykrons,

Thanks for sharing the links with us. As this may also help other people, I’m writing it back on the main thread.

Even though the pin is properly configured on the device tree to be a PU with the 0x20 set (see the following screenshot from NXP Reference Manual - 0x20 = 0100000b), there are some level shifters on the SoM level that make it behave differently than other pins like SODIMM133 that really do behave as PU like expected. These level shifters seem to be causing SODIMM144 to behave as a latch and are needed to regulate the voltage values on the module.

image
image1366×712 57.8 KB

Therefore, we’d like to know if you’d really need to have this specific pin as PU or if you could work with it as it’s today or if you could use another GPIO. What would be the most suitable option for you? If it is to really use this specific pin as PU we’d need to look for an HW workaround and we may need some time to present you with a proper solution.

What do you think?

Best regards,

11

Thanks for clarifications.

Not being able to use this GPIO as an input with a pull-up is an issue for us.
As previously said, this is our first revision of the carrier board. Currently that is the only problem we have identified so if we can save a new revision we would be happy, but we have other GPIOs available that we can use on a new revision.

What could be the HW workaround ? You mean on the Colibri module, on the carrier board ?

Regards

12

Hi @ykrons,

I understand that it can be problematic to update the carrier board design. I’m checking with the team about what can be done in that case. We’ll come back to you once we do have more information.

Best regards,

13

Hi,

At the end we have other problems on the carrier board so we will change the design and use other sodimm.

One comment : it can be a good improvement to update the Colibri iMX8X Datasheet manual and add more explicit warning about limitations (not usable as input, …) of the Sodimm pins connected to SCU.

Thanks for your support!

Kind regards

14

Hi @ykrons,

Thanks for reporting. I’ll forward your request to our team responsible for the datasheets and we’ll try to make things clearer :smiley:

Best regards,

Edit: According to our hardware team, you could force pin 144 to behave as a pull-up by adding one hard pull-up on the carrier board.