On 27 March 2015 at 11:42, Andy Polyakov <appro@xxxxxxxxxxx> wrote: >>> 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? > I need to double check that, but my suspicion is that it was the latter. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
