Changed flash driver to support writing to the user data page, as well as to any portion of the lockbits page above 512 bytes (the amount used for the actual page lock words). The top part of the lockbits page is used on at least the EFR32xG1 chips for the SiLabs bootloader encryption keys.
As presented to the user, the lockbits page is the same size as the other pages, but any attempt to write to its low 512 bytes is an error. To enforce this, efr32x_write is renamed to efm32x_priv_write and a wrapper function is provided in its place. If the user erases the lockbits page, the driver rewrites the cached lock words after the erase. When the driver erases the lockbits page in order to update the lock words, it first takes a copy of anything stored in the top part of the page, and re-programs it after the erase operation.
There are now multiple instances of flash_bank for each target, and the flash_bank instances must share their cached lock words to operate as intended. Therefore, when a bank is created, the global flash bank list is used to find any other banks that share the same target. Since some banks in the global list are invalid at the time free_driver_priv is called, reference counting is used to decide when to free driver_priv.
To avoid the need to find the lockbits flash_bank from another flash_bank, efm32x_priv_write and efm32x_erase_page now take an absolute address.
There didn't seem to be any reason to prohibit unprotecting individual flash pages, so that limitation is removed from efm32x_protect().
This addresses ticket #185.
Valgrind-clean, except for 2x 4kiB not freed/still reachable blocks that were allocated by libudev.
No new Clang analyzer warnings, no new sanitizer warnings.
Signed-off-by: Doug Brunner <doug.a.brunner@gmail.com>
Change-Id: Ifb22e6149939d893f386706e99b928691ec1d41b
Reviewed-on: https://review.openocd.org/c/openocd/+/6665
Tested-by: jenkins
Reviewed-by: Fredrik Hederstierna <fredrik.hederstierna@gmail.com>
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Prerequisites:
The users of OpenOCD as well as computer programs interacting with OpenOCD are expecting that certain commands
do the same thing across all the targets.
Rules to follow when writing scripts:
1. The configuration script should be defined such as , for example, the following sequences are working:
reset
flash info <bank>
and
reset
flash erase_address <start> <len>
and
reset init
load
In most cases this can be accomplished by specifying the default startup mode as reset_init (target command
in the configuration file).
2. If the target is correctly configured, flash must be writable without any other helper commands. It is
assumed that all write-protect mechanisms should be disabled.
3. The configuration scripts should be defined such as the binary that was written to flash verifies
(turn off remapping, checksums, etc...)
flash write_image [file] <parameters>
verify_image [file] <parameters>
4. adapter speed sets the maximum speed (or alternatively RCLK). If invoked
multiple times only the last setting is used.
interface/xxx.cfg files are always executed *before* target/xxx.cfg
files, so any adapter speed in interface/xxx.cfg will be overridden by
target/xxx.cfg. adapter speed in interface/xxx.cfg would then, effectively,
set the default JTAG speed.
Note that a target/xxx.cfg file can invoke another target/yyy.cfg file,
so one can create target subtype configurations where e.g. only
amount of DRAM, oscillator speeds differ and having a single
config file for the default/common settings.
aad8718058