AM62L: How to control GPIO in U-Boot

Hi Koji,
It appears that the device tree changes you are making are being applied to the Linux kernel source under arch/arm64/boot/dts/ti, rather than within the U-Boot source tree. U-Boot maintains its own copy of the device tree, so any GPIO-related modifications must be made in the corresponding U-Boot device tree directory for them to take effect during the bootloader stage.
Since no updates have been applied to the U-Boot device tree, the changes you expect are not being reflected in U-Boot, which is likely the root cause of the issue you're seeing.
Regards,
Shriya

Hi Shriya,

Sorry, I have attached wrong device tree.

This is correct one.

dts/upstream/src/arm64/ti/
|-- k3-am62l3-custom.dts
`-- k3-am62lx-custom-pinmux.dtsi

The pinmux is included in the dts.

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
#include <dt-bindings/net/ti-dp83867.h>
#include "k3-am62l3.dtsi"
#include "k3-am62lx-custom-pinmux.dtsi"
#include "k3-pinctrl.h"

Even though the U-Boot device tree is configured as above, "gpio set" command could not be succeeded.

Best Regards,

Koji

Hi Koji, 

Would you be able to send both your u-boot and linux device tree files? I also would like to know why you enabled certain bits for the PADCONFIG in the following line: 

mw 0x4084238 00054007

Regards,

Shriya

Shriya Surti said:

Would you be able to send both your u-boot and linux device tree files?

As I mentioned before, I don't understand why linux device tree is influence on working in U-Boot.

Do you need the all contents in device tree?

I think that already attached the contents related GPIO before.

I would like to get your explanation why  your want me to these information and what information is insufficient.

Shriya Surti said:

I also would like to know why you enabled certain bits for the PADCONFIG in the following line: 

GPIOI0_125 could be controlled by "gpio set" command, so I tried to enable the bits for GPIO0_123 to match with GPIO0_125.

As we go through the process of troubleshooting this issue, I want to clarify an earlier statement. Previously, I mentioned that the u-boot and linux device tree do not need to match up. However, they do need to match in respect to pinmux configurations. A mismatch in pinmux values between both dts files could be causing the issue you see above which is something we have not covered yet. That is why I would like to compare both files (specifically both GPIO configurations). 

That alongside incorrect PADCONFIG values can prevent a GPIO form physically toggling even if it appears to be toggled in software. Can you please explain further why you enabled the specific values you did in the PADCONFIG register? Here is a helpful guide that goes over the PADCONFIG registers bits: [FAQ] AM625 / AM623 / AM620-Q1 / AM62L / AM64x/ AM243x (ALV) / AM62Ax / AM62D-Q1 / AM62Px Design Recommendations / Custom board hardware design – Information on PADCONFIG bits and PADCONFIG registers default values summary - Processors forum - Processors - TI E2E support forums. 

Hope this helps,

Shriya

I've said  the pinmux of device trees for U-Boot and Linux don't have to match, and you didn't deny.

I ask the same thing again, why Linux device tree is influence on U-Boot before booting Kernel?

Koji Hirohashi said:

According to Bin Liu statement in the following thread, the pinmux of device trees for U-Boot and Linux don't have to match.

AM62L: GPIO device tree configuration in U-Boot and Linux

Shriya Surti said:

Can you please explain further why you enabled the specific values you did in the PADCONFIG register?

I already mentioned the reason above, and I have no further explanation.

I will try to write the specific bit for the PADCONFIG correctly, but I need your explanation why I could not set GPIO to output in the current situation.

You said me to read the register value, but you've never mentioned about the value yet.

In the first place, is this the expected value when the GPIO is set to output?

Koji Hirohashi said:

I tried to read and write the PADFONFIG.

It's the result when read and write the PADCONFIG for GPIO0_123.

Hi Koji, 

The development team I would need to consult with regarding your issue is currently out of office on holiday. We will get back to you next week with more information. In the meantime, if you are able to manipulate GPIO0_123 by writing the same value you had for GPIO0_125 PADCONFIG, would you be able to try this with other pins as well?

Thank you,

Shriya

Hi Koji, 

I see you have reopened the thread, was there any more information you would like to add until we hear back from the development team?

Regards,

Shriya

I already added all information I could.

Shriya Surti said:

In the meantime, if you are able to manipulate GPIO0_123 by writing the same value you had for GPIO0_125 PADCONFIG, would you be able to try this with other pins as well?

If your development team can't start to research before I have not done to confirm other pin's working, I will confirm it first.

Best Regards,

Koji

Do you have any update?

When I confirmed the other GPIO that configured as output, it seems that gpio-hog also could not be working.

I guess this issue is related with the gpio set issue.

p2-hog {
		/* P2 - ET1_RSTn */
		gpio-hog;
		gpios = <2 GPIO_ACTIVE_HIGH>;
		output-high;
		line-name = "ET1_RSTn";
	};

Best Regards,

Koji

Hi Koji,

I believe I can offer clarification. GPIOs configured as PIN_OUTPUT are failing to drive the pin even though the GPIO direction changes from input to output and the output register is written. In contrast, GPIOs initially configured as PIN_INPUT work correctly with gpio set, with no warning, as observed in your testing.

The failing GPIO0_123 showed a PADCONFIG value of 0x00010007, while a working GPIO0_125 showed 0x00054007. When the working PADCONFIG value was manually written to GPIO0_123 using mw, the pin immediately began working correctly with no warning and correct output readback. This confirms that the GPIO controller itself is functioning correctly and that the root cause is the PADCONFIG value for output pins.

Since neither gpio set nor gpio-hog updates the PADCONFIG register, both were physically unable to drive the pin until the PADCONFIG was manually corrected, meaning the permanent fix must be in the pinmux macro rather than in the GPIO commands.

The reason PIN_INPUT pins worked is that it enables the GPIO input buffer, allowing the pin level to be read correctly and to be used as an input or output. However, proper PADCONFIG settings are still required for reliable output driving. If the pins are set as inputs, you can use gpio set in U-Boot to change them. Otherwise, the PADCONFIG value must be modified (as done with GPIO0_123) if you want to keep the pin defined as PIN_OUTPUT in the device tree.

Hope this helps,

Shriya

I understood that gpio-hog issue is occurred by same reason with gpio set.

You have said it is not necessary to write to the PADCONFIG register.

Is your explanation consistent?

Shriya Surti said:

It is not necessary to write to the register, however, we were taking these steps as a sanity check.

Shriya Surti said:

Otherwise, the PADCONFIG value must be modified (as done with GPIO0_123) if you want to keep the pin defined as PIN_OUTPUT in the device tree.

Shriya Surti said:

meaning the permanent fix must be in the pinmux macro rather than in the GPIO commands.

I attached the GPIO pinmux before.

Is that configure correct?

There are the other questions you haven't answered yet.

This thread cannot be closed until these questions are resolved.

Koji Hirohashi said:

I ask the same thing again, why Linux device tree is influence on U-Boot before booting Kernel?

Koji Hirohashi said:

You said me to read the register value, but you've never mentioned about the value yet.

In the first place, is this the expected value when the GPIO is set to output?

How is your development team progressing?

Best Regards,

Koji

Hi Koji,
I apologize for the confusion caused by my earlier explanations.

My initial thought process was that the issue stemmed from differences between the Linux and U-Boot device trees. This is a common source of GPIO-related problems, as U-Boot pulls in a snapshot of the Linux device tree at build time and builds on top of that copy, rather than dynamically referencing the active Linux DTS at runtime. Because of this, any mismatch in how GPIO pins are defined between Linux and U-Boot can lead to the behavior you observed.

Koji Hirohashi said:

Is your explanation consistent?

Regarding my earlier comments on the PADCONFIG register: after additional testing on my side, I was able to set and control GPIO output pins in U-Boot only after updating the PADCONFIG register. I also can confirm that your register values for gpio0_123 and gpio0_125 are consistent with what is to be expected. This is why in my later explanation I recommended modifying the PADCONFIG value. Enabling the appropriate PADCONFIG bits through the U-Boot command line is required for this approach to function correctly. 

Koji Hirohashi said:

How is your development team progressing?

From the device tree code you shared, your configuration does appear correct. I am not certain why the expected output state is not reflected at initial boot, and I am working with the development team on resolving your issue, however, their responses may be delayed due to an upcoming release.
Please let me know if you would like further clarification.

Best regards,
Shriya

Shriya Surti said:

Because of this, any mismatch in how GPIO pins are defined between Linux and U-Boot can lead to the behavior you observed.

Do you mean it may be caused if there was just one difference between Linux and U-Boot device tree?

The pinmux for the GPIO where the problem occurs matches, but there are some differences in the other configure.

According to the another thread I asked, it is allowed difference between these device tree.

Shriya Surti said:

Enabling the appropriate PADCONFIG bits through the U-Boot command line is required for this approach to function correctly. 

In my understanding, it is not necessary to write to PADCONFIG normally, but it is necessary to write in the current situation.

Hi Koji,

I believe your current Linux and U-Boot device tree configuration should be fine, as you indicated that the GPIO pinmux settings match. In regards to the PADCONFIG register, your statement is correct. In general, PADCONFIG does not need to be explicitly written to, but based on the current behavior we are seeing, it appears to be necessary in this situation. I believe writing to the PADCONFIG register is the solution you are looking for. I will update you once I hear back from the development team in case there are any additional solutions.

Regards,
Shriya

I will work around by writing PADCONFIG until updating from development team.

The register value for GPIO output pin before write is 0x00010007.

According to TRM, I think this is already appropriate value as configuration for GPIO output.

Could you tell me what value I should write to the register?

Best Regards,

Koji

Hi Koji, 

You would want to enable RX_ACTIVE and the MUX_MODE, so 0x00040007. For more information please check the following link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1539321/faq-am625-am623-am620-q1-am62l-am64x-am243x-alv-am62ax-am62d-q1-am62px-design-recommendations-custom-board-hardware-design-information-on-padconfig-bits-and-padconfig-registers-default-values-summary/5921379?tisearch=e2e-sitesearch&keymatch=AM62L%20padconfig. 

Regards,

Shriya