On Fri, Feb 27, 2009 at 2:32 PM, Myles Watson <[email protected]> wrote: > - Show quoted text - > On Fri, Feb 27, 2009 at 2:25 PM, Marc Jones <[email protected]> wrote: >> On Fri, Feb 27, 2009 at 2:10 PM, Myles Watson <[email protected]> wrote: >>> On Fri, Feb 27, 2009 at 1:10 PM, Marc Jones <[email protected]> wrote: >>>> On Fri, Feb 27, 2009 at 12:40 PM, Myles Watson <[email protected]> wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Marc Jones [mailto:[email protected]] >>>>>> Sent: Friday, February 27, 2009 10:51 AM >>>>>> To: Myles Watson >>>>>> Cc: Stefan Reinauer; Coreboot >>>>>> Subject: Re: [coreboot] Coreboot patches for v2 with SeaBIOS >>>>>> >>>>>> On Fri, Feb 27, 2009 at 10:42 AM, Myles Watson <[email protected]> wrote: >>>>>> >>>>>> > Does this work for you with 4G of RAM? I don't have a Kontron board, >>>>>> > but I copied the implementation to the amdk8 northbridge code. It >>>>>> > works for me when I have the RAM "boosted" and it works when I boot >>>>>> > with less than 4G, but if I boot with 4G it tries to put the high >>>>>> > tables in the PCI decode space since they overlap. >>>>>> > >>>>>> > Besides that the patch is working well for me, and I'd like to see it >>>>>> merged. >>>>>> > >>>>>> > If it works in the 4G case and I just didn't implement it right for K8: >>>>>> > >>>>>> > Acked-by: Myles Watson <[email protected]> >>>>>> > >>>>>> >>>>>> Do you have an off by 1 problem? That would cause the problem @ 4GB as >>>>>> you described. >>>>> >>>>> I'm confused ( again :) ) >>>>> >>>>> I'm not sure where the off by one problem would be. >>>>> >>>>> I thought the problem was that when you have the top of RAM at 0x100000000 >>>>> and then subtract some small number from it you end up at 0xffff0000, >>>>> which >>>>> isn't where you should be accessing normal RAM, or reserving it for ACPI. >>>> >>>> I guess I didn't understand what you were saying. I assumed it was a >>>> problem with a size calculation at 4GB. If you have 4GB of memory it >>>> should hoist (boost) some portion of it. 512MB or 1GB typically. Is >>>> there a bug in the memory hoist code? Can you check what the tomk is >>>> with 4GB >>> >>> Sorry that took a while. Here are snippets of the output (full output >>> attached) >>> >>> //4 GB getting cleared: >>> Setting up local apic... apic_id: 0x00 done. >>> Clearing memory 2048K - 4194304K: >>> --------------------------------------------------------------- done >>> CPU #0 initialized >>> ... >>> //This is from northbridge.c where I grabbed the space for the high tables: >>> 0: mmio_basek=003e0000, basek=003e0000, limitk=00400000 >> >> It looks like CONFIG_HW_MEM_HOLE_SIZEK might not be set. I don't think >> that you are getting any memory hoisted.
You're right. > I guess I'll have to look into it more. > CONFIG_HW_MEM_HOLE_SIZEK = 1048576 > CONFIG_HW_MEM_HOLE_SIZE_AUTO_INC = 0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Setting resources... pci_domain_set_resources: HOLE_SIZEK=00100000, mmio_basek=003e0000 before hole check node 0 : mmio_basek=003e0000, basek=00000000, limitk=00400000 node 0 : mmio_basek=003e0000, basek=00000300, limitk=00400000 split needed: basek=00000300, limitk=00400000 first region of split: basek=00000300, pre_sizek=003dfd00 size left: sizek=00020000 node 0...@30 basek=003e0000, sizek=00000000 0: mmio_basek=003e0000, basek=003e0000, limitk=00400000 40K table at =f7ff0000 VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device It looks like it's using mmio_basek instead of limitk-HOLE_SIZEK for the first region. Then it doesn't do the second region. Thanks, Myles -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
