On Wednesday 12 July 2006 15:54, Wolfgang Denk wrote:
In message 200607121531.03551.laurent.pinchart@tbox.biz you wrote:
However, even though Linux doesn't do any byte swapping, U-Boot assumes little-endian byte order and swap bytes on big-endian architectures. Why is that ? U-Boot and Linux are clearly not compatible on big-endian architectures, and I'd like to fix the problem in the right place.
Can you please point out which specific parts of the code you are talking of, and which specific prolems you see with this? AFAIK cramfs has been working fine on PPC systems for a long time. [I have to admit that I didn't test it recently, but I am not aware of changes in that area either.]
U-Boot defines the following set of macros in include/cramfs/cramfs_fs.h:
CRAMFS_16(x) CRAMFS_24(x) CRAMFS_32(x) CRAMFS_GET_NAMELEN(x) CRAMFS_GET_OFFSET(x) CRAMFS_SET_OFFSET(x,y) CRAMFS_SET_NAMELEN(x,y)
The actual definitions depend on the target byte order: the CRAMFS_{16,24,32} macros are no-op on little-endian systems, and swap bytes on big-endian systems. This seems to imply that the cramfs image is in little-endian.
The mkcramfs tool generates a host-endian image by default (it doesn't perform any byte swapping). If the host is a little-endian machine, the image will be little-endian and will be read properly by U-Boot. This won't be true if the host is a big-endian machine though.
The Linux kernel doesn't swap bytes when accessing cramfs images. For little-endian images on little-endian targets, no problem there. On big-endian targets, mounting the image fails.
There's a patch available on the cramfs sourceforge page which adds a -r option to mkcramfs to reverse the byte order. With the -r option, a big-endian image can be created on a little-endian host, and the image can be accessed by Linux on big-endian target. This breaks U-Boot, as it swaps bytes on big-endian targets.
Hope this helps to understand the problem.
Best regards,
Laurent Pinchart