On Wednesday 12 July 2006 16:47, Wolfgang Denk wrote:
In message 200607121608.26551.laurent.pinchart@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