Cisco Meraki MX64/MX65 image support

Hi Guys,

I have a Cisco Meraki MX65 would this be a suitable candidate for OpenWrt? are these similar to the MX60 that currently has support?

The Specs i have gained so far:

12 ports (2 WAN / 10 LAN) with 2 POE ports up to 60W

Broadcom BCM58625BBOKF12G
StrataGX™ Communications Processor with Programmable Acceleration, Security and Storage Interface
[https://www.broadcom.com/products/embedded-and-networking-processors/communications/bcm5862x](http://Broadcom Specs)

16Gb (4x4 SKhynix H5TC4G83CFR)
The H5TC4G83CFR-xxA(I,L,J),H5TQC4G63CFR-xxA(I,L,J) are a 4Gb low power Double Data Rate III(DDR3L) Synchronous DRAM, ideally suited for the main memory applications which requires large memory density, high bandwidth and low power operation at 1.35V. SK Hynix DDR3L SDRAM provides backward compatibility with the 1.5V DDR3 based environment without any changes. SK Hynix 4Gb DDR3L SDRAMs offer fully synchronous operations referenced to both rising and falling edges of the clock. While all addresses and control inputs are latched on the rising edges of the clock (falling edges of the clock), data, data strobes and write data masks inputs are sampled on both rising and falling edges of it. The data paths are internally pipelined and 8-bit prefetched to achieve very high bandwidth.

2 x QCA8337-AL3C
The QCA8337 is a highly integrated seven-port Gigabit Ethernet switch with non-blocking switch fabric

LDT0666 linkcom
DC/DC Flyback transformer for PoE applications

2 x VP6014RM HF 1639M
IEEE 802.3at/ANSI X3.263 compliant performance.
Suitable for End-span POE applications with 720mA current capability.
Complying with ROHS & Halogen Free requirements.
Operating temperature range: -40℃ to +85℃.
Storage temperature range: -40℃ to +85℃.

5 x G2PM109RN LF 1524F (1 CHIP per 2 ports)
1000 Base T Dual Port Magnetics Modules; Insertion Loss (dB Max) 0.3~100MHz: -1.0

FCCID UDX-60047015

I have a USB-TTL on order so no output from the on-board serial as yet.

1 Like

It has Broadcom wireless, I wouldn't invest too much time in it unless you don't need the wireless part. The specific chips listed don't show up in the list of (un)supported devices by the official Linux driver either.

Nevermind me, looking at the wrong device.

MX65 is not even a wireless router.

Thanks Guys - Yes the MX65 is not wireless however the SOC does have support for wireless capabilities and more than likely is used for the MX65W wireless variant.

I don't require wireless was just looking to use the 10 Ports and the 2 POE for some wireless APs

Once my USB-TTL arrives i will have a play and see what i can get from the device

Hi Guys,

My USB -TTL arrived and i have managed to access the serial port during boot.
Dump posted here - [https://pastebin.com/rfnFYQm4](Meraki MX65 boot output)

Most relevant parts ( i think)

U-Boot 2012.10-00101-g93bc206
Linux version 3.4.111 (jdizzle@x) (gcc version 4.8.3 (GCC) ) #6 Wed May 4 11:23:30 PDT 2016
Linux version 3.4.109 (tpassaro@tpassaro-imac) (gcc version 4.8.3 (GCC) ) #15 SMP Sun Jan 10 21:10:58 PST 2016
BusyBox v1.20.2 (2015-12-18 17:37:54 PST)

It also seems like this is very similar (if not identical to the MX64 / MX64W hardware systems)

Meraki Z1 seem similar as well so i am going to read up on how they work with Openwrt and take it from there.

I have never worked on the hardware /flashing level before so any tips / guides would be appreciated.

Most timely hint would be to get the GPL sources and build chain. You’ll need to port to a current kernel, but that should have lots of info around chip and pin configuration.

Thanks for the advice @jeff . I have been doing a bit of digging around and found the following resources for GPL nothing specific about build chains and all seems to be a little out of date.
https://sourceforge.net/projects/officialmerakifirmware/files/ - Source files 2013 linux 2.X
https://osdn.net/projects/sfnet_officialmerakifirmware/releases/ - Source Files 2013
https://meraki.cisco.com/support/#policies - Meraki GPL policy
http://dl.meraki.net/linux/licenses/index.html - Meraki where source files were previously stored :frowning:
https://github.com/riptidewave93/meraki-linux - Source files linux 3.x

Meraki charge $15 for the latest downloads and you need to email them. open-source@meraki.com. This may become an option later down the line.

I started to follow the Z1 guide. Build for Cisco Meraki Z1 and have managed to gain root access. Big thanks to @vuhuy for such a well laid out guide.

Next step is to back up the partitions via SCP but that will have to wait until tomorrow.

3 Likes

So i have managed to back up each of the mtd partitions via SCP.

The question i now have. Will the initramfs images for the z1 work with the MX65? I don't know much about images for OpenWrt so hopefully someone with knowledge can advise?

The 2nd image for sysupgrade points to the following:

releases//targets/ar71xx/nand/openwrt--ar71xx-nand-z1-squashfs-sysupgrade.tar

When I search for the switch part QCA8337-AL3C
I get an OpenWrt page for [https://openwrt.org/toh/engenius/esr1750] (OpenWrt engenius)
This leads to the same ar71xx target

http://downloads.openwrt.org/releases/18.06.4/targets/ar71xx/generic/openwrt-18.06.4-ar71xx-generic-esr1750-squashfs-factory.dlf

Not sure how i work out of the BCM58625 is supported?
-edit so looking through the supported hardware table there is one entry for a BCM58XX device it uses target brcm47xx

Still not sure how to proceed from here. Any advice appreciated.

Following the "adding a new device guide" https://openwrt.org/docs/guide-developer/adding_new_device
I have captured the relevant data below:

dmesg output https://pastebin.com/XDDHZGJ7
cat / ls output https://pastebin.com/7MicTM4P

I have an MX64 and I can confirm this looks almost identical, even to the point where u-boot appears the same.

I have been given the sources from Meraki (didn't charge me $15 either). I can confirm:

  • They have taken U-Boot directly from a Broadcom dev kit and tweaked slightly to their requirements. There is however a lot of issues when attempting to build a more fully featured U-Boot so you can boot from tftp/xy modem or even USB. I know the Meraki CLI will allow you to flash from TFTP but this is pretty much a one-way deal. Rebuilding U-Boot allows a temporary initramfs so we can play on the platform and confirm 100% before flashing a sysupgrade.
  • Z1 and MX64/65 are not the same. Z1 is an Atheros based MIPS SoC whereas MX64/65 are Broadcom-iProc ARMv7. Don't flash as it simply won't work.
  • Everything else is already in kernel to with some basic work, you shouldn't have too much issues supporting this as a device. It really comes down to cracking u-boot to allow the flexibility needed.

Apart from this, they're quite a nice little router to play with. Dual core ARM 1.2ghz and passive cooling. Don't expect the performance figures Meraki quote under OpenWRT but should otherwise work fine, could do a iptables based firewall with a few extras like SNORT maybe.
I ran out of inspiration for using mine since I acquired an off the shelf firewall, but still happy to help.

Hey @micj thanks for the detailed reply. I have started searching around on meraki u-boot I came across the following https://github.com/riptidewave93/meraki-uboot/issues/1

I don’t know enough about u-boot yet to say if this will help but there are some decent comments on the issue

riptidewave93 (Chris) has done a great effort porting a lot of stuff over with the help of others. I reached out to him to host some of the sources below.

That page is a good guide on what's different between the meraki u-boot and a standard one.

Unfortunately if you use the standard source code for MX64 here:
https://dl.meraki.net/wired-14-39-mx64-20190426.tar.bz2
and
https://dl.meraki.net/U-boot-MX64-20190430.tar.bz2
There's still issues compiling standard features into u-boot.

Instructions for those wanting to play with the above sources:
First tarball:

cd meraki-firmware/openwrt

cp config-arm-3.4 .config

make oldconfig

make -j1 BOARD=arm-3.4 OPENWRT_EXTRA_BOARD_SUFFIX=_3.4

To build Linux-3.4 kernel:

cd meraki-firmware/linux-3.4

cp ../openwrt/target/linux/wired-arm-nsp-3.4/config .config

make CROSS_COMPILE=../openwrt/staging_dir_arm_nofpu_3.4/bin/arm-unknown-linux-uclibcgnueabi- ARCH=arm oldconfig

make CROSS_COMPILE=../openwrt/staging_dir_arm_nofpu_3.4/bin/arm-unknown-linux-uclibcgnueabi- ARCH=arm prepare

touch rootlist

make CROSS_COMPILE=../openwrt/staging_dir_arm_nofpu_3.4/bin/arm-unknown-linux-uclibcgnueabi- ARCH=arm vmlinux

second tarball (u-boot):

export CROSS_COMPILE=/path/to/arm32-cross-toolchain

cd U-boot.MX64

make kingpin_nand_config

make u-boot.bin

Looks like the MX65 is using the same U-boot as the MX64

xV4U-Boot 2012.10-00101-g93bc206 (Jun 19 2015 - 12:33:28)Meraki MX64 Boot Kernel Loader
U-Boot 2012.10-00101-g93bc206 (Jun 19 2015 - 12:33:28)Meraki MX64 Boot Kernel Loader

Looks like you could use some reinforcements, this thread is just poor CM65 doing all the work.

Well I've got a MX65W I just took apart, I'll join you to see if I can offer any help ! :slight_smile:

Thats great @arcstar7 have you gained root access yet? I used the Z1 guide (link in previous post) without issue but my MX65 has not been connected to the internet for updates in over 2 years so not sure if it will work on a more recent build.

I am currently trying to wrap my head around U-boot and how to build from the Meraki source before starting to make changes.

Meraki confirmed today that the MX64/MX65 share the same code in regards to OpenWRT and U-Boot. The latest code was already posted by @micj

Hello fellow OWRT users,
any progress on this topic? I just recently bought a used MX65W for 160 Bucks. I still have an active Cloud Account with remaining 2 years license, but I would prefer flashing all my meraki devices with openwrt.
Where do you guys stuck? Maybe I can help. :slight_smile:

May I summarize all achievments you guys managed out?

  • @CM65 managed it to become root (dats awesome)
  • BackUP Successfully
  • U-Boot not fully featured (tftp USB support/compiling issues/tweaks needed to get the hardware useable by 100%)
  • MX64/65 are technically equal (primary U-Boot)
  • Issues compiling from standard source code
  • SoC driver has to be changed from Atheros to Broadcom(BCM58XX) If we intend to try out the Z1 Version

Any other progress @CM65 ? Thanks by the way for your efforts. :slight_smile:

Lets step down where you currently stuck on, so we can try to work on the same step, since your last post were some days ago..

That's a great summery so far @g4njawizard. I am currently trying to build the Meraki images.

  • I started with a clean ubuntu 18.04.3 LTS build.
  • Installed libgtk2.0-dev
  • Installed make
  • Extracted the tar files that @micj posted
  • cp config-arm-3.4 .config
  • make oldconfig --> output from command here https://pastebin.com/qnsMdPHF I have not had a chance to review all the output yet
  • make -j1 BOARD=arm-3.4 OPENWRT_EXTRA_BOARD_SUFFIX=_3.4 --> This command errors out:
--->  toolchain/install
--->  toolchain/sed/prepare
--->  toolchain/sed/compile
--->  toolchain/sed/install
--->  toolchain/utils/prepare
--->  toolchain/utils/compile
--->  toolchain/utils/install
--->  toolchain/kernel-headers/prepare
Build failed. Please re-run make with V=99 to see what's going on (or look at make-log)
Makefile:46: recipe for target 'kernel-headers-prepare' failed
make[2]: *** [kernel-headers-prepare] Error 1
Makefile:128: recipe for target 'toolchain/install' failed
make[1]: *** [toolchain/install] Error 2
Makefile:85: recipe for target 'world' failed
make: *** [world] Error 2

Output of make-log file: https://pastebin.com/b4ENPK8d

I have not investigated further at this point and it may well be that i need to install some other packages to get this working correctly.

Thats a good progress you've made @CM65!
I wait for my delivery (USB & MX65W) and try the same steps. The only thing I have found in the short time I was watching over your make-log, is a similar issue that has been fixed some years ago, but I don't know if that helps in any way.
This Log looks similar to yours: https://dev.archive.openwrt.org/ticket/8447.html
This was the fix: https://dev.archive.openwrt.org/changeset/24516.html
It almost seems like there is a path missing. If I will find time today, I will respond later for further analysis.