I bought a TP-link TG-3468 (v. 4.0) ethernet board for my X5000. I have used the same product before, and it has worked ok with AmigaOS, MOS and Linux.
This new board does not seem work with AmigaOS anymore. Ranger reports it has a rtl8161 chip ( the earlier one had a rtl8168). In MOS it works automatically with the rtl8168 driver, which would suggest the rtl 8161 is compatible with rtl8168.
But why does it not work with AmigaOS...? Is there some trick to get the AmigaOS driver to accept the card? I did already try to create a settings file 'unit0' into ENVARCHIVE/rtl8169.device" drawer with this type of text, without success:
If its compatible chip, it might be as simple as being ignored due to wrong product id. if not you need a new driver for etch, or driver that support different chips (some drivers supports many different chips under Linux).
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@Skateman >Why not use the onboard X5000 adapter ??
Because it does not work with Linux! You seem to forget that you are the ONLY X5000 user for which that is working normally... All others have to use the unplug/replug trick with Linux, which is unacceptable.
Besides, I do not have free ethernet ports in my router to use two lines for X5000. I have to have one adapter which works with all OSs (AmigaOS, MOS and Linux). The earlier version of TG-3468 was such.
@Gregor Sorry, never had to meddle with network cards on the x5000, but why not buy a cheap 5 port switch (rougly 32 euro for a 5 port 10/100/1000) instead, then you have 4 ports out for the x5000 and remeber you have two ethernet ports on the X5000 both I think works on linux.
The best solution would be to find another one of the older version of TG-3468. But it is a hit and miss as most dealers do not know what they are selling.
>and remeber you have two ethernet ports on the X5000 both I think works on linux.
No they don't... Please reread my answer to Skateman above!
Story continues... I succeeeded to find an older v.2.0 TG-3468 board. This one works also with AmigaOS (and with Linux as the v.4.0 board did), but not with MorphOS! The card is recognized by the RTL8168 driver of MOS but it cannot be configured properly. There appears a window (NetStack.log) showing this error message:
This is exactly the kind of issue I (and obviously also the MOS devs) faced when developing network drivers for Realtek chipsets: there are a zillion different versions of each chip. Each with more or less subtle changes and incompatibilities. Setting only a single bit of one of the registers different may cause one chip of the "same" family work and another one fail.
In this case, it is even worse, because you are trying to use a driver for one family (8169) with chips from a different family (8168 - the 8161 is a variant of it).
There are actually a few variants of 8168 chips (those are native PCIe chips), which work similar enough to an 8169 (PCI) variant and hence work with rtl8169.device. The vast majority doesn't however.
The only way to support most (not all) variants of 8168 would be to write a dedicated driver for 8168. As far as I can see from a very quick look, there are at least 9 (!) different configuration paths to follow, depending on the exact variant. So it is not exactly a 5 minute job, if I even could be motivated to take the job .. I don't really see the benefit of it beyond rare special cases. Most of the time the internal NIC is enough or a supported PCI solution can be used.
So, I would actually suggest to get a plain 8169 board for good old PCI if you aren't able to use the internal NIC.
AmigaOS 4 core developer www.os4welt.de - Die deutsche AmigaOS 4 Gemeinschaft
"In the beginning was CAOS.." -- Andy Finkel, 1988 (ViewPort article, Oct. 1993)
Cyborg wrote:This is exactly the kind of issue I (and obviously also the MOS devs) faced when developing network drivers for Realtek chipsets: there are a zillion different versions of each chip. Each with more or less subtle changes and incompatibilities. Setting only a single bit of one of the registers different may cause one chip of the "same" family work and another one fail.
In this case, it is even worse, because you are trying to use a driver for one family (8169) with chips from a different family (8168 - the 8161 is a variant of it).
There are actually a few variants of 8168 chips (those are native PCIe chips), which work similar enough to an 8169 (PCI) variant and hence work with rtl8169.device. The vast majority doesn't however.
Thank you for clarifying the situation... Can you identify those different RTL variants on the basis of the code strings printed on the chips, or are there subvariants even within them? Are these variants properly documented, or do you have to test yourself how they behave?
I checked the codes from those two TG-3468 boards I have now at hands:
V.4.0 board RTL8168H KCCD6H1 QK51
V.2.0 board RTL8168E GCC17P1 GG526
The third card (which works with all OSs) I have is probably v. 3.0 but cannot check it now as it is in my second machine located otherwhere.
Quote:
The only way to support most (not all) variants of 8168 would be to write a dedicated driver for 8168. As far as I can see from a very quick look, there are at least 9 (!) different configuration paths to follow, depending on the exact variant. So it is not exactly a 5 minute job, if I even could be motivated to take the job .. I don't really see the benefit of it beyond rare special cases. Most of the time the internal NIC is enough or a supported PCI solution can be used.
Yes, it would mean too much work to try to support all variants... But would it be easier to modify the current RTL8169 driver and add there support for a variant present e.g. in the latest TG-3468 revision?
Quote:
So, I would actually suggest to get a plain 8169 board for good old PCI if you aren't able to use the internal NIC.
Actually I had originally such one in the machine I have now in front of me but it started to show connection problems with Linux, and it did not work at all with MOS. The primary reason I need a separate NIC is Linux, which does not work with the X5000's internal NIC (network needs the 'unplug/replug' tric to become available), and it would also be unpractical to move the network cable from one nic to another when switching OS.
and it would also be unpractical to move the network cable from one nic to another when switching OS.
Do you connect through a LAN? If so, just use two separate network cables for your two NICs (and if necessary put a network switch in between), i.e. have different IP numbers for the two.
Gregor wrote: Can you identify those different RTL variants on the basis of the code strings printed on the chips, or are there subvariants even within them? Are these variants properly documented, or do you have to test yourself how they behave?
Unfortunately, the "subvariants" are the problem. It is not said, that two 8168H chips actually have the same MAC or PHY version. They should, but in reality they don't have to. I had this issue with 8139 and 8169 already. The documentation gives many information, but i heavily depends on the version of the documentation you've got.
Basically, for 8168 I'd have to hunt for the latest documentation version I could get. Then start implementing a new driver from scratch. The generic framework is of course the same for all my network devices, but the chip specific parts obviously differ. Especially the initialisation code is the critical part here as that is, where the driver has to be very exact on which bit in which register it sets or unsets for each variant of a chip, with each combination of MAC and PHY version. Most likely it would take long until another new, unsupported variant surfaces in the wild :/
Quote:
Yes, it would mean too much work to try to support all variants... But would it be easier to modify the current RTL8169 driver and add there support for a variant present e.g. in the latest TG-3468 revision?
No, see above. It is pure luck that there is an 8168 variant, which works with rtl8169.device. Supporting other 8168 variants would just create even more mess in the 8169 driver. A separate driver would the only sensible way to go, with all its ups and downs.
Quote:
The primary reason I need a separate NIC is Linux, which does not work with the X5000's internal NIC (network needs the 'unplug/replug' tric to become available), and it would also be unpractical to move the network cable from one nic to another when switching OS.
I understand your issue, but it seems to me that the first one to ask for a fix would be the responsible dev for the Linux X5000 network driver. Granted, that might be difficult, but it really is rather a Linux issue than an AmigaOS issue. But even if not, there is still the thing with halfways economical use of my rare spare time, which doesn't really fit for writing a complete new network driver, which is not really of use for the majority of users, but basically solves only a very rare problem (you are the only one I know of) ... and that problem isn't even caused by AmigaOS nor my drivers, which work just fine with the chipsets they were designed for.
May if I'd win the lottery or if someone would pay me the regular rate, so I could spend time on such a driver without sacrificing part of my income, but each is rather unlikely.
If you can't find a chipset, supported properly by all three systems, the suggestion of nbache is probably the way to go for you. Use two network cables, one on the internal NIC for AmigaOS and MOS and the other one for Linux.
AmigaOS 4 core developer www.os4welt.de - Die deutsche AmigaOS 4 Gemeinschaft
"In the beginning was CAOS.." -- Andy Finkel, 1988 (ViewPort article, Oct. 1993)
Unfortunately, the "subvariants" are the problem. It is not said, that two 8168H chips actually have the same MAC or PHY version. They should, but in reality they don't have to. I had this issue with 8139 and 8169 already. The documentation gives many information, but i heavily depends on the version of the documentation you've got.
Ok, thanks for the info... I do not envy you who have to deal with that kind of mess while developing drivers .
Quote:
If you can't find a chipset, supported properly by all three systems, the suggestion of nbache is probably the way to go for you. Use two network cables, one on the internal NIC for AmigaOS and MOS and the other one for Linux.
Well, I have now all the three versions (2.0, 3.0 and 4.0) of TG-3468 in my hands, and tested them in a second X5000 (quad core). Quite peculiar... The v. 2.0 board which did not work with MorphOS in X5020 works with all OSs in X5040! Any idea why...? I tested the same MOS disk/installation in both machines, so the difference does not come from there.
Here is the complete compatilbility pattern for TG-3468:
V.2.0 board (RTL8168E GCC17P1 GG526)
* Works in X5040 with AmigaOS, MOS and Linux, but in X5020 only with AmigaOS and Linux
V.3.0 board: (RTL8168E JCE75P1 GJ51B)
* Works with AmigaOS, MOS and Linux
V.4.0 board: (RTL8168H KCCD6H1 QK51)
* Works with MOS and Linux
So, I can use the V3 board in X5020 and V2 board in X5040, which solves my problem - no need to hunt a second V3 board.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
All others have to use the unplug/replug trick with Linux, which is unacceptable.
