[LinuxBIOS] LNXI Merge: lnxi-patch-14/16

[yhlu]

good,

In the get_apicid_base, i already make it use the hole for io apic under
dual core and apic lifting even BSP is not lifted.

YH

On 10/8/05, Eric W. Biederman <ebiederman at lnxi.com> wrote:
>
> Stefan Reinauer <stepan at openbios.org> writes:
>
> > * Eric W. Biederman <ebiederman at lnxi.com> [050907 17:39]:
> >> yhlu <yinghailu at gmail.com> writes:
> >>
> >> > at such case We need to enable 8 bit ext apic id mode for Opteron. So
> > Opteron
> >> > could use 0x10 above.
> >> > and leave 0-0x0f to the device that can not support 8 bit apic id.
> >> >
> >> > I'm considering to align apic id lifting to the way that Norma BIOS
> does.
> >>
> >> Are io-apics limited to apic ids 0x0-0x0f as well?
> >>
> >> My memory says to me the limit should be 0x0-0xff...
> >
> > That's device specific I think. At least the 8131 has a maximum ioapic
> > address of 0x0f. See the island/aruma board. It has 7 8131, an 8111 and
> > 4 cpus. No way of getting this to work with Linux with LAPICs below
> > 0x10.
> >
> > How can we get this running with the LNXI patch?
>
> So I did a little bit of research and the original apics all only
> support 0x0-0x0f with 0x0f being the broadcast address. So
> since it appears we can only be able to count on the cpus having
> large apicid support things need to be tweaked a little bit.
>
> What that probably means is tweaking the default cpu apicid assignment
> scheme, and tweaking the io-apicid address code to find holes in
> the device tree instead of just looking for the end. Something
> like the current policy with the improved LNXI mechanism.
>
> I hate running out of address bits!
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051008/125e2a7e/attachment.html>