I want my target to work on firstboot. I look how other targets will
make image with 'deadc0de' at start of what will become jffs. This
means I have to change the image CRC32 so that when it gets formatted,
this part is not checked by u-boot next boot...

The bootloader is old U-Boot. I cannot get crc32 calculated
correctly.. I need to re-calculate the header and data CRC32, but
we'll start with header since it's short and hopefully once I figure
it out the data one will follow.

Here is sample data:

27 05 19 56 d0 c3 bf f2    4c d9 f8 12 00 17 b2 69
80 40 00 00 80 40 00 00    20 e8 9c ae 05 05 02 00
41 44 4d 38 36 36 38 20    4c 69 6e 75 78 20 4b 65
72 6e 65 6c 28 32 2e 34    2e 33 31 29 00 00 00 00

the first four bytes are uboot magic, the next four, d0c3bff2, are the
crc32 of that entire header. of course, they're 00s when it's
calculated and then inserted.

testing the kernel's crc32_le function in a .c compiled for my host
(PowerPC G4) and target both calculate d0c3bff2 from file.

when I do the same from target (little endian MIPS of course) in MTD
map driver, i get "hdr crc: len=64 le:0xa54edcc4 1s:0x5ab1233b"

i am lost as to why!!! i even print the header to make sure:

                unsigned char *data = (unsigned char *)&uhdr;
                uint32_t len = sizeof(uhdr);
                uint32_t crc, i;

                uhdr.ih_hcrc = 0;
                crc = crc32_le(0, data, len);
                for (i = 0; i < sizeof(uhdr); i++) {
                        printk("%02x%c", data[i], ((i+1)%8))?' ':'\n');
                }
                printk(KERN_NOTICE "hdr crc: len=%d le:%#x 1s:%#x\n", len,
                 crc, crc ^ 0xffffffff);


I also tried the 1-bit access crc function to make sure included
kernel one wasn't doing anything crafty, and same results. This is not
working directly on flash either but already read from flash into a
u-boot image struct. Endianess should not be issue, right? only 32-bit
and 16-bit reads to memory matter.

Any ideas?? The first seed of '0' seems correct too from u-boot
mkimage sources. :( pleaseeee i've spent too long on this 1 bug. maybe
other targets even do it different to ensure old parts of flash are
erased? i still would like to resize image in flash on first boot.
would allow squashfs replace without kernel. As now, kernel+squashfs
are at the mercy of this crc.

Maybe it's something simple I'm overlooking...

-Scott
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to