[coreboot] Init for multi-processor

[Kyösti Mälkki]

On Tue, 2011-11-22 at 15:17 +0900, Stefan Reinauer wrote:
> On Tue, 22 Nov 2011 08:01:01 +0200, Kyösti Mälkki wrote:
> > On Tue, 2011-11-22 at 06:30 +0900, Stefan Reinauer wrote:
> >> On 11/22/11 5:20 AM, Kyösti Mälkki wrote:
> >> > Hi
> >> >
> >> > Could someone explain the use of boot_cpu() in bootblock_normal.c
> >> > main()? I thought only the BSP CPU executes this code (currently)?
> >> >
> >> > I am about to push a change that does early SMP init for 
> >> hyper-threading
> >> > CPUs to allow cache-as-ram implementation. Shared cache remains 
> >> disabled
> >> > until both/all logical CPUs enable it.
> >> >
> >> For some CPUs types (like AMD K8) all CPUs / cores start running the
> >> reset vector code after power-on.
> >>
> >> Stefan
> >
> > Do the BSP CPU and/or AP CPUs execute bootblock_normal: main() and
> > mainboard/romstage: cache_as_ram_main() in parallel then?
> >
> > Remember there are no semaphores for shared resources like
> > CMOS_BOOT_BYTE in do_normal_boot() nor any spinlocks for
> > pci_write_config() etc.
> 
>  non-AP CPUs have to make sure they don't do (non-memory mapped) PCI 
>  config space access cycles.
>  This has actually been an issue before and it is a very bad idea to run 
>  rom stage on all CPUs.
>  reading CMOS_BOOT_BYTE should be fine. Writing to it should only happen 
>  on the BSP.
> 
>  A lot of K8 boards send their non-BSP processors to sleep in romstage.
> 
>  Stefan

Then the current bootblock_normal.c and bootblock_common.h are a bit
questionable, also AP CPUs do CMOS writes. Reading CMOS is safe only as
long as just that one CMOS_BOOT_BYTE is addressed.

The bootblock_common.h directives redefine boot_cpu(). I would
understand a non-SMP case where the only CPU may not have a lapic, but
otherwise, why?

Kyösti