I have a board TSI721, it can be detect in uboot, but can’t be found in kernel, I use lspci to check it. I know the kernel source include the driver. can you tell me how to enable it?.
thanks.
Hi all, anybody can help me? it block me long time. thanks.
I’m probably not able to help much on this, but lspci won’t show if the signal is really bad. Does the card work on another Linux machine, and if so, what does lspci show on the other Linux machine?
In lspci you’ll see the first column which describes where on the bus device is, e.g., it’ll look something like “01:00.0”. The “-s” option will pick just that device, and if you use sudo, then “-vvv” will give maximum information about the device. Try this from another working Linux system (substitute “01:00.0” with the actual value):
sudo lspci -s 01:00.0 -vvv
Also, you might check dmesg right after boot. There could be some PCIe information in there offering clues.
hi linuxdev, the following is the output in Uboot and Kernel.lspci is nothing to output.
the display in uboot:
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class Sub-Class
00.01.00 0x10de 0x0fae Bridge device 0x04
the display in kernel:
ubuntu@tegra-ubuntu:~$ lspci
ubuntu@tegra-ubuntu:~$ sudo lspci
[sudo] password for ubuntu:
ubuntu@tegra-ubuntu:~$ dmesg |grep pci
[ 0.610239] platform 1003000.pcie-controller: domain=ffffffc0fe27d558 allocat
es as[0]=ffffffc0fe1e83e8
[ 1.953041] tegra-pcie 1003000.pcie-controller: PCIE: Enable power rails
[ 1.958997] tegra-pcie 1003000.pcie-controller: probing port 0, using 4 lanes
and lane map as 0x14
[ 1.969060] tegra-pcie 1003000.pcie-controller: probing port 1, using 1 lanes
and lane map as 0x14
[ 1.999182] tegra-pcie 1003000.pcie-controller: link 0 down, ignoring
[ 2.003628] tegra-pcie 1003000.pcie-controller: link 1 down, ignoring
[ 2.010067] tegra-pcie 1003000.pcie-controller: PCIE: no ports detected
[ 2.016821] tegra-pcie 1003000.pcie-controller: PCIE: Disable power rails
[ 3.713392] ehci-pci: EHCI PCI platform driver
I’ve never thought about whether the device tree has any effect on PCIe, but if it does, then it is possible your device tree was not passed on to the Linux kernel. Anyone know if PCIe has any device tree requirements? If so, then this would make sense as to why U-Boot sees things, but Linux does not (I’m looking at a TX2 and don’t have my TX1 sitting where I can test right now, but a TX2 dmesg output says probably the device tree matters).
One thing to know is that if no PCIe device is plugged in that lspci does not normally show the PCIe bridge under Linux (perhaps this is a side-effect of how it is wired to the memory controller). If you have a PCIe device actually connected then the bridge shows up via lspci. I would assume that even if there is a device connected, that if that device has issues and won’t show up, then the bridge too won’t show up even if the bridge is functioning as expected (this is part of the module so I don’t think carrier board would have any effect on this).
What is the output of this:
dmesg | egrep '(PCI|pcie)'
hi linuxdev,
my kernel code is r24.2.1,please help me check if my configuration of device tree is right.
dmesg | egrep ‘(PCI|pcie)’
[ 0.610215] platform 1003000.pcie-controller: domain=ffffffc0fe26d558 allocat
es as[0]=ffffffc0fe1e83e8
[ 1.673043] PCI: CLS 0 bytes, default 64
[ 1.953129] tegra-pcie 1003000.pcie-controller: PCIE: Enable power rails
[ 1.959128] tegra-pcie 1003000.pcie-controller: probing port 0, using 4 lanes
and lane map as 0x14
[ 1.969168] tegra-pcie 1003000.pcie-controller: probing port 1, using 1 lanes
and lane map as 0x14
[ 1.999290] tegra-pcie 1003000.pcie-controller: link 0 down, ignoring
[ 2.003736] tegra-pcie 1003000.pcie-controller: link 1 down, ignoring
[ 2.010175] tegra-pcie 1003000.pcie-controller: PCIE: no ports detected
[ 2.016926] tegra-pcie 1003000.pcie-controller: PCIE: Disable power rails
[ 2.817414] ehci-pci: EHCI PCI platform driver
the configuration of device tree:
tegra210-jetson-2597-2180-a01-devkit.dts–>tegra210-jetson-cv-base-p2597-2180-a00.dts
pcie-controller {
nvidia,wake-gpio = <&gpio TEGRA_GPIO(A, 2) 0>;
nvidia,lane-map = <0x14>;
dvdd-pex-pll-supply = <&max77620_ldo1>;
l0-dvddio-pex-supply = <&max77620_ldo1>;
l1-dvddio-pex-supply = <&max77620_ldo1>;
l2-dvddio-pex-supply = <&max77620_ldo1>;
l3-dvddio-pex-supply = <&max77620_ldo1>;
l4-dvddio-pex-supply = <&max77620_ldo1>;
l5-dvddio-pex-supply = <&max77620_ldo1>;
l6-dvddio-pex-supply = <&max77620_ldo1>;
hvdd-pex-pll-e-supply = <&max77620_sd3>;
l0-hvddio-pex-supply = <&max77620_sd3>;
l1-hvddio-pex-supply = <&max77620_sd3>;
l2-hvddio-pex-supply = <&max77620_sd3>;
l3-hvddio-pex-supply = <&max77620_sd3>;
l4-hvddio-pex-supply = <&max77620_sd3>;
l5-hvddio-pex-supply = <&max77620_sd3>;
l6-hvddio-pex-supply = <&max77620_sd3>;
vddio-pex-ctl-supply = <&max77620_sd3>;
status = “okay”;
iommus = <&smmu TEGRA_SWGROUP_AFI>;
pci@1,0 {
status = “okay”;
};
pci@2,0 {
status = “okay”;
};
};
I can’t answer if the device tree is correct, but the dmesg logs indicate the Jetson thinks nothing is plugged into PCIe. This could be a case of not having device tree configured, or it could be such bad signal that not even control out-of-band is visible. Someone knowing more about PCIe and device tree will have to answer whether it is possible for PCIe to see devices…if so, then it is most likely a signal issue.
hi linuxdev,
I found my card is ok in Kernel 4.10.8, so it can confirm the device is ok, I try to merge the device tree from 4.10.8 to r24.2.1, but the system hang up. so far I think it relate to device tree. as you know 4.10.8 have a lot of differnet with r24.2.1(3.10.96).do you have some suggestion?
Regards
jianlin
Device tree is closely tied to drivers, and the kernel changed from a 3.x series to 4.x, so is expected that there would be some major device tree changes. Someone else will have to help you find out if your device tree is an issue for detecting the TSI721.
The TSI721 probably has a lot in common with bringing up an FPGA as an end point and I am unable to give a check list of what is needed for making the bridge visible. I suspect debugging its visibility (considering U-Boot confirms the signal should work) might be possible for someone who has also worked on bringing up a PCIe FPGA (e.g., delaying enumeration for some initialization to occur first).
Hi linuxdev, I found r27.1 had upgrade the kernel to 4.4.15, and I found some config(tegra21_defconfig) file under arm64. can I use it in TX1?
I try to build the image, but it can’t found the dts file. and it is hang up to use the image file.
do you have any way?
thank very much!
regards
jianlin
R27.1 only applies to a TX2…TX1 cannot use this, and most recent on a TX1 is R24.2.1 (there will be a future release in which the TX1 gets a 4.x series kernel, but I don’t know any details about that). R24.2.1 should work if the signal quality is good enough.
There is no way I can help with knowing if your device tree is correct for your custom carrier board. Since dmesg shows attempts to detect PCIe, I’m more tempted to believe you have a signal quality failure. The driver to PCIe is running (dmesg shows this), and this is what lspci needs…even if there is no driver specific to the add-on card lspci should show up if the signal quality is not bad.
Can you try other PCIe cards on this carrier board and see if lspci sees all of those too?
Please use below patch to enable TSI-721 driver
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 20354a2946a1..91facd9c8eef 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -307,6 +307,16 @@ source "drivers/pci/Kconfig"
source "drivers/pci/pcie/Kconfig"
source "drivers/pci/hotplug/Kconfig"
+config RAPIDIO
+ tristate "RapidIO support"
+ depends on PCI
+ default n
+ help
+ If you say Y here, the kernel will include drivers and
+ infrastructure code to support RapidIO interconnect devices.
+
+source "drivers/rapidio/Kconfig"
+
endmenu
menu "Kernel Features"
diff --git a/arch/arm64/configs/tegra18_defconfig b/arch/arm64/configs/tegra18_defconfig
index a4974a172142..393f898f86e7 100644
--- a/arch/arm64/configs/tegra18_defconfig
+++ b/arch/arm64/configs/tegra18_defconfig
@@ -50,6 +50,8 @@ CONFIG_PCI=y
CONFIG_PCI_TEGRA=m
CONFIG_PCIEPORTBUS=y
# CONFIG_PCIEASPM is not set
+CONFIG_RAPIDIO=y
+CONFIG_RAPIDIO_TSI721=y
# CONFIG_ARM64_ERRATUM_843419 is not set
CONFIG_SCHED_MC=y
CONFIG_PREEMPT=y
[sorry im the newbie] whats about how to fixing my nv jt tx2 error?
the last messages are :
tegra-ubuntu login: nvidia (automatic login)
[ 9.271530] CFGP2P-ERROR) wl_cfgp2p_add_p2p_disc_if : P2P interface registerd
[ 9.290283] WLC_E_IF: NO_IF set, event Ignored
Last login: Fri May 6 05:40:14 UTC 2016 on tty1
Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4.38-tegra aarch64)
- Documentation: https://help.ubuntu.com/
432 packages can be updated.
190 updates are security updates.
[ 9.660352] tegra-pcie 10003000.pcie-controller: link 2 down, retrying
[ 9.668914] tegra-pcie 10003000.pcie-controller: link 2 down, ignoring
[ 9.675481] tegra-pcie 10003000.pcie-controller: PCIE: no end points detected
[ 9.682823] tegra-pcie 10003000.pcie-controller: PCIE: Disable power rails
nvidia@tegra-ubuntu:~$ [ 9.869720] fuse init (API version 7.23)
This is the TX1 forum, and I see your post is for a TX2. The TX2 forum is here:
[url]https://devtalk.nvidia.com/default/board/188/jetson-tx2/[/url]
Added Note:
It would be best to start a new thread since problems will differ, but the above doesn’t show any specific error unless you have a PCIe card installed (PCIe can shut down power if it doesn’t detect anything…unless you have a PCIe card that message is only discovery and not an error).
Can you say (in the TX2 forum listed in the first reply) which version of L4T is running? Please describe what is occurring (e.g., locking up, video not working, networking failed, so on). It would be advisable to start a new topic in this TX2 forum (unless your issue is related to a TSI-721 driver).