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

  Brandon Bergren
  Technical Generalist

Reply via email to