[CM4] PCIe link down with VL805 for using multi USB 3.0 port
Hello, this is my first time visiting the forum, so I'm not sure if this is the right place to post, but I'm hoping to get some help.
I've been using Raspberry Pi for about three months, and I'm still learning a lot. I recently ran into a problem, and I've been searching for solutions for days, trying everything I can find, but I can't seem to narrow down the solution. So, I'm asking for help from experienced users.
The hardware I'm currently developing includes the basic configuration found on the CM4 IO Board. I'm having a problem with the CM4 - VL805 - USB 3.0 three port configuration. As you know, CM4 - VL805 is linked via PCIe. Some samples successfully connect via PCIe and eventually the USB 3.0 comes up, but other samples have the PCIe link down. I want to know the reason why.
I'm posting three dmesg results:
1. When the official Raspberry Pi OS is installed on a problematic sample.
2. When a custom OS (based on the official Raspberry Pi OS) is installed on a working sample.
3. When the custom OS is installed on a problematic sample.
- I don't know if the message below, which can be seen when the official Raspberry Pi OS is installed, is a reliable message. 3.3V and 1.05V are being supplied normally.
(However, unlike the CM4 IO board, 3.3V and 1.05V are not separated into Digital and Analog. The same power line is applied.)
- I have applied the things I could refer to through VL805 (etc. SMI Pull-up, although it didn't seem to matter much in the CM4 IO Board circuit).
Even if it's not a complete solution, I would like to know a good starting point that I couldn't find with AI or on the internet.
Thank you.
I've been using Raspberry Pi for about three months, and I'm still learning a lot. I recently ran into a problem, and I've been searching for solutions for days, trying everything I can find, but I can't seem to narrow down the solution. So, I'm asking for help from experienced users.
The hardware I'm currently developing includes the basic configuration found on the CM4 IO Board. I'm having a problem with the CM4 - VL805 - USB 3.0 three port configuration. As you know, CM4 - VL805 is linked via PCIe. Some samples successfully connect via PCIe and eventually the USB 3.0 comes up, but other samples have the PCIe link down. I want to know the reason why.
I'm posting three dmesg results:
1. When the official Raspberry Pi OS is installed on a problematic sample.
2. When a custom OS (based on the official Raspberry Pi OS) is installed on a working sample.
3. When the custom OS is installed on a problematic sample.
[Raspberry OS]
...
[ 0.572335] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[ 0.572367] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
[ 0.572391] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x063fffffff -> 0x00c0000000
[ 0.572411] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x007fffffff -> 0x0400000000
[ 0.573370] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[ 0.573401] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.573413] pci_bus 0000:00: root bus resource [mem 0x600000000-0x63fffffff] (bus address [0xc0000000-0xffffffff])
[ 0.573466] pci .&checktime(0000,00,00,':').0: [14e4:2711] type 01 class 0x060400 PCIe Root Port
[ 0.573486] pci .&checktime(0000,00,00,':').0: PCI bridge to [bus 00]
[ 0.573497] pci .&checktime(0000,00,00,':').0: bridge window [mem 0x00000000-0x000fffff]
[ 0.573509] pci .&checktime(0000,00,00,':').0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
[ 0.573552] pci .&checktime(0000,00,00,':').0: PME# supported from D0 D3hot
[ 0.575039] pci .&checktime(0000,00,00,':').0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 0.575132] pci_bus 0000:01: supply vpcie3v3 not found, using dummy regulator
[ 0.575212] pci_bus 0000:01: supply vpcie3v3aux not found, using dummy regulator
[ 0.575242] pci_bus 0000:01: supply vpcie12v not found, using dummy regulator
[ 0.919425] brcm-pcie fd500000.pcie: link down
[ 0.919572] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 0.919595] pci .&checktime(0000,00,00,':').0: PCI bridge to [bus 01]
[ 0.919608] pci_bus 0000:00: resource 4 [mem 0x600000000-0x63fffffff]
[ 0.919868] pcieport .&checktime(0000,00,00,':').0: PME: Signaling with IRQ 27
[ 0.920068] pcieport .&checktime(0000,00,00,':').0: AER: enabled with IRQ 27
[ 0.920347] pci_bus 0000:01: busn_res: [bus 01] is released
[ 0.920604] pci_bus 0000:00: busn_res: [bus 00-ff] is released
...
[Custom OS : Fail]
[ 0.572335] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[ 0.572367] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
[ 0.572391] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x063fffffff -> 0x00c0000000
[ 0.572411] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x007fffffff -> 0x0400000000
[ 0.573370] brcm-pcie fd500000.pcie: link down
- I have tried adding settings or options and changing the boot order with the eeprom image through usbboot, but it didn't work.[Custom OS : Normal]
[ 0.572335] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[ 0.572367] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
[ 0.572391] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x063fffffff -> 0x00c0000000
[ 0.572411] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x007fffffff -> 0x0400000000
[ 0.573370] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
[ 0.573452] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
- I don't know if the message below, which can be seen when the official Raspberry Pi OS is installed, is a reliable message. 3.3V and 1.05V are being supplied normally.
(However, unlike the CM4 IO board, 3.3V and 1.05V are not separated into Digital and Analog. The same power line is applied.)
- I have applied the things I could refer to through VL805 (etc. SMI Pull-up, although it didn't seem to matter much in the CM4 IO Board circuit).
I can upload additional materials needed for the advice if necessary.- supply vpcie3v3 not found, using dummy regulator
- supply vpcie3v3aux not found, using dummy regulator
- supply vpcie12v not found, using dummy regulator
Even if it's not a complete solution, I would like to know a good starting point that I couldn't find with AI or on the internet.
Thank you.
- dp11
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 1694
- Joined: Thu Dec 29, 2011 5:46 pm
Re: [CM4] PCIe link down with VL805 for using multi USB 3.0 port
Let us see your complete schematics and layout. Does working sample mean you have some working boards?
Re: [CM4] PCIe link down with VL805 for using multi USB 3.0 port
Dear dp11,
I'm really sorry... I momentarily forgot that I can't upload any materials from the company.
I'll try to write and upload just the CM4 - VL805 circuit separately at home later, even if it's a simple version. I don't think there will be any problem with this part.
However, to explain as much as possible for your reference:
1. The CM4 - VL805 circuit configuration is not significantly different from the CM4 IO USB 3.0 Board circuit.
- nPONRST -> nEXTRST connected directly
- nPEXCLKREQ -> PCIE_CLK_nREQ connected directly
- nPEXRST -> PCIe_nRST connected directly
- PEXRX line -> PCIE_TX line connected directly
- PEXTX line -> 0.1uF cap -> PCIE_RX line connected
- PEXCLK line -> PCIE_CLK line connected
2. Working sample
- Yes, there are already well-working boards. However, a small number of samples from the existing production run experienced this PCIe link problem (rev 1.00).
- Several patches were applied to the schematic (rev 1.01), but no samples were produced.
- In the problematic samples, the nPEXWAKE and nSMI pins, which were previously left in a not connected state, were pulled up. This seemed to solve the issue as the link was established, so the fix was applied. However, in the current samples, the problem occurred on a larger scale (rev 1.02).
- It is believed that none of the patches in between would have affected this circuit.
However, if I mentioned
[Question]
1. Is it possible that this symptom is caused by a power issue? After seeing that message, I tried testing by removing them one by one from rev 1.02 -> rev 1.00, but there was no change. For reference, I am creating 3.3v and 1.05v with an MPM3810 step-down regulator, and most circuits use the 3.3v line. 1.05v only for Vcore for VL805.
2. If the design is normal, is it possible that a problem could occur in the PCIe line due to the PCB artwork, causing the issue?
3. Based on the patches and experiments applied so far, I can't shake the feeling that I'm walking a tightrope. It feels like something is in between the working and non-working sides due to some factor, so it works if I'm lucky, and it doesn't work if I'm not.
I apologize once again for not being able to attach the data.
Thank you.
I'm really sorry... I momentarily forgot that I can't upload any materials from the company.
I'll try to write and upload just the CM4 - VL805 circuit separately at home later, even if it's a simple version. I don't think there will be any problem with this part.
However, to explain as much as possible for your reference:
1. The CM4 - VL805 circuit configuration is not significantly different from the CM4 IO USB 3.0 Board circuit.
- nPONRST -> nEXTRST connected directly
- nPEXCLKREQ -> PCIE_CLK_nREQ connected directly
- nPEXRST -> PCIe_nRST connected directly
- PEXRX line -> PCIE_TX line connected directly
- PEXTX line -> 0.1uF cap -> PCIE_RX line connected
- PEXCLK line -> PCIE_CLK line connected
2. Working sample
- Yes, there are already well-working boards. However, a small number of samples from the existing production run experienced this PCIe link problem (rev 1.00).
- Several patches were applied to the schematic (rev 1.01), but no samples were produced.
- In the problematic samples, the nPEXWAKE and nSMI pins, which were previously left in a not connected state, were pulled up. This seemed to solve the issue as the link was established, so the fix was applied. However, in the current samples, the problem occurred on a larger scale (rev 1.02).
- It is believed that none of the patches in between would have affected this circuit.
However, if I mentioned
If this part is a valid concern, then there are parts where power-consuming circuits have been added.- supply vpcie3v3 not found, using dummy regulator
- supply vpcie3v3aux not found, using dummy regulator
- supply vpcie12v not found, using dummy regulator
[Question]
1. Is it possible that this symptom is caused by a power issue? After seeing that message, I tried testing by removing them one by one from rev 1.02 -> rev 1.00, but there was no change. For reference, I am creating 3.3v and 1.05v with an MPM3810 step-down regulator, and most circuits use the 3.3v line. 1.05v only for Vcore for VL805.
2. If the design is normal, is it possible that a problem could occur in the PCIe line due to the PCB artwork, causing the issue?
3. Based on the patches and experiments applied so far, I can't shake the feeling that I'm walking a tightrope. It feels like something is in between the working and non-working sides due to some factor, so it works if I'm lucky, and it doesn't work if I'm not.
I apologize once again for not being able to attach the data.
Thank you.
- dp11
- Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator - Posts: 1694
- Joined: Thu Dec 29, 2011 5:46 pm
Re: [CM4] PCIe link down with VL805 for using multi USB 3.0 port
It does sound like you don't have a reliable system. Without seeing the full schematics and layout I can't really guess what is wrong. i would how every check the PSUs on the vli are in spec. during booting using a scope and high speed probing.
Re: [CM4] PCIe link down with VL805 for using multi USB 3.0 port
Dear dp11,
I can only apologize for not providing you with enough information.
I discovered something today and would like to get your opinion on it.
When referring to the CM4 IO board schematic, I didn't pay much attention to the fact that the nPONRST and nEXTRST pins are connected 1:1.
However, after looking at several other reference schematics and other similar USB 3.0 Host controller chips (Renesas uPD720201), I realized that (although there is no guarantee, assuming that the operation of VL805 and other USB 3.0 host controllers is similar)
The following flow must continue: 3.3V power-on -> 1.05V power -> power stabilization -> nPONRST -> nPEXRST.
(As a result of measuring my board, after 3.3V power-on, nPONRST becomes high from CM4 after about 2 seconds to nPONRST, and a reset signal appears from nPEXRST after about 6 seconds)
I'm wondering if the time between power stabilization and nPONRST should be short. In other words, the power-on reset should be completed before the CM4 attempts a PCIe link.
Based on this question, I tried the following with a failing sample:
- Disconnected the nEXTRST of CM4 and the nPONRST pattern of VL805.
- Connected the 3.3V and nPONRST lines, using an RC circuit in the middle to give a delay of about 10ms (so that the order of 3.3v - 1.05 - nPONRST inactive is achieved).
After doing this, I confirmed that the PCIe link, which never worked before, was established. It's somewhat unstable, as it doesn't always connect 100% of the time.
I overlooked it because there is little information about timing in the VL805 data sheet, but do you have any advice on these two signals, nPONRST / nPEXRST?
I wanted to speed up the high signal coming from the CM4's nEXTRST line, so I looked for ways to do it, but I couldn't find any.
I'd like to hear your opinion.
I can only apologize for not providing you with enough information.
I discovered something today and would like to get your opinion on it.
When referring to the CM4 IO board schematic, I didn't pay much attention to the fact that the nPONRST and nEXTRST pins are connected 1:1.
However, after looking at several other reference schematics and other similar USB 3.0 Host controller chips (Renesas uPD720201), I realized that (although there is no guarantee, assuming that the operation of VL805 and other USB 3.0 host controllers is similar)
The following flow must continue: 3.3V power-on -> 1.05V power -> power stabilization -> nPONRST -> nPEXRST.
(As a result of measuring my board, after 3.3V power-on, nPONRST becomes high from CM4 after about 2 seconds to nPONRST, and a reset signal appears from nPEXRST after about 6 seconds)
I'm wondering if the time between power stabilization and nPONRST should be short. In other words, the power-on reset should be completed before the CM4 attempts a PCIe link.
Based on this question, I tried the following with a failing sample:
- Disconnected the nEXTRST of CM4 and the nPONRST pattern of VL805.
- Connected the 3.3V and nPONRST lines, using an RC circuit in the middle to give a delay of about 10ms (so that the order of 3.3v - 1.05 - nPONRST inactive is achieved).
After doing this, I confirmed that the PCIe link, which never worked before, was established. It's somewhat unstable, as it doesn't always connect 100% of the time.
I overlooked it because there is little information about timing in the VL805 data sheet, but do you have any advice on these two signals, nPONRST / nPEXRST?
I wanted to speed up the high signal coming from the CM4's nEXTRST line, so I looked for ways to do it, but I couldn't find any.
I'd like to hear your opinion.
Re: [CM4] PCIe link down with VL805 for using multi USB 3.0 port
Please disregard my previous post (although you can still give me advice if you have any).
I've observed something new.
I made the problematic sample do various tasks, causing the temperature of the CM4 to rise above 60 degrees Celsius.
After that, I turned off the power and turned it back on, and I observed that the PCIe was connected.
I feel like I'm falling deeper into a mystery.
I will review the artwork again.
I've observed something new.
I made the problematic sample do various tasks, causing the temperature of the CM4 to rise above 60 degrees Celsius.
After that, I turned off the power and turned it back on, and I observed that the PCIe was connected.
I feel like I'm falling deeper into a mystery.
I will review the artwork again.
Re: [CM4] PCIe link down
I have a new CM4 (model CM4001008) - no Wifi or Bluetooth, mounted on a Waveshare CM4-10-BASE-C (V2), booting from TF card with 32-bit OS with desktop image.
There is a message: brcm-pcie pcie link down
Then the CM4 boots, displaying the splash screen, then (very briefly) the standard information:
Debian GNU/Linux 12 raspberrypi tty1
My IP address is: 192.168.1.137 ...
raspberrypi login: daves (automatic login)
The programs included with..
Debian GNU/Linux comes with...
Last login: ...
and then the display goes blank.
I can connect over ethernet using putty, perfectly correctly.
Please advise why I get no desktop.
There is a message: brcm-pcie pcie link down
Then the CM4 boots, displaying the splash screen, then (very briefly) the standard information:
Debian GNU/Linux 12 raspberrypi tty1
My IP address is: 192.168.1.137 ...
raspberrypi login: daves (automatic login)
The programs included with..
Debian GNU/Linux comes with...
Last login: ...
and then the display goes blank.
I can connect over ethernet using putty, perfectly correctly.
Please advise why I get no desktop.
Re: [CM4] PCIe link down with VL805 for using multi USB 3.0 port
dmesg | grep pcie returns:
Code: Select all
0.069857] /scb/pcie@7d500000: Fixed dependency cycle(s) with /scb/pcie@7d500000
[ 0.069986] /scb/pcie@7d500000: Fixed dependency cycle(s) with /scb/pcie@7d500000
[ 0.564867] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[ 0.564887] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
[ 0.564906] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x063fffffff -> 0x00c0000000
[ 0.564925] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x003fffffff -> 0x0400000000
[ 0.566009] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[ 0.567871] pci_bus 0000:01: supply vpcie3v3 not found, using dummy regulator
[ 0.567954] pci_bus 0000:01: supply vpcie3v3aux not found, using dummy regulator
[ 0.567977] pci_bus 0000:01: supply vpcie12v not found, using dummy regulator
[ 0.911811] brcm-pcie fd500000.pcie: link down
[ 0.912242] pcieport .&checktime(0000,00,00,':').0: PME: Signaling with IRQ 26
[ 0.912419] pcieport .&checktime(0000,00,00,':').0: AER: enabled with IRQ 26
Jump to
- Community
- General discussion
- Announcements
- Other languages
- Deutsch
- Español
- Français
- Italiano
- Nederlands
- 日本語
- Polski
- Português
- Русский
- Türkçe
- User groups and events
- Raspberry Pi Official Magazine
- Using the Raspberry Pi
- Beginners
- Troubleshooting
- Advanced users
- Assistive technology and accessibility
- Education
- Picademy
- Teaching and learning resources
- Staffroom, classroom and projects
- Astro Pi
- Mathematica
- High Altitude Balloon
- Weather station
- Programming
- C/C++
- Java
- Python
- Scratch
- Other programming languages
- Windows 10 for IoT
- Wolfram Language
- Bare metal, Assembly language
- Graphics programming
- OpenGLES
- OpenVG
- OpenMAX
- General programming discussion
- Projects
- Networking and servers
- Automation, sensing and robotics
- Graphics, sound and multimedia
- Other projects
- Media centres
- Gaming
- AIY Projects
- Hardware and peripherals
- Camera board
- Compute Module
- Official Display
- HATs and other add-ons
- Device Tree
- Interfacing (DSI, CSI, I2C, etc.)
- Keyboard computers (400, 500, 500+)
- Raspberry Pi Pico
- General
- SDK
- MicroPython
- Other RP2040 boards
- Zephyr
- Rust
- AI Accelerator
- AI Camera - IMX500
- Hailo
- Software
- Raspberry Pi OS
- Raspberry Pi Connect
- Raspberry Pi Desktop for PC and Mac
- Beta testing
- Other
- Android
- Debian
- FreeBSD
- Gentoo
- Linux Kernel
- NetBSD
- openSUSE
- Plan 9
- Puppy
- Arch
- Pidora / Fedora
- RISCOS
- Ubuntu
- Ye Olde Pi Shoppe
- For sale
- Wanted
- Off topic
- Off topic discussion