I have some tips for you in this matter.
I've had success running master on WRT3200 with WPA2-EAP. I noticed that the lock ups happened after a kernel warning:
Rekeying PTK for STA xx:xx:xx:xx:xx:xx but driver can't safely do that.
This warning was introduced in linux 4.20, so by itself, the rekeying change that came with the message does not cause trouble.
I have created a package in https://github.com/cotequeiroz/customfeed/tree/master/mwlwifi-thaw-clients that greps /dev/kmsg, and uses hostapd_cli to disassociate the client. I don't know why it works or why the message does not appear with WPA2-PSK, and haven't really looked into it.
Another patch is needed to add a newline to the message, so that it will be sent to kmsg right away without buffering. I have a branch in my fork of openwrt.git, rebased to 4b0f877, that has the three commits I'm mentioning here: https://github.com/cotequeiroz/openwrt/commits/mwlwifi
As for the kernel hash, it is tied to the kernel build options. It is generated in include/kernel-defaults#L121, and gets used to define LINUX_VERMAGIC. I haven't tested it, but I think you can set it from the make command line. The conventional way of matching this is to not have any CONFIG_KERNEL* differences between the official config.buildinfo and in your scripts/diffconfig.sh output.
If the kernel hash issue does not get resolved, or if you're going for a custom-build, I have two commits that will change the arch of the armada-385 series to use the neon extensions--always a hot topic. The openwrt_core packages (https://downloads.openwrt.org/snapshots/targets/, notice /targets/) , where the target-specific packages live, will have to be built locally. The rest of the standard repos in /etc/opkg/distfeeds.conf (from https://downloads.openwrt.org/snapshots/packages/, notice /packages/) can be used, as the packages for the arm_cortex-a9_neon arch are built by the bots.
I add -funsafe-math-optimizations to CONFIG_TARGET_OPTIMIZATION generate neon fp code, and keep my own repo of packages, but I understand it is not for everybody. Without it, though, the performance gain will not be too relevant. Some of the most relevant packages, such as openssl, will check for neon presence at run-time, using optimized code. Kernel crypto modules are already built to use neon, so IMMV.