Hi All,
For a future project I'm evaluating the Microchip KSZ9477 AVB Enabled switch.
The intention is to connect directly to XE216 device to create daisy chainable gigabit ethernet AVB nodes.
I'm doing test unsing official products evaluation boards with the following setup:
xC200 AUDIO MC2 <------> EVB-KSZ9477 <-----> MacBookPro
Unfortunatley this will not work out of the box: MacBook can't see the AVB node. (Of course if I connect directly XMOS and MacBook work perfectly)
I tried to tweak parameter of EVB-KSZ9477 but my undertanding is that out of the box firmware should setup the switch with AVB features enabled.
Anyone have success story with this Microchip switch IC.
Any suggestion about other AVB switch IC knowed to work fine with low firmware effort?
Many thanks
Lorenzo
Microchip KSZ9477 AVB Switch IC
-
lorenzochiesi
- Active Member
- Posts: 34
- Joined: Mon Sep 05, 2016 4:20 pm
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hmm. That is odd. I would have expected the evaluation board to just work transparently. Are your patch cables of cat7 quality and fully loaded? Does each patch cable work if only the Xmos audio board and the macbook? I would contact Microchip technical staff for an explanation on why the evaluation board is not working as expected. Please post your results.
-
lorenzochiesi
- Active Member
- Posts: 34
- Joined: Mon Sep 05, 2016 4:20 pm
Mee too :-(...yes, I'm using short cat5e patch cables but I tested it replacing switch with a simple ethernet joint and everiting work fine. Thecnically the switch work fine and transparently to connect other devices not requiring AVB support.
Do you have experience with that switch IC?
L.
Do you have experience with that switch IC?
L.
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
No, have not used this part but reviewing others for pending 10/100mbps designs. Try to review with Wireshark to see why it is failing. But not sure if Wireshark runs on Mac or not. Still do consider to contact Microchip online tech support for assistance.
Also review this thread...
http://www.xcore.com/viewtopic.php?t=4261
Also review this thread...
http://www.xcore.com/viewtopic.php?t=4261
-
akp
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
I am also interested in this application with that EVB, but haven't investigated yet. First thing I would do is run the xC200 AUDIO MC2 in the debugger and watch the xSCOPE messages. What is different when you have the MC audio board direct connected to the Mac vs thru the switch? Perhaps the EVB is not running gPTP (i.e. you don't see sync lock) or the switch isn't running the AVB routing stuff properly. Also set DEBUG_PRINT_AS_CAPABLE to 1 to show the PTP neighbour delay (average pdelay) -- it's supposed to be < 800ns, if not then there's something wrong with the timestamping on the rerouted packets. I tried the NXP TSN switch LS1021A Time-Sensitive Network (TSN) Board and it didn't have the right software running on it to get AVB.
You might want to check the latest EVB-KSZ9477 on github in case your software is old. Really hoping you have some success!
You might want to check the latest EVB-KSZ9477 on github in case your software is old. Really hoping you have some success!
-
lorenzochiesi
- Active Member
- Posts: 34
- Joined: Mon Sep 05, 2016 4:20 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,
Lorenzo
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,
Lorenzo
-
akp
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Hi Lorenzo,
Sounds like some great work! I think based on your experience it's quite likely an XCORE-200 running some version of the XMOS gptp stack would be sufficient, probably with an RGMII connection + SPI (or whatever) to the switch. But I also wonder if you will need SRP running, I feel that the XCORE-200 will need to configure which stream gets sent to which port on the switch. At least that is how the old XMOS AVB-DC code works, you can find it on the xcore github. https://github.com/xcore/sw_avb_dc
I think possibly extend the concept of 2 external ports + internal endpoint (kind of like 3 port switch) to n ports for the forwarding?
-- akp
Sounds like some great work! I think based on your experience it's quite likely an XCORE-200 running some version of the XMOS gptp stack would be sufficient, probably with an RGMII connection + SPI (or whatever) to the switch. But I also wonder if you will need SRP running, I feel that the XCORE-200 will need to configure which stream gets sent to which port on the switch. At least that is how the old XMOS AVB-DC code works, you can find it on the xcore github. https://github.com/xcore/sw_avb_dc
I think possibly extend the concept of 2 external ports + internal endpoint (kind of like 3 port switch) to n ports for the forwarding?
-- akp
-
Yuri
- Newbie
- Posts: 1
- Joined: Wed Apr 03, 2019 11:47 am
Hi Lorenzo!
We are also trying to do similar tests in our LAB, which we need for using KSZ9477 switch for AVB application.
We have two PCs each one running ptp4l and EVB-KSZ9477 in between. One PC is connected to port1 of the EVB and another one to port3. We took the latest version of ptp4l which supports TC, but our problem is that in ifconfig we can see just one physical port ETH0. So we are confused how to configure ptp4l for TC operation.
Please advise,
Yuri
We are also trying to do similar tests in our LAB, which we need for using KSZ9477 switch for AVB application.
We have two PCs each one running ptp4l and EVB-KSZ9477 in between. One PC is connected to port1 of the EVB and another one to port3. We took the latest version of ptp4l which supports TC, but our problem is that in ifconfig we can see just one physical port ETH0. So we are confused how to configure ptp4l for TC operation.
Please advise,
Yuri
-
akp
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Hi guys
Just wondering what the easiest way is to get a console open on the MOTU switch -- it looks like Lorenzo did it. Can we telnet / ssh or do we need disassemble and use UART for instance?
Just wondering what the easiest way is to get a console open on the MOTU switch -- it looks like Lorenzo did it. Can we telnet / ssh or do we need disassemble and use UART for instance?
-
lorenzochiesi
- Active Member
- Posts: 34
- Joined: Mon Sep 05, 2016 4:20 pm
Hi Akp,
Easiest way is accessing phisical ARM UART.
Probably is the only way considering that "ps" command don't show any ssh or telnet daemon
Following link let you download a zip with couple of hi-res picture with indication of UART pin.
You will also find log of useful console command answer (ps, ifconfig, df,...)
Lorenzo
Easiest way is accessing phisical ARM UART.
Probably is the only way considering that "ps" command don't show any ssh or telnet daemon
Following link let you download a zip with couple of hi-res picture with indication of UART pin.
You will also find log of useful console command answer (ps, ifconfig, df,...)
Lorenzo