[Milkymist-devel] NOR corruption analysis 3/4, a subtle gotcha
xiangfu at sharism.cc
Thu Oct 13 20:05:20 PDT 2011
please update your reflash_m1.sh. the new version reflash_m1.sh have fix wrong lockflash command.
we can also use
./reflash_m1.sh --lock-flash for lock the rescue partition without reflash images.
On 10/14/2011 09:54 AM, Xiangfu Liu wrote:
> 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.
> 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
> bad news is: if this is true all M1rc3 is unlocked :(
More information about the Devel