On 10/13/2011 02:37 AM, Werner Almesberger wrote:
...
Table 7 has the correct wording: "[...], all of the Block lock bits
that are set are cleared in parallel." Interestingly, section 10.1
calls the command "Clear Block Lock Bits".
Practical implications of this:
- UrJTAG has a subtle failure mode in the sense that explicitly
unlocking a block or writing a block (with hard-coded implicit
unlock) will unlock the entire NOR.
- if Flickernoise unlocks any NOR blocks during an update and
doesn't lock everything that's meant to be read-only afterwards,
this would also remove the protection.
Hi
good news is: there is no 'unlock' used in flickernoise(rtems driver)
- the protection we get is a little weaker than expected, because
any random occurrence of the two-byte unlock sequence could unlock
the NOR, after which it would be vulnerable to regular NOR
corruption. This may still be a very unlikely event, though.
- the process for setting up the M1rc3 being shipped should be
checked if the lock bits are really set at the end. At least my
version of reflash_m1.sh issues the "lockflash" before the last
"flashmem".
bad news is: if this is true all M1rc3 is unlocked :(
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
