Nvidia boot logo on Nvdia jetson nano 2gb

Hello, i hope u r doing well
after flashing the Nvidia Jetson nano 2gb dev kit, i can not update the boot logo.
i got two types of jetson nano, one type already got display on hdmi with Nvidia logo, i have changed the boot logo very easily following the mentioned steps on those type of kits
and other type of Jetson nano i receved didnt have display for that you mentioned to Flash it and it worked but on that jetson nano’s (23 pieces) boot logo is not updating and it results in no display when connected again with the screen ( i mean display drivers are again corrupted for some reason)
please guide how to fix and update the boot logo with my own
thank you

@WayneWWW so in my previous post you asked me to dump logs via serial. Here is the issue that we ran into.
After our try to update the NVIDIA Boot Logo, our Jetsons can’t output anything via any peripheral port or serial port. Here are the steps we followed and checked:

  1. Tried to connect serial via minicom, GND, TX Read and TX Send to TTYUSB but nothing displayed in minicom terminal (as opposed to a recently Jetpacked Jetson nano which works fine on Serial ports).
  2. Tried an external display ( Portable LCD powers through USB and HDMI our Jetson in our normal usecase) doesn’t display anything (as opposed to recently Jetpacked nano displaying output on that screen).

So, we can’t provide any dump logs. We treid updating logos on 3 nanos but all three display same behaviour.
Note: When FRC and GND are shorted and Nano is connected to J13 to connect to SDKMANAGER, they does show up there . So how can J13 work but not J9, J10 and J4 and guide us if and how can we dump some logs for your curious mind.

Hi,

Serial UART pin can dump log in every situation except recovery mode (it will print log after you start flash process).

I think it is just you don’t have enough experience to dump log. Please practice it on a fine module which can boot up fine first.

Are your J9, J10, J4 indicating below? Of course they will not output things as your board looks stuck somewhere during boot.

As my previous comment, it is more like you are not familiar with jetson yet. Please only focus on the uart pin. Your log won’t come from J13, J4, J9,J10. It will only come out on the UART serial debug pin.

@WayneWWW Yes we know the logs won’t come from J13, J4 and J10.
All we did was connected 3 nano on serial using either J12 Header or J6 Header.
We connected to minicom using both these headers individually one at a time (used J6 pins 2 times and then choose J12 pins for next two times) but these 3 nano won’t show anything on Serial Monitor however other boards do output on serial console.

So if we don’t see these nanos on serial monitor, do we assume they are in recover mode? (because if they are not dumping logs on serial monitor which can always dump log but in recovery mode as you said) Is there any other way to check for it? If yes, do state. If No, do we have to Flash these 3 nano again?

Hi,

I think you can try below test

  1. Flash one of the 3 modules again. Always read the log from the serial console. Do not disable it. Just keep monitoring them.

  2. Do your update steps to update the boot logo (your should still have serial console enabled).

  3. No matter it fails or successfully or not. Share the both the host side log and device side (aka your serial log) of the whole process.

You should only use J12 to dump log.

@WayneWWW Thankyou for your continued help. Will try out the steps you mentioned. I do have another question that may help us in the later steps. Is there a specific Version of Jetpack to be installed on NANO in order to replace the logo blob file?
Our current Jetpack version that was 4.6.4
Should we go again with this version or use different JP Version?
Thanks in advance

No, no need to try other version of Jetpack. I only need log file for current situation.

Changing the jetpack version will just make situation more complicated. So no need to do that for now.

Roger that. Will continue with 4.6.4 for now and will provide you wit logs.

One more question, can I concurrently flash via SDK and get logs from Serial at the same time? Is this the scenario we are running first?

Or for Step 1) i-e reflashing, logs from SDK console are enough?
@WayneWWW

Untitled 1.odt (29.4 KB)

this is the log from the SDK manager during flashing
and now i will change the boot logo and share its result

@mohiz.ahmad

This Untitled 1.odt does not help. It is a meaningless log…

Please export the log from sdkmanager by clicking the “export logs” button from your SDKM… Also, where is the UART log ?

The sdkmanager log shall be as this link.

You shall share a zip file here. Not just a 29.4KB file …

@WayneWWW
SDKM_logs_JetPack_4.6.4_Linux_for_Jetson_Nano_modules_2023-07-25_15-50-07.zip (107.1 KB)
Here are the console logs exported from Terminal.

I am still not sure how to acquire the Serial Logs when nothing is showing up there.

I think we need to reflash second nano, while it is connected to UART and then we flash it to acquire the serial logs as well. Am I right in assuming that?

Also, here is our terminal when we try to update the logo blob.
terminalLogs.txt (13.1 KB)

Do let me know if we have to reflash and then we can get you serial + zip logs from SDK

Hi @mohiz.ahmad

I think the problem here is you are not using a proper way to dump the serial console log.

For example, when you ran sdkmanager to flash, you shall see serial console print something. Also, when you try to update cboot logo, when it starts to flash, you shall see log from serial console too.

If you see nothing from it, please share me a photo of how is the exact connection of the cable to your carrier board and how is the software you are using on your host PC to dump such log.

You only need to do it with one jetson nano and one host PC. You don’t need any “second nano” to do with that.

Just a reminder that, what you dumped in this comment was correct. Such log is UART log. You shall see it in flash process too.

@WayneWWW here are flash logs from SDK and minicom (cap file).
The UART was on during the flashing process and you can check logs for it here
jetson.cap (30.5 KB)
SDKM_logs_JetPack_4.6.4_Linux_for_Jetson_Nano_modules_2023-07-25_21-36-09.zip (126.5 KB)

Will do the splash screen change as well and then provide you with those logs as well

Great. The log looks correct now.

Waiting for your update for the splash update part.

@WayneWWW so here is the part where flashing happens.
The text file represents terminal logs which are displayed on terminal while flashing the splash screen blob and minicom .cap file which ends with some gibberish when we disconnected nano (nano was stuck in Flashing line and no new UART message was being shown so we disconnected, hence the gibberish at the end)
The nano was stuck on Flashing part for quiet a while and then we disconnected it.
terminalLogs.txt (13.6 KB)
splash1.cap (7.4 KB)

Hi @mohiz.ahmad

This log looks correct too. Then the problem is what is the uart log after this flash is done?

Have you removed the jumper, restart the board and check the UART log there?

@WayneWWW Yes. Once we get The [BMP] has been updated successfully. in the terminal, UART’s last response was [0022.414] Flushing data to stroage

We waited for new response for 15 mins, nothing showed up, then we removed jumpers and restarted nano but nothing was being received in the minicom terminal after that and even now there is nothing on UART