Reversing the default value of CONFIG_COMPRESS from 1 to 0

ollie lho ollie at sis.com.tw
Tue Nov 19 03:18:00 CET 2002


On Tue, 2002-11-19 at 09:01, ollie lho wrote:
> On Tue, 2002-11-19 at 05:25, Eric W. Biederman wrote:
> > "Ronald G. Minnich" <rminnich at lanl.gov> writes:
> > 
> > > Eric, how much heartburn is there if we set the default value of 
> > > CONFIG_COMPRESS to 0? 
> > > 
> > > I've just hit another platform where it is trouble. At this point I 
> > > believe there are only a small number of platforms for which it works well 
> > > if set to 1. Do you have any issues if we have it default to 0, not 1, so 
> > > it is only enabled on platforms it is "known good" on?
> > 
> > My gut reaction says to keep the default as is, and just change it for known
> > problem boards.
> > 
> > Long term we want memory at 0xf0000.
> > 
> > In addition we have another way to solve this problem.  Write the code to assign
> > irqs, given a pirq table.  And that is something long term we need to do as well.
> > 
> 
> If the problem only occurs for IRQ table, why do we copy them to EBDA 
> instead of 0xf0000 ?? Is the 639kB used for other purpose ??
> 

OOPS, I am wrong. It is MP table that is searched in 639kB not PIRQ 
table (although they can be used for the same purpose). I must done
too much debug in this Intel Hyperthread/APIC stuff. 

Ollie





More information about the coreboot mailing list