Can someone tell me what software bug exists in version V1.0.70 of the mxl862?
I checked relevant forums, and it seems the network port problem is caused by incompatibility with the open-source OpenWrt image.
If you can provide more detailed information, please let me know.
Mainline driver (used also in openwrt) sometimes run in timeout (internal phys not recognized or bot completely configured) because switch is initialized first completely with all possible options in non-dsa mode which has also some security relevant issues and then driver configures some parts for dsa. For upstreaming switch has to be initialized in very basic mode (full isolation,no web-ui,etc.) and then configured like dt says. With current software afair 10g port mode cannot be changed, 10gbase-r is imho fixed for ports used for cpu and sfp/phy.
@sinovoip @sinovoip1 any words on this? Can we get some clarity on how you plan to handle this?
We would love some clear feedback on the topic.
Good morning @Pedro Ameruoso, they’re not going to answer you, and we don’t expect them to.
We’re still waiting for them to mass-produce all of this:
and this: BPI-R4 Accessories : WIFI7 module extension suites
You can wait a long time for them to show up and give any explanation; they’re only interested in the dollars.
Have a good day.
Equipment used: R4Pro 8X, CAT7 Ethernet cable, and a PC with a 10G Ethernet port.
Image name: BPI-R4Pro-8X-BE14-MT76-OpenWRT24.10-DSA-snand-251229.bin
MXL firmware version: 1.0.70.70
I tested the network port using the image from the BPI official website and did not experience any instability. Please try using the BPI official website image or source code.If you are using third-party source code, you may need to check the code’s compatibility.
I know that the downstream driver works,but mainline driver has some requirements which are not filled there. These require port isolation and very basic preconfig till driver kicks in. And then configuring all needed based on dts.
Hi everyone, BPI has put the latest 1.0.85 Mxl firmware on its official website. If you need to upgrade, you can download it from here. The flashing instructions are in gettingstart.
Hiya, thanks for that. I have a few questions.
- Can you also please provide the previous (working) firmware so if things don’t go right, I can revert it to the previous version.
- Why exactly should I update to this firmware? A detailed list of reasons would be great.
- Please provide
sha256sumof all the firmware files, including the previous one. - Has anyone tried out this firmware update? If so, what have you noticed?
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.
- Agree @hyf please provide sha256 at least of the firmware file so we can be sure we are downloading a good binary file.
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