Memory Sampling support when sbasize is zero.

[RaamyPi]

From the RISC-V Debug Specification (ratified February 2025), in the definition of the sbcs register, the sbasize field is defined (Page 44, Table on top) as:

sbasize : Width of system bus addresses in bits. (0 indicates there is no bus access support.)

But these lines in riscv-013.c, where sbasize is examined to return status about implementation support for memory sampling, do not include the case when sbasize is zero.

if (sbasize > 64) {
LOG_TARGET_ERROR(target, "Memory sampling is only implemented for sbasize <= 64.");
return ERROR_NOT_IMPLEMENTED;
}

This behaviour was observed when trying MemorySample tests from the RISC-V Debug Test suite on a design with only Program Buffer support.

The following patch fixes the issue:

if (sbasize == 0 || sbasize > 64)

Thanks.

[en-sc]

@RaamyPi, thank you for the report!

Unfortunately, I don't quite understand what is the issue you are having.

AFAIU, you are trying to run memory sampling tests on a target that does not support System Bus Memory access. Currently, the only supported access type for memory sampling is System Bus access.
Is the error you are getting not descriptive enough? Could you please attach OpenOCD's output?

[RaamyPi]

@en-sc thank you for the prompt response, appreciate it.

Currently, the only supported access type for memory sampling is System Bus access.

Yes, you are absolutely right.

Is the error you are getting not descriptive enough?

That's my entire issue, I am not getting an error.

Since my design only supports Program Buffer, I have tied sbasize to zero, to indicate no support for System Bus. When this sample_memory_bus_v1 function is called, openocd must return ERROR_NOT_IMPLEMENTED since I don't support System Bus (and hence Memory Sampling), correct? But since the checks don't cover the value zero, I never get an error. And as a result, it is assumed that my design supports memory sampling (when it is not actually the case) and the test proceeds to eventually fail, whereas it would have not proceeded had openocd returned an error indicating that the implementation does not support memory sampling.

I hope this clears things up. Please let me know in case it does not, I will attach some logs.

[en-sc]

@RaamyPi, please, attach the output of OpenOCD in your scenario.

The thing is -- tests from rescv-tests/debug do not analyze the error code returned by an OpenOCD command -- they only check the output.

You need to explicitly tell that your platform does not support system bus access. See:
https://github.com/riscv-software-src/riscv-tests/blob/b5ba87097c42aa41c56657e0ae049c2996e8d8d8/debug/targets/RISC-V/spike32.py#L18
https://github.com/riscv-software-src/riscv-tests/blob/b5ba87097c42aa41c56657e0ae049c2996e8d8d8/debug/gdbserver.py#L888-L889

Since my design only supports Program Buffer, I have tied sbasize to zero, to indicate no support for System Bus. When this sample_memory_bus_v1 function is called, openocd must return ERROR_NOT_IMPLEMENTED

Not really, AFAIU ERROR_NOT_IMPLEMENTED indicates that the feature is not implemented in OpenOCD. Here something like ERROR_TARGET_RESOURCE_NOT_AVAILABLE would be more appropriate. In any case the testsuite you are using does not care about the return code and only checks output.

I never get an error

What is read then? A bunch of zeroes?

[RaamyPi]

The thing is -- tests from rescv-tests/debug do not analyze the error code returned by an OpenOCD command -- they only check the output.

You're right, the tests are not looking for error codes from openocd but it does look at messages that openocd sends to gdb which helps debugging (which is what's lacking in this case).

You need to explicitly tell that your platform does not support system bus access. See: https://github.com/riscv-software-src/riscv-tests/blob/b5ba87097c42aa41c56657e0ae049c2996e8d8d8/debug/targets/RISC-V/spike32.py#L18 https://github.com/riscv-software-src/riscv-tests/blob/b5ba87097c42aa41c56657e0ae049c2996e8d8d8/debug/gdbserver.py#L888-L889

I am aware of this field in config files, it was intentionally modified to analyse behaviour when there's a misconfiguration, that was the entire point of this experiment.

Not really, AFAIU ERROR_NOT_IMPLEMENTED indicates that the feature is not implemented in OpenOCD. Here something like ERROR_TARGET_RESOURCE_NOT_AVAILABLE would be more appropriate. In any case the testsuite you are using does not care about the return code and only checks output.

I am not insisting that a specific error code be used. All I am trying to say is - openocd's checks should be stricter.

It is very possible for someone to miss this setting in the config file like you mentioned. But we don't even have to go there, what if someone tried memory sampling manually? Some mixup in the openocd config files led them to believe they were using sysbus when in fact they were not - does this scenario look very far fetched? In any case, don't you think having this extra check might help someone save time debugging?

Here is how openocd behaves now:
[riscv.cpu] Found 4 triggers
[riscv.cpu] Turning off memory sampling because it failed.

Here is how openocd behaves after the suggested patch:
[riscv.cpu] Found 4 triggers
[riscv.cpu] Memory sampling is only implemented for non-zero sbasize <= 64.
[riscv.cpu] Failed to read memory (addr=0x80000c7c)
[riscv.cpu] progbuf=skipped (target not halted), sysbus=disabled, abstract=disabled
[riscv.cpu] Turning off memory sampling because it failed.

Thanks.

[en-sc]

@RaamyPi, I do agree -- the error messaging can be improved. Please, submit the patch if you have the time.

[RaamyPi]

Sure, here's the patch that worked for us, corresponding lines.

- if (sbasize > 64) {
- LOG_TARGET_ERROR(target, "Memory sampling is only implemented for sbasize <= 64.");
+ if (sbasize == 0 || sbasize > 64) {
+ LOG_TARGET_ERROR(target, "Memory sampling is only implemented for non-zero sbasize <= 64.");

Hope this helps, thank you.