I've read the current docs on how to install Kamikaze on the Meraki.  These docs represent the result of a lot of great work by candlerb and others.  But me being fairly time-poor, and wanting to deploy Merakis in a largish community network (Melbourne Wireless), I would like to be able to install OpenWRT using a method as easy as with the WRT54G - i.e. by uploading a single binary file that "just works" as is.

It'd be nice to just SSH in to the Meraki vendor firmware, upload a single file, and issue "mtd -r write openwrt.bin linux"

As far as I can see, things that prevent this are:
* Meraki's Redboot can't load LZMA kernels
* There seems to be no Linux tool to label/remap flash partitions - this has to be done in Redboot
* Meraki's stage2 loader doesn't read the flash to get the partition boundaires - they are hard-coded in
* Meraki's stage2 loader wants a silly CRC checksum added to the Kernel

From http://forum.openwrt.org/viewtopic.php?id=7189&p=2

This is good news and when complete the new loader should take some steps out of the process.  I hope the new loader will not require the CRC-prefixed kernel, and will read the flash map at boot time.

Once complete, I hope the OpenWRT kernel, filesystem and new stage2 loader can be compiled into a single image that can be flashed from the Meraki vendor SSH command-line.

When this happens OpenWRT will be ready for prime-time on the Meraki.  I'm writing this because I'm an impatient bastard.

Given someone can donate a meraki mini to me, I can try to compile redboot with lzma support and add it to the meraki. Could be made almost identical to the fon router.

That's cool - I would make such a donation if I could be sure that the resulting code would be integrated into Kamikaze Trunk.  To do so it would need comply with the OpenWRT developers Policy.  I don't know for sure, but I believe that the Developers prefer to use the vendor's bootloader on all routers.  Overwriting the bootloader is very risky because if there is any problem then JTAG is the only way to fix it.  Because not all routers have JTAG headers, and not everyone who uses OpenWRT knows how use JTAG, the I believe the developers would prefer to keep the original bootloader as a safety precaution.

Because Meraki's RedBoot bootloader can't handle LZMA, and because it boots a stage 2 loader by default, writing a new stage 2 loader would be a better idea I think - which nbd has said he wants to do.  An OpenWRT image that contains a stage 2 loader can be booted without any need to change RedBoot settings, making the process of installing OpenWRT easier.  We want to eliminate the number of steps it takes to get OpenWRT onto the Meraki.  But would an OpenWRT image containing a stage2 loader also work on the Fonera?

The RedBoots on the Fonera and the Meraki have different default behaviours.  The former loads a linux kernel, the latter loads a stage 2 loader.  We don't want to have to reconfigure Redboot on either of them, but we'd like them both to load the same OpenWRT image.  Can this be done?  Or does something have to give?  Do we need to overwrite Redboot on both of them so they both behave the same?  Or do we produce different Kamikaze atheros-2.6 images, specific to the Fonera and the Meraki?

The Developers have a very good track record at sorting out these issues, so I await their (or anyone else's) solution with baited breath.

they both behave the same except for lzma support on fon, and obviously the programmed commads for loading things. no reason a loader would not work on the fonera

The both essentially the same. I do hope one day, the developers can write a new 2nd stage loader but for anyone that is eager to hack the meraki in the meanwhile, my offer still stands. I've flashed my fonera redboot loader to add 32mb support and i've done it a few times. Definitely for someone who knows what they are doing!

Yes, they both have Redboot, but the problem is their vendor default behaviour.  I want to be able to load OpenWRT on Meraki and Fonera without having to touch Redboot on either router.  I want to eliminate the step of having to get into Redboot to change it's programmed boot sequence.  I want to make it as easy as possible to load OpenWRT onto the Meraki for a non-hacker user.

What I'm hoping is that you don't need to get into Redboot to rename and alter partition sizes - I'm hoping you can get into the vendor firmware via SSH and use the "mtd" or "dd" commands to overwrite the existing stage2 loader, kernel and rootfs with a single image that contains a new stage2 loader, kernel and rootfs, with appropriate partition names.

To do this we have to take the default behaviour of Redboot into account - on the Fonera it loads the LZMA kernel, on Meraki it loads the stage2 loader.  If we compile an image that contains a stage2 loader + LZMA kernel + rootfs, can we make it work on the Meraki and the Fonera? 

How about we create an OpenWRT image containing partitions named thusly:
stage2
vmlinux.bin.l7
rootfs

The Meraki Redboot will load stage2 by default.  If nbd completes his new stage2 loader he could make it do whatever he wants - including reading the flash map so we can have different-sized kernel and rootfs partitions.  The stage2 loader can then be made to load the vmlinux.bin.l7, which we then point at our SquashFS rootfs partition - OpenWRT Kamikaze.

The Fonera Redboot ignores the stage2 loader and simply loads our vmlinux.bin.l7, which points at rootfs.

This plan works for the Meraki and for the Fonera.  But what about other atheros-2.6 routers?  It probably won't work because they will have yet another different Redboot config.  RedBoot is fantastically configurable, but this creates problems - each vendor will include a custom-configured version with their router.  You don't get this problem with CFE or PMON - the versions shipped with routers all seemed to behave the same way and it is rarely necessary to reconfigure them.

I think your making things too complicated for yourself.
however, that would indeed work. slightly different commands would be needed from ssh to flash the images (you wouldn't flash stage2 on fon, probably different mtd numbers, etc)
plus, if you don't go into redboot, you are stuck with the default flash layout, which is not ideal on the fon (but OK for most uses), and DEFINITELY not ideal on the meraki.
make it easier for yourself and hook up a serial console to each unit, run a few scripted commands, and be done

I'd like to not have to use the serial console.  I am trying to make it so it is as easy to flash a Meraki as it is a WRT54G.  I want to be able to distribute a firmware through the Melbourne Wireless website, and let anyone download it and install it themselves.  I'd like to not have to do the installations myself.  I am sure there are others in the same situation.

As candlerb mentioned, it would be nice if there was a Linux tool to rename and remap flash partitions.  Or it would be nice if we could change the Redboot config from outside Redboot - i.e. from the Linux command-line.

if you make a configuration in advance you wanted to use on multiple machines, you COULD update it from linux, by using mtd to write the redboot config area. this is actually pretty easy to do since the default firmware is set up to allow it (copy the config area from a device with the desired setup)

do not change the "board config" partition. all that has is mac address, serial number, radio configuration, etc

thanks Kevin, that's useful info.

If we are using a stage2 loader, do we really need to update the flash map in Redboot?  So long as our new stage2 loader fits in the same partition as the vendor (Meraki) stage2, could our new stage2 work out for itself where the new partition boundaries are?  Is there a problem if we overwrite the part1, part2 and /storage partitions and don't tell Redboot about it?

I'm thinking that when we change the flash map we aren't actually doing anything to the flash partition boundaries themselves, we are just creating a list of start and end addresses in the "redboot conf" partition for use by Redboot.  If the actual boundaries are different to what Redboot thinks they are, is this a big issue? - Redboot only needs to know where stage2 is.

I don't know this, I'm just guessing - tell me if I'm wrong.

you could have data wherever you want on the chip, but linux uses the redboot informtion to determine the partition layout, unless you include a static mapping or use some other method. redboot itself will not complain about the data unless you overwrite redboot (well it wouldn't complain then either, would it..) or the redboot/fis config or board config

you could use the original stage2 loader only if the kernel image is in the proper position (part1, part2 for backup image if wanted, but part2 is better used as storage in this case), and has the proper header added.

Has anyone had any luck with this?
Having these features would make the Meraki much more attractive for community wireless use.

Hi sk2, I'm starting to think that the easier option is to do a similar thing to what Sven-Ola has done with the Fonera - leave the vendor firmware on the device and simply ssh into it and install OLSR and other packages.  The meraki firmware supports OpenWRT packages (I think) - it should since it is forked from OpenWRT.  Sven-Ola's Fonera repository is here:
http://olsrexperiment.de/sven-ola/fonera/
I think I will experiment with installing some of these packages on a Meraki when I get the chance.

I would prefer to use current OpenWRT - but if it becomes too hard to quickly install, I will use an easier method to achieve the results I'm after.

After mucking around for the past day with my new Meraki mini, I've learned some pretty good tricks for easing the flashing and reflashing of OpenWRT.

The Wiki greatly over complicates things.  It is quite easy to automate the flashing via the ethernet port without using a serial cable.  The biggest trick is interupting Redboot when you telnet into it.  As I found out the hard way telnet on my SuSE machine never sends the Ctrl-C.  There are several great solutions to automating this on the NSLU2-linux site: http://www.nslu2-linux.org/wiki/HowTo/TelnetIntoRedBoot  I've been using the netcat method and it never misses.   Just remember that for the Meraki you need your machine set to 192.168.84.9 and the Meraki is at 192.168.84.1.

Forget keeping the Meraki partitioning.  It's a mess.  I wanted to use a squashfs partition with a jffs overlay like on broadcom routers, so here's what I did:

fis init
load -r -b 0x80041000 -m tftp -h 192.168.84.9 openwrt-atheros-2.6-vmlinux.gz
fis create -r 0x80041000 -l 0x200000 -e 0x80041000 linux
load -r -b 0x80041000 -m tftp -h 192.168.84.9 openwrt-atheros-2.6-root.squashfs
fis create -r 0x80041000 -l 0x650000 -e 0x80041000 rootfs

Then I ran fconfig and changed the boot script to:

fis load -d linux
exec

Be patient.  The flash on these things are very slow to write and you will see many AHB errors.  Redboot quits talking to telnet whenever a fis command is running.  Any network activity at these times creates these errors.  Just ignore them.  When the write operation is complete you will see telnet come back to life.   Don't be fooled that something is wrong when you enter the fis create commands.  You will see nothing back from Redboot until the command completes. 

Some explantion of this flashing method:
The first partion created for the kernel is approximately 1.5mb.  You only need about 1mb, but I left extra room so I can upgrade for the forseeable life of these without ever getting into redboot again.  Ideally I want to automate upgrades while these things are running in the field so reconnecting to the ethernet port is out of the question.

The second partition is allocated the rest of the free space and the squashfs image fills just the beginning.  Once OpenWRT boots for the first time it will create a jffs partition in any remaining space not taken by the squashfs partition and mount it in the typical overlay fashion. 

Now for upgrading OpenWRT all you have to do is scp the kernel and new squashfs image to the /tmp directory and run the following command:

mtd -e linux write openwrt-atheros-2.6-vmlinux.gz linux;mtd -e rootfs -r write openwrt-atheros-2.6-root.squashfs rootfs

Again be very patient as the flash is much slower than on any other hardware that I've run OpenWRT.

Thanks lschweiss, that's really handy info - I will try it as soon as I can!

After flashing one Meraki using your instructions, how easy do you think it would be to copy the RedBoot config to another Meraki, along with a new OpenWRT Kernel and root filesystem?

This is what I have in mind:

backup the "redboot config" partition (using dd) from a Meraki that has had OpenWRT installed on it as per lschweiss' instructions

Log in via SSH to another (virgin) Meraki that still has the Vendor firmware on it

scp the "redboot config" partition image from the first Meraki to the new Meraki

scp new OpenWRT kernel and filesystem images to the new Meraki

install the redboot image from the first Meraki to the new Meraki (using mtd or dd)

install the OpenWRT kernel and filesystem on the new Meraki (using dd as mtd won't know about the new parition names or boundaries)

reboot the meraki

upon reboot, the new meraki should read the new redboot config partition which will contain the correct partition names and boundaries for "rootfs" and "linux" - which will then pass these on to the new kernel.

This method allows OpenWRT to be installed, the partition boundaries to be changed and the reboot boot sequence to be changed without having to get into RedBoot (after doing it once on the first Meraki).

Can anyone see anything wrong with this plan?  (Other than it being a bit risky)

Sorry, but I think your plan is flawed.  The Redboot partition will be read only from the Meraki firmware.  However, I may be wrong on this; using dd instead of mtd may be a way around this.  I'll let you risk your Meraki. Let us know how it goes.

The other problem I see, is how you get to she into the Meraki.  On mine in order to ssh in, it had to first register with the Meraki network.  Is there another way?

I've been working on an automation script for flashing the Meraki's with OpenWRT.  It wouldn't be any different flashing a virgin image or a backup image of OpenWRT.  In fact that is my intention of the script so I can quickly rebuild and replace any Meraki that I put in the field.  I will post the script here or on the wiki when I am done with it.

Consider myself warned!   After playing with it I see I'll need to copy the "FIS Directory" partition too, which doesn't seem to show under "cat /proc/mtd" in the vendor firmware - but seems to exist after playing with the fis command under redboot.

What I did was boot the Meraki up and wait a couple of minutes.  It seems that at first it wants to pick up an address via DHCP.  Then if it doesn't get an address it assigns itself 10.128.128.128 and starts it's own DHCP server.  You can SSH into it on this address.  Keep in mind that I hadn't connected it to the internet or registered it.  Registering the meraki or connecting it to the net (it phones home and updates itself), may change this.

That'd be really cool.  Following your instructions today I successfully flashed the latest kamikaze snapshot to my Meraki and it works.

I want to make it as easy as possible for end-users to install OpenWRT onto their merakis.   The current methods involving serial cables or tftp servers and special IP addresses make this hard.

One other thing I should mention.  While following lschweiss' instructions, I found that RedBoot wouldn't let me create the "rootfs" partition with a length of 0x650000 bytes.  I did an 'fis free' command after creating the "linux" partition and saw that I only had 0x5A0000 bytes free (using a hex calculator to subtract the start address from the end address.

So the last line of the create command for me went like this:

You are correct.  It looks like I crossed a couple of my notes I made during creating this procedure.  I later reduced the kernel space to approximately 1.5 MB from the 2.0 MB that I explained earlier.  Since the current kernel is a little under 1.0 MB, I decided 50% growth room should be plenty.  This makes the flash procedure:

fis init
load -r -b 0x80041000 -m tftp -h 192.168.84.9 openwrt-atheros-2.6-vmlinux.gz
fis create -r 0x80041000 -l 0x150000 -e 0x80041000 linux
load -r -b 0x80041000 -m tftp -h 192.168.84.9 openwrt-atheros-2.6-root.squashfs
fis create -r 0x80041000 -l 0x650000 rootfs

Also note you don't need the entry point on the rootfs partition.

lschweiss, I've put your info in the wiki

I'm a software engineer, but I'm not smarter than a 5th grader. 

This is hex not decimal.  If I wanted 1.5 MB  for the kernel the length should have been 0x180000, making the length on rootfs 0x620000.

Thank you!   I updated the wiki with the correct hex math.

I've tried to do some scripting to further automate the installation of OpenWRT on the Meraki.  I've been using PuTTy's Plink under windows but I can't get it to pass any commands to RedBoot.  I think we need a more interactive, scriptable telnet client that can react to prompts from the host.

netcat(or console telnet)+expect might do what you need

I've downloaded a WinNT version of Expect and it comes with a console telnet (Vista doesn't anymore), so I've got some reading to do.  If anyone's got any experience with Expect I'd appreciate some assistance!