If it helps, I described the openwrt boot and install procedure for another RTL9301 device on svanheule.net wiki which is quite similar if not even same for the zyxel.
1 Like
Confirmed, the device is booting again.
Is the 838x target supposed to allow overclocking?
In dmesg this is logged:
[ 0.000000] rtl83xx-clk: initialized, CPU 500 MHz, MEM 300 MHz (8 Bit DDR3), LXB 200 MHz
[ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041786 ns
[ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns
[ 0.000000] Calibrating delay loop... 498.89 BogoMIPS (lpj=2494464)
...
[ 0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
...
[ 0.270000] rtl83xx-clk clock-controller: rate setting enabled, CPU 300-625 MHz, MEM 300-300 MHz, LXB 200-200 MHz, OVERCLOCK AT OWN RISK
However, overclocking is not possible.
root@OpenWrt:/# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies
325000 350000 375000 400000 425000 450000 475000 500000
root@OpenWrt:/# echo '625000' > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_setspeed
ash: write error: Invalid argument
Also, when changing clock speeds this message appears in the console. I think it was mentioned somewhere else already.
root@OpenWrt:/# echo 'ondemand' > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_governor
root@OpenWrt:/# [ 393.200000] R4K timer is unstable due to CPU frequency change
Furthermore, wall times are not calculated correctly with changed clocks (known limitation as per PR). Actual processing speed changes in accordance to the reduction in clock speed though. I've tested this via timed ssh.
Nice to get feedback about this. Current situation is as follows:
- The driver alone allows overclocking
- To make it save rtl838x.dtsi limits the allowed operating points (OPP).
- The current timers are bound to CPU speed. Changing it confuses the system.
- I just posted the enhancements for RTL930X (see https://github.com/openwrt/openwrt/pull/10574)
- Next step will be to switch the timers to stable sources
Feel free to test and report.
1 Like
I'll not be able to test for a week or so.
@olliver I've ordered a used xgs1010-12 to tinker with next. I'm planning to flash your u-boot build. Do I need a additional hardware or can I flash the boot loader from a booted openwrt build?
If your build's DTS was writeable you can replace u-boot from within OpenWrt. That will require you to set the u-boot flash range to writeable before compiling your own image.
You can, but the stock openwrt builds have the U-Boot partition marked as read-only as noted by @Borromini.
What is far easier, is interrupt the U-Boot shell, and flash U-Boot from U-Boot directly, that is the (only) way I have done it so far. See U-Boot for XGS12xx switches (and others based on realtek rtl930x) to find upgrade loader which will download u-boot.bin from the TFTP server 
Other then a tftp 'server' and a 'RS-232 USB cable', no you don't need anything special.
3 Likes
A dts overlay could be used in the futuree on a 'per user' basis probably
Obviously, those are available.
Would it be possible to not just tftp boot but flash a stock xgs1210-12 FW once the u-boot has been updated?
This package can be handy when you really feel like bricking something 
2 Likes
So I've coded a basic daemon to manage PoE on switches with TI-based PSE controllers. For now, I've copied most of the infrastructure from realtek-poe and it shares the same configuration file and structure. The ubus interface is not yet in place.
I defined a per-model mapping file that contains the association between i2c addresses, channels and switch ports. It should be relatively easy to add support for another model - for now, it requires recompilation.
Porting this to the XS2184 should also be relatively easy.
Code: https://github.com/andyboeh/openwrt-packages/tree/master/utils/realtek-poe-ti
Moving forward, I could imagine that realtek-poe contains several backends: MCU, TPS23861, XS2184. What do you think?
2 Likes
This is most definitely hardware description and should be independent of both code and config It would be nice to put it into the device-tree. But I guess that needs some discussion first, to follow traditions
Looks like this series eventually will go in: https://patchwork.kernel.org/project/netdevbpf/list/?series=672820&state=*
Should be easy to adapt to other PSE controllers.
I think that would be nice. And you could add an ethtool backend to the daemon once the mainline infrastructure is there.
3 Likes
(The link is broken because Discourse drops the asterisk at the end.)
1 Like
Link fixed.
2 Likes
I just tried to enable LED support on an RTL8393M device using a patch found here: https://github.com/openwrt/openwrt/commit/997c46702b0ee4ba2f6fac524fa3878cb1fc5753
Basically, it's working, but all LEDs are shifted by 4, i.e. port LED 5 lights up for LAN1. Is this LED support going to happen anytime soon?
Here's some initial feedback for PR# 10453 (tested on my pristine xgs1010-12).
Building images for xgs1010-12 doesn't work for me. There is no option in menuconfig.
I went with the 1250 image instead, so, results might be skewed a bit.
In general, I've noticed the same issues I had with the master images so far. Routing between two vlans just doesn't work.
My setup is fairly simple it has two clients in two vlans (100 and 200). Both clients can reach the routers webif on 192.168.1.1, also, both can ping 192.168.200.1. For some reason none of them can ping 192.168.100.1. Is there some sort of port isolation going on?
config
config bridge-vlan 'lan_vlan'
option device 'switch'
option vlan '10'
list ports 'lan1'
list ports 'lan4'
list ports 'lan5'
list ports 'lan6'
list ports 'lan7'
list ports 'lan8'
list ports 'lan9'
list ports 'lan12'
config interface 'lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option device 'switch.10'
config bridge-vlan
option device 'switch'
option vlan '100'
list ports 'lan2'
config bridge-vlan
option device 'switch'
option vlan '200'
list ports 'lan3'
config interface 'vlan100'
option proto 'static'
option device 'switch.100'
option ipaddr '192.168.100.1'
option netmask '255.255.255.0'
config interface 'vlan200'
option proto 'static'
option device 'switch.200'
list ipaddr '192.168.200.1/24'
I've tried two SFP modules so far with mixed results.
First test HP 1Gb RJ-45 module, got detected, but no link.
[ 820.731664] sfp sfp-p12: module AVAGO ABCU-5712RZ-HP1 rev sn 2Y1526MYAG dc 150625
[ 820.823169] rtl83xx-switch switch@1b000000 lan12: validation with support 0000000,00000000,00000000 failed: -22
[ 820.834614] sfp sfp-p12: sfp_add_phy failed: -22
Second test, HP Fibre Channel DAC, got detected fine. Didn't test any further though.
[ 876.921677] sfp sfp-p12: module Amphenol 575820003 rev D sn APF10370033525 dc 100923
[ 877.219437] rtl83xx-switch switch@1b000000 lan12: Link is Up - 10Gbps/Full - flow control off
[ 877.229065] rtl83xx-switch switch@1b000000 lan12: Link is Down
[ 877.284876] sfp sfp-p12: module removed
1 Like
These patches are only about CPU frequency scaling. I did not care about network devices yet.
Sorry, confused the two PR I'm testing at the moment.
Your's will be next.
The port LED register values really need to be set up to match the number of used LEDs, which may be different from the number of used ports (e.g. for device status LEDs). I've been working on more proper LED support instead of raw register values in DTS, but that's a rather large patch set.
In the mean time, you should be able to use a script similar to this one: https://github.com/openwrt/openwrt/pull/10486/commits/6fbf86ba894929a44af103a8e3482ae6fa3cb523
If the bootloader can correctly initialise the port LEDs, the correct register values should be maintained and accessible via debugfs after booting (an initramfs).
On my switch, all status LEDs are directly controlled via GPIOs, the shift registers really only control the port LEDs (and maybe the fan?).
I'm aware of this script, but it didn't work on a quick try: the debugfs only exports 24 LEDs, not 52 - I haven't had the time to submit a patch for this. And U-Boot does not initialize the LEDs at all, so I don't have a clue on the right register values. I'll keep toying around with this
Since I have a similar GS110TPP, I also checked the PLL registers after power-on via u-boot. It appears that some (why only some, Realtek!?) are read-write protected via the INT_RW_CTRL register:
RTL838x# mw.l 0xbb000058 0
RTL838x# md.l 0xbb000fc0 10
bb000fc0: 00003f07 00004748 0c14530e 2da0cfb8 ..?...GH..S.-...
bb000fd0: 00000000 00000000 2da0cfb8 0000414c ........-.....AL
bb000fe0: 04018c80 2d20cfb8 00000000 00000000 ....- ..........
bb000ff0: 2da0cfb8 aaaaaaa9 efffffff 00000000 -...............
RTL838x# mw.l 0xbb000058 3
RTL838x# md.l 0xbb000fc0 10
bb000fc0: 00003f07 00004748 0c14530e 2da0cfb8 ..?...GH..S.-...
bb000fd0: 000047c8 001ad30e 2da0cfb8 0000414c ..G.....-.....AL
bb000fe0: 04018c80 2d20cfb8 00007608 0134f30e ....- ....v..4..
bb000ff0: 2da0cfb8 aaaaaaa9 efffffff 00000000 -...............
Specifically, these are the protected registers:
-
0fd0:PLL_LX_CTRL0 -
0fd4:PLL_LX_CTRL1 -
0fe8:PLL_SW_CTRL0 -
0fec:PLL_SW_CTRL1