BPI-R4 Pro 8x on 7.1-main: boot-stuck root cause + lan1/lan6/MAC fixes (patches)

Leth · August 1, 2026, 8:47pm

I’m new to the forum and wasn’t really sure where to post this. I’ve been trying to get nixos working on the BPI-R4 pro 8x and have it booting on 7.1-main. Along the way I found a few things that may be the cause of other issues.

All patches I’ve created are located on my gitlab

7.1 boot stuck: pcie hogs lost output-high

A hog without a direction parses as -EINVAL and gpiolib now fails the whole gpiochip registration on hog errors:

gpiochip_add_data_with_key: GPIOs 512..595 (pinctrl_moore) failed to register, -22
mt7988-pinctrl 1001f000.pinctrl: error -EINVAL: Failed to add gpio_chip

Everything downstream defers, the board isn’t hung, root just never mounts. This is visible with: earlycon=uart8250,mmio32,0x11000000 keep_bootcon

Patch Here

With no serial aliases in the pro dtsi the numbering follows probe order. On 7.1 UART1 grabs the ttyS0 and console=ttyS0 lands on the pinless UART which makes the kernel look dead.

Patch Here

With the hogs fixed @frank-w 's disabled 8x eth description works, however ds_mux0 still had reg=<12> from before the AS21 port moved to 13. With that fixed lan1-4, lan5, and lan6 all forward.

Patch here

Lan1 intermittently missing

The driver waits for the management fw, but each internal GPHY boots up its own fw for ~3s more. The one shot of_mdiobus_register() scan hits address 0 first and intermittently drops lan1 for good. The 7.1 soft reset is what opened the window; the reset itself is right as it fixes the warm-reboot flap, this just gates the scan. Fix polls each DT-declared PHY for a sane PHYSID1 before registering the bus. Patch Here

The CMD 1802 returned error -19 boot storm is the same un-gated window, but cosmetic.

Random MACs on gmac1/gmac2

the pro dtsi only aliases ethernet0 while the plain R4 has all three, so u-boot’s MAC fixup has nowhere to put eth1addr/eth2addr and gmac1/gmac2 come up with random MACs every boot.

Patch Here

Back USB dead(now fixed upstream) I also carried a fix for the back USB being dead, but it looks like upstream fixed it on the 7.1-main as of July 30th, so I’ll just adopt that change.

I’m happy to answer any questions, provide full logs, my notes, or provide PR’s if desired.

Full disclosure: I am a devops/k8s person, I utilized Fable to assist with finding these issues and implementing appropriate fixes, however I would appreciate advice refining anything here if there are better ways. My collaborator in this understands it better than I do, but I am unsure if they have an account here, if anyone has any questions I can’t answer I’ll drag them over to come and answer!

frank-w · August 1, 2026, 8:59pm

thanks, but the gpio-hog patch is wrong as it does not allow to switch hog to different value with the other overlay…this is why i have changed it upstream…you have to apply overlays for the ports you want to use (one for pcie2 and one for pcie3). without these overlay indeed board hangs, but daniel posted a patch that hog is not tried to be initialized and breaking full pinctrl device

https://patchwork.kernel.org/project/linux-mediatek/patch/4c67cf0839ccf57db35a826df6d8fc779531509a.1783974733.git.daniel@makrotopia.org/

broken debug console i had only on the 4E board and also added an alias here (but only for serial0) to fix it, but feel free to send your patch upstream with all serial phandles.

dsmux i had not noticed yet (I used overlays in 7.2), but did a change here to be closer with downstream driver on upstream one which had reg+1 (afair in 7.0) and seem to miss this change.

got a bunch of PRs last days and the usb-fix was one of them…seems that clock got disabled because phy is shared between pcie and xhci (there are 2 PR where one was a bit more complex).

Leth · August 1, 2026, 9:37pm

Ahh, that makes sense. I didn’t know that the direction was dropped so the connector overlays pick the slot wiring; I see the cn13-18 dtso files now. I’ll swap to those and drop my hog patch. Thanks!

I’ll put together a PR for the three phandles and another for the mux; hopefully you’ll find them useful!

I figure you would have found the lan1 race prior to shipping your code, I just enabled the description early, so happened to run into it.

I assumed there were things I wasn’t aware of upstream that would make my fixes not ideal broad-scope, so I really appreciate you taking the time to reply! I didn’t really mean to find any fixes, I’m just playing with nixos and happened to stumble across these. I’m currently trying to see if I can get the rest of the thermals in the board to report, there are a few that can report but are just silent. Fun little weekend project!

Thanks again!

frank-w · August 1, 2026, 10:10pm

Did not noticed a race with lan1 yet

Leth · August 1, 2026, 10:34pm

It only fires when the management fw comes up early. My boots at 2390ms raced, 2450/2460ms didn’t open the window, so a board that trends late can cold-boot without hitting it. I encountered this on two different 8x boards - however I only have the boot logs from this board, I don’t have the logs from my friends board. Amusingly I managed to boot 3x in a row without encountering it and it caused a bunch of confusion when his failed on the same build. The 4 boot tests later it appeared to be 50/50, but 4 isn’t really large enough sample to say for sure.

Attached 3 logs: a failing boot, the 4-boot fix validation, and the measured timing. 3-fingerprint-and-timing.txt (785 Bytes) 2-fix-validation.txt (1.5 KB) 1-failing-boot.txt (803 Bytes)

Note on the failing boot: there’s no switch ready line on its console (loglevel); it’s present in that boot’s dmesg. Unbind/rebind of mxl862xx brings lan1 back on, so the PHY itself is fine, it’s purely scan timing. The patch doesn’t touch the reset, it only gates the scan behind PHY readiness.

Full captures available if you want them.

frank-w · August 2, 2026, 7:36am

Ah,thought you saw a trace,this looks like the issue with switch i see on my 4E board with same kernel that works without issue on 8X.

How have you fixed it? It was told me that this is caused by current firmware which is really unstable and taking different amount of time without possibility to check when it is really ready to initialize the dsa stack and phys.

Edit found it https://gitlab.scopecreep.productions/sbc/nixos-sbc/-/blob/main/pkgs/bananaPiR4Pro/r4pro-mxl862xx-wait-for-phys.patch

Maybe this is related and the more correct fix as it fixes possible rootcause:

github.com/frank-w/BPI-Router-Linux

net: phy: as21xxx: stop probing foreign PHYs (root cause of the MxL862xx relay error flood)

frank-w:7.1-main ← meehien:bpi/as21xxx_prob_foreign_phy

opened 09:44AM - 01 Aug 26 UTC

meehien

+16 -2

Follow-up to #201, which just silenced the symptom. `aeon_gen1_match_phy_devi…ce()` calls `aeon_gen1_read_pid()`, which uses `aeon_cl45_read()`. That accessor ends with: ```c static void aeon_mdio_patch(struct phy_device *phydev) { mutex_lock(&bus->mdio_lock); __mdiobus_c45_write(bus, 30, 0x1, 0x1, 0x1); mutex_unlock(&bus->mdio_lock); } ``` A write to PHY address 30 — nothing is there. phylib calls `match_phy_device()` for every registered driver entry against every phydev on every bus. That includes the four internal GPY cores of the MxL86252C at `mdio-bus:10-mii:00..03`, whose bus is the switch firmware's MDIO relay. There the patch write becomes an `INT_GPHY_WRITE` mailbox command for PHY 30, which the firmware rejects: ``` mxl862xx mdio-bus:10: CMD 1802 returned error -19 ``` `CMD 1802` **is** `INT_GPHY_WRITE`. The error is the patch write itself. ## Arithmetic ``` N_cores × 12 match entries (11 gen1 + 1 gen2) × 2 PID reads ``` Measured on a BPI-R4 Pro boot where three of the four cores were present: `3 × 12 × 2 = 72`. Exactly 72 observed. ## Timing on my device confirms it is the match path ``` [14.302844] mxl862xx mdio-bus:10: switch ready after 2390ms, firmware 1.0.70 [14.348624] mxl862xx mdio-bus:10: CMD 1801 returned error -19 [14.393903] mxl862xx mdio-bus:10: CMD 1802 returned error -19 <- first ... 24 errors, 6.4 ms apart ... [14.557880] MaxLinear Ethernet MxL86252 mdio-bus:10-mii:01: Firmware Version: 0.77 [14.584632] mxl862xx mdio-bus:10: CMD 1802 returned error -19 <- continues ``` The errors start 46 ms after the switch reports ready and run *interleaved with* PHY binding. They cannot come from `mxl-gpy`'s `config_init`, which is what #201 claimed — that runs after a PHY has bound. ## Comparison with mainline `drivers/net/phy/as21xxx.c` in this same tree has no `__mdiobus_*` calls, no `mdio_lock` manipulation and no flush of any kind — all 24 register accesses go through `phy_{read,write,modify}_mmd()`. It loads the same firmware and identifies the same silicon without a patch write anywhere, which is good evidence the flush is not a hardware requirement of this PHY. Mainline also gates its match function before touching the bus: ```c if (!phy_id_compare_vendor(phydev->c45_ids.device_ids[MDIO_MMD_PCS], PHY_VENDOR_AEONSEMI)) return genphy_match_phy_device(phydev, phydrv); ``` The 1.9.2 vendor driver has neither protection, though it already defines `PHY_VENDOR_AEONSEMI` (unused). ## The patches **1/2 — don't write to a nonexistent PHY after C45 reads.** A read needs no flush: `__mdiobus_c45_read()` has already completed and dropped the bus lock when the patch write is issued. `aeon_mdio_patch()` is kept in `aeon_cl45_write()`, where the original workaround was reported to matter. After this change every remaining caller is reached only once a device is confirmed to be an AS21xxx, so no foreign bus is touched. **2/2 — only probe Aeonsemi PHYs when matching.** Brings the vendor driver in line with mainline. This removes the PID reads themselves — each one a full mailbox round-trip (write LEN_RET, write CTRL, poll BUSY, read back).

Btw. I’m really happe to get some help from you @Leth, @rmandrad and @meehien (do not worry if i miss somebody,just want to thank posters of latest comments).

rmandrad · August 2, 2026, 1:23pm

Hi @Frank @Leth

suggest @leth you look at my repo Commits · rmandrad/BPI-Router-Linux · GitHub

in particular commit - arm64: dts: restore BPI-R4 Pro 8X downstream MxL wiring · rmandrad/BPI-Router-Linux@9804cd4 · GitHub

long story short i restored a lot of what was on my 6.19/7.0 repo … i do remember in 6.19 i had to include a delay … anyhow the 6.19 has a lot of debugging (later taken out) if you feel strong enough to into debug mode

frank-w · August 2, 2026, 2:27pm

I want to stay on upstream mxl driver instead of using the downstream one. I would also take/modify the upstream as21 driver,but i had not got it working to some basic point as it does not bind (downstream does use also generic phyid for binding)

rmandrad · August 2, 2026, 3:11pm

absolutely @frank-w i am not arguing with your approach i wish i didn’t had to spent cycles updating the code for every new release. In fact, i like as it is my test baseline for every new kernel

meehien · August 2, 2026, 5:25pm

I use this patch internally too. I think it should be included.

Leth · August 3, 2026, 12:12am

So the suggested patch there addresses the as21xxx flood, and it does correctly fix the 1802 flood on boot. I’m glad someone fixed that because I found it irritating, thanks @meehien !!!

@rmandrad I’ll check out your repo when I have some time, busy over next few days unfortunately and digging further into this took the time I had to work on this today.

Okay, so the race condition, the one-shot MDIO scan reads the ID at address 0 while that GPHY is still booting its own firmware and that one failed read drops the port until reboot or unbind/rebind.

I reproduced it with that patch applied and my rate of lan1 drops went from 2/4 to 1/9. On my board the firmware-ready sits at ~2390-2410ms, right on the edge of the race failure. It could be entirely board dependent, my friend’s hit it regularly though I did not test it with that patch applied. I went down a rabbit hole trying to figure that out, including at one point putting the r4-pro in a freezer, but I still have no explanation for the reduced hit rate on the race failure with that patch.

What actually gates reproduction is the ready-pool granularity: mxl862xx_wait_ready() polls every 100ms, so the printed “switch ready after Nms” is quantized into ~100ms slots, and whether the scan lands before or after the GPHYs wake is decided by a few ms of firmware jitter at a poll boundary.

I confirmed this by building with the kernel ready poll at 20ms instead of 100ms so the detection tracks true firmware-ready instead of the poll grid, which reproduces the alignment stock timing reaches whenever the firmware lands just before a poll boundary.

switch ready after 2390ms got the CMD 1801 error.

[   13.844549] mxl862xx mdio-bus:10: switch ready after 2390ms, firmware 1.0.70 (build 70)
[   13.882730] mxl862xx mdio-bus:10: CMD 1801 returned error -19
[   13.888502] mdio_bus mdio-bus:10-mii: MDIO device at address 0 is missing.
[   14.426422] mxl862xx mdio-bus:10 lan1 (uninitialized): failed to connect to PHY: -ENODEV

I believe we should gate the MDIO bus registration on the DT-declared PHYs answering an ID read before of_mdiobus_register() - that’s the patch I’m running and have validated it fixes the issue. Happy to PR if you would like.

I did run into something else, which I do not currently understand.

mxl862xx unbind behaved state-dependently. Unbinding a healthy switch Ooopsed in phylink teardown both times I did it phylink_stop / phylink_destroy when mxl862xx_remove calls into dsa_unregister_switch, however unbind/rebind as a recovery on a boot that had already lost lan1 worked for me.

frank-w · August 3, 2026, 5:05am

If you still experience this error i can still add your patch. The R4Pro 4E issue (i thought it is the one you see) was a completely different part but also fixed now.

Leth · August 3, 2026, 8:32pm

I’ll send it over!

Didn’t mean to flood you with info!! Just am keenly aware of the obnoxious nature of a race conditions and how hard they can be to replicate, especially if they’re hardware rooted like this one might be.

I’ll get a pr for you later today.

Would you happen to have any idea about why that teardown behaves in that way? No big deal if not, purely a curiosity question, please don’t spend any time on it if you don’t already know, no one should ever run into it in a real situation. I was in an absurd edge case hunting down this race, but it was something I didn’t understand.