Hi!

There's a really cool little Atheros AR2315 based WiFi router called the Meraki Mini (http://meraki.net/mini.html) built by an equally cool company called Meraki Networks (some of the guys behind MIT Roofnet). It's $49 each and runs a Linux 2.6 system. Since MIT Roofnet is based on OpenWRT AFAIK and the Meraki Mini is based on MIT Roofnet it wouldn't surprise me if it's OpenWRT based.

Since the source is available (http://www.meraki.net/linux) it might not be too hard to backport it into the buildroot system. I'm just beginning to learn about OpenWRT and might not be the right person, but perhaps somebody with experience working on AR231X support? How hard do you think this might be?

I have one with a serial USB interface laying around. If anybody wants to work on this and needs hardware just let me know!

Hi MrMesh,

Yeah, Meraki mini seems to be very interesting... I don’t know if OpenWRT is running on it but I would like to get such hardware, I would like to test it...

Do you have one?

Try a la fonera....very cheap and similar with 8mb of flash

Hi, GoldServe

According to your post,
http://forum.openwrt.org/viewtopic.php?id=7799
Firmware of La Foneras seems a fork of OpenWRT.
Is it possible to get the source code? I couldn't find it on FON's site.

According to the specs the Meraki has 8MB of Flash too.   Meraki also don't encrypt their firmware images and have already released some OpenWRT source and are encouraging 3rd party firmware development - they even sell a USB-serial interface cable for it.  So they seem a lot easier to work with than the La Fonera.  Also, the Meraki has some Power-Over-Ethernet capability, which in my opinion is the clincher in favour of the Meraki.

On closer inspection of this source:
http://www.meraki.net/linux/openwrt-meraki.tar.gz
It appears to be based on the Kamikaze-before-BRNG branch.  What is involved in porting it to buildroot-ng?

have tryed to build from miraki openwrt kitt.
fails.
http://pastebin.ca/266704
seems to be a problem with tar 1.15. went back to 1.13.25 fixes!

(Last edited by xtcfrk on 4 Dec 2006, 14:28)

I have four Meraki Minis plus the USB cable and am ready to play

I see someone has started a page at http://wiki.openwrt.org/OpenWrtDocs/Har … eraki/Mini - so I've added some notes as I go along.

I built the current version of their released source tarball:

openwrt-meraki.tar.gz   30-Nov-2006 12:11
size: 63072791
md5sum: da71bbdd97b33bbf7dbb17c819a6c636

under ubuntu-6.06 (with tar version 1.15.1-2ubuntu2.1). I didn't see the problem with tar mentioned above. However I did find that the compile aborted at various stages unless I installed the 'flex', 'sharutils' and 'gawk' packages first.

Unfortunately, the image I generated and wrote to flash caused the unit to go into an infinite crash and reboot loop, so I ended up learning rather more about flash recovery than I had intended! Details of the crash are on that wiki page.

I thought that perhaps the aborted builds had not recovered properly after I installed the missing flex/sharutils/gawk, so I rm -rf'd the directory and rebuilt the whole lot from scratch. My original upgrade.sh was 2637828 bytes, afterwards it was 2637830 bytes. Unfortunately this new image still crashes in the same way.

I probably would be happy enough with the original Meraki firmware, except that my application is for a client bridge which must use WPA-PSK.

Regards, Brian.

Poking around the source code, I think there's a lot of backporting work to do. I had a look at madwifi, since that's where the kernel is currently panicing for me.

In the Meraki tarball, the file madwifi-ng/SNAPSHOT suggests that the original madwifi codebase they forked from was SVN r1486, dated 2006-03-28. The $Id$ strings agree with this, as the highest one I can find is 1485 (madwifi-ng/net80211/ieee80211_wireless.c)

However, taking a diff between madwifi SVN r1486 and the Meraki tarball shows a large number of differences. One big change is that madwifi r1486 has HAL version 0.9.16.16, whereas the tarball contains HAL version 0.9.17.2 (which was introduced in r1631 at 2006-06-07, and superceded in r1711 at 2006-09-06). System-on-chip stuff has also been added - hal/ah_soc.h.

Now, the current madwifi release, 0.9.2.1, also contains HAL 0.9.17.2 and an identical hal/ah_soc.h. So I think they have backported a lot of stuff into their old snapshot base.

However a diff between Meraki and madwifi-0.9.2.1 and also shows a lot of differences across many files. So maybe a three-way diff is needed, between r1486, Meraki and release 0.9.2.1, to try to distinguish what they added from what they backported

Some of the changes they made are obvious and trivial, e.g. probing for the hardware at a different address in ath/if_ath_ahb.c. However there are a lot of additions, some presumably to support Meraki's mesh networking operation, but it's not clear to me which are needed (if any) in OpenWrt. Some seem to be allowing multiple device parameters to be passed to ath_hal_attach, maybe to support multiple ath instances?

I suppose one approach would be to start with madwifi release 0.9.2.1 and try to add the minimum set of changes to make it work on Meraki.

But that's just one component. A similar set of work has to be done for the kernel, and also between old buildroot-ng and their tarball. Again, maybe the right approach is to start with vanilla OpenWrt and try to make the minimum set of changes to make it work. That includes being able to generate runnable flash images for the Meraki. However my level of experience in the internals of OpenWrt, Madwifi, the Linux kernel, Atheros chipsets and RedBoot would make that an extremely hard job for me

On top of this the flash filesystems and partitioning need making OpenWrt-compatible. The current Meraki arrangement has two read-only firmware partitions each 3.25MB, and a 1MB data partition mounted on /storage. To work in the OpenWrt way we need at least a writeable /etc for configs, and somewhere to install ipkgs. Maybe the first firmware partition can become squashfs, the second can be jffs2, and they are union mounted. But again working on that is well outside my experience.

But although there may be a lot of work to do, the Meraki Mini is a very desirable target for a proper OpenWrt port. It's small, cheap, runs off a wide range of DC voltages, and (if their business model holds) may be something we can have an assured supply of for several years, rather than having to cope with the almost weekly rate at which consumer access points change.

Regards,

Brian.

   
Linux version 2.6.16.16-meraki-mini (root@bart) (gcc version 3.4.6) #9 Fri Dec 1
5 04:40:07 CST 2006
CPU revision is: 00019064
Determined physical RAM map:
memory: 02000000 @ 00000000 (usable)
User-defined physical RAM map:
memory: 01000000 @ 00000000 (usable)
Built 1 zonelists
Kernel command line: mem=16M console=ttyS0,9600 rootfstype=squashfs,jffs2
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB, 4-way, linesize 16 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 128 (order: 7, 2048 bytes)
Using 92.000 MHz high precision timer.
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 13184k/16384k available (2124k kernel code, 3200k reserved, 395k data, 1
32k init, 0k highmem)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
unpacking initramfs....done
NET: Registered protocol family 16
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
watchdog hb: 90  ISR: 0x21  IMR: 0x8  WD : 0xabc9a6f5  WDC: 0x0
ar2315_wdt_init using heartbeat 90 s cycles 3600000000
watchdog hb: 90  ISR: 0x21  IMR: 0x88  WD : 0xd65830f5  WDC: 0x0
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0xb1100003 (irq = 37) is a 16550A
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
setting one ethernet device to null...
MTD driver for SPI flash.
spiflash: Probing for Serial flash ...
spiflash: Found SPI serial Flash.
8388608: size
cmdlinepart partition parsing not available
Searching for RedBoot partition table in spiflash at offset 0x7d0000
No RedBoot partition table detected in spiflash
Creating 7 MTD partitions on "spiflash":
0x00000000-0x00030000 : "RedBoot"
0x00030000-0x00050000 : "stage2"
0x00050000-0x00150000 : "/storage"
0x00150000-0x00490000 : "part1"
0x00490000-0x007d0000 : "part2"
0x007d0000-0x007e0000 : "redboot config"
0x007e0000-0x00800000 : "board config"
oprofile: using timer interrupt.
NET: Registered protocol family 2
IP route cache hash table entries: 256 (order: -2, 1024 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
ip_conntrack version 2.4 (128 buckets, 1024 max) - 232 bytes per conntrack
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
ip_tables: (C) 2000-2006 Netfilter Core Team
ClusterIP Version 0.8 loaded successfully
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "<NULL>" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

this is a fonera with meraki firm. some more changes have to be done to get it completly up...

special thanks to billbong and kevin`

(Last edited by heini on 15 Dec 2006, 20:47)

One of the questions all of this raises is: If someone checks out some or all of the OpenWRT SVN, modifies it, then releases it as a tarball, can it really be said to be OpenWRT?  The Meraki developers may not have intended to create a fork  but developing support for other platforms takes time - in that time the SVN can change radically - which is what has happened.  The Meraki developers (for whatever reason) felt they needed to work outside the SVN to make the changes they needed to make.  But now that their tarball isn't very compatible with SVN OpenWRT it's almost useless because of the amount of work needed to fold it into the current build system.  This is a great shame.  Surely there's a way to allow hardware manufacturers to make their own modifications to the OpenWRT code to suit their hardware, without them falling behind the cutting edge.

And accidently in the same time they forget to mention anything about OpenWrt Anyways, 2.6 support for the AR2315 based stuff will be ready soon, followed by later with support for the other Atheros SoCs.

Well I agree it would be nice to keep contributions inline with the main tree, but I can also understand why this hasn't happened from the developers' point of view. OpenWrt Kamikaze is such a fast-moving target (especially over the last 6 months or so, where Kamikaze itself has forked into buildroot-ng and then marged back in) that it's very difficult to track. The only way to keep up is to get your changes committed the moment you make them - but even then, it's very difficult to support your own work if someone else keeps pulling the rug out from under you.

What Meraki needs is a stable build environment for their product, and OpenWrt hasn't provided that over the last year - although hopefully it will get better once there is a 2.0 release. WhiteRussian probably wasn't much use for them either, given it used a 2.4 kernel.

What would have been useful, though, is if they had said which version of buildroot-ng they had forked from (so at least we could work out what they changed). We can try infer this from the Id strings in the files themselves: looking in the openwrt subdirectory of their tarball, the latest revision I see is 3586 in openwrt/package/iptables/Makefile. That implies a fork at 2006-04-02, which sounds about right.

OTOH, Meraki made life much harder for us by dumping a whole kernel and madwifi into the root of their tarball, instead of following The OpenWrt Way of applying patches via Makefiles. We'll have to work out what differences are patches already in the trunk, and which are Meraki's.

However, for the main operwrt tree (comparing r3586 to Meraki), and ignoring the stuff they added at the top level (base, base-files, kernel and madwifi-ng), the changeset isn't as big as I thought it would be. What I can see from diff:

Kernel/hardware

* They added config-ar531x, config-brcm and config-x86 at the top level; added BR2_LINUX_2_6_BRCM, BR2_LINUX_2_6_X86 and BR2_LINUX_2_6_AR531X to rules.mk; and BR2_LINUX_2_6_AR531X to target/Config.in
* They added an x86_image target in the top-level Makefile
* Took out target/linux/ar531x-2.4/ and replaced with target/linux/ar531x-2.6, and corresponding change in openwrt/target/linux/Makefile
* target/linux/brcm-2.6/config has a bunch of changes, including CONFIG_LOCALVERSION="-meraki-mini", CONFIG_BSD_PROCESS_ACCT=y, CONFIG_KALLSYMS=y, CONFIG_ELF_CORE=y, CONFIG_SLAB=y, # CONFIG_SLOB is not set, CONFIG_MODULE_FORCE_UNLOAD=y, CONFIG_LBD=y and lots more
* target/linux/x86-2.4/config set CONFIG_NATSEMI=y
* target/linux/x86-2.6/config made a bunch of changes
* target/linux/brcm-2.6/Makefile and target/linux/x86-2.6/Makefile emasculated
* added target/linux/image/ar531x/devices-to-rootlist.txt, target/linux/image/ar531x/Makefile
* minor mods to target/linux/image/Makefile to create package dir and exclude .svn files
* change to unpacking in target/linux/kernel.mk

Config files

* They added a name_build script at the top level
* They removed trunk/package/base-files/default/ entirely
* Hacked about with package/base-files/files/brcm-2.6/ to set appropriate default interface names

Packages

* They enabled a bunch of tools in busybox (e.g. ext2fs tools) but bumped the version down from 1.1.1 to 1.1.0, and changed some patches (could do with closer investigation)
* Some frigs to package/iptables/Makefile, and changes to iptables patches (could do with closer investigation)
* They *removed* roofnet from package/click/Config.in, and upgraded click from cvs.2006.03.02 to cvs.2006.04.30
* They added ruby to package/Config.in and added package/ruby [if OpenWrt doesn't have this yet, we want it Ruby is much smaller than perl but more complete and much nicer to program in]
* They added "wpa_supplicant-compile: base-files-compile" to package/depend.mk
* They removed package/dropbear/files/S50dropbear, and changed /etc/dropbear to /storage/dropbear
* Stop package/lighttpd installing config files
* Added package/meraki-private to openwrt/package/Makefile, although they did not include package/meraki-private itself in the tarball
* A couple of patches to microperl
* Set CONFIG_DRIVER_BROADCOM=n in wpa_supplicant, and a change to the makefile to point to their hacked madwifi-ng instead of the one in the openwrt tree
* change to target/linux/package/madwifi/Config.in, and added ath_ahb to package/madwifi/files/madwifi.modules, and some changes to target/linux/package/madwifi/Makefile (not sure why, since they included their own madwifi-ng source anyway)

Miscellaneous

* swapped around the install: dependencies in target/Makefile
* changed the download URLs in toolchain/binutils/Makefile and toolchain/kernel-headers/Makefile to point to their local mirror

I doubt any of this is critical. We just need to make a new target in The OpenWrt Way for the new trunk. Hardest bit will be deciding how we want to use the flash. (e.g. this is serial flash - does this imply it's very slow, and so we should run the root filesystem from ramdisk?)

Well, they did release the source as openwrt-meraki.tar.gz

Nah, it's not that slow, except the initila boot process.. Anyways, don't spend too much time on this people, as you could be feel sorry for it a week later

I saw the comment on Ticket #12:

Has anybody tried running this on the Meraki Mini? Any special instructions?

Thanx for any help!

Our code runs well on the Meraki Mini. Try it

I would happily try it, if someone will post some specific installation instructions for the Meraki. That is, once I've built an image, what do I do with it? Does it run with the existing Meraki flash partitioning, or does the flash need to be repartitioned? If so, in what way? Do the kernel and the root filesystem go into separate partitions? Which ones?

I wrote up some notes on the existing Meraki firmware and Redboot partitioning at http://wiki.openwrt.org/OpenWrtDocs/Har … eraki/Mini but I need a few more clues in order to try OpenWrt on it.

Thanks, Brian.

Second that. I'd love to run it but I get stuck in the same place. Don't know what to do with the files in bin/ (openwrt-atheros-2.6-root.jffs2-128k openwrt-atheros-2.6-vmlinux.gz packages/ openwrt-atheros-2.6-root.jffs2-64k openwrt-atheros-2.6-vmlinux.elf and openwrt-atheros-2.6-vmlinux.lzma). Sorry for beeing such a noob and thanx in advance!

I've reorganised the Wiki page a bit to allow the info to be slotted in.

I'd expect to use the 64k JFFS2 root image (dmesg says erasesize 00010000).

So questions I have are:
* Do we use Meraki's stage2 loader, which has hardcoded knowledge of the location of part1 and part2 and performs CRC checks and LZMA decompression, or ignore it and boot the kernel directly from RedBoot?
* Do we use gz or lzma kernel?
* How do we tell Redboot which partition contains the kernel, and how to tell the kernel which partition contains the root FS, without using serial console? (We could replace the redconf partition, which is sourced from redconf.bin in the Meraki source, but I can't see a tool for creating redconf.bin)

B.

Well I've done some playing, by reading RedBoot docs and some info on the Fonera, and couldn't make it work. I have documented what I tried.

Most fundamentally, I've not been able to load a kernel via tftp and boot it:

RedBoot> load -r -v -d -b 0x80041000 -m tftp -h 192.168.84.9 openwrt-atheros-2.6-vmlinux.gz
\
Raw file loaded 0x80041000-0x8028e085, assumed entry at 0x80041000
RedBoot> exec -c "console=ttyS0,115200"
Now booting linux kernel:
 Base address 0x80030000 Entry 0x80041000
 Cmdline : console=ttyS0,115200

At this point it dies. If I can get past this bit, then putting it into flash should be straightforward.

(Last edited by candlerb on 3 Jan 2007, 12:38)

I've now done some reverse-engineering of Meraki's stage2 boot loader, and documented how to calculate and prepend the 8-byte header it needs. However my kernel still doesn't report anything.

RedBoot> fis load stage2
RedBoot> exec -c "console=ttyS0,115200" -w 2
Now booting linux kernel:
 Base address 0x80030000 Entry 0x80100000
 Cmdline : console=ttyS0,115200
About to start execution at 0x80100000 - abort with ^C within 2 seconds
starting stage2
reading flash at 0xa8150000 - 0xa8200000... done
Calculating CRC... 0xf32c0ed3 - matches
decompressing... done
starting linux

I did wonder whether perhaps it wasn't trying to send anything over the serial port - my attempts to pass console=ttyS0,115200 don't seem to help though.

I would imagine the Meraki flashing procedure would be almost identical to what is described here. http://www.dd-wrt.com/phpBB2/viewtopic. … mp;start=0

Note I said almost, which means this is just a guess.

The Meraki Mini is not the Fonera, even if they have the same chipset.

I've listed *exactly* what I have tried at http://wiki.openwrt.org/OpenWrtDocs/Har … eraki/Mini - along with transcripts of the results. I've tried to use as much info out of the Fon wiki page as seems relevant. However I've been unable to get the OpenWrt kernel to start at all.

So if you or anyone else has a specific suggestion as to what else to try, I'll try it. Alternatively, if someone has *actually* run OpenWrt on a Meraki Mini - not a Fonera or something "similar", but a real Meraki Mini - then I'd also like to hear exactly what they did. However, at the moment I have seen no evidence of OpenWrt running on a Meraki Mini at all, apart from nbd's tantalising comment above.

BTW I built OpenWrt using all defaults, apart from selecting atheros-2.6 as the target, and enabling the building of wpa-supplicant.

I run openwrt on a meraki mini. the only real thing you have to worry about for nbd's kernel is the serial rate is set to 9600 - change the kernel, change redboot, or switch really fast, your choice

the command line is hardcoded into the kernel code, search for it and you'll find it fairly easily. I just removed that line from the code and set the default kernel command line in the configuration, as that's easier to change for me

don't follow the fon instructions for flashing it without a serial port. please.  the fis directory and redboot config are in a different place, so you'd likely just break things. you don't need to do that anyway, because the meraki DOES have an ip address by default, and will accept a telnet connection to redboot if your quick

the kernel partition name doesn't matter, as long as the redboot script loads it.
the root partition should be called rootfs. this is hardcoded into the openwrt kernel

use a gzip kernel, as the meraki redboot doesn't support lzma. i've been meaning to hack around with meraki's stage2 to load lzma kernels, as it's faster.

(Last edited by Kevin on 3 Jan 2007, 17:45)