Cisco Meraki MX64/MX65 image support

I have never compiled myself, but looking over your log, I ask myself, why do you choose #14 -> UNSUPPORTED little-endian arm platform?
Do you know if its possible to upload a new Buildroot Config for BCM58? (Broadcom) I mean uploading the driver to the program.
Or did you try meraki elemental?

I did not choose any of the settings during the build phase these were provided by the .config file that i copied in this step:

  • cp config-arm-3.4 .config
    The next step referenced this file during the "make"

I am assuming that Meraki changed to this version at some point when updating the builds and never went back to name it correctly.

I'm glad to see there is still interest in flashing different firmware on these things. I got my hands on a Meraki MR18, MX64 and MS220-8P! Just flashed the MR18 using JTAG and am eager to do the same with the MX64!

I have updated the topic accordingly.

FYI - I have created the skeleton of a devicepage for the MX65:
https://openwrt.org/inbox/toh/meraki/meraki_mx65

Feel free to document the activities on adding OpenWrt support for MX64/MX65 there.

1 Like

Following the Z1 build guide I am looking to build an initramfs image that i can use on the MX65. Googling around I think i need to complete the following steps:

I need to work out the correct target for steps 2 and 3 below.

Looking at the BCM5862X-Series webpage ( listed in a previous post) it lists the processor as ARM® Cortex-A9

Looking at the makefile listings for BCM devices. I find the following:

bcm53xx - CPU_TYPE:=cortex-a9 - Build firmware images for Broadcom based BCM47xx/53xx routers with ARM CPU, not MIPS.

Looks promising however there is no config-default file user the generic folder. looks like i need to learn a bit more about targets and how they are defined.

  1. git clone "https://github.com/openwrt/openwrt.git "
  2. Edited the file “target/linux/bcm53xx/config-default to change the following. ”CONFIG_CMDLINE="console=ttyS0,115200 loglevel=7 root=/dev/ram0 rootfstype=ramfs board=Lima"
  3. Under “Target System”, choose “bcm53xx”, and under “Subtarget”, choose “Generic”
    Under “Target Profile”, I selected the “*devices LIMA” profile.
    Under “Target Images”, selected “ramdisk” (“lzma” compression) and de-selected “squashfs”.
  4. make -j2 V=s

My MX65 finally arrived.
Yesterday I tried to access via TTL, but unfortunately, I can't connect via Putty. It's not my first time I am trying to connect via COM-Port on a device, but this time something doesn't fit right.
I have an PL2303HX TTL. My MX65 boots up, but even after setting the Baudrate on 115200 (Windows Device-Manager & Putty), checking the jumper connection 5 times, I am unable to connect to COM3.
I need time to figure out where it stucks, or I need to buy the in the X1 documented TTL cable.
Wanted to upload a pictureto show you how I connected it and the image is smaller than 4096KB, but openwrt thinks its bigger -.- ...

Hey @CM65, apologize for the late reply. I have also gained root access on my unit. It is the MX65W; so the tutorial is compatible with this model also.

Do we know where the bootloader is stored as far as which SoC? This thing has a slew of them all over the place. I wouldn't mind taking a read off it though if we knew which one had it.

@g4njawizard I would double check your wiring. I hope you didn't accidentally connect that red cable to anything. Rip if you did. :frowning:

CM, going to follow your log and see if I can get to a comparable point and maybe actually somehow contribute to this build after all !

Thanks again for the hard work!

Hey @arcstar7
I checked my wiring multiple times. Seems that my TTL is bad china replica with bad driver support. (but bought in my country over ebay, but I checked that stick far 2 late so I couldn't send it back) The original driver from the manufacturer isn't working ... Windows Device Manager always had a warning on that port and told me it was deprecated and stuff like that. I only once tried it with the red cable, but it seems to still boot up, because the light is still flashing in rainbow colors. So I think its not bricked yet. ^^
Anyway, I ordered a new, but from china ... the locals here offer it way 2 expensive. I wait for it to come from china. :smiley:
But good to hear, that you have gained root access!! Hopefully I will be able to get my hands on that soon. My TTL is already shipping for 2 weeks now .. :confused:

Hmm, that is pretty strange. If you have wires and are comfortable soldering a few connections, you could just make your own serial connection and manually install a driver.


Keep in mind the max distance - 1.8M

Sorry for the spam but can I just attach the pictures to this thread for the wiki or do I need to manually put them in the page ?

@g4njawizard - I had the same issue here is the solution for me http://wp.brodzinski.net/hardware/fake-pl2303-how-to-install
basically use an older driver that does not check legitimacy.

@arcstar7 I think you have to manually put them in. I haven't checked the wiki, but maybe u can copy and paste the picture URL from this forum and paste it in the wiki. That should do the trick without uploading the Image a second time. But I don't know for how long pictures will be safed in the forum until they get deleted from the server.
@CM65 Thanks for the tipp! I might check that l8r. Hopefully it really works, because these errors are kinda annoying.

On my USB TTL I connect in the following way:

Set of 4 pins labeled J18

Square pin furthest from the on board USB socket (3.3v) DO NOT CONNECT to anything
Round Pin - connected to RX on my USB adapter
Round Pin - connected to TX on my USB adapter
Round pin (closest to USB socket) connected to Ground on my USB adapter

http://archive.openwrt.org/releases/packages-18.06/arm_cortex-a9/

This may help

So i now have an MX64 as well. However this one has the latest firmware updates applied so i could not use the 'odm help' trick to gain root access.

I did however manage to gain access to the broadcom recovery console (by holding the reset button during boot).

my other question is would this Busybox version allow TFTP access? looking through nvram output there is a default IP of 192.168.1.1 and the MR42 pages mentioned that this allows web browsing access on port 80 username blank password 'admin'. however i have not had time to test this yet

 Hit enter to continue...
BusyBox v1.7.2 (2015-03-26 20:02:08 PDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
help
Built-in commands:
-------------------
        . : [ [[ bg break cd chdir command continue echo eval exec exit
        export false fg hash help jobs kill local pwd read readonly return
        set shift source test times trap true type ulimit umask unset
        wait

and a dump of the nvram: https://pastebin.com/2DK94tkb

not sure if it helps or not.

My busybox version is 1.24.1, can confirm that TFTP access is present

Did you attempt to flash a compiled u-boot.bin? The ubootwrite.py method for loading it doesn't seem to work, but dd is available on the broadcom reference firmware so it may be possible to use this. The reference firmware also has usb storage support. I have u-boot compiled with tftp enabled however I am afraid to use dd in case I brick the device. I notice that mtd0 is 0xff padded. Can anyone advise how to safely attempt to do install the new u-boot?

Wow, great work. I'm still a noob at compiling uboot !

I really have no use for this device, if you think using dd is worth trying, I'm willing to take one for the team and if it bricks it, I'm not going to be too upset. As it stands, I barely have time to even catch up on the latest replies on here.

@clayface feel free to let me know if you think that could be useful in making progress further!

I have a spare of the MX64W devices available for experimenting if it will help.