Servus, kennt sich jemand mit dem genannten LAN Controller aus bzw hat damit schon gearbeitet? Ich kann Prima damit Daten Senden aber eben nicht empfangen egal was ich einstelle
Ich kann Prima damit Daten Senden aber eben nicht empfangen egal was ich einstelle
Bei der un-überschaubaren Menge an Informationen wird es schwierig werden eine Lösung zu finden.
wird es schwierig werden eine Lösung zu finden.
Er will keine Lösung finden, er sucht jemanden der den Controller kennt 😄
Er will keine Lösung finden, er sucht jemanden der den Controller kennt 😄
Ein Fall für Parship? Oder Julia Leischik?
Servus.. ich gehe erst ins Detail wenn sich hier jemand findet der schon mit diesem Controller gearbeitet hat.. Externe können hier sowieso nicht helfen weil das Thema zu speziell ist.
Hui, 600 Seiten Datenblatt. Das Teil ist etwas schon etwas komplexer und als Ethernet Switch mit SPI auch etwas exotisch.
Ich an deiner Stelle würde ja mal sagen was schon geht und was nicht. Ethernet können hier einige und SPI auch. Damit lassen sich bereits sehr viele der Probleme eingrenzen.
Hui, 600 Seiten Datenblatt. Das Teil ist etwas schon etwas komplexer und als Ethernet Switch mit SPI auch etwas exotisch.
Nein, isser nicht. Als managed Switch haben sie alle eine (Quad)-SPI. Denn da kommt üblicherweise das Eprom dran, wo die Firmware rein kommt. Oder eben die Schnittstelle, wo der MuC für das Management dran kommt.
Dass er nur zwei Ports hat, ist dann schon exotischer. Damit ist er quasi nur dazu da, um zwei Netzwerke zu trennen.
PS: Die Gigabit-Brüder kommen mal ganz nebenher mit 4..8kSeiten Handbuch und Appnotes. Um solche Knödel zu verwenden, sollte man zumindest in Grundzügen einen Überblick haben, was TCP/IP auf den unteren Layern so macht. Sonst wird das schnell ein Martyrium.
PPS: Daten senden aber nicht empfangen klingt etwas nach einer verkorksten Filter/NAT Geschichte im Switch.
Dass er nur zwei Ports hat, ist dann schon exotischer. Damit ist er quasi nur dazu da, um zwei Netzwerke zu trennen.
Genau genommen 3, der Host hängt ja auch als Port mit dran. Im Embedded-Bereich ist das praktisch fürs Daisy Chaining von Geräten, ohne dass die CPU mit softwaremässigem Bridging belastet wird.
IP-Telefone sind auch eine typische Anwendung dafür, aber heutzutage eher mit GbE.
Hui, 600 Seiten Datenblatt. Das Teil ist etwas schon etwas komplexer und als Ethernet Switch mit SPI auch etwas exotisch.
Ich an deiner Stelle würde ja mal sagen was schon geht und was nicht. Ethernet können hier einige und SPI auch. Damit lassen sich bereits sehr viele der Probleme eingrenzen.
Hallo, also ich nutze kein SPI sondern den 16 Bit Paralell Bus und die Kommunikation funktioniert. Ich kann alle Register beschreiben und lesen und ich kann auch Datenpakete über das Ethernet senden aber ich kann eben keine Pakete auf dem Kontroller empfangen. Dazu lese ich das RX_FIFO_INF (unteren 16Bit) und das ist immer 0 (sollte größer 0 sein wenn ein Paket empfangen wurde) RX an sich ist aktiviert und auch so konfiguriert das ich alle Pakete empfangen müsste
PPS: Daten senden aber nicht empfangen klingt etwas nach einer verkorksten Filter/NAT Geschichte im Switch.
ja das denke ich auch, aber wie gesagt ich habs eigentlich so konfiguriert das ich alles auf Port 0 (der Interne Port an dem mein PIC hängt) empfangen sollte
Im Embedded-Bereich ist das praktisch fürs Daisy Chaining von Geräten
Exakt das ist der Grund für den zweiten (dritten) Port.. es soll nur weitergeleitet werden
ich habs eigentlich so konfiguriert das ich alles auf Port 0 (der Interne Port an dem mein PIC hängt) empfangen sollte
Was sagen die Counter-Register?
Schuss ins Blaue: Die eingehenden Pakete landen in einem VLAN, in dem Port 0 nicht hängt.
ein Auszug der gesetzten Konfiguration: (ich habe übertrieben viel Aktiviert um zu provozieren das ich überhaupt irgendwas empfange, später will ich natürlich filtern)
HMAC_CR=
Receive All Mode (RXALL)
Disable Receive Own (RCVOWN)
Full Duplex Mode (FDPX)
Pass All Multicast (MCPAS)
Promiscuous Mode (PRMS) default set
Hash/Perfect Filtering Mode (HPFILT)
Transmitter enable (TXEN)
Receiver Enable (RXEN)
hier noch ein interessanter Satz ausm Datenblatt zum Verständniss: (HMAC_CR) Bits 19-15, 13, and 11 determine if the Host MAC accepts the packets from the switch fabric. The switch fabric address table and configuration determine which packets get sent to the Host MAC.
Der erste Teil ist damit erfüllt (HMAC_CR), es sollten also alle pakete die vonm switch fabric kommen empfangen werden. Allerdings habe ich das Gefühl das keine Pakete überhaupt vonm switch fabric gesendet werden weil sie vorher schon rausgefiltert wurden.
Ich gehe davon aus das mit "switch fabric address table" die "ALR" gemeint ist ?? Dort habe ich entsprechend die Broadcast MAC eingetragen und meine Port0 MAC. Aber bringt alles nix
Was sagen die Counter-Register?
gute Frage ich check das eben mal.. VLAN müsste glaube ich standartmäßig aus sein
Ich gehe davon aus das mit "switch fabric address table" die "ALR" gemeint ist ?? Dort habe ich entsprechend die Broadcast MAC eingetragen und meine Port0 MAC.
Eigentlich sollte der Switch das alleine machen: Wenn eine MAC-Adresse nicht in der Address Table steht (oder es ein Broadcast ist), geht das Paket an alle zum VLAN gehörigen Ports. Wenn sie drinsteht, nur an den passenden.
ich habe als Beispiel das MAC_RX_256_TO_511_CNT_1 gelesen und das Zeigt 4 Bytes an
Das MAC_RX_256_TO_511_CNT_0 (wo ich nix empfange) zeigt hingegen wie erwartet 0
ich habe sogar die Snooping funktion getestet:
SWE_PORT_MIRROR=
Enable RX Mirroring Filtered
Sniffer Port 0
Mirrored Port 1
Enable RX Mirroring
aber die Pakete die auf Port 1 eintreffen werden nie auf Port 0 weitergeleitet. Wie gesagt senden kann ich was ich will das klappt immer und er sendet es auch auf beiden Ports raus (wie zu erwarten).
ich habe als Beispiel das MAC_RX_256_TO_511_CNT_1 gelesen und das Zeigt 4 Bytes an
Das MAC_RX_256_TO_511_CNT_0 (wo ich nix empfange) zeigt hingegen wie erwartet 0
Die sollten dort eher im TX-Counter auftauchen, das sind schliesslich die Switch-MACs. Beim Host-MAC ist es dann wieder die RX-Seite.
Die sollten dort eher im TX-Counter auftauchen, das sind schliesslich die Switch-MACs. Beim Host-MAC ist es dann wieder die RX-Seite.
mm nee das passt schon so es sind ja eingehende pakete. Ich habe aktuell mein PC am Switch Port 1 hängen und die Fritzbox an Port 2
In den TX countern steht natürlich auch was (in allen dreien) weil senden vom Port 0 aus ja funzt
Hmmm schrieb:
Die sollten dort eher im TX-Counter auftauchen, das sind schliesslich die Switch-MACs. Beim Host-MAC ist es dann wieder die RX-Seite.
mm nee das passt schon so es sind ja eingehende pakete.
Wenn ein Paket auf Port 1 empfangen wird und auf Port 0 landet, würde ich folgendes erwarten:
- Switch-MAC 1: RX-Counter zählt hoch (Paket kommt dort in den Switch rein)
- Switch-MAC 0: TX-Counter zählt hoch (Paket verlässt dort den Switch)
- Host-MAC: RX-Counter zählt hoch (Paket kommt dort an)
Zum Testen würde ich mit unterschiedlichen Paketgrössen arbeiten (z.B. Embedded Device schickt immer kleine Pakete, Test-Gegenstellen grosse), damit Du an den Countern erkennen kannst, woher sie ursprünglich kamen.
Evtl. musst Du übrigens auch noch den Virtual PHY konfigurieren, damit überhaupt Pakete zwischen Host-MAC und Switch Fabric fliessen können.
Port 0 ist die Host MAC - desshalb landen eingehende Pakete beim RX counter 0
0 - virtuell / host mac
1 und 2 sind die Physischen
Evtl. musst Du übrigens auch noch den Virtual PHY konfigurieren, damit überhaupt Pakete zwischen Host-MAC und Switch Fabric fliessen können.
hast du spontan das Register bzw die Datenblatt Seite dazu?
Port 0 ist die Host MAC
Das Datenblatt sagt nein, siehe Figure 2-1. Demnach ist MAC_RX_256_TO_511_CNT_0 der Counter auf Switch-Seite.
hast du spontan das Register bzw die Datenblatt Seite dazu?
Seite 304, Kapitel 12.3.3.
MAC_TX_256_TO_511_CNT_0 = 3
das verwundert mich.. da ich von port 0 nichts gesendet habe.. oder aber es sind irgendwelche automatischen negotiation packete die er beim start sendet das könnte schon sein
VPHY_BASIC_CTRL habe ich so gelassen wie es ist
VPHY_ID_MSB - damit kann ich nichts anfangen ich denke da muss ich nichts einstellen ??
Rest auch auf default gelassen
auf port 1 empfange ich 50 Broadcast packete, die erwarte ich eigentlich zeitgleich auch auf port 0 aber dort kommen die nie an..
irgendwo fehlt mir noch ein Bit welches verhindert das Port 0 Teil des Switches ist, zumindest wenn es um das empfangen von Packeten geht
MAC_TX_256_TO_511_CNT_0 = 3
das verwundert mich.. da ich von port 0 nichts gesendet habe..
Ich wiederhole es nochmal: Die Counter für MAC 0 bis 2 beziehen sich auf die Switch-Seite, d.h. der Switch hat 3 Pakete dorthin (an den Host) geschickt.
oder aber es sind irgendwelche automatischen negotiation packete die er beim start sendet das könnte schon sein
Für STP-BPDUs klingen die recht gross. Sind das evtl. die verlorenen Pakete?
wie kommst du darauf das es von switch Seite und nicht von port Seite zu sehen ist ?
aber sei es drum auf Port 0 kommt nix an und der Promiscuous Mode und Receive All Mode aufm vphy ist aktiv so das alles durchgelassen werden müsste
wie kommst du darauf das es von switch Seite und nicht von port Seite zu sehen ist ?
Weil das die übliche Logik in Switches ist und der Switch im Blockschaltbild auch als abgegrenzte Einheit ("Switch Fabric") gezeigt wird.
Im Host-MAC scheint es leider keine Counter zu geben.
Ich habe aktuell mein PC am Switch Port 1 hängen und die Fritzbox an Port 2
Können die eigentlich über den Switch miteinander kommunizieren? Und landen Deine gesendeten Pakete bei beiden?
Im Host-MAC scheint es leider keine Counter zu geben
die heisen dort nicht direkt counter aber man sieht wie viele pakete empfangen/gesendet wurden und auch wie gros die sind. RX_FIFO_INF und RX_STATUS_FIFO
Können die eigentlich über den Switch miteinander kommunizieren? Und landen Deine gesendeten Pakete bei beiden?
sorry das habe ich überlesen. Ja die Kommunikation über den Switch klappt reibungslos. Wie gesagt ich habe mein PC an Port 1 und den Router an Port 2 während der Testphase
das ist echt zum verzweifeln.. MAC_TX_PKTOK_CNT_0 und MAC_RX_PKTOK_CNT_0 zählt empfangene und gesendete Pakete aber bei der Host Mac kommt angeblich nichts an (RX_FIFO_INF 15:0 == 0), obwohl sie so konfiguriert ist das sie alles durch lassen soll. Irgendwas übersehe ich
MAC_TX_PKTOK_CNT_0 und MAC_RX_PKTOK_CNT_0 zählt empfangene und gesendete Pakete aber bei der Host Mac kommt angeblich nichts an (RX_FIFO_INF 15:0 == 0), obwohl sie so konfiguriert ist das sie alles durch lassen soll.
Was sagt der RX Status FIFO, und zählt evtl. RX_DFC hoch, wenn Pakete reinkommen?
Was sagt der RX Status FIFO, und zählt evtl. RX_DFC hoch, wenn Pakete reinkommen?
beides 0 leider :/
beides 0 leider :/
Vielleicht findest Du hier Anregungen:
https://lore.kernel.org/all/20160219201415.GA9884@lunn.ch/t/
https://lore.kernel.org/all/20160219201415.GA9884@lunn.ch/t/
hab ich schon gesehen.. aber ich kanns mir ja nochmal anschauen
MC support hat sich endlich gemeldet, wenn der Fehler gefunden ist werde ich es hier mitteilen vielleicht hilft es irgendwann mal jemanden ^^
wenn der Fehler gefunden ist werde ich es hier mitteilen vielleicht hilft es irgendwann mal jemanden ^^
Würde mich auf jeden Fall interessieren.
OMG was findet hier für ein up und downvote Wahnsinn statt mach einer scheint nichts besseres zutun zu haben.
Aber back to topic - der MC support ist sehr träge, ich habe denen die Situation möglichst Ausführlich geschildert und ich rechne im laufe der nächsten Woche mit einer Lösung
Es gibt Neuigkeiten. Ich habe es durch Zufall wie es manchmal so ist selbst herausgefunden. Ich darf im Register "MAC_WUCSR" nichts setzten. Jetzt kann ich Pakete empfangen
Ich darf im Register "MAC_WUCSR" nichts setzten.
Dass Du nichts empfängst, wenn Du den Host-MAC in einen WOL-Schlaf schickst, ist allerdings naheliegend und auch so dokumentiert, hier z.B. für PFDA_EN:
"In this mode, normal data reception is disabled, and detection logic within the MAC examines the destination address of each received frame."
Aber danke für die Rückmeldung, das IC klingt insgesamt interessant.
In this mode, normal data reception is disabled, and detection logic within the MAC examines the destination address of each received frame.
ganz genau! Dieser Satz ist mir ins Auge gesprungen und ich habe daraufhin meine Config überprüft und tatsächlch hatte ich dieses Bit gesetzt.
Jetzt habe ich das nächste Problem. Ich empfange ein Paket mit 58 Byte Größe RX Status sagt 64 Byte (was ok ist wegen padding)
Allerdings ist mein 16. DWORD immer 0xC5C80253, ich erwarte aber 0x00000000
Allerdings ist mein 16. DWORD immer 0xC5C80253, ich erwarte aber 0x00000000
Hängt das evtl. mit PADSTR im HMAC_CR zusammen?
das gilt nur für Frames unter 46 bytes.. ich habe hier 58 byte. Außerdem ist es nicht aktiviert
Das komische ist auch das ich anschließend keine weiteren pakete mehr empfangen kann (RX Error Flag ist nicht gesetzt).
ok nevermind, ich kann jetzt auch weitere Pakete empfangen das war ein Fehler in meinem code.
jetzt muss ich mich noch mit PTPv2 auseinandersetzen in zusammenhang mit RTP.. kennst dich da zufällig aus ? Im RTP pakt habe ich ja einen Timestamp (32 Bit) aber das ist nicht der Selbe wie im PTP Paket - wie ist da die Realtion zu einander
Im RTP pakt habe ich ja einen Timestamp (32 Bit) aber das ist nicht der Selbe wie im PTP Paket - wie ist da die Realtion zu einander
Da gibt es gar keine direkte Relation. Bei RTP ist das ein Timestamp innerhalb des laufenden Streams, gemessen in Samples.
Der RTP-Sender kann natürlich per PTPv2 synchronisiert werden, aber so genau will man es wohl höchstens im Broadcast-Bereich haben, wo man dann eher den Studiotakt als Referenz nehmen würde.
jup genau ich will den RTP audio stream mit PTPv2 syncen Stichwort AES67 - Multicast. Eine Einspeise Einheit habe ich, die sendet im 4tel oder 8tel Sek Takt PTPv2 Sync, Anncounce und Follow up messages. Die müsstre ich iwi erstmal in dem Controller auffangen der hat ja volle PTPv2 Unterstützung.
Hmmm bist du noch am Start ? Habe aktuell das Problem das ich keine Multicast Adressen filtern kann. Ich habe die Multicast macs in die ALR eingetragen und das Valid und Static bit gesetzt. Zusätzlich noch das Bit 4 (Filter Multicast) im SWE_GLOBAL_INGRSS_CFG register. Das führt allerdings dazu das ich gar keine multicast frames mehr empfange
nvmd ich habs gefunden,mus die byte order vertauschen
:
Bearbeitet durch User
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.