Myles Watson wrote:
On Mon, Dec 1, 2008 at 1:52 PM, Jordan Crouse jordan@cosmicpenguin.netwrote:
Myles Watson wrote:
This patch updates qemu. It takes out the bus construct from the dts, adds the dts for ide, isa, and acpi. It changes the default for ide to enabled. It makes it so that only the plugged in cards are dynamic.
Since it's harder in emulation to tell if chips are cards or on the mainboard, I may be wrong with the VGA card. Help?
Excuse my ignorance, but why does it matter? They are on the PCI bus regardless of where the logic lives, right?
It matters for the expansion ROM. If it's onboard, then coreboot has to include it in the lar, otherwise it just reads the "card's" ROM. It also changes the logic of whether or not we set subsytem IDs.
So the defining criteria isn't "onboard or cards", its "need a ROM or not" - because not all onboard GPUs require an option ROM in the main system ROM - some can use an attached EEPROM (as do soldered down NICs and other such devices).
Its not a huge deal, since I see where you are doing with it - but it might relieve some confusion if we called it "need_optionrom" instead of "on_mainboard".
Jordan
-----Original Message----- From: Jordan Crouse [mailto:jordan@cosmicpenguin.net] Sent: Monday, December 01, 2008 4:29 PM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] qemu dts fixes
Myles Watson wrote:
On Mon, Dec 1, 2008 at 1:52 PM, Jordan Crouse
jordan@cosmicpenguin.netwrote:
Myles Watson wrote:
This patch updates qemu. It takes out the bus construct from the dts, adds the dts for ide, isa, and acpi. It changes the default for ide to enabled. It makes it so that only the plugged in cards are dynamic.
Since it's harder in emulation to tell if chips are cards or on the mainboard, I may be wrong with the VGA card. Help?
Excuse my ignorance, but why does it matter? They are on the PCI bus regardless of where the logic lives, right?
It matters for the expansion ROM. If it's onboard, then coreboot has to include it in the lar, otherwise it just reads the "card's" ROM. It
also
changes the logic of whether or not we set subsytem IDs.
So the defining criteria isn't "onboard or cards", its "need a ROM or not" - because not all onboard GPUs require an option ROM in the main system ROM - some can use an attached EEPROM (as do soldered down NICs and other such devices).
I guess the other thing is that you might want to throw an error if something that's soldered on doesn't respond (and it won't change addresses), but you won't even know if someone moves a card from slot to slot or plugs in a new one.
Its not a huge deal, since I see where you are doing with it - but it might relieve some confusion if we called it "need_optionrom" instead of "on_mainboard".
It's carried over from v2, but now is the time to change things that don't make sense.
Thanks, Myles
Jordan,
Sorry I obviously missed the point of your questions. I'd forgotten that the fix went in to make all devices found in the dts be "on the mainboard." Here's a new patch that updates the dts with that in mind. It also fixes the subsystem_vendor, which was broken in the last patch.
I appreciate the sanity check.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On Tue, Dec 2, 2008 at 7:13 AM, Myles Watson mylesgw@gmail.com wrote:
Jordan,
Sorry I obviously missed the point of your questions. I'd forgotten that the fix went in to make all devices found in the dts be "on the mainboard." Here's a new patch that updates the dts with that in mind. It also fixes the subsystem_vendor, which was broken in the last patch.
I appreciate the sanity check.
This patch is updated so that qemu works with resource allocation in phases. Here are the changes:
1. Add a dts for the northbridge so it can have its own ops. 2. Separates the domain from the device resource code. 3. Add new resources for the APIC and VGA area.
Signed-off-by: Myles Watson mylesgw@gmail.com
On Tue, Dec 2, 2008 at 10:57 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Dec 2, 2008 at 7:13 AM, Myles Watson mylesgw@gmail.com wrote:
Jordan,
Sorry I obviously missed the point of your questions. I'd forgotten that the fix went in to make all devices found in the dts be "on the mainboard." Here's a new patch that updates the dts with that in mind. It also fixes the subsystem_vendor, which was broken in the last patch.
I appreciate the sanity check.
This patch is updated so that qemu works with resource allocation in phases. Here are the changes:
- Add a dts for the northbridge so it can have its own ops.
- Separates the domain from the device resource code.
- Add new resources for the APIC and VGA area.
Move the IOAPIC to the the 82371? I'm not sure if the LAPIC belongs in the northbridge on since every core needs one it might belong in the CPU but I think you only need to reserve the range once.
On another note, Do you find the res-> size and res->limit redundant? I can't think of how they could be different.
Marc
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Tuesday, December 02, 2008 8:06 PM To: Myles Watson Cc: jordan@cosmicpenguin.net; coreboot@coreboot.org Subject: Re: [coreboot] qemu dts fixes
On Tue, Dec 2, 2008 at 10:57 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Dec 2, 2008 at 7:13 AM, Myles Watson mylesgw@gmail.com wrote:
Jordan,
Sorry I obviously missed the point of your questions. I'd forgotten
that
the fix went in to make all devices found in the dts be "on the
mainboard."
Here's a new patch that updates the dts with that in mind. It also
fixes
the subsystem_vendor, which was broken in the last patch.
I appreciate the sanity check.
This patch is updated so that qemu works with resource allocation in
phases.
Here are the changes:
- Add a dts for the northbridge so it can have its own ops.
- Separates the domain from the device resource code.
- Add new resources for the APIC and VGA area.
Move the IOAPIC to the the 82371? I'm not sure if the LAPIC belongs in the northbridge on since every core needs one it might belong in the CPU but I think you only need to reserve the range once.
I'm happy to put them wherever makes the most sense. APICs are a black box to me at this point. I've never had to do much with them.
On another note, Do you find the res-> size and res->limit redundant? I can't think of how they could be different.
I just set them both here for completeness. In other resources they aren't redundant, because the limit says how high it could go (usually 0xffff for IO), but the base+size-1 is the end of the resource.
Thanks, Myles
On Tue, Dec 2, 2008 at 8:05 PM, Marc Jones marcj303@gmail.com wrote:
On Tue, Dec 2, 2008 at 10:57 AM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Dec 2, 2008 at 7:13 AM, Myles Watson mylesgw@gmail.com wrote:
Jordan,
Sorry I obviously missed the point of your questions. I'd forgotten
that
the fix went in to make all devices found in the dts be "on the
mainboard."
Here's a new patch that updates the dts with that in mind. It also
fixes
the subsystem_vendor, which was broken in the last patch.
I appreciate the sanity check.
This patch is updated so that qemu works with resource allocation in
phases.
Here are the changes:
- Add a dts for the northbridge so it can have its own ops.
- Separates the domain from the device resource code.
- Add new resources for the APIC and VGA area.
Move the IOAPIC to the the 82371? I'm not sure if the LAPIC belongs in the northbridge on since every core needs one it might belong in the CPU but I think you only need to reserve the range once.
Can we put the LAPIC in the NB domain? Hopefully we can reserve an area that would cover any CPU connected to that NB. Here's my current resource list for qemu. This is after resource assignment.
PCI_DOMAIN: 0000 resource base 1000 size 410 align 8 gran 0 limit ffff flags 80100 index 0 PCI_DOMAIN: 0000 resource base fc000000 size 2001000 align 25 gran 0 limit ffffffff flags 80200 index 1 PCI_DOMAIN: 0000 resource base fec00000 size 100000 align 0 gran 0 limit ffffffff flags e0000200 index 2 PCI_DOMAIN: 0000 resource base fee00000 size 10000 align 0 gran 0 limit ffffffff flags e0000200 index 3 PCI: 00:00.0 resource base 0 size 0 align 0 gran 12 limit ffff flags 80100 index 0 PCI: 00:00.0 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index a PCI: 00:00.0 resource base a0000 size 20000 align 0 gran 0 limit bfff flags c0040200 index 1 PCI: 00:00.0 resource base c0000 size 6f40000 align 0 gran 0 limit 0 flags e0004200 index b PCI: 00:01.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags e0000100 index 0 PCI: 00:01.1 resource base 1400 size 10 align 4 gran 4 limit ffff flags 40000100 index 20 PCI: 00:02.0 resource base fc000000 size 2000000 align 25 gran 25 limit ffffffff flags 40001200 index 10 PCI: 00:02.0 resource base fe000000 size 1000 align 12 gran 12 limit ffffffff flags 40000200 index 14 PCI: 00:03.0 resource base 1000 size 100 align 8 gran 8 limit ffff flags 40000100 index 10
Which APIC resource did you want to move into the 82371?
Thanks, Myles
Can we put the LAPIC in the NB domain? Hopefully we can reserve an area that would cover any CPU connected to that NB. Here's my current resource list for qemu. This is after resource assignment.
Random note: LAPIC is in each CPU. It has always same address in each CPU.
Rudolf
-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: Thursday, December 04, 2008 7:52 AM To: Myles Watson Cc: Marc Jones; coreboot@coreboot.org; jordan@cosmicpenguin.net Subject: Re: [coreboot] qemu dts fixes
Can we put the LAPIC in the NB domain? Hopefully we can reserve an area that would cover any CPU connected to that NB. Here's my current resource list for qemu. This is after resource assignment.
Random note: LAPIC is in each CPU. It has always same address in each CPU.
So would it be reasonable to have the domain reserve it, since having a resource for each CPU at the same place could get confusing? Do we have LAPIC devices on any platforms in Coreboot, so that it could be reserved there?
Thanks, Myles
So would it be reasonable to have the domain reserve it, since having a resource for each CPU at the same place could get confusing? Do we have LAPIC devices on any platforms in Coreboot, so that it could be reserved there?
LAPIC is in any CPU post Pentium.
R.
On Thu, Dec 4, 2008 at 8:21 AM, Rudolf Marek r.marek@assembler.cz wrote:
So would it be reasonable to have the domain reserve it, since having a resource for each CPU at the same place could get confusing? Do we have LAPIC devices on any platforms in Coreboot, so that it could be reserved there?
LAPIC is in any CPU post Pentium.
I was trying to say what Rudolf clarified. There is a local APIC in each CPU core at the addess 0xFEE00000 so we only need to reserve it once. Logically it doesn't make sense to have it in the northbridge. That gets back to just putting it in the domain. I thought that the IOAPIC 0xFEC00000 should in the southbridge but if the LAPIC is in the domain then maybe the IOAPIC shoud be with it.
I think that the only CPU coreboot supports that doesn't have a LAPIC is the Geode. It has no multicore capability and sitll uses the legacy PIC.
Marc
On Thu, Dec 4, 2008 at 10:52 AM, Marc Jones marcj303@gmail.com wrote:
On Thu, Dec 4, 2008 at 8:21 AM, Rudolf Marek r.marek@assembler.cz wrote:
So would it be reasonable to have the domain reserve it, since having a resource for each CPU at the same place could get confusing? Do we have LAPIC devices on any platforms in Coreboot, so that it could be reserved there?
LAPIC is in any CPU post Pentium.
I was trying to say what Rudolf clarified. There is a local APIC in each CPU core at the addess 0xFEE00000 so we only need to reserve it once. Logically it doesn't make sense to have it in the northbridge. That gets back to just putting it in the domain.
That makes sense to me. I didn't want to put it in the CPU because it only needs to be reserved once. This doesn't really matter for resource allocation because the IOAPIC is at a lower address and so resource allocation will never come this high. I'd like it to be logical and complete in case something else needs to know, though.
I thought that the IOAPIC 0xFEC00000 should in the southbridge but if the LAPIC is in the domain then maybe the IOAPIC shoud be with it.
It makes sense to me to put it in the southbridge. Rudolf has said that different southbridges reserve different amounts of space for these, and domains are independent of southbridges.
I think that the only CPU coreboot supports that doesn't have a LAPIC
is the Geode. It has no multicore capability and sitll uses the legacy PIC.
I should have clarified here. I was asking if any of the platforms would create a device in the dts for the LAPIC. I'm assuming that the answer is no.
Thanks, Myles
-
Jordan Crouse -
Marc Jones -
Myles Watson -
Rudolf Marek