>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.
My version of flash_unlock doesn't accept -i, nor does the one I found on github, but omitting that option did the trick! flash-kernel works again, even after a power cycle. Okay, now I have a few questions: Why did running flash_unlock on a single block of mtd1 unlock all of mtd1 and mtd2? How did they become locked in the first place? Why didn't write attempts produce any errors or kernel logs to indicate that the devices were locked? Thanks so much for your help, Uwe. Looks like I don't have to resort to emergency hardware replacement after all.
