Thanks! Blocksize turned out to be the issue -- resolved for the devices
in question.
I'm still interested in finding out where the definition of the
"default" sysupgrade.img
is found in make files of the build system.
Jeff
On 7/1/19 1:47 PM, Hannu Nyman wrote:
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, and 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
possibly causes the sysupgrade archive detection problem at the boot
time (as the detection looks properly at 0x3f0000 based on the
split-detected jffs2 size 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
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
