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 .
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.
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").
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.
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.
I hate having to hold cheap clips too, so I use a ball of blu-tak on the rear, above the hinge, to weight the clip down a little and use a rubber band near the tip to proide a little more closure force.
I inspect the "nose" of the clip for damage regularly , you may have to clean up or remove badly-moulded plastic or trim damage with a scalpel.
As a desperate last resort you can try to carefully score across each of the clip contact faces with a very fine pointed scalpel to provide some extra grip in the form of serrations. This will require a good magnifier and a very delicate hand.
If you wish to invest some money I recommed Pomona as a good brand
Is the firmware still at tinkerer level? It looks like you've done some amazing work pushing the project forward and really detailed instructions. I planned to buy the switch and use your firmware and i'm trying to work out if that's sensinble for something I'd need to work (in a home network) thanks.
Flashed your firmware this morning and had no issues. Can SSH into the system and set the MAC address. My question now is around configuration of the ports - In your firmware is click still used for configuration as in Leo's firmware? Should I just echo out port configurations as used in Luckas script? Or is there a better way to approach this?
In your firmware is click still used for configuration as in Leo's firmware?
Yes. As far as I know, bootlin has not finished adding support for the luton26 to the mainline kernel, and I don't have access to the Vitesse SDK so using the stock kernel modules are the only way to manage the switch fabric.
Should I just echo out port configurations as used in Luckas script?
That's what I would do. To be honest I am not that enthusiastic about investing a lot of time into making the current firmware better. It is clear that mainline support is coming soon™ and I don't see the investment into this dead-end kernel/click method as being worth the time.
I also have one with long expired license that I don't intend to renew and I'm willing to experiment...
Although, it's quite usable in current state. Works as a dumb switch and PoE is enabled on all ports. Quite good for my IP cameras. I've just blocked it from phoning home on my router.