(Generalplus USB Audio) Modify Kernel for the NVIDIA Jetson TK1

I would like to enable my Jetson TK1 with a USB Audio adapter I own, however I run into problems.

lsusb:

Bus 002 Device 019: ID 1b3f:2008 Generalplus Technology Inc.

alsamixer:

0 HDA NVIDIA Tegra
1 tegra-rt5639

uname -r:

3.10.40-grinch-21.3.4

pactl info:

Server String: /run/user/1000/pulse/native
Library Protocol Version: 30
Server Protocol Version: 30
Is Local: yes
Client Index: 12
Tile Size: 65496
User Name: ubuntu
Host Name: tegra-ubuntu
Server Name: pulseaudio
Server Version: 8.0
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.platform-tegra-snd-rt5639.0.analog-stereo
Default Source: alsa_input.platform-tegra-snd-rt5639.0.analog-stereo

pactl list sinks short:

0 alsa_output.platform-tegra-snd-rt5639.0.analog-stereo module-alsa-card.c s16le 2ch 44100Hz SUSPENDED
1 alsa_output.platform-tegra30-hda.hdmi-stereo module-alsa-card.c s16le 2ch 44100Hz SUSPENDED

pactl list sources short:

0 alsa_output.platform-tegra-snd-rt5639.0.analog-stereo.monitor module-alsa-card.c s16le 2ch 44100Hz SUSPENDED
1 alsa_input.platform-tegra-snd-rt5639.0.analog-stereo module-alsa-card.c s16le 2ch 44100Hz SUSPENDED
2 alsa_output.platform-tegra30-hda.hdmi-stereo.monitor module-alsa-card.c s16le 2ch 44100Hz SUSPENDED

cat /proc/asound/cards:

0 [Tegra ]: HDA-Intel - HDA NVIDIA Tegra
HDA NVIDIA Tegra at 0x70038000 irq 113
1 [tegrart5639 ]: tegra-rt5639 - tegra-rt5639
tegra-rt5639

As you can see, Alsa and Pulse do not show up with generalplus as an option even though it is detected in lsusb.

In this post:
Missing driver for usb soundcards
it suggests:

Please add CONFIG_SND_USB_AUDIO=y to tegra21_defconfig, rebuild/replace kernel and try again.

But how do i perform this on my setup please? I have not rebuilt a kernel before but feel comfortable trying if somebody could help me.

Basically, I am trying to run Mycroft Ai on my TK1 but have no microphone working - the generalplus adapter works with mycroft on my ubuntu laptop.

as my TK1 is ARMv7 running debian i figure this post may be of use somehow:

General plus on Rpi

Many Thanks in advance.

dmesg | grep General:

[ 219.384343] usb 2-1.3: Manufacturer: GeneralPlus
[ 219.415317] input: GeneralPlus USB Audio Device as /devices/platform/tegra-ehci.2/usb2/2-1/2-1.3/2-1.3:1.3/input/input8
[ 219.416939] hid-generic 0003:1B3F:2008.0007: input,hidraw2: USB HID v2.01 Device [GeneralPlus USB Audio Device] on usb-tegra-ehci.2-1.3/input3
[ 220.930727] usb 2-1.3: Manufacturer: GeneralPlus
[ 220.938415] input: GeneralPlus USB Audio Device as /devices/platform/tegra-ehci.2/usb2/2-1/2-1.3/2-1.3:1.3/input/input11
[ 220.938943] hid-generic 0003:1B3F:2008.000A: input,hidraw2: USB HID v2.01 Device [GeneralPlus USB Audio Device] on usb-tegra-ehci.2-1.3/input3

Do i need to edit
sudo nano /usr/share/alsa/alsa.conf
to change to generalplus? How to identify correct device number?

or edit:
sudo nano /etc/asound.conf

or:
sudo nano /etc/modprobe.d/alsa-base.conf

thanks in advance (again)

Hi,
Usually a USB audio device can be plugin-and-play. You may check if you see the device being listed in arecord -l or aplay -l.

Hi, doing aplay it shows only the onboard tegra-rt5639 device:
aplay -l:

**** List of PLAYBACK Hardware Devices ****
card 0: Tegra [HDA NVIDIA Tegra], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 0: rt5639 PCM rt5639-aif1-0
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 1: SPDIF PCM dit-hifi-1
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 2: BT SCO PCM dit-hifi-2
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 3: VOICE CALL PCM rt5639-aif1-3
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 4: BT VOICE CALL PCM dit-hifi-4
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 5: offload-pcm (*)
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 7: offload-pcm-capture snd-soc-dummy-dai-7
Subdevices: 1/1
Subdevice #0: subdevice #0

And the same with arecord -l it only lists onboard audio:

**** List of CAPTURE Hardware Devices ****
card 1: tegrart5639 [tegra-rt5639], device 0: rt5639 PCM rt5639-aif1-0
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 2: BT SCO PCM dit-hifi-2
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 3: VOICE CALL PCM rt5639-aif1-3
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 4: BT VOICE CALL PCM dit-hifi-4
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 5: offload-pcm (*)
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: tegrart5639 [tegra-rt5639], device 7: offload-pcm-capture snd-soc-dummy-dai-7
Subdevices: 1/1
Subdevice #0: subdevice #0

What would I need to do to add the lsusb recognised generalplus usb device to aplay and arecord? Many thanks.

I guess one of the reasons I wish to use a USB microphone is because the internal device stops working as soon as a program is opened. I can usually restart the microphone either by opening sound settings and toggling between mono and stereo microphone options, however reopening the software causes the error to be repeated.

Some suggested doing this in terminal:
TK1 Microphone Issue
However, it too only temporarily restarts the mic, and again as soon as a program is opened the mic stops working again.

Also this post:
Audio input on Jetson TK1
will also restart the microphone temporariliy.

Is there any way to have the onboard TK1 audio device not stop working when a program is run? - I am unable to solve this problem, which is why I would like to try and install the USB audio device (generalplus)

I can record a 10 second mic test using:

arecord -d 10 test.wav

shows recording set as:

Recording WAVE ‘test.wav’ : Unsigned 8 bit, Rate 8000 Hz, Mono

and play it back successfully using:

aplay test.wav
shows recording set as:
Playing WAVE ‘test.wav’ : Unsigned 8 bit, Rate 8000 Hz, Mono

Is there anyway to change the aplay record and playback test to record at different hz and change between mono/stereo?

–Update–
So, it appears I can do this:

arecord -d 10 -f cd -t wav test.wav

and it will record in signed 16-bit little endin, rate 44100hz, stereo

aplay test.wav

plays it back as the above.
This shows my TK1 onboard audio records and plays 44100hz stereo ok.
However, when I try to run a program using onboard microphone it stops working at moment of launch.
What could be causing this? My initial guess is segmentation fault due to limitations of the TK1 2gb memory limit? How can I set memory swap to improve this?

What do you see from:
zcat /proc/config.gz | grep 'CONFIG_SND_USB_AUDIO'

Incidentally, if you are going to experiment with a kernel build, then it is a good idea to save a copy of config.gz somewhere safe for future reference.

If “=m” or “=y”, then this is already enabled. If not, then “=m” (loadable module) is far simpler to install versus “=y” (integrated into the kernel).

Since you use “3.10.40-grinch-21.3.4”, then you would need the Grinch source to build modules from. If you still want to build this (and I don’t know if this would help any issue), then we’d need to know if you are cross compiling from a Linux PC host, or if you are natively compiling directly on the TK1.

I get:

CONFIG_SND_USB_AUDIO is not set

Since you use “ 3.10.40-grinch-21.3.4 ”, then you would need the Grinch source to build modules from. If you still want to build this (and I don’t know if this would help any issue), then we’d need to know if you are cross compiling from a Linux PC host, or if you are natively compiling directly on the TK1.

I have done both ways using TK1, usb host compile, and natively. But I have only used pre-built packages and make, I have not really edited any configs before compile

I think Grinch has a different default config than the stock kernel. I think people with the more recent TK1 L4T releases (which are still old) were able to switch to the default kernel. However, if you save a copy of the running system’s “/proc/config.gz”, and note what your “uname -r” output is, then you can match the exact configuration of that kernel when building kernel source (presumably when building from the same Grinch release source).

Since your “uname -r” is “3.10.40-grinch-21.3.4”, this implies the “suffix” is “-grinch-21.3.4”. Wherever you’ve copied your “/proc/config.gz” to, you can then gunzip this to decompress it, and edit the CONFIG_LOCALVERSION to match:
CONFIG_LOCALVERSION="-grinch-21.3.4"

Whenever you build again, if you start with fresh source without configuration, you can copy this file to name “.config” at your build location and this will substitute for “make tegra_defconfig”. From there you could use an application such as “make nconfig” (you might need to first “sudo apt-get install libncurses5-dev”), find symbol CONFIG_SND_USB_AUDIO (note that nconfig has a hot key list at the bottom, and one is to search for a symbol). Go to that symbol, select it as a “module” with the “m” key. Run “make modules_prepare” (or better yet, just for more guarantee that everything is ok, run “make Image”…this also runs modules_prepare, but takes longer…I like to do this at least once as a test even if I am only building modules), and then “make modules”.

Some notes:

  • If you use “O=/some/where” which is an empty directory, then always use this, even in nconfig.
  • If you use “O=/some/where”, then this is where you would copy your new “.config” derived from “/proc/config.gz”.
  • If you also use “INSTALL_MOD_PATH=/some/module/temp/location” with an empty directory, then you can safely run:
    make O=/some/where modules_install INSTALL_MOD_PATH=/some/module/temp/location
    …and find everything from modules there.
  • If you have a mistake, then just recursively delete and recreate the previous empty directories.
  • You want to avoid altering the original kernel source, but if you are unsure if you have, then “make mrproper” (withoutO=”) should fix that.

I do not realy need 3.10.40-grinch-21.3.4, could it be ok to download a different kernel, and compile it, replacing 3.10.40-grinch-21.3.4?

Yes, you could replace the kernel. Before doing so though, you should ask yourself if there is anything Grinch is configured for which is “non-standard”, and which it is needed? Sorry, this gets a bit long, but it might make your life easier in the long run. This includes steps to keep the Grinch kernel available in addition to the new kernel (you may want to remove Grinch at a later date, but not until you know the new kernel is sufficient). This goes with the assumption that you might have something developed or installed which you want to keep functional (if not, then you could perhaps just flash with the most recent release and ignore everything which follows…let me know if you just want to flash).

Note also that before you go about major changes, if there is some valuable work installed, that you could also clone the TK1 as additional backup before you start making changes.

History and trivia (optional, just for fun, explains how Grinch was different from the production kernel): Long ago (I think it was back in 2013) the TK1 was the first of the GPU-enabled embedded systems, and although other Tegra devices had been running for a long time on Linux, this was the first time that NVIDIA was selling such devices directly to the public (NVIDIA had only made reference platforms for third party partners prior to that…I think the TK1 reference accidentally turned out to be so popular with end users it actually created what you see today as NVIDIA’s publicly sold embedded systems for the average person). This was also the first Tegra device with a GPU. There were all kinds of drivers and kernel support which people were finding they needed, e.g., some particular camera driver or filesystem type, and they had to be back-ported from a newer kernel to the current kernel. This was done by Santyago (he did some amazing work!), and intended for L4T R19.x users (this was probably the single most successful/popular third party contribution ever). Later on much of this was made available by default (in L4T R21.x) due to a newer kernel and much (not all) of the back-port content was no longer needed. See the URL for a list of features back-ported.

Your TK1 is probably using L4T R21.x (I hope so…R19.x is astonishingly old). See “head -n 1 /etc/nv_tegra_release”. This largely does not need a Grinch back port. However, it does not mean that a feature you wanted was necessarily enabled by default (you might need to enable something prior to build). In a few cases Grinch would still be required. You need to know the L4T release in order to download the right kernel source version (which can then be configured, and you may at times want to look at the Grinch config while figuring out some configuration issue).

Note that the file “/proc/config.gz” is not a real file, and exists only in RAM. This is a reflection of the running system’s config at the time of compile (with one exception, the value of “CONFIG_LOCALVERSION”). Unlike the kernel build command “make tegra_defconfig”, this is a guaranteed exact match to what you are actually running (once “CONFIG_LOCALVERSION” is updated). You will want to save a copy of config.gz for future reference even when the Jetson is not running that kernel. Save a copy of this somewhere safe with name “config-grinch-21.3.4.gz” (save uname -r as part of the config name…the base version 3.10.40 is removed, and the suffix of the rest of uname -r is included…which also happens to be the CONFIG_LOCALVERSION value at the time the kernel was built).

Although you are not replacing the Grinch kernel, save this somewhere safe for later use as well (something could go wrong). Name it like the config file. The kernel is probably a zImage format, and would be in “/boot”. Save a copy of this zImage (adjust if not “z” prefix) as “zImage-grinch-21.3.4”. You could make an archive directory on your host PC named “3.10.40”, and add the zImage and config.gz there (with the uname -r built in to the file names). If you have these saved, then it is simple to add them back in. Technically, you could also save a recursive copy of everything in “/lib/modules/3.10.40-grinch-21.3.4/” in your archive directory as well (a subdirectory of your “3.10.40/” named “modules/3.10.40-grinch-21.3.4/”).

Note that in 32-bit days a zImage was always used. This is a smaller byte size than is Image, and is compressed. However, the bootloader remained 32-bit even when the 64-bit TX1 came out, and the compressed zImage began to be used as Image instead. This seems to have been done because it was possible the decompression software in the bootloader could not handle a 64-bit address space. Whenever you build a zImage, you also build Image, which is then compressed to become zImage. For the TK1 you can always use the zImage.

FYI, when you build a kernel the uname -r is a combination of the base kernel release version and the CONFIG_LOCALVERSION as the suffix. Modules are searched for by that kernel at “/lib/modules/$(uname -r)/”. If modules are to be found by the kernel as it loads, then uname -r and CONFIG_LOCALVERSION become important.

A combination of the config and “uname -r” and the source code implies the ability to build an exact match at a later time should you lose something. Any modification you ever make to a kernel will most likely start with an exact match to the running kernel, and then edits will be made to the configuration which was originally an exact match. If the new kernel works as intended, then you’d save a safe copy somewhere of the new config.gz (along with its “uname -r”). The cycle can then start again where you start with an exact match and easily make edits for something new.

When switching to the “regular” (non-Grinch) kernel be sure to keep the Grinch kernel in place, and simply add your new kernel as a second entry in extlinux.conf without removing the Grinch kernel (I’m not sure, but at that time extlinux.conf might have still been located in “/boot/extlinux.conf” instead of “/boot/extlinux/extlinux.conf”).

Why replace the old working kernel before you know the new kernel works when you can have both and pick between them? The serial console allows you to pick which kernel to boot while you test things (there is a very short moment during boot where you can hit a key in serial console and pick which kernel entry to boot with, else it will boot a default). Do you have serial console available? This is extremely valuable when changing kernels in case something goes wrong.

Here is the URL which has the complete historic listing of releases (you might need to go there, log in, and go there again if forwarding does not work):
https://developer.nvidia.com/embedded/linux-tegra-archive

Because of your “uname -r” I am going to pretend your L4T release is R21.3.4 (however, be certain to examine “head -n 1 /etc/nv_tegra_release” to know for certain). Substitute if your version differs. R21.3.4 is a patch release to R21.3, and so the L4T R21.3 URL is here:
https://developer.nvidia.com/linux-tegra-r213
(note that if you just flash you could go to release R21.8…this is the final version published for the TK1 prior to its end of life for new feature development…everything went 64-bit after that)

There is a “Documentation” link there telling how to cross-compile a kernel. One difficulty you might run into is an actual need to downgrade your host o/s to Ubuntu 14.04 or 16.04, or to otherwise have cross tools of a sufficiently old version that kernel build works. Natively compiling on the TK1 most likely avoids that problem since it is already that old.

The “driver package” is the flash software, the “sample file system” is what an image is created from after adding some NVIDIA-specific drivers. There are also a set of “source packages”, and the “kernel sources” will be what you are interested in. Assuming building directly on the TK1 you probably won’t need anything extra for the build, except perhaps “sudo apt-get install libncurses5-dev” (which is used for the menu based editor of kernel configuration).

The download provides “kernel_src.tbz2”. Assuming you have enough disk space you can unpack this in any new empty directory. If not enough space, then you could mount an SD card somewhere, and unpack to the SD card mount point. Unpack produces subdirectory “kernel/”.

You will want to keep that location clean, and so create two empty subdirectories for intermediate work. I will assume that you unpacked the kernel source at “/usr/local/src”, but it could be some other preferred location. This produces “/usr/local/src/kernel” (I will refer to this as the TOP directory). Two example empty build locations would be constructed like this (I am assuming in the home directory, but this could also be on an SD card mount if low on space):

# Make empty directories:
sudo mkdir /usr/local/src
sudo mkdir /usr/local/src/kernel
mkdir ~/kernel_out
mkdir ~/modules_out
# Set environment variables for ease of use:
# TOP:
cd /usr/local/src/kernel
export TOP=`pwd`
# Verify:
echo $TOP
# TEGRA_KERNEL_OUT:
cd ~/kernel_out
export TEGRA_KERNEL_OUT=`pwd`
# Verify:
echo $TEGRA_KERNEL_OUT
# INSTALL_MOD_PATH:
cd ~/modules_out
export INSTALL_MOD_PATH=`pwd`
# Unpack kernel source:
cd /usr/local/src
sudo tar xvfj /where/ever/it/is/kernel_src.tbz2
# Verify content, "`ls`" will show files and not an empty location:
cd $TOP
ls
# NOTE: The TK1 SoC is the 12x series, and the SoC specific to the TK1
# reference board is the 124. The following reference to "tegra12" is a
# reference to the the TK1 series of devices.
#
# Note that defconfig would not be needed if you had the config.gz from the original
# kernel...the Grinch config.gz cannot be used here since it is a different kernel source.
# Start with the defconfig:
make O=$TEGRA_KERNEL_OUT tegra12_defconfig
# Assuming you have installed the earlier mentioned `ncurses5-dev`,
# "`sudo apt-get install libncurses5-dev`", then edits can be made:
make O=$TEGRA_KERNEL_OUT nconfig
# The only edit we will make is to CONFIG_LOCALVERSION. Note nconfig shows a
# hot key list for functions at the bottom. You can "search" for "localversion". Then
# set to "-tegra", which is what "uname -r" would use for a default kernel.
# Save and exit from nconfig. Verify the change:
grep CONFIG_LOCALVERSION $TEGRA_KERNEL_OUT/.config
# Build zImage:
make -j 4 O=$TEGRA_KERNEL_OUT zImage
# Build modules:
make -j 4 O=$TEGRA_KERNEL_OUT modules
# Install modules to alternate path:
make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT

At this point you should be able to find zImage:
find $TEGRA_KERNEL_OUT -name zImage

You should be able to see an entire new set of kernel modules named after the base kernel version and “-tegra”. Make sure there is no “+” on the end of the following location (this can be fixed if it is there):

cd $TEGRA_MODULES_OUT
cd lib/modules
ls
# You should see subdirectory "3.10.40-tegra" if the base version is "3.10.40", and if
# CONFIG_LOCAVERSION is "-tegra".

Assuming all went well, then you can copy the zImage to “/boot/zImage-3.10.40-tegra”. Note that I named the zImage after the “uname -r” so it would not collide with the other kernel.

Technically, we could have directly installed modules. Had we not used “INSTALL_MOD_PATH” during “modules_install”, then the final install location would have been directly created. You can do this now if you want, but it is important to verify first there is no “+” on the end of the directory name. To install modules:

cd $TOP
make O=$TEGRA_KERNEL_OUT modules_install

This is equivalent to recursively copying the “3.10.40-tegra/” subdirectory of “$TEGRA_MODULES_OUT/lib/modules/3.10.40-tegra/” to “/lib/modules/” without the “$TEGRA_MODULES_OUT” prefix.

If you see a “+” on the end of that directory, then you’ll have to make an adjustment and build again, or else make adjustments to the actual install procedure.

Assuming no adjustments are needed, you would then edit “extlinux.conf” (in this early release it might be at either of “/boot/extlinux.conf” or “/boot/extlinux/extlinux.conf”. The existing extlinux.conf will have a Grinch entry, and we will merely supplement that entry instead of replacing the entry. The Grinch entry might look something like this, and will be copy and pasted, followed by editing for the new entry (the entry might differ slightly, I am just illustrating):

LABEL grinch
      MENU LABEL primary kernel
      LINUX /boot/zImage-3.10.40-grinch-21.3.4
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=2 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

You would add a blank line following this, and paste a copy of the Grinch entry. Then edit the new entry to reflect some new names and labels:

LABEL notgrinch
      MENU LABEL original kernel
      LINUX /boot/zImage-3.10.40-tegra
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerne3.10.40-grinch-21.3.4ltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=2 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

The part which changed is the “LABEL”, and the name of the “LINUX” line naming the kernel file name. At the top of extlinux.conf there is a “DEFAULT” name which corresponds to a “LABEL”. If you have serial console and can manually pick an entry, then do not change “DEFAULT” to “notgrinch” until you’ve tested that this will work for you…simply use serial console instead to pick entry “2” with label “original kernel”.

If you do not have a serial console available, then you can change the “DEFAULT” from whatever it is which points to the Grinch kernel, to instead be “DEFAULT notgrinch”. If things go bad and it won’t boot, then you could use a serial console (even if you have to order one) and recover directly without difficulty simply by picking the Grinch kernel during boot. Otherwise you would need to flash again (perhaps with a clone to cheat and make it faster/easier).

A particular note is needed about the “FDT” entry. I am just listing the one which is stock for an R21.6 TK1. The device tree file could have changed with Grinch. Likely the non-Grinch device tree name is the same between R21.3 and R21.6, which is “/boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb”. The original addition of Grinch probably did not remove “/boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb”, and that file will likely still be there even if the Grinch tree differs. You would want to edit FDT of the new kernel to point at the one which was intended for the non-Grinch kernel. If you don’t have this, then it is possible the Grinch device tree will work, but there is no guarantee.

If you wanted to back up the Grinch kernel to your host PC, then you should probably back up:

  • The relevant zImage.
  • The relevant FDT entry device tree file.
  • The uname -r the kernel uses.
  • The recursive content for modules at “/lib/modules/$(uname -r)/
  • The extlinux.conf entry.

This is a lot of information for something considered obsolete, but it might be useful for people in the future. If you don’t have something important to save, then you might consider simply flashing R21.8. If you want to safely flash R21.8, but have a way out if it won’t work for you, then you could clone your R21.3.4 first.

Epic post award goes to you! Not many make it to this level.

My TK1 has been a great development and learning board, learning what works, how to make things fit, and what doesn’t work. Even with only 2gb ram and 16gb emmc, I run it with Ubuntu 16.04 with an Intel Neural Compute Stick for ai experiments. I had no idea the TK1 is so old, this decade has flown by.
A quick look at my hardware:
Jetson TK1 (2014) is one of my newest hardware systems
My Ubuntu Laptop is a HP Elitebook 2530p (2008)
Macbook Pro 17" Late 2008
Main Desktop is Z170 32GBram Using Intel ES i7 chip (2015) which is just great for anything (VMs, CAD, QT, Hackintosh)
I feel I have been very resourceful with things in times of low investment

I think I might flash R21.8, config for USB Audio, and update to Ubuntu 16.04, nice and clean, most of my backups are on SD card, and package installs i can usually pull out of my thoughts on a good day.

Looking towards my future for embedded, I havent felt as though I need another embedded board, the TK1 is fantastic for me, I haven’t needed high-end or cutting edge, I think those investments are for Colleges and Education, the TK1 has beaten all my history of embedded boards, Odroid, Rpi, Hummingboard etc, they all got sold or thrown away.
I feel like what is being used more and more are esp32 boards and FPGA. Micropython on the esp32 is great with WebRepl, and more and more tasks for ai- are using FPGA for opencv. The TK1 is great as a host for all these things though, which is why I can see apple moving toward ARM + GPU systems. Great move by Nvidia to aquire ARM by the way. I can see them propping up ioT.

If I were to buy an embedded board, I would be looking toward Pine64 and their pinebook/pinephone ideas, so maybe Nvidia can take all this onboard and go in that direction, start releasing kits to use their embedded jetson modules in laptop and phone kits for makers. I would love a TK1/Nano laptop with sd card distros, the tegra gpu would be a great advantage.

Thank linuxdev for sharing the experience. Sincerely appreciate your help.

Ok, so I bit the bullet and ordered a Jetson Nano 2GB which fits my budget, if I could have gotten hold of a 4gb for say 20 more I would have got that.
I’m going to setup the nano with mycroft and the usb audio adapter, then give the TK1 to a local maker group.

Update:
I took delivery of a Jetson Nano 2gb this morning and USB Generalplus Audio device works out of the box, so I guess it has gotten me further than with my Jetson TK1.
Things I am enjoying so far on the Jetson Nano 2gb:

  • RTL SDR runs nicely on GQRX
  • Generalplus USB audio dongle working
  • Lifecam Studio Working at 1080p

First Day Worries:
Thermal Temps feel hot even just playing a youtube video, tegra stats around 45c but the heatsink almost burning. I have never had a sbc as hot as this before - I have used rpi, beagleboard, odroid, hummingboard, tk1.


I am editing this case which fits the 2gb nano too, so it fits snug to the ports, csi camera ribbon slot, pcb hole mounts. I might add a momentary button for power too like I did with the TK1.

Just to update, I have Mycroft Ai running using my Generalplus USB audio dongle on Jetson Nano 2gb. Both mic & speaker work just fine now, so upgrading from TK1 to Jetson Nano 2gb worked for me