Hi @Leo-PL,
When you have some time, please take a look at this LED issue (it's for MR52, not MX64/65) to see if you may have some idea of its root cause: https://github.com/openwrt/openwrt/issues/15596
Thanks a lot!
I gave it a shot anyway (see https://gist.github.com/Leo-PL/934f87295521f3073c079216e5d60e27 again) and it seems that qca8k expects at least one port to be marked as CPU:
[ 0.651634] b53-srab-switch 18036000.ethernet-switch: SerDes lane 0, model: 1, rev B0 (OUI: 0x0143bff0)
[ 0.661085] b53-srab-switch 18036000.ethernet-switch: Port 5 mode: sgmii
[ 0.668638] b53-srab-switch 18036000.ethernet-switch: SerDes lane 1, model: 1, rev B0 (OUI: 0x0143bff0)
[ 0.678059] b53-srab-switch 18036000.ethernet-switch: Port 4 mode: sgmii
[ 0.684882] b53-srab-switch 18036000.ethernet-switch: found switch: BCM585xx/586xx/88312, rev 0
[ 0.707692] b53-srab-switch 18036000.ethernet-switch: SerDes lane 0, model: 1, rev B0 (OUI: 0x0143bff0)
[ 0.717140] b53-srab-switch 18036000.ethernet-switch: Port 5 mode: sgmii
[ 0.724715] b53-srab-switch 18036000.ethernet-switch: SerDes lane 1, model: 1, rev B0 (OUI: 0x0143bff0)
[ 0.734144] b53-srab-switch 18036000.ethernet-switch: Port 4 mode: sgmii
[ 0.740884] b53-srab-switch 18036000.ethernet-switch: found switch: BCM585xx/586xx/88312, rev 0
[ 0.755050] qca8k mdio_mux-1.0:10: No cpu port configured in both cpu port0 and port6
[ 0.762946] b53-srab-switch: probe of 18036000.ethernet-switch failed with error -22
So it looks like qca8k needs modification to accept that. I need to think this out more deeply - I.E. this will have to wait a bit. Any chance you could look on LAN LEDs patch for the device tree?
1 Like
well yes port 0 = cpu port
port 6 interconnected with the other switch...
Hi All. Thanks for this. I saw this get into the main openwrt git so I decided to get one to try....
Also looking the wiki. mx65 hasn't been updated. I guess I'll have a go if I can get mine to work.
edit:
OK more reading. Removed unnecessary information.
SO above there's a CPU port, and a switch to switch interconnect?
That's going to require work?
So we currently have to switch through the CPU?
What I'm curious about is do the PoE PSE's work? I'll have to look up what chips
they are and whether there's an easy way to talk to them?
What is PoE PSE status?
Similarly, any more info on the PoE PD functionality?
PoE PD capability:
I'm confused about mx65 can't power another mx65, but mx68 can power mx65? Datasheet says both PoE+ or am I missing something?
So is it nonstandard PD detection, or is it the class is such that we can't power it? I need to do more research.
read the bootlog. Everything is in one br-lan switch? At least for kernel 5.4? (old?)
Works, but packets from LAN3~7 towards LAN8~12 go through Broadcom switch instead of directly between QCAs, taking some bandwitdh from CPU which also attaches to Broadcom switch, together with WAN1~2 ports.
Works with custom test build I uploaded above. Not upstreamed yet, the PSE driver is a hot steaming pile of mess. Rebased patches are on my github on meraki-mx65-poe branch if someone needs to build from source.
Never annouced officially, but requires no work from OpenWrt side.
Very old indeed, my builds are basically the same as current main (6.6) - and LAN3-LAN12 are on br-lan, yes. Switching is of course offloaded by DSA.
Yes and no at the same time, they do go towards CPU, but it isn't a direct connection from DSA's perspective in the way DSA's creators imagined. But anyway - the device works, the qca8k-qca8k interconnect is IMHO just nice to have right now.
Another thing is, whether DSA can support a cyclic connection between switches at_all, I need to take a look at Turris Mox device tree once again - it had a complex example of multiple switch connections. If there is a cycle, then maybe there is a chance.
1 Like
well maybe some inter-chip API are needed or for sure the FDB needs to have correct values for the 2 switch to accept packet... But again the first thing to check is if the port 6 in both switch is correctly configured with the right values. Then maybe port 6 needs to be enable autolearning...
One thing to check would be to dump the fdb table and see if one switch have entry of the other.
1 Like
Huh... good idea. I could enable both as user ports just to verify if they can pass packets, at first.
1 Like
I just installed the latest snapshot dated today Oct 24th on my MX64. It looks like the Luci Package has dependency issues with installing. Will this iron itself out in a couple days?
Edit never mind guess the packages were not done updating on the repo.
1 Like
I tried making port 6 a user port, but with a fixed-link attached, and got crash in qca8k upon attempting to bring that port up:
[ 35.055839] phy_copy_pause_bits from qca8k_port_enable+0xcc/0xe0
[ 35.061954] qca8k_port_enable from dsa_port_enable_rt+0x2c/0xa0
[ 35.067986] dsa_port_enable_rt from dsa_slave_open+0xb8/0x180
[ 35.073851] dsa_slave_open from __dev_open+0xd4/0x1a0
[ 35.079014] __dev_open from __dev_change_flags+0x184/0x220
[ 35.084601] __dev_change_flags from dev_change_flags+0x18/0x60
[ 35.090536] dev_change_flags from devinet_ioctl+0x5b4/0x800
[ 35.096221] devinet_ioctl from inet_ioctl+0x16c/0x280
[ 35.101383] inet_ioctl from sock_ioctl+0x240/0x620
[ 35.106282] sock_ioctl from sys_ioctl+0x25c/0xc20
[ 35.111097] sys_ioctl from ret_fast_syscall+0x0/0x54
Full crash dump here: https://gist.github.com/Leo-PL/a00892548ed8521f252fb8f1390c9f70
Looks, like this situation (no PHY attached to a user port) will need some explicit handling as well.
1 Like
Context:mx65W
edit3: Looks like I should have read the top of the git commit properly..... =S
But I'm working through this with a serial console instead.
edit4:
there isn't an initramfs in openwrt snapshot? only squashfs install?
edit5:
But yeah made an initramfs building from source fine.
Of note for future reference. I had to leave it powered off for a long time to get it to come alive again after flashing the bootloader....
also of note: wouldn't find my 4G flash drive which had FAT by itself with no partition (i.e. /dev/sdb was what you mount in linux). Whilst 128M drive with fat16 in a partition. i.e. /dev/sdb1 when mounting was fine.
finally: port layout (which also makes sense after re-reading the git commit message....) is as follows:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
3: wan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-wan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
4: wan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-wan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
5: sw0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1502 qdisc noqueue state UP qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
6: sw1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1502 qdisc noqueue state UP qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
7: lan8@sw1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
8: lan9@sw1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
9: lan10@sw1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
10: lan11@sw1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
11: lan12@sw1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
12: lan3@sw0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
13: lan4@sw0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
14: lan5@sw0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
15: lan6@sw0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
16: lan7@sw0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
17: br-lan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
18: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
Patch sent through to the mailing list to get the initramfs builds in snapshot:
http://lists.openwrt.org/pipermail/openwrt-devel/2024-October/043324.html
Plus now that I've had success I have updated the wiki =)
I am trying to figure out if I have the updated uboot that allows for kernels larger than 3MB. I am able to boot up the latest snapshot directly from the Openwrt repo. The boot kernel MTD is only 3MB so I wasn't sure.
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00040000 "u-boot"
mtd1: 00300000 00040000 "bootkernel1"
mtd2: 00040000 00040000 "nvram"
mtd3: 00040000 00040000 "u-boot-env"
mtd4: 00080000 00040000 "shmoo"
mtd5: 00300000 00040000 "bootkernel2"
mtd6: 3f700000 00040000 "ubi"
Side note has anyone noticed the main OpenWRT.org site is incredibly slow lately?
1 Like
Then you have the right one, otherwise if the unit even booted, the networking would very likely be broken. You can also sha256sum your U-boot and compare against what I have.
1 Like
Thanks upon further reading of the pull request it says the size of mtd0 should be 00100000 or larger which as you rightly stated is what I have.
1 Like
It's been like that for me for the past 5 years =P
This statement confused me. I thought it was that the updated, larger bootloader size didn't fit?
The bigger bootloader was >512k and 0x80000 is 512k?
"Meraki diagnostic partition scheme used 0x80000"
Or was the question that you had the smaller / older bootloader flashed and need to check?
I was checking to make sure my partition scheme was correct and that I had the updated boot loader. Sorry for any confusion. I do have the latest boot loader.
1 Like
edit: I had a look at the git commit again and there's something about a race condition with eth0 and dsa probe in preinit but unsure if these issues would then cause issues later?
Has anyone tried to reconfigure the wan ports and/or delete br-wan on an MX65?
I put mine back together so I don't have serial port at the moment....
Deleting the wan config at least for me results in not being able to talk to the device over any of the lan ports.
My workaround at the moment is br-wan just contains wan1 and I have wan2 used directly. i.e. at the moment:
root@OpenWrt:~# uci show network
network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='<redacted>'
network.globals.packet_steering='1'
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='lan3' 'lan4' 'lan5' 'lan6' 'lan7' 'lan8' 'lan9' 'lan10' 'lan11' 'lan12'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.@device[1]=device
network.@device[1].name='br-wan'
network.@device[1].type='bridge'
network.@device[1].ports='wan1'
network.@device[1].macaddr='<mostlyredacted>3'
network.@device[2]=device
network.@device[2].name='wan1'
network.@device[2].macaddr='<mostlyredacted>1'
network.@device[3]=device
network.@device[3].name='wan2'
network.@device[3].macaddr='<mostlyredacted>2'
network.wan=interface
network.wan.device='br-wan'
network.wan.proto='dhcp'
network.wan6=interface
network.wan6.device='br-wan'
network.wan6.proto='dhcpv6'
network.wan2=interface
network.wan2.proto='dhcp'
network.wan2.device='wan2'
network.wan2v6=interface
network.wan2v6.proto='dhcpv6'
network.wan2v6.device='wan2'
network.wan2v6.reqaddress='try'
network.wan2v6.reqprefix='auto'
Hi all, I am new to Openwrt and just recently tried to flash MX65 following steps in
https://openwrt.org/toh/meraki/mx65w
Using clayface uboot
but then initramfs-kernel from the same repo folder was not working for me.
However thanks to this thread and Leo builds,
https://drive.google.com/drive/folders/1sq2kuuHpL4ylq3zJKcKXXG2a0BRrdE4N
, I managed to flash the MX65 successfully.
BusyBox v1.36.1 (2024-10-19 19:10:52 UTC) built-in shell (ash)
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -| || | | || || |
|_____|| |||||___||| |____|
|| W I R E L E S S F R E E D O M
OpenWrt SNAPSHOT, r27578+130-23ac1ad95155
As I next step, I was looking for some packages, but seems opkg update is failing.
Downloading https://downloads.openwrt.org/snapshots/targets/bcm53xx/generic/packages/Packages.gz
*** Failed to download the package list from https://downloads.openwrt.org/snapshots/targets/bcm53xx/generic/packages/Packages.gz
Not sure if this is because of the device being experimental and not production.
Sorry if this is a very obvious, easy or off topic question, just was not sure why is this happening.
Thanks for the brilliant work done for this device. Seems very capable for home use (may be more for others) and without Openwrt support, it will be just another e-waste.
There is official support merged since almost a month. There is no more need to use my test images.
As for the packages not updating, please wait a while until NTP syncs time, so HTTPS certificate validates.
Thanks Leo,
I have downloaded the sysupgrade image:
https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=bcm53xx%2Fgeneric&id=meraki_mx65
and the initial the upgrade over web UI luci.
After reboot I am able to ssh to the device, but there is no webui/luci and also not able to install anything as opkg is missing 
BusyBox v1.36.1 (2024-11-15 23:25:14 UTC) built-in shell (ash)
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -| || | | || || |
|_____|| |||||___||| |____|
|| W I R E L E S S F R E E D O M
OpenWrt SNAPSHOT, r28092-487ca61f91
opkg -h
-ash: opkg: not found
Any idea, should I rollback to your image?
Thats because they changed to apk.