Amd_early_mtrr.c
#ifndef AMD_EARLYMTRR_C #define AMD_EARLYMTRR_C #include <cpu/x86/mtrr.h> #include <cpu/amd/mtrr.h> #include "cpu/x86/mtrr/earlymtrr.c"
static void amd_early_mtrr_init(void) { static const unsigned long mtrr_msrs[] = { /* fixed mtrr */ 0x250, 0x258, 0x259, 0x268, 0x269, 0x26A, 0x26B, 0x26C, 0x26D, 0x26E, 0x26F, /* var mtrr */ 0x200, 0x201, 0x202, 0x203, 0x204, 0x205, 0x206, 0x207, 0x208, 0x209, 0x20A, 0x20B, 0x20C, 0x20D, 0x20E, 0x20F, /* var iorr msr */ 0xC0010016, 0xC0010017, 0xC0010018, 0xC0010019, /* mem top */ 0xC001001A, 0xC001001D, /* NULL end of table */ 0 }; msr_t msr; const unsigned long *msr_addr;
/* Enable the access to AMD RdDram and WrDram extension bits */ msr = rdmsr(SYSCFG_MSR); msr.lo |= SYSCFG_MSR_MtrrFixDramModEn; wrmsr(SYSCFG_MSR, msr);
/* Inialize all of the relevant msrs to 0 */ msr.lo = 0; msr.hi = 0;
for (msr_addr = mtrr_msrs; *msr_addr; msr_addr++) { wrmsr(*msr_addr, msr); }
/* Disable the access to AMD RdDram and WrDram extension bits */ msr = rdmsr(SYSCFG_MSR); msr.lo &= ~SYSCFG_MSR_MtrrFixDramModEn; wrmsr(SYSCFG_MSR, msr);
/* Enable memory access for 0 - 1MB using top_mem */ msr.hi = 0; msr.lo = ((CONFIG_LB_MEM_TOPK << 10) + TOP_MEM_MASK) & ~TOP_MEM_MASK; wrmsr(TOP_MEM, msr);
/* Enable caching for 0 - 1MB using variable mtrr */ set_var_mtrr(0, 0, (CONFIG_LB_MEM_TOPK << 10), MTRR_TYPE_WRBACK);
#if defined(XIP_ROM_SIZE) /* enable write through caching so we can do execute in place * on the flash rom. */ set_var_mtrr(1, XIP_ROM_BASE, XIP_ROM_SIZE, MTRR_TYPE_WRBACK); #endif
/* Set the default memory type and enable fixed and variable MTRRs */ /* Enable Variable MTRRs */ msr.hi = 0x00000000; msr.lo = 0x00000800; wrmsr(MTRRdefType_MSR, msr);
/* Enale the MTRRs in SYSCFG */ msr = rdmsr(SYSCFG_MSR); msr.lo |= SYSCFG_MSR_MtrrVarDramEn; wrmsr(SYSCFG_MSR, msr);
/* Enable the cache */ enable_cache(); }
#endif /* AMD_EARLYMTRR_C */
YhLu YhLu@tyan.com writes:
Amd_early_mtrr.c
Ok. I will agree that disable_cache in amd_early_mtrr is overkill and remove that. Since the wbinvd seems to be necessary in the general disable_cache case.
I am leery about not reusing code between the various versions of mtrr setup because that causes behaviour skew.
It actually is not appropriate to enable cache of memory until we have enabled it. You don't see that on an Opteron but it is trivial to see on a Xeon, and that has been a bug that has been waiting to hit us for a while. CPU prefetch units can cause amazing problems.
As for messing with RdDram and WrDram extension bits we are not using the fixed mtrrs at this point and I fee that is better a question left up cpu initialization code to handle later. Hmm. We don't actually handle it later either so I have just added that code, there. That way everything should be all in one place.
Thanks for the code review.
Eric
On Wed, 2004-10-20 at 20:52, Eric W. Biederman wrote:
As for messing with RdDram and WrDram extension bits we are not using the fixed mtrrs at this point and I fee that is better a question left up cpu initialization code to handle later. Hmm. We don't actually handle it later either so I have just added that code, there. That way everything should be all in one place.
I have done that but you removed they ALL in your new CPU thing. It was there for reasons, we need the RdDRAM/WrDram programmed correct for VGA devices.
Ollie
Li-Ta Lo ollie@lanl.gov writes:
On Wed, 2004-10-20 at 20:52, Eric W. Biederman wrote:
As for messing with RdDram and WrDram extension bits we are not using the fixed mtrrs at this point and I fee that is better a question left up cpu initialization code to handle later. Hmm. We don't actually handle it later either so I have just added that code, there. That way everything should be all in one place.
I have done that but you removed they ALL in your new CPU thing. It was there for reasons, we need the RdDRAM/WrDram programmed correct for VGA devices.
Oops it was a big re-org and I had not realized I had missed some of the cpu development. What it should have been was a lot of code motion and a few cleanups in structure I did not intend to drop any functionality.
I still need to get back in there and implement overlapping mtrrs.
At this point we should be able to look at the device tree and see if we need to use and io range register or the RdRam WrDram bits.
Eric
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my mind ? I hope in the mtrr.c for K8 instead of hack with the mem_map we have:
setup_mtrr() { if (search_for_vga_device_on_the_tree() == FOUND) { enable_rd_wr_mem_in_fixed_mtrr(); clear_rd_wr_mem_for_legacy_vga_buffer(); set_IORR_to_AGP_aperture(); } else { disable_rd_wr_mem(); }
do_some_other_thigs(); }
And the code is executed on each processors.
Ollie
Li-Ta Lo ollie@lanl.gov writes:
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my mind ? I hope in the mtrr.c for K8 instead of hack with the mem_map we have:
setup_mtrr() { if (search_for_vga_device_on_the_tree() == FOUND) { enable_rd_wr_mem_in_fixed_mtrr(); clear_rd_wr_mem_for_legacy_vga_buffer(); set_IORR_to_AGP_aperture(); } else { disable_rd_wr_mem(); }
do_some_other_thigs(); }
And the code is executed on each processors.
I was thinking more like:
for_each_mem_resource() { if (resource < TOP_MEM) { if (can_use_fixed_iorr()) { setup_fixed_iorr_in_fixed_mtrr(); } else { setup_iorr(); } } }
That should be a fairly simple loop to code up. The interesting part is to add a resource to the VGA devices who gets to live at the legacy address.
Largely I had not realized mtrr.c had been updated to handle this before my merge or I would have made an attempt to convert that code.
It looks like it would be profitable for me to look through the old cpu directories and see what code changes I have missed.
Eric
On Thu, 21 Oct 2004, Eric W. Biederman wrote:
It looks like it would be profitable for me to look through the old cpu directories and see what code changes I have missed.
and, ah, <cough>, commit more often.
"Be more committed" :-)
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Thu, 21 Oct 2004, Eric W. Biederman wrote:
It looks like it would be profitable for me to look through the old cpu directories and see what code changes I have missed.
and, ah, <cough>, commit more often.
"Be more committed" :-)
Ron that joke is getting real old. Especially when I am working hard to get all of the pieces sorted out.
The joke actually grates when it comes to this piece of code especially as you asked me to hold of on committing these changes and then before we could resolve anything LANL had 2 months of downtime.
I was intending to be very careful about breaking things at that point. But at this were delayed so much I figured it was much healthier to go ahead push in the code reorganization and break everything, and then pick up the pieces.
If time were not a finite resource I could do more... Hmm.... Ron do you know if any of the research at LANL is working on something that could help with this problem?
Eric
On Fri, 22 Oct 2004, Eric W. Biederman wrote:
Ron that joke is getting real old. Especially when I am working hard to get all of the pieces sorted out.
sorry! your efforts are always appreciated.
If time were not a finite resource I could do more... Hmm.... Ron do you know if any of the research at LANL is working on something that could help with this problem?
if you don't mind being sucked into a black hole.
ron
Li-Ta Lo ollie@lanl.gov writes:
On Thu, 2004-10-21 at 12:00, Eric W. Biederman wrote:
At this point we should be able to look at the device tree and see if we need to use and io range register or the RdRam WrDram bits.
Are you talking somthing in my mind ? I hope in the mtrr.c for K8 instead of hack with the mem_map we have:
Ok I just put in amd_mtrr.c the equivalent of what you had in mtrr.c At least with respect to the fixed mtrrs.
Things still need to be refined quite a bit, but this should be a good start for the short term.
Eric
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Ronald G. Minnich -
YhLu