Hi All
Apology in advance if I am not explaining this correctly, and, as it is very
likely, I am mistaken.
When gdb issues the "load <image>" instruction for RISCV 0.13 compliant
processor, and if riscv target use the program buffer route
(write_memory_progbuf() [riscv-013.c:3368) the riscv target uses batch
processing to write the binary image data. See while loop on [riscv-013.c:3437]
In the while loop, riscv target chop up the image data to 32/64 bit words for
writing. RISCV target batch this up, preparing each 32/64 bit into dmi
instruction using riscv_batch_add_dmi_read() [riscv-013.c:3492-3].
So far, so good.
My question is, in riscv_batch_add_dmi_write() [batch.c:116], at
batch:c124: riscv_fill_dmi_nop_u64(batch->target, (char *)field->in_value);
we are actually writing assigning a value to field->in_value. This will
eventually result in DR scan doing a read.
I believe this read is redundant, as we are not using the return value from DR.
So this is my question: why do this read?
In my driver, this extra read from DR is causing delays. Hence, I am gathering
opinion on this to see whether can I do some refactoring to take out this read.
I also believe it is not as easy as setting field->in_value=NULL in
rsicv_fill_dmi_nop_u64(), as it might be used elsewhere that actually require
field->in_value.
Many thanks
Cinly
Quick link to source code:
- riscv-013.c
https://sourceforge.net/p/openocd/code/ci/master/tree/src/target/riscv/riscv-013.c
- batch.c
https://sourceforge.net/p/openocd/code/ci/master/tree/src/target/riscv/batch.c
