Hi,
I think the way you are thinking of this problem is wrong…
It is your hardware design… your hardware engineer should have some background knowledge about usb and he/she should provide initial idea to you first.
We need otg support so that device mode could be enabled… that is all we need. Whether what kind of port design to use, you should check with your hw engineer.
I understand.As our hardware guy was bit new to the internal details of USB, even though he has designed, I was trying study as much possible and start off before discussing with him for more details.
Mean while, we are not able to see nvidia corp. listing when we type “lsusb” now.
Our hardware guy says he has done same. wiring connections as yesterday where we could see “nvidia corporation…” for lsusb command.
We wanted this recovery mode (nvidia corporation listing with lsusb comand)so that we can try initrd flashing command and try to get the flash serial log. We are not able to proceed.
Any idea how to go about this?
Shall I try initird flashing command even without nvidia corp.and see If flashing proceeds? I will try it tmrw.
Just your thoughts on this.
As the default BSP linux package from NVidia website will be loaded and flshed on the orion NX developer kit SOM module, which also supports recovery mode and flashing, I expected some device tree changes/updates already in this file, but I cannot see any device tree changes in this .dtsi file for configuring usb2-port 0 for OTG mode.
1)Could you explain this discrepancy?
Hi,
Another clarification here
“Recovery mode” is totally a hardware triggered event. You put some jumper to make the board in recovery mode, it triggered some pin inside and make it to be a usb device mode “through hardware”. This process is for the first “bootloader flash” as my explanation. After bootloader flash is done, this recovery mode is gone.
But the “usb device mode” needed for initrd flash needs to be done by using software. That is why device tree configuration is needed.
which also supports recovery mode and flashing, I expected some device tree changes/updates already in this file
What file are you talking about? Our device tree supports OTG too but in a type C way. It has such code. Orin Nano/NX devkit supports OTG mode… if you don’t believe me, you could test devkit on your side too.
- Also in the below snippet from product design guide, it recommends we should configure it as Micro B type of USB.
But our hardware guy says Type A also fine. please confirm which is the correct one.
No, that is not correct. Have you ever seen there is someone use “type A” usb port to run as a usb device in your life? I guess not. All of them are all usb host mode…
Type A does not support OTG by its nature. Lacking of vbus_det pin and id pin.
hardware/nvidia/t23x/nv-public/tegra234-p3768-0000.dtsi
code snippet
79 ports {
80 /* recovery port */
81 usb2-0 {
82 mode = "otg";
83 vbus-supply = <&vdd_5v0_sys>;
84 status = "okay";
85 usb-role-switch;
86 };
87
hardware/nvidia/t23x/nv-public/nv-platform/tegra234-p3768-0000+p3767-xxxx-nv-common.dtsi
padctl@3520000 {
182 ports {
183 usb2-0 {
184 port {
185 typec_p0: endpoint {
186 remote-endpoint = <&fusb_p0>;
187 };
188 };
189 };
190 };
191 };
Understood. Thanks.
Sorry, I trust you. We dont have development kit here to test. So the final conclusion is USB2.0 port 0 of Type C is used for flashing in recovery mode. First half of the flash is using hardware type recovery mode, second type using device tree update software method.
So we can customize device tree for Type B as well as per product guide?
ok. We shall try out Type C or B
SOrry, I dont have host PC right now, so I cannot verify this device tree code in the BSP package I downloaded.
Is this the updated device tree code for developer kit? where OTG mode works fine.
I dont see any customization entry for TYype C or Type B ( any property entry in the device tree nodes above ) .
This is the device tree for the type C port on Orin NX/Nano devkit.
You need to refer to the previous document I shared and modify above to type B usb port…
xusb_padctl: padctl@3520000 {
…
ports {
usb2-0 {
…
connector {
compatible = “gpio-usb-b-connector”;
label = “micro-USB”;
type = “micro”;
vbus-gpio = <&gpio
TEGRA234_MAIN_GPIO(M, 3) GPIO_ACTIVE_LOW>;
id-gpio = <&gpio
TEGRA234_MAIN_GPIO(Q, 0) GPIO_ACTIVE_HIGH>;
};
…
};
};
…
};
Does this looks fine.
But I did not observe the connector node above for usb-c type.
Instead I see the below ctype node in the documentation link. Can you explain this variation with respect to type B and Type C customization while updating device tree…
typec@8 {
status = “okay”;
compatible = “cypress,cypd4226”;
firmware-name = “nvidia,jetson-agx-xavier”;
reg = <0x08>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA234_MAIN_GPIO(Y, 4) IRQ_TYPE_LEVEL_LOW>;
ccg_typec_con0: connector@0 {
compatible = “usb-c-connector”;
reg = <0>;
label = “USB-C”;
data-role = “host”;
};
ccg_typec_con1: connector@1 {
compatible = “usb-c-connector”;
reg = <1>;
label = “USB-C”;
data-role = “dual”;
port {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
hs_ucsi_ccg_p1: endpoint {
remote-endpoint = <&hs_typec_p1>;
};
};
port@1 {
reg = <1>;
ss_ucsi_ccg_p1: endpoint {
remote-endpoint = <&ss_typec_p1>;
};
};
};
};
};
You could read document first… That is why it exists. It has the explanation of how it works…
I have read 2 times already. What ever questions I am asking is after reading there only. But some things are not clear. Only those things I am asking here for clarity.
I feel, it not fully up to the mark.
It says
As I already told, this whole document is applicable for any kind of Orin platforms… It is talking about general rules for usb device tree…
You misunderstood it… This document note is talking about “this section is not part of device tree of Orin AGX devkit because Orin AGX devkit does not use this solution.” Orin AGX devkit is using Cypress Type C controller as solution…
If you want to make a micro USB port on your board, then you need to refer to this section …
ok
This more elaborate descriptions can help some new developers to understand sooner.
One more query;
I see a mentioning of usb-a-connector here, I understand it is talking about type.
for usb-b-connector the type=“micro”.
in case of usb-a-connector as mentioned above what should be the type value?
You had told usb-a-connector wont be applicable here earlier. Its mentioned here as just a type. please clarify.
Shouldn’t we be adding the below node as well, apart from the above two mentioned here . for USB2.0 Type C connector. kindly confirm.
You can just read the code of this user.
His device tree is correct in accordance with their schematic…
In the dmesg log I observe this line:
[ 109.629547] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 202405.0-ca7f3d9f-dirty 05/22/2024
but they have used customize carrier board for there design, then this line AGX Orion Developer Kit should not appear in the dmesg log. Any justification for this?
I am not sure why you always focus on so many unrelated things…
This is just a string. If this user didn’t change it for their custom board, then it will be the original one as the devkit… because no one really write a device tree from scratch… they use NV device tree as template.
You are using a custom board on your side too. But if you didn’t change the string, its name will be same as devkit too…
I won’t be able to guide you like from the beginning how a device tree works here as this is Linux kernel things… you better reading some other online resources on the Internet first…
Sorry. I was trying to understand it much better. As things are very complex in NvIdia here and might many things are related in one way or the other.
Coming to device tree, I have basic idea of device tree and it usage. Already I have completed on project based on Jetson AGX Xavier Industrial where I customized audio codec sgtl5000 and brought up the audio sound functionality successfully.
Now, I have almost understood how to update device tree for our customized board for flashing port USB2.0 - port 0 which can be either micro USB or Type C. Thanks.
once our hardware guy fixes the recovery mode issue using hardware connection, I will try my flashing script with the updated device tree(DTB) for micro USB or type C( which ever hardware guy finalizes). Thanks.
I already see these changes in the device tree files…in the BSP package downloaded from nvidia website…
So I will try flashing and it should work straight away
It won’t work straight away. If it already worked in the beginning, you wouldn’t have filed this topic and asked…
You should study and figure out each meaning in the usb device tree and dig into each node.
For example, that fusb_p0 definitely not work on your side/custom board.
