From: Rob Landley <rob@landley.net>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Andreas Färber" <andreas.faerber@web.de>,
"Alexander Graf" <agraf@suse.de>,
"Ben Leslie" <benno@benno.id.au>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Allow ARMv7M to be started without a kernel
Date: Tue, 10 May 2011 00:36:22 -0500 [thread overview]
Message-ID: <4DC8CED6.9010502@landley.net> (raw)
In-Reply-To: <BANLkTi=a68YL=M696+3q0nU-6mjEfiGdvw@mail.gmail.com>
On 05/09/2011 10:50 AM, Peter Maydell wrote:
> On 9 May 2011 16:11, Alexander Graf <agraf@suse.de> wrote:
> [about -kernel, unless I've got confused]
>> The issue is that this is not how it works on real hardware. Grub won't just
>> load a vmlinux file and boot it. I'm not even sure how much exactly the
>> early entry code handles in Linux before it jumps to the ELF entry point.
>>
>> Either way, if you get something rolling that also ensures that it fails
>> when it's an ELF file that's not Linux, I'd be very open to it :).
>
> If we do that we need to document what the new way of doing "just load
> and jump to the entry point of my not-a-linux-kernel ELF image" is; at
> the moment for ARM that use case is supported by -kernel (the code
> specifically handles ELF images as not-kernels), so changing that would
> be a back-compatibility break...
Arm doesn't need nearly as much setup as x86, some boards just map flash
at the physical start address with a jump straight to the kernel entry
point.
On arm there's no legacy start mode, meaning no 16->32 bit transfer
requiring mmu initialization as part of the setup. (I believe arm
starts with a 1-1 virtual/physical mapping in the absence of initialized
page tables, or something like that.) The big black magic thing
coreboot/bios and uboot do is DRAM refresh, which QEMU simply doesn't
care about: we map dram from the host and it gets refreshed at that level.
So this behavior may actually be correct for Linux in the absence of a
device tree (which just means initializinng a register to point to it on
ppc, dunno what ARM does).
And if you feed in an "-append" option to set a kernel command line,
then you know it's a linux kernel. If we explicitly ask for more setup,
then you know to do more setup. (I think that bit still needs to be
written, I have to go read the code...)
Rob
next prev parent reply other threads:[~2011-05-10 5:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 8:23 [Qemu-devel] Allow ARMv7M to be started without a kernel Ben Leslie
2011-05-05 9:56 ` Peter Maydell
2011-05-05 12:03 ` Ben Leslie
2011-05-05 13:20 ` Peter Maydell
2011-05-05 23:26 ` Alexander Graf
2011-05-05 23:50 ` Rob Landley
2011-05-06 12:48 ` Alexander Graf
2011-05-08 14:10 ` Andreas Färber
2011-05-08 18:25 ` Rob Landley
2011-05-09 14:11 ` Alexander Graf
2011-05-09 15:50 ` Peter Maydell
2011-05-10 5:36 ` Rob Landley [this message]
2011-05-10 4:58 ` Rob Landley
2011-05-10 5:13 ` Alexander Graf
2011-05-10 23:29 ` Rob Landley
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=4DC8CED6.9010502@landley.net \
--to=rob@landley.net \
--cc=agraf@suse.de \
--cc=andreas.faerber@web.de \
--cc=benno@benno.id.au \
--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).