Supporting flash that powers up locked
tpoynor at mvista.com
Wed Nov 24 20:15:50 EST 2004
David Woodhouse wrote:
> We already have a bit to set in the partition flags to show that a
> partition should be read-only.
Yeah I saw that the bit is really an amalgam of
MTD_CLEAR_BITS|MTD_SET_BITS that are also involved in other capability
combos (MTD_CAP_NANDFLASH, et al) and wasn't sure if there were other
side effects of messing with those at runtime.
> I'd rather do this with a blacklist of the chips which lock themselves,
> and have the chip driver automatically unlock it at boot time and
> suspend time (or automatically as required).
I did receive some pushback when I previously tried to do something
similar, since we'd often be unlocking bootloader firmware and such.
It may be better to err on the side of caution and make it the
responsibility of userspace to unlock the needed portions. Assuming the
root fs is read-only then boot time probably isn't a problem. System
resume time could be a problem, since we can't guarantee nothing will
write to previously-writeable filesystems before the "restore flash
state" script runs. So if the dangers of unlocking bootloaders etc.
aren't felt to be that important then unlocking all blocks is the easier
Another option suggested previously was to require userspace to unlock
needed blocks, but keep a bitmap of unlocked blocks and restore the
flash to the same state at mtd resume, so writeable file systems
continue to be writeable at resume time (and no userspace callback is
needed at resume time).
If, all in all, unlocking the whole chip is still the best way to go
then I'll send a proposed patch for Intel K3 StrataFlash. Thanks,
More information about the linux-mtd