White Rabbit Switch - Gateware issueshttps://ohwr.org/project/wr-switch-hdl/issues2020-06-08T14:49:39Zhttps://ohwr.org/project/wr-switch-hdl/issues/2PTP frames not sent after reboot despite link up2020-06-08T14:49:39ZGrzegorz DanilukPTP frames not sent after reboot despite link upIn the setup with 2 WR PTP Cores (v4.0) connected to the WR Switch v5.0,
both nodes are synchronized. I restarted the switch (by executing
*reboot* in the linux shell) and after booting up again, only one WRPC
was synchronized, the other was stuck in listening not receiving any
traffic.
Having a quick look in the WRS it looks that despite the link being up,
no frames are sent on one of the ports. In SNMP, PTP Tx frames counter
increments on that port, and also in Pstats NIC\_Tx counter increments.
However Tx frames counter in the Endpoint remains 0.
ifconfig wriX down; ifconfig wriX up fixes the problem.https://ohwr.org/project/wr-switch-hdl/issues/1Port mirroring does not work2020-06-08T14:48:54ZAdam WujekPort mirroring does not workThe performed test had the following setup:
\--a traffic running on port 1 (PTP, LLDP and application)
\--sniffer connected to the port 2
Expected result was that all the traffic will be redirected from port 1
to port 2.
Configuration of a switch:
# disable port mirroring in case it was enabled
# read RX_CTR register
devmem 0x10060014 32
# remove flag 0x20 (MR_ENA) from the given result (0x19 & ~0x20 = 0x30)
devmem 0x10060014 32 0x19
# Configure destination port to port 2
devmem 0x10060024 32 0
devmem 0x10060028 32 0x2
# Configure reception traffic mirror source to port 1
devmem 0x10060024 32 2
devmem 0x10060028 32 0x1
# Configure transmission traffic mirror source
devmem 0x10060024 32 3
devmem 0x10060028 32 0x1
# Enable port mirroring in case it was enabled
# read RX_CTR register
devmem 0x10060014 32
# add flag 0x20 (MR_ENA) to the given result (0x19 | 0x20 = 0x30)
devmem 0x10060014 32 0x39
Additional observations:
\--on a port 2, LLDP packets were transmitted from CPU (should not
happen)https://ohwr.org/project/wr-switch-hdl/issues/40Low Phase Drift Calibration (LPDC)2020-06-08T14:46:43ZGrzegorz DanilukLow Phase Drift Calibration (LPDC)Low Phase Drift Calibration is a new feature added in release v6.0 that improves phase stability between WR switch restarts to <10ps. Due to FPGA limitations this functionality is present only on ports 1-12. The LPDC requires an additional, automated calibration procedure to run for Tx and Rx path of each affected FPGA transceiver. The Tx calibration is performed once for all ports at startup of the WR switch. The Rx calibration is performed each time a link goes up on a port. Both Tx and Rx calibration is indicated by blinking of Link/WR Mode LED (left). The downside is that the calibration makes startup of the WR switch longer. Similarly, the time between connecting a fiber and the link going up (e.g. as observed in *wr_mon*) is noticeably longer.https://ohwr.org/project/wr-switch-hdl/issues/6rx pcs should accept preamble shrinkage2020-06-08T14:26:18ZGrzegorz Danilukrx pcs should accept preamble shrinkageIn some cases (depends on the transceiver implementation on the other
side of the link) the preamble which is normally 6 bytes can be shrank
to 5 bytes. More information about the reasons for preamble shrinkage
can be found e.g. in [Xilinx Ethernet PCS/PMA product
guide](http://www.xilinx.com/support/documentation/ip_documentation/gig_ethernet_pcs_pma/v15_1/pg047-gig-eth-pcs-pma.pdf)
Although this situation with our TX PCS, we should be able to handle
this on RX side to allow connecting various non-WR devices to the WR
switch.Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/38v3.0 - [NIC] Broadcast storm to CPU2019-02-12T09:51:48ZMaciej Lipinskiv3.0 - [NIC] Broadcast storm to CPUFrames with broadcast forwarding decisions are forwarded to the CPU as
well, if there is a broadcast storm, the CPU gets a bit stuck.
Some kind of detection and prevention mechanism needs be implemented in
NICGrzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/37v3.0 - [RTU] Unrecognized frame broadcast to CPU2019-02-12T09:51:47ZMaciej Lipinskiv3.0 - [RTU] Unrecognized frame broadcast to CPUUnrecognized broadcast frames are forwarded to CPU as well - this causes
CPU to get overwhelmed if a flood of unrecognized frames is received.Maciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-switch-hdl/issues/34v4-dev - Per-port statistics counters (PSTATS)2019-02-12T09:51:47ZGrzegorz Danilukv4-dev - Per-port statistics counters (PSTATS)Generic module of per-port counters, counting various events generated
inside the WR Switch.Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/33v4-dev - WR Endpoint events generation2019-02-12T09:51:46ZGrzegorz Danilukv4-dev - WR Endpoint events generationModification of WR Endpoint to trigger events counter by PSTATS module.Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/32v3.0 - [RTU] Aging/update of MAC entry when src port changes2019-02-12T09:51:46ZMaciej Lipinskiv3.0 - [RTU] Aging/update of MAC entry when src port changesThe bug is basic but major: RTU@HW don't remember on which port it
learns a
MAC entry. This means that if the MAC entry is in memory (HTAB), and the
port
on which a source MAC is received is changed before the old MAC entry is
aged....
the invalid MAC entry will be found and considered OK, so updated as if
it was correct...
and it will never age.Maciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-switch-hdl/issues/31v3.0 - [RTU] Aging bitmap update at src and dst MAC found2019-02-12T09:51:45ZMaciej Lipinskiv3.0 - [RTU] Aging bitmap update at src and dst MAC foundThe aging map is updated when a MAC entry is found for given source and
destination MAC. This is wrong behaviour. It should be updated only on
source MAC found.Maciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-switch-hdl/issues/30v4.0 - [HWDU] HardWare Debugging Unit2019-02-12T09:51:44ZMaciej Lipinskiv4.0 - [HWDU] HardWare Debugging UnitA simple wishbone interface which enables to read values of critical
registers from different modules of the switch gateware (e.g.: current
number of used pages in the SWcore)Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/29Documentation of HDL2019-02-12T09:51:43ZBenoit RatDocumentation of HDLA simple documentation on how to synthetize and which block are involved
could be nicehttps://ohwr.org/project/wr-switch-hdl/issues/28activity LED for wr0 is never blinking2019-02-12T09:51:43ZBenoit Ratactivity LED for wr0 is never blinkingI don't know if it is a feature or not, but it is not possible to make
it work with only one switchhttps://ohwr.org/project/wr-switch-hdl/issues/27v4-dev - [Endpoint] VLAN tagging/untagging2019-02-12T09:51:42ZMaciej Lipinskiv4-dev - [Endpoint] VLAN tagging/untaggingFixed bugs in Endpoint:
\- proper tagging of frames
\- untagging of frames
\- passing the newly tagged VLAN to RTU
Tested:
\- Port as Access Point which adds VLAN tag
\- Untagging on egress
Still, all the combinations in the attached table needs to be tested
### Files
* [Support_to_Enhanced_Internal_Sublayer_Service.pdf](/uploads/728d0d589d1c12569d6c85f7c34bd24d/Support_to_Enhanced_Internal_Sublayer_Service.pdf)Maciej LipinskiMaciej Lipinskihttps://ohwr.org/project/wr-switch-hdl/issues/26Switch locking to wrong offset2019-02-12T09:51:41ZGrzegorz DanilukSwitch locking to wrong offsetAfter replugging the fiber WR slave Switch sometimes locks with the
offset about -700 ps. If you are unlucky and have 2-3 layers of
switches, your WR network might not be sub-ns any more.
### Files
* [switch_bug.PNG](/uploads/7fb82df2b752d7991aee2025682a48ce/switch_bug.PNG)Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/25v3.0 - [PWM] FANs are turned off by default2019-02-12T09:51:40ZGrzegorz Danilukv3.0 - [PWM] FANs are turned off by defaultPWM HDL module adjusting the speed of FANs in WR Switch box makes them
turned off by default. If something bad happens with HAL software and it
will not start when the switch boots, user will end up with programmed
FPGA but no cooling from FANs.Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/23Tagging of PTP (and other slow protocol frames)2019-02-12T09:51:40ZMaciej LipinskiTagging of PTP (and other slow protocol frames)If we use tagging at the ingress port, we tag with VLAN frame all the
incoming traffic, this also concerns PTP, RSTP, etc:
1\) related to other issue: we need to forward this to CPU regardless of
VLAN tag
2\) not sure it's good if CPU receives this traffic with VLAN tags,
possible solution: untag all the traffic coming to CPU -\> needs to
brainstormed whether this is goodGrzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/22WR Switch crashes under the burst of frames.2019-02-12T09:51:39ZGrzegorz DanilukWR Switch crashes under the burst of frames.Although it was proven in existing installations that the WR Switch
provides a stable timing distribution, its networking features are still
a work in progress. The low latency features are not in the official
firmware, but the Ethernet switching functionality is there.
To verify the performance of Ethernet switching, the tests were made
with *Spirent TextCenter SPT-2U* device. Results for the WR Switch v3.3
running latest stable firmware release v3.3 are presented in the table
(100% load is the full Gigabit Ethernet
load):
![](/uploads/e0e799b6e336fadbe61c55414ed896c3/v3.3_networking_test.png)
You can see there, that for some loads WR Switch starts loosing frames.
It's especially notable for small payloads (64 bytes). Moreover, when it
starts loosing 100% frames, it's unable to recover the correct state
when the traffic load is reduced (i.e. bursting a port with 94% load of
128 bytes crashes the WR Switch so that it's unable to forward any more
Ethernet frames, even with 10% load).
Current version of the WR Switch gateware/software can be crashed with a
burst of Ethernet frames. The threshold when the crash occurs depends on
the frames size and the traffic load.
### Files
* [v3.3_networking_test.png](/uploads/e0e799b6e336fadbe61c55414ed896c3/v3.3_networking_test.png)Grzegorz DanilukGrzegorz Danilukhttps://ohwr.org/project/wr-switch-hdl/issues/21v3.3 - WR Switch locks on wrong offset once in a while2019-02-12T09:51:38ZGrzegorz Danilukv3.3 - WR Switch locks on wrong offset once in a whileSometimes after connecting the fiber WR Switch locks on wrong offset
(e.g. 3ns, 7ns) and stays that way. The event is very rare but it
happens once in a while.https://ohwr.org/project/wr-switch-hdl/issues/19Add HW-forward-to-CPU of Reserved addresses2019-02-12T09:51:37ZMaciej LipinskiAdd HW-forward-to-CPU of Reserved addressesIt requires modifying slightly already existing forward of PTP frames to
CPUMaciej LipinskiMaciej Lipinski