[CustomKernel] The Grinch 21.2.1 for Jetson TK1 / not developed

I’m assuming that all of the network issues are the previously reported netdev watchdog timer issue. What is interesting is that the reports I found related to this were from quite some time ago on x86 machines. In one such case the distribution that the bug was reported for simply closed the bug as no longer supported because it was so old. Sometime after this issue appeared, the error seems to have simply gone away.

Since I never saw a specific fix to the related driver, I can’t say as to whether this was part of the infrastructure surrounding RTL8169 or the driver itself, nor can I say which kernel version fixed this. It seems fairly obvious the long term stable 3.14.x kernels don’t have the issue, nor did the R19.3 L4T kernel. Packages surrounding user space are unlikely the cause, as L4T uses the more modern surrounding packages both in R19.x and R21.x. What would really help is to know the first kernel version where the problem went away…other than knowing a specific kernel version to target, I’m not sure of a good way to fix this other than going to a 3.14.x kernel (very labor intensive and not easy).

I mentioned this to Santyago in a PM, but it’s worth mentioning here.

My issues with the NIC on R21.2 did not happen when I had the thing plugged into the network at my office. It only happened on my network at home.

My home router is a piece of junk that was furnished by my ISP.

Still, I had no issues with R21.1 on the home network, so it seems to be a combination of things.

From what I can tell the issue is related to gigabit speeds only. So if one of the networks were 100 Mbit, it wouldn’t show up. On gigabit, it could show up with only a single connection. Even if your outside world is connected slow, a gigabit switch between Jetson and the link could conceivably have the issue. The issue is difficult to research since it happened so far back in time in the x86 world and current distributions are long past the issue.

Someone sticky this thread please. Thanks.

There is realy something wrong. I’m check other 1Gbit adapter - this same issue + AER errors.

It seems that the driver is not a problem. Everything is back to normal at the forced speed to 100mbps.

For now I don’t know what going on. I think it has to do with tegra-pci or clocks…

I decide skip 21.1 & 21.2 release and back to 19.3 development

@Shervin, you can unstick this topic?

21.2 is behaving very odd with wifi too. I have two broadcom adapters and one atheros based. All three exhibits random connection speed changes 1Mb - 140Mbps. Random connection dropouts… Situation is somehow better when bluetooth is turned off on atheros adapter. However, it is far from usable. I’m rolling back to 19.3

Ah, great howto. Thanks! What a bummer about ethernet though.
Could you consider adding FS support for DFS and ADFS file systems? (Acorn Archimedes).
This is pretty special I admit but probably also wont hurt anybody else :)

enthusi, i will try

Have you applied the modification from Apache14 about Tegra CEC.
The libcec can’t find the driver ?

no, not applied.

Btw, Grinch 21.2.x is stopped temporarily, until they do not solve the problem with the network. I have only one Jetson, making it difficult for me to work on several versions L4T

Good news! work on Gribch versions 21.x 19.x will be carried out simultaneously. big thanks to Dustin Franklin, who has supported me to buy a second Jetson!

Also a big thank you to Peter Bauer for the financial support!

Stay tuned!


You might as well add the fix I outlined in the post below, we pretty much have a fully working TegraCEC implementation, activating the CEC driver still doesnt register the platform device without this fix.

(Its only a 3 line fix)


I had to miss :) I’ll add it to the next version.

I got to this step:

Flash Jetson TK1:
1.sudo ./flash.sh jetson-tk1 mmcblk0p1

*** Flashing target device started. ***
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
USB device not found
Failed flashing ardbeg.

lsusb, and I get this:

Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I’m using an NVidia shield usb cable to connect my TK1 to my Win 8 laptop, which has VirtualBox running Ubuntu. You hold down the recovery button for a second, right?

Normal USB devices like mice and keyboards end with a “type A” connector. The micro connector on the Jetson is able to work with both a type A and a type B, but this changes the function of the Jetson itself. Type B is mandatory (this is the type of the supplied cable) during flash, as well as booting the Jetson into recovery mode. So the question is whether the shield cable is type B…if not it won’t work. Combine this with powering up the Jetson while the recovery button is held down (type B plus recovery causes the Jetson to be seen as an nVidia device on the linux host lsusb).

There have also been some issues with flash from a non-linux file system, e.g., NTFS underneath a virtual linux will fail. Remember that your linux host is copying files over to Jetson and preserving file types and permissions…if the underlying file system does not preserve this the install will not work.

Oh it’s working now. The trick is to hold down recovery and press reset. I got my TK1 working, launched GParted, and got this mesage. What do?

I recommend my gigabit ethernet solution:

I have not tried to use any application to expand a partition…but the difference between the absolute maximum partition size (14580Mib) and what many people use (14GiB) is tiny. You could try to let gparted expand to maximum size, and if it fails, flash with 14580GiB instead of 14GiB. Personally I’d just ignore it.

14580MiB ;)
but you could also use 14GiB and add a swap partition in the remaining 580Mb if you don’t have a SATA drive connected.