Dear Simon Glass, In message <capnjgz2jrvpq56_epvkumh8e1l2lj0hgzncs-grn9bxfosx...@mail.gmail.com> you wrote: > > >> +#ifdef USE_HOSTCC > >> + crc = htobe32(crc); > >> memcpy(output, &crc, sizeof(crc)); > >> +#else > >> + put_unaligned_be32(crc, output); > >> +#endif > > > > Why is this depending on USE_HOSTCC, and not on the endianess? > > We always want big-endian in this case, since the bytes have to date > been written that way by the crc32 command.
Let me rephrase. Why do we need an #ifdef here, and why depends this on USE_HOSTCC? > > And why do we need the #ifdef? Can we not always use htobe32() and > > put_unaligned_be32() ? > > Well I don't think put_unaligned_be32 is available to user space, > which is the environment that the tools are built under. It is > available in the kernel, but that's not our environment. It appears put_unaligned_be32() is a widely unknown, pretty exotic function that so far has been used in ony two source files: drivers/usb/gadget/f_mass_storage.c lib/tpm.c The implementation (in "include/linux/unaligned/generic.h") is ugly and pretty expensive in terms of run time and memory footprint. I would like to avoid it's usage all together. > I'm not happy with this solution and would be pleased to find a better > way, but I'm not sure what it is. Does the htobe32() + memcpy() approach not work everywhere? > But this patch does fix a real bug which we should sort out before the > release, one way or another. Agreed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "I find this a nice feature but it is not according to the documen- tation. Or is it a BUG?" "Let's call it an accidental feature. :-)" - Larry Wall in <6...@jpl-devvax.jpl.nasa.gov> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot