Russell King - ARM Linux wrote:
> It might be worth doing a 32-bit sum of the kernel zImage while its on
> your disk, and getting the boot loader to do the same immediately before
> calling the decompressor code, and comparing the values. Then, at least
> you have the confidence that the image in memory before decompression is
> what is on your hard disk.
Here's a patch that does an MD5 sum on the contents of any transferred
file upon reception:
ftp://ftp.wearablegroup.org/pub/software/patches/
bootldr-snapshot-15-mar-2001.patch.gz
MD5 includes the length of the data buffer in its computation, which is
hard to know when transferring over XMODEM (what bootldr currently
does). This is because XMODEM transfers 128-byte packets with no
provision for a "short packet" and no metadata to describe the correct
final file size. YMODEM fixes this with a "filename packet" (it also
adds support for a more butch integrity check, CRC16). As such, I've
added YMODEM support to bootldr as well; to use it instead of the
default XMODEM, just set the "ymodem" param to a nonzero value.
Interestingly, I noticed that when bootldr flashes a kernel image (of
size n bytes), it writes n bytes beginning at the offset of the SDRAM
buffer where the kernel was loaded from the modem subroutines.
Unfortunately, bootldr adds 12 bytes of metadata at the beginning of
that buffer, so the length should really be n+12. This would not matter
in a number of cases, because the buffer length returned from the modem
subroutines would be some multiple of 128 bytes in size, and so n+12 is
often less than 128-byte-aligned size. I suspect that some of the
decompressor failures we have been seeing may be related to the case
where n+12 is greater than this size, so I've adjusted the flash
programming parameter.
Good luck,
-jd
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
