systembus read access.. #880

InspireSemi · 2023-07-08T15:30:06Z

Why is it assumed that on a write of the address for systembus read it automagically happens?

From read_memory_bus_v1()

	if (info->bus_master_read_delay) {
		jtag_add_runtest(info->bus_master_read_delay, TAP_IDLE);
		if (jtag_execute_queue() != ERROR_OK) {
			LOG_ERROR("Failed to scan idle sequence");
			return ERROR_FAIL;
		}
	}

	/* First value has been read, and is waiting for us to issue a DMI read
	 * to get it. */

Would not a better solution be to poll on sbusy and tiemout if it does not go low?
There is even a api for this read_sbcs_nonbusy()

The text was updated successfully, but these errors were encountered:

timsifive · 2023-07-10T17:36:19Z

Polling is slow, and usually unnecessary. Instead, the code attempts to learn how many run-test/idle cycles need to be inserted to avoid ever encountering a busy state. In doing so it might end up encountering busy for the first several attempts.

InspireSemi · 2023-07-11T04:59:26Z

polling guarantees that you are actually reading the data when you should and not when you should not...

JanMatCodasip · 2023-07-11T08:03:51Z

As @timsifive pointed out, the current code in read_memory_bus_v1() is very optimistic: It tries to read the whole requested block, and only at the very end it detects if there's been "system bus busy" situation encountered. If so, it tries to re-read the unread part of the block (starting from the point when the "busy" popped up) with higher bus_master_read_delay. So the function should behave correctly - at least based on my visual check of the current code.

Still, I think there is some room for improvement in that function:

Currently the bus_master_read_delay is applied only once -- after the first read of the block. But not after the subsequent reads within that block.
The read could be split to smaller blocks so that the "system bus busy" state is detected sooner - especially important when reading large memory blocks.
The code of the function could be re-structured (and perhaps split) for better readability.

@InspireSemi Please let us know if you think we missed something, and there is something to be fixed. Thanks.

InspireSemi · 2023-07-11T18:04:42Z

item 1 above is a good example of what I am talking about. You cannot guarantee that from read to read over a multi read transaction the delay will be the same. You can guarantee that if you poll you will get the data correctly at the correct time.

timsifive · 2023-07-11T21:43:53Z

In practice, this is much faster than always polling.

Do you have any problems with OpenOCD where this is a problem?

InspireSemi · 2023-07-12T04:11:03Z

Running in sim with remote bitbang in testbench has some issues. Marc Karasek Principal Software Engineer M: 678.770.3788 [A close up of a sign Description automatically generated] www.inspiresemi.com<http://www.cryptocoretech.com/> THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND/OR EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or agent responsible for delivering the message to the intended recipient, then you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please delete it from your system without copying it and notify the sender by reply e-mail so that our address record can be corrected. Thank you. From: Tim Newsome ***@***.***> Sent: Tuesday, July 11, 2023 5:44 PM To: riscv/riscv-openocd ***@***.***> Cc: Marc Karasek ***@***.***>; Mention ***@***.***> Subject: Re: [riscv/riscv-openocd] systembus read access.. (Issue #880) In practice, this is much faster than always polling. Do you have any problems with OpenOCD where this is a problem? — Reply to this email directly, view it on GitHub<https://url.avanan.click/v2/___https:/github.com/riscv/riscv-openocd/issues/880%23issuecomment-1631550719___.YXAzOmluc3BpcmVzZW1pOmE6bzpjMGJkM2ZkNDllYzgzNWNlNGYxYjEyYzMyMDUzNTlkOTo2OjRhMGE6OTc1NmIxNDYwOTUyNzZkZDRhZGQ2N2JiNmJjMGUxNTM1MDczMjEwMThkYWU2Y2NmZjQ1MTQ2YWQ2ZmRmMjQzYzpoOlQ>, or unsubscribe<https://url.avanan.click/v2/___https:/github.com/notifications/unsubscribe-auth/AR3S6Y46U3RILUBRR244SQTXPXCKJANCNFSM6AAAAAA2C5BHNQ___.YXAzOmluc3BpcmVzZW1pOmE6bzpjMGJkM2ZkNDllYzgzNWNlNGYxYjEyYzMyMDUzNTlkOTo2OjUzYzg6ZWI1ZmQzOTZhYjE0ZmU5MzRiYTE4ZTk1MDY3OTBmMjdhNDAxODM3ODM5ZTQwOWQ4ZDAwMDQ0MDgyYjM2OGJkNjpoOlQ>.You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

timsifive · 2023-07-12T17:58:01Z

What issues? Can you share an openocd -d log?

InspireSemi · 2023-07-19T20:34:36Z

There are a lot of issues when in Sim due to sim time being not the same as PC time.

TommyMurphyTM1234 · 2023-07-19T20:47:47Z

There are a lot of issues when in Sim due to sim time being not the same as PC time.

As @timsifive suggested above, whenever there are issues with OpenOCD debugging, a good first step is to collect a verbose log using openocd -d3.

MarcKarasek · 2023-10-24T01:58:55Z

I have found 1 issue with this read before sbbusy goes away. According to the spec if a read is in progress and another read is done then sbbusyerror will be set. By doign the read before checking that sbbusy is cleared you are triggering another read ( again according to the spec) this causes sbbusyerror to be set.

Set when the debugger attempts to read data
while a read is in progress, or when the debug-
ger initiates a new access while one is already in
progress (while sbbusy is set). It remains set until
it's explicitly cleared by the debugger.
While this eld is set, no more system bus accesses
can be initiated by the Debug Module.

On a read I do not see this getting cleared (per above) at the end of the read.

I and InspireSemi are the same person BTW

TommyMurphyTM1234 · 2023-10-24T10:54:47Z

I have found 1 issue with this read before sbbusy goes away. According to the spec if a read is in progress and another read is done then sbbusyerror will be set. By doign the read before checking that sbbusy is cleared you are triggering another read ( again according to the spec) this causes sbbusyerror to be set.

Set when the debugger attempts to read data while a read is in progress, or when the debug- ger initiates a new access while one is already in progress (while sbbusy is set). It remains set until it's explicitly cleared by the debugger. While this eld is set, no more system bus accesses can be initiated by the Debug Module.

On a read I do not see this getting cleared (per above) at the end of the read.

Do you have an openocd -d3 log for this scenario?

InspireSemi · 2023-10-24T13:24:45Z

I have a waveform that shows this happening. And if you follow the spec it will happen. You are reading the data prior to sbbusy being clear and this causes a dbl read. I can do a log. I have debug turned on in openocd and this shows as well the read of 0x3c prior to checking 0x38 ... and when 0x38 is checked the sbbusyerror bit is set (which it should be). Our reads are currently timing out and I need to debug this. Do not know at this point if this is related or not. But sbbusyerror imo should not be set at all except for a real error and this one is a forced error by the code. Sent from my T-Mobile 5G Device Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Tommy Murphy ***@***.***> Sent: Tuesday, October 24, 2023 6:54:59 AM To: riscv/riscv-openocd ***@***.***> Cc: Marc Karasek ***@***.***>; Mention ***@***.***> Subject: Re: [riscv/riscv-openocd] systembus read access.. (Issue #880) I have found 1 issue with this read before sbbusy goes away. According to the spec if a read is in progress and another read is done then sbbusyerror will be set. By doign the read before checking that sbbusy is cleared you are triggering another read ( again according to the spec) this causes sbbusyerror to be set. Set when the debugger attempts to read data while a read is in progress, or when the debug- ger initiates a new access while one is already in progress (while sbbusy is set). It remains set until it's explicitly cleared by the debugger. While this eld is set, no more system bus accesses can be initiated by the Debug Module. On a read I do not see this getting cleared (per above) at the end of the read. Do you have an openocd -d3 log for this scenario? — Reply to this email directly, view it on GitHub<https://url.avanan.click/v2/___https://github.com/riscv/riscv-openocd/issues/880%23issuecomment-1776981233___.YXAzOmluc3BpcmVzZW1pOmE6bzpkMmQ5OWQ0N2RkZDAxYjIwNGExMDYwMGEyZDBhNzYzZTo2OmY3Yjc6ZTQyOTU1NTkwNjcyOGY5NzJhMzVmMmFlMjQ2M2ViYjJjYjQzNmM1MGI0ZWYwMDllYzM3YzNlMjY1M2IzMTIwYTpoOlQ>, or unsubscribe<https://url.avanan.click/v2/___https://github.com/notifications/unsubscribe-auth/AR3S6Y6K73OVD5DPQBLWZXLYA6NAHAVCNFSM6AAAAAA2C5BHNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWHE4DCMRTGM___.YXAzOmluc3BpcmVzZW1pOmE6bzpkMmQ5OWQ0N2RkZDAxYjIwNGExMDYwMGEyZDBhNzYzZTo2Ojg2N2M6MDgxOGRhYjdiNjNiNWY3ZTg0MDJlM2U0MDc4NGNmODE1NGViOTU2MjkwYjI4MGNjNmVkZGMyYjg4NWVmMDZhODpoOlQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

InspireSemi · 2023-10-24T14:10:52Z

Here is the log from the section where I was doing a byte read from gdb : The highlighted sections are where it is writing first to 0x3a, 0x39 which will trigger a read as sbreadonaddr is set. This is followed by a read from 0x3C(data) prior to any polling/reading of 0x3C(sbcs). This triggers a second read while the first one is in progress. Which in turn causes the sbbusyerror in the sbcs to be set. Debug: 3566 20804568 gdb_server.c:375 gdb_log_incoming_packet(): [riscv.cpu] received packet: m110000000000,1 Debug: 3567 20804568 gdb_server.c:1510 gdb_read_memory_packet(): addr: 0x0000110000000000, len: 0x00000001 Debug: 3568 20804568 target.c:2438 target_read_buffer(): reading buffer of 1 byte at 0x110000000000 Debug: 3569 20804568 riscv.c:3218 riscv_set_current_hartid(): setting hartid to 0, was 0 Debug: 3570 20804568 riscv-013.c:4073 riscv013_get_register(): [riscv.cpu] reading register priv Debug: 3571 20804568 riscv.c:3218 riscv_set_current_hartid(): setting hartid to 0, was 0 Debug: 3572 20804568 riscv-013.c:785 execute_abstract_command(): command=0x3207b0; access register, size=64, postexec=0, transfer=1, write=0, regno=0x7b0 Debug: 3573 20806094 riscv-013.c:391 scan(): 90b w 003207b0 @17 -> + 00000382 @00; 0i Debug: 3574 20807627 riscv-013.c:391 scan(): 90b r 00000000 @16 -> + 00000382 @00; 0i Debug: 3575 20809032 riscv-013.c:391 scan(): 90b - 00000000 @16 -> + 00000004 @00; 0i Debug: 3576 20810557 riscv-013.c:391 scan(): 90b r 00000000 @04 -> + 00000004 @00; 0i Debug: 3577 20811938 riscv-013.c:391 scan(): 90b - 00000000 @04 -> + 00000000 @00; 0i Debug: 3578 20813451 riscv-013.c:391 scan(): 90b r 00000000 @05 -> + 00000000 @00; 0i Debug: 3579 20814893 riscv-013.c:391 scan(): 90b - 00000000 @05 -> + 00000000 @00; 0i Debug: 3580 20814893 riscv-013.c:1488 register_read_direct(): {0} dcsr = 0x0 Debug: 3581 20814893 riscv.c:3365 riscv_get_register(): [riscv.cpu] priv: 0 Debug: 3582 20814893 riscv-013.c:4073 riscv013_get_register(): [riscv.cpu] reading register mstatus Debug: 3583 20814893 riscv.c:3218 riscv_set_current_hartid(): setting hartid to 0, was 0 Debug: 3584 20814893 riscv-013.c:785 execute_abstract_command(): command=0x320300; access register, size=64, postexec=0, transfer=1, write=0, regno=0x300 Debug: 3585 20816426 riscv-013.c:391 scan(): 90b w 00320300 @17 -> + 00000000 @00; 0i Debug: 3586 20817955 riscv-013.c:391 scan(): 90b r 00000000 @16 -> + 00000000 @00; 0i Debug: 3587 20819366 riscv-013.c:391 scan(): 90b - 00000000 @16 -> + 00000004 @00; 0i Debug: 3588 20820896 riscv-013.c:391 scan(): 90b r 00000000 @04 -> + 00000004 @00; 0i Debug: 3589 20822306 riscv-013.c:391 scan(): 90b - 00000000 @04 -> + 00007800 @00; 0i Debug: 3590 20823838 riscv-013.c:391 scan(): 90b r 00000000 @05 -> + 00007800 @00; 0i Debug: 3591 20825245 riscv-013.c:391 scan(): 90b - 00000000 @05 -> + 8000000a @00; 0i Debug: 3592 20825245 riscv-013.c:1488 register_read_direct(): {0} mstatus = 0x8000000a00007800 Debug: 3593 20825245 riscv.c:3365 riscv_get_register(): [riscv.cpu] mstatus: 8000000a00007800 Debug: 3594 20825245 riscv-013.c:4073 riscv013_get_register(): [riscv.cpu] reading register satp Debug: 3595 20825245 riscv.c:3218 riscv_set_current_hartid(): setting hartid to 0, was 0 Debug: 3596 20825245 riscv-013.c:785 execute_abstract_command(): command=0x320180; access register, size=64, postexec=0, transfer=1, write=0, regno=0x180 Debug: 3597 20826767 riscv-013.c:391 scan(): 90b w 00320180 @17 -> + 8000000a @00; 0i Debug: 3598 20828293 riscv-013.c:391 scan(): 90b r 00000000 @16 -> + 8000000a @00; 0i Debug: 3599 20829735 riscv-013.c:391 scan(): 90b - 00000000 @16 -> + 00000004 @00; 0i Debug: 3600 20831263 riscv-013.c:391 scan(): 90b r 00000000 @04 -> + 00000004 @00; 0i Debug: 3601 20832673 riscv-013.c:391 scan(): 90b - 00000000 @04 -> + 00000000 @00; 0i Debug: 3602 20834174 riscv-013.c:391 scan(): 90b r 00000000 @05 -> + 00000000 @00; 0i Debug: 3603 20835581 riscv-013.c:391 scan(): 90b - 00000000 @05 -> + 00000000 @00; 0i Debug: 3604 20835581 riscv-013.c:1488 register_read_direct(): {0} satp = 0x0 Debug: 3605 20835581 riscv.c:3365 riscv_get_register(): [riscv.cpu] satp: 0 Debug: 3606 20835581 riscv.c:1560 riscv_mmu(): MMU is disabled. Debug: 3607 20837107 riscv-013.c:391 scan(): 90b w 00110000 @38 -> + 00000000 @00; 0i Debug: 3608 20837107 riscv-013.c:401 scan(): sbreadonaddr sbautoincrement -> Debug: 3609 20838515 riscv-013.c:391 scan(): 90b - 00000000 @38 -> + 00000000 @00; 0i Debug: 3610 20840059 riscv-013.c:391 scan(): 90b w 00001100 @3a -> + 00000000 @00; 0i Debug: 3611 20841588 riscv-013.c:391 scan(): 90b w 00000000 @39 -> + 00000000 @00; 0i Debug: 3612 20843036 riscv-013.c:391 scan(): 90b - 00000000 @39 -> + 00000000 @00; 0i Debug: 3613 20844585 riscv-013.c:391 scan(): 90b r 00000000 @3c -> + 00000000 @00; 0i Debug: 3614 20845993 riscv-013.c:391 scan(): 90b - 00000000 @3c -> + 00000000 @00; 0i Debug: 3615 20845993 riscv-013.c:2501 log_memory_access(): M[0x110000000000] reads 0x00 Debug: 3616 20847530 riscv-013.c:391 scan(): 90b r 00000000 @38 -> + 00000000 @00; 0i Debug: 3617 20848945 riscv-013.c:391 scan(): 90b - 00000000 @38 -> + 2071080f @00; 0i Debug: 3618 20850471 riscv-013.c:391 scan(): 90b r 00000000 @38 -> + 2071080f @00; 0i Debug: 3619 20851887 riscv-013.c:391 scan(): 90b - 00000000 @38 -> + 2071080f @00; 0i Debug: 3620 20853413 riscv-013.c:391 scan(): 90b r 00000000 @38 -> + 2071080f @00; 0i Debug: 3621 20854831 riscv-013.c:391 scan(): 90b - 00000000 @38 -> + 2071080f @00; 0i Debug: 3622 20856310 riscv-013.c:391 scan(): 90b r 00000000 @38 -> + 2071080f @00; 0i Marc Karasek Principal Software Engineer M: 678.770.3788 [A close up of a sign Description automatically generated] www.inspiresemi.com<http://www.cryptocoretech.com/> THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND/OR EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or agent responsible for delivering the message to the intended recipient, then you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please delete it from your system without copying it and notify the sender by reply e-mail so that our address record can be corrected. Thank you. From: Tommy Murphy ***@***.***> Sent: Tuesday, October 24, 2023 6:55 AM To: riscv/riscv-openocd ***@***.***> Cc: Marc Karasek ***@***.***>; Mention ***@***.***> Subject: Re: [riscv/riscv-openocd] systembus read access.. (Issue #880) I have found 1 issue with this read before sbbusy goes away. According to the spec if a read is in progress and another read is done then sbbusyerror will be set. By doign the read before checking that sbbusy is cleared you are triggering another read ( again according to the spec) this causes sbbusyerror to be set. Set when the debugger attempts to read data while a read is in progress, or when the debug- ger initiates a new access while one is already in progress (while sbbusy is set). It remains set until it's explicitly cleared by the debugger. While this eld is set, no more system bus accesses can be initiated by the Debug Module. On a read I do not see this getting cleared (per above) at the end of the read. Do you have an openocd -d3 log for this scenario? — Reply to this email directly, view it on GitHub<https://url.avanan.click/v2/___https:/github.com/riscv/riscv-openocd/issues/880%23issuecomment-1776981233___.YXAzOmluc3BpcmVzZW1pOmE6bzpkMmQ5OWQ0N2RkZDAxYjIwNGExMDYwMGEyZDBhNzYzZTo2OmY3Yjc6ZTQyOTU1NTkwNjcyOGY5NzJhMzVmMmFlMjQ2M2ViYjJjYjQzNmM1MGI0ZWYwMDllYzM3YzNlMjY1M2IzMTIwYTpoOlQ>, or unsubscribe<https://url.avanan.click/v2/___https:/github.com/notifications/unsubscribe-auth/AR3S6Y6K73OVD5DPQBLWZXLYA6NAHAVCNFSM6AAAAAA2C5BHNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWHE4DCMRTGM___.YXAzOmluc3BpcmVzZW1pOmE6bzpkMmQ5OWQ0N2RkZDAxYjIwNGExMDYwMGEyZDBhNzYzZTo2Ojg2N2M6MDgxOGRhYjdiNjNiNWY3ZTg0MDJlM2U0MDc4NGNmODE1NGViOTU2MjkwYjI4MGNjNmVkZGMyYjg4NWVmMDZhODpoOlQ>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

timsifive · 2023-10-24T17:31:09Z

The highlighted sections are where it is writing first to 0x3a, 0x39 which will trigger a read as sbreadonaddr is set. This is followed by a read from 0x3C(data) prior to any polling/reading of 0x3C(sbcs). This triggers a second read while the first one is in progress. Which in turn causes the sbbusyerror in the sbcs to be set.

The key is what OpenOCD does next. It's OK to encounter sbbusyerror like you described. In that case the OpenOCD code should increase the delay (run-test/idle cycles) it puts between scans and try the same memory operation again. Your log is cut off when sbbusyerror is first encountered. (I think you're probably in read_sbcs_nonbusy(), where we wait for riscv_command_timeout_sec waiting for sbbusy to go low. Presumably you put that timeout quite high. It might be a bug that we do this loop, in the sense that it wastes time but will eventually do the correct thing.) Does OpenOCD not retry correctly? Can you let it run a little further and share that log?

Based on the timestamps in your log, your target is outrageously slow, which matches with it being a simulation. It will take a lot of time for OpenOCD to discover the correct timing. Instead of going through this learning process every time (assuming it works) you could change the OpenOCD source (riscv-013.c, init_target()) to give bus_master_read_delay (and presumably bus_master_write_delay) higher default values.

InspireSemi · 2023-10-24T18:05:57Z

It just keeps polling 0x38 until it times out: It then tries abstract command. (I need to pull this from the .cfg as we only support systembus reads/writes) Need to debug a bit further on systembus reads/writes in rtl Debug: 5978 24440452 riscv-013.c:391 scan(): 90b r 00000000 @38 -> + 2071080f @00; 0i Debug: 5979 24441879 riscv-013.c:391 scan(): 90b - 00000000 @38 -> + 2071080f @00; 0i Debug: 5980 24443439 riscv-013.c:391 scan(): 90b r 00000000 @38 -> + 2071080f @00; 0i Debug: 5981 24444889 riscv-013.c:391 scan(): 90b - 00000000 @38 -> + 2071080f @00; 0i Debug: 5982 24446443 riscv-013.c:391 scan(): 90b r 00000000 @38 -> + 2071080f @00; 0i Debug: 5983 24447863 riscv-013.c:391 scan(): 90b - 00000000 @38 -> + 2071080f @00; 0i Error: 5984 24447863 riscv-013.c:2550 read_sbcs_nonbusy(): Timed out after 3600s waiting for sbbusy to go low (sbcs=0x2071080f). Increase the timeout with riscv set_command_timeout_sec. Warn : 5985 24447863 riscv-013.c:2843 log_mem_access_result(): Failed to read memory via system bus. Debug: 5986 24447863 riscv-013.c:2959 read_memory_abstract(): reading 1 words of 1 bytes from 0x110000000000 Debug: 5987 24449419 riscv-013.c:391 scan(): 90b w 00001100 @07 -> + 2071080f @00; 0i Debug: 5988 24450831 riscv-013.c:391 scan(): 90b - 00000000 @07 -> + 2071080f @00; 0i Debug: 5989 24452366 riscv-013.c:391 scan(): 90b w 00000000 @06 -> + 2071080f @00; 0i Debug: 5990 24453790 riscv-013.c:391 scan(): 90b - 00000000 @06 -> + 2071080f @00; 0i Debug: 5991 24453790 riscv-013.c:788 execute_abstract_command(): command=0x2080000 Debug: 5992 24455311 riscv-013.c:391 scan(): 90b w 02080000 @17 -> + 2071080f @00; 0i Debug: 5993 24455311 riscv-013.c:401 scan(): cmdtype=2 -> Debug: 5994 24456851 riscv-013.c:391 scan(): 90b r 00000000 @16 -> + 2071080f @00; 0i Debug: 5995 24458254 riscv-013.c:391 scan(): 90b - 00000000 @16 -> + 00000704 @00; 0i Debug: 5996 24458254 riscv-013.c:801 execute_abstract_command(): command 0x2080000 failed; abstractcs=0x704 Debug: 5997 24459842 riscv-013.c:391 scan(): 90b w 00000700 @16 -> + 00000704 @00; 0i Debug: 5998 24459842 riscv-013.c:401 scan(): cmderr=7 -> Debug: 5999 24461294 riscv-013.c:391 scan(): 90b - 00000000 @16 -> + 00000704 @00; 0i Debug: 6000 24461294 riscv-013.c:788 execute_abstract_command(): command=0x2000000 Debug: 6001 24462851 riscv-013.c:391 scan(): 90b w 02000000 @17 -> + 00000704 @00; 0i Debug: 6002 24462851 riscv-013.c:401 scan(): cmdtype=2 -> Debug: 6003 24464412 riscv-013.c:391 scan(): 90b r 00000000 @16 -> + 00000704 @00; 0i Debug: 6004 24465838 riscv-013.c:391 scan(): 90b - 00000000 @16 -> + 00000704 @00; 0i Debug: 6005 24465838 riscv-013.c:801 execute_abstract_command(): command 0x2000000 failed; abstractcs=0x704 Debug: 6006 24467394 riscv-013.c:391 scan(): 90b w 00000700 @16 -> + 00000704 @00; 0i Debug: 6007 24467394 riscv-013.c:401 scan(): cmderr=7 -> Debug: 6008 24468839 riscv-013.c:391 scan(): 90b - 00000000 @16 -> + 00000704 @00; 0i Warn : 6009 24468839 riscv-013.c:2843 log_mem_access_result(): Failed to read memory via abstract access. Error: 6010 24468839 riscv-013.c:3593 read_memory(): Target riscv.cpu: Failed to read memory (addr=0x110000000000) Error: 6011 24468839 riscv-013.c:3594 read_memory(): progbuf=disabled, sysbus=failed, abstract=failed Debug: 6012 24468839 gdb_server.c:392 gdb_log_outgoing_packet(): [riscv.cpu] sending packet: $00#60 Debug: 6013 24468839 riscv.c:2186 riscv_openocd_poll(): polling all harts Marc Karasek Principal Software Engineer M: 678.770.3788 [A close up of a sign Description automatically generated] www.inspiresemi.com<http://www.cryptocoretech.com/> THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND/OR EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or agent responsible for delivering the message to the intended recipient, then you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please delete it from your system without copying it and notify the sender by reply e-mail so that our address record can be corrected. Thank you. From: Tim Newsome ***@***.***> Sent: Tuesday, October 24, 2023 1:31 PM To: riscv/riscv-openocd ***@***.***> Cc: Marc Karasek ***@***.***>; Mention ***@***.***> Subject: Re: [riscv/riscv-openocd] systembus read access.. (Issue #880) The highlighted sections are where it is writing first to 0x3a, 0x39 which will trigger a read as sbreadonaddr is set. This is followed by a read from 0x3C(data) prior to any polling/reading of 0x3C(sbcs). This triggers a second read while the first one is in progress. Which in turn causes the sbbusyerror in the sbcs to be set. The key is what OpenOCD does next. It's OK to encounter sbbusyerror like you described. In that case the OpenOCD code should increase the delay (run-test/idle cycles) it puts between scans and try the same memory operation again. Your log is cut off when sbbusyerror is first encountered. (I think you're probably in read_sbcs_nonbusy(), where we wait for riscv_command_timeout_sec waiting for sbbusy to go low. Presumably you put that timeout quite high. It might be a bug that we do this loop, in the sense that it wastes time but will eventually do the correct thing.) Does OpenOCD not retry correctly? Can you let it run a little further and share that log? Based on the timestamps in your log, your target is outrageously slow, which matches with it being a simulation. It will take a lot of time for OpenOCD to discover the correct timing. Instead of going through this learning process every time (assuming it works) you could change the OpenOCD source (riscv-013.c, init_target()) to give bus_master_read_delay (and presumably bus_master_write_delay) higher default values. — Reply to this email directly, view it on GitHub<https://url.avanan.click/v2/___https:/github.com/riscv/riscv-openocd/issues/880%23issuecomment-1777704771___.YXAzOmluc3BpcmVzZW1pOmE6bzpmZGNmZGM2OWNhOTM1MmM2NjlhMmUyZjVmODc5OTRiYTo2OjQwYzU6NzU5NzJmZjc3ZjkxMTkyMmZjNjFkZWFmNGJjOTk1NWYzMzg1MjVlOTZhZThhNDU1ZDc4MDRmZTdjY2ExZDljMTpoOlQ>, or unsubscribe<https://url.avanan.click/v2/___https:/github.com/notifications/unsubscribe-auth/AR3S6Y2WAAUEEAVTPYBVDKDYA73ORAVCNFSM6AAAAAA2C5BHNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZXG4YDINZXGE___.YXAzOmluc3BpcmVzZW1pOmE6bzpmZGNmZGM2OWNhOTM1MmM2NjlhMmUyZjVmODc5OTRiYTo2OjkwYTI6NzQ3YjlhMzlkNjI0NmRhNDc5MWI1MWM2YTFmZTgzN2E0ODFmMjc4NmRjMTZhN2U4ZDk0ZmUzMTQxNGU1NWQ3ODpoOlQ>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

timsifive · 2023-10-26T20:52:31Z

There's definitely some bug(s) when encountering sbbusyerror. I'm hacking spike to replicate the problem, and will then look into exactly what OpenOCD is/should be doing.

InspireSemi · 2023-11-06T21:21:09Z

Did you find anything on this?

timsifive · 2023-11-06T21:23:21Z

Yes. AFAICT handling sbbusyerror worked poorly if at all. I'm making progress, but don't have something that handles all the cases yet

InspireSemi · 2023-11-06T21:28:03Z

Great! Are you going to be upstreaming this change to the other openocd? If not, I can pull the changes down and patch our version (based on the other openocd)… I have some changes myself for 64 bit support that no one has yet.. 😊 Marc Marc Karasek Principal Software Engineer M: 678.770.3788 [A close up of a sign Description automatically generated] www.inspiresemi.com<http://www.cryptocoretech.com/> THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND/OR EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or agent responsible for delivering the message to the intended recipient, then you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please delete it from your system without copying it and notify the sender by reply e-mail so that our address record can be corrected. Thank you. From: Tim Newsome ***@***.***> Sent: Monday, November 6, 2023 4:24 PM To: riscv/riscv-openocd ***@***.***> Cc: Marc Karasek ***@***.***>; Mention ***@***.***> Subject: Re: [riscv/riscv-openocd] systembus read access.. (Issue #880) Yes. AFAICT handling sbbusyerror worked poorly if at all. I'm making progress, but don't have something that handles all the cases yet — Reply to this email directly, view it on GitHub<https://url.avanan.click/v2/___https:/github.com/riscv/riscv-openocd/issues/880%23issuecomment-1796513461___.YXAzOmluc3BpcmVzZW1pOmE6bzplMzhmYmIxMDM0Nzg4NmM4NjZiN2I3MWQyNGZjZjE2Nzo2OjU1MmU6OWVkYWE2NThjNGY4ODFlNzAxMTQ0ZWVmZjg5YzM2ZTYzZmNkYmRkM2UxYjc4Yzg2MjQ5ZGE3ZmQ4NmY4Mzg3YjpoOlQ>, or unsubscribe<https://url.avanan.click/v2/___https:/github.com/notifications/unsubscribe-auth/AR3S6YYHGNSAJCX7GXMAAJLYDFINNAVCNFSM6AAAAAA2C5BHNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJWGUYTGNBWGE___.YXAzOmluc3BpcmVzZW1pOmE6bzplMzhmYmIxMDM0Nzg4NmM4NjZiN2I3MWQyNGZjZjE2Nzo2OmVkNWM6ZjFhYWQ0NWQ2YmI5NDRhODk0ZTYyNzUxNDQwZjhiY2M2ZTU5ZWExZWZjNjMxMzZiMmZiNTk4YTA3OTE2MjJmNTpoOlQ>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

InspireSemi · 2023-11-20T15:04:26Z

Will this be sent to the other openocd?

timsifive · 2023-11-21T21:57:23Z

Yes, eventually, but don't hold your breath. We have years of backlog and virtually no time is spent working on it.

en-sc · 2024-01-22T19:18:27Z

@InspireSemi, AFAIU the issue is resolved. I would like to close it.

InspireSemi · 2024-01-22T22:15:29Z

I just checked the ticket and it does not show a resolution. I would like to leave this up until a patch is available.. Marc Karasek Principal Software Engineer M: 678.770.3788 [A close up of a sign Description automatically generated] www.inspiresemi.com<http://www.cryptocoretech.com/> THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND/OR EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient or agent responsible for delivering the message to the intended recipient, then you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If you have received this electronic transmission in error, please delete it from your system without copying it and notify the sender by reply e-mail so that our address record can be corrected. Thank you. From: Evgeniy Naydanov ***@***.***> Sent: Monday, January 22, 2024 2:19 PM To: riscv/riscv-openocd ***@***.***> Cc: Marc Karasek ***@***.***>; Mention ***@***.***> Subject: Re: [riscv/riscv-openocd] systembus read access.. (Issue #880) @InspireSemi<https://url.avanan.click/v2/___https:/github.com/InspireSemi___.YXAzOmluc3BpcmVzZW1pOmE6bzo2OTdlY2IyMzc4YjJkY2EwMzgyODRmNDFkYzBlZWJhNDo2OmZlZTQ6ODA5MTYxNzBjM2EwMzQ5ZDAwYTg5MzIyOTRmMjUxZDllYTBlYTcxNjQ5M2IxNGEyZGM5ZmQ1NGZlMWIyM2I3MzpoOlQ>, AFAIU the issue is resolved. I would like to close it. — Reply to this email directly, view it on GitHub<https://url.avanan.click/v2/___https:/github.com/riscv/riscv-openocd/issues/880%23issuecomment-1904649617___.YXAzOmluc3BpcmVzZW1pOmE6bzo2OTdlY2IyMzc4YjJkY2EwMzgyODRmNDFkYzBlZWJhNDo2OjgzOTA6MmM5NjdhMzU5ZjM4MDEzZWMzMmUzMWQ3MzJhY2JlZDFkYjc4NjM5NDA3MjViNWE5YWVmMzYwMzI4MmIzYTM4NDpoOlQ>, or unsubscribe<https://url.avanan.click/v2/___https:/github.com/notifications/unsubscribe-auth/AR3S6Y3IVZHL25KWJUYA6ZLYP23Q7AVCNFSM6AAAAAA2C5BHNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBUGY2DSNRRG4___.YXAzOmluc3BpcmVzZW1pOmE6bzo2OTdlY2IyMzc4YjJkY2EwMzgyODRmNDFkYzBlZWJhNDo2OjAzMGU6ZTJiYjI0ZjZiYmZhYTU4MThkNjUwYmE4YTY1MDZmMTBjNDRiMzI5MDIyZmExNTkwMzI2Y2MyOTQzODJmOTczNTpoOlQ>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

InspireSemi · 2024-03-14T16:12:47Z

Pull request:
https://github.com/riscv-collab/riscv-openocd/pull/957/files/08182bfc6bfffa448dee1470676a676e496ed586
Fixes this issue

timsifive mentioned this issue Nov 7, 2023

target/riscv: Handle sbbusyerror in read_memory_bus_v1 #957

Merged

InspireSemi closed this as completed Mar 14, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

systembus read access.. #880

systembus read access.. #880

InspireSemi commented Jul 8, 2023

timsifive commented Jul 10, 2023

InspireSemi commented Jul 11, 2023

JanMatCodasip commented Jul 11, 2023 •

edited

Loading

InspireSemi commented Jul 11, 2023

timsifive commented Jul 11, 2023

InspireSemi commented Jul 12, 2023 via email

timsifive commented Jul 12, 2023

InspireSemi commented Jul 19, 2023

TommyMurphyTM1234 commented Jul 19, 2023

MarcKarasek commented Oct 24, 2023 •

edited

Loading

TommyMurphyTM1234 commented Oct 24, 2023

InspireSemi commented Oct 24, 2023 via email

InspireSemi commented Oct 24, 2023 via email

timsifive commented Oct 24, 2023

InspireSemi commented Oct 24, 2023 via email

timsifive commented Oct 26, 2023

InspireSemi commented Nov 6, 2023

timsifive commented Nov 6, 2023

InspireSemi commented Nov 6, 2023 via email

InspireSemi commented Nov 20, 2023

timsifive commented Nov 21, 2023

en-sc commented Jan 22, 2024

InspireSemi commented Jan 22, 2024 via email

InspireSemi commented Mar 14, 2024

systembus read access.. #880

systembus read access.. #880

Comments

InspireSemi commented Jul 8, 2023

timsifive commented Jul 10, 2023

InspireSemi commented Jul 11, 2023

JanMatCodasip commented Jul 11, 2023 • edited Loading

InspireSemi commented Jul 11, 2023

timsifive commented Jul 11, 2023

InspireSemi commented Jul 12, 2023 via email

timsifive commented Jul 12, 2023

InspireSemi commented Jul 19, 2023

TommyMurphyTM1234 commented Jul 19, 2023

MarcKarasek commented Oct 24, 2023 • edited Loading

TommyMurphyTM1234 commented Oct 24, 2023

InspireSemi commented Oct 24, 2023 via email

InspireSemi commented Oct 24, 2023 via email

timsifive commented Oct 24, 2023

InspireSemi commented Oct 24, 2023 via email

timsifive commented Oct 26, 2023

InspireSemi commented Nov 6, 2023

timsifive commented Nov 6, 2023

InspireSemi commented Nov 6, 2023 via email

InspireSemi commented Nov 20, 2023

timsifive commented Nov 21, 2023

en-sc commented Jan 22, 2024

InspireSemi commented Jan 22, 2024 via email

InspireSemi commented Mar 14, 2024

JanMatCodasip commented Jul 11, 2023 •

edited

Loading

MarcKarasek commented Oct 24, 2023 •

edited

Loading