[PATCH] v3 Resource allocator to v2
This patch series makes v2 more similar to v3. It splits resource allocation into read, compute, allocate. There is no more mutual recursion. They go in this order: 1. white.diff 2. read_first.diff 3. domain_resources.diff 4. constraint.diff 5. compute_allocate.diff It is boot tested on SimNOW and qemu. domain_resources needs to be expanded to include other southbridges and domains. I just wanted early feedback rather than late. Signed-off-by: Myles Watson <mylesgw@gmail.com> Thanks, Myles
On Fri, May 22, 2009 at 4:17 PM, Myles Watson <mylesgw@gmail.com> wrote:
This patch series makes v2 more similar to v3. It splits resource allocation into read, compute, allocate. There is no more mutual recursion.
They go in this order: 1. white.diff 2. read_first.diff 3. domain_resources.diff 4. constraint.diff 5. compute_allocate.diff
It is boot tested on SimNOW and qemu. Now it is boot tested on Tyan s2892 as well. There are a few changes for multiple links.
Signed-off-by: Myles Watson <mylesgw@gmail.com> Carl-Daniel, I think you can use this to fix your PCI config space problem. If you declare that BAR as a fixed resource, assigned, but not stored, I think it will work. Thanks, Myles
We really need this improvement and boot testing is a good step. Myles, thanks for this; it's a huge jump in our code base. Acked-by: Ronald G. Minnich <rminnich@gmail.com> So much good stuff has come in in the last 2 months in v2; quite impressive! ron
Myles, thanks for this; it's a huge jump in our code base. Thanks :)
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
I am holding off on the commit for now. I don't want to break anyone's board. Remaining issues: 1. Right now I'm testing it with a reserved area for the IOAPIC in the southbridge and a reserved area in the lpc/ISA function of the southbridge. The downside of this is that I have to touch every southbridge to add it. I think it is the right place, though. 2. Kontron will break because I removed its special case from the resource allocator. I think with the new resource allocator it will be easy to fix, but I'd like a Kontron tester. Comments? Thanks, Myles
On 28.05.2009 17:32 Uhr, Myles Watson wrote:
Remaining issues: 1. Right now I'm testing it with a reserved area for the IOAPIC in the southbridge and a reserved area in the lpc/ISA function of the southbridge.
The downside of this is that I have to touch every southbridge to add it. I think it is the right place, though.
Not so much of a downside, since this is a fix for a real issue, and puts the code where it (in my opinion) belongs.
2. Kontron will break because I removed its special case from the resource allocator. I think with the new resource allocator it will be easy to fix, but I'd like a Kontron tester.
I'll be glad to test... Can you suggest a fix or give a pointer on how to fix this? If we can get rid of the PCIe hole handling hack, I'm all for checking this in. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
On Thu, May 28, 2009 at 10:15 AM, Stefan Reinauer <stepan@coresystems.de> wrote:
On 28.05.2009 17:32 Uhr, Myles Watson wrote:
Remaining issues: 1. Right now I'm testing it with a reserved area for the IOAPIC in the southbridge and a reserved area in the lpc/ISA function of the southbridge.
The downside of this is that I have to touch every southbridge to add it. I think it is the right place, though.
Not so much of a downside, since this is a fix for a real issue, and puts the code where it (in my opinion) belongs. Good. I agree.
2. Kontron will break because I removed its special case from the resource allocator. I think with the new resource allocator it will be easy to fix, but I'd like a Kontron tester.
I'll be glad to test... Can you suggest a fix or give a pointer on how to fix this? If we can get rid of the PCIe hole handling hack, I'm all for checking this in. I think there are a couple of possible fixes depending on what the real problem is.
If the problem is that it needs to be at a fixed address, allocate it at the top (as high as you can before the IOAPIC) of the address space, and mark it fixed. I guess there are too many other possibilities for why you needed to implement it that way, but I'd be happy to help you solve the problem. Thanks, Myles
On 28.05.2009 18:23 Uhr, Myles Watson wrote:
2. Kontron will break because I removed its special case from the resource allocator. I think with the new resource allocator it will be easy to fix, but I'd like a Kontron tester.
I'll be glad to test... Can you suggest a fix or give a pointer on how to fix this? If we can get rid of the PCIe hole handling hack, I'm all for checking this in.
I think there are a couple of possible fixes depending on what the real problem is.
If the problem is that it needs to be at a fixed address, allocate it at the top (as high as you can before the IOAPIC) of the address space, and mark it fixed.
It's basically really just a fixed address memory space of a certain fixed size that needs to be kept free by the resource allocator, very similar to the way it needs to be done for the IOAPIC and Local APIC. Since the PCIe BAR is part of the northbridge, I tried to tell the resource allocator to do this in the northbridge.c code, but I couldn't seem to figure out a way to make the (old) allocator honor it. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
It's basically really just a fixed address memory space of a certain fixed size that needs to be kept free by the resource allocator, very similar to the way it needs to be done for the IOAPIC and Local APIC. Great. That makes it easy.
Since the PCIe BAR is part of the northbridge, I tried to tell the resource allocator to do this in the northbridge.c code, but I couldn't seem to figure out a way to make the (old) allocator honor it. There was no check for fixed resources before. There was a #warning in compute_allocate_resources about it. It just set the limits below 0xfec00000, and as long as your fixed resources were above that you were fine.
The gotcha here is that I haven't implemented fixed resources in the middle of the rest of the PCI memory address space. If you declare a fixed region 0xf4000000-0xf4000007 you can no longer use 0xf4000008-0xfec00000. All of the PCI BARs have to fit on one side (above or below) the fixed regions. I don't think that's much of an issue, but it is there. Thanks, Myles
On Wed, May 27, 2009 at 7:01 PM, ron minnich <rminnich@gmail.com> wrote:
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Rev 4394. Thanks, Myles
In SB600, the IOAPIC is allocated in sb600_sm.c. Is there any conflict with sb600_lpc.c? Zheng ________________________________________ From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Myles Watson Sent: Friday, July 03, 2009 2:59 AM To: ron minnich Cc: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] v3 Resource allocator to v2 On Wed, May 27, 2009 at 7:01 PM, ron minnich <rminnich@gmail.com> wrote: Acked-by: Ronald G. Minnich <rminnich@gmail.com> Rev 4394. Thanks, Myles
In SB600, the IOAPIC is allocated in sb600_sm.c. Is there any conflict with sb600_lpc.c?
It was just for backward compatibility. I put a fixed allocation at 0xfec00000 in most boards because that's where it used to be. If there's nothing that needs to be protected there, you can remove it. You'd probably need one for the local APICs for the processors, though. Sorry for the confusion. Thanks, Myles
On Thu, Jul 02, 2009 at 12:58:57PM -0600, Myles Watson wrote:
On Wed, May 27, 2009 at 7:01 PM, ron minnich <rminnich@gmail.com> wrote:
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
Rev 4394.
This patch seems to cause trouble, at least on the Kontron board where I tested recent trunk, but probably on other systems also I'd guess. r4393 works fine, r4394 is the first broken revision. What I see is a module not loading correctly (r8169), and a hard hang later in the boot process (after blacklisting the r8169 module). It seems the hang is caused by intel_agp or agpgart, not sure. Attached is a log from the Kontron board using both r4393 and r4394. The diff shows quite a lot of resource allocation changes, not sure which of those is relevant and is causing the problems. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Rev 4394.
This patch seems to cause trouble, at least on the Kontron board where I tested recent trunk, but probably on other systems also I'd guess. It could be, but the problem you're seeing is Kontron-specific.
Adding PCIe enhanced config space BAR 0xf0000000-0xf4000000. This BAR is added in a way that the allocator doesn't understand. That was done on purpose because the old allocator didn't avoid fixed resources. There are several proposed fixes, but it isn't clear what the best one is. You can chime in. Here are some possible solutions: 1. Let the allocator place the BAR. Care would need to be taken when the BAR was set and the value would have to be passed to the ACPI code. 2. Mark the resource as fixed and let the allocator avoid it. Either you lose a significant portion of the address space or you have to move it. I think you could move it to 0xf8000000-0xfc000000. 3. Add a PCI hole option to the resource allocator and manually allocate things that you want to live there.
r4393 works fine, r4394 is the first broken revision.
Sorry about that. Thanks, Myles
On Sat, Jul 04, 2009 at 07:41:09PM -0600, Myles Watson wrote:
Rev 4394.
This patch seems to cause trouble, at least on the Kontron board where I tested recent trunk, but probably on other systems also I'd guess. It could be, but the problem you're seeing is Kontron-specific.
Hm, possible, but then there are other issues in the new code I guess. Here are two dumps of r4393/r4394 from the MS-6178 (i810) board. The first one works fine and shows a FILO menu (on serial), the second one contains lots of "!! Resource didn't fit !!" lines among other things, and I see a totally garbled or blank FILO screen (on serial) and it seems to hang at that point.
Adding PCIe enhanced config space BAR 0xf0000000-0xf4000000.
This BAR is added in a way that the allocator doesn't understand. That was done on purpose because the old allocator didn't avoid fixed resources. There are several proposed fixes, but it isn't clear what the best one is.
You can chime in.
Not really, I don't know enough about this stuff to post useful comments, sorry.
1. Let the allocator place the BAR. Care would need to be taken when the BAR was set and the value would have to be passed to the ACPI code.
2. Mark the resource as fixed and let the allocator avoid it. Either you lose a significant portion of the address space or you have to move it. I think you could move it to 0xf8000000-0xfc000000.
3. Add a PCI hole option to the resource allocator and manually allocate things that you want to live there.
Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-----Original Message----- From: Uwe Hermann [mailto:uwe@hermann-uwe.de] Sent: Sunday, July 05, 2009 5:14 PM To: Myles Watson Cc: 'ron minnich'; coreboot@coreboot.org Subject: Re: r4394 breaks on hardware (was: Re: [coreboot] [PATCH] v3 Resource allocator to v2)
On Sat, Jul 04, 2009 at 07:41:09PM -0600, Myles Watson wrote:
Rev 4394.
This patch seems to cause trouble, at least on the Kontron board where I tested recent trunk, but probably on other systems also I'd guess. It could be, but the problem you're seeing is Kontron-specific.
Hm, possible, but then there are other issues in the new code I guess. Here are two dumps of r4393/r4394 from the MS-6178 (i810) board. Thanks for testing. That breakage is different.
The first one works fine and shows a FILO menu (on serial), the second one contains lots of "!! Resource didn't fit !!" lines among other things, and I see a totally garbled or blank FILO screen (on serial) and it seems to hang at that point. PNP: 002e.6 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 60 PNP: 002e.6 resource base 0 size 1 align 0 gran 0 limit 0 flags 400 index 70
The problem here is that these two resources are not fixed. Since the limit is set to 7ff on 2e.6 @ 60, the resource allocator tries to fit everything into 0-7ff. If you make this resource fixed, or remove them, the problem will disappear. In your old log, both of those resources end up at 0, which is not good. Thanks, Myles
You can chime in.
Not really, I don't know enough about this stuff to post useful comments, sorry. The point of the new allocator was to make it easier to debug and fix resource allocation problems. Hopefully it is less magical than it was, but I'm happy to help fix all the problems that come up.
Thanks, Myles
PNP: 002e.6 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 60 PNP: 002e.6 resource base 0 size 1 align 0 gran 0 limit 0 flags 400 index 70
The problem here is that these two resources are not fixed. Since the limit is set to 7ff on 2e.6 @ 60, the resource allocator tries to fit everything into 0-7ff. If you make this resource fixed, or remove them, the problem will disappear.
It looks like 2e.6 is Consumer IR, which is a TODO in the Config.lb. Could you try changing it to: device pnp 2e.6 off end I think that will fix it for you. Otherwise you could fill in the correct values if you want it to be enabled. If that doesn't work, send me the log and we'll look again. Thanks, Myles
On Mon, Jul 06, 2009 at 09:25:27AM -0600, Myles Watson wrote:
PNP: 002e.6 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 60 PNP: 002e.6 resource base 0 size 1 align 0 gran 0 limit 0 flags 400 index 70
The problem here is that these two resources are not fixed. Since the limit is set to 7ff on 2e.6 @ 60, the resource allocator tries to fit everything into 0-7ff. If you make this resource fixed, or remove them, the problem will disappear.
It looks like 2e.6 is Consumer IR, which is a TODO in the Config.lb. Could you try changing it to:
device pnp 2e.6 off end
Yep, this fixes it indeed, thanks. Fix committed in r4423. I attached a diff before/after the fix for reference. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
It looks like 2e.6 is Consumer IR, which is a TODO in the Config.lb. Could you try changing it to:
device pnp 2e.6 off end
Yep, this fixes it indeed, thanks. Fix committed in r4423.
Great! Thanks for testing it.
I attached a diff before/after the fix for reference.
Looks good. Thanks, Myles
On Sat, Jul 4, 2009 at 6:41 PM, Myles Watson<mylesgw@gmail.com> wrote:
2. Mark the resource as fixed and let the allocator avoid it. Either you lose a significant portion of the address space or you have to move it. I think you could move it to 0xf8000000-0xfc000000.
this seems the most reasonable to me. But we'll have to see what patrick and stefan say. ron
On Wed, May 27, 2009 at 4:25 PM, Myles Watson <mylesgw@gmail.com> wrote:
On Fri, May 22, 2009 at 4:17 PM, Myles Watson <mylesgw@gmail.com> wrote:
This patch series makes v2 more similar to v3. It splits resource allocation into read, compute, allocate. There is no more mutual recursion.
They go in this order: 1. white.diff 2. read_first.diff 3. domain_resources.diff 3.a domain_functions.diff 3.b reserved_regions.diff 4. constraint.diff 5. compute_allocate.diff
I've added reserved regions for the IOAPICs and flash parts, and removed duplicate pci_domain_read_resources and pci_domain_scan_bus functions. I know I've missed some southbridges. The ones I did were the ones that already had reserved regions because it was simpler to figure those out. If you don't see your southbridge in this list, you could add it or let me know what you think should be reserved. grep Index patches/reserved_regions.diff Index: cbv2/src/southbridge/amd/sb600/sb600_lpc.c Index: cbv2/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c Index: cbv2/src/southbridge/broadcom/bcm5785/bcm5785_sb_pci_main.c Index: cbv2/src/southbridge/intel/esb6300/esb6300_lpc.c Index: cbv2/src/southbridge/intel/i3100/i3100_lpc.c Index: cbv2/src/southbridge/intel/i82801dbm/i82801dbm_lpc.c Index: cbv2/src/southbridge/intel/i82801xx/i82801xx_lpc.c Index: cbv2/src/southbridge/sis/sis966/sis966_lpc.c Index: cbv2/src/southbridge/intel/i82801ca/i82801ca_lpc.c Index: cbv2/src/southbridge/intel/i82801er/i82801er_lpc.c Index: cbv2/src/southbridge/intel/i82371eb/i82371eb_isa.c Here's the rest from the earlier patch. grep Index patches/domain_resources.diff | grep south Index: cbv2/src/southbridge/intel/i82371eb/i82371eb_isa.c Index: cbv2/src/southbridge/amd/amd8111/amd8111_lpc.c Index: cbv2/src/southbridge/intel/i82801gx/i82801gx_lpc.c Index: cbv2/src/southbridge/nvidia/ck804/ck804_lpc.c Index: cbv2/src/southbridge/nvidia/mcp55/mcp55_lpc.c Index: cbv2/src/southbridge/nvidia/ck804/ck804_pci.c Index: cbv2/src/southbridge/nvidia/mcp55/mcp55_pci.c Signed-off-by: Myles Watson <mylesgw@gmail.com> Thanks, Myles
On 28.05.2009 00:25, Myles Watson wrote:
On Fri, May 22, 2009 at 4:17 PM, Myles Watson <mylesgw@gmail.com> wrote:
This patch series makes v2 more similar to v3. It splits resource allocation into read, compute, allocate. There is no more mutual recursion.
They go in this order: 1. white.diff 2. read_first.diff 3. domain_resources.diff 4. constraint.diff 5. compute_allocate.diff
It is boot tested on SimNOW and qemu.
Now it is boot tested on Tyan s2892 as well. There are a few changes for multiple links.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Carl-Daniel,
I think you can use this to fix your PCI config space problem. If you declare that BAR as a fixed resource, assigned, but not stored, I think it will work.
Wow, that's indeed neat. Thanks! I'll try as soon as I have access to the hardware again. Regards, Carl-Daniel -- http://www.hailfinger.org/
participants (6)
-
Bao, Zheng -
Carl-Daniel Hailfinger -
Myles Watson -
ron minnich -
Stefan Reinauer -
Uwe Hermann