Hi Tim and Jan I had created a new pull request at https://github.com/riscv/riscv-openocd/pull/619 on the topic. Let’s continue the discussion there.
HTH Cinly From: Ooi, Cinly Sent: Friday, June 4, 2021 9:58 AM To: 'Tim Newsome' <t...@sifive.com> Cc: OpenOCD <OpenOCD-devel@lists.sourceforge.net> Subject: RE: gdb "load <image>" performing unnecessary reading from JTAG for riscv013? HI Tim >> 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 don't think that is the case. It's simply assigning in_value some known > value. Later on in_value will be overwritten with the result from the actual > scan. Sorry I had miscommunicated. I have to reread my own statements a few times and finally understood how my statement is received by you and perhaps Jan. You are right, there is no extra DR scan. What I meant to say is, setting field->in_value field will require the JTAG driver to write what it receives from JTAG from the same JTAG scan back to the caller. If it were NULL, the driver does not have to write the value it received from JTAG. For a JTAG driver developer, it can make a different I speculate to say that for most driver developers it does not matter as the extra overhead of returning the value it received from JTAG is negligible. However, my aji_client driver uses a client-server architecture and is designed to work across a network. The aji_client driver, attached to OpenOCD, is the client. Having to return the value read from JTAG means the server must perform the scan and return the result. It is only after the server returned the result the client can send the next scan request. If returning the received data is not needed, the reply packet from the server is smaller because there is no received data. Moreover, more importantly. the server can just reply the scan request is received as soon as it is received, causing the client send the next scan request immediately while it is performing the actual scan. This improve the overall speed by reducing delay. This can be pronounce for multiple sequential write-only scan request as the client is able to send these requests as fast as possible. In my particular case, difference between returning data read from JTAG and not returning data read from JTAG over the network can be significant. It is particularly pronounced in gdb’s “load” command call. Please note that I am not asking for any modification, just want to confirm my observation to inform my next step. If there is work needed I am prepared to do it myself and submit the patches. > There are probably some ways to optimize memory writing, but the inner loop > of write_memory_progbuf() scans no more bits than necessary. Agreed. Just in case of misunderstanding, I am not asking for optimization. I always feel that optimization work must have a specific goal in mind. In my case if I do it it will be to reduce the impact of network. Many thanks Cinly
