2355

XGS1250:
I managed to get OpenWRT master working by adding more printfs and identifying the failing SDS, which is sds 9, the SFP port. I commented those out and booting works fine. Perhaps as expected, I can ping hosts on various ports and vlans, but those hosts cannot ping each other through the switch (i did run /etc/init.d/firewall disable && /etc/init.d/firewall stop). Seems like port isolation problem is a problem on both trees.

1 Like
2356

could be that they simply generate a password based on something.

BTW, the xgs1250 does have bootloader source code ... I thought :slight_smile: https://gitlab.com/olliver/openwrt/realtek_sdk/-/tree/xgs1250

While You are more then welcome to keep using the vendored u-boot; why not flash the one I compiled for the xgs1010? I don't think the 2g5 or SFP ports work in u-boot anyway, and it gets rid of all this bs :slight_smile: https://gitlab.com/olliver/openwrt/realtek_sdk/-/packages/8573361

Surprising, as I have 2 SFP ports (8 and 9) which work fine (with their restrictions).

2357

Speaking of SFP+ on the XGS1210, are there any types of modules that are guaranteed to work on it in OpenWRT? I'd like to have STP and LLDP working on my switches (no support in stock firmware), but I have several DACs in my current setup. I also need tagged VLANs to work (they had trouble last time I tried).

So aside from buying new switches that already support STP and LLDP, would switching to a different type of module instead of a DAC work? For example, 10Gbase-T modules should work, but run hot. Optical transcievers, do those work? And how about direct-attach optical?

2358

Note that the 10G ports (there are 3) work in OEM uboot, but not in your fork. Since our ability to use these ports in OpenWRT still partially depends on uboot's configuration (rtk network on), this means that these ports also did not work on the -wip branch either with the sdk uboot (they do with OEM, but OEM doesn't like the partition magic number, necessitating bootm and an empty password). I also want to make sure I'm testing OEM, since we apparently depend on that uboot init currently.

2359

That's fixable though; or, just recompile the 1250-12 u-boot; the instructions are the same, just use the diff branch I recon. One thing I do see, is that I found out that mostly what the SDK does, add 'hardware profiles' to 'configure' the hardware. A poor mans devicetree. I see for the XGS1250-12 add for those aquantic' PHY's (RTK_PHYTYPE_CUST1). Technically, the SDK allows one to have multiple hardware profiles, and the BOARD_TYPE variable is used to select between them. So it could be very much, that a) my u-boot was compiled only with a single (thus forced) hardware profile, and b) the cust1 PHY type needs to be added too.

Looking into my xgs1250 source branch, the sad truth is, they snook in a pre-compiled object; violation of the GPL of course but there it is, *phy_cust1.o" which contains all the phy initalization and customization code :frowning:

So back to the password search (or compiling xsg1250 from scratch :slight_smile: i wonder if that u-boot is passwordless, if it is, then it's a local modification they haven't put in the source, which I don't think is GPL wise allowed ...

Anyway, just sharing thoughts :slight_smile:

2360

No guarantee's ever, from anyone, what works today can break tomorrow :slight_smile:

Currently, a few (short) DAC's (Direct Atached Cable) work. Optical SFP's are likely to work, as they don't need to be tuned for length, but who knows. Copper SFP units should be in the same spot as optical, but consume a lot of power/get hot.

As for those features, if it doesn't work; patches welcome :slight_smile: but in hardware, it seems most things are in place for it. I think LLDP however is a software thing, no hardware needed.

Of all things, I think DAC is the hardest, as you basically extend the SERDES lines directly over copper to the other end, so your PCB traces in essence become meters instead of centimeters.

2361

USW-Aggregation reset GPIO is 3.
I'm currently starting with dev/realtek-wip fresh. I'll send a patch later, note that the compatibles are currently wrong for this board (missing 3 in a few places...bad sed?). i2c is also unhappy, it doesn't like the resource address for i2c0. I also managed to get readout on the STM32F2xxx that runs the LCD panel. I think I have a better understanding of the protocol there. GPIO5 will put it into flashing mode (/proc/gpio/lcm on OEM fw). Then you can stm32flash -b 115200-k /dev/ttyS1; stm32flash -b 115200 -r blah.rom /dev/ttyS1 to obtain a copy. I don't plan on changing this anytime soon, but it's nice to dump out the strings it can understand in JSON...I believe it should be possible to pretend to be the OEM FW from usermode, but it may require some fixed GPIO setup to ensure it leaves flashing mode.

Other findings. There is definitely a PCA9555A chip on the board, but I can't see it on the i2c bus in the OEM firmware. I will try various TP-link like configs, I'm wondering if that might be exactly the same or not. I still can't identify the chips near the SFP+ ports, they are 8-pin and extremely tiny.
EDIT: I think they are rtl8231s being used as GPIO expanders, OEM fw says RTL8231 probe (unit 0): (found)

For LED configs, I think this board is weird. There are white LEDs that work already, associated with each SFP port. The system led is claimed by diag led sys state to exist and work, but toggling it doesn't produce changes I can see. It may be a state input for the LCD? The port led config dumped by diag says none of the led groups are configured.

I found Birger's sfp_10g branch, somehow it's there in gitlab but not directly. I think this commit is pretty key: https://gitlab.com/olliver/openwrt/openwrt/-/commit/4c7816b0d18ab4d5068ee753647f8cec72f0623b

OOO bonus! The rest of the PCA9555 config and GPIOs for SFPs.

Here's my latest state integrated to -wip. i2c is still weirdly broken and can't find resources on its of node...I didn't have this problem on openwrt master, so I assume it's something off about the way the DTS files are on wip. I added some printfs there. I may try some of birgers patches on OpenWRT master next, since I had the phy detected and negotiating there, I think i2c and phylink need to work for that. DTS is missing some semicolons, does receive 150 bytes (then nothing) but ethtool results aren't as good as I've seen.

2362

Thanks, pushed. It's gpio3 on my rtl9301 as well, 22 on my rtl9302b :slight_smile:
Yeah, not so much sed, just phat fingers :s or typing to fast for my own good :smiley:

Being able to flash from linux would still be useful, in case the vendor updates the firmware :slight_smile:

Where did you find it, I don't see it on your pics, probably related to the GPIO's of those SFP ports. But to be able to probe it, you'd need to know and enable the correct i2c ports. Maybe it sits on the second i2c controller by itself?

RTL8231 is not an 8 pin chip though; and I'm not sure they make them in different sizes. But it makes sense that they use one or two rtl8231's as that is 'baked into' their soc in a way. likely to drive the leds is my guess, but we can easily test that by setting up proper led-sets.

Hmm, I think without the led-set compatible, we are not configuring the leds at all, thus they are using the default register values, which would make it 'just work'. A bug imo :slight_smile: as we should reset the led-sets in that case.

Does any of this work in u-boot with rtk-network on? You can dump the led values in that case from U-boot (otherwise from vendor linux) to figure out what they are. rtk network on; md 0xbb00cc00 should give you all led registers, paste them here and we can confirm if these are default settings or not.

does it rapidly blink during power on? does it go 'off' when linux is booting? It shouldn't be visible in linux without status_led { status = "okay"; } in the dts ... with that added, i like the heartbeat trigger to see if its working properly.

ohh nice one, i'll add those asap!!

Which i2c ports? anything on i2c0? or are you using i2c1 too. I think i2c1 can't work right now.

Thanks for the research!!

Yeah :slight_smile: I think I fixed those also; I forgot to enable some dts compiles last few times, I turned them on to make sure all of them get built.

2363

i2c0 only, i2c1 is not used. res is coming back NULL from platform_get_resources on this branch, wasn't checked (supposedly ok, ioremap checks this?) and then ioremap will return a -22 because there are no resources.

The GPIO expander is shadowed by the case lip and the heatsink. There are two of them apparently, it seems Birger already got quite far on this board, but some of the changes vary and some are experimental looking. I am going to try to figure out the minimum set of them to make the board work on master. They are possibly in the wrong i2c bus, i2cdump 5 shows them on 0x21 and 0x24 and can be read, but on master my DTS was trying to probe them on 6. Not sure if I had that mistake in the wip patch.

1 Like
2364 
uboot> # md 0xbb00cc00
bb00cc00: 01053659 aaa9aaa9 0055a9a9 00000000    ..6Y.....U......
bb00cc10: 00000000 00000000 00000000 00000000    ................
bb00cc20: 00000000 0000ffff 0a010ba0 00000000    ................
bb00cc30: 00000000 00000000 00000000 0f110101    ................
bb00cc40: 0f110101 0f110101 00000000 00000000    ................
bb00cc50: 00000000 00000000 00000000 00000000    ................
bb00cc60: 00000000 00000000 00000000 00000000    ................
bb00cc70: 00000000 00000000 00000000 00000000    ................
bb00cc80: 00000000 00000000 00000000 00000000    ................
bb00cc90: 00000000 00000000 00000000 00000000    ................
bb00cca0: 00000000 00000000 00000000 00000000    ................
bb00ccb0: 00000000 00000000 00000000 00000000    ................
bb00ccc0: 00000000 00000000 00000000 00000000    ................
bb00ccd0: 000fa000 00271000 004e2000 0007d000    .....'...N .....
bb00cce0: 00138800 00271000 0003e800 0009c400    .....'..........
bb00ccf0: 00138800 00019000 0003e800 0007d000    ................
2365

Thanks!, that helps for sure.

Pushed the latest modifications. Still don't think you need anything MDI related, because, what wires are they connecting with? I2C is used to connect to the SFP modules as per spec. UNLESS!! They are using the MDI pins for that. As long as you can read the eeprom via MDI, it's possilbe, MDI and I2C are quite closely related. Its just not something I've seen realtek do. So who knows? I'd be more inclined to think we may need to make sure https://gitlab.com/olliver/openwrt/openwrt/-/commit/4b2014993fbb06af1b4cde885ba1a4a9421ed479 mdio-i2c is enabled ...

How did you find it? Git tells me:

git branch -a --contains 827e37ee93e4dfacbd27d1c1ea929dd5ba0ab503
  remotes/origin/kobi/sfp_10g

so it should be there? anyway, that's probably a missing patch in my big pile of patches :slight_smile: so i'll go over that branch :slight_smile:
Sadly, I can't really find any code changes that are missing, maybe something very tiny would be possible of course, but everything more or less seems to be there.

What was missing was that dts file ...

btw, those gpio expanders are interesting, we're missing few GPIO's ... looking at the xs1250 SFP config, we are 'missing' the tx-disable-gpios ...

2366

All I had there was the commented note, but I think it was wrong (oem fw shows no GPIO changes on insertion and removal at least, maybe there's a better way to trigger it). It's good to find this for power savings, but we shouldn't need it to get things working. It does appear the GPIOs used from the expanders are not sequential, so it's likely the tx_disable is one of the unused pins.

2367

On OpenWRT master, I have phylink and the SFP talking just fine. I think it will work on -wip if whatever is broken in i2c land is fixed, and it's probably just a DTS inheritance problem.

root@OpenWrt:/# dmesg | grep -i sfp
[   52.341329] sfp sfp-lan1: Host maximum power 1.0W
[   52.347912] sfp sfp-lan1: No tx_disable pin: SFP modules will always be emitting.
[   52.358256] sfp sfp-lan2: Host maximum power 1.0W
[   52.364834] sfp sfp-lan2: No tx_disable pin: SFP modules will always be emitting.
[   52.375182] sfp sfp-lan3: Host maximum power 1.0W
[   52.381686] sfp sfp-lan3: No tx_disable pin: SFP modules will always be emitting.
[   52.392058] sfp sfp-lan4: Host maximum power 1.0W
[   52.398646] sfp sfp-lan4: No tx_disable pin: SFP modules will always be emitting.
[   52.408975] sfp sfp-lan5: Host maximum power 1.0W
[   52.415552] sfp sfp-lan5: No tx_disable pin: SFP modules will always be emitting.
[   52.425941] sfp sfp-lan6: Host maximum power 1.0W
[   52.432449] sfp sfp-lan6: No tx_disable pin: SFP modules will always be emitting.
[   52.442790] sfp sfp-lan7: Host maximum power 1.0W
[   52.449291] sfp sfp-lan7: No tx_disable pin: SFP modules will always be emitting.
[   52.459643] sfp sfp-lan8: Host maximum power 1.0W
[   52.466231] sfp sfp-lan8: No tx_disable pin: SFP modules will always be emitting.
[   52.694360] sfp sfp-lan1: module OEM              SFP-10G-SR       rev 02   sn CSF101L80337     dc 210805
[   57.721573] sfp sfp-lan1: module OEM              SFP-10G-SR       rev 02   sn CSF101L80337     dc 210805
[   58.546732] Workqueue: events_power_efficient sfp_timeout
[   58.624819] [<80488d1c>] phylink_sfp_module_start+0x40/0x50
[   94.070547] sfp sfp-lan1: module OEM              SFP-10G-SR       rev 02   sn CSF101L80337     dc 210805
[   95.077521] Workqueue: events_power_efficient sfp_timeout
[   95.155660] [<80488d1c>] phylink_sfp_module_start+0x40/0x50
root@OpenWrt:/# ethtool lan1
Settings for lan1:
        Supported ports: [ FIBRE ]
        Supported link modes:   10000baseSR/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 20
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

Link detection might be a missing piece there, but I suspect that is more of the small changes in sfp_10g to e.g. set the media correctly, not sure. I do have some upstream kmods about mdio and i2c enabled, and the pca9555 kmod is required also. Though I remember Birger talking about SMBus and MDIO and i2c a lot with respect to SFPs on this board, so maybe that is the missing part.

2368

Back to my D-link DGS-1210-16 issue:
I booted it up, flashed today's snapshot and tried to reboot again.
It still ends up being stuck and only disconnecting power allows it to boot again.
Then I tried to change the minimum frequency to see if there is any difference, but for some reason it told, me, that it has no permission to /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
I fear, that sth. in my switch might be bricked.
This is the serial console output during these attempts: https://haste.tchncs.de/uwezutohah.yaml
Maybe someone has an idea what can be done to bring back normal functionality with working reboot.

2369

Can you break into uboot console? I generally try not to flash and boot tftp instead to avoid having to use a flash programmer to unbrick, but that may be necessary.

2370

yes, I can access u-boot:

U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Jul 23 2020 - 13:01:19)

Board: RTL838x CPU:500MHz LXB:200MHz MEM:300MHz
DRAM:  128 MB
SPI-F: 1x32 MB
Loading 1024B env. variables from offset 0x80000
Board Model = DGS-1210-16-G1 Cameo_bdinfo_get_BoardID [293] 
Switch Model: RTL8382M_8218B_INTPHY_8214FC_DEMO (Port Count: 20)
Switch Chip: RTL8382
**************************************************
#### RTL8218B config - MAC ID = 0 ####
Now External 8218B
**************************************************
#### RTL8218B config - MAC ID = 8 ####
Now Internal PHY
**************************************************
**** RTL8214FC config - MAC ID = 24 ****
Now External 8214FC
Net:   Net Initialization Skipped
rtl8380#0
Hit Esc key to stop autoboot:  0 
u-boot># 
DDP Timeout.

Abort
Ctrl-c was pressed..(Changing to u-boot console mode(0)) 
<INTERRUPT>
u-boot>#
2371

So that means you're not bricked, at least. The log you posted looked like reboot worked, is that because you had to pull the plug?

2372

Well, I meant bricked in the sense of that I can#t reboot the device, but it otherwise works normally.
Yes, when you see reboot: Restarting system in the log, the device just hangs and the power led flashes constantly until I cut power.

2373

The 1210-series shares the same GPIO setup in the current source tree. A restart is initiated via GPIO34 on Controller 1 (there is a gpio-restart node).

I just had a look at the git history: Looks like this gpio-restart node wasn't there before refactoring the D-Link support. IMHO it is very well possible that a different GPIO pin is required for your device.

I don't know if there is a better way to identify the GPIO, but when I ported a switch, I exported all GPIOs via sysfs and then toggled each one until I found the one that reliably restarted the switch.

Maybe you can try if a different GPIO works for you?

1 Like
2374

it's an 'output' e.g. the switch would drive it. It tells the SFP to 'disable power' :slight_smile: easy to test if you have a working SFP in, and as the link is working, toggle the GPIO to disable transmission. might even be able to spot it optically without cables in?

I have donated the cheapest SFP i could find on ebay, a whole $2.50 inc shipping :slight_smile: and disconnected everything and soldered wires to it, so now I can measure some of the signals.

But, you are right, it's not important for the functionality we try to accomplish. Though my gut feelings tells me it must be this :slight_smile: (my gut has been known to be wrong at times :p)

Oh sfp_module_start is crashing? you can always go back to the 'original' i2c dts stuff to see if that makes a difference. I'll free up some time to fix the new dts stuff. I thought it would 'just work (tm)' (as long as you don't enable the second i2c controller :p)

Yeah, we'll also need to make sure we'll enable all needed kernel modules in our kernel config.

The SFP ports work for me on master, but I haven't checked on any switches the latest status, was trying out some other stuff :stuck_out_tongue:

I think that's the wrong node to modify, I think that'll just tell you, the user, what the minimum freq. is you can set.

First, you need to ensure that the 'userspace' governor is available to you, and then set that. (or check the current governor). I'll check tomorrow if you haven't found out by then :slight_smile: