svn@coreboot.org wrote:
Modified: coreboot-v3/arch/x86/intel/core2/init_cpus.c coreboot-v3/arch/x86/secondary.S Log: This is a trivial commit and I want to get other people to look at the code.
I can still get to linux but core1 is not work Modified: coreboot-v3/arch/x86/secondary.S =================================================================== --- coreboot-v3/arch/x86/secondary.S 2009-02-21 00:05:20 UTC (rev 1136) +++ coreboot-v3/arch/x86/secondary.S 2009-02-21 17:28:24 UTC (rev 1137) @@ -23,10 +23,9 @@ */ .text .globl _secondary_start, _secondary_start_end
- .balign 4096
_secondary_start: .code16
- .long 0
- .balign 4096 cli
This looks bogus.
/* Set the stack pointer */
- movl _secondary_start, %esp
- movl $_secondary_start-4,%eax
- movl 0x0(%eax),%esp
Why?
Stefan
In v2, the esp was loaded from a global variable defined in another module. We're running in CAR, no global variables, so what I do is copy the secondary_start to low 1M, as before, but put the stackpointer right before the start of the code.
hence:
/* Set the stack pointer */
movl _secondary_start, %esp
movl $_secondary_start-4,%eaxmovl 0x0(%eax),%esp
So the C code running on the BSP will put the stack pointer value right before the code. This (ought to) work -- secondary start is in ram at (for now) 0x5000.
I've verified that we're at least starting core1, but something else is going wrong. Not yet sure what.
Also I guess it's time to make printk smp-safe.
ron
one last note: the .S code has to be 4K aligned. Just FYI.
ron
On 21.02.2009 21:31 Uhr, ron minnich wrote:
one last note: the .S code has to be 4K aligned. Just FYI.
Yes, but probably before the entry point, not after it? Otherwise the CPU executes through up to 4k of add [bx+si],al
On 21.02.2009 21:31, ron minnich wrote:
Also I guess it's time to make printk smp-safe.
Cool! The big problem here is that you need locking and for that you need something which is shared between CPUs. IIRC this means storing the lock in CAR is a no-go on some processors.
Regards, Carl-Daniel
On 21.02.2009 21:39 Uhr, Carl-Daniel Hailfinger wrote:
On 21.02.2009 21:31, ron minnich wrote:
Also I guess it's time to make printk smp-safe.
Cool! The big problem here is that you need locking and for that you need something which is shared between CPUs. IIRC this means storing the lock in CAR is a no-go on some processors.
Yes. the locking mechanisms are all there but can not be used. (or they were, at some point)
The simplest way would be to use a scratchpad register of the chipset as a semaphore. That's rather safe but unless on PCIe it can not be done atomic.
On 21.02.2009 21:49, Stefan Reinauer wrote:
On 21.02.2009 21:39 Uhr, Carl-Daniel Hailfinger wrote:
On 21.02.2009 21:31, ron minnich wrote:
Also I guess it's time to make printk smp-safe.
Cool! The big problem here is that you need locking and for that you need something which is shared between CPUs. IIRC this means storing the lock in CAR is a no-go on some processors.
Yes. the locking mechanisms are all there but can not be used. (or they were, at some point)
The simplest way would be to use a scratchpad register of the chipset as a semaphore. That's rather safe but unless on PCIe it can not be done atomic.
What about scratchpad registers in the CPU which are guaranteed to be cache-coherent across multiple cores and processors?
Regards, Carl-Daniel
On Sat, Feb 21, 2009 at 2:45 PM, Carl-Daniel Hailfinger
What about scratchpad registers in the CPU which are guaranteed to be cache-coherent across multiple cores and processors?
Certainly on core 2 with one cpu we can use a scratchpad registers.
In the case of core 2 SMP startup, when we get to starting the AP core 1, memory is functional. It is possible that the cpu support code is going to need to provide a locking code framework of some sort, since when and how locks can be done varies quite a bit depending on cpu, chipset, and what part of coreboot we are executing.
ron
-
Carl-Daniel Hailfinger -
ron minnich -
Stefan Reinauer