All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dave@treblig.org>
To: qemu-arm@nongnu.org
Cc: alistair23@gmail.com, mdavidsaver@gmail.com
Subject: [Qemu-arm] v7m reset vs rom loading ordering
Date: Sat, 26 Dec 2015 19:07:59 +0000	[thread overview]
Message-ID: <20151226190759.GA8638@gallifrey> (raw)

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.

arm_cpu_reset does:
        rom = rom_ptr(0);
        if (rom) {
            /* Address zero is covered by ROM which hasn't yet been
             * copied into physical memory.
             */
            initial_msp = ldl_p(rom);
            initial_pc = ldl_p(rom + 4);
        } else {
            /* Address zero not covered by a ROM blob, or the ROM blob
             * is in non-modifiable memory and this is a second reset after
             * it got copied into memory. In the latter case, rom_ptr
             * will return a NULL pointer and we should use ldl_phys instead.
             */
            initial_msp = ldl_phys(s->as, 0);
            initial_pc = ldl_phys(s->as, 4);
        }

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.
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).

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.
What's the right fix here - is the 'rom_ptr(0)' that arm_cpu_reset
doing sane given that I've got an alias?   Or does the load need
to be delayed?

Dave
-- 
 -----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   |_______/

             reply	other threads:[~2015-12-28 20:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-26 19:07 Dr. David Alan Gilbert [this message]
2015-12-28 20:35 ` [Qemu-arm] v7m reset vs rom loading ordering Peter Maydell
2015-12-28 20:35   ` [Qemu-devel] " Peter Maydell
2016-01-03 20:07   ` Dr. David Alan Gilbert
2016-01-03 20:07     ` [Qemu-devel] " Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151226190759.GA8638@gallifrey \
    --to=dave@treblig.org \
    --cc=alistair23@gmail.com \
    --cc=mdavidsaver@gmail.com \
    --cc=qemu-arm@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.