Microchip KSZ9477 AVB Switch IC

XCore Project reviews, ideas, videos and proposals.
User avatar
XCore Expert
Posts: 580
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Hi Lorenzo,

Thanks! That worked to access the console. Appreciate the help.
Active Member
Posts: 36
Joined: Sat May 09, 2020 4:20 pm

Post by fabra »

Hi Lorenzo,

I would be interested to get involved in your project. Do you plan to make the switch driver open source?

I have some experience with AVB implementations. I had been working on the XMOS AVB implementation and other stacks including driver for the Marvell 88E6352.

Posts: 1
Joined: Thu Apr 08, 2021 4:22 pm

Post by DellyRosen »

Hi...I have an inquiry on the KSZ9897 segment. I need to utilize the KSZ9897 ethernet switch, without 6-7 MAC ports.
I need to config the switch with equipment as it were. (not by the control-register).
Is it conceivable?

buy pcb online
Posts: 1
Joined: Tue Jun 28, 2022 3:03 pm

Post by peci1 »

Hi lorenzochiesi, could you please explain to me where have you found the information that KSZ9477 actually needs a host processor to support P2P TC mode? I've tried running this chip as a managed switch (i.e. without any CPU connected to the SGMII port), but it seems the switch itself really doesn't generate any path delay requests, which would be needed for P2P TC to work. So your finding seems to be true, but I don't really get where did you find it out :) The datasheet is quite vague on this topic. Even if we added a host processor (which I think is a large overkill), I don't understand why e.g. port 7 should generate the path delay requests on behalf of other (downstream) ports. The path delay packets must not be forwarded by the switch, so even if port 7 generated the request, it should be swallowed by the switch fabric. Or is the host port treated differently in this regard?

Thanks, Martin
lorenzochiesi wrote: Thu Feb 28, 2019 7:16 pm Hi All,

After several month passed on other project I come back on AVB switch problem....

Following the suggestion of AKP i loaded on the Microchip evaluation board EVB-KSZ9477 the last software available on github and surprisingly everything start working!!
In the meanwhile I bought for testing a MOTU AVB switch: also that worked out of the box with xc200 MC Audio MC2 and MAC computers.

I tried to go in deep on how this 2 switch works and discovered that they are pretty similar.
Both the switch IC (Microchip KSZ9477 and Marvell 88E6352 for the MOTU) need to be assisted by a linux powered ARM host processor (Atmel SAMA5D33 for Microchip, Texas Intrument AM1802 for MOTU) to deliver AVB connectivity.
The main AVB task involving the processor is the managing of PTP P2P protocol that in both case is achieved running an open source daemon (ptp4l on Microchip, ptpd on MOTU).
There are other open source daemon running in both system that I suppose are needed to manage stream reservation and band shaping (msrpd,mvrpd), anyway they seems not essential to achieve AVB packet switching.
To verify this I tried on both platform to kill/disable all process except ptp daemons and AVB operations was still working propery.
In both case as soon as ptp daemon was disabled the switch continuate to work as regular GB switch but xMOS and MAC can't lock on ptp due to high and variable delay as shown by xc200 debug printout.
Thus when ptp daemon was active both MAC and xc200 established a ptp p2p lock to the switch host processor, when ptp was disabled the ptp packed was issued by the switch fabric but the delay introduced was very high and unreliable correctly preventing ptp lock.
In conclusion both this implementation relay on linux driver for the switch component and then on open source implementation of ptp daemon.

Sayng all this I'm started wondering if could be possible an implementation of a switch without involving a linux powered processor, in particular what I want to achieve is a multiple port gigabit AVB node (talker/listener) based exclusively on an XMOS XC200 processor and Microchip KSZ9477 switch.
The code architecture in the XMOS AVB refererence design seems to me properly modularized to achieve this goal. In particular I think that this should require the design of a specific MAC module that wrap the external switch capabilities showing toward other XMOS process (in particular ptp manager) the same interface of the dual mii mac used in daisy chain reference design.

I understand that it's not trivial at all but seems ineteresting enough to start a discussion about faisibility and effort required involving interested person that probably are on this thread (mon2, akp) and maybe also xmos internal (infiniteprobability) that answered to similar question in the past.

Many thanks in advance for your comments,