After unexport, GPIO can't be controlled again anymore.

Hi Sir/Madam,

After “echo GPIO# > /sys/class/gpio/unexport”, gpios can’t be controlled by export again.
The value can be changed, but the voltage don’t change by the value. Is it normal?

And one AON GPIO(GSYNC_VSYNC), I set output/high as default but after unexport the voltage will become low not keep at high.

Thanks

I would suppose it depends on what the new function of the pin is after you unexport. If nothing claims that pin (if no function is defined) after unexport then it seems there would be no defined state. You might want to add a use-case to describe what you are trying to accomplish.

I can’t verify every pins but pins I can measured no matter gpio or aon gpio have the same problem. I didn’t do anything after unexport and try export again but pins can’t be controlled anymore. (I can control the direction, value but the voltage of pins won’t be changed by the value I set). Before unexport, gpio pins work well. If pins would be no defined state, it should be controlled when I export it again.

Just to clarify, is it the case that GPIO works after export, but then after unexport and exporting again the voltage appearing on the pin can no longer be controlled despite the register being on or off as you echo values to the register?

yes

I have seen a similar issue. I suspect it was related to the level converter, but I haven’t tracked down where to do a voltage test for the various pins of the converter itself. It would be helpful if you can give an exact connector/pin number on the carrier board and the register you export/unexport for the test (which gives an exact test case). Some pins may have other uses which get in the way, but if a specific pin can be tracked when it is known to not have anything else trying to use that gpio it becomes easier to track (obviously there are a lot of gpio which might have different settings in the system).

Hi JasonFan,

Is this still an issue or has been clarified and fixed?

Thanks

Hi kayccc,

Now I don’t unexport gpios once I export ones.
I’m not sure if it is normal behaviors or driver issues for TX2 platform or not.
But now I can use this alternative way to work.

Thank you

I think there are workarounds, but there is still an issue with randomly exporting and unexporting a given GPIO (in this case to J21 header) where output does not consistently change relative to register changes.

hello JasonFan,

could you please try below change?
thanks

diff --git a/kernel-dts/jetson-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi b/kernel-dts/jetson-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi
index 30cdcf3..e8b2123 100644
--- a/kernel-dts/jetson-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi
+++ b/kernel-dts/jetson-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi
@@ -649,7 +649,7 @@
                        spi2_mosi_pb4 {
                                nvidia,pins = "spi2_mosi_pb4";
                                nvidia,function = "spi2";
-                               nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+                               nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
                                nvidia,tristate = <TEGRA_PIN_DISABLE>;
                                nvidia,enable-input = <TEGRA_PIN_ENABLE>;
                        };
@@ -657,7 +657,7 @@
                        spi2_miso_pb5 {
                                nvidia,pins = "spi2_miso_pb5";
                                nvidia,function = "spi2";
-                               nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+                               nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
                                nvidia,tristate = <TEGRA_PIN_DISABLE>;
                                nvidia,enable-input = <TEGRA_PIN_ENABLE>;
                        };
@@ -665,7 +665,7 @@
                        spi2_sck_pb6 {
                                nvidia,pins = "spi2_sck_pb6";
                                nvidia,function = "spi2";
-                               nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+                               nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
                                nvidia,tristate = <TEGRA_PIN_DISABLE>;
                                nvidia,enable-input = <TEGRA_PIN_ENABLE>;
                        };

Hi JerryChang,

I can’t find this file. tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi
I’m using R28.1 with TX2.

Thank you.

If you use source_sync.sh (“sudo ./source_sync.sh -k tegra-l4t-r28.1”) this will download not just the kernel source, but also some other subdirectories. This is in the “hardware” subdirectory:

hardware/nvidia/platform/t210/jetson/kernel-dts/jetson-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi

Kernel build seems to use a relative path for building the dtbs target which uses this hardware directory.

Hi linuxdev,

I don’t use source_sync.sh to download kernel source.
I decompress source_release_Source Packages.tbz2 and build kernel and hardware.
In hardware/nvidia/platform/, I only have t18x and tegra folders

So now my questions are

  1. For my understanding, tegra186 is for TX2 and tegra210 is for TX1. Is it right?

  2. Should I still need this folder “hardware/nvidia/platform/t210” to build my kernel and dtbs because I don’t have this folder

  3. If I modify hardware/nvidia/platform/t210/jetson/kernel-dts/jetson-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi. Will it be effective for my current build environment with source_release_Source Packages.tbz2?

Thank you

t186 is TX2, and t210 is TX1. There may be some cases where TX1 code works in TX2 though…their hardware is not entirely unique. Some parts of the device tree may also be in common.

When a new Tegra SoC is produced it is common for old controllers to remain unchanged, and new controllers get added at a different base address as a means of increasing that hardware feature (e.g., GPIO gets new controllers to add more GPIO lanes…the old controllers are still there and typically the same base address if you were to access them by physical address…the old hardware is often not replaced, but is instead appended to). So it is safe to say that if you see something for an old SoC in the code of a new SoC there is a good chance that part of the hardware did not change and the code is probably just being reused.

Changes to device tree (such as in that dtsi file you mentioned) don’t change the actual kernel…they change how the hardware is set up. There are instructions in the documentation on how to update a device tree…this changed when R28.1 was released (in comparison to older releases). You may need to run a flash procedure with your produced dtb file in the right place. I don’t know about this specific feature so I can’t tell you for sure about exactly what must be flashed.

Hi Linuxdev,

I know how to update dtb only with R28.1. Just have questions about this file /kernel-dts/jetson-platforms/tegra210-jetson-cv-pinmux-p2597-2180-a00.dtsi because there are different environments between JerryChang and mine. I need to make sure we have the same environment first otherwise won’t get the correct solution.

Thank you

By “different environment”, do you mean different carrier board or perhaps different hardware configuration? The file in question would be downloaded via the source_sync.sh script mentioned above.

Mostly if you start with the same configuration as your running Jetson, and make any edits to this file, then any build target using that file will reflect the changes in a way which otherwise matches what you started with. For example, there is a “make dtbs” target for building dtb files (you’d probably want to make sure “make Image” works prior to this just for sanity…plus it tells you right away if certain configuration issues might break the build).

“different environment” means different source base (software related…)

If the partition layout is the same in your system (I suppose some changes to U-Boot could break things, but probably not if derived from the R28.1 U-Boot), then the dtb update procedure should be the same. The flash script (you’ll want to read the R28.1 customization docs for device tree) will place the right content in the right place if the dtb you’ve customized is in place at the time of flash (and flash can be told to not flash the rootfs and just flash dtb).

Thanks, I know how to just flash dtb only correctly.

after unexport and export. set direction first and then value and check the voltage

thanks
Bibek