-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Checksum documentation #44
Comments
Therefore, not necessary to get the resultant size of the full free ROM. |
Okay. I'm trying to figure out the probability of collision in the free space... Logic tells me that in case of 65k of free space, this amount would simply be subtracted from the 4 billion possible codes, only introducing a very slight probability, as you say. Also when considering the remainder of flash memory - that's not really random data, is it. Perhaps would be better modeled as FFFF. |
Actually, after further thought, the probability is quite a bit more substantial IMHO. Introducing 65000 more OK-codes does not simply subtract, but rather divide the checksum codespace by that amount. That's moving from 1 in 4B towards 65k in 4B. Therefore the resultant checksum would only have a strenght of 16 bits instead of 32. Again, that's when considering random distribution. |
Found an interesting article. So I think that 32-bit checksums are good for the small devices, but I prefer a 64-bit if it doesn't consume an extra flash page. |
It's not entirely obvious how the firmware checksum validation works. I seem to have some idea but would like confirmation.
_APP_START
up until__romend
)Does this mean that the application image should be linked with the resultant size of
__romend - _APP_START - 4
in order to guarantee correct checksum verification?The text was updated successfully, but these errors were encountered: