qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP bo


From: Peter Maydell
Subject: Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
Date: Mon, 16 Jan 2012 08:31:34 +0000

On 16 January 2012 01:56, Alexander Graf <address@hidden> wrote:
>
> On 13.01.2012, at 21:52, Peter Maydell wrote:
>
>> From: Evgeny Voevodin <address@hidden>
>>
>> The secondary CPU bootloader in arm_boot.c holds secondary CPUs in a
>> pen until the primary CPU releases them. Make boards specify the
>> address to be polled to determine whether to leave the pen (it was
>> previously hardcoded to 0x10000030, which is a Versatile Express/
>> Realview specific system register address).
>
> Is smp_boot implementing the same logic as hw/ppce500_spin.c? It
> looks like the normal u-boot way of waiting for a magic address
> to be written with boot info. What I don't understand is the WFI.
> How can you wait for an interrupt if the trigger is a memory
> write? Or are you actually getting IPIs?

Basically this code is implementing the boot-rom half of
what is technically a platform-specific contract[*] between
the boot rom and the Linux kernel. The kernel end has to
(a) write the secondary CPU's entry point into the register
being polled and (b) send the CPU a softirq (an IPI, in
other words). The WFI basically allows h/w to avoid running
3 cores at 100% when we're booting a uniprocessor OS.
So the arm_boot end has to (a) enable the CPU's interrupt
controller, (b) wait for interrupt, (c) get the entry point
and jump to it.

[*] realview, vexpress, highbank and exynos4 all do something
that's sufficiently similar that we can handle them all by
parameterising the secondary boot code a bit. omap is kinda
different but then we don't support -kernel with omap anyway.

-- PMM



reply via email to

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