[coreboot] Coreboot patches for v2 with SeaBIOS

[Myles Watson]

On Fri, Feb 27, 2009 at 2:32 PM, Myles Watson <mylesgw at gmail.com> wrote:
> - Show quoted text -
> On Fri, Feb 27, 2009 at 2:25 PM, Marc Jones <marcj303 at gmail.com> wrote:
>> On Fri, Feb 27, 2009 at 2:10 PM, Myles Watson <mylesgw at gmail.com> wrote:
>>> On Fri, Feb 27, 2009 at 1:10 PM, Marc Jones <marcj303 at gmail.com> wrote:
>>>> On Fri, Feb 27, 2009 at 12:40 PM, Myles Watson <mylesgw at gmail.com> wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Marc Jones [mailto:marcj303 at gmail.com]
>>>>>> 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 <mylesgw at gmail.com> 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 <mylesgw at gmail.com>
>>>>>> >
>>>>>>
>>>>>> 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 at 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