Does anyone here have upstream Linux/u-boot working with PCIe and the on-board Ethernet? I was intending to run the latest (4.1.1) on my board for a headless server. Figured the main deficits there would be video-related, which is fine with me. But I am having some trouble with the PCIe driver:
tegra-pcie 1003000.pcie-controller: resource collision: [mem 0x01000000-0x3fffffff] conflicts with pads [mem 0x01003000-0x010037ff]
and thus no network connection, since this is on PCIe.
The elinux wiki on upstream Linux spoke of ongoing work with PCIe, but I think that page is rather dated. Does anyone know where I can find out what is supposed to work, and what is known to not be working yet? Short of emailing Thierry and taking up his valuable time :)
Also, if anyone has a working .config for 4.1.x on their TK1 board, I’d like to compare with mine.
Thanks.
Wow, surprised that this did not garner more interest.
Anyway, answering my own question (at least in part), I found the kernelci.org automated build/test system and referenced their working .config for 4.1:
[url]http://storage.kernelci.org/mainline/v4.1/arm-tegra_defconfig/[/url]
Not sure exactly what my problem was previously, but now the PCIe and Ethernet are working.
Default configs for arm 32 bit are in arch/arm/configs/ in kernel source tree. For example: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/configs/tegra_defconfig?id=refs/tags/v4.1.2
To compile kernel for tegra do this:
make tegra_defconfig
Sweet. Didn’t know they had added arch-specific config templates; that’s very useful.
Next question, if I wanted to try out nvidia’s optimized OpenCV library (binary blobs), can that still be done with a recent kernel, or are there dependencies locking it to 3.10 / L4T?
Nvidia OpenCV needs CUDA. CUDA needs GPU drivers from nvidia. Nvidia drivers need Nvidia kernel driver(not nouveau) which mainline kernel doesn’t have. Porting this driver to mainline would be hard and time comsuming but not impossible. So for now unmet dependencies are kernel driver for tegra and their binary blob.
BTW. L4T 21.4 is out and supports newer Xorg abis (17, 18, 19). There might be a possibility to install newer version of native ubuntu on Jetson. Cheers
Meh, probably not worth it to me to be locked to L4T. This is mostly a headless server but I could imagine playing with CUDA/OpenCV stuff if available. Too bad they don’t use an open-source shim that can be compiled into any kernel, like they do with their desktop graphics drivers.
I’m planning to run debian; really don’t like ubuntu. Too many layers between me and the hardware. (debian is getting worse too)
I’m getting this on mainline 4.6 rc5 kernel. Any help?
[ 0.000000] Tegra clk 127: register failed with -17
[ 0.731115] +USB0_VBUS_SW: Failed to request enable GPIO108: -517
[ 0.731148] reg-fixed-voltage regulators:regulator@7: Failed to register regulator: -517
[ 0.731313] +5V_USB_HS: Failed to request enable GPIO109: -517
[ 0.731343] reg-fixed-voltage regulators:regulator@8: Failed to register regulator: -517
[ 0.731624] +1.05V_RUN_AVDD_HDMI_PLL: Failed to request enable GPIO63: -517
[ 0.731655] reg-fixed-voltage regulators:regulator@11: Failed to register regulator: -517
[ 0.731818] +5V_HDMI_CON: Failed to request enable GPIO86: -517
[ 0.731847] reg-fixed-voltage regulators:regulator@12: Failed to register regulator: -517
[ 0.732006] +5V_SATA: Failed to request enable GPIO242: -517
[ 0.732035] reg-fixed-voltage regulators:regulator@13: Failed to register regulator: -517
[ 0.732194] +12V_SATA: Failed to request enable GPIO242: -517
[ 0.732223] reg-fixed-voltage regulators:regulator@14: Failed to register regulator: -517
[ 2.904381] tegra-xusb-padctl 7009f000.padctl: failed to setup XUSB ports: -517
[ 2.915836] tegra-pcie 1003000.pcie-controller: Failed to get supply 'avddio-pex': -517
[ 3.811281] serial-tegra serial@70006000: failed to get alias id, errno -19
[ 3.818341] serial-tegra serial@70006040: failed to get alias id, errno -19
[ 3.833399] tegra-hdmi 54280000.hdmi: failed to get HDMI regulator
[ 3.971063] +VDDIO_SDMMC3: failed to get the current voltage(-22)
[ 3.977171] as3722-regulator as3722-regulator: regulator 13 register failed -22
[ 3.988340] as3722-regulator: probe of as3722-regulator failed with error -22
[ 5.086193] rt5640 0-001c: ASoC: Failed to add route DAC L2 Power -> direct -> IF2 DAC L
[ 5.101103] rt5640 0-001c: ASoC: Failed to add route DAC R2 Power -> direct -> IF2 DAC R
[ 5.687578] tegra-pcie 1003000.pcie-controller: Failed to get supply 'avddio-pex': -517
[ 5.696233] tegra-hdmi 54280000.hdmi: failed to get PLL regulator
[ 5.702940] tegra-ahci 70027000.sata: Failed to get supply 'avdd': -517
[ 5.709562] tegra-ahci 70027000.sata: Failed to get regulators
[ 5.768559] tegra-xusb 70090000.usb: Failed to get supply 'avddio-pex': -517
[ 5.775673] tegra-xusb 70090000.usb: failed to get regulators: -517
[ 5.819697] tegra-pcie 1003000.pcie-controller: Failed to get supply 'avddio-pex': -517
[ 5.828486] tegra-hdmi 54280000.hdmi: failed to get PLL regulator
[ 5.835456] tegra-ahci 70027000.sata: Failed to get supply 'avdd': -517
[ 5.842195] tegra-ahci 70027000.sata: Failed to get regulators
[ 5.858054] tegra-xusb 70090000.usb: Failed to get supply 'avddio-pex': -517
[ 5.858062] tegra-xusb 70090000.usb: failed to get regulators: -517
[ 5.873866] tegra-pcie 1003000.pcie-controller: Failed to get supply 'avddio-pex': -517
[ 5.874561] tegra-hdmi 54280000.hdmi: failed to get PLL regulator
[ 5.875255] tegra-ahci 70027000.sata: Failed to get supply 'avdd': -517
[ 5.875261] tegra-ahci 70027000.sata: Failed to get regulators
[ 14.060157] init: Failed to obtain startpar-bridge instance: Unknown parameter: INSTANCE
I too have begun bringing up a mainline kernel on our own board with a tegra124 (nearly identical to the jetson-TK1 but without Ethernet). I built the 4.7.2 using config/device tree modeled after those for the jetson.
Anyway it boots fine however USB can’t see anything but it’s own hubs (an I do have a USB device plugged in):
ubuntu@tegra-ubuntu:~$ uname -a
Linux tegra-ubuntu 4.7.2 #1 SMP PREEMPT Tue Aug 30 11:34:16 PDT 2016 armv7l armv7l armv7l GNU/Linux
ubuntu@tegra-ubuntu:~$ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
This broken peripheral issue might be something close to what mark999 saw with his broken pcie. Has anyone gotten to the bottom of this?
I couldn’t tell you what the correct setup is, but the device tree plus kernel command line options bind ports to controllers. What you see in this case of lsusb are controllers. To see devices attached to the controllers the ports have to be routed properly (perhaps ports are not reaching controllers). I think other PCIe issues are related to signals in the physical layer, rather than being due to basic configuration.
Part of this port routing configuration is controlled in kernel command line, and different drivers may alter what the kernel command line is seen by (what a driver uses from kernel command line is custom to that driver). Combined with device tree the kernel command line should link a port to a controller…if either are not matched, then there is essentially no way for a USB device to be seen by the controller. In this mainline kernel you need to verify the device tree is valid and that the kernel command line is used in the drivers.
Thanks for the input linuxdev. I can run one of either 2 builds:
- Linux 3.10 (from the jetson jetpack) or
- Linux 4.7.2 (my own mainline build)
In the former USB works and in the later it does not. Comparing the kernel command lines between the two (using cat /proc/cmdline) I find the two are identical. They both give:
ubuntu@tegra-ubuntu:~$ cat /proc/cmdline
console=ttyS0,115200n8 ignore_loglevel earlyprintk=ttyS0 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt
In our own board we have eliminated the pcie ethernet because we needed that ethernet interface for something else on our board. But we still absolutely require network connectivity and the plan was to use an ethernet USB dongle for that. That sort of works for a short while but we soon get error messages:
ubuntu@tegra-ubuntu:~$ [ 613.455711] cdc_ether 2-1:2.0 eth0: kevent 11 may have been dropped
and the network stops working. We also find this same behavior on the straight jetson board using unaltered code from the jetpack. The purpose of the attempt at a mainline build was to see if the issue was still present in a whole new kernel. But the failure of USB devices to be recognized in that kernel frustrates that test.
Correction:
“we needed that pcie interface for something else”
What driver does the ethernet dongle use? Also, what is the output of “ifconfig”? Should the errors/overruns/collisions be zero, then the error is likely all in the driver. If there are visible errors/overruns/collisions, then it may be a config issue.
Yes you are right- the errors/overruns/collisions were all 0 and the issue on the jetson with the nvidia 3.10.40 kernel was just a dongle driver issue. Everything works fine on another dongle. But the USB issue on the mainline 4.7.2 kernel still remains.
Quite apart from any issues related to drivers for whatever might plugged into the USB lsusb should still see whatever is in the USB slots. Is there some firmware blob relevant to the operation of the tegra’s USB that needs to be loaded into the chip? I saw some other post that seemed to imply this.
Also management here has decided that we should try to bring up the CUDA drivers on the 4.7.2 kernel. I image that the source for this driver is available somewhere in their devkit. Can anyone point me to where that might be? And is there also some binary blob that the CUDA part of the tegra needs in order to operate?
If so does such blob have any driver version dependencies? I’m guessing that no such dependencies exist- but if anyone knows otherwise I hope they will mention this.
This is probably only part of what you are wanting to know, I won’t claim the information is complete. The USB under non-L4T is likely quite different, but under L4T USB has some configuration in the u-boot boot loader (u-boot configures USB2); when execution transfers to the kernel, then the kernel changes what it does dependent upon the kernel command line. The default command line sets the full-sized USB connector to USB2 mode…this can be changed with a simple edit in extlinux.conf to become USB3. Should u-boot be USB2 and the kernel stays in USB2 mode you can boot off of devices using USB. Should the kernel switch mode from USB2 to USB3, you cannot boot from USB devices.
You can see what kernel command line was booted from via “cat /proc/cmdline”. You can edit “/boot/extlinux/extlinux.conf” and change “usb_port_owner_info=0” to “usb_port_owner_info=2” and get USB3 speeds. On a booted system “lsusb -t” shows USB2 nodes as “480M” and USB3 nodes as “5000M”. In a non-L4T kernel I do not know if drivers support the usb_port_owner_info syntax…individual drivers may be coded for different command lines.
Normally lsusb should indeed show a device even if the device does not have a driver. However, there can be one detail which gets in the way: If the USB device supports only USB3 with no backwards compatible USB2 modes, then the device may fail to respond to USB queries under USB2. It’s kind of rare and odd to see a USB3 device with no response to anything at all under at least a subset of USB2. What is common is that some devices are considered to only work for their major function via full USB3 bandwidth, and so part of the device will show up but the main function for data transfer just appears to not exist if query is via USB2 (e.g., some full motion cameras do not have a backwards compatible USB2 mode to operate in degraded resolution).
In the category of “it shouldn’t happen, but sometimes does”, power delivery to the USB device may be insufficient and cause the device to not show up. There are certain timing requirements as to how fast a USB device must show up and to how much power should be delivered in standby to make a USB device answer the “I am here” query, and sometimes even a device with enough power may not show up if power up timing is wrong. I always suggest using a powered HUB to avoid that question.
Finally, there have been issues with several USB devices not enumerating correctly from a suspend mode. You can disable USB auto-suspend to avoid this annoying possibility. Search for “USB” here:
[url]http://elinux.org/Jetson/Performance[/url]
CUDA and the video/GPU drivers are tied together. The nVidia video driver is binary only and source code is not available. So long as your X11 ABI stays constant you can probably use the existing binary video driver (this ABI in a newer Linux system would probably require downgrading the X11 server and infrastructure).
Thanks for your reply. You’ll notice in a previous post I had included the output of “cat /proc/cmdline” and (as noted) the output was identical between the L4T Linux 3.10 kernel with working USB and the mainline 4.7.2 kernel on which USB fails.
I’m using the exact same u-boot in both tests so any u-boot USB initialization should be the same in the two cases.
Are you saying that perhaps the L4T kernel knows what to do with the command line arguments to make the tegra USB work whereas perhaps the mainline kernel does not? Would you know where in the L4T kernel source this special command line/USB parsing etc. is done?
Thanks for your reply. You’ll notice in a previous post I had included the output of “cat /proc/cmdline” and (as noted) the output was identical between the L4T Linux 3.10 kernel with working USB and the mainline 4.7.2 kernel on which USB fails.
I’m using the exact same u-boot in both tests so any u-boot USB initialization should be the same in the two cases.
Are you saying that perhaps the L4T kernel knows what to do with the command line arguments to make the tegra USB work whereas perhaps the mainline kernel does not? Would you know where in the L4T kernel source this special command line/USB parsing etc. is done?
Also I should add that in the working L4T 3.10 kernel case I see this:
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
whereas in the broken mainline 4.7.2 kernel case I see this:
ubuntu@tegra-ubuntu:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
In the case of USB2 (which 480M implies) you see the driver is tegra-ehci. If it were USB3 it’d be the xhci instead of ehci. Both mainline and L4T kernels seem to use the same driver (the driver shown is only part of a chain of drivers though).
It is correct that possibly the mainline kernel does not understand the “usb_port_owner_info” because either (a) the proper Tegra driver is not configured, or (b) the configured driver differs and was not coded for this. Since you have the same command line and same driver in both cases, it implies either the tegra-ehci driver in mainline does not understand the usb_port_owner_info, or else somewhere else in a chain of dependencies some other part dealing with tegra-ehci does not understand usb_port_owner_info.
If you were to look at the kernel in R21.5 source code, subdirectory “arch/arm/mach-tegra/”, a search for “usb_port_owner_info” shows up in many places, e.g., via:
cd arch/arm/mach-tegra
egrep -R 'usb_port_owner_info' *
Several of those files may apply to ehci, e.g., many Tegra boards inherit from ardbeg. I do not have the 4.7.2 source code you are using, but if you go within 4.7.2 source and run the above search from its “arch/arm/mach-tegra/”, does usb_port_owner_info show up?
First of all everyday I find myself unable to log in to this forum because of “invalid credentials” errors. I keep signing up as new users to get back then I discovered that if I pretend that I ‘forgot’ my password and reset it I can get back in that way. Does anyone know who to contact about this problem?
Anyway I find no ‘usb_port_owner_info’ in 4.7.2:
dan@dan-MacBookPro:~/linux-4.7.2/arch/arm/mach-tegra$ egrep -R ‘usb_port_owner_info’ *
dan@dan-MacBookPro:~/linux-4.7.2/arch/arm/mach-tegra$
Another problem is that 4.7.2 has no idea that something must be done with the ‘tegra_xusb_firmware’ file:
dan@dan-MacBookPro:~/linux-4.7.2/drivers/usb/host$ egrep -R ‘tegra_xusb_firmware’ *
dan@dan-MacBookPro:~/linux-4.7.2/drivers/usb/host$
whereas L4T seems to use it somehow:
dan@dan-MacBookPro:~/linux-3.10/drivers/usb/host$ egrep -R ‘tegra_xusb_firmware’ *
xhci-tegra.c:#define FIRMWARE_FILE “tegra_xusb_firmware”
dan@dan-MacBookPro:~/wilberth/linux-3.10/drivers/usb/host$
Perhaps at the point the tegra code was pushed upstream there was no tegra model that needed to load firmware for USB?