Hi We have created a test board to check how to make the direct RGMII to RGMII coms between two Verdin modules. (PHY less)
I cant build full images here, but I can edit some bits of the device tree with fdt commands in uboot.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello!
For the second Ethernet interface on Verdin modules, it is available as a Reduced Gigabit Media-Independent Interface (RGMII). This interface is designated as “Reserved” and requires a PHY to be placed on the carrier board to utilize various media types for the physical link layer.
If you are considering a direct RGMII connection without a PHY, it’s important to ensure proper signal integrity. RGMII connections require careful attention to:
TX and RX delays
Signal termination
Interface timing
Unfortunately, the available documentation does not provide specific guidance on PHY-less RGMII connections between Verdin modules. However, understanding these key considerations can help you in planning your design.
If you have further questions or need more detailed information, feel free to ask!
So im at this stage now added 2ns scews to the tx and rx, ive tried phy mode rgmii and rgmii-id and I still can not ping between boards.
I really am out of ideas here. Ive even added 22r resistors between the boards rgmii wondering it it was too hot… or was getting excessive reflections. But no.
I can see the pin request go out on the scope and I can see a clean 125mhz clock rate…
to remove ambiguity as the ethernet1/0 get redefined a couple times in the device tree. Im directly addressing the 30be port.
I have tried with and without tx/rx-delay values added. tried rgmii-id rgmii-txid and rgmii.
I can see a ping signal go out over the rgmii datalines over my scope. I see a stable 125mhz clock. I have tried setting link speed to 100mb, but I still cant ping between the two toradex modules. It just hangs there waiting for a reply.
I really do feel like Im so close to fixing this but I dont know whats left to do.
As a concept this should work. And it looks like electrically speaking it half is working. Just something is missing.
Are you able to try to implement these device tree changes in a device tree or device tree overlay?
This would be the recommended approach here to reduce the likelyhood os mistakes.
Can you also send the dmesg logs?
Maybe there is something useful there.
I don’t have any kind of Linux build environment setup here… So sadly no, I can only make the changes via FDT.
RE the fdt commands. I think the main issue right now is the delay. That needs to be implemented but the delay command is entirely unknown if its correct.
If you happen to know the correct command to put in I can test from there…
The dmesg didnt really show anything useful as far as i remember, simply that link was up at what ever speed I set it to in the fdt commands.
And after assigning ip addresses to both toradex boards, I try to ping from one to the other, and dont get any response.
I have found some interesting oddities in ethtools, where one side would get rx crc errors, but the other wouldnt even recognise it had any rx at all…
I realise at this point thats a bit nondescript, I can give you harder numbers in a bit.
But I think the very first thing is confirming the proper way to add a 2ns delay to the MAC and we can go from there.
But still no luck.
Bellow is the ethtool printout after the ping attempt from SOM2 to SOM1, You can see the stats of both devices on ether side.
It just doesnt look like any data is being received at all this time.
Ok an update on everything, some good news. Ive mostly got it working…
So ignore all the ethtool posts before…
Turns out properly soldering the sodimm slot helps a lot… Had a couple of dry solder joints on the rgmii.
So Ive got this test board working on 100mb but I cant quite get 1GB to work. The receiving SOM picks up a number RX_CRC but thats about it.
Now there was a small error on this test board with a couple of traces being off spec by about 0.8mm. That really shouldnt make a difference even at 1GB.
I did notice that the clock signal is stronger at 100mb being a full 0-1.8v, at 1gb 125mhz its certainly narrower.
My nest test will be to remove the 22ohm resistors. In case theyre making the signals a little too weak. Its unlikely but theres little else I can try right now unless you have any other suggestions?
It is good to know you were able to get this working with 100 Mb.
For future reference, we do provide a tool which makes it easier to work with device trees and device tree overlays, Torizon Core Builder: TorizonCore Builder Tool - Customizing Torizon OS Images | Toradex Developer Center
It is intended to customize Torizon OS images, with the capability of adding custom device trees and device tree overlays without the need for a full build system.
Due to the higher frequency of Gb Ethernet, the resistors could be related to the problem.
We do not use 22 Ohm resistor for the RGMII lines in our designs.
Therefore, I would say that replacing these resistors with 0R resistors is a good test here.
More good news… I got GB working. But its a really hacky approach, using the resistor pads to solder to, I added 30CM of twisted copper wire (one strange to ground one to signal) to the RXC and TXC clocks.
This added a physical delay to the clocks, though while I was aiming for 90degrees out of phase, I ended up going 270 on the wire… It still managed to work. (though clearly still needs some figuring out… )
So basically it appears on the IMX8MP the commands:
fdt set /soc@0/bus@30800000/ethernet@30be0000 tx-internal-delay-ps <2000>
fdt set /soc@0/bus@30800000/ethernet@30be0000 rx-internal-delay-ps <2000>
actually have no effect at all.
On Monday I’ll be looking for a signal buffer that can add a fixed 2ns delay to the signal and do another test PCB to prove it works.
