From: Alistair Francis <alistair23@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v1 1/1] target_arm: Make the reset rom_ptr a property
Date: Thu, 21 Aug 2014 18:35:00 +1000 [thread overview]
Message-ID: <CAKmqyKObLu0piQTCv7nyWVM+h+nbi_tdbw+QQ5CHUttgY96zyA@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA-ymT8Kb_Ewf=6beJCWTdYERzJTk5svWpZ-PAE8bm3=Xw@mail.gmail.com>
On Thu, Aug 21, 2014 at 6:01 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 21 August 2014 02:36, Alistair Francis <alistair23@gmail.com> wrote:
>> This allows the board to set the reset address, which is required
>> for some boards (the Netduino Plus 2 for example)
>>
>> Signed-off-by: Alistair Francis <alistair23@gmail.com>
>
> This looks a bit odd -- I'm pretty sure the hardware doesn't
> get only the reset address from an IMPDEF location.
> Are you sure this board doesn't actually have an IMPDEF
> reset value for the vector table offset register VTOR?
>
> Which CPU core is this, anyway? Googling suggests
> it's a Cortex-M4, and the M4 TRM suggests that VTOR
> always resets to 0.
I'm not sure what you mean about the IMPDEF reset value
in the VTOR. The actual board is a Netduino Plus 2, with an
STM32F405RG (which is a Cortex-M4, but I'm making do with
the M3 for the moment).
Not sure if this helps, but to quote the datasheet:
"The Cortex ® -M4 with FPU CPU always fetches the reset
vector on the ICode bus, which implies to have the boot space
available only in the code area (typically, Flash memory)."
The reason this is such a problem is that the Netduino Plus 2
maps memory to 0, but the memory that is mapped there can be changed.
The actual memory mappings are in different locations, the 0 address is more
of a pointer.
Thanks,
Alistair
>
> thanks
> -- PMM
next prev parent reply other threads:[~2014-08-21 8:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 1:36 [Qemu-devel] [PATCH v1 1/1] target_arm: Make the reset rom_ptr a property Alistair Francis
2014-08-21 1:40 ` Alistair Francis
2014-08-21 3:37 ` Peter Crosthwaite
2014-08-21 4:13 ` Alistair Francis
2014-08-21 10:55 ` Andreas Färber
2014-08-21 12:33 ` Peter Maydell
2014-08-21 12:37 ` Peter Crosthwaite
2014-08-21 12:40 ` Peter Maydell
2014-08-21 12:43 ` Peter Crosthwaite
2014-08-21 13:15 ` Christopher Covington
2014-08-21 13:18 ` Peter Maydell
2014-08-21 8:01 ` Peter Maydell
2014-08-21 8:35 ` Alistair Francis [this message]
2014-08-21 9:14 ` Peter Maydell
2014-08-21 12:09 ` Alistair Francis
2014-08-21 12:22 ` Peter Crosthwaite
2014-08-21 12:26 ` Alistair Francis
2014-08-21 12:24 ` Peter Maydell
2014-08-21 12:35 ` Peter Crosthwaite
2014-08-21 12:37 ` Alistair Francis
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=CAKmqyKObLu0piQTCv7nyWVM+h+nbi_tdbw+QQ5CHUttgY96zyA@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).