Closed bluewww closed 4 years ago
OpenOCD currently has no concept of debug index to hart id mapping. It assumes they're equal and, as you discovered, that they're continuous starting at 0. This is a problem and needs to be fixed. I have a bit of a backlog, however, and can't tell when I'll get to it.
If you want to take a look at this code, I would think the first step is to mess with riscv-013.c examine() so that it checks for the unavailable bits and doesn't terminate discovery. Then you have the problem that hart index 0 should be ignored altogether.
You may be able to work around this problem by explicitly specifying the hart id in the OpenOCD configuration file. See e.g.https://github.com/riscv/riscv-tests/blob/master/debug/targets/RISC-V/spike-2.cfg which configures core ID 0 and 1. I'm not sure if anything is going to break if the numbers aren't contiguous.
Don't you think we should establish a mapping between continuous "debug indices" to the existing harts in examine()
and then go from there?
Another (imo ugly) way, is to establish a one to one correspondence between "debug indices" to hart id and then do the stuff of ignoring the corresponding harts. Infact currently I'm setting RISCV_MAX_HARTS
to 1024 because in my setup, due to legacy reasons, the first available hart number might be as high as 992. This doesn't work for -rtos
though.
Yes, there should be a mapping from indices to harts.
Some day, when -rtos riscv
can go away and everybody will use -rtos hwthread
instead, then RISCV_MAX_HARTS can be gotten rid of altogether.
This is a duplicate of #278.
My (test)system has
hartid=0
unavailable,hartid=1
first existing hart,hartid=2,3,4...
nonexistent as allowed by the debug spec v0.13.1.See p.10
This happens when I try to run the tests (with
-rtos
)Working around that issue by forcing
xlen=32
. I get:whereas the last errors are being repeated.