yep just run provision_all and it reflashes u-boot into both bootkernel locations (redundancy) and the new ubi openwrt image. Then boot and its going. I just flashed four of them... no problems.
Yes I'll probably rebase this soon, and maybe if I get time review the changes- might be worth the effort to get this into openwrt
I just updated the images, and the openwrt submodule. I cleaned up the default config removing tricolour LED references, and some lingering usb and disk modules being built in. Also I'd forgotten to commit a DAWN patch in the packages feed. After running it a few days I found DAWN was pretty unstable- would lock up and crash... so I hacked that a bit and added some more patches. Its been going for a day on 6x APs and DAWN is doing a great job finally. Some more tuning I think but its really close.
I'll make another repo at some stage to share configs since after a long time I never found a decent setup from forum trawling. This one I've been fine tuning to "just work". Across 6 APs (3 different types with dual band concurrent- IPQ4019 and the MR53) running this openwrt build its been really solid. I have 4 dual band SSIDs on each wired to different vlans on the trunk PoE cable, each in their own Mobility Domain. A lot of key to share so I made a bunch of provisioning scripts to sync all of the APs at once if I add/remove one.
I also started a wireless controller project that can use the spare monitor radio to actively survey the area, and make intelligent dynamic band and power adjustment for openwrt APs. Its early days but looking doable, and a strange kind of fun.
Thats all way OT but I will share it all when I come up for air... who doesn't want a working plug and play config for what 99% of users end up wanting?
If you plan to rebase, it might be safer to go with 25.12 to avoid the frequent breakages in the main branch. But hey, it’s up to you, the real Sifu 
Ozzies are fun, adventurous, and just a little bit cheeky, always up for surfing waves, hopping around like kangaroos, and turning everyday life into a little adventure!
Hi @slow-boat
I cloned your repository from scratch (branch “mr53”) and built a new MR53 image. I then copied it to my MR53 and ran sysupgrade -v -n new-mr53-image. The upgrade appeared to complete successfully and the device rebooted automatically, with the system LED staying solid white. However, after the upgrade there was no Ethernet port LED activity, and a computer connected to the LAN port does not receive an IP address.
I also tried performing a factory reset using the RESET button. The system LED blinked orange and then returned to solid white after some time, but there was still no Ethernet port activity. Do you have any idea what might have gone wrong or if there is a way to recover the device without disassembling it again to access the serial console? Thanks!
The latest commit in the “mr53” branch is 70eb312bbb628009e032a1851cd344a038ab5746
Thats definitely a working commit. Could be something missing from the build that wasn't a forced dependency. It certainly wont work if you dont compile in the switch-phy and qca85xx switch drivers.
I put some config seeds in configs directory which you can compare and see if anything went missing...
default config bridges lan1 and lan2 in br-lan. and adds the leds to system config. I'll do a clean default build from git and double check if I missed anything in generic.mk.
edit:
[ 13.530922] ipq806x-gmac-dwmac 37400000.ethernet: Unsupported PHY mode: "qsgmii"
I somehow didn't add the dwmac ipq8 driver into the patch and didn't check it was missing... super lucky my working kernel wasn't cleaned or I would have cried.
Committed the patch now. Built from clean clone, installed and its working.
Sorry for the hassle.
Has anyone who used these things with default firmware noticed that they get really really hot???
I have no experience with these in their native environment but the ones I got looked like they'd been living in a volcano for most of their life... the plastic had deteriorated so badly on the back (top/hot side) that it just snaps like super thin chocolate from the freezer. Really that weak. I destroyed all of the backs by breathing on them.
The bottom (white part) is OK apart from the mounting posts with the heatset nuts. That plastic also went crazy brittle. They would have copped conducted heat through the bolts.
The default target setting was for both cores in performance mode maxed out at 1.4G, so I changed it to a scaling governer. Seems fine.
But it doesn't make any noticeable difference to the shell temperature. I didn't get the metal mounting hardware with these (came in an auction lot) so was going to 3D print some ceiling mounts. But I'm now worried they'll just melt....
Meraki MR access points do not have fans and rely on passive cooling. Most of the heat is generated by the 5 GHz Wi-Fi radios and also from the SoC. The units are designed to be mounted upside down (for example, on a ceiling), and the mounting bracket provides sufficient clearance above the device to allow heat to dissipate properly.
To reduce heat generation, you can lower the 5 GHz transmit power and disable the monitoring Wi-Fi PHY (not via the DTS! 
).
Rear plastic on my units is the same.
Maybe the MR53 units from both of you were installed in non-air-conditioned environments. The back of my units still looks great and solid, but the top white plastic is very dirty, so much so that even 99% isopropyl alcohol cannot clean it properly.
Is the plastic discoloured? If it is, could be UV damage. There are various techniques you can use for this, such as hydrogen peroxide: https://www.retrotechlab.com/how-to-fix-a-yellowing-snes-console-step-by-step-guide/
thanks for the feedback confirming these things always run hot. I lazily googled this and realise its a "design feature". I have the scan radio off in the config, and power is only 20dBm. CPU scaling seems to be working, but yeah I think the main culprit is that sea of older gen high power FEMs in the chain (8 of them) and nowhere to radiate the heat aside from upwards through the plastic.
Mine will have the top metal shell exposed thanks to the old plastic disintegrating. I think it will be OK. Also I didn't get the mounting hardware which is a PITA so I have to make something for them. I'm not blowing $400 on 4 kits. PETG is all I have handy but the temp is prob too high for that. I can spray paint the top with rustoleum matte black, and that should bring the temp down maybe 3-5C, and I can tape the contact points of plastic with Kapton to help the plastic a bit. I guess thats the answer 
If you're removing the back plastic why don't you just bolt into the 4 screw mounts under the feet? You can pretty easily create one of these slide or twist locking mounts with just bolts and some 1-2mm plexi/plywood.
The inverse of this:
That’s a Idea. Would be awesome to find the bracket for the MR62/MR66.
Hi @slow-boat
Please take a look at this issue when you have some time. Thanks.
I don't see this on mine.
Its a bug in a userspace library or program - triggering
EDC4 0B02 → VLDR s1, [r4, #8] (VFP/NEON load, 4-byte aligned required)
ie its trying to load a non-word-aligned floating point number. Sounds like a badly packed structure or a network protocol containing float thats not word aligned and then the pointer being passed into a float operation. There are ways to hunt this down... and/or identify the culprit.
I'll keep an eye on mine. I've also merged openwrt master and feeds into a test branch but I havent had time to put it on the mr53s yet. Maybe on the weekend.
I used the same set of packages (yes, quite a few) in the .config for MR53 and other platforms (MR52, MX4300, etc.) with the latest feed updates, but I did not encounter these alignment errors on the other platforms. The only difference is that MR53 is still using kernel 6.12.65, while the others are on 6.12.74.
I’ll try again later after you rebase the MR53 branch. Thanks a lot!
