coreboot October 2011

coreboot@coreboot.org

46 participants
501 discussions

Patch set updated for coreboot: b92ae6b Fixed broken MTRR for >4GB memory on AMD K8 fam 0fh rev <=E
by Oskar Enoksson 07 Oct '11

07 Oct '11

Oskar Enoksson (enok(a)lysator.liu.se) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/238 -gerrit commit b92ae6b8fd0dba5ac8472ce91c7a0a2b5f6e774c Author: Oskar Enoksson <enok(a)lysator.liu.se> Date: Thu Oct 6 18:21:19 2011 +0200 Fixed broken MTRR for >4GB memory on AMD K8 fam 0fh rev <=E AMD K8 rev F and later implements a bit SYSCFG_MSR_TOM2WB in SYSCFG_MSR to mark dram memory above 4GB as WB. However, AMD K8 rev E and earlier don't implement this bit and therefore need MTRR spanning dram memory above 4GB. The current implementation of amd_setup_mtrrs never generate MTRR above 4GB. This caused memory > 4GB not to be recognized in e.g. Linux on those rev E or older platforms. This commit should fix that bug. I use the value of CONFIG_K8_REV_F_SUPPORT (I hope I've understood it's meaning correctly). Signed-off-by: Oskar Enoksson <enok(a)lysator.liu.se> Change-Id: Ie568a52a8eb355969c86964d5afc4692e60f69c1 --- src/cpu/amd/mtrr/amd_mtrr.c | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/src/cpu/amd/mtrr/amd_mtrr.c b/src/cpu/amd/mtrr/amd_mtrr.c index 623a344..6066284 100644 --- a/src/cpu/amd/mtrr/amd_mtrr.c +++ b/src/cpu/amd/mtrr/amd_mtrr.c @@ -113,7 +113,6 @@ void amd_setup_mtrrs(void) unsigned long i; msr_t msr, sys_cfg; - /* Enable the access to AMD RdDram and WrDram extension bits */ disable_cache(); sys_cfg = rdmsr(SYSCFG_MSR); @@ -168,7 +167,10 @@ void amd_setup_mtrrs(void) msr.hi = state.tomk >> 22; msr.lo = state.tomk << 10; wrmsr(TOP_MEM2, msr); - sys_cfg.lo |= SYSCFG_MSR_TOM2En | SYSCFG_MSR_TOM2WB; + sys_cfg.lo |= SYSCFG_MSR_TOM2En; +#if CONFIG_K8_REV_F_SUPPORT == 1 + sys_cfg.lo |= SYSCFG_MSR_TOM2WB; +#endif } /* zero the IORR's before we enable to prevent @@ -201,5 +203,13 @@ void amd_setup_mtrrs(void) /* Now that I have mapped what is memory and what is not * Setup the mtrrs so we can cache the memory. */ + + // Rev. F K8 supports has SYSCFG_MSR_TOM2WB and dont need + // variable MTRR to span memory above 4GB + // Lower revisions K8 need variable MTRR over 4GB +#if CONFIG_K8_REV_F_SUPPORT == 1 x86_setup_var_mtrrs(address_bits, 0); +#else + x86_setup_var_mtrrs(address_bits, 1); +#endif }

1 0

Patch set updated for coreboot: 9a43592 Don't do a call as the first instruction in libpayload.
by Marc Jones 07 Oct '11

07 Oct '11

Marc Jones (marcj303(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/240 -gerrit commit 9a4359203d961e591e8f3dfe32045608117c918a Author: Marc Jones <marcj303(a)gmail.com> Date: Thu Oct 6 16:38:35 2011 -0600 Don't do a call as the first instruction in libpayload. Doing a call before the payload has set up its stack is risky. The stack may not be in a favorable location. Normally this is not an issue with coreboot or other well behaved callers. Change-Id: Ie6f6748a471324b29ebad045c807dfc9f4b92034 Signed-off-by: Marc Jones <marcj303(a)gmail.com> --- payloads/libpayload/arch/i386/head.S | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/payloads/libpayload/arch/i386/head.S b/payloads/libpayload/arch/i386/head.S index 88db412..3dd6133 100644 --- a/payloads/libpayload/arch/i386/head.S +++ b/payloads/libpayload/arch/i386/head.S @@ -38,10 +38,7 @@ * change anything. */ _entry: - call _init - - /* We're back - go back to the bootloader. */ - ret + jmp _init .align 4 @@ -66,6 +63,9 @@ _init: /* No interrupts, please. */ cli + /* There is a bunch of stuff missing here to take arguments on the stack + * See http://www.coreboot.org/Payload_API and exec.S. + */ /* Store current stack pointer. */ movl %esp, %esi

1 0

New patch to review for coreboot: f58d203 Don't do a call as the first instruction in libpayload.
by Marc Jones 07 Oct '11

07 Oct '11

Marc Jones (marcj303(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/240 -gerrit commit f58d203a35b5a75feb3a17319a83d41385852a9f Author: Marc Jones <marcj303(a)gmail.com> Date: Thu Oct 6 16:38:35 2011 -0600 Don't do a call as the first instruction in libpayload. Doing a call before the payload has set up its stack is risky. The stack may not be in a favorable location. Normally this is not an issue with coreboot or other well behaved callers. Change-Id: Ie6f6748a471324b29ebad045c807dfc9f4b92034 Signed-off-by: Marc Jones <marcj303(a)gmail.com> --- payloads/libpayload/arch/i386/head.S | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/payloads/libpayload/arch/i386/head.S b/payloads/libpayload/arch/i386/head.S index 88db412..3dd6133 100644 --- a/payloads/libpayload/arch/i386/head.S +++ b/payloads/libpayload/arch/i386/head.S @@ -38,10 +38,7 @@ * change anything. */ _entry: - call _init - - /* We're back - go back to the bootloader. */ - ret + jmp _init .align 4 @@ -66,6 +63,9 @@ _init: /* No interrupts, please. */ cli + /* There is a bunch of stuff missing here to take arguments on the stack + * See http://www.coreboot.org/Payload_API and exec.S. + */ /* Store current stack pointer. */ movl %esp, %esi

1 0

FID/VID change and display flicker
by Rudolf Marek 06 Oct '11

06 Oct '11

Hi all, I finally moved my desktop to the Asrock socket 939 board with 785G/SB700 + coreboot. So far even with 6 harddrives and 2GB RAM everything works :) I only noticed a flicker if CPU freq/voltage changes. I briefly chekced the LDTSTOP settings in SB and also in HTIU in NB so far it makes sense. Is it a bug or feature? I admit I did not check with original BIOS. Thanks Rudolf

2 3

Re: [coreboot] New patch to review for coreboot: 1c4e003 Fixed broken MTRR for >4GB memory on AMD K8 fam 0fh rev <=E
by Oskar Enoksson 06 Oct '11

06 Oct '11

On 10/06/2011 06:51 PM, yhlu wrote: > On Thu, Oct 6, 2011 at 9:26 AM, Oskar Enoksson<gerrit(a)coreboot.org> wrote: >> - >> + // Test if this CPU is a Fam 0Fh rev. F or later >> + const int is_revF = >> + ((cpuid_eax(0x80000001)&0x00000f00)>>8>= 0xf) || >> + (((cpuid_eax(0x80000001)&0x00000f00)>>8 == 0xf)&& >> + ((cpuid_eax(0x80000001)&0x000f0000)>>16>= 0x4)); >> + if(is_revF) >> + printk(BIOS_DEBUG, "Detected CPU Fam 0Fh rev.F or later\n"); > should be configuration option instead of run-time checking. > > There is no MB that will support revE and revF at same time. they are > different sockets > > Yinghai So, is it CONFIG_K8_REV_F_SUPPORT == 1 I should use?

1 0

Patch set updated for coreboot: 4780961 Fixed broken MTRR for >4GB memory on AMD K8 fam 0fh rev <=E
by Oskar Enoksson 06 Oct '11

06 Oct '11

Oskar Enoksson (enok(a)lysator.liu.se) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/238 -gerrit commit 478096179cbc7c777641dda7ac1a7f1cce7d400e Author: Oskar Enoksson <enok(a)lysator.liu.se> Date: Thu Oct 6 18:21:19 2011 +0200 Fixed broken MTRR for >4GB memory on AMD K8 fam 0fh rev <=E AMD K8 rev F and later implements a bit SYSCFG_MSR_TOM2WB in SYSCFG_MSR to mark dram memory above 4GB as WB. However, AMD K8 rev E and earlier don't implement this bit and therefore need MTRR spanning dram memory above 4GB. The current implementation of amd_setup_mtrrs never generate MTRR above 4GB. This caused memory > 4GB not to be recognized in e.g. Linux on those rev E or older platforms. This commit should fix that bug. Signed-off-by: Oskar Enoksson <enok(a)lysator.liu.se> Change-Id: Ie568a52a8eb355969c86964d5afc4692e60f69c1 --- src/cpu/amd/mtrr/amd_mtrr.c | 19 ++++++++++++++++--- 1 files changed, 16 insertions(+), 3 deletions(-) diff --git a/src/cpu/amd/mtrr/amd_mtrr.c b/src/cpu/amd/mtrr/amd_mtrr.c index 623a344..7d15b84 100644 --- a/src/cpu/amd/mtrr/amd_mtrr.c +++ b/src/cpu/amd/mtrr/amd_mtrr.c @@ -112,7 +112,14 @@ void amd_setup_mtrrs(void) struct mem_state state; unsigned long i; msr_t msr, sys_cfg; - + // Test if this CPU is a Fam 0Fh rev. F or later + const int cpu_id = cpuid_eax(0x80000001); + const int is_revF = + (((cpu_id>>8 )&0xf) >= 0xf) || // Family > 0F + ((((cpu_id>>8 )&0xf) == 0xf) && // Family == 0F + (((cpu_id>>16)&0xf) >= 0x4)); // Rev>=F deduced from rev tables + if(is_revF) + printk(BIOS_DEBUG, "Detected CPU Fam 0Fh rev.F or later\n"); /* Enable the access to AMD RdDram and WrDram extension bits */ disable_cache(); @@ -168,7 +175,9 @@ void amd_setup_mtrrs(void) msr.hi = state.tomk >> 22; msr.lo = state.tomk << 10; wrmsr(TOP_MEM2, msr); - sys_cfg.lo |= SYSCFG_MSR_TOM2En | SYSCFG_MSR_TOM2WB; + sys_cfg.lo |= SYSCFG_MSR_TOM2En; + if(is_revF) + sys_cfg.lo |= SYSCFG_MSR_TOM2WB; } /* zero the IORR's before we enable to prevent @@ -201,5 +210,9 @@ void amd_setup_mtrrs(void) /* Now that I have mapped what is memory and what is not * Setup the mtrrs so we can cache the memory. */ - x86_setup_var_mtrrs(address_bits, 0); + + // Rev. F K8 supports has SYSCFG_MSR_TOM2WB and dont need + // variable MTRR to span memory above 4GB + // Lower revisions K8 need variable MTRR over 4GB + x86_setup_var_mtrrs(address_bits, is_revF ? 0 : 1); }

1 0

New patch to review for coreboot: af6f38b Fixes several issues with amd k8 SSDT P-state generation
by Oskar Enoksson 06 Oct '11

06 Oct '11

Oskar Enoksson (enok(a)lysator.liu.se) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/239 -gerrit commit af6f38bbfbf7702a5c432a6275e58dd13ce318bd Author: Oskar Enoksson <enok(a)lysator.liu.se> Date: Thu Oct 6 18:43:43 2011 +0200 Fixes several issues with amd k8 SSDT P-state generation For multi-socket CPU the current implementation emitted Processor objects for cores in the first CPU only. This commit fixes the bug. One caveat though: the unlikely case of CPU's with different FID/VID capabilities mixed in the same system is not handled correctly. Second issue fixed: processors not supporting P-state transitions got no Processor objects at all. It's probably better to give them a Processor object with one single P-state. The old loop also looked wrong in case a processor in the table doesn't have any declared P-states at all. The rewritten loop is safe. Some possibly dangerous array lengths were also fixed. Third issue: on MP-boards the recommended ramp-voltage (RVO) is 0mV according to the BKDG. The current implementation always set it to 25mV. This commit selects 0 or 25mV depending on if the number of populated CPU sockets is >1 or not. Signed-off-by: Oskar Enoksson <enok(a)lysator.liu.se> Change-Id: I61f6e2210b84ccba33a36c5efc866447b7134417 --- src/cpu/amd/model_fxx/powernow_acpi.c | 155 ++++++++++++++++++++++----------- 1 files changed, 103 insertions(+), 52 deletions(-) diff --git a/src/cpu/amd/model_fxx/powernow_acpi.c b/src/cpu/amd/model_fxx/powernow_acpi.c index bbcf013..65bbd90 100644 --- a/src/cpu/amd/model_fxx/powernow_acpi.c +++ b/src/cpu/amd/model_fxx/powernow_acpi.c @@ -586,70 +586,121 @@ static int pstates_algorithm(u32 pcontrol_blk, u8 plen, u8 onlyBSP) u8 cmp_cap; struct cpuentry *data = NULL; uint32_t control; - int i = 0, index, len = 0, Pstate_num = 0; + int i = 0, index = 0, len = 0, Pstate_num = 0, isock = 0, nsock = 0; msr_t msr; - u8 Pstate_fid[10]; - u16 Pstate_feq[10]; - u8 Pstate_vid[10]; - u32 Pstate_power[10]; + u8 Pstate_fid[MAXP+1]; + u16 Pstate_feq[MAXP+1]; + u8 Pstate_vid[MAXP+1]; + u32 Pstate_power[MAXP+1]; u8 Max_fid, Start_fid, Start_vid, Max_vid; struct cpuid_result cpuid1 = cpuid(0x80000001); + unsigned sockets[] = { 0x18, 0x19, 0x1a, 0x1b }; + struct cpuentry entr_dummy = {.pstates[0].freqMhz = 0 }; - msr = rdmsr(0xc0010042); - Max_fid = (msr.lo & 0x3F0000) >> 16; - Max_vid = (msr.hi & 0x3F0000) >> 16; - Start_fid = (msr.lo & 0x3F00) >> 8; - Start_vid = (msr.hi & 0x3F00) >> 8; - - cmp_cap = - (pci_read_config16(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xE8) & - 0x3000) >> 12; + // Count number of populated sockets + for (isock = 0,nsock = 0; isock < ARRAY_SIZE(sockets); isock++) { + if(dev_find_slot(0, PCI_DEVFN(sockets[isock], 0))!=NULL) + nsock++; + } + + for (isock = 0; isock < ARRAY_SIZE(sockets); isock++) { + if(dev_find_slot(0, PCI_DEVFN(sockets[isock], 0))==NULL) + continue; + // TODO: We should read msr from the right CPU here + // The following only works if fid/vid values are identical on + // all CPU's + msr = rdmsr(0xc0010042); + Max_fid = (msr.lo & 0x3F0000) >> 16; + Max_vid = (msr.hi & 0x3F0000) >> 16; + Start_fid = (msr.lo & 0x3F00) >> 8; + Start_vid = (msr.hi & 0x3F00) >> 8; + + cmp_cap = + (pci_read_config16(dev_find_slot(0, PCI_DEVFN(sockets[isock], 3)), 0xE8) & + 0x3000) >> 12; + + for (i = 0; i < ARRAY_SIZE(entr); i++) { + if ((entr[i].cpuid == cpuid1.eax) + && (entr[i].startFID == Start_fid) + && (entr[i].maxFID == Max_fid) + && (entr[i].brandID == ((u8 )((cpuid1.ebx >> 6) & 0xff)))) { + data = &entr[i]; + break; + } + } - for (i = 0; i < ARRAY_SIZE(entr); i++) { - if ((entr[i].cpuid == cpuid1.eax) - && (entr[i].startFID == Start_fid) - && (entr[i].maxFID == Max_fid) - && (entr[i].brandID == ((u8 )((cpuid1.ebx >> 6) & 0xff)))) { - data = &entr[i]; + if (data == NULL) { + printk(BIOS_WARNING, "Unknown CPU in socket %d, please update powernow_acpi.c\n",isock); + data = &entr_dummy; + } + /* See if the CPUID(0x80000007) returned EDX[2:1]==11b */ + cpuid1 = cpuid(0x80000007); + switch ((cpuid1.edx & 0x6)) { + case 0x6: + break; + case 0x0: + printk(BIOS_INFO, "Processor not capable of performing P-state transitions\n"); + data = &entr_dummy; + break; + default: + printk(BIOS_WARNING, "Capability of performing P-state transitions unknown\n"); break; } - } - - if (data == NULL) { - printk(BIOS_WARNING, "Unknown CPU, please update the powernow_acpi.c\n"); - return 0; - } - - /* IRT 80us, PLL_LOCK_TIME 2us, MVS 25mv, VST 100us */ - control = (3 << 30) | (2 << 20) | (0 << 18) | (5 << 11) | (1 << 29); - len = 0; - Pstate_num = 0; - Pstate_fid[Pstate_num] = Max_fid; - Pstate_feq[Pstate_num] = fid_to_freq(Max_fid); - Pstate_vid[Pstate_num] = Max_vid; - Pstate_power[Pstate_num] = data->pwr * 100; - Pstate_num++; - - do { - Pstate_fid[Pstate_num] = freq_to_fid(data->pstates[Pstate_num - 1].freqMhz) & 0x3f; - Pstate_feq[Pstate_num] = data->pstates[Pstate_num - 1].freqMhz; - Pstate_vid[Pstate_num] = vid_to_reg(data->pstates[Pstate_num - 1].voltage); - Pstate_power[Pstate_num] = data->pstates[Pstate_num - 1].tdp * 100; + if(nsock==1) + // IRT 80us, PLL_LOCK_TIME 2us, MVS 25mv, VST 100us RVO = 50mV + control = (3 << 30) | (2 << 20) | (0 << 18) | (5 << 11) | (1 << 29); + else + // MP-systems should default to RVO=0mV (no ramp voltage) + // IRT 80us, PLL_LOCK_TIME 2us, MVS 25mv, VST 100us RVO = 0mV + control = (3 << 30) | (2 << 20) | (0 << 18) | (5 << 11) | (0 << 29); + // RVO: 00 0mV (default for MP-systems) + // 01 25mV + // 10 50mV (default) + // 11 75mV + // IRT: 00 10uS + // 01 20uS + // 10 40uS + // 11 80uS (default) + // MVS: 00 25mV (default) + // 01 50mV (reserved) + // 10 100mV (reserved) + // 11 200mV (reserved) + // VST: time is value*20uS (default value: 5 => 100uS) + // PLL_LOCK_TIME: time is value*1uS (often seen value: 2uS) + // + + len = 0; + Pstate_num = 0; + + Pstate_fid[Pstate_num] = Max_fid; + Pstate_feq[Pstate_num] = fid_to_freq(Max_fid); + Pstate_vid[Pstate_num] = Max_vid; + Pstate_power[Pstate_num] = data->pwr * 100; Pstate_num++; - } while ((Pstate_num < MAXP) && (data->pstates[Pstate_num - 1].freqMhz != 0)); - for (i=0;i<Pstate_num;i++) - printk(BIOS_DEBUG, "P#%d freq %d [MHz] voltage %d [mV] TDP %d [mW]\n", i, - Pstate_feq[i], - vid_from_reg(Pstate_vid[i]), - Pstate_power[i]); + while ((Pstate_num <= MAXP) && (data->pstates[Pstate_num - 1].freqMhz != 0)) { + Pstate_fid[Pstate_num] = freq_to_fid(data->pstates[Pstate_num - 1].freqMhz) & 0x3f; + Pstate_feq[Pstate_num] = data->pstates[Pstate_num - 1].freqMhz; + Pstate_vid[Pstate_num] = vid_to_reg(data->pstates[Pstate_num - 1].voltage); + Pstate_power[Pstate_num] = data->pstates[Pstate_num - 1].tdp * 100; + Pstate_num++; + } - for (index = 0; index < (cmp_cap + 1); index++) { - len += write_pstates_for_core(Pstate_num, Pstate_feq, Pstate_vid, - Pstate_fid, Pstate_power, index, - pcontrol_blk, plen, onlyBSP, control); + for (i=0;i<Pstate_num;i++) + printk(BIOS_DEBUG, "P#%d freq %d [MHz] voltage %d [mV] TDP %d [mW]\n", i, + Pstate_feq[i], + vid_from_reg(Pstate_vid[i]), + Pstate_power[i]); + + for (i = 0; i < cmp_cap + 1; i++) { + len += write_pstates_for_core(Pstate_num, Pstate_feq, Pstate_vid, + Pstate_fid, Pstate_power, index+i, + pcontrol_blk, plen, onlyBSP, control); + } + index += i; } + printk(BIOS_DEBUG,"%d Processor objects will be emitted to SSDT\n",index); return len; }

1 0

New patch to review for coreboot: 1c4e003 Fixed broken MTRR for >4GB memory on AMD K8 fam 0fh rev <=E
by Oskar Enoksson 06 Oct '11

06 Oct '11

Oskar Enoksson (enok(a)lysator.liu.se) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/238 -gerrit commit 1c4e003269ed43e3d46c60f56e62bcb1049a3fc0 Author: Oskar Enoksson <enok(a)lysator.liu.se> Date: Thu Oct 6 18:21:19 2011 +0200 Fixed broken MTRR for >4GB memory on AMD K8 fam 0fh rev <=E AMD K8 rev F and later implements a bit SYSCFG_MSR_TOM2WB in SYSCFG_MSR to mark dram memory above 4GB as WB. However, AMD K8 rev E and earlier don't implement this bit and therefore need MTRR spanning dram memory above 4GB. The current implementation of amd_setup_mtrrs never generate MTRR above 4GB. This caused memory > 4GB not to be recognized in e.g. Linux on those rev E or older platforms. This commit should fix that bug. Signed-off-by: Oskar Enoksson <enok(a)lysator.liu.se> Change-Id: Ie568a52a8eb355969c86964d5afc4692e60f69c1 --- src/cpu/amd/mtrr/amd_mtrr.c | 18 +++++++++++++++--- 1 files changed, 15 insertions(+), 3 deletions(-) diff --git a/src/cpu/amd/mtrr/amd_mtrr.c b/src/cpu/amd/mtrr/amd_mtrr.c index 623a344..93a3bba 100644 --- a/src/cpu/amd/mtrr/amd_mtrr.c +++ b/src/cpu/amd/mtrr/amd_mtrr.c @@ -112,7 +112,13 @@ void amd_setup_mtrrs(void) struct mem_state state; unsigned long i; msr_t msr, sys_cfg; - + // Test if this CPU is a Fam 0Fh rev. F or later + const int is_revF = + ((cpuid_eax(0x80000001)&0x00000f00)>>8 >= 0xf) || + (((cpuid_eax(0x80000001)&0x00000f00)>>8 == 0xf) && + ((cpuid_eax(0x80000001)&0x000f0000)>>16 >= 0x4)); + if(is_revF) + printk(BIOS_DEBUG, "Detected CPU Fam 0Fh rev.F or later\n"); /* Enable the access to AMD RdDram and WrDram extension bits */ disable_cache(); @@ -168,7 +174,9 @@ void amd_setup_mtrrs(void) msr.hi = state.tomk >> 22; msr.lo = state.tomk << 10; wrmsr(TOP_MEM2, msr); - sys_cfg.lo |= SYSCFG_MSR_TOM2En | SYSCFG_MSR_TOM2WB; + sys_cfg.lo |= SYSCFG_MSR_TOM2En; + if(is_revF) + sys_cfg.lo |= SYSCFG_MSR_TOM2WB; } /* zero the IORR's before we enable to prevent @@ -201,5 +209,9 @@ void amd_setup_mtrrs(void) /* Now that I have mapped what is memory and what is not * Setup the mtrrs so we can cache the memory. */ - x86_setup_var_mtrrs(address_bits, 0); + + // Rev. F K8 supports has SYSCFG_MSR_TOM2WB and dont need + // variable MTRR to span memory above 4GB + // Lower revisions K8 need variable MTRR over 4GB + x86_setup_var_mtrrs(address_bits, is_revF ? 0 : 1); }

2 1

Re: [coreboot] amd_model_fxx_generate_powernow with dual-socket dual-core K8 system just handles first CPU(?)
by Marc Jones 06 Oct '11

06 Oct '11

On Thu, Oct 6, 2011 at 7:59 AM, Oskar Enoksson <enok(a)lysator.liu.se> wrote: > I think I can fix it, or at least improve it. > > One question though: is there any easy way to read msr register from a > particular cpudevice (not from the core on which we currently execute)? > No, MSRs can only be read by code running on a given CPU. Marc > On 10/06/2011 01:07 AM, Rudolf Marek wrote: >> >> Hi all, >> >> Yes there should be a loop for processor sockets. I wrote that for single >> cpu (dual core...) >> >> Please fix it so it works on all cases. >> >> Thanks >> Rudolf >> > > -- http://se-eng.com

1 0

Re: [coreboot] patch to display ASRock E350M1 freq correctly
by Marc Jones 06 Oct '11

06 Oct '11

Keeping this on the list. On Wed, Oct 5, 2011 at 7:03 PM, mopz0506 mopz0506 <mopz0506(a)gmail.com> wrote: > I'm very surprised too. > > I'm not familiar with coreboot code base, but seems all SB800-based > system are running hardcoded codepath and ignores a lot of Agesa code. > There are so many indirection and everytime you call the same > function it may do different thing, depends on "The service desired", > and the callback. > > Don't have serial port/cable so what I can do is guessing. > > so below is what happened, I guess. > > in agesawrapper_amdinitlate (), AmdLateParams has been filled > with 0 (And AmdLateParams.StdHeader.HeapBasePtr). > > so we must set "AmdLateParams.PlatformConfig.UserOptionPstate" > to "TRUE", tell Agesa that we want a PState table. > > then call AmdInitLate(&AmdLateParams) and let Agesa to build > SSDT for us. > > AmdInitLate() call GenerateSsdt () to do the real work. > > GenerateSsdt () call HeapLocateBuffer() to get the location of > PState data, which Agesa prepared for us before. > > unlucky, HeapLocateBuffer() requires (NULL != StdHeader->HeapBasePtr), > here StdHeader is &AmdLateParams.StdHead. > > since AmdLateParams has been initialized to 0, aka. the stdheader.HeapBasePtr > is NULL, the HeapLocateBuffer() failed and return AGESA_ERROR. > > so, all those pointer, *DmiTable, *AcpiPstate, *AcpiSrat, *AcpiSlit, > *AcpiWheaMce, *AcpiWheaCmc, *AcpiAlib, always being NULL. > > since AcpiPstate is NULL, write_acpi_tables() always skip Agesa and > fallback to hardcoded data and ACPI setting. > > we must set the AmdLateParams.StdHeader to a valid HeapBasePtr to fetch > Agesa's PState data. > > but seems HeapManager is for Agesa internal only. Tried HeapGetBaseAddress() > the computer frozen. I know nothing about programming on such raw hardware > and don't know why. > > I checked agesawrapper.c from other mainboards and found nothing. > > how could I get a valid HeapBasePtr to call HeapLocateBuffer() and > HeapAllocateBuffer()? > > Any hints? > > Thanks, > mopz0506 > > On Wed, Oct 5, 2011 at 12:24 AM, Marc Jones <marcj303(a)gmail.com> wrote: >> On Tue, Oct 4, 2011 at 1:38 AM, Rudolf Marek <r.marek(a)assembler.cz> wrote: >>> Hi all, >>> >>>> I'm not native speaker and sorry for my English. >>> >>> Yep me too ;) But your doing OK we can understand what you wrote. >>> >>>> Finally I think maybe I can fix it myself and start >>>> digging ACPI and source code. >>> >>> I'm quite surprised that this is hardcoded. We used to have a functions >>> which place it there runtime depending on CPU model. I don't know >>> why it is hardcoded here. I think a proper fix would be to provide that >>> runtime depending on CPU. Maybe AGESA has some infrastructure for that. Did >>> not check so far. >>> >>> Thanks >>> Rudolf >> >> This should be generated by the AMDInitLate call, which needs some >> work in coreboot acpi/agesa wrappers. Feel free to check out the >> tables that are generated and look at how they should be integrated. >> >> Marc >> >> >> >> -- >> http://se-eng.com >> > -- http://se-eng.com

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2011