Open Alan-19950616 opened 3 months ago
As far as I know, the Could not fetch register "..."; remote failure reply 'E0E'
message is expected for non-existent/unimplemented CSRs. If you want to avoid it or it's causing you problems then you might need to use the riscv hide_csrs ...
command:
For some related discussion see also here:
These error messages cause the IDE register component to not display properly.
What exactly are you referring to here? What "IDE register component"?
If these registers are not available, why not automatically hide it, or just return a fixed value just like before. If return a ERROR value like what is handled now, in Eclipse embedded CDT register window the register value will be Could not fetch register "hstatus"; remote failure reply 'E0E'
which cause user confused.
If these registers are not available, why not automatically hide it
It's explained in the links that I posted previously. There's no obvious/reliable way to determine that certain CSRs are not available - e.g. during OpenOCD's "target examine" process using the misa
extension bits etc. Not all optional CSRs are keyed off a RISC-V extension.
or just return a fixed value just like before.
When before? That's not a good idea as it makes it look like such CSRs exist when they do not. And arbitrarily masking errors arising from back-end debugging interactions with the target isn't a good idea on my opinion. What happens if the debugger tries to access a CSR that does exist, the operation fails, but OpenOCD masks the error and pretends that it succeeded? Nothing good I would imagine.
If return a ERROR value like what is handled now, in Eclipse embedded CDT register window the register value will be
Could not fetch register "hstatus"; remote failure reply 'E0E'
which cause user confused.
Even if you use the riscv hide_csrs ...
command to hide the unavailable CSRs? E.g. via the relevant target or board specific OpenOCD script?
In my opinion it's at least as confusing/misleading, if not more so, to pretend to the user that some CSRs exist and have some default value when they do not.
Even if you use the riscv hide_csrs ... command to hide the unavailable CSRs? E.g. via the relevant target or board specific OpenOCD script?
For this, if this CPU is a chip, it will be ok, but if it is a soft-cpu run in FPGA, it will be hard to maintain different configuration files for different soft-cpu configs which may have different csrs exposed, I will prefer just one configuration file for all soft-cpu cores.
This will cause eclipse cdt debug register windows show like this:
Previous version of openocd, will not show so many errors.
For this, if this CPU is a chip, it will be ok, but if it is a soft-cpu run in FPGA, it will be hard to maintain different configuration files for different soft-cpu configs which may have different csrs exposed,
In that case it should be possible to arrange for the generation the riscv hide_csrs ...
list as an artefact of the FPGA implementation "build" process since all of the information needed is available in/from the HDL implementation?
Previous version of openocd, will not show so many errors.
What specific version?
In that case it should be possible to arrange for the generation the
riscv hide_csrs ...
list as an artefact of the FPGA implementation "build" process since all of the information needed is available in/from the HDL implementation?
For our case, it is not possible, this bit generation don't generate openocd configuration files, the openocd config file is just one file stay in the sdk distributed to others.
What specific version?
Our port is based on this commit https://github.com/riscv-collab/riscv-openocd/commit/52177592f9d3afc6a008f8e1b321cf74e823018f
For our case, it is not possible, this bit generation don't generate openocd configuration files, the openocd config file is just one file stay in the sdk distributed to others.
I meant that with some work the bitstream generation flow could be extended to extract the necessary info from the HDL implementation from which the riscv hide_csrs ...
list and target specific OpenOCD script could be generated.
Our port is based on this commit 5217759
Maybe create a PR that implements the functionality for unimplemented/missing CSRs that you think should be used and it can then be considered/reviewed as normal?
@fanghuaqi, are you using gdb_report_register_access_error disable
in your OpenOCD config?
This functionality was broken by https://review.openocd.org/c/openocd/+/7876. https://review.openocd.org/c/openocd/+/8228 should fix it, but it is not ready to be merged yet.
However, this does not change the fact that gdb_report_register_access_error disable
is a hack -- the error will not be reported when the access to another register (e.g. GPR) fails. I would strongly discourage you from using it.
Please, consider implementing the approach suggested by @TommyMurphyTM1234.
If you wish for OpenOCD config to stay constant, you can use Jim TCL's json extension and parse a JSON file that would specify the list of CSRs to hide in the OpenOCD script.
@fanghuaqi, are you using
gdb_report_register_access_error disable
in your OpenOCD config?
Just to note that disable
is the default setting for this option so if that's the preferred option then it doesn't need to be explicitly specified.
@fanghuaqi, are you using
gdb_report_register_access_error disable
in your OpenOCD config?Just to note that
disable
is the default setting for this option so if that's the preferred option then it doesn't need to be explicitly specified.
Yes, I am using this option's default feature.
These error messages cause the IDE register component to not display properly.
https://github.com/riscv-collab/riscv-openocd/commit/236c54c94a53ff76537a1bf91cfe74a264a2756f
This is part of the gdb output: