Xavier nx flash jp5.1.2 image error by using physical server machine DELL PowerEdge R740

Hi nv team,
we release xavier nx/jp5.1.2 image. and local verification is successful by notebook computer thinkpad T14 on u20.04.
But the terminal customer use server machine as host, and flash error using the same jp5.1.2 image.

We check the host machine: U20.04, x86_64 arch, Intel Xeon cpu.
there is no obvious difference, compared with notebook pc.

by serial console log, there are some mistakes:
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.0# [ 38.005151] vdd-1v8-sd: disabling

Can the server machine be used as host?
how to fix this customer issue…

1、the flash cmd:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --massflash 2 --network usb0
2、serial console log:
uart.log (76.0 KB)

3、R740 env info:

by the way, the R740 host can flash jp4.6 image successfully.
and the corresponding command is:
sudo ./nvmflash --showlogs

I can’t answer, and someone else will need to comment. I do want to add some information.

Most drivers have some form of “file” access (in *NIX/Linux you often hear “everything is a file”). When the file interface for things like read and write is not sufficient the driver has an I/O control call added, which is the ioctl() function. The functions are all custom to that specific driver, and use an indexed number. The typical reason for “inappropriate ioctl for device” is that something has attempted to control the driver of a device using the ioctl() call of a different driver. A good example is that perhaps two different manufacturers create two devices which do the same thing, but they use their separate drivers, and someone might apply a feature or setting that either (A) exists only on one of them, or (B) exists, but uses a different index.

Something running in a bash script seems to be setting up a driver for a given function which uses a different driver than the working machine.

I don’t know though which driver it is. I see some log lines related to the power rails, so maybe this is the driver. I’m thinking that your flashes might not be flashing the same thing, but perhaps not in the way you are thinking.

Is your Xavier NX a separate commercial module on a third party carrier board? If it is, then the device tree will change (unless that carrier board is an exact electrical layout match to the dev kit). Is it an eMMC model, or is it an SD card model (it’d have to be a dev kit if it is an SD card model; we are not counting SD cards on the carrier board…an SD card model dev kit mounts the SD card on the module itself, and that format of module is not available for separate use).

Each module does have separate QSPI memory on it, plus for eMMC models, the eMMC. Jetsons don’t have an actual BIOS, instead they have software which performs the same function, and this is part of each full flash. When flashing an image it is a mistake to flash that image without having flashed the correct “other” content, and I’m thinking maybe the “other” content is different at the customer end. The correct “other” content depends on the model, and whether it gets that content depends on the flash.

using PC host, the customer already evade this flash issue.
so be it.

There are some problems here to clarify first

  1. Your UART log got truncated in each line… so information is not completed. Please dump the log again with your terminal resize… Read the log before you sharing it out…

  2. You better sharing the full UART log and host log during flash process…

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.