sdkmanager 0.9.9 flash AGX failed

Dear davyhuang,
As per the logs, it seems you are able to flash successfully. Please let us know if you have any other issues

Dear SivaRamaKrishna,

I suffered from this issue today as well, and tested various Ubuntu 16.04 Distro.
From 16.04.1 to 16.04.5.

Testing of every Distro as follows:

  1. Install ubuntu newly
  2. install NVIDIA driver (410.93 on GFX 1060)
  3. install sdkmanager (0.9.9-2351)
  4. Run sdkmanager

As I tested, all Distro. returned faults to install Drive SW.
However, only one, 16.04.3 (4.13.0-36 kernel) could succeed PARTIALLY.
It means ‘Flash Xavier-A’ and ‘Flash Xavier-B’ each other.
‘Flash Xavier A+B’ never done.

And next, even OS installation, none like DriveWorks, DriveAV/AR/IX etc were installed.
Should I install them manually with dependency checks?

Some Error might be there in installation scripts?

Thanks,


updated

I have to add sth.
My desktop has the 8th gen Intel CPU, therefore, some old Distro. can not detect/install proper drivers like Ethernet.
Without Ethernet, sdkmanager is not able to run at first.
Without this condition, IMO, with older than 16.04.3 Distro. Installation job would operate well.

Thanks


updated

I tried to install DriveAV/AR/IX manually.
Manual commands as follow at deb packages /root/apt-repos;

$ sudo dpkg -i *.deb

However lots of dependency error occurred and failed.
Even GMSL sample application of DriveWorks does not work.
sample_drivenet works!

Should I back to the previous Drive SW?

Thanks,

In TegraA, it looks like the flashing script(bootburn.sh) is success, but no signal from HDMI on TegraA.

I checked the output message from the USB debug port by using the command below.

  • ./tcu_muxer ---> minicom -D /dev/pts/XXX(XXX is GUEST OS)

The output message is stopped suddenly (input too).
The stopped point is different every time.

The log is attached:

  • bootburn_script_tegraA.log is output of bootburn script.
  • dmesg.log is output of dmesg command.
  • minicom_usb_debug_port_tegraA.log is output of USB debug port.

In contrast, In TegraB, The flashing script is success, and HDMI output to the display is OK.

I don’t know why the flashing is success on TegraB and fail on TegraA.

Thanks.
bootburn_script_tegraA.log (47.9 KB)
dmesg.log (100 KB)
minicom_usb_debug_tegraA.log (35.1 KB)

Dear astutaka,
Can you try flashing Xavier A again as davyhuang is able to succeed in second attempt after flashing Tegra B. Let us know if you still have issue

Dear SivaRamaKrishna,

I have already tested it, but have the same issue.

Thanks.

Dear SivaRamaKrishna,

I update what I did after #22.

I tried to run sdkmanager again to the target with ‘Flash Xavier-A+B’ and made it!
Target looks clear and made sure Xavier A and B boot properly, Aurix FW(V5.0.13-E3550-EB-xxx) as well.
DriveAV/AR/IX are installed as expected, even not tested yet.

However, this time, GMSL camera example does not work, same with #22.
To test I use SF3325 included in the accessory box.

I attach error log here.
Thanks,
err_cam1.log (1.79 KB)

Dear ddpx2,
Just to confirm, are you able to flash Xavier A+B in parallel via SDKmanager? or you flashed each xavier at a time?
Could you double check if camera connected to A0 port? The error looks like you have not connected camera to A0 port.

SivaRamaKrishna,

Firstly, flashed each other through sdkmanager.
But, here, I’ve got some problems that some packages were not installed and did something by manual. Therefore, file system might have been changed.
Then I tried to install again via sdkmanager, at this step, only flashing directly.
That’s all. some DriveAV example is running.

GMSL camera, you’re right! My Mistake it is.

Thanks

Dear astuka,
It seems other folks are able to succeed if they flash Tegras one after the other. Could you let us know the aurix version?

Dear SivaRamaKrishna,

The aurix version is below.

Info: Executing cmd: version, argc: 0, args:
SW Version: DRIVE-V5.0.13-E3550-EB-Aurix-With3LSS-3.01.05
Compilation date: Nov 12 2018, 11:33:03

I have another one.
I have flashed it by using sdkManager, and everything is OK.
There is a difference of HW only.(Host PC, USB cable, harness cable, power supply are the same.)

I would be grateful if you could tell about any information we should check.
Any information would greatly help.

Thanks.


updated

I have changed to the aurix version below and am testing, but occur the same issue at the moment…

shell> version
Info: Executing cmd: version, argc: 0, args:
SW Version: DRIVE-V5.0.13-E3550-EB-Aurix-ForHyperion-3.01.05
Compilation date: Nov 12 2018, 12:50:16
Command Executed
shell>

Thanks.

Dear atsutaka,
Could you share all logs of your recent attempt.

Dear SivaRamaKrishna,

The logs on the recent attempt is attached.

  • bootburn_script_tegraA.log is output of bootburn script.
  • SDKM_logs_DRIVE_Software_8.0_Linux_for_DRIVE_AGX_Developer_Kit_02142019_1107.zip is outpu of sdkmanager(parallel flasshing)

I still have the same issue.

bootburn_script_tegraA.log (47.7 KB)
SDKM_logs_DRIVE_Software_8.0_Linux_for_DRIVE_AGX_Developer_Kit_02142019_1107.zip (717 KB)

Dear atsutaka,

Thank you for your prompt update.
Sorry for the inconvenience, I would like to ask you one more thing.
We need some more data for this issue.
I would appreciate it if you get the log in the following way and share it.

-. Identifying USB device for TegraA and TegraB.

  1. Remove all USB cables connected to the host system
  2. List all ttyUSB and confirm nothing available "ls -la /dev/ttyUSB*”
  3. Connect Target to host, make sure you connect only Tegra board
  4. Confirm 16 ttyUSB devices are listed.“ls -la /dev/ttyUSB*”
  5. The following are the Target ports for
  • Aurix - /dev/ttyUSB3
  • TegraA - /dev/ttyUSB2
  • TegraB - /dev/ttyUSB6

Please get Target kernel logs using minicom/screen.

  • Issue "tegrarecovery x1 off"
  • Connect to TegraA
  • "tegrareset x1"
  • capture OS start on TegraA logs.
  • Dear SteveNV,

    Thanks for your reply.
    The logs are attached.

    • minicom_aurix_on_ddpx.log is output of aurix.
    • minicom_tegraA_on_ddpx.log is output of tegraA.

    -. Identifying USB device for TegraA and TegraB.(1~5)
    —> I have confirmed the above.

    As I mentioned in “#25 Posted 02/12/2019 05:53 AM”, the output message from TegraA is stopped suddenly.
    The stopped point is different every time.

    Thanks.
    minicom_aurix_on_ddpx.log (465 Bytes)
    minicom_tegraA_on_ddpx.log (7.86 KB)

    Dear SteveNV,

    Like Atsutaka we also have problems with flashing the drive. We made a separate forum post, but there we have not received any repsonse yet. My team and I would like to know if there is a solution or more information about the problem. In the post we will add a bootcapture of Tegra-A and Tegra-B when booting both devices with the AURIX.

    I hope we can find a solution.

    Dear GEntius,

    Sorry for late reply.
    Currently we are checking the log now and we will update you as we find solutions to your issue. Thanks.

    Hi SteveNV,

    Thank you for your quick repsonse. I forgot to add the link [url]https://devtalk.nvidia.com/default/topic/1047538/drive-agx/no-hdmi-signal-from-xavier-a/[/url] to the original post. Don’t forget to check the newest log files.

    Dear SteveNV,

    Have you found anything useful in the logs files yet? Is there more information regarding the problems with flashing?

    Thanks

    Dear GEntius,

    The logs “minicom_tegraA_on_ddpx.log” show the kernel boot has stopped.
    This is Tegra boot with recovery off, not flashing kernel boot logs (i.e., during flashing with recovery on).
    So is it fair to summarize as follows.

    1. User flashed successfully TegraA
    2. switched off TegraA recovery (tegrarecovery x1 off) and reset TegraA
      3.captured the TegraA logs.

    Could you please update the current status on this target and about the TegraA logs attached?

    Hi GEntius,

    We have just released a Tech Bulletin “LINUX KERNEL UPGRADE CAUSES FLASHING ERRORS”. Please check that out.

    So please up- or downgrade your kernel to 4.15.0-43 and make sure you are

    1. running Xenial Linux since we do not support company ones and
    2. you are not blocked by a firewall so that you have setup correct proxy settings.

    We have reasons to assume your custom Linux is not compatible with our package as you are running Linux Quintor that is not a Canonical one.

    Fabian