[OpenWrt-Devel] build: sysupgrade: kernel: mtd: Image too SMALL to Restore Config

[Hannu Nyman]

> The smaller, "failing" image contains in /dev/mtd2:

> 003eebd0 00 01 59 5a be e7 20 00  00 00 00 00 04 80 00 00  |..YZ.. .........|
> 003eebe0  00 00 dc eb 20 00 00 00  00 00 ff ff ff ff ff ff  |.... ...........|
> 003eebf0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff |................|
> *
> 00400000  19 85 20 03 00 00 00 0c  f0 60 dc 98 19 85 e0 01  |.. ......`......|
> 00400010  00 00 00 36 5d 44 48 fe  00 00 00 01 00 00 00 00 |...6]DH.........|
> 00400020  00 00 00 02 00 00 00 00  0e 08 00 00 97 8f 0a 5b |...............[|
> 00400030  31 ff 3d bc 73 79 73 75  70 67 72 61 64 65 2e 74 |1.=.sysupgrade.t|


The failure may actually be on the image sysupgrade appending logic during 
sysupgrade/flash time, not in the boot time logic. The interesting part is 
that the appended sysupgrade data starts at 0x400000 in both cases, 
eventhough the firmware image ends at 0x3eb3710 in the failing case. In the 
failing case, there is thus an extra 64 kB of empty 0xff before the appended 
sysupgrade.tgz, and that causes the sysupgrade archive detection problem at 
the boot time (as the detection looks properly at 0x3f0000 and finds nothing).

Possible mismatch in the eraseblock size detection? Maybe the sysupgrade 
creation script or padjffs thinks that you have a 128 kB erase block instead 
of 64 kB, and pads up to 0x400000 instead of 0x3f0000, so that theer is no 
deadcode indicator at 0x3f0000.

Your secondary NAND flash seems to have 128 kB block size?
      spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048, OOB 
size: 128

Any way that you get into picture here and create confusion about the NOR 
flash block size?  Dual NOR/NAND flash systems are rare, which could explain 
why nobody has stumbled into this earlier.


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel