Also you mention “So long as your X11 ABI stays constant you can probably use the existing binary video driver…”. Won’t that refuse to even load due to the kernel version mismatch?
For forum account help, the bottom of forum pages have a link “Contact Us” (which is the same link as shown in “Support”). That URL is [url]https://developer.nvidia.com/contact[/url].
I have noticed lately that there are times when particular threads just don’t respond for a long time, but then they later start working again.
In terms of the dtb expect this to be loaded and used within the nVidia version of u-boot…other versions probably won’t read this by default unless those versions also understand ext4 file systems (extlinux.conf is on ext4, and extlinux.conf is what points at the dtb file for boot loader). The boot loader would use those values for an initial setup, and as the kernel loads, this would basically be inherited even though it is u-boot that reads this. I do not know if the kernel will also read this later…perhaps it does. The firmware which the kernel itself always loads is that within “/lib/firmware/”. It would be expected that the dtb makes initial setup to where other firmware can be loaded, then the “/lib/firmware/” is loaded, and that the two work together as essentially an API for driver access. So these three things must use matching versions, but each covers a different aspect of making the hardware function: (A) dtb, (B) “/lib/firmware/”, and (C) kernel drivers. If just one of them has a different idea of what is going on, then you can expect either failing devices or odd behavior with unexpected consequences.
I do not know the particulars of matching the nVidia video binary to a new kernel, but if you have X11 on a newer Linux distribution release, and then downgrade X11 to match the older X11 ABI used by the nVidia binary, then you may also find that this binary could be used by that newer kernel. Possibly you would have to do something to force version checking to be disabled on load (having the driver accepted by the kernel won’t help if X11 of that older version is not supported). If you can load the older Nouveau driver with the older ABI then I’d expect that switching to the nVidia driver has a reasonable chance to succeed (which also means CUDA has a chance to succeed). Match the kernel and older X11, then graft in the nVidia binary.
I did an experiment on my working L4T 3.10 system on which USB works fine:
ubuntu@tegra-ubuntu:~$ lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
ubuntu@tegra-ubuntu:~$
I then deleted /lib/firmware/tegra_xusb_firmware and rebooted. And USB still was working fine. So it does not appear that the issue is with the failure to load that file.
You can easily pull down the 4.7.2 kernel release from kernel.org and do a make jetson-tk1_defconfig (it IS in the upstream release) and put that on your jetson and you’ll no doubt see the USB failure I see…
For what I’ trying to do I’m using:
(A) dtb (built for jetson-tk1 from device tree in 4.7.2 from kernel.org)
(B) “/lib/firmware/” (from rootfs that came with jetpack)
(C) kernel drivers (built using jetson-tk1_defconfig from 4.7.2 from kernel.org)
Also our intended system will simply not have X11. It’s a headless embedded system but does need CUDA for some heavy computation unrelated to graphics.
I’m not positive but I think that firmware xusb file implies it only matters when in USB3 mode. The 480M listed in the earlier lsusb -t shows USB2 only. If you don’t need USB3 you don’t need that firmware.
Note that a dtb file does not work independently of other software. This dtb is tied to other firmware files as well as the source code of the drivers. If any of those three things do not match you will have no effect or odd and disastrous effects. Working as intended will not be one of those effects. Firmware may not be an issue if USB stays in USB2 mode, but USB hardware will probably ignore your dtb in that case.
You will probably simplify life if you install a virtual X11 server which is more or less only for remote desktop software or X11 developers. It would be interesting to see if the binary nVidia GPU driver can be made to function with no X11 server, but I would expect having a fake X11 server is a far easier project. As a side effect if you can’t get that older Xorg ABI working on the newer kernel with the Nouveau driver I wouldn’t expect it to be possible to get it to work with the nVidia driver…you might want to think of getting the older ABI working on the newer kernel as a validation step even if you don’t keep the Xorg server after you are done.
You say “This dtb is tied to other firmware files as well as the source code of the drivers.”. For our case the dtb and kernel drivers are both built from the code that comes with the 4.7.2 Linux kernel- so those two should match one another. If what we really need is the “Linux 4.7.2 version” of the firmware blobs we’re out of luck as only Nvidia can generate these images (is that correct?).
Anyway we have established that the USB firmware image is not even being used in our USB 2.0 case. I suppose that it’s possible that the issue is some mismatch with some other firmware binary. But this seems unlikely since other peripherals (like Ethernet) are working just fine under 4.7.2- firmware versions be damned.
For us if we cannot have a working USB getting the CUDA up is irrelevant. Please let us know if you have any other suspicions we might test out in the mystery of the dead USB.
Assuming we are able to surmount the USB issue somehow you say that for the driver we probably must confine ourselves to “the existing binary video driver”. Just to make sure there is no confusion can you tell me the name of the binary file you’re referring to and where it might be found?
Also on the page:[url] http://elinux.org/Tegra/Mainline_SW/Linux_kernel[/url] it lists:
A probably-incomplete list of features that are not yet implemented is:
…
PCIe on Tegra124. Thierry Reding is working on this.
…
Of course we’re using the Tegra124 and the reason we need to use the USB for our network connection is that on our board we have eliminated PCIe-based Ethernet to free up that interface for our board’s main function. In short we absolutely require a working PCIe on our Tegra124 board.
Can you tell me the status of that development?
I should add that firmware must also match the hardware…so there are 4 associations, not 3. When firmware is involved in USB on a Jetson the firmware generally is not “generic”…the driver code can be generic if the firmware puts the hardware in a standardized configuration. Lib firmware goes into the device, dtb goes into controller setup, this combination is somewhat analogous to a function signature…then the driver must use the function signature of the combined dtb/firmware/hardware. Unlike a regular C program where there are headers to find things in a safe manner (the compiler complains about signature mismatches) direct hardware access has no such safety…it’s taken on faith that the device and its controller are in agreement about how to access the device. What the “device” is depends on firmware currently loaded into it.
With a generic mainline kernel I do not know if the more specialized firmware provided by the generic kernel source understands the specific Tegra SoC hardware (it might). If it does, then the second question is whether the driver uses the same API and schema for accessing the hardware (if that API differs from a binary-only format driver you are out of luck). The firmware coming with L4T is guaranteed to be correct for the device, although the newer driver may be mismatched (or not) in some way…the newer firmware with the mainline kernel would match the drivers, but we don’t know if it matches the hardware. However, I do not think the firmware files for USB are anything special…WiFi is special because of FCC certification, video drivers are special because they are proprietary, but there is a reasonable chance USB can work from mainline (for USB it is a case of try it and find out).
I do not know the whole list of files you are interested in, at least not conclusively. Within the driver package (not the sample rootfs) is the nv_tegra subdirectory. This contains “nvidia_drivers.tbz2”. That file contains most of the binaries in question, although kernel modules are separate. The files of that tarball going to “usr/lib/xorg” or subdirectories are directly related to video/GPU hardware. Indirectly some of the libraries may require those versions to work with or link to…newer libraries from mainline which have the same API version likely work, other libraries with a different version will fail if the nVidia binaries must link to them.
The “kernel” subdirectory contains “kernel_supplements.tbz2” and has kernel module/driver support files. The files under “video” are directly related to video; some files there may be indirectly related for functions like memory controller…Tegra SoCs connect directly to the memory controller rather than through PCIe. Thus the video files may have a dependency on the memory controller software as well. There may also be some drivers which only load if a dependency driver is loaded, and the dependency must fulfill the requirements of the more obvious binary (one binary can result in a long chain or tree of other files needing to be preserved).
I have no knowledge of mainline PCIe support.
Thanks linuxdev. Are you an NVidia employee? If so can you point me to someone there who could tell me the status of bringing up the PCIe on Tegra124? If that is simply not going to work anytime soon then the rest of my issues become academic.
I am not employed by nVidia although I have an interest in evolving the nVidia embedded product support in the Linux environment. Several employees of nVidia browse the forums on a regular basis, but I’d expect the Labor Day holiday to have some of them temporarily unavailable.
The person to talk to if you need to get a direct contact is “dusty_nv”…he has the nVidia moderator logo on his posts. If you go to one of his posts you can message him directly. For example Dusty started this thread and you could probably direct message him from the icon under his name:
[url]https://devtalk.nvidia.com/default/topic/902307/jetson-tx1/edu-discount-for-jtx1/[/url]
There is also the “contact us” link at the bottom of the forum pages:
[url]https://developer.nvidia.com/contact[/url]
Thanks. Clearly PCIe must be working in the latest Linux kernel 4.7.2 because the jetson-tk1 Ethernet works just fine under that kernel and that’s connected via PCIe.
Oddly I find I can take the straight jetpack u-boot and rootfs and simply drop in zImage and tegra124-jetson-tk1.dtb I build in the mainline Linux 4.7.2 source. And absolutely everything is working just fine… EXCEPT USB.
Okay- I have not touched the “nvidia driver” for which no source is available. I would guess that that binary file would have a .ko extension if it is (as I assume) a loadable kernel driver. But there are simply no .ko files at all in nvidia_drivers.tbz2. I am still unclear as to where to fine this mysterious file and what it might be named. If you can enlighten me please do.
The .ko files are in the kernel supplements file of the kernel directory (apply_binaries.sh unpacks several tar archives).
Thanks- yes I do see:
./lib/modules/3.10.40-ga7da876/extra/edp/edp_debug.ko
./lib/modules/3.10.40-ga7da876/extra/mem_translation/mem_translation.ko
./lib/modules/3.10.40-ga7da876/extra/hsi/hsi_test.ko
./lib/modules/3.10.40-ga7da876/extra/timekeeping/time_test.ko
./lib/modules/3.10.40-ga7da876/extra/crypto/crypto_kpi_test.ko
./lib/modules/3.10.40-ga7da876/extra/tegra_config/tegra_config.ko
./lib/modules/3.10.40-ga7da876/extra/scheduler/scheduler_test.ko
./lib/modules/3.10.40-ga7da876/kernel/net/wireless/cfg80211.ko
./lib/modules/3.10.40-ga7da876/kernel/net/bluetooth/rfcomm/rfcomm.ko
./lib/modules/3.10.40-ga7da876/kernel/net/bluetooth/bnep/bnep.ko
./lib/modules/3.10.40-ga7da876/kernel/net/bluetooth/bluetooth.ko
./lib/modules/3.10.40-ga7da876/kernel/net/bluetooth/hidp/hidp.ko
./lib/modules/3.10.40-ga7da876/kernel/net/rfkill/rfkill-gpio.ko
./lib/modules/3.10.40-ga7da876/kernel/net/rfkill/rfkill.ko
./lib/modules/3.10.40-ga7da876/kernel/net/mac80211/mac80211.ko
./lib/modules/3.10.40-ga7da876/kernel/fs/configfs/configfs.ko
./lib/modules/3.10.40-ga7da876/kernel/fs/cifs/cifs.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/iwlwifi/dvm/iwldvm.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/iwlwifi/mvm/iwlmvm.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtl8188ee/rtl8188ee.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtl8723ae/rtl8723ae.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtl8192se/rtl8192se.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtl8192ce/rtl8192ce.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtl8192c/rtl8192c-common.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/wireless/rtlwifi/rtl8192de/rtl8192de.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/slip/slhc.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/pppopns.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/pppolac.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/ppp_generic.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/ppp_async.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/ppp_deflate.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/ppp_synctty.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/ppp_mppe.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/pppox.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/net/ppp/bsd_comp.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/bluetooth/btusb.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/md/dm-crypt.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/md/dm-mod.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/video/tegra/host/vi/nvhost-vi.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/input/joystick/xpad.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/input/joydev.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/usb/class/cdc-acm.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/usb/class/cdc-wdm.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/usb/gadget/g_ether.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/usb/gadget/g_mass_storage.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/usb/gadget/libcomposite.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/usb/serial/baseband_usb_chr.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/media/platform/soc_camera/soc_camera_platform.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/media/platform/soc_camera/tegra_camera/tegra_camera.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/media/usb/gspca/gspca_main.ko
./lib/modules/3.10.40-ga7da876/kernel/drivers/media/v4l2-core/videobuf2-dma-contig.ko
./lib/modules/3.10.40-ga7da876/kernel/crypto/twofish_common.ko
./lib/modules/3.10.40-ga7da876/kernel/crypto/sha256_generic.ko
./lib/modules/3.10.40-ga7da876/kernel/crypto/md4.ko
./lib/modules/3.10.40-ga7da876/kernel/crypto/twofish_generic.ko
./lib/modules/3.10.40-ga7da876/kernel/crypto/tcrypt.ko
But which is the “nvidia driver”.
Also please have a look at my most recent post to here:
“[mainline kernel] USB not working”
and tell me if you happen to know anything about that issue.
Thanks!
Quite often a kernel module does not work by itself, but you’ll notice that the path in the module subdirectory more or less matches where the driver is located in the kernel source (which also corresponds to the configuration system when something like menuconfig offers to set up an option). As an example, the video driver is here, but, nvhost-vi.c is not in the published kernel source…some other modules are directly in the kernel source:
.../3.10.40-ga7da876/kernel/drivers/<b>video</b>/tegra/host/vi/nvhost-vi.ko
Only the “extra” directory will not necessarily have some corresponding kernel source tree location match. I can only guess that relevant USB driver is somewhere here:
.../3.10.40-ga7da876/kernel/<b>drivers/usb/class/</b>
Note that “gadget” subdirectory is not related to a normal host USB system, so this can be ignored (gadgets produce devices and do not act as host). Keep in mind that these are just the nVidia install-time kernel modules, that there may be more modules related to USB in those directories if a config has changed. Should you find a specific change between the 3.10 kernel and 3.13 kernel in a specific USB file, and if that change is what makes the hardware work with the kernel, then chances are good this can be backported in and also work.