Wifi dies after using shared kernel (Auvidea J20 / Imx219)

Hi,
Really stuck on this one and cant figure out what the problem is, a friend of mine witch has the exact same revision (B04) on his tx2 (28.2) as i do, but he can not use a “image” file and dtb created on my tx2.

I tar’d down my newly compiled image file from /boot and my dtb, he copy’s the image manually to /boot on the tx2 (and check the permissions) and flashes the dtb from the host with:

sudo ./flash.sh -r -k kernel-dtb -d ./dtb/tegra186-quill-p3310-1000-a00-00-base.dtb jetson-tx2 mmcblk0p1
(like to have it in it’s own folder, faster to flash back the original if something goes wrong).
Flash successfully finished.

This work just like it should on my system, i boots up, finds my Auvideo J20 and finds the IMX219, it also
works on his system, captures video without any problem so that shows the dtb and imx219 driver s working.

But, he losses wifi (my wifi is just fine) , it’s no where to be found, nothing in system settings / network and does not seem to be started at all in dmesg.

So, i decided to send him a more resent version of my dtb and image today, that i fix some imx219 problems in (again works perfect on my tx2) but now he got to the nvidia login screen and it he pressed the password box the screen turn blue, and is now blue on every reboot.

easily fixed by doing a:
sudo ./flash.sh -k kernel jetson-tx2 mmcblk0p1
and a :
sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

in recovery, but why does this happen ? copying the kernel and flashing only that dtb should be fine, or am i missing something ? :)

btw, i build the kernel by using GitHub - jetsonhacks/buildJetsonTX2Kernel: Build the NVIDIA Jetson TX2 Kernel on the device itself and then i build the dtb by doing a sudo make all in src/kernel/kernel4.4

Include the dmesg from his system,dont mind the J20 / imx219 errors, he had video, and the errors are now fixed, but it got worse as you can read…

mydmesg.log (85.5 KB)

Spawn32,

I cannot see any log related to probing wifi in your dmesg. May I ask why your friend cannot use jetpack but your image and dtb?

Hi WayneWWW.

Yes, that is the strange bit, it dosen probe or have any messaged about the bcm, wl or wifi in the dmesg.

He need to use my dtb and kernel because it contains a driver for the Auvidea J20 camera interface and the raspberry pi imx219 camera’s, that are going to be used in our robotics project.

Is there som security / encryption / signing going on in 28.2 that can make this happen ? very strange when it works on 1 of 2 identical platforms.

Or is it more than just that one dtb he needs to be flashed ,we also tested with all 5 dtb’s from my sudo make all", but got the exact same result, the J20 and the imx219 worked, but no wifi…

And we can still just copy the image file like on earlier jetpacks ? dtb is the only thing that needs flashing ? is the Zimage also needed ?

If we can’t solve this we need to setup a “build” environment on his tx2 and generate the kernel and dtb on his own system, was hoping to avoid that.

Or do a full backup of my system, but that’s a 32gb file…

And as i said, if he restores he’s own dtb’s and kernel from his jetpack he get’s the wifi back, i am really puzzled…

Some notes (things to consider…this isn’t an answer)…

zImage is not used with this version of U-Boot (64-bit). Use the Image file (or renamed to not overwrite the original). Kernel target “make Image” is all you need. “make zImage” builds both zImage and Image, but you will never use zImage with this version of U-Boot on 64-bit systems.

There are many partitions other than rootfs. If you clone a kernel and rootfs from one to another, then the base version has to be the same. For example, if two systems were originally R28.2, then the rootfs and kernel will be portable across the two. If the base version is different, then you can expect to run into many issues by transplanting a kernel or rootfs from one to the other (e.g., a rootfs of R28.1 may have a lot in common with R28.2, but there will be failures).

If you copied a dtb to “/boot”, then it won’t work on any of these newer releases.

Hi linuxdev, and thanks for your input :)

Yes, i read that we dont need the zimage anymore, but since this fault is so strange i had to ask…

We downloaded and reinstalled our jetpack’s with just a few day between (2 weeks back) , i am using the *b196.run version and he is checking his right now. but they should be the same.

the image is copied to /boot on both systems and the dtb is flashed with:
sudo ./flash.sh -r -k kernel-dtb -d ./dtb/tegra186-quill-p3310-1000-a00-00-base.dtb jetson-tx2 mmcblk0p1

on both system’s, min works like it should, his dose not have wifi, crazy :)

i am building the kernel on target using the jethacks scripts, could this make any difference ?
I know the “official” way is building on host.

the dtb is compiled on target, but no scripts, just “sudo make all” in src/kernel/kernel4.4, i then transfer the dtb to the host and flash it…

It sounds like it would work, but I am not familiar with the script so I can’t guarantee it.

What I’d suggest is that on the running systems, both flashed using the same exact dtb files, create a copy of “/proc/device-tree/” and then diff the files. So on each Jetson (use sudo if needed…probably not needed):

dtc -I fs -O dts -o extracted.dts /proc/device-tree

• Then compare your two extracted.dts files with diff. See if they are the same.
• Check if your "/proc/cmdline" shows the same on both.
• Check if your "uname -r" is the same on both.
• cd to "/lib/modules/$(uname -r)/. See if "du -s ." matches (just assuming file sizes will be the smae).
• See if both show the same output from "lsmod".

Do note that in R28.2 (you didn’t say if it was R28.2, but using JetPack3.2 would use this) there is now a signature at the start of the dtb partitions. If you each compile your own version from the same specs there could still be a difference in signature (but I don’t know how the signature mechanism works). I am assuming that the output of “/proc/device-tree/” will not change so long as the dtb is not rejected. Signature is added during the flash and dtb in most ways won’t care about this.

Thank you linuxdev, you seem to be a endless source of information :)

yes, we are both on 28.2 final release.
I will go through everything you wrote and check it.

Got a bit more info now, if he flashes back his own dtb’s the Auvidea J20 stops and the video sources are no longer in his /dev (of course), but that dosent fix the wifi problem, but when he also copys back his own original kernel image his wifi is back, dont know if that rings any bells ?

Compare the content of “/proc/config.gz” for kernel differences between the kernel which works and the one which does not.

I don’t know how much of this applies to the Auvidia board, but see if you get “ok” or failed from files in both your working system and the failing system via:

sha1sum -c /etc/nv_tegra_release

The Auvidea J20 / imx219 driver is now finalized, so will do a new test on the other TX2 system tomorrow and report back…

Spawn32,

I have several wifi topics recently. Below one has something to check, though it is a tx1 topic.
https://devtalk.nvidia.com/default/topic/1035709/

In your dmesg, I saw “[ 3.343242] mmc1: new ultra high speed SDR104 SDIO card at address 0001”, which indicates the wifi chip is still detected by mmc. It indicates the wifi hardware is still working but sw configuration is wrong.

Please try to follow above topic link(debug starts from #17) and share some info with us.

Spawn32,

Any update?

Hi WayneWWW,
We never found out what caused this, did som debuging, se the log her:

nvidia@tegra-ubuntu:~$ sha1sum -c /etc/nv_tegra_release
/usr/lib/xorg/modules/extensions/libglx.so: OK
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketserver.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomxilclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvidia-egl-wayland.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamerautils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_graphics.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvosd.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_2d_v2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtestresults.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_vic.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamlog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvparser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_image.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_gpu.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_parser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcameratools.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvimp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnet.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libscf.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libglx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_contentpipe.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtnr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstorehdfx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtvmr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstream_camconsumer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstoredefog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_video.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvavp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvll.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvdc.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcolorutil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvapputil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvos.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmedia.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvodm_imager.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcam_imageencoder.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvwinsys.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstreamproducer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvexif.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtx_helper.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvideocodec.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvidconv.so: OK
nvidia@tegra-ubuntu:~$ xxd /proc/device-tree/bcmdhd_wlan/status
00000000: 6f6b 6179 00 okay.
nvidia@tegra-ubuntu:~$ ls /lib/firmware/brcm/
fw_bcmdhd.bin nvram.txt
nvidia@tegra-ubuntu:~$ /etc/modprobe.d$ lsmod
bash: /etc/modprobe.d$: No such file or directory
nvidia@tegra-ubuntu:~$
nvidia@tegra-ubuntu:~$ /lib/modules/4.4.38-tegra/kernel/drivers/net/wireless/bcmdhd$ ls
bash: /lib/modules/4.4.38-tegra/kernel/drivers/net/wireless/bcmdhd$: No such file or directory
nvidia@tegra-ubuntu:~$

There was just no way he could use my kernel “image” and my dtb, he got video from the Auvidea J20 / IMX219, but the wifi would always be missing.

So i gave up and we setup a build environment on his TX2 (jetsonhack) he then compiled my driver sources and dtsi’s , copied the new kernel and flashed the new dtb and all was ok, he got Video and wifi… :)

Could it be something to do with the new dtb signing ?