[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target descriptio

From: Peter Maydell
Subject: Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
Date: Thu, 7 Aug 2014 16:39:22 +0100

On 7 August 2014 16:06, Richard W.M. Jones <address@hidden> wrote:
> On Thu, Aug 07, 2014 at 02:53:33PM +0100, Peter Maydell wrote:
>> I think the biggest difficulty is not the code to actually
>> do the switch but figuring out what the command line
>> UI to request "start in AArch32" ought to be and how that
>> then gets plumbed into the code to do the actual work.
> Out of interest, how do you do this on real hardware?

Depends what level you're thinking at. At the absolute
lowest level, the Cortex-A57 for instance has an input
signal that's sampled on reset that indicates whether it
starts in AArch32 or AArch64. (In QEMU terms that would
be a CPU QOM property.) I'd expect that most boards
in practice would just hardwire that, though, since the
first thing that runs is going to be board-specific bootrom
code and having that be multi-width would be pointless
when you can just have the bootrom start EL2 in
AArch32 if it really needs to.

I don't know what the typical boot loader does. For
UEFI the files it boots are PE/COFF so in theory
it could look at the header (but I'm told that at the
moment 64-bit UEFI simply assumes 64-bit kernels).
I think u-boot also currently assumes 64-bit kernels
if it's a 64-bit u-boot.

Basically virtual machines are about the only place
where you'd actually want to run a 32 bit kernel if
your hardware supports 64 bit. So the only precedent
we have here is kvmtool, which currently requires
you to pass a command line argument if you want
your 64-bit guest CPU to start in AArch32.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]