commit 2d61f8821 might be of interest to anyone building some mvebu targets. Time to try to address FS#867 again.
Edit: Or maybe not bang your head against that wall.
6 Likes
And this one.
1 Like
ML thread to back it out, but rejected in the end.
- Depends on what you run on the device.
- Any FP code generated by the compiler is potentially impacted for the negative. If you use some of the bits under patented functionality, i.e. AV transcoding, I would anticipate a negative impact. But in that case you have to build it yourself and probably have gone to NEON anyways.
- Do you have a reference
- For wrtpac devices > mamba the change cut the FP registers available for use in half; assuming the compiler respects options provided. I have not bothered to go and look at the assembler churned out, but as the device that did not work now does...
- OpenVPN would depend on SSL library used. I would expect no impact with openssl, I have not taken a close look at mbedtls so not sure.
- Easy enough to load an image with / without on the two partitions and test whatever the bits are that are of concern to you. But the change to go back from whence we came is trivial, so I just do that and fuhgeddaboudit.
Turris Omnia with a Marvell Armada 385 88F6820 features
half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
and this commit just castrates the CPU capabilities.
There is no point in sticking with OpenWrt if the repo is not able to diversify the CPU architecture for the target class but instead penalising device owners.
1 Like
Another kick at the cat, let's hope it is a case of PR3079 being third time lucky.
1 Like
Looks like it worked, the commit been pushed into Master and there is now cortexa9_neon sub-target. 
I don't see that and I would guess this will probably languish.
Well, you were right then. Looks like end of the road... 