I thought ACPI was a superset of _MP_. I have a friend who claims not:
"0xffffffffffff0390 A P I C Local APIC Address 0xfee00000, flags 0x00000001 type 0, length 8 ACPI Processor ID 1 APIC ID 0 Flags 0x00000001 type 0, length 8 ACPI Processor ID 2 APIC ID 1 Flags 0x00000001 type 0, length 8 ACPI Processor ID 3 APIC ID 2 Flags 0x00000001 type 0, length 8 ACPI Processor ID 4 APIC ID 3 Flags 0x00000001 type 1, length 12 I/O APIC ID 4 I/O APIC Address 0xfec00000 Global System Interrupt Base 0x00000000 type 1, length 12 I/O APIC ID 5 I/O APIC Address 0xfe6fe000 Global System Interrupt Base 0x00000018 type 1, length 12 I/O APIC ID 6 I/O APIC Address 0xfe6ff000 Global System Interrupt Base 0x0000001c type 2, length 10 IRQ 0 Global System Interrupt 0x00000002 Flags 0x0000 type 2, length 10 IRQ 0 Global System Interrupt 0x00000002 Flags 0x0000
there's not enough info there to actually do anything."
Is he missing something? Is this old information? I'd like to know.
thanks
ron
On Feb 9, 2008 1:30 PM, ron minnich rminnich@gmail.com wrote:
I thought ACPI was a superset of _MP_. I have a friend who claims not:
"0xffffffffffff0390 A P I C Local APIC Address 0xfee00000, flags 0x00000001 type 0, length 8 ACPI Processor ID 1 APIC ID 0 Flags 0x00000001 type 0, length 8 ACPI Processor ID 2 APIC ID 1 Flags 0x00000001 type 0, length 8 ACPI Processor ID 3 APIC ID 2 Flags 0x00000001 type 0, length 8 ACPI Processor ID 4 APIC ID 3 Flags 0x00000001 type 1, length 12 I/O APIC ID 4 I/O APIC Address 0xfec00000 Global System Interrupt Base 0x00000000 type 1, length 12 I/O APIC ID 5 I/O APIC Address 0xfe6fe000 Global System Interrupt Base 0x00000018 type 1, length 12 I/O APIC ID 6 I/O APIC Address 0xfe6ff000 Global System Interrupt Base 0x0000001c type 2, length 10 IRQ 0 Global System Interrupt 0x00000002 Flags 0x0000 type 2, length 10 IRQ 0 Global System Interrupt 0x00000002 Flags 0x0000
there's not enough info there to actually do anything."
Is he missing something? Is this old information? I'd like to know.
you are right.
for irq routing: ACPI: need madt + dsdt NON ACPI: need mptable
current linux kernel seem could use lapic from ACPI MADT, and other irq routing for device from MPTABLE...never tried... don't think it will work other than AMD 8111/8131 platform
YH
On Feb 9, 2008 2:09 PM, yhlu yinghailu@gmail.com wrote:
you are right.
for irq routing: ACPI: need madt + dsdt NON ACPI: need mptable
current linux kernel seem could use lapic from ACPI MADT, and other irq routing for device from MPTABLE...never tried... don't think it will work other than AMD 8111/8131 platform
I don't understand. On an ACPI system, do you need _MP_ or not?
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I don't understand. On an ACPI system, do you need _MP_ or not?
You dont need MP table in ACPI system.
Rudolf
Rudolf Marek wrote:
I don't understand. On an ACPI system, do you need _MP_ or not?
You dont need MP table in ACPI system.
Rudolf
From what I seem to remember, as soon as you have an ACPI DSDT and MADT, both MP and PIRQ will be ignored.
Stefan
On Feb 9, 2008 5:08 PM, Stefan Reinauer stepan@coresystems.de wrote:
Rudolf Marek wrote:
I don't understand. On an ACPI system, do you need _MP_ or not?
You dont need MP table in ACPI system.
Rudolf
From what I seem to remember, as soon as you have an ACPI DSDT and MADT, both MP and PIRQ will be ignored.
some os still need to use PIRQ table to find out real slot number.
YH
On Feb 9, 2008 4:59 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I don't understand. On an ACPI system, do you need _MP_ or not?
You dont need MP table in ACPI system.
if you have acpi support in OS...
YH
* yhlu yinghailu@gmail.com [080210 02:49]:
On Feb 9, 2008 4:59 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I don't understand. On an ACPI system, do you need _MP_ or not?
You dont need MP table in ACPI system.
if you have acpi support in OS...
Yes, of course. But it is one or the other. You never need/use both ACPI and _MP_, nor?
On Feb 9, 2008 7:33 PM, Stefan Reinauer stepan@coresystems.de wrote:
- yhlu yinghailu@gmail.com [080210 02:49]:
On Feb 9, 2008 4:59 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I don't understand. On an ACPI system, do you need _MP_ or not?
You dont need MP table in ACPI system.
if you have acpi support in OS...
Yes, of course. But it is one or the other. You never need/use both ACPI and _MP_, nor?
For LinuxBIOS support: make linuxbios provide ACPI table include MADT, SRAT, SLIT...but not DSDT.
and linux kernel will use ACPI table with DSDT and use MP Table to get irq routing for devices.
You can not dump the DSDT in legacy BIOS and decode it and use it for LinuxBIOS. that CP is belong to phoenix or AMI instead of MB vendor. except dsdt for 8111/8131/8132 is from AMD.
YH
On Feb 9, 2008 9:51 PM, yhlu yinghailu@gmail.com wrote:
and linux kernel will use ACPI table with DSDT and use MP Table to get irq routing for devices.
So that means that ACPI is not a superset of _MP_. If you need both tables, then ACPI can not be a proper superset.
Which means we can not build a machine with only an ACPI table -- we need both ACPI and _MP_ tables.
Thanks, that was my question.
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Which means we can not build a machine with only an ACPI table -- we need both ACPI and _MP_ tables.
Nope, if you do ACPI routing in DSDT you dont need the MP.
Rudolf
On Feb 9, 2008 10:04 PM, ron minnich rminnich@gmail.com wrote:
On Feb 9, 2008 9:51 PM, yhlu yinghailu@gmail.com wrote:
and linux kernel will use ACPI table with DSDT and use MP Table to get irq routing for devices.
So that means that ACPI is not a superset of _MP_. If you need both tables, then ACPI can not be a proper superset.
Which means we can not build a machine with only an ACPI table -- we need both ACPI and _MP_ tables.
If you have one DSDT that could handle irq routing, (that DSDT need one clean room implementation, instead of "stealing" or referring dumping from legacy BIOS) you could acpi with DSDT only.
you will still need pirq table for some application to find slot number for pci card.
the tiny kernel need to have acpi support, and according to Andi that will need extra 270K bytes.
YH
On Sun, Feb 10, 2008 at 12:10:58PM -0800, yhlu wrote:
If you have one DSDT that could handle irq routing, (that DSDT need one clean room implementation, instead of "stealing" or referring dumping from legacy BIOS) you could acpi with DSDT only.
you will still need pirq table for some application to find slot number for pci card.
So these applications would read the table directly.
Are they running in Linux? Doesn't Linux offer an API with same information?
the tiny kernel need to have acpi support, and according to Andi that will need extra 270K bytes.
Ouch! Good to know!
Does anyone know how OLPC are doing with the device tree in x86 Linux? Seems that we want that (or another easy way to hand over interrupt routing info to the kernel) pretty badly.
//Peter
On Feb 10, 2008 12:22 PM, Peter Stuge peter@stuge.se wrote:
Does anyone know how OLPC are doing with the device tree in x86 Linux? Seems that we want that (or another easy way to hand over interrupt routing info to the kernel) pretty badly.
This came up a while back. I tried to talk to one OLPC person about it, w.r.t. using OF tree instead of ACPI, but the reponse was not at all encouraging. It seemed you had to buy the whole package, including an open firmware bios and callbacks, or you could not really use the OF tree. I can find the email if anyone cares.
I think we should just continue to use _MP_.
ron
ron minnich wrote:
On Feb 10, 2008 12:22 PM, Peter Stuge peter@stuge.se wrote:
Does anyone know how OLPC are doing with the device tree in x86 Linux? Seems that we want that (or another easy way to hand over interrupt routing info to the kernel) pretty badly.
This came up a while back. I tried to talk to one OLPC person about it, w.r.t. using OF tree instead of ACPI, but the reponse was not at all encouraging. It seemed you had to buy the whole package, including an open firmware bios and callbacks, or you could not really use the OF tree. I can find the email if anyone cares.
This is complementary to what uboot and ePAPR do. The whole embedded powerpc scene is shifting to using an OF tree without an actual open firmware system running. Remember: This is where "dtc" came from. So yes, of course it is possible.
I think we should just continue to use _MP_.
On those platforms limited enough so they can still cope with that and on the other hand do not need to care for power consumption, yes. definitely. _MP_ is always good as a quick hack of getting things to work.
On Feb 10, 2008 4:06 PM, Stefan Reinauer stepan@coresystems.de wrote:
This is complementary to what uboot and ePAPR do. The whole embedded powerpc scene is shifting to using an OF tree without an actual open firmware system running. Remember: This is where "dtc" came from. So yes, of course it is possible.
if we can get it to work then I would be very happy.
ron
On Feb 10, 2008 4:36 PM, ron minnich rminnich@gmail.com wrote:
On Feb 10, 2008 4:06 PM, Stefan Reinauer stepan@coresystems.de wrote:
This is complementary to what uboot and ePAPR do. The whole embedded powerpc scene is shifting to using an OF tree without an actual open firmware system running. Remember: This is where "dtc" came from. So yes, of course it is possible.
if we can get it to work then I would be very happy.
do you mean make linux kernel understand dtc for x86 with irq routing?
like acpi supporting x86, and ia64.
wonder if openfirmware support PPC, spard, PA-risc?
YH
YH
On Sun, Feb 10, 2008 at 06:17:12PM -0800, yhlu wrote:
This is complementary to what uboot and ePAPR do. The whole embedded powerpc scene is shifting to using an OF tree without an actual open firmware system running.
if we can get it to work then I would be very happy.
do you mean make linux kernel understand dtc for x86 with irq routing?
Yes exactly, and also for memory map and other hardware information that is currently determined using BIOS interfaces that are emulated by coreboot.
like acpi supporting x86, and ia64.
wonder if openfirmware support PPC, spard, PA-risc?
Don't know, but I think so.
//Peter
On Feb 10, 2008 12:22 PM, Peter Stuge peter@stuge.se wrote:
On Sun, Feb 10, 2008 at 12:10:58PM -0800, yhlu wrote:
If you have one DSDT that could handle irq routing, (that DSDT need one clean room implementation, instead of "stealing" or referring dumping from legacy BIOS) you could acpi with DSDT only.
you will still need pirq table for some application to find slot number for pci card.
So these applications would read the table directly.
Are they running in Linux? Doesn't Linux offer an API with same information?
Yes.
that is just a mapping bus:dev:fn ==> slot number
So the user will known which card is which.
ACPI DSDT should provide such info too. at least for hotplug support.
YH
On Feb 10, 2008 12:10 PM, yhlu yinghailu@gmail.com wrote:
the tiny kernel need to have acpi support, and according to Andi that will need extra 270K bytes.
That's disgusting! 270K for APCI?
ron
-
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer -
yhlu