On Sat, Jul 10, 2021 at 10:47:55PM +0300, Vladimir Oltean wrote: > On Sat, Jul 10, 2021 at 12:25:54PM -0700, Colin Foster wrote: > > 1. The first probe of the internal MDIO bus fails. I suspect this is related to > > power supplies / grounding issues that would not appear on standard hardware. > > Where and with what error code does it fail exactly? I don't understand > the concept of "the first probe"? You mean that there is an > -EPROBE_DEFER and it tries again immediately afterwards? Or you need to > unbind and rebind the driver to the device, or what? My hardware I'm using for test / dev is a bit of a hack. Beaglebone jumped to a VSC7512 dev board SPI lines after some modifications. I believe I'm seeing grounding-related issues as a result of this. For instance, if I power on the dev board before powering on the Beaglebone, the BB will be held in reset. The same thing will happen if I reset the BB when the Microsemi dev board has been powered on, but left unconfigured. When I run "modprobe mscc_ocelot_spi" the first time the driver fails to enumerate swp1-3 with "failed to connect to port X: -19" message. But after doing that, I can reset the BB to my heart's content. Future boots will be able to successfully find those at initial mod insertion. And reloading / rebinding the driver successfully registers the ports at spi0.0-imdio:0X > > > 2. Communication to the CPU bus doesn't seem to function properly. I suspect > > this is due to the fact that ocelot / felix assumes it is using the built-in CPU > > / NPI port for forwarding, though I am not positive. > > What is the CPU bus and what doesn't function properly about it? I'm still learning a lot about how the chip functions, especially now that I have attained some functionality from the driver. There's a CPU bus that can be utilized when you're running internally, and I believe that can be configured as the NPI bus if you're running through PCIe. When controlling through SPI I'm not convinced we'll have access to that bus, and if the Ocelot driver relies on that functionality I've got some more work in front of me. > > > Nonetheless, these two issues likely won't require a large architecture change, > > and perhaps those who know much more about the ocelot chips than I could chime > > in. > > I guess you don't know if that's the case or not until you know what the > problem is... True
