I flashed the code to the Xavier Industrial P2888 on the custom carrier board using the command “sudo ./flash.sh jetson-agx-xavier-industrial-cti mmcblk0p1” with the new pinmux settings and right after the flash completed the Xavier works and I can able to display the ubuntu desktop from the DP0 and I could able to complete the ubuntu setup. However, when I reset / power cycle the Xavier I will get the Unhandled Exception in EL3 error at the UART log uart_error_log_reset after flashed…txt (6.3 KB)
(see attach) and it hangs. What is this error mean and what cause this error?
We are using JetPack 4.6.1 to flash code to the Xavier and we design the custom board based on the P2822_B03 Jetson Xavier Developer Kit Carrier Board schematic with some modification. I would like to know what this error mean and where should I check for this error?
I am assuming it is the ARMv8-a core 0 with that error, but I suppose it is possible the error came from some other boot control processor (doubtful, but I don’t know enough to say for sure).
I’ll be curious to find out what the cause was when it is solved. Unless something needs signing or does not flash correctly (resulting in a corruption somewhere which requires a signature), and since you used default flash, it is more unusual.
We design and build the carrier board. Our company is Cornet Technology. Inc. Now i am checking the power up and power down sequence and we are using power button supervisor MCU with auto power on case.
Hello I am with Cornet working on the same project as klaml3o9. I am trying to build the UEFI on linux Ubuntu system and I get the following errors pasted at the end.
I following the guidelines to install mono and updated the images but I still get the error. Could you help me get over this hump . Do you think it is better to compile the UEFI on windows since the NuGet tool is inherently windows.
SECTION - Initial update of environment
UpdatingWARNING - [SDE] Failed to fetch NugetDependecy: firstname.lastname@example.org: [Nuget] We failed to install this version 20200717.0.0 of edk2-acpica-iasl
WARNING - [SDE] Failed to fetch NugetDependecy: email@example.com: [Nuget] We failed to install this version 2.15.05 of mu_nasm
SECTION - Second pass update of environment
UpdatingWARNING - [SDE] Failed to fetch NugetDependecy: firstname.lastname@example.org: [Nuget] We failed to install this version 2.15.05 of mu_nasm
.WARNING - [SDE] Failed to fetch NugetDependecy: email@example.com: [Nuget] We failed to install this version 20200717.0.0 of edk2-acpica-iasl
ERROR - We were unable to successfully update 2 dependencies in environment
SECTION - Summary
Instead of just uploading the debug uefi using the flash command. I reflash the whole system.img which included the debug uefi. After it reflashed and I power cycled it, the logs on the serial output are stored in the file.
Post the crash stage. I ran the command
sudo ./flash.sh -r -k BCT jetson-agx-xavier-industrial-cti mmcblk0p1
and the system will come up. This time the UEFI spits out a lot of debug information
PROGRESS CODE: V03051005 I0
PROGRESS CODE: V03050000 I0
Deleting fragment fragment@0
Deleting fragment fragment@1
So it looks like the UEFI debug version does work (I had tried to just flash the uefi and that did not seem to work).
From the logs it looks like what you had deduced before i.e it is not hitting the UEFI is correct. What else could it be ? How do we approach this issue. This seems to happen very consistently if we power cycle.
The current logs are the correct one with UEFI debug enabled (that is using the uefi image from user100090). I can confirm that it is a debug uefi is because I see a lot of extra debug messages with the UEFI when it does come up correctly. After I power cycle it goes into the crash mode which is there in the logs. I do not see any of the debug message which tells me that the UEFI has not been entered.
Unfortunately we do not have a devkit for the xavier. We only have one for orin (which will be custom made in the future). The custom boards we have are all xavier. Would you be able to request the hardware folks to see if they have any suggestions.
The other question we had was when the flash.sh is run with partition BCT what does it do and why running that seems to fix the situation. Just running the flash.sh for BCT partition (which is much quicker than the whole image) seems to fix the crash issue. Is there any correlation between power outage and the BCT area loosing information ?