[U-Boot-Users] CramFS endianness

[Laurent Pinchart]

On Wednesday 12 July 2006 16:47, Wolfgang Denk wrote:
> In message <200607121608.26551.laurent.pinchart at tbox.biz> you wrote:
> > > 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:
>
> I do know this code.
>
> > 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.
>
> Did you try it out? What was the specific problems you saw?

I tried it out. U-Boot is unable to access an image in big-endian format on a 
big-endian target (MPC8260). Here is what happens when I try to load a file 
from the cramfs partition:

=> fsload 00200000 /lib/firmware/fpga/fpga.bit
### JFFS2 loading '/lib/firmware/fpga/fpga.bit' to 0x200000
Scanning JFFS2 FS:  done.
find_inode failed for name=lib
load: Failed to find inode
### JFFS2 LOAD ERROR<0> for /lib/firmware/fpga/fpga.bit!

And here is the output of the same command when removing the byte-swapping 
macros, all other options being the same:

=> fsload 00200000 /lib/firmware/fpga/fpga.bit
### CRAMFS loading '/lib/firmware/fpga/fpga.bit' to 0x200000
### CRAMFS load complete: 169287 bytes loaded to 0x200000

The cramfs image is in big-endian format (such an image can be generated on a 
big-endian host or using a patched mkcramfs on a little-endian host).

> > Hope this helps to understand the problem.
>
> No, it doesn't as you fail to explain what the problem is.

Please don't cut the part where I explain what the problem is:

"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."

To access the cramfs from Linux, the image has to be in host-endian format:

"All data is currently in host-endian format; neither mkcramfs nor the
kernel ever do swabbing." (fs/cramfs/README in the Linux tree)

U-Boot fails to access the host-endian cramfs image on big-endian targets, as 
I showed above. The Linux kernel is able to access the image properly. The 
situation is reversed for little-endian images on big-endian targets, where 
U-Boot is able to access the image but the Linux kernel isn't.

Best regards, and thank you for your help.

Laurent Pinchart