aboutsummaryrefslogtreecommitdiff
path: root/NEWS-0.4.0
diff options
context:
space:
mode:
authorAntonio Borneo <borneo.antonio@gmail.com>2022-01-14 15:15:30 +0100
committerAntonio Borneo <borneo.antonio@gmail.com>2022-05-14 08:53:35 +0000
commita73adb52410acb4b4b92f281920d14bd5c490fe4 (patch)
tree70180c80eb5affc49658230767f81799f78acd8d /NEWS-0.4.0
parentd4335071b8460b227889a3a2072df424eebb4e5e (diff)
downloadriscv-openocd-a73adb52410acb4b4b92f281920d14bd5c490fe4.zip
riscv-openocd-a73adb52410acb4b4b92f281920d14bd5c490fe4.tar.gz
riscv-openocd-a73adb52410acb4b4b92f281920d14bd5c490fe4.tar.bz2
arm_adi_v5: handle faulting entry in ROM table
ARM IHI0031F "Arm Debug Interface Architecture Specification" chapter C2.6.1 "BASE, Debug Base Address register" reports: A debugger must handle the following situations as non-fatal errors: - ... - An entry in the ROM Table points to a faulting location. - ... Typically, a debugger issues a warning if it encounters one of these situations. However, Arm recommends that it continues operating. An example of an implementation that might cause errors of this type is a system with static base address or ROM Table entries that enable entire subsystems to be disabled, for example by a tie-off input, packaging choice, fuse, or similar. Don't halt ROM table parsing if one entry causes an error; log the error condition and continue to next entry. Not sure if we have to send an ABORT before continuing. Change-Id: I94fdb5b175bfb07dde378149421582b7e7cd5b09 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Reviewed-on: https://review.openocd.org/c/openocd/+/6818 Tested-by: jenkins Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Diffstat (limited to 'NEWS-0.4.0')
0 files changed, 0 insertions, 0 deletions