JetPack 4.4 Developer Preview - L4T R32.4.2 released

The same steps! and after many trys I can see the desktop but for few minutes, because the graphical interface don’t respond at any command, keyboard and mouse get stuck.
I press Atl+2 and can go to console mode and I see that the graphical interface had many erros logged.

I tried that, it was a handful of so files it complained about. But after I fixed the soft links it instead gave segmentation fault as soon as I did the import command in python.

You don’t burn that image, you unzip that file and you get something like

sd-blob-b01.img

burn this image with etcher. it worked on Mac OSX 10.15.3. Nano booted no problems

hmm, sounds like build from source is needed or check to see if the base lib is something like

libcudart.so

create soft links to this lib instead of libcudart.so.10

Akshually, I believe Etcher supports writing from zip, but you’re right it will certainly fail with many other image writing solutions.

Hi @guzzzt, install the PyTorch for JetPack 4.4 DP from here: PyTorch for Jetson Nano - version 1.5.0 now available

1 Like

Hai egarciag,

The default link is https://developer.nvidia.com/jetson-nano-sd-card-image - this got me nv-jetson-nano-sd-card-image-r32.4.2 (with the sluggish behaviour and nvgpu errors).

For now I am using the earlier nv-jetson-nano-sd-card-image-r32.3.1 from the Jetpack 4.3 page, i.e. at https://developer.nvidia.com/jetson-nano-sd-card-imager-3231.

Regards,

Hi Alexander_1 !,

You have reason, I unpacked the image “nv-jetson-nano-sd-card-image-r32.4.2” and burn the file sd-blob-b01.img, it work finally without any problem.
Thanks for your info!

1 Like

Hi meerbartj,

Finally I can burn the image “nv-jetson-nano-sd-card-image-r32.4.2”, @Alexander_1, suggest unpack the archive and burn the file “sd-blob-b01.img” and it work without any problem, the graphical interface never crash, I burn en three diferent SD Card and no problem.

Thanks for your info.

BR!

1 Like

For the gpu issue that causes the system slow, you could apply this patch to the kernel.

Does anyone have a very lean kernel config? I want all of the unused drivers and bloat disabled.

I tried to burn the unzipped “nv-jetson-nano-sd-card-image-r32.4.2” image, i.e. sd-blob-b01.img, but experienced the same symptoms: graphics freezing already during the installation steps.

I downloaded the nano image fresh (2020-05-11); with this binary the problem seems gone.

Still the same old linux kernel 4.9?
Lol, I lost hope in this company.
Waited almost one year, no changes here.
Can’t even install AX card drivers properly.

I’d like to report an issue about JetPack-4.4 DP here. A more detailed description could be found on GitHub: https://github.com/NVIDIA/TensorRT/issues/562

Basically, I was able to use “trtexec” to build the TensorRT engine from the Caffe SSD_300x300 model and run inferencing with it. However, “trtexec” would seg-fault when deserializing the engine file. More specifically, the seg-fault happened during deserialization of the “PriorBox” plugin.

The above worked in TensorRT 6 (JetPack-4.3) previously. So it does seem a bug introduced in current TensorRT 7.1.0 DP.

Our company does use this feature in the products. We hope this issue would be fixed in the GA release.

Hi @jkjung13, please post this issue as a new topic, so we can be sure to look into it promptly. Thanks.

@dusty_nv, sure. I’ver created a new issue here: TensorRT 7.1.0 DP segfault when deserailizing the "PriorBox" plugin. Thanks.

Any chance you could issue a version of SDKmanager for Linux x64 architecture that can actually talk to a Jetson Nano or NX? Very hard to develop when you point to broken tools.

You don’t have to use SDK manager anymore for anything @Whichway . Tegra devices is now feature apt based OTA updates, and the rest of the files SDKM provides can be obtained independently and are largely architecture independent.

I don’t suppose anyone could update the online documentation to say that. I spend day after day going round and round the site trying to find things that might actually work or at least relevant. How did you find out that SDKManager was no longer useful? Sounds like I should be following that. Thanks.