Hi Christopher,
On 17/07/2020 23:15, Christopher Head wrote:
Hi folks,
I’ve noticed that there are quite a lot of Flash “protect” callbacks
that don’t actually do anything to the hardware. Some of them just loop
through and set the “is_protected” values; one of them (pic32mx)
doesn’t even do that, it does literally nothing and then returns
ERROR_OK. The psoc6 one does nothing and returns ERROR_OK, but prints a
LOG_WARN saying it’s not supported.
We should distinguish between two cases: one like pic32mx, which is
undoubtedly
wrong (I probably missed the more exotic drivers in
http://openocd.zylin.com/4765).
The second, usually used for SPI flash, which "just loop through and set
the is_protected values",
this works like a software protection. I don't like it either.
Hypothetically somebody
can use it as volatile protection.
This all seems wrong to me. None of them are actually doing any
protecting of the Flash. In my opinion, none of them should return
ERROR_OK; I think they should all be deleted so that attempts to use
them will take the NULL-check path in “flash_driver_protect”, print an
error message, and return ERROR_FLASH_OPER_UNSUPPORTED, a sane value.
Leaving them as is, in my opinion, is just misleading to the user, who
*thinks* they’re doing some sort of protection when they really aren’t.
It’s especially egregious for hardware that *has* protection capability
but where the OpenOCD driver hasn’t implemented it (the user would
expect that the “protect” command, if it succeeds, has activated that
capability), but seems silly also for hardware that doesn’t have that
capability at all.
Agreed.
If we decide for whatever reason to keep the software only protection,
the user should be warned. I'm not against getting rid of the sw only
prot at all.
Tom
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
