>> Could you share the error log please?
> 
> OK, I spotted one issue with this code:
> 
> arch/arm/crypto/sha256-core.S: Assembler messages:
> arch/arm/crypto/sha256-core.S:1847: Error: invalid constant (ffffefb0)
> after fixup
> 
> This is caused by the fact that, when building the integer-only code
> for an older architecture, the conditional compilation produces a
> slightly bigger preceding function, and the symbol K256 is out of
> range for the adr instruction.
> 
> @Jean-Christophe: is that the same problem that you hit?
> 
> @Andy: I propose we do something similar as in the bsaes code:
> 
> #ifdef __thumb__
> #define adrl adr
> #endif
> 
> and replace the offending line with
> 
> adrl r14,K256

Sorry about delay. Yes, that would do. I did test all combinations, but
all "my" combinations, i.e. without __KERNEL__ defined :-( And without
__KERNEL__ there are few extra instructions in integer-only subroutine
that "push" instruction in question code toward higher address, so that
constant was ffffefc0, which can be encoded. Anyway, I've chosen to add
that #define next to .thumb directive. See attached.

Ard, you have mentioned that you've verified it on big-endian, but I've
spotted little-endian dependency (see #ifndef __ARMEB__ in attached). I
guess that it worked for you either because it was NEON that was tested
(it does work as is) or __LINUX_ARM_ARCH__ was less than 7 (in which
case it uses endian-neutral byte-by-byte data load). Can you confirm either?