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? - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
