Netzwerkchipdingsi

[cycomate]

Hallo allerseits -

mal ne ganz dumme Frage:

ich habe schon gesehen, daß sich einige LED an ihren Netzwerkchip gebrutzelt haben und solche schönen Sachen.

Wenn sowas möglich ist, wie sieht es denn damit aus, gleich einen anderen - full duplex fähigen - 100mbit chipsatz einzulöten?

Momentan habe ich so das Gefühl, die Netzwerkeinheit der dbox2 ist der Flaschenhals für richtig anständiges streaming. Wenn ich über tcp streame, ist die Aufnahme meist schon nach 10 sekunden nicht mehr lippensynchron, bei udp streaming ist es zwar synchron, aber ab und zu sind doch mal massive Bildstörungen zu beobachten.

Spricht irgendwas dagegen, abgesehen von der Fummelarbeit und der Benutzung eines anderen Treibers?

[tmbinc]

ja - es gibt keine ordentlichen chips für 100mbit die nicht auf PCI basieren.

das gleiche problem gibts in der dreambox. da ist einer der zwei verfügbaren 100mbit controller drin (es gibt noch einen von asix, aber viel besser ist der auch nicht), und die box schafft nichtmal annähernd die hälfte - und das ist nen 252MHz prozessor.

das problem ist die daten zum netzwerkchip zu kriegen. bei der dbox ist der netzwerkchip ja cpu-intern im cpm (draussen ist ja nur noch nen MAC+PHY), daher kann man recht schnell die daten dareinkriegen (wenn ich mich recht entsinne kann der sogar DMA).

richtig sinn macht sowas nur mit PCI und bus mastering. dafür braucht man aber einen pci controller. der wiederrum muss zugriff auf den ram haben. das alles ist in der dbox leider so nicht möglich

also theoretisch könnte man IRGENDWIE nen 100mbit chipsatz da rein kriegen, aber bringen würde das imho nicht so viel.

[cycomate]

schade

aber thx für die Ausführung!

[Bitbanger]

Mit dem Gedanken hab ich auch schon gespielt - aber 100MBit-PHYs haben je vier Datenleitungen RXD und TXD, der SCC2 im MPC823 hat halt nur je eine, somit gehen nur 10MBit.


@tmbinc:

Laut dem Reference Manual kann der MPC823 Full-Duplex Ethernet, der PHY und die Beschaltung zum MPC können es auch - hast Du ne Ahnung warum die Box trotzdem nur auf Half-Duplex läuft?

[tmbinc]

genauer lesen

Full duplex kann er nur im loopback mode, und da bringt das nicht so wirkl ich viel.

[Bitbanger]

Du hast Recht. Wer lesen kann ist klar im Vorteil (ist aber auch gut versteckt: auf S. 1-3 steht einfach nur "Ethernet/IEEE 802.3 Support (10Mbps and Full-Duplex Operation")

Ich kann's nicht fassen: wenn das FDE-Bit gesetzt ist muß auch LPB gesetzt sein, was für ein Schwachsinn. Das Manual wurde wohl eher von Motorola's Marketing geschrieben, reden erst großartig von Full-Duplex, nur in einer kleinen Anmerkung ist der Haken dabei erklärt. Der MPC ist wohl dafür optimiert, sich selbst zu beschäftigen.

[lord_binary]

Ihr habt recht, im Manual steht, dass das FDE Flag nur in Verbindung mit LPB zu setzen ist. Es steht da aber auch, dass es 2 Loopback modi gibt. internal und external.

Fuer 'internal' setzt man das DIAG Feld im GSMR_L. Dabei werden RX mit TX und snd u. rcv clock verbunden. Da geht dann natuelich von aussen nichts rein oder rauss.

Was aber ist mit 'external'? Das DIAG Feld bleibt dabei auf 'normal operation', das klingt soch schonmal gut. Die Beschreibung sagt, dass ein paralleler Sende- und Empfangsbetrieb ueber den EEST funktioniert. Und das klingt fuer mich *sehr gut*.

Also ich glaub ja, dass diese Kombination von FDE u. LBP nichts anderes ist als die Collision Detection abzuschalten, genau das, was wir wollen. Warum das im Manual so komisch drinsteht koennte folgenden Grund haben: Zu der Zeit, als diese Chip designed wurde gab es hauptsaechlich Ethernet HUBs und selbst Switche konnten bei 10 MBit/s meist nur half duplex. Also war diese Modus praktisch nicht zu verwenden. Fuer einen externen Loopback Test musste man aber Collision Detection ausschalten, sonst gabs ja nur Kollisionen.

Lange Rede kurzer Sinn: Ich wuerde es toll finden, wenn das jemand mal mit den beiden Flags gesetzt testen koennte. Ich mach das zur Not auch selber, das wird nur ein bischen dauern bis ich alles zusammen hab um cvs builds hinzubekommen.

Kann das mal jemand testen?

mfg

lord_binary

[dhd]

sag mir was ich machen soll und ich teste direkt

[Npq]

dhd: Naja, den Kernel entsprechend patchen. (müßte in arch/ppc/8xx_io/enet.c und Umgebung sein)

Das mit dem external hat mich auch mal gewundert, für mich hörte sich das so an, als wenn das was reinginge dann auch wieder rausgehen würde. Ob der Chip dann aber auch Zugriff auf die Daten hat?

Da war aber noch was mit dem äußeren IC, ich meine irgendeine Leitung war da für FD nicht richtig beschaltet, hatte mir das aber nur mal kurz angesehen.

Interessant wäre es sicherlich, leider hab ich keinen Switch der mir direkt sagt ob FD aktiviert ist.

Npq

[lord_binary]

Hi,

das sollte es sein:

---snip---
*** arch/ppc/8xx_io/enet.c-ORG 2003-12-28 13:46:57.000000000 +0100
--- arch/ppc/8xx_io/enet.c 2003-12-28 13:50:24.000000000 +0100
***************
*** 894,901 ****

/* Set processing mode. Use Ethernet CRC, catch broadcast, and
* start frame search 22 bit times after RENA.
*/
! sccp->scc_pmsr = (SCC_PMSR_ENCRC | SCC_PMSR_NIB22);

/* It is now OK to enable the Ethernet transmitter.
* Unfortunately, there are board implementation differences here.
--- 894,902 ----

/* Set processing mode. Use Ethernet CRC, catch broadcast, and
* start frame search 22 bit times after RENA.
+ * Enable Full duplex mode (requires external loopback configuration)
*/
! sccp->scc_pmsr = (SCC_PMSR_ENCRC | SCC_PMSR_NIB22 | SCC_PMSR_LPB | SCC_PMSR_FDE);

/* It is now OK to enable the Ethernet transmitter.
* Unfortunately, there are board implementation differences here.
---snap---

Good luck und nicht vergessen den switch *fest* auf full duplex zu stellen. Auto Negotiation klappt da warscheinlich nicht (klappt eh nie so, wie man das erwartet, irgendwie kaputt...)

lord_binary

[Npq]

Also spielen tut es nachher noch, aber zumindest ein Switch zeigt kein FD an, man müßte das wohl fest verdrahten und sich nochmal die Beschaltung von dem PHY/MAU-IC da drin ansehen.

Da hab ich aber momentan nicht die große Lust zu, am einfachsten wäre es wohl, die 2er per Cross-Kabel direkt an einen PC zu hängen und dann ein bißchen mit dem Linuxtreiber für die Netzwerkkarte zu spielen und FD fest einzuschalten.

Kann ja mal jemand ausprobieren.

Npq

[obi]

an dem switch hier bringt es kein laempchen zum leuchten.
(CONFIG_SCC_ENET_FULL_DUPLEX in u-boot)

[lord_binary]

@obi

Das wundert mich nicht wirklich, da der MPC823 kein auto-negotiation kann. Ich denke mal das ein Switch, wenn er auf 10 MBit/s laeuft entweder default maessig half-duplex waehlt oder gar kein 10 Mbit/s full-duplex kann (ja, solche gibts auch...).

Am besten mal per crosscable an nen linux host connecten und dann ein paar tests fahren. Ein netstat (-i) auf der dbox waere natuerlich auch ganz nett, da sieht man dann gleich, ob collisionen gezaehlt werden.

lord_binary

[Rudi Ratlos 4711]

Vielleicht hilft es (bei SAGEM) wenn man mal zwecks Diagnose an die pins 6-9 je eine LED mit Vorwiderstand auf +3,3V hängt.

Dann sieht man schön Linkstatus / TXD / RXD und Collisions....

RR4711

[Npq]

Gerade noch mal geschaut, zwar nur für Nokia und Sagem, bei den anderen weiß ich nicht was drin ist.

Es gibt bei beiden PHY/MAU-ICs einen Pin namens "LEDC/!FDE". Das ist Pin 6 bei der Sagem (LTX905LC). Als Ausgang zeigt er die Kollisionen an, als Eingang wird die Kollisionserkennung abgeschaltet falls er auf Masse liegt.

Bei Nokia scheint der Pin laut Schaltbild nicht angeschlossen zu sein, bei der Sagem liegt da ein 10k-Widerstandsarray, wahrscheinlich gegen Vcc (gerade nicht im Betrieb gemessen).

Für Full Duplex muß dieser Pin aber wie gesagt gegen Masse gezogen werden.

Npq

[Rudi Ratlos 4711]

Wenn es hilft:

http://www.intel.com/design/network/pro ... 927102.pdf

Das iss der Ethernet PHY der Sagem (evtl. auch philips)

RR4711

[Jau]

Wie Npq bereits sagte: Der Pin 6 muß gegen Masse gesetzt werden, hatte vor 2 Jahren oder so mal mit tmbinc und derget darüber gechattet. Prob war laut ihrer Aussage die Anbindung MPC<=>PHY, denn die wäre auch nur half.

Wäre natürlich geil, wenn das klappen würde.

[Rudi Ratlos 4711]

So, hab mal die Änderungen reinkompliert und den /FDE Pin auf Ground gelegt. (SAGEM Box).

Box bootet noch, allerdings gibts da verstärkt Probleme mit dem NFS Server bei Yadd booten. Logisch, transceiver arbeitet FDX, aber die Netzwerkkarte nur Halbduplex.

Hab auf der rechnerseite ne 3COM 3C905 drin. Wenn ich die Yadd hochgefahren habe, kann ich mit Gewalt den 10BaseT Fullduplexmode einschalten (Modulparameter).

Die Verbindung zur Box läuft dann einwandfrei.

Hab mal das /dev/mtd/5 (komplettes Flash) in eine Datei ins /tmp kopiert und die dann vom Linuxrechner aus mit FTP rüberkopiert.

Code: Alles auswählen

150 Opening BINARY mode data connection for test.img (8388608 bytes).
226 File send OK.
8388608 bytes received in 7.13 secs (1148.6 kB/s)
ftp> quit
221 Goodbye.
deb1800xp:/tmp# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:50:04:18:EC:9C
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11751 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10891 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:9676294 (9.2 MiB)  TX bytes:5263649 (5.0 MiB)
          Interrupt:11 Base address:0xd000

Also keine Collisions mehr und Transferrate ist dann wohl am theoretischen Limit. Müsste man nur den Bootloader und das UBOOT so patchen, daß die gleich Fullduplex aktivieren.

Kann jemand mal ne Vergleichsmessung machen, was ohne Fullduplex passiert ?

Und es wird wohl nur mit ner Netzwerkkarte über Crosslink gehen, weil Autonegotiation iss wohl nicht.

Evtl. iss ja ein I/O Port am Proz frei, dann ginge sowas evtl. zu implementieren.

RR4711

[mash4077]

Kann jemand mal ne Vergleichsmessung machen, was ohne Fullduplex passiert ?

~ > ifconfig eth0
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6163 errors:0 dropped:0 overruns:0 frame:0
TX packets:4138 errors:0 dropped:0 overruns:0 carrier:0
collisions:1924 txqueuelen:100
RX bytes:8688804 (8.2 MiB) TX bytes:275906 (269.4 KiB)
Base address:0x3d00

Keine Ahnung, ob das das ist was Du erwartest hast!?
Dbox hängt an nem' Switch.

Gruß
mash

[Rudi Ratlos 4711]

Ja, danke, das hatte ich erwartet. Collisions ohne Ende.

Ich streame hier gerade RTL2 ohne eine einzige Collision während ich RTL schaue

Wie lange dauert es 8MB von der Box via FTP zu kopieren ? Kannst du das mal testen ?

RR4711

[mash4077]

Ja, danke, das hatte ich erwartet. Collisions ohne Ende.

Ich streame hier gerade RTL2 ohne eine einzige Collision während ich RTL schaue

Wie lange dauert es 8MB von der Box via FTP zu kopieren ? Kannst du das mal testen ?

RR4711

Natürlich!

Etwa 10 Sekunden

Gruß
mash

[wojo]

Evtl. iss ja ein I/O Port am Proz frei, dann ginge sowas evtl. zu implementieren.
RR4711

Ich hatte angedacht, das über einen PCF8574(A) (http://www.semiconductors.philips.com/pip/PCF8574T.html) zu machen. Der Chip wird an den I2C-Bus angeschlossen und bietet 8 zusätzliche PINS. Ob die entsprechende I2C-Adresse noch frei ist habe ich aber noch nicht geprüft.
Gibts bei Reichelt ab EUR 2,40.

[Z80]

Evtl. iss ja ein I/O Port am Proz frei, dann ginge sowas evtl. zu implementieren.
RR4711

Ich hatte angedacht, das über einen PCF8574(A) (http://www.semiconductors.philips.com/pip/PCF8574T.html) zu machen. Der Chip wird an den I2C-Bus angeschlossen und bietet 8 zusätzliche PINS. Ob die entsprechende I2C-Adresse noch frei ist habe ich aber noch nicht geprüft.
Gibts bei Reichelt ab EUR 2,40.

Selbiges I2C-IC wurde/wird (erfolgreich) von " Friedel " (jetzt im dbox2world-board, vorher in s-board) verwendet um per Linux-Soft die Frequenz (s)einer entwickelten (hier im Board aber nicht näher diskutierten HardWare-Erweiterung (MC)) der dBox2 zu realisieren. Hierbei sind letzlich nur SCL/SDA des i2c der jeweiligen dBox2 anzuzapfen.
Weiterhin existiert softwareseitig für den PCF8574 T/A der/ein Source-Code/binary. Als Modul eingebunden, wird durch einfaches zuweisen von z.B.

echo "2" > /proc/pcf8574/pcffreq

eines der 8 verfügbaren Register gesetzt.
Zitat:

PCF8574T ist der Adressbereich 40 (wenn Adressleitungen A0,A1,A2 auf Masse gesetzt sind)
Für das PCF 8574AT gilt genau das Gleiche, nur eben Adressbereich 70.

Nun Erklärungen zu dem IC.
Das IC hat 8 Datenports.

Wir benutzen die Ports P0, P1, P2

P0 = x MHz Oszillator
P1 = y MHz Oszillator
P2 = z MHz Oszillator

Nun muß man beachten, daß wir ja den entsprechenden Port schalten, indem wir ihn gegen 0 ziehen.

Wenn man sich das Data Byte 1 ansieht, dann stellt man sich die 8 Bit nebeneinander auf 1 vor. Jedes Bit stellt dann einen Port dar.
Da wir ja den Oszillator schalten, indem wir den entsprechenden Ausgang auf 0 setzen, darf zwingend immer nur einer der Bits auf 0 stehen
(streng genommen gilt das natürlich nur für den Port 0-2, da wir die anderen ja nicht benutzen)
Von rechts angefangen(wie beim binären Zahlensystem ist dann mit

1 1 1 1 1 1 1 1 = FF alle Ausgänge auf High

Für den port P0 bedeutet das

1 1 1 1 1 1 1 0 = FE

für den Port P1 bedeutet das

1 1 1 1 1 1 0 1 = FD

für den Port P2 bedeutet das

1 1 1 1 1 0 1 1 = FB

Also

PCF 8574T

y MHz = 40 FD

x MHz = 40 FE

z MHz = 40 FB


PCF 8574AT

y MHz = 70 FD

x MHz = 70 FE

z MHz = 70 FB

Ich habe das mal mitgepostet, falls jemand wirklich seine Kaffeemaschine über die Box schalten will. Es sind ja noch Ports frei und mit der Soft kann man ja eigene kleine Schaltungen entwerfen, quasi Relaisbänke oder so.

<-- sowas ähnliches brauchen wir ja eben
Eingebunden sieht das dann so aus:

Code: Alles auswählen

Using /var/bin/pcf8574.o
insmod: Warning: kernel-module version mismatch
        /var/bin/pcf8574.o was compiled for kernel version 2.4.22
        while this kernel is version 2.4.22-dbox2

pcf8574: $Id: pcf8574.c,v0.02 2003/09/26 22:30:00 DoppelD Exp $
i2c-core.o: driver PCF8574 Sensor Chip Driver registered.
[pcf8574.c]: pcf8574_attach_adapter
[pcf8574.c]: pcf8574_detect
[pcf8574]: found PCF8574 chip @ Adress 0x4e
i2c-core.o: client [PCF8574 chip] registered to adapter [PowerPC 8xx I2C adapter
](pos. 5).
PCF8574: attached to adapter PowerPC 8xx I2C adapter

Sollte also absolut kein Problem sein mit dem i2c-IC, obigen Adressen/Registern und ggf. einem Schalttransistor unserem Ethernet-Chip den FullDuplex-Mode beizubringen.

[dhd]

hmmm bringt das uns denn was wenn die hdd ja auchnoch rein soll dann würd ich persönlich gerne wissen ob das nich nen bischen happig wird *g* besonders wenn ich höhre das die evt auf den hdd port auch nen netzwerk draufmachen wollen oder was soll nic sonst heißen

[Z80]

hmmm bringt das uns denn was wenn die hdd ja auchnoch rein soll dann würd ich persönlich gerne wissen ob das nich nen bischen happig wird *g* besonders wenn ich höhre das die evt auf den hdd port auch nen netzwerk draufmachen wollen oder was soll nic sonst heißen

ähmm, bist du dir sicher, dass du diesen thread und den "IDE" thread gelesen und verstanden hast?
Wozu auf einen bis dato noch nichtmals geplanten, geschweige denn betriebsbereiten, ungetesteten "Ethernet via IDE"-Port warten, wenn durch geringsten aufwand die vorhandene, betriebsbereite, getestete hardware (und Software(!)) u.U. im Brutto-Datendurchsatz verdoppelt werden kann?