- It says GPIO can be controlled by driver, please let me know how to control it using drivers( by changing the dtsi files)
If you include your dtsi correctly, then it will already enabled the driver to control it.
The current situation is we don’t know whether you really apply them correctly. That is the purpose we need kernel log and your dtb file to tell.
the including of the .dtsi files inside the corresponding .dts file are already done, we need not do it.
pls find the master .DTB file which is getting flashed ( tegra194-p2888-0008-p2822-0000.dtb) ( which is renamed as .txt file for attachment purpose here ).
tegra194-p2888-0008-p2822-0000.txt (385.3 KB)
kernel log i will try to get it later from the target PC…
I don’t know what are you talking about exactly.
Your dtb just showed that your gpio dtsi is not added to it at all.
.cfg file is in readable text format we can understand.
Regarding the DTB file which is not in readable format how to convert it to DTS format. I tried with DTC command but it is not working properly. Please let me know. Thanks.
Hi,
Let me explain this again since you are still not in situation.
First, I told that you have to include the dtsi to your kernel dtb in this comment.
Next, you shared out your kernel dtb and I convert it back to dts and check the content. “tegra19x-jetson_agx_industrial-gpio-default.txt” totally not added to it.
So there are few questions
Did you ever build kernel dtb before? If so, how did you do that?
What dtc command you are using ? For what purpose?
Just have a small doubt here regarding this including of .dtsi files generated by PIN mUX spreadsheet.
You need to understand the boot flow first. There are lots of software component during the whole boot flow.
The flow would be MB1-> MB2-> UEFI-> Kernel.
The pinmux will take effect in MB1 boot stage. The next boot component will either modify it or just inherit the previous stage.
For example, if your enable a pin as GPIO with output low in cfg, it will take effect in MB1. When device boots into MB2, it will still be the state as what you set in MB1.
Next, if MB2 didn’t change its configuration, then it would still work as GPIO output low and move to UEFI.
This rule will keep going until entering kernel. And actually kernel most likely will change it because lots of driver enabled there.
Thus, it is most likely this gpio state has been updated multiple times during the whole process.
The point to add gpio setting in kernel dtb is to make sure there is a driver in kernel to really set GPIO state to what you want.
Thanks for the reply. That was very informative. Please let me know what is location and name of kernel dtb?( dts/dtsi files that we should edit for GPIO ).
Hi,
You need to download the source code from the website and follow the page to build kernel dtb.
→
For the device tree, replace the files in
Linux_for_Tegra/kernel/dtb/with a copy from:
$kernel_out/arch/arm64/boot/dts/nvidia/
DTC cannot directly include and build the dtsi file. For example, dtc is not even able to recognize the first line in your dtsi file. It does not know what is tegra-gpio.h.
include <dt-bindings/gpio/tegra-gpio.h>
We are already doing the same, what you have mentioned as per the steps mentioned in the website.
I am asking if you know any specific dtsi files that need to be edited for. GPIO configuring.
Thanks.
Could you pls provide the command to convert DTB file tp DTS file using DTC or FTDUMP
I tried it but it wasn’t working properly. Thanks
We are not explicitly building DTS/DTSI files but they are getting built as part of our total Kernel build command.
Please trace your tegra194-p2888-0008-p2822-0000.dts and you will find it out.
If you want to really understand how things work here, trace the code. I also do not “memorize” every dtsi code in every platform. If you ask me which dtsi file is for this part, basically I just open the dts source code and start to trace it back.
Could you pls provide the command to convert DTB file tp DTS file using DTC or FTDUMP
This command. Actually you can find it from google search.
dtc -I dtb -O dts your_dtb > the_dts_filename
Just in case you are still not in situation after all these comments. What we are talking about is above file or the content of above file was not included in any of your kernel dtb.
You only generated this thing out from spreadsheet and looks like you just put it there and nobody knows the existence of this file and you thought it got built into your kernel dtb.
This file was used to generate the. Cfg file using python script. That CFG file was flashed as per the steps given in website.
There was no steps in the website nor anywhere to include this dtsi file inside any of the parent dts/dtsi file to build it as part of kernal dtb.
That’s why I didn’t include this dtsi file anywhere. I will try including this file and test on Monday and will let you know the result. Thanks.
I have included the gpio and pinmux dtsi files generated from the PIN MUX spread sheet and built the DTB file and flashed to the unit. But still not able to see the CAN DIN0, DOUT0, DIN1, DOUT1 being mapped to GPIO port AA pins 01,02,03,04 when I check in the /SYS/kernel/Gpio command . Also my other GPIO PINs GPIO05, GPIO10, GPIO1, GPIO13, GPIO35, GPIO24, GPIO26, GPIO27, GPIO29, GPIO30 which are mapped to various GPIO ports are not updated as per what I changed in the PIN MUX sheet.
Please find decoded master DTS file attached for details. Also find the GPIO and pinmux .dtsi files also.
tegra19x-jetson_agx_industrial-gpio-default.txt (2.4 KB)
tegra19x-jetson_agx_industrial-pinmux.txt (54.3 KB)
tegra194-p2888-0008-p2822-0000.txt (528.1 KB)
Please share your dmesg.
But still nt able to see the CAN DIN0, DOUT0, DIN1, DOUT1 being mapped to GPIO port AA pins 01,02,03,04
Just a reminder that the only thing that explicitly set to GPIO in above 4 pins are GPIO AA4. The rest of 3 ports still set as SFIO.
lso my other GPIO PINs GPIO05, GPIO10, GPIO1, GPIO13, GPIO35, GPIO24, GPIO26, GPIO27, GPIO29, GPIO30 which are mapped to various GPIO ports are not updated as per what I changed in the PIN MUX sheet.
It looks like GPIO05 which is GPIO PA.01 is also not listed.
It looks like pinmux spreadsheet still has something that not selected correctly.
Can let me know how did you find out they are SFIO from the dtsi file?
Also I see the CANIN and CANOUTs are mapped to GPIO port AA as shown below from pinmux.dtsi file which is matching that they are used as SFIO being mapped to CAN IN/OUT pins
can1_dout_paa0 {
nvidia,pins = “can1_dout_paa0”;
nvidia,function = “can1”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};can1_din_paa1 { nvidia,pins = "can1_din_**paa1**"; nvidia,function = "can1"; nvidia,pull = <TEGRA_PIN_PULL_UP>; nvidia,tristate = <TEGRA_PIN_ENABLE>; nvidia,enable-input = <TEGRA_PIN_ENABLE>; }; can0_dout_paa2 { nvidia,pins = "can0_dout_**paa2**"; nvidia,function = "can0"; nvidia,pull = <TEGRA_PIN_PULL_UP>; nvidia,tristate = <TEGRA_PIN_DISABLE>; nvidia,enable-input = <TEGRA_PIN_DISABLE>; }; can0_din_paa3 { nvidia,pins = "can0_din_**paa3**"; nvidia,function = "can0"; nvidia,pull = <TEGRA_PIN_PULL_UP>; nvidia,tristate = <TEGRA_PIN_ENABLE>; nvidia,enable-input = <TEGRA_PIN_ENABLE>; };