David Brownell wrote: > On Tuesday 02 February 2010, Edgar Grimberg wrote: >>> What might make more sense is to have the 0.5 series dump that >>> status only after "protect_check" ... like it only dumps erase >>> status after "erase_check". >> Or we can clone the functionality of at91sam7 flash driver. The last >> thing in at91sam7_protect function is to call at91sam7_protect_check, >> so the information is updated. The initial state is filled in with >> real data in at91sam7_read_part_info, that is called by >> at91sam7_probe. > > That would be an 0.5 thing too. :) > > >> Checking for the protection status of sectors is a "light" operation >> (unlike check erase), so we can query the hardware as a side effect of >> some commands (flash protect and flash probe, as in the sam7 driver). > > I'm not sure it's appropriate to assume, at an architectural or > infrastructural level, that it's always "light". And even if we > could, that type of side effect can cause trouble. > > However I *would* like the symmetry of knowing that both "check" > operations behave the same way in all notable respects. They seem > to have started out that way ... but got out of sync when the flash > sector struct stopped tracking erase status (in part because the > firmware can change it). > > > By the way ... if STR7 can't actually read the protect status from > the hardware, why does that flash driver have a str7x_protect_check() > method which pretends to do exactly that, instead of just printing > a warning that the status can't be read? >
The register reflects the state of a non-volatile register. So after a reset halt - reading this register returns valid protection data. Any writes to this register are not reflected by reading the register again. Cheers Spen _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
