Hi Wolfgang, On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk <w...@denx.de> wrote:
> > So how about changing the element type of output in the definition of > > hash_func_ws, adapting the corresponding implementations sha1_csum_wd, > > sha256_csum_wd and crc32_wd_buf, and adapting the output argument > > of the sole call to hash_func_ws, that is, the local "u8 > > output[HASH_MAX_DIGEST_SIZE];" in hash.c? Then we'be done with > > alignment. > > OK, but that would be a totally different approach (which appears to > be a good one, here). Indeed; I would suggest splitting this change in two independent ones: - fix the endianness issue: change the endianness of crc through the use of htonl() but leave the existing memcpy() in place as it is, even though it is not speed-optimized. That's what Simon's patch does if the HOSTCC part is ignored; - fix the unalignment issue by changing parameter 'output' of function type 'hash_func_ws' from u8* to u32* and adjusting the rest of the code accordingly -- which would lead to replacing the crc32 final memcpy() with a single indirect assignment. These two changes could be submitted either separately, or as a series. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
