Le 12/29/17 à 13:56, Florian Fainelli a écrit : > Le 12/29/17 à 12:21, Florian Fainelli a écrit : >> Hi Jochen, >> >> Le 12/18/17 à 02:44, Jochen Friedrich a écrit : >>> Hi Florian, >>> >>> unfortunately, this doesn't make any difference. >>> >>> Just out of curiosity, BPI-R1 has pull-down resistors on LED6 and 7 >>> (MII_MODE0/1). However, the public available 53125U sheet doesn't >>> document these pins: >>> >>> LED[6] IMP_MODE[0] Pull-up Active low (since IMP Mode is not used) >>> LED[7] IMP_MODE[1] Pull-up Active low (since IMP Mode is not used) >>> >>> Is this MII mode maybe incompatible with Broadcom tags? >> >> AFAICT, it should not, this is largely independent from enabling >> Broadcom tags. >> >> I have now reproduced this on my BPI-R1 as well and am looking at what >> might be going wrong. > > OK, so I have been able to find out what was going on. On BCM53125 and > earlier switches, we need to do a couple of things for Broadcom tags to > be usable: > > - turn on managed mode (SM_SW_FWD_MODE) > - configure Port 8 for IMP mode (B53_GLOBAL_CONFIG, setting bit > GC_FRM_MGMT_PORT_MII) > > After doing that, I can now see the correct outgoing packets on my host, > however, the replies don't seem to be delivered to the per-port DSA > network devices, and I suspect it's because of stmmac, so I am > investigating this now. >
So stmmac was indeed part of the problem. I had to clear the GMAC_CONTROL_ACS bit in GMAC_CORE_INIT in order to allow stmmac to properly receive packets, otherwise, packets were truncated to 8 bytes on reception which I assume is because the Broadcom tags may look like some sort of weird LLC/SNAP packet which was confusing the hardware. This is all working correctly now after a bunch of changes that I will submit in the next few days. Preliminary patches available here: https://github.com/ffainelli/linux/commits/stmmac-fixes Thank you very much for your patience! -- Florian