Hauppauge WinTV-HVR-950Q not powering on

When plugging in my Hauppauge WinTV-HVR-950Q ATSC usb dongle I’m not getting any activity in the LEDs. This dongle is definitely working as it works in my laptop and RPI3 and it even shows up when running lsusb on the Nano. For whatever reason the activity lights on the dongle arn’t working when plugging into the Nano and it’s not usable by any applications. This can be verified by launching Kaffeine and not seeing the dongle in the sources list. This isn’t an issue when plugging into my laptop or my RPI3.

dmesg output

[ 6952.755098] usb 1-2.1: new high-speed USB device number 12 using tegra-xusb
[ 6952.797757] usb 1-2.1: New USB device found, idVendor=2040, idProduct=7200
[ 6952.797762] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=10
[ 6952.797765] usb 1-2.1: Product: WinTV HVR-950
[ 6952.797769] usb 1-2.1: Manufacturer: Hauppauge
[ 6952.797771] usb 1-2.1: SerialNumber: 4032701650

Hi,
This patch may help:

Please apply it, rebuild/replace kernel, and give it a try.

Do you have a guide on how to actually do this?

Following the guide at https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide%2Fkernel_custom.html%23, there is much to be left to interpretation. That being said, I tried my best to make sense of it and now I’m left with an OS that gets through the startup processes and then turns into a black screen instead of a login screen. The following are the steps I took to get there. Please advise on what I’m doing wrong.

# https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fkernel_custom.html%23

sudo apt install build-essential bc

cd ~
wget "https://developer.nvidia.com/embedded/L4T/r32_Release_v4.3/sources/T210/public_sources.tbz2"
tar -xjf public_sources.tbz2 
cd Linux_for_Tegra/source/public/
tar -xjf kernel_src.tbz2 
cd kernel/kernel-4.9/

# create build dir
mkdir ~/kernel
TEGRA_KERNEL_OUT=~/kernel

# manually copy patch to new patch suggested in https://patchwork.ozlabs.org/project/netdev/patch/20170927213103.11987-1-aleksander@aleksander.es/
vi usb.patch

# apply patch
patch < usb.patch 

# build kernel (I think)
make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig
make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j$(nproc)

# copy new stuff over old stuff
sudo cp ~/kernel/arch/arm64/boot/Image /boot/Image
sudo cp -rp ~/kernel/arch/arm64/boot/dts /boot

#suggested here: https://forums.developer.nvidia.com/t/android-usb-tethering-not-working/123202/34?u=bradley.bruggemann
make modules_install /

# reboot
sudo reboot

# black screen after startup processes complete

Rebuilt from scratch. Tried again with the following steps. System boots but responds the same. I believe everything is built properly but ATSC dongle is still behaving the same.

LinuxTV wiki page for Hauppauge 950Q:
https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q

# check current kernel
uname -a
Linux jetson-desktop 4.9.140-tegra #1 SMP PREEMPT Thu Jun 25 21:25:44 PDT 2020 aarch64 aarch64 aarch64 GNU/Linux

# download kernel source and unpack
cd ~
wget "https://developer.nvidia.com/embedded/L4T/r32_Release_v4.3/sources/T210/public_sources.tbz2"
tar -xjf public_sources.tbz2 
cd Linux_for_Tegra/source/public/
tar -xjf kernel_src.tbz2 
cd kernel/kernel-4.9/

# create build dir
mkdir ~/kernel
TEGRA_KERNEL_OUT=~/kernel

# download patch suggested in https://patchwork.ozlabs.org/project/netdev/patch/20170927213103.11987-1-aleksander@aleksander.es/
wget "https://patchwork.ozlabs.org/series/5452/mbox/" -O "rndis_host-support-Novatel-Verizon-USB730L.patch"
patch -p1 < rndis_host-support-Novatel-Verizon-USB730L.patch

# build and install kernel
make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig
make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j$(nproc)
sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install
sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT install

# verify modules
ls -l /lib/modules/
drwxr-xr-x 3 root root 4096 Jul 30 10:35 4.9.140
drwxr-xr-x 3 root root 4096 Jul  1 06:18 4.9.140-tegra

ls -l /lib/modules/4.9.140
total 1184
lrwxrwxrwx 1 root root     19 Jul 30 10:35 build -> /home/jetson/kernel
drwxr-xr-x 8 root root   4096 Jul 30 10:35 kernel
-rw-r--r-- 1 root root 367501 Jul 30 10:35 modules.alias
-rw-r--r-- 1 root root 362223 Jul 30 10:35 modules.alias.bin
-rw-r--r-- 1 root root  21745 Jul 30 10:35 modules.builtin
-rw-r--r-- 1 root root  24719 Jul 30 10:35 modules.builtin.bin
-rw-r--r-- 1 root root  51143 Jul 30 10:35 modules.dep
-rw-r--r-- 1 root root  81547 Jul 30 10:35 modules.dep.bin
-rw-r--r-- 1 root root    138 Jul 30 10:35 modules.devname
-rw-r--r-- 1 root root  27248 Jul 30 10:35 modules.order
-rw-r--r-- 1 root root     85 Jul 30 10:35 modules.softdep
-rw-r--r-- 1 root root 107271 Jul 30 10:35 modules.symbols
-rw-r--r-- 1 root root 131811 Jul 30 10:35 modules.symbols.bin
lrwxrwxrwx 1 root root     60 Jul 30 10:35 source -> /home/jetson/Linux_for_Tegra/source/public/kernel/kernel-4.9

# update bootloader in /boot/extlinux/extlinux.conf

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/vmlinuz-4.9.140
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

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

# reboot
sudo reboot

# check current kernel
uname -a
Linux jetson-desktop 4.9.140 #1 SMP PREEMPT Thu Jul 30 10:12:16 EDT 2020 aarch64 aarch64 aarch64 GNU/Linux

Hi,

Firstly, you need to know how to debug kernel when monitor is out.

https://elinux.org/Jetson/General_debug

Also, the document we shared is asking customer to try cross-compile but not build on device.

However, if it can build w/o error, then I think it is okay. Probably some setup causes the device dead. Please check the log first.

Hi

Please export the following environment variables before build:

$ export CROSS_COMPILE=<cross_prefix>
$ export LOCALVERSION=-tegra

•<cross_prefix> is the the absolute path of the ARM64 toolchain without the gcc suffix. For example, for the reference ARM64 toolchain, <cross_prefix> is: <toolchain_install_path>/bin/aarch64-linux-gnu-

You can download toolchain from here.

The device is no longer dead. In my follow-up post I included all steps to rebuild. I have a working system right now, but the Hauppauge dongle still isnt functioning.

Upon further reading the tuner needs 1) xc5000 firmware and 2) the xc5000 driver.

The firmware is already located on Jetpack 4.4 at /lib/firware/dvb-fe-xc5000-1.6.114.fw

However, I believe the actual xc5000 driver is missing as the directory tree /sys/module/xc5000 isn’t present.

I poked through the Linux v4.9 source and found the xc5000 driver source so maybe it wasn’t included for some reason? https://github.com/torvalds/linux/blob/v4.9-rc1/drivers/media/tuners/xc5000.c

Just some information to add, not an answer.

The file “/proc/config.gz” is not a real file, this is the kernel showing its configuration in the running system. If you run this command, it will show all symbols (and symbols are how you find drivers):
zcat /proc/config.gz

If you see “=y”, then that feature was compiled in integrated into the kernel Image. If you see “=m”, then the feature was compiled as a module and the module file would be somewhere within “/lib/modules/$(uname -r)/kernel/”. If the line starts as a comment with the “hash” mark ‘#’, then the feature could have been set, but was not built.

If the feature is not listed at all, and I mean not even listed as not built, then probably the source code was not present in this kernel and there would be no possibility of building this without outside source code.

You could search for the symbol CONFIG_MEDIA_TUNER_XC5000 (I cheated and looked up the hardware), and I would expect this to not normally be compiled since few people will use this. The normal scenario is that if you have that hardware you’d add the driver. The part which looks odd is that this symbol does not occur, at all, in any form. Looking at this URL it claims the driver should be available in the current kernel. You can check your kernel version with “uname -r”. So this driver may have been excluded from this release, but I don’t know why. It is unlikely NVIDIA removed it, and I suspect someone knowing more about the driver would have to answer that question (NVIDIA would not be able to answer why someone else removed the source from that release version).

Technically you could try to add the source in yourself and build the module, but if the source is missing, then there might be a reason for it.

1 Like

Hi,
The patch id for devices using rndis driver. I thought your device used it but looks like it requires additional driver. You may check if you can port the driver from upstream kernel code.