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

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 <dave@treblig.org> 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

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

[Dr. David Alan Gilbert]

[-- Attachment #1: Type: text/plain, Size: 4324 bytes --]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> (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.)

Thanks, I hadn't realised the two were tied together.

> On 26 December 2015 at 19:07, Dr. David Alan Gilbert <dave@treblig.org> 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.

Hmm; it does work with Stellaris, both with a binary file (the ./qs_ek-lm3s6965.bin
you posted in a link a few weeks back) and an ELF; but for Netduino it only
works with a binary file, an ELF file doesn't work, without the extra reset I add.
I *think* this is because of the alias but I'm not yet 100% sure.

> > 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?

It looks like what I see with elf on netduino is:
   a) An initial reset
   b) vl.c calls qemu_system_reset->qemu_devices_reset
     b1) That calls arm_cpu_reset
     b2) Then it calls rom_reset

In both (a) and (b1) the arm_cpu_reset gets NULL from rom_ptr and
does the ldl_phys and before rom_reset the ldl_phys(0) is returning 0;
that address is from the alias.   rom_reset (b2) seems to actually copy
the data.
If I do another system_reset then  arm_cpu_reset is called again and now
it's already had a rom_reset, so it gets the right value (still
getting NULL from rom_ptr).

If I give the netduino a binary then rom_ptr is giving a pointer
on the 2nd reset.

That's testing 2.5 with:
   qemu-system-arm -M netduino2 -kernel fiddle.elf


My ELF has the code loaded into the ROM, but doesn't touch the
alias address in the ELF.

Is there any way to guarantee that rom_reset gets called before the 
(last) CPU reset?  Then we could also remove the test using rom_ptr.

Dave
P.S. I've attached the elf I'm using, it wont get much further
even when it does load the right start address, it needs a bunch
of stm32 hardware we don't have upstream.

> 
> thanks
> -- PMM
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

[-- Attachment #2: fiddle.elf --]
[-- Type: application/octet-stream, Size: 141440 bytes --]