Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
On 16 January 2012 23:31, andrzej zaborowski wrote: > On 16 January 2012 09:31, Peter Maydell wrote: >> [*] 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. > > In the last sentence you mean the SMP case, right? Hmm, I think I was a bit confused there. So (a) you're right that the non-SMP case doesn't have a platform dependency so it will work on anything that wants to call arm_load_kernel (including omap boards). (b) omap1-3 are all single core anyhow, and I don't know of anybody who's proposing to write an omap4 model right now (c) the currently-out-of-tree omap3 models don't call arm_load_kernel but instead have a model of the omap3 boot rom and just boot from SD card images like the real hardware. [It's (c) that I was vaguely thinking of when I wrote that remark.] -- PMM
Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
On 16 January 2012 09:31, Peter Maydell wrote: > On 16 January 2012 01:56, Alexander Graf wrote: >> >> On 13.01.2012, at 21:52, Peter Maydell wrote: >> >>> From: Evgeny Voevodin >>> >>> 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 0x1030, 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. In the last sentence you mean the SMP case, right? Cheers
Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
On 16 January 2012 01:56, Alexander Graf wrote: > > On 13.01.2012, at 21:52, Peter Maydell wrote: > >> From: Evgeny Voevodin >> >> 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 0x1030, 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
Re: [Qemu-devel] [Android-virt] [PATCH 03/12] hw/arm_boot.c: Make SMP boards specify address to poll in bootup loop
On 13.01.2012, at 21:52, Peter Maydell wrote: > From: Evgeny Voevodin > > 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 0x1030, 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? Alex
