Add the lan SFP and overlays for the wan SFP and 2g5 port for the bpi r4 pro 4e.

[wteiken]

This adds the 4E specific ports:

• SFP1 directly connected to the MXL862
• The additional 1g phy from the internal switch
• One overlay for SFP2 as WAN
• One overlay for the 2g5 port as WAN

[frank-w]

Hi,why closing the PR? As i have no R4Pro 4E this would be a good patch. Afaik we do not need overlays for 4E variant except the existing ones,but the sfp can be added directly to 4e dts

looked in schematics and there is still a eth mux on 4E variant but between the internal 2g5 phy and wan-sfp, so we have to handle this mux similar to 8x...if we do via overlays we have to set the mux-gpio too

but lan-sfp is fixed and can be added to 4e dts.

[frank-w]

@wteiken i have added your patch to branch 7.1-rc, please can you test, if lan/wan works there correctly on 4E board?

[wteiken]

Sorry, accidentally moved the branch.

While GPIO3 is not marked as optional in the schematics the mux is only listed in the block diagram for 8X, not the 4E. And on the board I see an empty spot, so I assume that is where the mux would be (similar to the mux of the LAN SFP/PHY for the 8E that is also empty).
So I think it's an inaccuracy in the schematics that that part is not listed as optional.

[wteiken]

For 7.1 for sure the names need to be changed, it seems the base pro setup now names lan1-lan4, not lan0-lan3, so the 4e-dts needs to use lan5/lan6 not lan4/lan5.

[wteiken]

I hope to test this this afternoon, will send a PR with changes needed.

[wteiken]

The 7.1-rc branch is having some issues booting, so not yet sure there. The overlays work for the wan ports in 7.0 (though the sfp lan does not work, but given it's also commented out in our 8x version I assume that is somewhat expected).

[frank-w]

Which issues have you with booting 7.1 on R4?

In latest branches i changed mxl ports to lan1-lan4 and lan5 is the old mgmt...i guess your lan4 label is the problem here - have changed it in 7.1-rc

i've booted my 7.1-rc on my R4 4G 2SFP and R4Pro 8x without issues (except the flooding of messages due to the phy driver on mxl mdio)

Have you tested both overlays and the dts change? I have modified it a bit in 7.1-rc so it uses lan6 as label

[wteiken]

Yeah, I am aware of the renumbering issues, I had also moved the lan sfp to lan7 (lan5 being old mgmt, lan6 the additional 1gbe from the internal switch).

Serial output stops working after about a second. It never becomes pingable, which may mean something on the networking side is not working, or it could be fully crashed. Without the serial output I am not sure.

It's on my list today to see if I can figure out what the issue is there.

I think the mxl drivers are identical between your 7.0 and 7.1-rc branches so I'd expect things to work the same between the two versions.

I tested both overlays with the "non-downstream" mxl driver on 7.0 and that works for lan1-lan6. lan7 being borked on the drivers (it never shows a link established).

On the "downstream" drivers everything works except for a few minor oddities (the downstream driver expects a different dsa tag label, and the link status is "off by one port", I assume as a consequence for the patch you added to align port numbering between the two drivers.

[wteiken]

Seems for me 7.1-rc is crashing right around the serial console initialization. Last lines are:
[ 0.857040] mtk-xsphy soc:xs-phy@11e10000: failed to get ref_clk(id-1)
[ 0.864836] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.878970] Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
[ 0.887117] printk: legacy console [ttyS0] disabled
[ 0.912548] 11000100.serial: ttyS0 at MMIO 0x11000100 (irq = 99, base_baud = 2500000) is a ST16650V2
[ 0.921878] printk: legacy console [ttyS0] enabled
[ 0.931521] printk: legacy bootconsole [uart8250] disabled

[frank-w]

Strange i do not see this and this patch is also there:

6658d42

Basicly i used the 7.0-main tree to build 7.1-rc through rebase...but maybe something in mainline has changed,but cannot reproduce it. You use the usb-c console,right?

And yes,downstrem driver needs changes for tagging-protocol,but i will drop it soon as mainline driver works so far.

If this works on 4e board and you fixed the lan5 i can merge here...there is another 1g poet from internal switch there?

[wteiken]

Yes, usb console.Booting from nand+Nvme, will try tomorrow if booting from SD makes a difference.On May 25, 2026, at 3:59 AM, Frank Wunderlich ***@***.***> wrote:frank-w left a comment (frank-w/BPI-Router-Linux#177) Strange i do not see this and this patch is also there: 6658d42 Basicly i used the 7.0-main tree to build 7.1-rc through rebase...but maybe something in mainline has changed,but cannot reproduce it. You use the usb-c console,right? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[frank-w]

I wonder about mapping of ttyS0 it maps ttyS0 to serial1 not 0

https://github.com/frank-w/BPI-Router-Linux/blob/7.1-rc/arch/arm64/boot/dts/mediatek/mt7988a.dtsi#L342

Have you changed bootargs in dts or uboot? Still strange that i do not have this issue with 8x board.

Could you try these bootargs?

console=ttyS0,115200 earlycon keep_bootcon ignore_loglevel loglevel=8 initcall_debug

And maybe disable pci with pci=off? Or limiting cpu and irq handling

maxcpus=1 irqpoll

Also wonder about ledtrig-cpu....have you enabled this?

btw. this is how it looks on my 8x board:

root@bpi-r4:~# dmesg | grep ttyS                                                                                                                                                                              
[    0.000000] Kernel command line: board=bpi-r4 console=ttyS0,115200n1 earlycon=uart8250,mmio32,0x11000000 root=/dev/mmcblk0p6 rootfstype=ext4 rootwait debug=7                                              
[    0.847049] printk: legacy console [ttyS0] disabled                                                                                                                                                        
[    0.872361] 11000000.serial: ttyS0 at MMIO 0x11000000 (irq = 99, base_baud = 2500000) is a ST16650V2                                                                                                       
[    0.881662] printk: legacy console [ttyS0] enabled                                                                                                                                                         
[    0.923288] 11000100.serial: ttyS1 at MMIO 0x11000100 (irq = 100, base_baud = 2500000) is a ST16650V2                                                                                                      
[    0.953525] 11000200.serial: ttyS2 at MMIO 0x11000200 (irq = 101, base_baud = 2500000) is a ST16650V2                                                                                                      
[   19.960886] systemd[1]: Expecting device dev-ttyS0.device - /dev/ttyS0...                                                                                                                                  
root@bpi-r4:~# uname -a                                                                                                                                                                                       
Linux bpi-r4 7.1.0-rc1-bpi-r4 #1 SMP PREEMPT Sun May 24 12:26:39 CEST 2026 aarch64 GNU/Linux                 
root@bpi-r4:~# cat /proc/cmdline                                                                                                                                                                              
board=bpi-r4 console=ttyS0,115200n1 earlycon=uart8250,mmio32,0x11000000 root=/dev/mmcblk0p6 rootfstype=ext4 rootwait debug=7                                                                                  
root@bpi-r4:~# 

[wteiken]

Yeah it's a bit strange given the 6.18 and 7.0 boot just fine. With the other kernels it looks like your boot log (i.e., the messages about initializing the other serials). I poured over the kernel config, and for serial it all seems to match your default r4 kernel.

Let me try the bootarg variants to see if I can get it to boot.

[wteiken]

keep_bootcon makes it crash later (at "Disabling unused clocks"), so there is definitely something funky going on with the console.

cpu led triggers are not enabled.

[wteiken]

With clk_ignore_unused it went even further, and it's now hanging with a long list of "deferred probe pending", including the serial. That at least explains why all output stopped. And I assume all the pending probes may also cause the issues with the unused clocks being released (as most probes are not yet done).

I hope to find some time to debug what's going on there next weekend.

[frank-w]

Do you use my build.sh and defconfig? This is really strange

[wteiken]

I had used the r4 defconfig for one build, that still crashed. But that was a brief test, I am not yet positive there were no issues with that config. I am also using a different build script, so testing with your exact build envs is one thing I wnt to check.
I may have a driver in my build that hangs that is not in your defconfig. Same for the u-boot, in case that does initializations that causes the failure later (e.g. my u-boot has nvram compiled in, I think your config does not).

[wteiken]

Had a brief chance to look at the logs, it seems the regulator is not coming up:

platform cci: deferred probe pending: platform: wait for supplier /soc/i2c@11003000/rt5190a@64/regulators/buck3

The same kernel binary boots successfully on a bpi r4 which supposedly uses the same regulator, so not sure what's going on.

Successful boots contain a "/soc/i2c@11003000/rt5190a@64: Fixed dependency cycle(s) with /soc/i2c@11003000/rt5190a@64/regulators/buck1", so wondering if that has something to do with it (i.e., if the circular dependency is not fixed I assume it could be a deadlock during boot).

But no idea why it would manifest here and not for you. Also I did not see any changes various related files I looked at between 7.0 and 7.1-rc1.

But at least a starting point.

[wteiken]

The 4e pro boots further with the r4 dtb (drops me into emergency shell), so something in the 4e dtb borks it up.

[wteiken]

Mystery (somewhat) solved, it was the pcie-hogs. With them removed the system boots up. No idea why this did not affect you though. Do you have all pci disabled?

Can also confirm now that sfp lan is working with the dts changes, and the overlays work for the wan interfaces.

[frank-w]

You cannot set all pcie overlays...only 2...one for pcie2 (cn13 or cn15) and one for pcie3 (cn14 or cn18).

[wteiken]

Yes. I don't have any overlays loaded (so the pcie lines are with the m.2 ports for nvme).

If I remove the pcie-hogs from the mt7988a-bananapi-bpi-r4-pro.dtsi then I can acctually boot. With them in the dts kernel 7.1-rc1 has these errors:
[ 2.317121] gpiochip_add_data_with_key: GPIOs 512..595 (pinctrl_moore) failed to register, -22
[ 2.325863] mt7988-pinctrl 1001f000.pinctrl: error -EINVAL: Failed to add gpio_chip
[ 2.333623] mt7988-pinctrl 1001f000.pinctrl: probe with driver mt7988-pinctrl failed with error -22
[ 2.342894] probe of 1001f000.pinctrl returned 22 after 20000 usecs

That seems to then cascade into all the other issues.

With 7.0 (or 6.18) this does not happen with the same dtb. So something in 7.1 has changed the setup of the gpio-hogs that makes this fail. I'll see if I can debug a bit more this weekend.

But I am still puzzled that this does not happen with the 8x board, as far as I can tell none of this should be board-specific.

[frank-w]

I have 2 pcie overlays (cn15 pcie2-key-b and cn14 pcie3 key-m) applied through uenv.txt

[wteiken]

D'OH I completely missed that overlays for cn13 and cn14 were introduced and had not overlay which is causing the crash.

This seems like a not very user friendly situation given that if no overlay is used the kernel crashes with a somewhat obscure error message (GPIOs not being able to register).
Why not make the output high default for the hogs and only use the cn15/cn18 overlays to override that to a low?

Or as an alternative if overwriting values is frowned upon not put the hogs into mt7988a-bananapi-bpi-r4-pro.dtsi at all? Then at least the kernel does not crash, and the overlays would add it to be explicit. That would also give a reasonable default behavior as -- according to the docs -- the mux defaults to the high setting. That also matches my test yesterday when I removed the hogs from the dtsi, I still could boot from the nvme which requires the pcie line.

[wteiken]

Created a PR against 7.1 for the changes for the SFP LAN. Also created a PR for a suggested change of the overlay structure for the pcie-hogs.

[frank-w]

D'OH I completely missed that overlays for cn13 and cn14 were introduced and had not overlay which is causing the crash.
This seems like a not very user friendly situation given that if no overlay is used the kernel crashes with a somewhat obscure error message (GPIOs not being able to register). Why not make the output high default for the hogs and only use the cn15/cn18 overlays to override that to a low?

That is not possible as active-low/high is a boolean property which cannot ve overridden by the other resulting in both properties set and similar unstable. This was the way i first upstreamed before i had added the key-m overlays.

Or as an alternative if overwriting values is frowned upon not put the hogs into mt7988a-bananapi-bpi-r4-pro.dtsi at all? Then at least the kernel does not crash, and the overlays would add it to be explicit. That would also give a reasonable default behavior as -- according to the docs -- the mux defaults to the high setting. That also matches my test yesterday when I removed the hogs from the dtsi, I still could boot from the nvme which requires the pcie line.

Also thought about this,but then i had to put the full gpio-hog into all overlays which makes redundant code twice.

[wteiken]

Yeah, override was the wrong word. But I agree that setting both creates a bad dependency between the dts and the implementation given it only works with how the properties are currently checked. And it would be reasonable that there will be a check added at some point that flags both properties being set.

I still think that the code duplication by pulling the full hog description into the overlays is better than having a dts that by itself makes the kernel crash.

Another option here would be for the gpio code to throw an error and ignore the hog instead of causing the whole gpio initialization failing. But that may be a worse outcome with other boards.

I am also still wondering if not having the hog at all for cn13/cn14 is a reasonable option given the "default" should be they are used (according to the schematics). Though not sure if it would be a default high (or open) for the GPIOs, or if basically whatever u-boot initialized would persist if no explicit hog config is set up.