Hello, On 03/02/2017 01:08 AM, Forest wrote: > 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?
Right, this is still the same data as in your first reply. You can try flash_unlock -i /dev/mtd1 0 1 . Looking at the device tree no other reason for the flash being RO sticks out. The chip has a write-protect input, maybe its status can be read out with the RDSR command, but I don't see how you could send this from within Linux unless you start writing to the spi controller by hand, which is ugly and error prone. So I hope the unlocking helps. Best regards Uwe
signature.asc
Description: OpenPGP digital signature
