On 13/04/2022 15:21, Erhan Kurubas wrote:
+Tomas Vanek for his comment.
------------------------------------------------------------------------
*From:* Erhan Kurubas
*Sent:* Friday, April 8, 2022 11:57 PM
*To:* Antonio Borneo <borneo.anto...@gmail.com>
*Subject:* alternative workarea config
Hi Antonio,
Espressif targets use 2 different work area configs in sram for the
code and data sections during stub flasher operations.
Currently upstream repo support only one command set. So, we added
another command to specify working area for the data space.
(-alt-work-area-xxx)
https://github.com/espressif/openocd-esp32/blob/master/tcl/target/esp_common.cfg#L22
https://github.com/espressif/openocd-esp32/blob/master/src/target/target.c#L5345
Before creating a patch, I would like to ask your opinion for this
approach.
Thanks in advance for your support.
Hi Erhan,
you're right the current single work-area system in OpenOCD is not
suitable for Harward architecture CPU.
Unfortunately some features of the solution used in esp fork seems me
unacceptable:
1) I don't like the working area maintenance code is completely duplicated.
target->working_areas is already implemented as the list, so adding
properties like code_only and data_only
to struct working_area would do the job
2) The comment
https://github.com/espressif/openocd-esp32/blob/master/src/flash/nor/esp_flash.c#L44
reads:
* It is important that the both stub sections reside
* at the beginning of respective working areas because stub code is
linked as ELF and therefore it is
* position dependent. So target memory for stub code and data must be
allocated first.
My question is why a working area is used at all if the both code and
data should load at fixed addresses?
The OpenOCD concept of working area is suitable for (small chunks of)
position independent code, buffers, stack.
I would recommend storing the huge stub as an elf file and using
load_image.
Tom
