Hello !

I'm looking for a hint how to force 10BaseT-FD for a switchport on WR1043nd (rtl8366rb) with openwrt.
Got some old devices not capable of autonegotiation.
mii-tool will not do it, swconfig not either.

But since swconfig is capable of reading all neccessary registers from the switch,
should it be not to much effort to make it capable of writing those ?
Unfortunately my coding experience is very close to zero.
Can anybody help ?

Regards,
Ralph

Push...

Regards,
Ralph

Nobody can help ?
Please...

Regards,
Ralph

push.

Have you tried your old devices? No idea about swconfig and the 1043ND switch, but IMHO modern PHY do parallel detection, i.e.
they can detect normal link pulses from a 10BaseT device. They will configure half duplex in this case.

(Last edited by jal2 on 29 Dec 2010, 13:39)

Thank You,
but the problem is, that the old device is set up fixed to 10MBit fullduplex, no way to change that.
And any switch, that does autonegotiation will set it's own side to 10 MBit halfduplex,
which doesn't fit together...

Regards,
Ralph

The driver does not yet support changing the auto negotiation. I have tried to find the datasheet for rtl8366rb to get the correct addresses, so I can try adding this feature to the driver, without success

I'm in a similar situation where my 1043nd connection to my 24 Mbit ADSL modem is limited to 10Mbit link on openwrt, but have 100Mbit link on the factory firmware.

If someone have the register addresses (primarily PortN_Ability, Port Advertising Ability Control Register) for the rtl8366rb I would be happy to try to implement more of the features into the driver. If only I have the datasheet, I could also try to implement features like port mirroring etc. that the chip seems to supports.

If you find the time to try:

http://realtek.info/pdf/rtl8366_8369_datasheet_1-1.pdf

Chapter 8.14

The chip seems to load the config only upon reset, but even that shouldn't be much of a problem, because according to 10.4.1, even a soft reset does the trick.

(Last edited by sborilla on 5 Feb 2011, 02:33)

Maybe this one could be helpful, especially the belkin sources:

https://dev.openwrt.org/ticket/7977

Regards,
Ralph

(Last edited by sagemol on 6 Feb 2011, 11:43)

Hi,
I made a small review of the RTL8366rb controller driver in the openwrt's source branch, particularly : /target/linux/generic/files/drivers/net/phy/rtl8366rb.c and found several options which should be possible to be parsed via swconfig, but not sure if these have to be enabled in the config file first
However, the link options should work, so try this (let's say, you are configuring port 1 - the first LAN port):

$ swconfig dev rtl8366rb port 1 get link

$ swconfig dev rtl8366rb port 1 set link <option>

Hi,

sorry, tried this before. Anything i tried with "set link" didn't work.
But although i'm not a programmer, i can read some code (i hope).
And when i went through the sources, there was the "get link" only, "set link" doesn't seem to be implemented...

Regards,
Ralph

Hmm, unfortunately you are right, I walked through the driver file and only
.get = rtl8366rb_sw_get_port_link,
line present, no set function. I am not a programmer too, simply trying to figure out some functionality of the controller as reviewing the c code.

I am also very interested and impressed by the optional features of RTL8366rb controller as sated in the link given by you above: https://dev.openwrt.org/ticket/7977
However I cannot find the entries regarding the jumbo frames, broadcast/multicast storm prevention, etc in the current state of rtl8366rb.c
Is this patch added to the trunk branch, or these statements should be added/enabled manually before recompiling the image?
Regrds,dir2cas

(Last edited by dir2cas on 8 Feb 2011, 20:03)

went through the trunk sources, looks like at least jumbos are in there:

...
#define RTL8366RB_SGCR_MAX_LENGTH_9216
...

Edit:

....
#define RTL8366RB_SGCR_EN_BC_STORM_CTRL
....

Regards,
Ralph

(Last edited by sagemol on 8 Feb 2011, 20:16)

Yes, I also noticed the define statements at the beginning, but the functions enabling, this to be triggered with swconfig , etc are not present in comparison to the patch, given in the link
https://dev.openwrt.org/attachment/ticket/7977/patch

(Last edited by dir2cas on 8 Feb 2011, 20:50)

Yep, You're right.
Seems, the patch wasn't implemented in trunk.
So You'll have to patch it manually.

Regards,
Ralph

(Last edited by sagemol on 9 Feb 2011, 08:14)

Hum, nothing new here for a month ?

mjonsson, didn't you want to do some work on the driver ?

regards,
ralph

There is some problem getting time to do it... I have done a hack to read and write all registers, but have not yet have time to analyze the results

Sorry to hear that...
Maybe i could help You with testing ?

regards,
Ralph

(Last edited by sagemol on 14 Mar 2011, 15:29)

A little push...

Regards,
Ralph

Hum, as nobody seems to care, i created a patch myself,
although i really do NOT know, what i'm doing here in depth...

I'm not a programmer, so the code might not be compliant to anything it probably should,
but it works and it does what it is expected to do.
If some "real" coder could take a look over it and possibly submit this or something
similar to svn....

 /* See later Posting for better patch....*/

With this patch swconfig will be able to set any port to any speed fixed, e.g.

"swconfig dev rtl8366rb port 2 set forcephy 3"

will set port 2 to 10-MBit-Full-Duplex with autonegotiation disabled.

I still wonder why nobody seemed to care about this feature request since my first post regarding this
in 04/2010 in the WR1043nd-thread, although in some early sources this seemed to be included already:

http://svn.dd-wrt.com/browser/src/linux … ?rev=13863

(rtl8366rb_setEthernetPHY, probably not accesible via swconfig....)

Anyway, i finally got what i needed.
Thanks to all helpers.

regards,
Ralph

(Last edited by sagemol on 29 Jun 2011, 12:13)

That looks pretty nice to me. I guess you should sign a ticket with that patch, so one of the developers will step over it and add it to trunk.

Uh, eh, err....... ehm, sign a ticket ? :-)
I'm new to submitting patches and tickets.... How ?

regards,
Ralph

Me too. But what I would do is visiting https://dev.openwrt.org/newticket and enter your information about what that patch does. After signing, you will get the chance to append any files: that should be the patch you posted here.
Another way (which is actually explained on dev.openwrt.org) is to join the openwrt mailing list and post your patch there. I did that before as well, but I haven't seen any progress so far, but I receive like 10 mails per day of other people discussing and submitting things.

Lol, my first patch and i already had to revise it....
But now it's stable.

Index: target/linux/generic/files/drivers/net/phy/rtl8366rb.c
===================================================================
--- target/linux/generic/files/drivers/net/phy/rtl8366rb.c    (revision 27302)
+++ target/linux/generic/files/drivers/net/phy/rtl8366rb.c    (working copy)
@@ -21,7 +21,7 @@
 #include "rtl8366_smi.h"
 
 #define RTL8366RB_DRIVER_DESC    "Realtek RTL8366RB ethernet switch driver"
-#define RTL8366RB_DRIVER_VER    "0.2.3"
+#define RTL8366RB_DRIVER_VER    "0.2.4"
 
 #define RTL8366RB_PHY_NO_MAX    4
 #define RTL8366RB_PHY_PAGE_MAX    7
@@ -64,11 +64,17 @@
 #define RTL8366RB_PHY_CTRL_READ            1
 #define RTL8366RB_PHY_CTRL_WRITE        0
 
+#define RTL8366RB_PHY_CONTROL_REG               0
 #define RTL8366RB_PHY_REG_MASK            0x1f
 #define RTL8366RB_PHY_PAGE_OFFSET        5
 #define RTL8366RB_PHY_PAGE_MASK            (0xf << 5)
 #define RTL8366RB_PHY_NO_OFFSET            9
 #define RTL8366RB_PHY_NO_MASK            (0x1f << 9)
+#define RTL8366RB_PHY_FORCE_10_BASE_T_HALF    0x0000
+#define RTL8366RB_PHY_FORCE_10_BASE_T_FULL    0x0100
+#define RTL8366RB_PHY_FORCE_100_BASE_T_HALF    0x2000
+#define RTL8366RB_PHY_FORCE_100_BASE_T_FULL    0x2100
+#define RTL8366RB_PHY_FORCE_AUTONEGOTIATION    0x1340
 
 #define RTL8366RB_VLAN_INGRESS_CTRL2_REG    0x037f
 
@@ -738,6 +744,43 @@
     return 0;
 }
 
+static int rtl8366rb_sw_set_port_phy_force(struct switch_dev *dev,
+                    const struct switch_attr *attr,
+                    struct switch_val *val)
+{
+    struct rtl8366_smi *smi = sw_to_rtl8366_smi(dev);
+    u32 phy_force = 0; /* is zero for failsafe */
+    u32 reg;
+    int ret;
+    
+    if (val->port_vlan >= RTL8366RB_NUM_PORTS)
+        return -EINVAL;
+
+/* There's no way to set forced speed/duplex at 1000Base-T, autonegotion MUST always be on. */
+
+    if ((val->value.i > 4 ) || (val->value.i < 0 ))
+        return -EINVAL;
+
+    if (val->value.i == 4 ) {
+        phy_force = RTL8366RB_PHY_FORCE_10_BASE_T_HALF;
+    }
+    if (val->value.i == 3 ) {
+        phy_force = RTL8366RB_PHY_FORCE_10_BASE_T_FULL;
+    }
+    if (val->value.i == 2 ) {
+        phy_force = RTL8366RB_PHY_FORCE_100_BASE_T_HALF;
+    }
+    if (val->value.i == 1 ) {
+        phy_force = RTL8366RB_PHY_FORCE_100_BASE_T_FULL;
+    }
+    if (val->value.i == 0 ) {
+        phy_force = RTL8366RB_PHY_FORCE_AUTONEGOTIATION;
+    }
+
+    return rtl8366rb_write_phy_reg(smi,val->port_vlan,0,RTL8366RB_PHY_CONTROL_REG,phy_force);
+
+}
+
 static int rtl8366rb_sw_set_port_led(struct switch_dev *dev,
                     const struct switch_attr *attr,
                     struct switch_val *val)
@@ -1025,6 +1068,14 @@
         .set = NULL,
         .get = rtl8366rb_sw_get_port_link,
     }, {
+        .type = SWITCH_TYPE_INT,
+        .name = "forcephy",
+        .description = "Set Force Speed/Duplex (0 = Auto, 1 = 100Full,"
+        " 2 = 100Half, 3 = 10Full, 4 = 10Half,)",
+        .max = 4,
+        .set = rtl8366rb_sw_set_port_phy_force,
+        .get = NULL,
+    }, {
         .type = SWITCH_TYPE_NOVAL,
         .name = "reset_mib",
         .description = "Reset single port MIB counters",

I have "hijacked" a ticket already:

https://dev.openwrt.org/ticket/7977

Let's see, what happens.
I made it, i gave it, i can live with that.

regards,
Ralph

I would recommend to make use of that "attach file" button. Don't know how notification with the tickets works, so I don't know how far the developers get to know about your comments.