[U-Boot-Users] CramFS endianness

[Laurent Pinchart]

On Wednesday 12 July 2006 15:54, Wolfgang Denk wrote:
> In message <200607121531.03551.laurent.pinchart at 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