Getting flashing error using initrd.sh on JP 6.0 for orion NX on external 16 GB NVMe

I found out later that the flash initrd.sh command:

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p “-c ./bootloader/generic/cfg/flash_t234_qspi.xml” -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit nvme0n1p

that I gave earlier was slightly wrong.
It should have been as shown below:

Here it says fusb_p0 is used for Orion Nano,so I assume its same for orion NX 16GB.
my hardware guy says, he has not used any usb controller on the carrier board so I assume its present inbuilt on the SOM side.
Please confim.

This thing is not on SOM…

The document is talking about the situation on NV devkit carrier board…
Your hardware guy is talking about your own custom board.

These two things are totally unrelated.

Could you really let your hardware folks join the reading of the document first because I think he/she would know more about the hardware than you…

Also, did your hardware folk know there is the schematic of Orin Nano devkit on the download center? I think he/she could start from reading that first… If he/she read, then such question won’t be asked…

1 Like

hardware guy says he has directly done the connections as per the schematics and not using any controller so its understood for me that it should of micro USB type B.
So as per my understanding I would be going through the below changes in device tree ruling out USB3.X / Type C connectors:

ports {
80 /* recovery port */
81 usb2-0 {
82 mode = “otg”;
83 vbus-supply = <&vdd_5v0_sys>;
84 status = “okay”;
85 usb-role-switch;
86 };

padctl@3520000 {
182 ports {
183 usb2-0 {
184 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>;
};
188 };
189 };
190 };

Also In the PIN MUX sheet, I am not able to find out GPIO-port*Q,0 and GPIO-portM,3 by searching. Could you help me finding it.I want to confirm, if these pins are freely available and not used for some other functionality.

Your image is not attached. Not sure what you want.

wanted to confirm if GPIO pins are freely available and not used for any special purpose functionality, so that I can use them in my device tree for “device mode” configuration.

Actually your understanding of this whole situation is still unclear…

hardware guy says he has directly dont the connections as per the schematics and not using any controller so its understood for me that it should of micro USB type B.

I don’t see any reason this comment would lead to a conclusion " it should of micro USB type B.". Actually, totally don’t know what you are talking about . What schematic is this?

wanted to confirm if GPIO pins are freely available and not used for any special purpose functionality

It feels like your communication with your hardware guy is like a communication between two strangers… You should not use “as my understanding”. Go to ask your hardware guy what is the exact design he is doing. If this is micro usb, then he should tell you this is micro usb directly but not let you guess…

Also, the GPIO question is weird too. This should be a question from your hardware guy. But not “I want to use it in my device tree”. If hardware guy didn’t use them, then what is the meaning you write it in the device tree?

This whole discussion for now is not something for a software engineer to do… it should be hardware engineer to finalize the design…
After he finalized the design, he should tell you what software field to use… for example, which GPIO is for vbus_det and which one is for ID pin…

Pls find the UART log. We are not able to flash successfully again even after updating device tree.
Kindly let us know what could be the issue.

uart_console_flashing_error.txt (94.9 KB)

Device tree changes done as shown below for USB micro B type , in the file tegra234-p3768-0000.dtsi inside nv-public directory:

:
> ports {

  		/* recovery port */
  		usb2-0 {
  			mode = "otg";
  			vbus-supply = <&vdd_5v0_sys>;
  			status = "okay";
  			usb-role-switch;
  			//Trident changes start
  			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>;
  			};
  				//Trident changes end
  		};

This error is not related to usb device tree… just you need to disable CVB eeprom because custom board may not have such design…

https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html?highlight=cvb_eeprom_read_size#mb2-configuration-changes

we are getting this below error after updating the above EEPROM fix in device tree file.

Note: We built only the DTB files. Hope this is enough and building kernel source, out of tree modules are not required each time, we change device tree files.

root@trident-B660M-AORUS-PRO-AX-DDR4:/home/trident/Downloads/r36_3_0/Linux_for_Tegra# sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit internal
/home/trident/Downloads/r36_3_0/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --external-device nvme0n1p1 -p -c bootloader/generic/cfg/flash_t234_qspi.xml -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit internal


  •                              *
    
  • Step 1: Generate flash packages *
  •                              *
    

Create folder to store images to flash
Generate image for internal storage devices
Generate images to be flashed
ADDITIONAL_DTB_OVERLAY=“” /home/trident/Downloads/r36_3_0/Linux_for_Tegra/flash.sh --no-flash --sign -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal

###############################################################################

L4T BSP Information:

R36 , REVISION: 3.0

User release: 0.0

###############################################################################
ECID is
Board ID() version() sku() revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()
emc_opt_disable_fuse:(0)
Error: Unrecognized module SKU
Error: failed to generate images
Cleaning up…

What did you change? I don’t think you follow the document…

I did below changes:

cvb_eeprom_read_size = <0x0>

eeprom {
cvm_eeprom_i2c_instance = <0>;
cvm_eeprom_i2c_slave_address = <0xa0>;
cvm_eeprom_read_size = <0x100>;
cvb_eeprom_i2c_instance = <0x0>;
cvb_eeprom_i2c_slave_address = <0xac>;
//cvb_eeprom_read_size = <0x100>;
//Trident changes
cvb_eeprom_read_size = <0x0>;
};

Please put the board into recovery mode correctly and flash again… also see if any uart log there…

BTW, this change should be applied in the beginning. It is totally independent of the original issue…

we restarted the unit and the unit is in recovery mode.

we dont any uart log, because flashing is failing at the first stage immediately only as shown below:

root@trident-B660M-AORUS-PRO-AX-DDR4:/home/trident/Downloads/r36_3_0/Linux_for_Tegra# sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit internal
/home/trident/Downloads/r36_3_0/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --external-device nvme0n1p1 -p -c bootloader/generic/cfg/flash_t234_qspi.xml -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit internal


  •                              *
    
  • Step 1: Generate flash packages *
  •                              *
    

Create folder to store images to flash
Generate image for internal storage devices
Generate images to be flashed
ADDITIONAL_DTB_OVERLAY=“” /home/trident/Downloads/r36_3_0/Linux_for_Tegra/flash.sh --no-flash --sign -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal

###############################################################################

L4T BSP Information:

R36 , REVISION: 3.0

User release: 0.0

###############################################################################
ECID is
Board ID() version() sku() revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()
emc_opt_disable_fuse:(0)
Error: Unrecognized module SKU
Error: failed to generate images
Cleaning up…
root@trident-B660M-AORUS-PRO-AX-DDR4:/home/trident/Downloads/r36_3_0/Linux_for_Tegra# sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network usb0 jetson-orin-nano-devkit internal
/home/trident/Downloads/r36_3_0/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p -c bootloader/generic/cfg/flash_t234_qspi.xml --showlogs --network usb0 jetson-orin-nano-devkit internal


  •                              *
    
  • Step 1: Generate flash packages *
  •                              *
    

Create folder to store images to flash
Generate image for internal storage devices
Generate images to be flashed
ADDITIONAL_DTB_OVERLAY=“” /home/trident/Downloads/r36_3_0/Linux_for_Tegra/flash.sh --no-flash --sign -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal

###############################################################################

L4T BSP Information:

R36 , REVISION: 3.0

User release: 0.0

###############################################################################
ECID is
Board ID() version() sku() revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()
emc_opt_disable_fuse:(0)
Error: Unrecognized module SKU
Error: failed to generate images
Cleaning up…

what do you mean by begining here?

should I do complete kernel source build, out of tree modules build, dtbs build etc and do flashing after that??

All custom boards have the nature that they don’t have EEPROM on it. Thus, it is a must-have change for all custom boards to have.

You are reporting a new issue which totally has nothing to do with usb device tree change.

Such patch (skip eeprom read) should be applied even in 6/5 when you filed this topic…

Do you have NV devkit that can cross check if this module is still fine?

ok… Understood and we have updated accordingly my making EEPROM size =0x0;

Yes. Pls tell solution for this new issue.

Yes.Understood,

We dont have dev kit. we have some more SOM modules, we can try on that.
I doubt it is issue with the SOM module.

Please file a new topic for this. I don’t think this is related to original topic.

This topic is only for discussing the initrd flash failed in USB device mode part.

1 Like

@nagesh_accord

Could you really just let your hardware engineer come here and comment?

Sorry to say that. I don’t really think you have ability to resolve and understand the situation here.

This topic indicates you cannot understand what yourself is doing …