On Sun, 26 Feb 2017 10:45:03 +0100, Uwe Kleine-König wrote:
>>> Without having checked every byte, this looks okish. Is this NAND or NOR
>>> memory?
>>
>> Looks to me like it's NOR:
>I'd something like this:
>
>dd if=/dev/zero of=zero bs=10240 count=1
>flashcp -v zero /dev/mtd1
>memtool md -s /dev/mtdblock1 0+0x2800 | grep -vE '(0{8} ){4}'
Only 10KiB? Okay. Unfortunately, flashcp once again said "File does not
seem to match flash data", and the grep output shows nonzero bytes at every
single offset.
>flash_erase /dev/mtd1 0 0
>memtool md -s /dev/mtdblock1 0+0x2800 | grep -vE '(f{8} ){4}'
Again, grep shows non-FF bytes at every single offset.
I just noticed something, though: In both tests above, the hex dumps aren't
full of 0x00 or 0xFF, but they aren't full of garbage, either. For example:
00000000: 56190527 9aac8fc2 4e5a9258 28a41f00 '..V....X.ZN...(
00000010: 00800000 00800000 db880208 00020205 ................
00000020: 6e72656b 33206c65 2e36312e 2d342d30 kernel 3.16.0-4-
00000030: 6b72696b 646f6f77 00000000 00000000 kirkwood........
That looks to me like the start of a kernel image. Could that be the old
kernel image, completely intact? Perhaps the problem here is not
corruption, but some kind of read-only mode? What do you think?
