No sound output from Fe-Pi Audio Z v2.2

I bought a Fe-Pi Audio Z (v2.2) to get a headphone socket for my Nano without sacrificing a USB port for a USB sound card. It works fine on my RPi 4 so its not a hardware fault with the Audio Z.

There is already a thread on these forums where a nano user managed to get their Audio Z v1.1 working using the dtb for the 2.x so I’d hope I should be able to get my v2.2 to work but I’ve had no luck yet.

https://forums.developer.nvidia.com/t/jetson-nano-and-fe-pi-audio-z-v1-1-audio-card/

That user neglected to mention which version of Jetpack they were running and if they had rebuilt the kernel.

Some of the commands I have run trying to get it to run include:

sudo /opt/nvidia/jetson-io/jetson-io.py

Which created a new dtb. Jetson-io has a preset for the Audio Z so I chose that and rebooted. After rebooting and trying it again, it still didn’t work, even when I manually flashed the dtb file it created, I still haven’t been able to get any sound out of my Audio Z.

$ dmesg | grep sgtl5000

Doesn’t return anything. aplay -l does list several tegrasndt210 devices and I’ve also tried running:

alsactl init tegrasndt210

but that hasn’t helped. The speaker test command runs but I don’t hear any sound.

I am presuming Jetpack 4.4 has a suitable ALSA driver for this board included with its standard kernel but just the DTB needs to be replaced?

Do NVIDIA plan to enable SPI and GPIO audio by default in future Jetpack releases? Switching dtb files is simple on the RPi but its quite an involved process on the Nano, one I’d rather avoid.

Hello!

Yes the FE-PI Audio V1 and Z V2 are both supported on the latest JetPack for Nano.

Sounds like you did the right thing by using jetson-io to configure the board for the FE-PI Audio Z V2. However, if you are not seeing anything in dmesg for the sgtl5000 then that is surprising. After rebooting, if the correct DTB has been selected, then you should see that the node for the sgtl5000 codec is present in the following location …

$ ls /proc/device-tree/i2c@7000c400/sgtl5000@0a/

If you do not have this entry then for some reason the correct DTB has not been loaded. Your extlinux.conf should have something like the following …

$ cat /boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT FE-PI Audio Z V2

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=PARTUUID=3c68dabc-9ad3-4293-adbc-63c4ebe41673 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

LABEL FE-PI Audio Z V2
        MENU LABEL FE-PI Audio Z V2
        LINUX /boot/Image
        FDT /boot/tegra210-p3448-0000-p3449-0000-a02-fe-pi-audio-z-v2.dtb
        INITRD /boot/initrd
        APPEND ${cbootargs} quiet root=PARTUUID=3c68dabc-9ad3-4293-adbc-63c4ebe41673 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

Note that the default is FE-PI configuration. And yes everything is included for the FE-PI audio Z V2 to work, we just need to update the DTB.

The jetson-io tool was developed to help simplify this process. Can you elborate a bit more on why this is cumbersome on Jetson?

Regards,
Jon

Hi Jonathon

Thanks for explaining how to check for this i2c device in the device tree. I have /proc/device-tree/i2c@7000c400/ but there is no sgtl5000 dir or file within there.

Since my previous post I have thought of one important detail I had forgot to mention. I have transferred my root partition onto a USB SSD as per this guide:

Could that cause any issues for jetson-io? It looks like I will have to at least modify the initrd and the root devices if I want to have my root on USB as they’re not set correctly for my setup. Also, all of the extra boot options are missing after ${cbootargs} for the FE-PI boot entry here.

Getting slightly OT I hear Jetpack plans to officially support USB booting soon but will my nano ever be able to boot directly off USB or will it always require a microSD card?

Doesn’t messing with /boot/extlinux/extlinux.conf require that extlinux get run to update the bootloader? It doesn’t appear that jetson-io runs any extlinux commands and the extlinux tools aren’t installed by default under jetpack.

jetson-io gives me the impression I should be able to run it and reboot but is there actually an extra step or two to flask the dtb and/or update the bootloader? If so, how do I do these extra steps? Maybe I messed up the dtb update process, which I believe involves setting a jumper and entering recovery mode, right?

Hello!

Yes that is most likely the problem. The jetson-io tool is looking for a partition called ‘APP’ which would be typically on the SD-card …

$ findfs PARTLABEL="APP"
/dev/mmcblk0p1

And it will update the ‘/boot/extlinux/extlinux.conf’ on the APP partition. The jetson-io tool appends a new entry to the extlinux.conf and updates the DEFAULT configuration that is booted. Note that Nano uses the U-Boot bootloader which parses the extlinux.conf and not the extlinux bootloader itself.

So the question is, what extlinux.conf file is jetson-io updating on your platform? The one in the USB drive or the SD-card?

Regards,
Jon

Yes, APP is mmcblkp1 so it sounds like I might have 2 options:

  • Re-install and run jetson-io before transferring OS to SSD
  • Rename the PARTLABEL of sda1 to APP and mmcblkp1 to something else

The second option might not be an option at all though because it seems NVIDIA are using some proprietary partition table format that fdisk, gdisk etc don’t recognise.

Have I got to re-install if I want to get my Audio Z working?

Hello!

Is should not be necessary to re-install. We just need to ensure U-Boot is loading the appropriate extlinux.conf file and picking up the newly created DTB with the FE-PI configuration.

I am guessing that U-Boot is loading the extlinux.conf in the USB drive. What is in the extlinux.conf on the USB drive?

What do you see in …

$ sudo mkdir /mnt/tmp
$ sudo mount PARTLABEL=APP /mnt/tmp
$ sudo cat /mnt/tmp/boot/extlinux/extlinux.conf

Regards,
Jon

Hi Jon

I’ve got it working now and with root on USB too although I had to do a complete re-install but this time running jetson-io before transferring root to USB.

When I ran those commands in your last post, I could see that jetson-io hadn’t added a new entry for the Fe-Pi to /mnt/tmp/boot/extlinux/extlinux.conf like it had done to /boot/extlinux/extlinux.conf so I tried copying the config in /mnt/tmp/boot/extlinux/extlinux.conf to /boot/extlinux/extlinux.conf and rebooting but it failed to activate my Fe-Pi.

Before I did a complete re-install, I tried reinstalling the JetPack SD card image, apt updating, running jetson-io (which did get the sound working) then after doing only steps 1 and 4 in the USB guide, ie attempting to retain my existing root disk and it would load the driver (I would see sgtl5000 in dmesg) but sound wasn’t working.

Great! Thanks for letting us know you have it working now.

Regards
Jon

Would you be able to modify jetson-io so it would work even if the user has already transferred their root partition onto USB?

Is it possible to rename the default APP partition created on microSD by the JetPack installer? I might’ve been able to avoid doing a re-install if I knew how to rename the APP partition, then I could’ve used that label for the USB partition and this script should’ve worked, right?

Hello!

It should be not necessary to modify jetson-io to make this work. Ideally, the kernel and DTBs should just reside on the APP partition on the SD card and then the rootfs on the USB drive. At least this is how it was intended and why jetson-io is updating the extlinux.conf in the APP partition.

What is not clear to me is which extlinux.conf U-Boot is loading in this configuration (ideally it should be the one on the SD card) and what is in the extlinux.conf that it is loading.

Regards,
Jon

Hello!

I just wanted to let you know that we will review this and see what we can do to improve this.

Regards,
Jon