On Sat, 15 Feb 2025 at 18:24, Richard Henderson
<richard.hender...@linaro.org> wrote:
>
> On 2/14/25 18:16, Keith Packard via wrote:
> > The ROM images all get deleted as they've been loaded to memory, so we
> > can't go fetch the reset vector from there. Instead, fetch it from
> > memory. To make that work, we need to execute the delayed mmu setup
> > function tcg_commit_cpu as that wires up memory dispatching.
> >
> > Signed-off-by: Keith Packard <kei...@keithp.com>
> > ---
> > target/rx/cpu.c | 24 +++++++++++++++++++-----
> > 1 file changed, 19 insertions(+), 5 deletions(-)
>
> IIRC this is where the cpu needs to be part of the 3-phase reset process.
> ROM gets reset too, but with unspecified ordering wrt the cpu itself.
> By delaying the load of the reset vector to the reset_exit phase,
> you can always load from rom.
>
> I believe Peter most recently handled a very similar situation with armv7m.
v7m still does the same thing this patch does, where you call
rom_ptr_for_as() and look at the return value to see what's
going on -- see the code and comments in
target/arm/cpu.c:arm_cpu_reset_hold() ("Load the initial SP and PC").
Now that we do a full three phase reset for everything, I
think this probably could be cleaned up, but there's a
fair chance that there's some unexpected issue in there
that I won't find out until I try it. So I'm definitely
not going to require that somebody else does that before
I've had a go at it on the v7m code.
So I'm OK with this patch doing this the way it does,
except that I have one question: what's that
process_queued_cpu_work() call doing? We don't need
that on the Arm equivalent...
Also, if() statements always have braces in QEMU, even
if the body of the if is a single statement. But since
if you don't set env->pc it is zero anyway, you don't
need the if() at all I think and can directly set
env->pc unconditionally.
thanks
-- PMM
