If I’m thinking correctly, virtualbox uses software emulation of usb ports for its guests.
Only VMware uses actual pass-through. My biggest problem with Microsoft hyper v is the lack of usb pass-through for non disk devices. 3rd party software gets it done in some cases but nothing like VMware.
By the way, the atk9k problem can be reproduced using rfkill (without using shutdown):
ubuntu@tegra-ubuntu:~$ sudo rfkill block wifi
[ 257.847734] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
[ 257.854780] Internal error: : 1406 [#1] PREEMPT SMP ARM
[ 257.859994] Modules linked in: bnep rfcomm bluetooth dm_crypt parport_pc parport rtc_as3722 ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill nvhost_vi
[ 257.874289] CPU: 0 PID: 1286 Comm: rfkill Not tainted 3.10.24-grinch-19.3.5 #3
[ 257.881498] task: eb629080 ti: edb60000 task.ti: edb60000
[ 257.886894] PC is at ath9k_ioread32+0x38/0x78 [ath9k]
[ 257.891945] LR is at ath9k_hw_wait+0x74/0xa4 [ath9k_hw]
...
I’m going to try moving to grinch-19.3.6 …
UPDATE:
Switching to grinch-19.3.6 made no difference.
I tried switching to the Atheros AR5B195 mini pcie (AzureWave AW-NB037H), and now shutdown / restart seems to work ok. As an added bonus, it appears that bluetooth is now available as well, though I haven’t tested it.
After I fail to flash the board I follow the Hint#1, then flash is success and boot into Ubuntu 14.04 after it finish. But problem is that when I restart the board it will go blank after the Nvidia(beta driver) logo show up. I flash it one more time and got the same result. I tried ssh into the board and it’s working fine, just unable to display a graphic
Then I change the line 284 from Hint#1 back, this time flash is successful and I able to reboot into Ubuntu.
I am new to this board, just hope this info will be useful to others developers ;)
I haven’t installed grinch myself, but in general the flash.sh script uses the “-L” option for naming boot loader. For u-boot that comes with L4T:
-L bootloader/u-boot.bin
Fastboot depends on the kernel being in the 6th partition (-k 6), but u-boot depends on zImage being in /boot. So before you flash, copy zImage to /boot. If you are just flashing kernel and boot loader, the system.img and sample rootfs shouldn’t be used, and so the new u-boot wouldn’t be able to see your new zImage without it being manually put in /boot. You can edit the /boot/extlinux.conf and copy the default boot image to dual boot…simply put your zImages in /boot with a different name on each, e.g., zImage-uname -r, and edit copies of the original extlinux.conf entries.
Each extlinux.conf entry is accessible via serial console if you are quick on the keyboard…if you actually hit a key at serial u-boot prompt too soon, just type “boot”, enter, and hit a key again…u-boot’s first prompt is for command line, the second prompt is kernel selection via extlinux.conf. At least in R19.3, the .uimg format is no longer used for u-boot…this file can be ignored; I’m not sure how recently they changed this.
The losetup loopback issue was reported to nVidia shortly after R19.3 was released. It’s possible they will change this part in the flash.sh whenever a new L4T version is released for Jetson. In the meantime, all you can do is beware that /dev/loop0 is already in use on some systems, or non-existent until generated on more purely udev systems.
My guess as to why yours wasn’t changed is probably linked to how you extracted the tarballs and ran the scripts. Were you sudo sh the entire time or only sudo when you to had to be?
I always run as root on my host machine when setting up for flash; apply_binaries.sh was used to add libglx.so to the sample rootfs (and this is copied into system.img and burned to Jetson). I have not had to deal with it since flash to L4T R19.3. Within R19.3 I have done apt update and upgrade many times with no issue. Unfortunately, I have never had to admin a debian-based system, so I don’t know how to tell apt to leave this file alone. However, there must be a way on systems which have overwritten this file to query apt and ask it which package it thinks the file belongs to; this would lead to a way to blacklist the offending package.
Hey Santyago, I really appreciate your effort creating the enhanced kernel “the grinch”. It’s working very well. One minor thing is that I’m facing crashs on start up (kernel panic?) while my pcie wlan card (centrino n 1000) is installed. I already added it to the “famous” Network Adapter list on elinux.org as mentioned above.
Another thing which caught my attention is the bullet point “Adding Tegra CEC support” in your latest release. My wish is to make use of the HDMI CEC in a HTPC setting. Could you please provide some additional information? Does this mean the Jetson TK1 is capable of HDMI CEC? And if so, how do I activate it?
I already tried - following some advice I recently found on the net - to list possible CEC devices, but all I got was “Found devices: NONE”. My TV or the recently installed Kodi/XBMC does not find the CEC device either.
To conclude: What’s behind that Tegra CEC? Am I heading in the right direction, do I need a special driver or is there no HDMI CEC at all included?