Is there a change log for Note the "b"!


we want to build our own image for a B01 board. Unfortunately these are very unstable and there are hangups in the desktop when connected to HDMI. In the dmesg log there are mmu and nvgpu errors visible.

We see the same problems when using the “old”, official image.

Now there is a new image with a “b” inside the name which solves these issues (available e.g. from the getting started pages). Is there information or a change log available for this image? How can we build our own image similar to this new one?

I searched up and down but could not find any information about it.
Maybe related is the thread here HDMI was flicker on demo kit when running stress on gpu


Hi Tom,

We uploaded a new fresh file an added “b” to the file name is to ensures that no file could be cached for a workaround of resolving the downloading problem happened at China.
There is no different between them, they are all same R32.4.2 version, but package name.


What if you use the latest official sdcard image? What do you mean the “old” official sdcard image?

This is very strange. The files changed definitely for us. See the screenshot of my Chrome download log for what I downloaded. BTW, the access URL was which is linked in

-rw-r–r-- 1 tho tho 6348022895 Jul 2 21:48
-rw-r–r-- 1 tho tho 6347594220 Apr 24 11:37

$ sha256sum nv-jetson-nano-sd-card-image-r32.4.2*

If we use the current (latest) official sdcard image everything works fine. If we use the older one we get Hangups.

Unfortunately if we build our own image we get the same results as with the old image. We are using
-rw-r–r-- 1 tho tho 1318995013 Jun 16 19:34 Tegra_Linux_Sample-Root-Filesystem_R32.4.2_aarch64.tbz2
59abb16e0ef77337c914e3357057cef079828bde3efd6a390c20e98e21ceb884 Tegra_Linux_Sample-Root-Filesystem_R32.4.2_aarch64.tbz2

This seems to need some more investigation …


The latest official nano will have this md5sum value.


I can confirm that this is the md5sum of the I downloaded last week.

Still the question remains what did change between the older version and the current one. We need to build it from scratch and the official sources build an image which is similar to the old one.


I don’t think you need to care about what is the difference between new and old one. Please just use the latest one.

AFAIK, we had an immediate update on sdcard image because the gpu issue is fatal. Thus we abandoned your so-called “old” sdcard image and does not recommend any users to try it.

And there may not be only gpu issue got fixed. Unfortunately we don’t have a change log between these two images.

Thanks a lot. I think you are right. But I need to care as I am not able to build a stable image on my own. I need to get access to the updated kernel stuff.

I installed both images and did a diff on the package level.

The packages nvidia-l4t-kernel, nvidia-l4t-kernel-dtbs and nvidia-l4t-kernel-headers changed from 4.9.140-tegra-32.4.2-20200408182156 to 4.9.140-tegra-32.4.2-20200428140713.

Besides this only some python2.7 stuff (adding an ubuntu1 to the version) changed which I do not care about.

Can you find out and tell me what the difference in the kernel stuff is? According to;a=shortlog;h=refs/tags/tegra-l4t-r32.4.2 the last change was in March this year. The above dates indicate that there have been changes in April.

Please allow me one more question. As I need a stable image: does it make sense to go to r32.3.1? This is marked as latest production release, but does it run without problems on the B01 Jetson Nano boards? Or does it have the same problems as the “old” r32.4.2?
And if you advise to use r32.3.1 are the sources up to date with the image so I can build it on my own?
Final question about r32.3.1: where can I find the SD card image for it? I would like to do a quick check on my own.


Have you tried the kernel source already or not? IMO, if you build the kernel source code/ modules and it does not hit this gpu issue, then it is a good one. Just use this one directly. So far, we don’t get any report about gpu issue when using image built from kernel source.

If you are really worried about missing few patches here, then just fallback to rel-32.3.1 is also ok.

We tried the sources already and our build shows a gpu issue.This happened only with 50% of our B01 boards (and not with A02) and the symptoms we see are hangups and a crash of compiz when using HDMI/Keyboard/Mouse. Using the boards remotely seems to be fine but looking with dmesg shows a lot of errors. I assume not everybody really sees the problems.

So yes, we are worried about missing some patches. To be honest I am scared that NVIDA official sources do not match the official image. I really hope you fix this for the production release of 32.4.2

Of course there is a chance that we did something wrong. But how can we check this?

We will follow your recommendation to fallback to r32.3.1 for now. Thanks for this confirmation.


Unfortunately, we won’t fix this for rel-32.4.2 source code. Actually, we didn’t fix or update any source code tarball after the release. Not only for rel-32.4.2 but also for all the src tarballs on dlc.
We will only fix this in next release.

Also, rel-32.4.2 is just a developer preview. The next rel-32.4.3 will be a production release.

Good news. What is the planned release date for rel-32.4.3?

If the release is in the very near future and if we can build a working image from the sources, I am fine.

But I doubt it is legal to provide any binary image (e.g. without the matching sources. At least it is not helpful for the developers. Maybe you can improve on this in future.

Just for the records: I extracted the nvgpu.ko kernel module from the and replaced the one from the source build with it.
After this the hangups/errors were gone.

So it seems NVIDIA fixed the problem in the nvgpu driver.