Julien Goodwin
Forum Replies Created
- AuthorPosts
Sorry for not replying when I first saw this, but that error would cause exactly the behaviour I was seeing. I fixed that, and length matched within 1mm.
The new boards arrived back from the CM today.
I’ve not yet done a full test, but at least at 100Mbit it’s passing packets enough for uboot to be able to DHCP and try a netboot.
Thank you very much for finding that pin error.
The Juniper kit is carrier network equipment, I trust its interface counters.
Again, wireshark will say nothing, as packets never reach a level where they could be captured.
I’ll look into the TI Starterware software.
“1. Which utility are you using to observe the packets? Wireshark can be helpful in finding out if the packets are corrupted.”
Nothing, the raw interface counters on the switch (Have tested multiple, mainly a Juniper SRX I already had on my desk) confirm no packets are getting to that point. Juniper are pretty good with error counters too, and those aren’t incrementing either.
” 2. Which Debian version are you using?”
Tried both:
bone-debian-9.3-iot-armhf-2018-03-05-4gb.img
bone-debian-9.5-iot-armhf-2018-10-07-4gb.imgFor uBoot it’s git head from a few weeks back.
” 3. Please share the boot log.”
There’s nothing useful in the log.After reading TI’s RGMII timing doc (SNLA243) I took at look at the TX/RX enable/error lines, and there I was further out. Still under 10mm, which seems low for causing an issue, given expected signal propegation time, but it was easy enough to re-layout that section and have all match to within 0.5mm.
I got the test boards back in August, but it was only last month that I got around to trying the Ethernet bringup.
I’ve run out of ideas as to what’s going wrong, and would appreciate any ideas.
The PHY is detected, as is link (at least at 100Mbit, & 1g, I did a quick test at 10Mb, but didn’t have results logged), and I can see packets travelling in both directions across the RGMII link, however packet counters at each end never show receive packets.
This occurs both in Linux & U-Boot.
Although I didn’t explicitly length-match traces (which I should have), all the MAC->PHY lines are within 4mm, and all the PHY->MAC lines within 5mm. Given the data rates, while this is suboptimal, this seems like it should work. Also despite the straps set for 0 PHY delay I removed those on a test board and the default 2ns delay gives the same result. I note you don’t have any details about length-matched traces like the MII lines in your layout guide, are traces length-matched inside the package?
On the Linux side I also patched up a reset gpio, and confirmed it caused the expected reset, but this didn’t change behaviour.
Relevant subset of schematic:
https://julien.studio442.com.au/images/sip-ethernet-schematic.pngThe devicetree chunk:
https://julien.studio442.com.au/sip-ethernet-devicetree.dtsAh thanks, I’d looked at the reference design a while back, which must be why I was pretty sure that RGMII was possible.
Will dig back into it.
- AuthorPosts
