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:
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.
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:
```text
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:
```text
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.
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:With a size of 128k (extra padding) the header is almost the same:
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.
Fixed by
54a0cd90b2