From a73adb52410acb4b4b92f281920d14bd5c490fe4 Mon Sep 17 00:00:00 2001 From: Antonio Borneo Date: Fri, 14 Jan 2022 15:15:30 +0100 Subject: [PATCH] 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 Reviewed-on: https://review.openocd.org/c/openocd/+/6818 Tested-by: jenkins Reviewed-by: Daniel Goehring --- src/target/arm_adi_v5.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c index 5c3941b3fe..4d24e8f2fc 100644 --- a/src/target/arm_adi_v5.c +++ b/src/target/arm_adi_v5.c @@ -1522,8 +1522,11 @@ static int rtp_rom_loop(struct command_invocation *cmd, /* Recurse. "romentry" is signed */ target_addr_t component_base = base_address + (int32_t)(romentry & ARM_CS_ROMENTRY_OFFSET_MASK); retval = rtp_cs_component(cmd, ap, component_base, depth + 1); - if (retval != ERROR_OK) - return retval; + if (retval != ERROR_OK) { + /* TODO: do we need to send an ABORT before continuing? */ + LOG_DEBUG("Ignore error parsing CoreSight component"); + continue; + } } return ERROR_OK; -- 2.30.2