October 2005 - coreboot - mail.coreboot.org

RE: [LinuxBIOS] Latest commit - clarification
by Lu, Yinghai Oct. 26, 2005

Oct. 26, 2005

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@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(a)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(a)openbios.org [mailto: linuxbios-bounces(a)openbios.org <mailto:linuxbios-bounces@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(a)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.

1 0

RE: [LinuxBIOS] Latest commit - clarification
by Lu, Yinghai Oct. 26, 2005

Oct. 26, 2005

Done. -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Wednesday, October 26, 2005 10:48 AM To: Lu, Yinghai Cc: San Mehat; Eric W. Biederman; LinuxBIOS Subject: Re: [LinuxBIOS] Latest commit - clarification * Lu, Yinghai <yinghai.lu(a)amd.com> [051026 19:30]: > 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. > Yinghai, can you add that patch to the issue tracker? Stefan

1 0

RE: [LinuxBIOS] Latest commit - clarification
by Lu, Yinghai Oct. 26, 2005

Oct. 26, 2005

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(a)openbios.org [mailto:linuxbios-bounces@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(a)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.

3 2

[LinuxBIOS] Proposed change to amd/amdk8/incoherent_ht.c
by San Mehat Oct. 26, 2005

Oct. 26, 2005

While we're on the 'error handling' track, I also had an issue where 'ht_optimize_link()' was continually indicating that a reset was required and causing an endless reset loop. The culprit was the code which performs an 8 bit read to get the *current* frequency of the link and doesn't mask off the error bits next to the frequency bits (bits 0-4 are frequency, and bits 5-7 are error status). Once again, this was triggered by a transient error on the link (likely due to link retraining). Heres the patch: ****START CUT**** Index: incoherent_ht.c =================================================================== --- incoherent_ht.c (revision 2064) +++ incoherent_ht.c (working copy) @@ -198,12 +206,12 @@ freq = log2(freq_cap1 & freq_cap2); /* See if I am changing the link freqency */ - old_freq = pci_read_config8(dev1, pos1 + LINK_FREQ(offs1)); + old_freq = (pci_read_config8(dev1, pos1 + LINK_FREQ(offs1)) & 0x0f); // Mask off error bits needs_reset |= old_freq != freq; - old_freq = pci_read_config8(dev2, pos2 + LINK_FREQ(offs2)); + old_freq = (pci_read_config8(dev2, pos2 + LINK_FREQ(offs2)) & 0x0f); // Mask off error bits needs_reset |= old_freq != freq; - /* Set the Calulcated link frequency */ + /* Set the Calculated link frequency */ pci_write_config8(dev1, pos1 + LINK_FREQ(offs1), freq); pci_write_config8(dev2, pos2 + LINK_FREQ(offs2), freq); ***END CUT****

2 2

[LinuxBIOS] Latest commit - clarification
by San Mehat Oct. 26, 2005

Oct. 26, 2005

Hey Jason, Would you mind just chucking up an exec summary of all the changes?.. I'm trying to adapt our port to the new code and am trying to figure out whats going on ;) Mainly: set_apicid_cpuid_low() = gone start_other_cores() = gone __cpu_reset = gone get_apicid_base() = gone Actually, the __cpu_reset: thing looks broken on CAR systems... looking at the tyan s4882 board, the Config.lb <http://Config.lb> only brings in arch/i386/lib/cpu_reset.inc if we're NOT CAR.... We're basicaly doing everything as CAR. Are there more changes comming? or should we just start hacking to pick up the pieces? thanks man... ;) -san

2 3

RE: [LinuxBIOS] lnxi-merge complete
by Lu, Yinghai Oct. 26, 2005

Oct. 26, 2005

I mean you at least need to make sure you don't break the current code when you clean up or bring up new stuff. YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Wednesday, October 26, 2005 10:02 AM To: Lu, Yinghai Cc: Stefan Reinauer; Jason Schildt; linuxbios(a)openbios.org Subject: Re: [LinuxBIOS] lnxi-merge complete "Lu, Yinghai" <yinghai.lu(a)amd.com> writes: > Don't block me, I never broke the code. I totally object to the tone of this response. This shouldn't be about blocking anyone but about what things we can do to make the process work better for everyone. What tools can we build that will cut down on the number of brown paper bag incidents. A checkin hook that calls abuild.sh and ensures everything succeeds may be one way to stop build problem from ever being checked in. Which is what I believe Stefan was suggesting. Completely blocking people will make the problem worse as merges won't happen and the patch pressure will just build up. Or else changes will get dropped. Eric

1 0

[LinuxBIOS] Re: [linuxbios-checkins] r2079 - in trunk/LinuxBIOSv2: src/southbridge/amd/amd8111 util/abuild
by Stefan Reinauer Oct. 26, 2005

Oct. 26, 2005

* svn(a)openbios.org <svn(a)openbios.org> [051026 00:24]: > Author: jschildt > Date: 2005-10-26 00:24:46 +0200 (Wed, 26 Oct 2005) > New Revision: 2079 > > Modified: > trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111_usb2.c > trunk/LinuxBIOSv2/util/abuild/abuild.sh > Log: > - Fixed fat-finger typo enable - enabled Please do run abuild _before_ commit. > - Fixed abuild.sh to use larger size for ROM_IMAGE_SIZE. This will work for some, but fail for others. Some of the non-k8 boards. Stefan

1 0

RE: [LinuxBIOS] Latest commit - clarification
by Lu, Yinghai Oct. 25, 2005

Oct. 25, 2005

Don't worry, Please stay with the old code. After LNXI put back apic id lifting back, I will enable the CAR shortly in the public tree. YH ________________________________ From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of San Mehat Sent: Tuesday, October 25, 2005 4:59 PM To: LinuxBIOS Subject: [LinuxBIOS] Latest commit - clarification Hey Jason, Would you mind just chucking up an exec summary of all the changes?.. I'm trying to adapt our port to the new code and am trying to figure out whats going on ;) Mainly: set_apicid_cpuid_low() = gone start_other_cores() = gone __cpu_reset = gone get_apicid_base() = gone Actually, the __cpu_reset: thing looks broken on CAR systems... looking at the tyan s4882 board, the Config.lb only brings in arch/i386/lib/cpu_reset.inc if we're NOT CAR.... We're basicaly doing everything as CAR. Are there more changes comming? or should we just start hacking to pick up the pieces? thanks man... ;) -san

4 6

[LinuxBIOS] lnxi checkins
by Richard Smith Oct. 25, 2005

Oct. 25, 2005

I see... Log: - See Issue Tracker id-7 "lnxi-patch-7" Is this some sort of internal issue tracker at lnxi? Or did linuxbios gain one when I wasn't looking? -- Richard A. Smith

2 3

[LinuxBIOS] LNXI mega patch commits beginning
by Jason Schildt Oct. 25, 2005

Oct. 25, 2005

All, We're in a conference room going over the lnxi patches and will be commiting them to the repository over the next few minutes. Please stand by... --jason-- -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx

1 0