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

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
1

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!

2

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).

3

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!

4

Did not noticed a race with lan1 yet

5

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.