[LinuxBIOS] Latest commit - clarification

[Lu, Yinghai]

You need to use 1025_enable_CAR_init_cpus_get_apicid_base.diff.

 

The 1025_enable_CAR.diff missed init_cpus.

 

YH

 

________________________________

From: San Mehat [mailto:san at google.com] 
Sent: Wednesday, October 26, 2005 11:02 AM
To: Lu, Yinghai
Cc: Eric W. Biederman; LinuxBIOS
Subject: Re: [LinuxBIOS] Latest commit - clarification

 

YH,

I've applied your patch, and started porting some of the bits over from
the s2895 code, however it looks like I'm missing
"cpu/amd/model_fxx/init_cpus.c" or wherever 'init_cpus()' is defined.

The cleanups look pretty damned good so far though... still trying to
get building to work...

Kudos anyawys ;)

-san



On 10/26/05, Lu, Yinghai <yinghai.lu at amd.com> wrote:

San,

 

Please check the patch for CAR

1.	add cpu_init_detectedx, it is passed from cache_as_ram.inc and
to amd64_main... 
2.	add init_cpus for CAR ---more readable
3.	post_cache_as_ram   ---> make cache_as_ram_auto.c shorter....
4.	renable get_apicid_base, in case some one still want BSP apid id
=0 but other cpu is lifted.

 

YH

 

________________________________

From: linuxbios-bounces at openbios.org [mailto:
linuxbios-bounces at openbios.org <mailto:linuxbios-bounces at openbios.org> ]
On Behalf Of San Mehat
Sent: Wednesday, October 26, 2005 9:55 AM
To: Eric W. Biederman
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] Latest commit - clarification

 

 

On 10/25/05, Eric W. Biederman <ebiederman at lnxi.com> wrote:

killing get_apicid_base looks like a bug.
But as far as I can tell everything that is gone is now unnecessary. 


Okay... so what replace start_other_cores()?.. In CAR mode, do I make a
call to 'do_k8_init_and_stop_secondaries()'?
That code itself wont build due to the following in
'k8_init_and_stop_secondaries()':
  if (init_detected) {
                asm volatile ("jmp __cpu_reset");
        }

because in CAR configs, arch/i386/lib/cpu_reset.inc is not included. On
this particular issue, I'm happy to wait for YH's fixes.

I just think if we're going to deprecate a core call like that, there
should be some documentation on *why* it was removed, as well as some
indication as to where the behavior got 'moved' to.

It just makes things a lot easier for thoes of us that are either
ramping up, or trying to maintain things..

Thanks Eric ;)

-san

PS: I'm still going to get you drunk and shave your beard.

 

 




 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051026/819f4c32/attachment.html>