And to clarify, the extent of the "rewrite" was changing the function calls to be sh compatible instead of using bash syntax.
EDIT:
Basically remove the word "function" from the function definition.
so
function foo()
{
}
becomes
foo()
{
}
Make sense?
Do you still have the updated dump-patched.dat with the corrected shell scripts in there?
If so, are you willing to share or should I just get busy and fix it up myself?
No, I flashed the one from the git repo, then using the serial console and vi I edited the scripts on the switch directly. It was real annoying, but I was too lazy to rebuild the dat file. Sorry about that 
Thanks for the info on the file transfer scripts, I managed to make a little progress this evening.
I extracted kexec with binwalk and got the transfer up and running but I'm unsure how to stop the script once the file transfer is complete, should the job terminate itself or am I missing some basic info here? I'm unable to interact with busybox once the transfer completes as the script is still running on the switch, whilst on the PC I'm being told the file transfer is done.
It should print . . . . while it's transferring, and once it's done, it should quit on it's own.
I didn't realize that I needed to disconnect from the serial console after starting the recv script on the switch.
so start the recv script, disconnect the terminal, start the send script, and wait forever...
The kexec extract was 242KB for the one that worked, the one from stage 1 was only 111kb, and definitely did not work.
Edit: apparently stage1 is the proper 242kb file? Check them both it should be 242kb and not 111kb.
I notice that Leo's page (https://leo.leung.xyz/wiki/Meraki_MS220-8P) has been updated with the following details:
Lukas Schauer improved my script above by adding IPv6, VLAN and LLDP support and more and can be found at https://gist.github.com/lukas2511/0f4199b56f248775119eba3378c857bf
My programming clip has also just arrived so i am going to follow Leo's rooting guide in the next few days and will report back on my success
hey @herbert,
I am following Leo's guide but I am a little stuck, i have modified the transfer scripts removing the function word and changing the shebang to #!/bin/sh. I can start the script on the switch and then kill the screen session CTRL + a, k. However when i send the file from the PC I get:
Sending file .......... (Note i don't get ssss or xxxx as @t4thfavor mentioned in his previous post)
I have tried a lot of different combinations but I never get the file onto the switch.
If i log back into the switch i get the word FAIL appear. This suggest looking at the code that the Hash transferred ok but not the file i.e hash vs file does not match.
Anyone have any ideas?
On the switch type "sh sw_recv.sh kexec" and once it's running, close the console connection.
On your pc type "bash util_xfer.sh kexec" and the ... should start, is this not what you're seeing?
Does your USB adaptor have separate tx and rx LED's?
I seem to remember putty doing a much better job of getting the files over than any other terminal emulator.
Let us know how you get along.
Thanks @herbert my error was on the switch side I was not giving the sw_recv.sh file a destination to write to.
I have copied both kexec and firmware.bin to the switch however my kexec is only 111KB. Can someone tell me where you managed to grab the 242KB from? I have checked the original stage 2 firmware and Leo's modified version both are 111KB. @t4thfavor can you remember?
It's OK I figured it out after a bit of searching. The 242KB kexec file is located in the stage 1 dump and not stage 2. I now have a working switch with VLANS 
I have another switch to do as well so will try to document step by step as I go.
So I haven't touched the switch in quite some time. It's just been working fine, so no need. Today I unplugged it to move some stuff around on the shelf, and it seems to have lost it's mind.
It thinks it's IP address (from serial term) is 1.1.2.2, and does not pass any other traffic. I'm wondering if it somehow talked to Meraki and got bricked.
Now I have to re-read through all this thread to figure out how to do the initial configuration again
It's bricked. I can boot to a root shell over serial, but no amount of loading init.sh scripts will make it work again. Any reference to my original config are in some odd CSV looking json file. I'll shelve it until someone gets a full firmware loaded (Never??). In the mean time I've acquired an actual Cisco 10 port POE managed switch .
Sooo does this look a little "familiar"?
Perhaps we can get some clues from this device with the ubiquiti firmware?
You can get the source code for the 8-Port UniFi switch from UBNT, and it's based on the Broadcom 5334: https://www.broadcom.com/products/ethernet-connectivity/switching/strataconnect/bcm5334x
444314 0x6C79A uImage header, header size: 64 bytes, header CRC: 0x787FDAEF, created: 2020-01-11 23:41:25, image size: 15027520 bytes, Data Address: 0x18000, Entry Point: 0x18000, data CRC: 0xE263E496, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Ubiquiti 4.0.80.10875"
This is a completely different SoC and is not comparable to the MIPS/Vitesse based MS220 series.
It is possible to compile 3.18.123 ("stage2" kernel) from the Meraki GPL archive and boot it from NOR with a modified bootloader. I decided to use squashfs to store a stripped down version of Meraki's "stage2" firmware including kernel modules.
This firmware is alpha quality; a proof of concept to show that it is possible to boot the switch entirely from NOR, without needing to transfer kexec over uart or modify the contents of NAND flash. It is not suitable for daily use, as the init scripts are broken, the kernel modules don't load in the correct order, and the click filesystem is somehow missing the NAT entries. However, because this is in squashfs, it is easy to pull apart and modify. You don't need to recompile the kernel or even patch CRCs into the image with a hex editor 
I highly doubt OpenWrt will ever support this hardware, as it relies on proprietary closed source kernel modules for an outdated kernel. But I think this proof of concept shows that something much closer to an OpenWrt-style firmware is possible and can be realized with a few months more effort.
If you are interested in details or would like to contribute to the effort of creating an entirely NOR based firmware, I have released all the details on my blog, and the build scripts on GitHub.
https://watchmysys.com/blog/2020/04/modifying-the-cisco-meraki-ms220-8p-firmware/
Hey @Thunderwolf I've got a beta firmware that should work on your MS220-48LP. Drop me an email (just look at any of my GitHub commits).
@t4thfavor See here for a "full firmware": https://watchmysys.com/blog/2020/06/ms220-8p-custom-firmware-from-scratch/
If you just want the instructions to flash the firmware (IMHO, it's easier than Leo's method because you don't even need UART, just SPI flash it and wait for it to DHCP after booting) they're at the bottom of the above post (ctrl+f for "installation instructions").
I accept PRs: https://github.com/halmartin/meraki-builder
Lets assume I don't have 14 Cisco switches laying around my office, and lets further assume I can get serial console on my MS220-8P that still thinks it's rooted, but I can't get any of the networking to work.
How would I go about flashing from the console maybe from tftp or via serial terminal? I liked having a simple POE switch that didn't cost 400$ to mess around with in the lab.
My first and foremost suggestion would be that you invest in an SPI programmer and a SOIC16 chip clip. It will be by far the fastest and easiest method to flash the switch, if you value you time at any value above $0.
This is completely untested, but if you already have a serial console, you could transfer my firmware build over zmodem or something and then flash it. This will take forever over UART and will likely not work anyway, because the mtd layout is completely different between Leo's firmware and the SPI firmware I have created.
You're more than welcome to try alternative methods to install the firmware, but for the moment I can only support SPI flashing using an external programmer.
Installation doc is at the bottom of this post: https://watchmysys.com/blog/2020/06/ms220-8p-custom-firmware-from-scratch/
OK, cool. I used the SPI interface on an old raspberry Pi model B. I will probably have to wait on this until I have more time to mess with it. I recall it being sort of a pain to solder to the tiny pins, so maybe this switch gets donated, and I buy something ready made.
I like to tinker with this kind of stuff, but in this instance I need something that I don't have to mess with.
An SOIC-16 chip clip will cost around $5 and will save you the hassle of soldering tiny pins, however the clips can sometimes be difficult to make contact and I frequently have to hold them for the duration of the flash, which can be quite annoying.
The firmware is definitely still at the "tinkerer" level of maturity, so if you're looking for something polished I think there are more convenient options available.