JetPack 4.4 will not flash on custom board

Autonomous Machines Jetson & Embedded Systems Jetson TX2
5

My bad, I was watching the serial console the whole time, and missed it. Logging it and looking at it now, I see this error:

[0360.200] E> Waypoint-0.5 ACK pending: 0x8
[0360.204] C> MTS error (2) : dram alias check failure
[0360.209] C> cpu waypoint 0.5 failed
[0360.212] C> ERROR: Highest Layer Module = 0x32, Lowest Layer Module = 0x32,
Aux Info = 0x1, Reason = 0x6
[0000.280] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-mobile-7d3edb9d)

And then it goes into a regular boot, back into Jetpack 4.3.

6

Hi,

And then it goes into a regular boot, back into Jetpack 4.3.

What did you see when you do flash? I don’t get what do you want to say here. Why does flash failure would go to regular boot?

7

What I’m saying is that the flash never happens. The flash.sh goes through making system.img, adding binary blob to blob.bin, etc. Once it goes to start sending stuff to the bootloader the reset happens. Nothing ever gets written.

The device already has 4.3 on it, which is why it is able to boot back into the existing OS.

8

Could you paste the full flash log?

If this only happens to Orbitty board + jetpack4.4, maybe need to consult with them directly…

9

Sure, here is the full flash log
orbitty_flash.log.gz (5.1 KB)

10

Hi,

I meant the full log of uart…

12

Hi,

If you can please contact us directly via our support form and we can help you get up and running:

Regards,

-Rob

1 Like
13

Though Rob has been here, I still share what I want to check.

  1. In previous comment, you already shared some log from serial console, so I assume you can dump log from this carrier board.

[0360.200] E> Waypoint-0.5 ACK pending: 0x8
[0360.204] C> MTS error (2) : dram alias check failure
[0360.209] C> cpu waypoint 0.5 failed
[0360.212] C> ERROR: Highest Layer Module = 0x32, Lowest Layer Module = 0x32,
Aux Info = 0x1, Reason = 0x6
[0000.280] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-mobile-7d3edb9d)

  1. Based on (1), we need the serial console log when you running the flash command.
    When you press the command “sudo ./flash.sh …”, the host will sends some binary to the device through usb cable. During that time, UART should dump some log too. That is what we need to check for flashing issue.
14

Here you go Wayne:
uart_out.log.gz (5.5 KB)

15

Hi chadiris,

Is there any log prior to/ before this part?

[0507.764] E> Waypoint-0.5 ACK pending: 0x8
[0507.768] C> MTS error (2) : dram alias check failure
[0507.773] C> cpu waypoint 0.5 failed
[0507.777] C> ERROR: Highest Layer Module = 0x32, Lowest Layer Module = 0x32,
Aux Info = 0x1, Reason = 0x6

The timestamp has reached 507 at this log. It means it should be at least 8~9 mins logs are disappeared.

16

No there is not. I put the device into recovery mode, and then type the sudo ./flash.sh ... command. There is some time while flash.sh builds everything, which I think explains the time lapse - there is no output until it starts sending the first blob.

It usually doesn’t take 8~9 minutes (third post in this thread shows about ~6), so there may have been a slight delay between when I put in recovery mode and when the first blob was sent.

17

I should add that I don’t have serial pin outs on this custom board, so I’m accessing the serial port over micro USB.

18

I reflashed with 4.3, and then tried to do an OTA update to 4.4 as described in the docs:

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fquick_start.html%23wwpID0E0EB0HA

It appears to install OK, but upon reboot it bails with three lines:

[0001.872] C> MTS error (2) : dram alias check failure
[0001.877] C> cpu waypoint 0.5 failed
[0001.880] C> ERROR: Highest Layer Module = 0x32, Lowest Layer Module = 0x32,
Aux Info = 0x1, Reason = 0x6

And then stops. (Interestingly is the same lines that pop up when 4.4 flash fails).

I can reflash with 4.3 again to get the device back into a healthy state.

Not sure what to try next.

19

Do you have nv devkit to verify this issue only happens to cti carrier board?

20

Yes, I’ve been able to flash TX2 developer kits with 4.4 without issue.

21

In your method to OTA upgrade to 4.4, I am also wondering if you can move the module which you cannot boot on cti board to devkit. Will it boot successfully?

I mean:

  1. OTA upgrade from 4.3 to 4.4 on cti board → installation should be okay but cannot boot up

  2. Power off the board and move this module directly to devkit and boot up → will it boot up fine?

22

Yes, it did, interestingly enough. It booted up and I am logged into it (on the dev board) and everything looks fine.

I’m perplexed as to what is so significantly different with 4.4 that would cause this incompatibility with the custom board.

24

I did discover something interesting - the board will boot under 4.4 when the USB cable is disconnected. So this eliminates being able to flash 4.4, as the cable is required for the flashing process.

However, when I attempt the OTA upgrade (flash 4.3, then OTA from 4.3 → 4.4), I had previously stated that the flash worked, but it wouldn’t boot into 4.4 after I issued the reboot command. This is because I had the micro USB cable still connected so that I could monitor the UART. If I disconnect this cable, it boots just fine.

So 4.4 won’t boot with the micro USB cable connected to this board (and it would on previously releases)

25

I’m seeing a very similar issue in Dram alias check failure on D00 revision TX2 SOM and custom carrier board - #15 by danwalkes1 however I’ve only noticed when using rev D00 SOMs, and in my case unplugging the USB connection isn’t helping to resolve.

27