Re: [Qemu-devel] [Qemu-arm] v7m reset vs rom loading ordering

[Peter Maydell]

(You forgot to cc qemu-devel, which meant this message got hung
up in the "people who haven't posted to qemu-arm yet end up in
the semi-automatic moderation" machinery, and nobody saw it because
there was no qemu-devel cc.)

On 26 December 2015 at 19:07, Dr. David Alan Gilbert <address@hidden> wrote:
> Hi,
>   I'm having problems with the v7m reset code happening before the loading
> of the ROM code, and hence getting the wrong starting location.
> I'm using the stm32f205 model (modified to take an m4 and change the
> sizes of ram/flash for the 401), with a board that's the same as the
> netduino. It has the stm's internal flash and an alias for that flash at
> address 0.

> I seem to be ending up on the bottom half of this (because of the alias?)
> and it ends up loading both 0, even though I can see load_elf has already
> been called.

This does AFAICT work for the stellaris boards, though it's all an
ugly hack for the fact we don't have a nice way to say "this happens
when the CPU comes out of reset" (and also no nice way for that to
interact with an attached debugger). I don't think that rom_ptr()
cares about whether the memory it's going to put the ROM into is an
alias or not, so that is probably a red herring.

> The reset gets called after the realize triggered in the netduino board's
> init function; but all that happens before the rom_check_and_register_reset
> is called and gets the ROM data in the right place.
>
> In Michael's world he has the extra comment (from 'remove extra cpu_reset'):
> +    /* Realizing cpu calls cpu_reset(), which must have rom image
> +     * already mapped to find the correct entry point.
> +     */
>
> so it sounds like the same problem, even in his world.
> (I've hit this both on head and head with Michael's patches from the
> start of December applied).

You shouldn't need to care about intermediate resets that happen at
realize time, because vl.c will do a system reset which should
include resetting the CPU and this should happen after the ROMs are
all properly present.

> I've bodged around this by adding a call to arm_load_kernel to armv7m_realize
> so that the arm reset handler is called and then doing a system_reset
> after I get to the hmp; but obviously that's not the fix.

Why does the system_reset from hmp work but the one done by vl.c
after machine creation not?

thanks
-- PMM