This is not an issue with the CPU emulation, it is a bug in the gdb memory read/write path, which currently effectively always does its accesses as nonsecure. The CPU itself is correctly coming out of reset in secure mode and will be able to read the correct value of the register.
I suspect that the following change will fix this:
diff --git a/exec.c b/exec.c
index 6e875f0640a..2f0f40b0be6 100644
--- a/exec.c
+++ b/exec.c
@@ -3881,12 +3881,10 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
phys_addr += (addr & ~TARGET_PAGE_MASK);
if (is_write) { address_space_write_rom(cpu->cpu_ases[asidx].as, phys_addr,
- MEMTXATTRS_UNSPECIFIED,
- buf, l);
+ attrs, buf, l);
} else { address_space_rw(cpu->cpu_ases[asidx].as, phys_addr,
- MEMTXATTRS_UNSPECIFIED,
- buf, l, 0);
+ attrs, buf, l, 0);
}
len -= l;
buf += l;
I'll test it later today and send it as a proper patch if it works.
This is not an issue with the CPU emulation, it is a bug in the gdb memory read/write path, which currently effectively always does its accesses as nonsecure. The CPU itself is correctly coming out of reset in secure mode and will be able to read the correct value of the register.
I suspect that the following change will fix this: .2f0f40b0be6 100644 rw_debug( CPUState *cpu, target_ulong addr,
address_ space_write_ rom(cpu- >cpu_ases[ asidx]. as, phys_addr, UNSPECIFIED,
address_ space_rw( cpu->cpu_ ases[asidx] .as, phys_addr, UNSPECIFIED,
diff --git a/exec.c b/exec.c
index 6e875f0640a.
--- a/exec.c
+++ b/exec.c
@@ -3881,12 +3881,10 @@ int cpu_memory_
phys_addr += (addr & ~TARGET_PAGE_MASK);
if (is_write) {
- MEMTXATTRS_
- buf, l);
+ attrs, buf, l);
} else {
- MEMTXATTRS_
- buf, l, 0);
+ attrs, buf, l, 0);
}
len -= l;
buf += l;
I'll test it later today and send it as a proper patch if it works.