In the last post I was lamenting not having a working Visual Studio code. I knew it had worked before the update because I had used it and had written of my success in the past. As it turns out I’ve outfitted the NX with a Western Digital Black 250GB NVME M.2 SSD. That’s were I stash files I don’t want to use when I trash the boot drive, which like the Raspberry Pi, is on an micro SDXC card. Sure enough I found an old Visual Studio deb file, version 1.50. I installed that and Visual Studio worked. I did a bit of installation shuffle between old VSCode releases and discovered that any version for arm64 greater than or equal to 1.60 would not work. Thus I found and installed 1.59.1 and called it a day. I have no time to waste on trying to fix this, nor do I feel the need to finger point.

In order to keep VSCode from yelling about an update, go to File | Preferences | Settings and search for Update: Mode. On the drop down menu select none. Then restart VSCode.

To keep apt from updating it when it’s run, at a prompt type sudo apt-mark hold code and press return. The next time apt is run it’ll show an update for VSCode, but it won’t install it.

I’ve now decided to repurpose the NX to something more useful, such as an environmental monitor and house hold assistant. I don’t know what I’ll use in the future, but it won’t be nVidia. Reports are appearing that nVidia is pouring all its resources into its AI products, and they’re charging top dollar for everything. I checked to see what the official price for a Jetson Orin Nano Developer kit was, and it’s $500. Back when I purchased my Xavier NX, I also purchased the then-available Nano Developer kits, and they were $100 each. There’s a reason I’ve been following and using RISC-V based microcontrollers, and that because everyone is now working on versions that can do AI/ML workloads. I’ll keep working with what I’ve already got because it’s in hand and I don’t want to waste it and let it lie idle. But whether its their AI products or their graphic cards, nVidia is out to pull every dollar it can get away with out of folks wallets. I’m tired of the too-high prices, and I’m done with nVidia.

As I’ve been clearing out the collected detritus of a lifetime around my house, I’ve also been collecting and reorganizing all my various computers. One of those computers is the nVidia Jetson Xavier NX Developer kit.

I purchased it in May 2020 from Amazon for the $300 initial asking price. I figured that if I were going to be locked in due to the pandemic I’d spend my time doing something useful. The Xavier was advertised as an entrée into edge-of-the-network machine learning. I also purchased a third-party enclosure to wrap it up and protect it a little better than leaving the bare board exposed to the world. My first post about the kit was May 2020 (see below), while my last post was December 2021. Along the way I brought up various versions of Python, Emacs, and even got Visual Studio code to work. I also complained about the OS being based on Ubuntu 18.04. I didn’t do nearly as much as I had planned to do, what with all my time being sucked into a project that started in July of 2020.

When I powered the Xavier back up I re-acquainted myself with the state I’d left in in a year-and-a-half ago. All the hacks and patches, all the special Python 3.x builds, all of it. I noted that Ubuntu 18 look-and-feel. I then checked the nVidia on-line references and discovered that the Xavier had been end-of-lifed and a substitute, the Orin, was being sold in its place. I don’t know what’s special about the Orin, but whatever it is nVidia sells it for twice what they sold the Xavier. That puts the Orin squarely outside my discretionary budget.

I also discovered that the the latest version of JetPack, the software stack for the Xavier, had updated the Ubuntu portion to 20.04. I tried to upgrade the version of Ubuntu already on the Xavier from 18.04 to 20.04, but that ended in a hot mess. I downloaded a new image and started over again. You can see what I’m running via neofetch shown above.

So far things are better, I guess. What’s taken a hit is my enthusiasm for this device. That hit is due in part to the fact I can’t get official Visual Studio Code to run, and I don’t want to live inside of Emacs on this little device. VSCode really is needed on this tiny machine.

Time to wrap this post up.

Links

bringing up jetson xavier nx developer kit

WARNING: Value for scheme.headers does not match. Please report this to <https://github.com/pypa/pip/issues/10151>distutils: /usr/local/include/python3.10/UNKNOWNsysconfig: /ssd/jetson/Python-3.10.1/Include/UNKNOWNWARNING: Additional context:user = Falsehome = Noneroot = '/'prefix = NoneLooking in links: /tmp/tmplaxd5qzjProcessing /tmp/tmplaxd5qzj/setuptools-58.1.0-py3-none-any.whlProcessing /tmp/tmplaxd5qzj/pip-21.2.4-py3-none-any.whlInstalling collected packages: setuptools, pip  WARNING: Value for scheme.headers does not match. Please report this to <https://github.com/pypa/pip/issues/10151>  distutils: /usr/local/include/python3.10/setuptools  sysconfig: /ssd/jetson/Python-3.10.1/Include/setuptools  WARNING: Value for scheme.headers does not match. Please report this to <https://github.com/pypa/pip/issues/10151>  distutils: /usr/local/include/python3.10/pip  sysconfig: /ssd/jetson/Python-3.10.1/Include/pipSuccessfully installed pip-21.2.4 setuptools-58.1.0WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

I have never had a problem before now, and I suspect it’s all to do with Python 3.10. I went looking for an explanation and fix ( see https://stackoverflow.com/questions/67244301/warning-value-for-scheme-data-does-not-match-when-i-try-to-update-pip-or-inst for example), but the explanation(s) are confusing, with the general consensus as “don’t worry about it.” Which I consider crap.

So far 3.10.1 seems to work, with one notable exception: you can’t install PyQt6, as there is no qt6-default support package, and PyQt6 won’t build without it. You’re thus stuck with PyQt5.

Determining Various Version Numbers

This section is primarily for me to remember for the future. I’m tired of looking it up.

To determine what version of Ubuntu you’re running:

$ cat /etc/os-release NAME="Ubuntu"VERSION="18.04.6 LTS (Bionic Beaver)"ID=ubuntuID_LIKE=debianPRETTY_NAME="Ubuntu 18.04.6 LTS"VERSION_ID="18.04"HOME_URL="https://www.ubuntu.com/"SUPPORT_URL="https://help.ubuntu.com/"BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"VERSION_CODENAME=bionicUBUNTU_CODENAME=bionic$

To determine what version of Jetpack you’re running:

$ sudo apt-cache show nvidia-jetpackPackage: nvidia-jetpackVersion: 4.5.1-b17Architecture: arm64Maintainer: NVIDIA Corporation...

I have for some time now been running multiple versions of Linux as VMs on my 2019 MacBook Pro via Parallels. Up to this point everything has run smoothly. Until recently, that is, with Visual Studio Code. For whatever reason, something was altered within VSCode that causes it to completely render the display either as you see it above, or if I resize the window, as a red-only window with the white, in which the black is replaced with red. I at least traced to the release where the problem did not occur to 1.52.1, the November 2020 release. Every release since then has exhibited this problem.

Normally I’d take this as something of a challenge and try to find and fix the issue, but before I decided to dive in and look into it I fired up a RHEL 8.3 VM. I had VSCode installed on it and I needed to do some rather quick code work inside VSCode. I have all my VMs sharing common data using a folder on the Mac so it’s rather easy to keep data and source code easily synced. Unfortunately the same problem reared its ugly head on the RHEL VM.

I believe that there is something unique about the current release of VSCode that causes it to improperly render when running within a Parallels Linux VM.

In the mean time I’ve dropped back to VSCode 1.52.1 and blocked it from being updated. I’ve also built and installed Emacs 28, just like I did on the Nvidia Xavier under Ubuntu 18.04. If this problem remains unsolved in VSCode then it looks like I’ll stick with Emacs.

I’ve been wrestling with building Deno on my Jetson Xavier NX running Nvidia’s version of Ubuntu 18.04.2 as part of L4T, or Linux For Tegra (although I tend to think of ‘T’ for Tensorflow). Deno is a reimplementation, if you will, of NodeJS in Rust, attempting to correct many of the bad design decisions that went into Node over time. Deno was created by Ryan Dahl, the original creator of NodeJS, so he should know where the skeletons of Node are buried.

The problem with installing and working with Deno on the Xavier is that it’s Arm-based, whereas all the other environments are x86-based. You can thus download and update (deno upgrade) Deno natively, whereas on the Xavier you need to install a native distribution of Rust, then build deno on the platform with cargo build deno. This worked for all of deno versions up to 1.6.7, then 1.7 was released and building deno on Arm failed repeatedly due to a failure to build librusty_v8. I filed a bug report over two weeks ago, and then, three days ago, I got a response from one of the devs telling me that there was “no pre-built 0.17.0 static library for aarch64 but there is one if you upgrade to 0.20.0.” Sure enough, when I re-ran cargo build deno and watched the task pull and build all the libraries, it pulled librusty_v8 version 0.20.0, which successfully built along with everything else. I have since closed the bug (see https://github.com/denoland/rusty_v8/issues/630 ).

The big draw for me is Deno’s experimental support for WebGPU API. I ran the example given in the release notes ( https://deno.land/posts/v1.8 ) and copied the results into the top of this post. I doubt that JavaScript running on Deno will replace Python as the front-end for ML running on the Jetson Xavier, but I can see it supporting Python, especially with web-based development. I am no fan of Python’s web frameworks, and I’ve lost my disdain for JavaScript over the past 12 months due to another task that showed I could use minimal JavaScript to cleanly solve a knotty problem. Deno also gives me plenty of powerful examples of programming in Rust, so there’s that angle.

Since retirement I’ve explored more interesting languages and their uses than I ever did in the last five years of my regular employment. It wasn’t so much ageism as it was my employer’s adamant insistence that development was their way or the highway. I’m now free to follow my own path(s) and finding what I’m learning to be new, interesting, and challenging in a good way.

Install Build Prerequisites

To build all Python modules the following libraries need to be installed. Simply copy-and-paste the following line:

sudo apt install zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev libbz2-dev

Build Python

Download the latest version of Python, build, and install:

1. Download the latest Python, version 3.9.1, from https://www.python.org/downloads/.
2. Untar the file (we’ll assume it’s downloaded to the default ~/Downloads):

   tar xvf Downloads/Python-3.9.1.tar.xz

3. Make a build directory at the same level as the untarred source directory. In my case I named the build directory build-python-3.9.1
4. Change directory into the build directory.
5. From within the build directory execute the configure script:

   ../Python-3.9.1/configure --enable-optimizations

6. Run make with all active cores:

   make -j $(nproc)

   On my machine I enabled all six cores of the Jetson Xavier NX. Running with fewer cores will result in a longer build time.

7. Install into the alternate location for this version of Python:

   sudo -H make altinstall

8. Check for the alternate location with which python3.9. It should return /usr/local/bin/python3.9.

I created a Python 3.9.1 virtual work environment, something I highly recommend. I do that to keep the stock and newly installed environments distinct from one another. These are the specific steps I used to create that virtual Python environment.

1. In your home directory create a work folder. On my system I named it ‘vpython’. Change directory (cd) into it.
2. Then create a Python VE:

   python3.9 -m venv 39

3. While you’re there you might as well update pip. Always count on the pip bundled with any version to be out of date with the official version. Using my environment as an example:

   $HOME/vpython/39/bin/python3.9 -m pip install --upgrade pip

Now you’re ready to use the latest Python.

Install PyQt5

I use Python library PyQt5. In order to do that you must install Ubuntu’s Qt5 support libraries as well as the Python module.

1. Install Ubuntu Qt5 support: sudo apt install qt5-default
2. Enable Python 3.9 virtual environment: source $HOME/vpython/39/bin/activate
3. Install Python PyQt5: pip install PyQt5

You’re pretty much free to use Python 3.9 with PyQt5 at this point.

Note that these directions also apply to installation on the Jetson Nano on the same Jetpack version.

Back in September 2019 I wrote how I failed to build Qt 5.13 from its C++ source, which was the latest Qt release at that time(see /2019/09/02/an-absolute-failure-unable-to-build-qt5-on-a-raspberry-pi-4/ ). My primary reason to build the latest Qt was to step up the Qt version used in PyQt5. There were problems I’d discovered in the installed repo version, and I’d wanted to create a development environment where I could investigate, and if possible, try to fix any of those problems, with an eye towards pushing any fixes back up stream. That obviously didn’t work out, and I left the whole thing alone. Until now.

For whatever reason I decided to try again. Except this time, I used JetPack 4.4 on the Nvidia Xavier NX Developer Kit. While the Xavier is ostensibly for machine learning prototyping and development, the fact it’s based on Ubuntu 18.04.5, ported onto Nvidia’s six core ARM chip, makes it too tempting for me just to use for ML. And thus I decided to try to run with the latest PyQt5 on the latest Python 3 release.

Installation

I’m starting from my Python 3.8 installation inside an activated Python virtual environment. I’d documented how to build Python from scratch as well as create a working virtual environment here: /2020/05/24/building-python-3-8-3-on-jetpack-4-4-dp-and-the-jetson-xavier-nx/ , so I won’t go through that again.

However, before we really get started, you’ll need to install the basic Qt5 development tools, otherwise PyQt5 won’t install. You do that with sudo apt install qt5-default . That gives all the basic tools and support libraries.

With Qt5 default installed, activate the Python 3.8 virtual environment. I’ve since moved up to Python 3.8.5, and I’m getting ready to install Python 3.9 alongside 3.8.5 when it’s officially released. That’s another reason I like virtual environments; it’s incredibly easy to keep multiple Python versions on hand.

Within the virtual environment, do a simple pip install pyqt5 .

You might as well go off and do house work or watch an episode or two of your favorite streaming shows, because this is going to take a while (as in hours). No, I didn’t time it.

Once it’s done, it should announce it’s successful. From there you can work with PyQt5 within that virtual Python environment. I would strongly recommend you always work within a Python virtual environment. It all works with your regular security permissions (no sudo), and if you want to blow it away, it’s very easy to do so. I just don’t like adulterating the system installation of Python anymore.

So far, except for the long build time, everything is working without any drama.

Which was, in hind sight, actually a Good Thing. The Developer’s Preview had picked up a bit of cruft from all my experimentation. Being forced to recreate the boot image wasn’t all that horrible, it just cost me a detour and a chunk of my time I really didn’t want to have to give up.

It wasn’t all that bad, actually. After all, you flash a micro SDXC card, poke it into the NX, and apply power. Fortunately for me the bits I cared about were on my blog, and I used my other Linux notebook to basically copy my home directory to a 64GB thumb drive, from which I cherry-picked the bits I want to move over to the new install.

One of the oddball problems I ran into was re-installing Deno. On the 4.4 Developer’s Preview I’d installed Deno via Rust’s cargo, and got Deno version 1.0.2 up and running. This time, Deno had moved up to version 1.1.3 and failed to build via cargo. I’ve gotten Deno back by pulling the source tarball off of Deno’s github site. I discovered what the cargo build failure was by watching the source tarball build: The module deno_lint is 0.1.16 from cargo, and it fails all over the place with unresolved calls. The module deno_lint in the source tarball is version 0.1.15, and it builds. After the build, I pushed my binary over to ~./local/bin (which is in my path) and carried on using Deno.

Oh, and I pulled the latest Emacs from their git site, and I’m now running with version 28.0.50. Some things are actually a smidge better with this release.

The deb file was built on the Jetson Xavier NX board, then copied to a thumb drive, then moved over via the thumb drive over to the Rasbperry Pi and installed from there. So far it’s behaved reasonably well. I’ve learned quite a bit about the build tools that come with the source. I suppose it’s good that I found some of the directions I did on the web, but now that I’ve gone through this whole process a number of times, what I used to start with short circuits what is available in the source tree cloned from GitHub.

I appreciate that I can use the Jetson NX as a build system. I also appreciate that there is a method in the source tree for building the deb file. That to me is super. Now I can keep up with releases, knowing I can target 64-bit ARM binaries for Debian/Ubuntu.

And speaking of Debian, the 64-bit OS running on the Raspberry Pi now identifies itself simply as Debian.

Once I feel comfortable running the full build suite in Visual Studio Code I’ll post a streamlined how-to for ARMv8/aarch64/arm64. Too many labels, frankly.

As before I used the directions on Clarence’s Wicked Mind blog ( https://www.clarenceho.net/2019/05/building-visual-studio-code-on-jetson.html ). Even though these directions are now over a year old, they still work, which to me is amazing considering how bit rot can quickly set into any given how-to. Since I’m still building off trunk, and not the latest formal release, I wound up with this version:

The current formal release is 1.46 (I checked on my Mac).

I went in and picked out the extensions I wanted to work with because of what I’m working with on the NX:

And for the curious, I’m running the Docker extension with Docker on the NX, and just for grins, I opened up the debug console on the right, just to see what that was all about. All pretty impressive and it looked really interesting, except for the Recommended section on the bottom left, which is empty. And that’s what kept sending me over into the weeds.

I could have sworn on a stack of Bibles that Recommended is never empty. So I went and checked again on my Mac, and wouldn’t you know it, it only had two entries. The behavior I’m describing used to be this way, on Windows. But it changed, and even though I’ve been good to keep up with the updates, I just didn’t pay attention. So when I saw zero recommendation I thought it was somehow broken. Until I went searching for something, and discovered this behavior all over again:

When I searched for ‘angular’ as an example, lo and behold I got all the Angular plugins. A few more searches and I was finally convinced I had a fully working VSCode for the Jetson SBCs. I was just absolutely stupid.

And since I started out with Docker, here’s a bit more of the Docker plugin to gaze upon:

The Docker plugin gives a bit more control and insite into Docker containers. The middle upper window is latest.json for the image, while the bottom middle is attached to the bash shell running inside the container. The right window is the debug window for all of VSCode, just so it looks cool in the blog post. Whatever…

Right now I’ve got a fully operational instance of VSCode by following someone else’s directions to build it. And I couldn’t be happier. Hopefully, I’ve gotten past this patch of personal stupids. But you never know.

These are directions for building and running the Jetson Inference examples on the Jetson Xavier NX running JetPack 4.4 Developer Preview. Jetson Inference was originally released for the Jetson Nano. It’s been a while since I worked with these examples on that platform, and I did not document anything, as it all seemed to work back then.

These are tl;dr instructions for guaranteed application building.

First, install the following packages:

sudo apt install libglew-dev qt5-default

Then clone a copy of Jetson Inference. You can do this anywhere, but do it in a part of the file system where you have normal (non-root) access.

git clone https://github.com/dusty-nv/jetson-inference.git

This will produce a new folder jetson-inference. Change directory into jetson-inference and execute the following git command.

git submodule update --init

Create a build directory (mkdir build), and change directory into it.

Execute CMake to create the necessary build infrastructure.

cmake ../

During the cmake process step, two scripts will be run that will display ASCII menus within the terminal. The first menu is the Model Downloader. This is how it first appears.

Only two of the models are selected by default.

I selected all of them and downloaded everything. That’s because I’m working off the Western Digital Black SSD I installed and documented two posts back (see “adding a western digital wd_black 250gb nvme drive to jetson xavier nx“)

After selecting all the models, a second ASCII menu is presented to install PyTorch.

I personally skipped this one because I want to install PyTorch using my Python 3.8.3 virtual environment, which I also built for this NX a few posts back. Once I figure out how to install the PyTorch for Python 3.8.3 I’ll revisit documenting that specific step.

Once CMake is finished, execute make within the build folder.

make -j $(nproc)

Assuming you have all six NX cores enabled, and are building on an SSD (not the boot SDXC card), then it should build fairly quickly.

Now for the running part. As a very basic smoke test, attach a Raspberry Pi Camera Module V2 to the CAM0 port. That port is on the edge of the bottom circuit board right above the power barrel connector. You might want to power down the NX when you do this.

When you come back up change back to the jetson-inference/build folder, and then:

./aarch64/bin/camera-capture

You should see something on your desktop similar to the following screen capture.

The application, when running, will take over the entire desktop. The small window will allow you to set up the application for other tasks, and if you kill the window, then the entire application exits.

I’m in the process of testing out other features found in the Jetson Interface examples on the NX and will report anything untoward or unusual when time permits. My honeydew list is calling…

At first I thought it was going to be very simple to get a Bluetooth speaker paired with the Jetson NX. The video stream part isn’t an issue, as I’ve been streaming a lot and I have yet to find anything that won’t stream on either the Jetson NX or the earlier Nano.

Fixing Bluetooth Audio

Bluetooth audio, as it currently ships on JetPack 4.4/Ubuntu 18.04, is incomplete and thus broken out-of-the-box. Researching as usual via Google, I finally found instructions for making Bluetooth audio work on the Jetson TX2. I tried them for the Jetson Xaiver NX and found that they worked there as well. The full link to the original instructions is: https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fhw_setup.html%23wwpID0E0KN0HA

The instructions repeated here with suitable edits are:

To enable Bluetooth audio

1. Open a shell and using sudo, edit this file with the text editor of your choice:

   /lib/systemd/system/bluetooth.service.d/nv-bluetooth-service.conf

2. Change this line:

   ExecStart=/usr/lib/bluetooth/bluetoothd -d --noplugin=audio,a2dp,avrcp

   …to this:

   ExecStart=/usr/lib/bluetooth/bluetoothd -d

   That is, delete the “‑‑noplugin…” switch and all of its values to the end of that line. Then save the file.

3. Execute these commands to install the pulse audio package:

   $ sudo apt update && sudo apt install pulseaudio-module-bluetooth

4. Finally reboot the Jetson device:

   $ sudo reboot

5. When the reboot is complete, you should be able to pair and connect nearly any Bluetooth audio device.

Pairing the EcoXGear EcoEdge Bluetooth Speaker

I purchased a pair of these at my local Costco for $40 each. You can find them on line at Amazon for the same price. I love the fact that they’re waterproof (IP67) and will float in a pool, and if I really need one, it has a bottle opener on one corner (see above). You never know when you’ll really need a bottle opener, especially here in Florida.

After installing the software you’ll need to pair the speaker with the NX. Make sure the speaker has a decent charge on it. It comes with a micro USB charging cable, but no charger. Fortunately for me I have wall warts everywhere, so that’s not a problem for me. The minimum for charging is 5V1A, so that’s not going to be a problem either.

With a decent charge on the speaker turn on the speaker by pressing its on/off button. When it turns on it will say pleasantly “power on.” Then press the Bluetooth switch to turn on Bluetooth. The speaker will announce that as well.

On the NX desktop, in a shell, run ‘sudo bluetooth wizard’. The little application that pops up will list a whole slew of Bluetooth MAC addresses, and an entry for the speaker, ECOXGEAR. Select that and press next.

The application will quickly pair with the speaker, and the speaker will say “Connection successful.”

If you want to check out the hardware and test that it works, then go to the Bluetooth icon in the upper right corner of the desktop, and click for the menu.

Move the mouse arrow down to the name of the paired device. You want to see that the connection is “ON.” If you want to further test, then move over and click on “Sound Settings…”

Note the mode: High Fidelity Playback (A2DP Sink). It needs to be this in order to play audio.

The Jetson Xavier NX is more sophisticated than it’s earlier predecessor, the Jetson Nano. The NX has an NVMe connector on the bottom of the support board for NVMe SSDs. In this post, I install, format, and mount a Western Digital WD_Black SN750 250GB NVMe SSD.

The SSD is extremely easy to add to the NX.

1. Using a small Phillips head screwdriver, remove the screw on the left beneath the screw that is holding in the WiFi/Bluetooth adapter.
2. Insert the slotted end of the SSD into the matching connector on the right of the NX board, at a 45° angle up from the board, and push gently until the slotted end snaps into the socket.
3. Push down the other end of the SSD so that its left edge semi-circular hole lines up with the hole on the NX board right beneath it.
4. Re-install the small Phillips head scew so that it physically holds the SSD down in place.

At this point the SSD should be flat against NX board.

Now comes the formatting and mounting of the SSD to make is usable to the NX system.

1. Power up the NX and log into Ubuntu as your regular user.
2. Open a shell on the desktop and execute gnome-disks. Make sure that the entry as shown below is selected. On the gear button, click and select “Format Partition…”
3. You can type just about any standard ASCII character and number sequence for volume name. I chose WD250 because it was short and descriptive to me. I took the defaults for everything else. Click ‘Next’.
4. On the ‘Confirm Details’ dialog click the ‘Format’ button.
5. In the next dialog, type in your password, the same password you would use for any sudo command. Then hit Enter.
6. When you return back to the initial application view, you’ll see a new right arrow button. You’ll click this to mount the newly formatted disk.
7. When everything is finished, the gnome-disks application will show the size in decimal GB (not base-2), the device name (dev/nvme0n1 in this example), the UUID of the device, and the mount point of the drive (/media/jnx/WS250 in this example).

You’ll note that gnome-disks shows both the new 250GB drive and another 500GB SSD, Crucial MX500. This is the drive I purchased some time back for my Raspberry Pi 4, and which I “carried forward” to use with my Jetson Nanos. It’s big and fast for what I need. But I was curious to see how it’s speed compared to the new NVMe drive, so I ran some very basic (some would say crude) tests to write data to both drives and time how long the writes took. Again, let me state this is a very rough order of magnitude.

I used the utility ‘dd’ to write a 1GB file to both devices. Writes are a good 40% faster to the NVMe the the 500GB SSD, which is attached via a SATA to USB3 adapter.

So what are the overall benefits of replacing an external USB3 SATA SSD with the NVMe SSD?

1. The obvious first benefit is speed. For building and running models, the WD_Black is second to none.
2. The NVMe is a “real” drive. The boot device on the NX is a SanDisk 128GB micro SDXC memory card. It’s great for booting, but quite lousy with regards to speed.
3. With the NVMe I get back a USB3 port on the NX. I’ve also noticed a problem with the USB3 SATA adapter. It appears to cause interference and problems with any other attached USB device, especially my wireless keyboard.

I’m sure there are others. As far as cost is concerned I picked up the WD_Black from Amazon for $55. I find that to be an amazingly low price for a storage device of this type. While the NVMe is only 1/2 the storage space of the SATA device, I find that the new drive is more than enough for what I currently need.

These are directions for building and running the Jetson Inference examples on the Jetson Xavier NX running JetPack 4.4 Developer Preview. Jetson Inference was originally released for the Jetson Nano. It’s been a while since I worked with these examples on that platform, and I did not document anything, as it all seemed to work back then.

These are tl;dr instructions for guaranteed application building.

First, install the following packages:

sudo apt install libglew-dev qt5-default

Then clone a copy of Jetson Inference. You can do this anywhere, but do it in a part of the file system where you have normal (non-root) access.

git clone https://github.com/dusty-nv/jetson-inference.git

This will produce a new folder jetson-inference. Change directory into jetson-inference and execute the following git command.

git submodule update --init

Execute CMake to create the necessary build infrastructure.

cmake .

Then execute make.

make

Assuming you have all six NX cores enabled, and are building on an SSD (not the boot SDXC card), then it should build fairly quickly.

Now for the running part. As a very basic smoke test, attach a Raspberry Pi Camera Module V2 to the CAM0 port. That port is on the edge of the bottom circuit board right above the power barrel connector. You might want to power down the NX when you do this.

When you come back up change back to the jetson-inference folder, and then:

./aarch64/bin/camera-capture

You should see something on your desktop similar to the following screen capture.

The application, when running, will take over the entire desktop. The small window will allow you to set up the application for other tasks, and if you kill the window, then the entire application exits.

I’m in the process of testing out other features found in the Jetson Interface examples on the NX and will report anything untoward or unusual when time permits. My honeydew list is calling…

These instructions will help you build Python 3.8.3 on the Jetson Xavier NX Development Kit running JetPack 4.4 Developer Preview. There are two broad steps to building this version. The first is the installation of support developer libraries to allow as many Python modules as possible to successfully build. After the installation step, then comes the build steps. This was reversed in the 16 May build how-to.

To build as many modules as possible the following libraries need to be installed.

• libgdm-dev
• libnss3-dev
• libssl-dev
• libsqlite3-dev
• libreadline-dev
• libbz2-dev
• libdb-dev, libdb++-dev (Berkeley db)
• libgdbm-dev
• libffi-dev

And for those of you following along who just want to copy and paste one time, the single line command to install all the libraries at once is:

sudo apt install libgdm-dev libnss3-dev libssl-dev libsqlite3-dev libreadline-dev libbz2-dev libdb-dev libdb++-dev libgdbm-dev libgdbm-dev libffi-dev

The package libffi-dev was not in the installation list from 16 May. If not installed then then module _ctypes will fail to build.

1. If you haven’t done so already then download the latest Python, version 3.8.3, from https://www.python.org/downloads/.
2. Untar the file (we’ll assume it’s downloaded to the default ~/Downloads):

   tar xvf Downloads/Python-3.8.3.tar.xz

3. Make a build directory at the same level as the untarred source directory. In this case the build directory was named build-python-3.8.3
4. Change directory into the build directory.
5. From within the build directory execute the configure script:

   ../Python-3.8.3/configure --enable-optimizations

6. Run make:

   make -j 6

   Note that we’re using all six cores of the Jetson Xavier NX. This means that all six cores should be enabled on the NX.

7. Install into the alternate location for this version of Python:

   sudo -H make altinstall

8. Check for the alternate location with ‘which python3.8’. It should return ‘/usr/local/bin/python3.8’.

I then created a Python 3.8.3 virtual work environment. These are the specific steps I used to create that environment.

1. In your home directory, create a work folder. In this example it was named ‘venv383’. Change directory (cd) into it.
2. Then create a Python VE:

   python3.8 -m venv app01

Once created, you should have a directory structure like this:

├── bin/│   ├── activate│   ├── activate.csh│   ├── activate.fish│   ├── easy_install│   ├── easy_install-3.8│   ├── pip│   ├── pip3│   ├── pip3.8│   ├── python -> python3.8│   ├── python3 -> python3.8│   └── python3.8 -> /user/local/bin/python3.8├── include/├── lib/│   └── python3.8/│   └── site-packages/│   ├── easy_install.py│   ├── pip/...│   ├── pip-19.2.3.dist-info/...│   ├── pkg_resources/...│   ├── __pycache__/...│   ├── setuptools/...│   └── setuptools-41.2.0.dist-info/...├── lib64 -> lib/└── pyvenv.cfg

To active the virtual environment, you would execute

source bin/activate

In my environment I created a Bash alias to handle that:

alias activate='source $HOME/venv383/app01/bin/activate'

Note that this incorporates the folder and virtual environment name I personally created earlier. If you change any of that then you’ll incorporate what you created.

Here’s a quick run to see if those bits are working properly.

And so it would appear that they do.

Deno was created by Ryan Dahl (along with help from a few special friends), the original creator of NodeJS. Ryan created Deno because, according to him, “I see the bugs that I made, design mistakes made that just cannot be corrected now.” There’s more to his reasons and how he went about solving Node’s problems and limitations in the article “Node.js creator delivers Deno 1.0, a new runtime that fixes ‘design mistakes in Node’“, https://www.theregister.co.uk/2020/05/14/nodejs_creator_deno_10/

I can’t judge whether he’s fixed any, or all, of Node’s problems. But I can judge that his work is very interesting because it’s all implemented in Rust.

To get Deno running I first installed Rust. Then using Rust’s cargo I installed Deno, all on the Jetson Xavier NX running JetPack 4.4, which means Ubuntu 18.04.

Installing Rust is simple enough as documented here: https://www.rust-lang.org/learn/get-started

Or you can copy the following command directly from this post, which was copied from the Rust page, to cut to the chase as it were:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Make sure you ‘apt install curl’ before you do this because curl isn’t installed by default in this version of Ubuntu.

Then go over to the Deno installation section here: https://deno.land/#installation
Or you can simply run the following command once Rust is installed and have Rust just do the heavy lifting:

cargo install deno

You can sit back and watch cargo download and build all the necessary packages to produce a Deno runtime. By the way, Rust is installed in your login directory under ~/.cargo, and that’s where all of Deno is also stashed. It’s local to whatever login account you’re using which makes it kind of handy if you want to delete everything and start over.

With Deno installed I then wrote/copied the tiny test program on the Deno main web page and executed it.

It’s kinda neat. Here is a real strong alternative to Node, written in Rust. It’s a bit over the top to say this, but Deno could be Rust’s “killer project” that really helps push Rust along. If you want a way to dive into Rust, then do it through Deno.

One other thing. I tried to edit TypeScript code in Emacs by attempting to install support via MELPA and MELPA-stable. I’m still the Emacs neophyte after all these years, especially with Emacs Lisp, so that’s a mark against me. But the workaround right now is to name all my files with a .js extension, and then Emacs does its syntax highlighting thing. Problem solved.

I have to admit I’m having fun. I haven’t had this much fun since the “good old days” of the 1970s and early 1980s with the 6502 KIM, Apple ][, and Commodore 64. All those were wide open and very approachable. Today’s Raspberry Pi and Jetson Nano and NX boards bring a lot of that back and make working with both hardware and software so much easier and more powerful.

I’ve got my tools in place, so now it’s time to dig and get a proper feel for the NX and JetPack 4.4.

The Jetson Xavier NX Developer kit arrived today. I have installed JetPack 4.4 Developer Preview, just like I did with my Jetson Nano. I also moved my Crucial 500GiB SSD over and plugged it into the NX. JP 4.4 was flashed onto a SanDisk 128GB SDXC Extreme Plus V30 XC1 U3 A2 (yeah, I know). After initial poweron and setup, the card has 117GiB total storage, with 13GiB of it used so far.

First things I installed were pip, curl, htop, and jtop.

With the SSD installed I moved over to the emacs build area and prepared to build and install emacs, just like I’d done on my Nano. For that I installed the following libraries (again):

• texinfo
• libxaw7-dev
• libjpeg-dev
• libpng-dev
• libgif-dev
• libtiff-dev
• gnutls-dev
• libncurses-dev
• libfreetype6-dev
• libcairo-dev
• libgif-dev

The last entry, libgif-dev, was missing in my original post about building emacs. I’d picked it up when I built python 3.8.3 first. This time I built emacs first, just to test my original build directions, and found the hole in my installation. Of note is what apt printed to the console when installing three of the libraries:

Note, selecting 'libgnutls28-dev' instead of 'gnutls-dev'Note, selecting 'libncurses5-dev' instead of 'libncurses-dev'Note, selecting 'libcairo2-dev' instead of 'libcairo-dev'

Everything built and linked successfully in spite of the “substitutions.” No, I did not see this the last time.

I checked the emacs clone with git status, and found nothing in source had changed. I then performed a make clean, followed by a configure, then a ‘make -j 6’ so I could run make against all six cores of the NX. That’s why jtop’s CPU monitor shows all six cores fully utilized. Once finished, make install, and then a quick test. Before this I’d moved over all my emacs configuration files.

Not much more to say at this point. I have yet to decide if I’ll build python 3.8.3 like I did on the Nano. I do want to get completely off of Python 2, but I need to better understand the tooling in JetPack before I go off and break stuff.

I will have more to say later about the overall hardware of the NX. Suffice to say it’s a hex core Cortex A75 equivalent, which is, core for core, twice the performance over the Nano’s Cortex A57 cores. It has 8GiB of memory, which makes development much sweeter than on the Nano. And this Developer Kit comes with WiFi and Bluetooth built-in, which makes it much easier to integrate with network and other wireless tools. But as I said, more to come.