Re: [ECOS] Re: Bug in crc32 routine?

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

I checked around and found a few more CRC calculations. In summary

1) zlib
2) jffs2
3) gdb stubs
4) cygmon
5) ks32c5000 net driver
6) Redboot - already using cyg_crc32()

cygmon and gdb stubs i've left alone. The code is not particularly
well commented.

jffs2 uses the same algorithm as cyg_crc32.

ks32c5000 wants the Ethernet FCS algorithm. 
zlib uses an algorithm which happens to be the FCS algorithm :-)

So, what i've done is left cyg_crc32 alone and added a new one,
cyg_ether_crc32. Another coincidence, is that it appears to use the
same table of coefficients as cyg_crc32. The only difference is that
it does some XORs at the beginning and the end. jffs2 and zlib need to
be able to run the CRC over multiple buffers, so i've added support
for this as well and some tests.

Redboot should not be affected in any way. I've removed the code from
zlib, jffs2 and the ks32c5000 net driver. Unfortunately, i don't have
the required hardware to test all this properly. It all compiles
cleanly. The zlib tests run correctly. Also the normal jffs2 test
passes. I hacked around with the jffs2 romfileio1 test on linux. It
correctly recognizes the filesystem, but fails some of the mkdir and
rename tests. This could be something to do with it running with a
ramfs not romfs?

What i would like is some volunteers to run the following test:

1) redboot flash CRC still work OK
2) redboot support for gzip images still works OK
3) Somebody with a Compaq Ipaq test that jffs2 still works OK
4) Somebody with a snds with a ks32c5000 test its still OK

Here is the patch. Once i get feedback on these i will commit the
patch.

        Andrew

Attachment: crc.diff
Description: Text document