Hello,
I'm having some trouble with current releases of coreboot on a Supermicro H8DMR-i2.
The initial problem, it takes about 2 minutes to show the: "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." and equally as long after the warm reset.
The second, the system freezes at "Clearning initial memory region:" for about a half hour before proceeding. After that, everything works as expected.
There has been some list chatter about a similar problem with the H8DME, but that was based upon the H8DMR code so it's odd that it found it's way here. I've attached the full serial output if that's at all useful.
Vitals: Vendor: Supermicro MainBoard: H8DMR-i2 NorthVBridge: Fam10h SouthBridge: NVIDIA MCP55 Super I/O: Winbond™ W83627EHG CPU: AMD Opteron
Any suggestions are welcome, TIA, Nicholas Lemberger
---snip--- coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting...
BSP Family_Model: 00100f23 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1022, current patch id = 0x00000000 microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] POST: 0x33 cpuSetAMDMSR done POST: 0x34 Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 00 01 AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 02 ff Exit amd_ht_init() POST: 0x35 cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f23 F3xD8: 03001b12 F3xDC: 0000542c Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f23 F3xD8: 03001b12 F3xDC: 0000542c setup_remote_node: 01 done Start node 01 done. POPSOSTT: :0 0xx3630
Co rcoer0 es0:t ar t--e-d :{ 0A1PI sItD a=rt _04o thNeODrE_cIoD r=es (01) oOinREiIt Dn =o de00:} 0 0-- - c :rmiesc:ro c03o de S etqarutiv aotlhenetr creovre id- n o= de0ix1d0: 202,0 ccurorreesnt: 0p3at ::i niidt =n o0dex0: 000010 0 PPPOO0cO0oSSSTrTT :es m0:00ixxcx r0333o0300 c
o
dSe :ccctoooa rrrrreeetexx xv :::o ti hd --e -(r---- --1 0 c6{o{{ r 2 )AAAePP Pd-IIICCCo eInIIDoDsD d===eni OcOR00d0:21 3m 0NNaNtOO1O DDcDhEE EcII ItDDoD r h=ei==s s00: 0p 000 a0tC3CCO OI hRREEE.PII --:-: - e i:===c r0000PPPOox231OOS}SSc3}} T TTo7:d x ----0-00:sx t Na
cc 3330or00mmmiiitt
c erudrr oocccop dcaccooorraopoorddeeetd eeaeexxx:::d:p:: i ! eece Fqqiq------iuudu:ii---xi v vv {a{{ma*al O ilAceeAAeAPnPPrnnPtt ItIIoCCc 0C I1rIIorreeDseDDd evv tv=a ==_ uii ri 0d0pdd0t5e7 6d a d N=Nt==N 2 2=22=02=D0*D0E xE[xExI1IA1I]1D 0D0DP0 2 DtM , ,, 2c0s p0 0cc11tcu1Su uu aCCrerCrrrrOOttrOAeReeRReEEdMnEnnIttII t- D DD S*p pp=aa==R a At tt 00P0ccc hh2d h13} } }o0 n3 i ii-dd-es-d- - - r i-=-== n t0 c0c00c00rfiexmmmi0i00itd_ _ s 5 r0ro0o00oi*cd c0c00o00ovAo0d0d00diPed e0e00:
nn eetesmmmiiqaqtqiuacccuguieiirrrrooov2vvtaaeccca loalldooddedpee d eeneit:ctt*:: i drrrArrree:eeePe vvvv vv0 0 iii4ii6idsdddd 1)0 0 ( ( a(=11=r1= 0 00 t0e06066x2dx2x21)1) t ttt 02*2dd2d2o 2oo2,e,eA,e ss sP c c c unu0unnroor7rortrttrsete e nmanmnmtatarta t t ttecpcpcpadhahaht t hhhhhh cc 3000 i iiisPsiisd d O d p pSpaT==a=a tt: t0ccc 00xxxhhh00x00...
0 0mm0m0i0 r 0ii0cc00c ceccoo00oBoo0
ogdiddmmmieiiene: c:cc:r Fr roNoNNIoccocooDoVotott dId deuuueDe: :ppp: d M ddraarSraetetteRv eveev 0d dd!!iix!id ddc 0 FFF (i(0(ii1xx11x10 00060mmm662227iii)c))1ccrr r d0oododooxccoceoee2ooddsdss0eae e nn_6_n_ouoou0up1tptth0h1 d mmaa4maatatt at0teteesscxcsch[[[h4h c ]]] tt0t h
i teetctctccc p p 0ppuupup3a aSSaSte SD cthAhAhAPOMMM... M MM nodededemSSiR iRiRc c 0c rrxr o3dooddco9occoonon eP: e :
avvavtit i iinnNTNnNoiiio:otttttt 0 ___ufxuuffiipi3ppdddddada
tiieddeedEddnd___ss!!!sd ttt FFFaaaFiiiIgggeexxxDe2nneeep0ppuuu1S1SSeee4t ttAAA0MxMMDDD4McMMSSS0RR0R 4c0 d3ddooo n m
c d_ipiinn5ni5iittt__n__fffuimiiddd:v0vviii1dd __ssstttaaagggeee222 aaapppiiiccciiiddd::: 000765
POST: 0x3b fill_mem_ctrl() POST: 0x3d POST: 0x40 raminit_amdmct() raminit_amdmct begin: Node: 00 base: 00 limit: 3ffffff BottomIO: e00000 Node: 01 base: 4200000 limit: 81fffff BottomIO: e00000 Copy dram map from Node 0 to Node 01 raminit_amdmct end: POST: 0x41 v_esp=000cbf38 testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region:
Am 04.09.2010 00:07, schrieb Nick Lemberger:
The initial problem, it takes about 2 minutes to show the: "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." and equally as long after the warm reset.
The second, the system freezes at "Clearning initial memory region:" for about a half hour before proceeding. After that, everything works as expected.
I guess both stem from a known cache setup issue on AMD chipsets. Unfortunately no one worked on it yet.
Patrick
"Nick Lemberger" Nick.Lemberger@lkfd.net writes:
Hello,
I'm having some trouble with current releases of coreboot on a Supermicro H8DMR-i2.
The initial problem, it takes about 2 minutes to show the: "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." and equally as long after the warm reset.
The second, the system freezes at "Clearning initial memory region:" for about a half hour before proceeding. After that, everything works as expected.
There has been some list chatter about a similar problem with the H8DME, but that was based upon the H8DMR code so it's odd that it found it's way here. I've attached the full serial output if that's at all useful.
Can you see if the patches posted in http://article.gmane.org/gmane.linux.bios/57707 make any difference for you?
On 9/6/10 10:12 AM, Arne Georg Gleditsch wrote:
"Nick Lemberger" Nick.Lemberger@lkfd.net writes:
Hello,
I'm having some trouble with current releases of coreboot on a Supermicro H8DMR-i2.
The initial problem, it takes about 2 minutes to show the: "coreboot-4.0-r5775 Fri Sep 3 14:55:01 CDT 2010 starting..." and equally as long after the warm reset.
The second, the system freezes at "Clearning initial memory region:" for about a half hour before proceeding. After that, everything works as expected.
There has been some list chatter about a similar problem with the H8DME, but that was based upon the H8DMR code so it's odd that it found it's way here. I've attached the full serial output if that's at all useful.
Can you see if the patches posted in http://article.gmane.org/gmane.linux.bios/57707 make any difference for you?
Did we ever figure out what is causing this?
The patch would require 4KB more stack on all supported systems, so if we can we should do things differently.
Also, it's not really guaranteed that the code works from the new location since we don't compile coreboot with -fPIC (and as far as I understand the GCC guys, even that would not help), so I am a bit hesitant to check this in.
Stefan
Stefan Reinauer stefan.reinauer@coresystems.de writes:
Can you see if the patches posted in http://article.gmane.org/gmane.linux.bios/57707 make any difference for you?
Did we ever figure out what is causing this?
The last time I really dug into this, it was fairly obvious that it was caused by instruction fetch thrashing towards the ROM. I tried to amend this with MTRR settings, but I was unable to make that work correctly. For some reason it seemed like the HT requests were sublty changed when the MTRR was applied, and didn't hit the legacy southbridge properly.
The patch would require 4KB more stack on all supported systems, so if we can we should do things differently.
It doesn't have to be stack, but it is nice to have it memory mananged in some way. The unrv2b patch I posted addressing the same problem was even more kludgy.
Also, it's not really guaranteed that the code works from the new location since we don't compile coreboot with -fPIC (and as far as I understand the GCC guys, even that would not help), so I am a bit hesitant to check this in.
Agreed, it is a bit icky. Not sure what the best way to handle that is, though. On the pro side, I assume breakage here is going to be obvious, and (supposing these patches actually help Nick) this is an issue people are running into with some regularity.
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Arne Georg Gleditsch Sent: Monday, September 06, 2010 05:50 AM To: coreboot@coreboot.org Subject: Re: [coreboot] AMD cache setup is broken
Stefan Reinauer stefan.reinauer@coresystems.de writes:
Can you see if the patches posted in http://article.gmane.org/gmane.linux.bios/57707 make any difference for you?
Did we ever figure out what is causing this?
The last time I really dug into this, it was fairly obvious that it was caused by instruction fetch thrashing towards the ROM. I tried to amend this with MTRR settings, but I was unable to make that work correctly. For some reason it seemed like the HT requests were sublty changed when the MTRR was applied, and didn't hit the legacy southbridge properly.
The patch would require 4KB more stack on all supported systems, so if we can we should do things differently.
It doesn't have to be stack, but it is nice to have it memory mananged in some way. The unrv2b patch I posted addressing the same problem was even more kludgy.
Also, it's not really guaranteed that the code works from the new location since we don't compile coreboot with -fPIC (and as far as I understand the GCC guys, even that would not help), so I am a bit hesitant to check this in.
Agreed, it is a bit icky. Not sure what the best way to handle that is, though. On the pro side, I assume breakage here is going to be obvious, and (supposing these patches actually help Nick) this is an issue people are running into with some regularity.
"Scott Duplichan" scott@notabs.org writes:
One necessary condition for caching MMIO such as the flash chip on AMD family 10h processors is not well known:
If the processor has an L3 cache, then bit 15 of msr C001_102A (ClLinesToNbDis) must be set. This bit needs to eventually be cleared in order for the OS to use the L3 cache. But BIOS must not clear this bit until cacheable accesses to the flash chip are no longer needed. This situation applies only to family 10h processors that have L3 cache. Often BIOS clears this bit too early and slow execution results.As an experiment, you could add code to set this bit before the slow function and see what happens.
This is certainly interesting information. I'd like to test this out on real hardware, but I'm afraid I can't promise it'll be in the immediate future.
Stefan Reinauer stefan.reinauer@coresystems.de writes:
Can you see if the patches posted in http://article.gmane.org/gmane.linux.bios/57707 make any difference for you?
Did we ever figure out what is causing this?
The last time I really dug into this, it was fairly obvious that it was caused by instruction fetch thrashing towards the ROM. I tried to amend this with MTRR settings, but I was unable to make that work correctly. For some reason it seemed like the HT requests were sublty changed when the MTRR was applied, and didn't hit the legacy southbridge properly.
The patch would require 4KB more stack on all supported systems, so if we can we should do things differently.
It doesn't have to be stack, but it is nice to have it memory mananged in some way. The unrv2b patch I posted addressing the same problem was even more kludgy.
Also, it's not really guaranteed that the code works from the new location since we don't compile coreboot with -fPIC (and as far as I understand the GCC guys, even that would not help), so I am a bit hesitant to check this in.
Agreed, it is a bit icky. Not sure what the best way to handle that is, though. On the pro side, I assume breakage here is going to be obvious, and (supposing these patches actually help Nick) this is an issue people are running into with some regularity.
On Mon, Sep 6, 2010 at 6:40 PM, Scott Duplichan scott@notabs.org wrote:
Stefan Reinauer stefan.reinauer@coresystems.de writes:
Can you see if the patches posted in http://article.gmane.org/gmane.linux.bios/57707 make any difference for you?
Did we ever figure out what is causing this?
The last time I really dug into this, it was fairly obvious that it was caused by instruction fetch thrashing towards the ROM. I tried to amend this with MTRR settings, but I was unable to make that work correctly. For some reason it seemed like the HT requests were sublty changed when the MTRR was applied, and didn't hit the legacy southbridge properly.
The patch would require 4KB more stack on all supported systems, so if we can we should do things differently.
It doesn't have to be stack, but it is nice to have it memory mananged in some way. The unrv2b patch I posted addressing the same problem was even more kludgy.
Also, it's not really guaranteed that the code works from the new location since we don't compile coreboot with -fPIC (and as far as I understand the GCC guys, even that would not help), so I am a bit hesitant to check this in.
Agreed, it is a bit icky. Not sure what the best way to handle that is, though. On the pro side, I assume breakage here is going to be obvious, and (supposing these patches actually help Nick) this is an issue people are running into with some regularity.
-- Arne.
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
One necessary condition for caching MMIO such as the flash chip on AMD family 10h processors is not well known:
If the processor has an L3 cache, then bit 15 of msr C001_102A (ClLinesToNbDis) must be set. This bit needs to eventually be cleared in order for the OS to use the L3 cache. But BIOS must not clear this bit until cacheable accesses to the flash chip are no longer needed. This situation applies only to family 10h processors that have L3 cache. Often BIOS clears this bit too early and slow execution results.As an experiment, you could add code to set this bit before the slow function and see what happens.
Last night I tried to debug this code on simnow. An HT modeling problem kept me from getting past HT init. I may try it again today.
The recommended cacheability setting for MMIO is WP. At the point the simnow model hangs in HT init, the setting is WB. While this should be OK for family 10h, it will be important to use WP for families 14h and 15. ClLinesToNbDis is properly set for MMIO caching at this point (HT init):
------------Effective memory type and destination by address------------
NORMAL NORMAL NORMAL SMM SMM SMM READ WRITE EXECUTE READ WRITE EXECUTE 00000-C3FFF UC MMIO.................... UC MMIO.................... C4000-CFFFF WB DRAM.................... WB DRAM.................... D0000-FFFFF UC MMIO.................... UC MMIO....................
00100000-00FFFFFF UC DRAM 01000000-FFEFFFFF UC MMIO FFF00000-FFF7FFFF WB MMIO <=== really should be WP FFF80000-FFFFFFFF UC MMIO
-msr c001102a 00000040_010080C8 <=== good at this point
Thanks, Scott
Simnow testing with Tilapia confirms that the coreboot AMD family 10h code _does_ have the problem of clearing ClLinesToNbDis too early. To confirm this problem, someone testing on real AMD family 10h hardware should remove the msr C001_001a write from STOP_CAR_AND_CPU() and from mct_ClrClToNB_D(). An AMD F10h system running an optimized legacy bios can boot to a DOS ptompt in less than one second. There is no reason coreboot should be any slower.
Thanks, Scott
Ah, this makes sense now. Is c001_001a a shared msr? Is it ok for the APs to be disabled and just leave it enabled on the BSP until the ramstage is decompressed? I should have a patch ready this afternoon.
Marc
]On Mon, Sep 6, 2010 at 6:40 PM, Scott Duplichan scott@notabs.org wrote: ]> Stefan Reinauer stefan.reinauer@coresystems.de writes: ]>>> Can you see if the patches posted in ]>>> http://article.gmane.org/gmane.linux.bios/57707 make any difference for ]>>> you? ]>>> ]>> Did we ever figure out what is causing this? ]> ]> The last time I really dug into this, it was fairly obvious that it was ]> caused by instruction fetch thrashing towards the ROM. I tried to amend ]> this with MTRR settings, but I was unable to make that work correctly. ]> For some reason it seemed like the HT requests were sublty changed when ]> the MTRR was applied, and didn't hit the legacy southbridge properly. ]> ]>> The patch would require 4KB more stack on all supported systems, so if ]>> we can we should do things differently. ]> ]> It doesn't have to be stack, but it is nice to have it memory mananged ]> in some way. The unrv2b patch I posted addressing the same problem was ]> even more kludgy. ]> ]>> Also, it's not really guaranteed that the code works from the new ]>> location since we don't compile coreboot with -fPIC (and as far as I ]>> understand the GCC guys, even that would not help), so I am a bit ]>> hesitant to check this in. ]> ]> Agreed, it is a bit icky. Not sure what the best way to handle that is, ]> though. On the pro side, I assume breakage here is going to be obvious, ]> and (supposing these patches actually help Nick) this is an issue people ]> are running into with some regularity. ]> ]> -- ]> Arne. ]> ]> -- ]> coreboot mailing list: coreboot@coreboot.org ]> http://www.coreboot.org/mailman/listinfo/coreboot ]> ]> ]> ]> One necessary condition for caching MMIO such as the flash chip on ]> AMD family 10h processors is not well known: ]> ]> If the processor has an L3 cache, then bit 15 of msr C001_102A ]> (ClLinesToNbDis) must be set. This bit needs to eventually be cleared ]> in order for the OS to use the L3 cache. But BIOS must not clear this ]> bit until cacheable accesses to the flash chip are no longer needed. ]> This situation applies only to family 10h processors that have L3 cache. ]> Often BIOS clears this bit too early and slow execution results.As an ]> experiment, you could add code to set this bit before the slow function ]> and see what happens. ]> ]> Last night I tried to debug this code on simnow. An HT modeling problem ]> kept me from getting past HT init. I may try it again today. ]> ]> The recommended cacheability setting for MMIO is WP. At the point the ]> simnow model hangs in HT init, the setting is WB. While this should ]> be OK for family 10h, it will be important to use WP for families ]> 14h and 15. ClLinesToNbDis is properly set for MMIO caching at this point ]> (HT init): ]> ]> ------------Effective memory type and destination by address------------ ]> ]> NORMAL NORMAL NORMAL SMM SMM SMM ]> READ WRITE EXECUTE READ WRITE EXECUTE ]> 00000-C3FFF UC MMIO.................... UC MMIO.................... ]> C4000-CFFFF WB DRAM.................... WB DRAM.................... ]> D0000-FFFFF UC MMIO.................... UC MMIO.................... ]> ]> 00100000-00FFFFFF UC DRAM ]> 01000000-FFEFFFFF UC MMIO ]> FFF00000-FFF7FFFF WB MMIO <=== really should be WP ]> FFF80000-FFFFFFFF UC MMIO ]> ]> -msr c001102a ]> 00000040_010080C8 <=== good at this point ]> ]> Thanks, ]> Scott ]> ]> ]> ]> Simnow testing with Tilapia confirms that the coreboot AMD family 10h ]> code _does_ have the problem of clearing ClLinesToNbDis too early. To ]> confirm this problem, someone testing on real AMD family 10h hardware ]> should remove the msr C001_001a write from STOP_CAR_AND_CPU() and ]> from mct_ClrClToNB_D(). An AMD F10h system running an optimized legacy ]> bios can boot to a DOS ptompt in less than one second. There is no ]> reason coreboot should be any slower. ]> ]> Thanks, ]> Scott ] ]Ah, this makes sense now. Is c001_001a a shared msr? Is it ok for the ]APs to be disabled and just leave it enabled on the BSP until the ]ramstage is decompressed? I should have a patch ready this afternoon.
I checked on real hardware, and family 10h msr c001_102a is not shared among cores on a die. I suppose it would be OK to do what you say. I imagine that would minimize code changes. The alternative is to remove the two instances where ClLinesToNbDis is cleared early, and then clear it at some later time, before AP MSRs are synced to the BSP values. I see the BKDG was finally updated to address this situation:
When BIOS is done executing from WP-IO the following steps are followed: 1. MSRC001_102A[ClLinesToNbDis]=0.
]Marc ] ]-- ]http://se-eng.com
"Scott Duplichan" scott@notabs.org writes:
I checked on real hardware, and family 10h msr c001_102a is not shared among cores on a die. I suppose it would be OK to do what you say. I imagine that would minimize code changes.
As a minimal change, I did the following:
diff --git a/src/arch/i386/lib/cbfs_and_run.c b/src/arch/i386/lib/cbfs_and_run.c index 1b86f56..2f90b0c 100644 --- a/src/arch/i386/lib/cbfs_and_run.c +++ b/src/arch/i386/lib/cbfs_and_run.c @@ -34,6 +34,12 @@ void cbfs_and_run_core(const char *filename, unsigned ebp) asm("hlt\n"); }
+ __asm__ volatile ( + "rdmsr\n" + "btr $15, %%eax\n" + "wrmsr\n" + :: "c"(0xc001102a) : "eax", "edx"); + print_debug("Jumping to image.\n"); __asm__ volatile ( "movl %%eax, %%ebp\n" diff --git a/src/northbridge/amd/amdmct/mct/mct_d.c b/src/northbridge/amd/amdmct/mct/mct_d.c index 3693891..fd07fa5 100644 --- a/src/northbridge/amd/amdmct/mct/mct_d.c +++ b/src/northbridge/amd/amdmct/mct/mct_d.c @@ -3189,7 +3189,7 @@ static void mct_FinalMCT_D(struct MCTStatStruc *pMCTstat, print_t("\tmct_FinalMCT_D: Clr Cl, Wb\n");
- mct_ClrClToNB_D(pMCTstat, pDCTstat); +// mct_ClrClToNB_D(pMCTstat, pDCTstat); mct_ClrWbEnhWsbDis_D(pMCTstat, pDCTstat); }
I can confirm that this removes the earlier observed delays for me. Obviously, this is AMD-specific code that needs to be hooked in in a proper manner, but this definately seems to be the culprit.
The alternative is to remove the two instances where ClLinesToNbDis is cleared early, and then clear it at some later time, before AP MSRs are synced to the BSP values. I see the BKDG was finally updated to address this situation:
As far as I can see, this bit is cleared in the APs just before they are stopped in the rom stage. Aas they'r not in play again until well into the ram stage, I'm assuming this is ok. Pushing the ClrClToNB operation in mct_d to after the BSP is done executing from rom should be sufficient, and this seems to be confirmed by testing.
Arne Georg Gleditsch arne.gleditsch@numascale.com writes:
I can confirm that this removes the earlier observed delays for me. Obviously, this is AMD-specific code that needs to be hooked in in a proper manner, but this definately seems to be the culprit.
Apparently, it's not crucial to clear this at the exact moment we switch to using ram, so something like the appended is perhaps more appropriate. Confirmed to work on hw.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numscale.com
Am 09.09.2010 11:16, schrieb Arne Georg Gleditsch:
Apparently, it's not crucial to clear this at the exact moment we switch to using ram, so something like the appended is perhaps more appropriate. Confirmed to work on hw.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numscale.com
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
and in as r5791
Thanks, Patrick
Patrick Georgi patrick@georgi-clan.de writes:
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
and in as r5791
Thanks Patrick,
I guess we want to do this in the DDR3 path as, well. Patch appended to do so, as well as fix a minor typo in the last one.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numscale.com
Am 09.09.2010 12:06, schrieb Arne Georg Gleditsch:
I guess we want to do this in the DDR3 path as, well. Patch appended to do so, as well as fix a minor typo in the last one.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numscale.com
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
r5792
Thanks, Patrick
On Thu, Sep 9, 2010 at 4:35 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Am 09.09.2010 12:06, schrieb Arne Georg Gleditsch:
I guess we want to do this in the DDR3 path as, well. Patch appended to do so, as well as fix a minor typo in the last one.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numscale.com
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
r5792
Thanks for doing this. I got sucked into other issues yesterday....
Marc
So, after all this, I think we still need the lzma change that Arne proposed. I have found that the videobios decompress is still slow, which is after the rom caching is disabled.
Marc
Marc Jones marcj303@gmail.com writes:
So, after all this, I think we still need the lzma change that Arne proposed. I have found that the videobios decompress is still slow, which is after the rom caching is disabled.
I thought the decompress itself needed to run from ROM for us to see this. What kind of video bios is this; is it embedded in the coreboot image or is it hosted on an external video card? I have a vague recollection of there being a facility or hook that allowed option roms to copy themselves from ROM to RAM, could that be involved here?
On Sat, Sep 11, 2010 at 5:05 AM, Arne Georg Gleditsch arne.gleditsch@numascale.com wrote:
Marc Jones marcj303@gmail.com writes:
So, after all this, I think we still need the lzma change that Arne proposed. I have found that the videobios decompress is still slow, which is after the rom caching is disabled.
I thought the decompress itself needed to run from ROM for us to see this. What kind of video bios is this; is it embedded in the coreboot image or is it hosted on an external video card? I have a vague recollection of there being a facility or hook that allowed option roms to copy themselves from ROM to RAM, could that be involved here?
This is a lzma compressed rom embeeded in the coreboot image.
Marc
Marc Jones marcj303@gmail.com writes:
I thought the decompress itself needed to run from ROM for us to see this. What kind of video bios is this; is it embedded in the coreboot image or is it hosted on an external video card? I have a vague recollection of there being a facility or hook that allowed option roms to copy themselves from ROM to RAM, could that be involved here?
This is a lzma compressed rom embeeded in the coreboot image.
Then I don't think I quite understand what happens... The ramstage contains its own copy of ulzma, does it not? Does the copy-to-stack approach actually help in your case? How about delaying the clear ClLinesToNbDis-operation?
Arne Georg Gleditsch arne.gleditsch@numascale.com writes:
- /* Clear ClLinesToNbDis */
- msr = rdmsr(BU_CFG2_MSR);
- msr.lo &= ~(1 << 15);
- wrmsr(BU_CFG2_MSR, msr);
On an slightly unrelated note; do we want to clear bit 35 here as well? At the moment, this is only done for the BSP, causing the MSR settings to be inconsistent after boot. I see that errata 343 indicates that this should be cleared after CAR is disabled, so it might not matter all that much for the APs...
]-----Original Message----- ]From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Arne Georg Gleditsch ]Sent: Thursday, September 09, 2010 04:58 AM ]To: Scott Duplichan ]Cc: 'Marc Jones'; coreboot@coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]Arne Georg Gleditsch arne.gleditsch@numascale.com writes: ]> + /* Clear ClLinesToNbDis */ ]> + msr = rdmsr(BU_CFG2_MSR); ]> + msr.lo &= ~(1 << 15); ]> + wrmsr(BU_CFG2_MSR, msr); ] ]On an slightly unrelated note; do we want to clear bit 35 here as well? ]At the moment, this is only done for the BSP, causing the MSR settings ]to be inconsistent after boot. I see that errata 343 indicates that ]this should be cleared after CAR is disabled, so it might not matter all ]that much for the APs...
I think it would be best to clear bit 35 of msr c001_102a in the AP cores as well as the BSP core. Otherwise, the OS might see AP cores having slightly lower performance than the BSP core. This bit affects family 10h revC and newer (45 nm).
Thanks, Scott
] ]-- ] Arne.
"Scott Duplichan" scott@notabs.org writes:
I think it would be best to clear bit 35 of msr c001_102a in the AP cores as well as the BSP core. Otherwise, the OS might see AP cores having slightly lower performance than the BSP core. This bit affects family 10h revC and newer (45 nm).
Ok, so here's a patch adding this. Clearing bit 35 is done unconditionally for all fam10 cpus, is that ok? Setting is done based on processor type in defaults.h, as before.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numascale.com
]-----Original Message----- ]From: coreboot-bounces+scott=notabs.org@coreboot.org [mailto:coreboot-]bounces+scott=notabs.org@coreboot.org] On Behalf Of Arne Georg Gleditsch ]Sent: Monday, September 13, 2010 03:51 AM ]To: Scott Duplichan ]Cc: 'Marc Jones'; coreboot@coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]"Scott Duplichan" scott@notabs.org writes: ]> I think it would be best to clear bit 35 of msr c001_102a in the AP ]> cores as well as the BSP core. Otherwise, the OS might see AP cores ]> having slightly lower performance than the BSP core. This bit affects ]> family 10h revC and newer (45 nm). ] ]Ok, so here's a patch adding this. Clearing bit 35 is done ]unconditionally for all fam10 cpus, is that ok? Setting is done based ]on processor type in defaults.h, as before.
Thanks. This looks correct to me. I used simnow/tilapia to confirm bit 35 gets cleared in all cores. I found bit 35 never actually gets set. I submitted a patch to correct that. Once that patch is applied, I can see bit 35 gets set in all cores, then gets cleared in all cores.
Thanks, Scott
] ]Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numascale.com ] ]-- ] Arne.
On Mon, Sep 13, 2010 at 9:15 PM, Scott Duplichan scott@notabs.org wrote:
]-----Original Message----- ]From: coreboot-bounces+scott=notabs.org@coreboot.org [mailto:coreboot-]bounces+scott=notabs.org@coreboot.org] On Behalf Of Arne Georg Gleditsch ]Sent: Monday, September 13, 2010 03:51 AM ]To: Scott Duplichan ]Cc: 'Marc Jones'; coreboot@coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]"Scott Duplichan" scott@notabs.org writes: ]> I think it would be best to clear bit 35 of msr c001_102a in the AP ]> cores as well as the BSP core. Otherwise, the OS might see AP cores ]> having slightly lower performance than the BSP core. This bit affects ]> family 10h revC and newer (45 nm). ] ]Ok, so here's a patch adding this. Clearing bit 35 is done ]unconditionally for all fam10 cpus, is that ok? Setting is done based ]on processor type in defaults.h, as before.
Thanks. This looks correct to me. I used simnow/tilapia to confirm bit 35 gets cleared in all cores. I found bit 35 never actually gets set. I submitted a patch to correct that. Once that patch is applied, I can see bit 35 gets set in all cores, then gets cleared in all cores.
Thanks, Scott
Hi Scott,
Can you Acked-by: if this is working for you.
Marc
-----Original Message----- ]From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Marc Jones ]Sent: Wednesday, September 15, 2010 01:32 PM ]To: Scott Duplichan ]Cc: Arne Georg Gleditsch; coreboot@coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]On Mon, Sep 13, 2010 at 9:15 PM, Scott Duplichan scott@notabs.org wrote: ]> ]-----Original Message----- ]> ]From: coreboot-bounces+scott=notabs.org@coreboot.org [mailto:coreboot-]]bounces+scott=notabs.org@coreboot.org] On Behalf Of Arne ]> Georg Gleditsch ]> ]Sent: Monday, September 13, 2010 03:51 AM ]> ]To: Scott Duplichan ]> ]Cc: 'Marc Jones'; coreboot@coreboot.org ]> ]Subject: Re: [coreboot] AMD cache setup is broken ]> ] ]> ]"Scott Duplichan" scott@notabs.org writes: ]> ]> I think it would be best to clear bit 35 of msr c001_102a in the AP ]> ]> cores as well as the BSP core. Otherwise, the OS might see AP cores ]> ]> having slightly lower performance than the BSP core. This bit affects ]> ]> family 10h revC and newer (45 nm). ]> ] ]> ]Ok, so here's a patch adding this. Clearing bit 35 is done ]> ]unconditionally for all fam10 cpus, is that ok? Setting is done based ]> ]on processor type in defaults.h, as before. ]> ]> Thanks. This looks correct to me. I used simnow/tilapia to confirm bit ]> 35 gets cleared in all cores. I found bit 35 never actually gets set. ]> I submitted a patch to correct that. Once that patch is applied, I can ]> see bit 35 gets set in all cores, then gets cleared in all cores. ]> ]> Thanks, ]> Scott ] ]Hi Scott, ] ]Can you Acked-by: if this is working for you.
Thanks Marc. Here you go..
Acked-by: Scott Duplichan scott@notabs.org http://www.coreboot.org/pipermail/coreboot/attachments/20100913/5dbed41d/attachment.bin
]Marc
]-- ]http://se-eng.com
On Wed, Sep 15, 2010 at 12:51 PM, Scott Duplichan scott@notabs.org wrote:
-----Original Message----- ]From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Marc Jones ]Sent: Wednesday, September 15, 2010 01:32 PM ]To: Scott Duplichan ]Cc: Arne Georg Gleditsch; coreboot@coreboot.org ]Subject: Re: [coreboot] AMD cache setup is broken ] ]On Mon, Sep 13, 2010 at 9:15 PM, Scott Duplichan scott@notabs.org wrote: ]> ]-----Original Message----- ]> ]From: coreboot-bounces+scott=notabs.org@coreboot.org [mailto:coreboot-]]bounces+scott=notabs.org@coreboot.org] On Behalf Of Arne ]> Georg Gleditsch ]> ]Sent: Monday, September 13, 2010 03:51 AM ]> ]To: Scott Duplichan ]> ]Cc: 'Marc Jones'; coreboot@coreboot.org ]> ]Subject: Re: [coreboot] AMD cache setup is broken ]> ] ]> ]"Scott Duplichan" scott@notabs.org writes: ]> ]> I think it would be best to clear bit 35 of msr c001_102a in the AP ]> ]> cores as well as the BSP core. Otherwise, the OS might see AP cores ]> ]> having slightly lower performance than the BSP core. This bit affects ]> ]> family 10h revC and newer (45 nm). ]> ] ]> ]Ok, so here's a patch adding this. Clearing bit 35 is done ]> ]unconditionally for all fam10 cpus, is that ok? Setting is done based ]> ]on processor type in defaults.h, as before. ]> ]> Thanks. This looks correct to me. I used simnow/tilapia to confirm bit ]> 35 gets cleared in all cores. I found bit 35 never actually gets set. ]> I submitted a patch to correct that. Once that patch is applied, I can ]> see bit 35 gets set in all cores, then gets cleared in all cores. ]> ]> Thanks, ]> Scott ] ]Hi Scott, ] ]Can you Acked-by: if this is working for you.
Thanks Marc. Here you go..
Acked-by: Scott Duplichan scott@notabs.org
r5817
-
Arne Georg Gleditsch -
Marc Jones -
Nick Lemberger -
Patrick Georgi -
Scott Duplichan -
Stefan Reinauer