Reversing the default value of CONFIG_COMPRESS from 1 to 0
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.
More information about the coreboot