FWIW I've been chasing a failure on beaglebone black where a random subset of relinked kernels fail to get as far as console init and am pretty flummoxed about it.
Turning off the strictness might fix whatever issue that was, and save me the pain of soldering on a JTAG connector and learning OpenOCD just because I don't have access to printf() early enough to debug it without doing things the hard way. I will be testing this patch with interest. An alternative to having the processor sweep unaligned accesses under the rug would be to change the trap handler to do actual alignment fixups, complaining about having to do alignment fixups, and then continuing, instead of treating it in a fatal manner, I suppose. Just my 2c. On Thu, Feb 22, 2018, at 3:51 PM, Mark Kettenis wrote: > I hate to loose yet another strict-alignment canary, but the reality > is that the rest of the world assumes that armv7 supports unaligned > access which means that compilers generate code that assumes this > works when compiling code for armv7 and later (e.g. NEON code) and > that hand-written assembler code assumes this works as well. I hit > yet another case of this while playing around with softfp. > > The diff below stops the kernel from generating alignment faults as a > first step. > > ok? > > > Index: arch/arm/arm/cpufunc.c > =================================================================== > RCS file: /cvs/src/sys/arch/arm/arm/cpufunc.c,v > retrieving revision 1.52 > diff -u -p -r1.52 cpufunc.c > --- arch/arm/arm/cpufunc.c 8 Sep 2017 05:36:51 -0000 1.52 > +++ arch/arm/arm/cpufunc.c 22 Feb 2018 21:42:35 -0000 > @@ -395,7 +395,6 @@ armv7_setup() > | CPU_CONTROL_AFE; > > cpuctrl = CPU_CONTROL_MMU_ENABLE > - | CPU_CONTROL_AFLT_ENABLE > | CPU_CONTROL_DC_ENABLE > | CPU_CONTROL_BPRD_ENABLE > | CPU_CONTROL_IC_ENABLE > -- Brandon Bergren Technical Generalist
