Steve Underwood wrote: > > 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. > OK, I created my 416 byte ID file, and put it and another file in a separate directory where I ran genromfs -f /dev/sda. I can then mount /dev/sda /mnt and see the two files, the first 416 bytes, the second 308. The I dd' two blocks of /dev/sda to another file and looked at it with vi. It shows me 64 bytes of something between the 32 byte superblock and the first 32 byte file header. It also says that my total fs size is 896 bytes. According to the scant romfs docs, it should be 820 bytes. It does correctly set the file sizes to 416 and 308. So, there is a total of 76 extra bytes that I have to track down the meaning of ;(.
Thanks, Garst
