Garst R. Reese wrote:
Yes, the sumcheck in linux/fs/romfs/inode.c where it expects the the
result of romfs_checksum(x) to be 0. In genromfs.c it uses
-romfs_checksum(x) to set the checksum. That makes sense, but scattered
in the code are htonl's and ntohl's, these functions either do nothing,
or a 32bit byte swap, depending on endianess. I've tried every
combination of byte-swapping or not that I can think, and it still tells
me I have a bad checksum. I also looked at the affs sources. I'm still
stumped. There are endian issues both with the MMC and the msp430.
How about you write a file system with Linux, and then try to make sense
of what was written to the disk? You could read it with Linux and read
it with your code to make comparisons.
Regards,
Steve