On 03/02/2017 05:32 AM, Forest wrote: >> 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. \o/ > Okay, now I have a few questions: > > Why did running flash_unlock on a single block of mtd1 unlock all of mtd1 > and mtd2? See https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p_128.pdf The Status Register has three bits (Block Protect Bits). See table 2 for their meaning. It seems you must at least unlock half of the chip. I didn't check the driver, maybe even the coarse locking the chip supports isn't implemented correctly. > How did they become locked in the first place? Hmm, no idea. Maybe that's some power up default. I didn't find anything about default values in the manual. > Why didn't write attempts produce any errors or kernel logs to indicate that > the devices were locked? Probably that's because the write command doesn't return an error because the device doesn't signal a problem. Best regards Uwe
Attachment:
signature.asc
Description: OpenPGP digital signature