Hiya, thanks for that. I have a few questions.
sha256sum of all the firmware files, including the previous one.Thanks,
- Bana
For 1 I tried asking this in the past to pbi. They never allowed me to have it. I decided to use flashrom and a sop-8 clip to dump it myself for backup purposes.
For 2 look at the thread on openwrt pull request and focus on Daniel posts. It will give you visibility in what should have been addressed.
Hello everyone.
I decided to trust the firmware files provided by Banana Pi and updated the MaxLinear MxL862xx switch firmware on my BPI-R4 Pro 8X.
I used this file:
mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca.bin
The flashing process reported:
Erase flash
Program flash
successfully download firmware to target
However, immediately after that, the kernel started showing multiple errors:
mxl862xx: failed to read mmd on port 1
mxl862xx: failed to read mmd on port 2
phy_check_link_status returned: -22
FW Upload Failed - Register Read Failed
During reboot, there were also many bridge and VLAN-related errors:
failed to remove port from bridge
failed to clear bridge port flag
failed to delete vlan 1: -EPERM
WARNING at nbp_vlan_flush
After reboot, the switch firmware version is detected as:
Firmware version 1.0.85.85
Firmware Version: 0.105 (0x0069 test version)
root@OpenWrt:~# dmesg | grep -iE 'mxl.*firmware|firmware.*mxl'
[ 6.801806] MaxLinear Ethernet MxL862XX mxl862xx_dsa-0:00: Firmware Version: 0.105 (0x0069 test version)
[ 6.839988] MaxLinear Ethernet MxL862XX mxl862xx_dsa-0:01: Firmware Version: 0.105 (0x0069 test version)
[ 6.878171] MaxLinear Ethernet MxL862XX mxl862xx_dsa-0:02: Firmware Version: 0.105 (0x0069 test version)
[ 6.916339] MaxLinear Ethernet MxL862XX mxl862xx_dsa-0:03: Firmware Version: 0.105 (0x0069 test version)
[ 11.781786] mxl862xx mdio-bus:10: Firmware version 1.0.85.85
The router boots and the MxL ports appear to work, but the log still contains repeated messages such as:
mxl862xx: failed to write mmd on port 30
So the firmware update itself seems to have completed, but the amount of errors and the “test version” label are concerning.
Is this expected behavior for firmware version 1.0.85.85 / build 0x0069?
I would suggest you put all your findings on the openwrt pull request for Daniel to comment and see if it is normal
This is caused by the as21 phy driver writing to non-existent device before checking for as21 phy.
This is only happen when using the downstream as21 driver from bpi/mtk-sdk and can be fixed like this:
Even then how do you know what you read is the correct firmware? I think without, at least, the checksum this is risky business.
I dumped 5 times and all the dumps have same sha. Better than nothing.
Anyone as brave enough as @abs1ck to update their firmware?
@hyf, have you tried the new firmware and do you work for the company?
I asked Claude a question or set of questions and it said:
The debug shell is huge. Baked into this image is a full Zephyr shell with
gphy_cfg,xpcs_cli,sfp_cli,msec_cli,mgmt_intf,flash_mxl,chiptest, plus raw primitives:devmem(physical memory r/w), raw MDIO/MMD/SERDES/XPCS register read-write, cable diagnostics (ABIST/CDIAG), loopback and BERT test modes. If that console is reachable (UART header, or theUART_0backend it references), it’s a very deep hook into the chip.
We really need the old firmware just in case something happens with the new update. That said, apparently there are dual firmware slots so this shouldn’t be an issue - one has to figure out how to switch to the old one in the event that the new one does not work or has issues.
MxL 1.0.85: three incompatibilities with the mainline DSA driver
I flashed the new mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca on a BPI-R4 Pro 8X and want to warn people running the mainline/DSA driver rather than BPI’s downstream one. @abs1ck’s report above is on the downstream driver (mxl862xx_dsa-0:00).
Setup: Arch Linux, @frank-w 7.1-main (tip f301d684b889), MxL86252C. The flash itself worked perfectly via the in-kernel devlink dev flash: firmware 1.0.85 (build 85), internal GPHYs 0.77 → 0.105 (0x0069).
Then three separate things broke.
1. XPCS API returns ENOTSUP → switch unreachable
mxl862xx_setup_pcs() selects the firmware XPCS ops at >= 1.0.80. On 1.0.85 those commands do not exist:
mxl862xx mdio-bus:10: configuring for fixed/10gbase-r link mode
mxl862xx mdio-bus:10: CMD 1a03 returned error -134
mxl862xx mdio-bus:10: CMD 1a01 returned error -22
mxl862xx mdio-bus:10: pcs_config failed: -EIO
1a03 is XPCS_PCS_ENABLE; -134 is ENOTSUP in the Zephyr errno space. 1a01/1a02 (PCS_CONFIG/GET_STATE) then fail with -EINVAL, and GET_STATE is polled once per second forever. No SerDes port links, including port 9 — the 10GBASE-R CPU port — so the switch is unreachable from the SoC even though the internal GPHYs link normally.
@dangowrt’s tree already handles this: the gate is at >= 1.0.84, and the XPCS API was renumbered (PCS_ENABLE is gone; +0x7 is now PCS_LINK_UP). frank’s snapshot predates that.
2. PCE rule writes rejected with -1022
mxl862xx mdio-bus:10: CMD 0202 returned error -1022
mxl862xx mdio-bus:10: Unable to use tag protocol "mxl862xx-8021q": -EIO
mxl862xx mdio-bus:10: probe with driver mxl862xx failed with error -5
0202 is TFLOW_PCERULEWRITE. Probe aborts, so zero user ports are registered. Port 0 accepts CTP indices 1–4; port 1 accepts 1–3 and is refused 4 — looks like a reduced or shared per-CTP block rather than a per-port-type limit. Region-0 PCE writes still succeed, so struct mxl862xx_pce_rule is unchanged.
Again already fixed upstream of frank: @dangowrt added PCERULELOGICWRITE gated at >= 1.0.83, where the firmware grows the per-CTP block on demand instead of indexing a fixed one.
3. tag_8021q stops forwarding
With dsa-tag-protocol = "mxl862xx-8021q" on 1.0.85, probe completes, every port links, bridge ports reach forwarding — and nothing passes. Conduit capture shows the tags are correct in both directions (per-port VIDs 3074/3075/3085, stripped properly). Disabling bridge VLAN filtering changes nothing.
Switching the same running kernel to the native tag restores forwarding on the SerDes port immediately:
echo mxl862xx > /sys/class/net/<conduit>/dsa/tagging
Still unsolved: GPHY ingress is dead!
The four internal 2.5G copper ports receive nothing, in either tag mode. Switch-side RMON (ethtool -S) on a port with a 1G client and carrier up for minutes:
tx_packets: 8439 rx_packets: 0 rx_bytes: 0
TxAcmDroppedPkts: 0 RxFilteredPkts: 0 RxExtendedVlanDiscardPkts: 0
MtuExceedDiscardPkts: 0 RxBadBytes: 0
Every discard counter is zero — frames never reach the switch MAC at all. The SerDes port on the same switch shows normal RX plus non-zero RxFilteredPkts/RxBadBytes.
@dangowrt’s mxl-gpy.c carries a link_change_notify hook that force-sets VSPEC1_SGMII_CTRL_ANEN on every link change, with the comment “setting SGMII AN to enabled then back to disabled clears this for some reason” — same symptom, no root cause. I reproduced the register state (VSPEC1_SGMII_CTRL = 0x0008, ANEN clear, at a 1G link) and tried setting ANEN, ANEN+ANRS, and the enable→disable toggle by hand. The writes stick (read back correctly, firmware does not fight them) but RX stays at 0. So on this firmware it is not simply the ANEN bit.
Summary
@frank-w — would a resync of drivers/net/dsa/mxl862xx/ (and the mxl-gpy delta) from @dangowrt’s tree be on the cards? Happy to test and send a PR if useful.
@dangowrt — the GPHY ingress failure above may be a cleaner reproduction of whatever your link_change_notify hack is papering over, if that’s of any use. Full logs, conduit captures and RMON dumps available on request.
@pameruoso — you mentioned dumping your 1.0.70 off the QSPI with flashrom and getting a matching SHA five times. Would you be willing to share it? No public 1.0.70 image exists and BPI has declined to provide one, so it is currently the only known rollback for anyone who hits this. (Also interested in how you’d restore it — the published upgrade image has an MCUboot header and two CRC’d slots, which a raw chip dump won’t match.)
My dumps are 8MB size (the size of the qspi).
If anything goes wrong and if bpi or maxlinear does not provide anything I think last resort for me would be to just use the same sop-8 clip with flashrom -w to write entirely the spi again.
I don’t know if my backup is shareable…I guess I am not allowed for NDA paperworks. Should we just wait for Daniel to jump in and clarify if the .85 build should just work?
these are great news … let’s see if it works with 7.2 when is out
Would be great if you can strip changes between 7.2-ec or 7.1-main and daniels wip tree.
Want to try upgrading firmware with wip tree next days. Does it work so far for you?
It’s fine. And also quick update. I think I managed to fix most of the things so, TLDR, I’m in an equivalent (or better) state than 1.0.70 was. These tasks are so much easier with AI now, but harder to verify, I guess. A cost worth paying sometimes I guess. Anyway see below:
XPCS works: the -134/-EINVAL cascade was exactly what it looked like — frank’s tree gates the API at >= 1.0.80 and 1.0.85 has renumbered/reshaped it, same as @dangowrt found. I disassembled the 1.0.85 dispatch table to pin down the new PCS_CONFIG/GET_STATE payload layouts and what +0x7 (now PCS_LINK_UP) actually does. One catch worth flagging for anyone else hitting this: the CPU port’s XPCS instance on my board refuses the firmware’s own negotiation commands once it’s been put into a fixed-rate mode, so driving it through the API — rather than the legacy register path — silently breaks forwarding while the port still reports link. Traced that down to the instance itself, not the payload shape, so the fix keeps the CPU port on the legacy path and only moves the SFP/PHY combo port onto the new API.
tag_8021q works: forwarding was dying on a VBP (virtual bridge port) map ordering bug, unrelated to the XPCS issue. Fixed and confirmed working with per-port VLANs.
GPHY work: mxl862xx_set_cpu_vbp() updates each virtual bridge port with a mask covering only BRIDGE_ID and EGRESS_SUB_METER, leaving bridge_port_map zeroed in the request. The map had been written once, by mxl862xx_setup_virtual_bridge_port(). Firmware 1.0.85 does not preserve a field the caller did not select, and mxl862xx_complete_tag_8021q_setup() calls set_cpu_vbp() for every port immediately after allocation — so the map was cleared before the first frame was ever forwarded.
Can I help with firmware testing? But I have version 4e. How can I take the current firmware dump and how can I find out what version it is? Now I use:
But I need fairly detailed instructions.
root@bpi-r4:~# devlink dev
platform/15020000.switch
mdio_bus/mdio-bus:10
root@bpi-r4:~# devlink dev info mdio_bus/mdio-bus:10
mdio_bus/mdio-bus:10:
driver mxl862xx
versions:
fixed:
asic.id 8628
asic.rev 0
running:
fw 1.0.70
stored:
fw 1.0.70
currently applying daniels latest patches to my 7.2-rc tree as his tree has strange erros with my debian rootfs and my initrd has no devlink command
root@bpi-r4:~# ls
dmesg_7.2-rc1-r4pro8x.log mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca.bin regs rootfs_arm64.cpio.zst
root@bpi-r4:~# devlink dev flash mdio_bus/mdio-bus:10 file mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca.bin
[ 202.154602] mxl862xx mdio-bus:10: Direct firmware load for mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca.bin failed with error -2
[ 202.166882] mxl862xx mdio-bus:10: Falling back to sysfs fallback for: mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca.bin
Error: failed to locate the requested firmware file.
root@bpi-r4:~# cat /sys/class/thermal/thermal_zone0/temp
40742
root@bpi-r4:~# cp mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca.bin /lib/firmware/
root@bpi-r4:~# devlink dev flash mdio_bus/mdio-bus:10 file mxl862xxc_1030_1085_1085_0069_signed_xfi_upgrade_fca.bin
[ 346.177994] mxl862xx mdio-bus:10: flash: running firmware 1.0.70
[ 346.185852] lanbr0: port 3(lan1) entered disabled state
[ 346.192836] lanbr0: port 1(lan2) entered disabled state
[ 346.199830] lanbr0: port 2(lan3) entered disabled state
[ 346.205476] mtk_soc_eth 15100000.ethernet eth2: Link is Down
Waiting for bootloader
Erasing flash
Flashing 100% ( 0m 22s )[ 398.682014] mxl862xx mdio-bus:10: switch ready after 2080ms, firmware 1.0.85 (build 85)
after that i got many traces and had to power off the board
after a boot i get this:
root@bpi-r4:~# dmesg | grep -i mxl
[ 5.431737] mxl862xx mdio-bus:10: switch ready after 2140ms, firmware 1.0.85 (build 85)
[ 5.464303] mxl862xx mdio-bus:10: CMD 1801 returned error -19
[ 5.481280] MaxLinear Ethernet MxL86252 mdio-bus:10-mii:01: Firmware Version: 0.105 (0x0069 test version)
[ 5.519008] MaxLinear Ethernet MxL86252 mdio-bus:10-mii:02: Firmware Version: 0.105 (0x0069 test version)
[ 5.546630] MaxLinear Ethernet MxL86252 mdio-bus:10-mii:03: Firmware Version: 0.105 (0x0069 test version)
[ 5.911723] mxl862xx mdio-bus:10: configuring for fixed/10gbase-r link mode
[ 5.918995] mxl862xx mdio-bus:10: Link is Up - 10Gbps/Full - flow control off
[ 5.945748] mxl862xx mdio-bus:10 lan1 (uninitialized): failed to connect to PHY: -ENODEV
[ 5.953839] mxl862xx mdio-bus:10 lan1 (uninitialized): error -19 setting up PHY for tree 0, switch 0, port 1
yes. i have some patches for that. it’s exactly what i experienced.
yes. it’s exactly what i got after the update. I have some patches for it, but they are very rough. i’ll see if i can sort them out and do a PR tomorrow, against the 7.1-main, if you want them.
mhm, error does not happen with reg+1 of the phys, but now second port is lan1 and gives a linkup…first port is dead
his tree has also 0-based phy-regs
so i reverted this change for now
Did I understand correctly that testing is currently taking place on Debian? I need wait fix for openwrt?
I use debian for development as i find it much more easier as i can simply replace kernel without reflashing or rebuilding userspace and no struggle with quilt and patchfiles,others may test in openwrt.
Ok. I will wait update openwrt repo and i can test it. Now i not upgrade the firmware and i want save the old firmware. And i use bpi r4 pro 4e version the board. Big thx for the work! UpD: Now i see it:
It help for next support bpi r4 pro i hope.