realtek-poe is now in the packages feed, and since 3 days also with the ubus support for managing power on each port.
2 Likes
Thanks, I didn't notice that! But only in the snapshot feed, not for 22.03., right?
Not sure about 22.03. Are you running 22.03 on yours?
Nice, do you have compiled /bin/poe.lua file? or how can i compile?
You can try mine, I have included them in my personal 22.03 builds. You might need a few extra dependencies but I believe those are available in 22.03 by default.
1 Like
Thanks! Is there any online detailed guidance on the better alternative? It seems a bit hard for me to make it work.
Probably but it would be better to run this question in a separate tread since it is a “how to use the hardware question”.
But I don’t think it exist any direct manual yet specific for OpenWrt switches (this is pretty much the first ones in big volumes we have). The closest instruction is probably the one for dumb access points. If I remember right that one tells how to set up a management interface. And just ignore everything with wifi.
The other interfaces you simply remove in the switch and only set what ports you want to connect to what specific vlan as you already have done. And the port for the cable from the router you set all vlan as tagged, set the same on the port on the router.
Then it should pretty much run like a flying bat by itself.
But to run a switches like this on L2 level is standard operating procedure in enterprise networks so it’s nothing spooky in that way. It is mostly that OpenWrt has been so focused to make firmware for home use routers that managed switches doesn’t really fit into those instructions yet.
1 Like
Go check out the PoE thread:
2 Likes
booting now, but no improvements for the Zyxel 1250-12
The 1250-12 still gets stuck during boot? Interesting.
I narrowed the reset down a bit. I am not big into C, but comments help.
The line sw_w32_mask(0, 1, RTL838X_EXTRA_GPIO_CTRL) triggers the reset.
target-mips_4kec_musl/linux-realtek_rtl838x/linux-5.10.144/drivers/gpio/gpio-rtl8231.c
int rtl8231_init(struct rtl8231_gpios *gpios)
{
u32 ret;
pr_info("%s called MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
gpios->reg_cached = 0;
if (soc_info.family == RTL8390_FAMILY_ID) {
// RTL8390: Enable external gpio in global led control register
sw_w32_mask(0x7 << 18, 0x4 << 18, RTL839X_LED_GLB_CTRL);
} else if (soc_info.family == RTL8380_FAMILY_ID) {
// RTL8380: Enable RTL8231 indirect access mode
pr_info("Here is where everything goes nuts...");
// sw_w32_mask(0, 1, RTL838X_EXTRA_GPIO_CTRL);
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
ret = rtl8231_read(gpios, RTL8231_LED_FUNC1);
if ((ret & 0x80000000) || ((ret & RTL8231_READY_MASK) != RTL8231_READY_VALUE))
return -ENXIO;
}
Outcome in compiled image:
[ 0.850000] Probing RTL8231 GPIOs
[ 0.850000] rtl8231_init called MDIO bus ID: 0
[ 0.860000] Here is where everything goes nuts...
[ 0.860000] rtl8231-gpio rtl8231-gpio: no device found at bus address 0
[ 0.980000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 0.990000] printk: console [ttyS0] disabled
If you interrupt the bootloader, what does md.l 0xbb00a0e0 1 tell you?
In case the lowest bit of that register is unset, the MDIO lines will be muxed to their GPIO function and you could check the effect toggling them has. You will probably need to export GPIOs 490 and 491 (lines 2 and 3 on the internal controller). For example:
cd /sys/class/leds
echo 490 > export
echo 491 > export
cat gpio490/direction && cat gpio490/value
echo low > gpio490/direction
cat gpio491/direction && cat gpio491/value
echo low > gpio491/direction
Thanks, I hardly have an idea what I am doing here, but step by step 
.
I guess it is unset, 0h in the lowest halfbyte
RTL838x# md.l 0xbb00a0e0 1
bb00a0e0: 00000180 ....
Can I do the rest when I boot from the initramfs-kernel-image in ram, though the rtl8231-gpio has not been initialized ? Hmm, no
root@OpenWrt:/sys/class/leds# ls -l /sys/class/leds/
lrwxrwxrwx 1 root root 0 Jan 1 1970 green:sys -> ../../devices/platform/leds/leds/green:sys
Can I somehow toggle them from the C-code ?
The GPIO related commands I listed can be run from an initramfs. The GPIO lines I referenced are on the SoC's internal GPIO controller, not the RTL8231. If the RTL8231 driver is active, you should have two gpiochips:
/sys/class/gpio/gpiochip488 # internal GPIO controller
/sys/class/gpio/gpiochip451 # RTL8231
Could you also check the output of md.l 0xbb000144?
I am still able to boot the 1250 image, ther's some serdes spamage, probably related to the aquantic PHY's missing, idk; but it does boot however.
I've since done some things, not related and pushed an update. Doubt this will change things.
I have since at least pin-pointed which commit introduced the watchdog timeouts on network init, which are sadly not related to the networking code, but the timer patch instead. So probably my hacking there is probably not right or, as I said before, the timer patch simply triggers the problem, without being the actual problem. So i'll see if I can pinpoint some things ...
So, I was afraid that me doing uci set network.lan.proto=dhcp after boot, before network setup (e.g. during dropbear key generation) was causing the issue more often due to me wanting dhcp. I've now changed my build to default to dhcp (to type less) and the issue doesn't pop up quite as often/at all.
I have managed to found something that triggers it somewhat more reliably; interaction during boot, just before or as the network tries to come up. So either this is related to multitasking or something else stalling (when trying to interact, e.g. cat the terminal also just stalls/hangs for a bit; could be that this is a good indicator that we are probably hanging the kernel somewhere with some nasty loop ...
I've also added (sleep 2m; reboot) in my /etc/init.d/done script, to trigger reboot loops, as well as watchdog timeouts, and that sleep might actually also cause the issue ... sometimes but not sure if done is run before or after network bringup ...
@plappermaul pointed me into the right direction for a quick test of the timer; echo 650000 > "/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed" which causes R4K timer is unstable due to CPU frequency change indicating I'm not using the new timer. So something bad on my end. The good news is, could mean no problems on those network patches.
Memory dump from the u-boot loader:
RTL838x# md.l 0xbb000144
Result:
bb000144: 00000000 00000000 1fffffff 1fffffff ................
bb000154: 00000000 00000000 00000000 00000000 ................
bb000164: 0fffffff 00003000 000003e8 00000003 ......0.........
bb000174: 00000001 00000000 00000000 00000001 ................
bb000184: 00000000 00000000 00000000 00000000 ................
bb000194: 00000000 00000008 00000000 00000000 ................
bb0001a4: 00000000 00000000 00000000 00000000 ................
bb0001b4: 07070707 87878787 00000000 00000001 ................
bb0001c4: 00000007 00000000 00000000 00000000 ................
bb0001d4: 00000000 00000000 00000000 00000000 ................
bb0001e4: 00000000 00000000 00000000 00000000 ................
bb0001f4: 00000000 00000000 00000000 00000000 ................
bb000204: 00000000 00000000 00000000 00000000 ................
bb000214: 00000000 00000000 00000000 00000000 ................
bb000224: 00000000 00000000 00000000 00000000 ................
bb000234: 00000000 00000000 00000000 00000000 ................
The /sys/class/gpio/gpiochip488 # internal GPIO controller is present, the /sys/class/gpio/gpiochip451 # RTL8231 of course not .
I still don't understand how I can poke the RTL8231 gpio lines one by one when there is only the gpio controller present.
Hi, I rebased my 5.15 work on current master, and Panasonic Switch-M48eG PN28480K (RTL8393M) stucks while booting.
RTL839x# # bootm
## Booting kernel from Legacy Image at 81000000 ...
Image Name: MIPS OpenWrt Linux-5.15.69
Created: 2022-09-25 15:57:22 UTC
Image Type: MIPS Linux Kernel Image (gzip compressed)
Data Size: 7677800 Bytes = 7.3 MB
Load Address: 80000000
Entry Point: 80000400
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
[ 0.000000] Linux version 5.15.69 (musashino205@TAIHA.NET) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r20530+5-5b94cddfa5) 11.3.0, GNU ld (GNU Binutils) 2.37) #0 SMP Sun Sep 25 15:57:22 2022
[ 0.000000] RTL838X model is ffffffff
[ 0.000000] RTL839X model is 83936802
[ 0.000000] SoC Type: RTL8393
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc)
[ 0.000000] MIPS: machine is Panasonic Switch-M48eG PN28480K
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Using appended Device Tree.
(stuck)
Perhaps this issue is identical to the one reported by @lucize, and I think this is introduced by the following commit.
my solution:
RTL839x# # bootm
## Booting kernel from Legacy Image at 81000000 ...
Image Name: MIPS OpenWrt Linux-5.15.69
Created: 2022-09-25 15:31:45 UTC
Image Type: MIPS Linux Kernel Image (gzip compressed)
Data Size: 7677672 Bytes = 7.3 MB
Load Address: 80000000
Entry Point: 80000400
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
[ 0.000000] Linux version 5.15.69 (musashino205@TAIHA.NET) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r20530+5-5b94cddfa5) 11.3.0, GNU ld (GNU Binutils) 2.37) #0 SMP Sun Sep 25 15:31:45 2022
[ 0.000000] RTL838X model is ffffffff
[ 0.000000] RTL839X model is 83936802
[ 0.000000] SoC Type: RTL8393
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019555 (MIPS 34Kc)
[ 0.000000] MIPS: machine is Panasonic Switch-M48eG PN28480K
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Using appended Device Tree.
[ 0.000000] Detected 1 available secondary CPU(s)
[ 0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes.
[ 0.000000] Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
... (truncated)
Before booting, can you perform the following write from the bootloader:
mw.l 0xbb000144 1
That selects MDIO access mode for the RTL8231, instead of I2C that is apparently selected on your device.
The GPIO lines I was referring to aren't on the RTL8231, and that was sort of the point. The pins on the SoC that are used to talk to the RTL8231 can be used as GPIOs, or as an MDIO master. For things to work as expected, they need to be configured as MDIO, but if the are left as GPIO pins, you could manually toggle the line states, thus possibly triggering the reboot. Seeing that your device is trying to use the I2C port/mode, I think it's more likely for the issue to be situated there.
I am seeing the same issue on a HPE 1920-48G (also RTL8393) with kernel 5.10, and your fix also works here.
1 Like