Hi!
Currently there is no single scheme used. Some chips (like STM32) use
only one generic target cfg file with (more or less accurate) default
values that (more or less) suit the whole family. Other chips (like LPC
from NXP) have separate cfg files for each chip.
In a recent discussion (Problems with workareasize and STM32F100 (8kB of
RAM)) I mentioned problems with default values of WORKAREASIZE in
stm32.cfg (16kB), that made flashing chips with lower amount of RAM
(<16kB) really slow (~200 bytes/s) beacuse block writes are impossible
then. Of course this default value could be changed to "least common
denominator" throughout the family (4kB IIRC), but this would limit the
flashing speed of chips that actually have more RAM (tests -
https://lists.berlios.de/pipermail/openocd-development/2010-October/016792.html
).
Therefore I propose a completely new target cfg files scheme for OpenOCD
- separate cfg files for all target devices and organized directories.
Something like:
- target
- STM32
stm32f103rb.cfg
stm32f107v8.cfg
stm32f100rb.cfg
...
stm32.cfg // generic file
- LPC17xx
lpc1758.cfg
lpc1768.cfg
...
lpc17xx.cfg // generic file
- LPC2xxx
lpc2103.cfg
lpc2148.cfg
lpc2214.cfg
...
lpc2xxx.cfg // generic file
- STR7xx
...
- STR9xx
...
- ...
and so on.
The idea is to still have generic cfg files (if possible) with safe
defaults (least common denominator). Chip-specific cfg files would just
define "right" values and include generic family files. It should be
possible to still use generic files alone - just like now.
Main pros:
- user-friendliness - there would be no need to change anything (or very
little - crystal frequency) in target cfg files
- low impact on current setups (only change the path to file -
"target/stm32.cfg" -> "target/stm32/stm32.cfg" [or sth like that])
- maximize performance - no need to limit workareasize for chips with
lots of RAM
Main con:
- a lot of files (there are >80 stm32f's, and so on)
I'm willing to prepare patch, but I'd like to hear maintainers' opinion
first, as my time is limited and wasting it is not my purpose (;
4\/3!!
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
