Current method for calculating extra padding is unreliable

ehlers commented 8 months ago

While the current method (extra padding if IOS <= 15.0 or when the NVRAM size is at least 128 KByte) works pretty good, it's not always correct. As shown in the attached file, some IOU and the IOSv images behave differently. So the current algorithm must be revised.

For example i86bi-linux-l3-adventerprisek9-15.4.1T.bin with a NVRAM size of 16k (no padding) used this header:

00000000  ab cd 00 01 52 82 0f 04  12 2b 93 44 12 2b 99 85  |....R....+.D.+..|
00000010  00 00 06 41 00 00 00 00  00 00 00 00 00 00 00 00  |...A............|
00000020  00 00 00 00                                       |....|

With a size of 128k (extra padding) the header is almost the same:

00000000  ab cd 00 01 a2 d7 0f 04  f1 23 60 34 f1 23 66 75  |.........#`4.#fu|
00000010  00 00 06 41 00 00 00 00  00 00 00 00 00 00 00 00  |...A............|
00000020  00 00 00 00                                       |....|

None of the less explored header fields shows any difference. Only the addresses are totally different, if extra padding is added: The addresses are very high.

Tests with all available images showed, that this behavior is always the case. So the address is currently the only reliable way to check, if extra padding is needed.

#1 Current method for calculating extra padding is unreliable