[coreboot] vga not working
Arnaud Maye
arnaud.maye at 4dsp.com
Fri Aug 21 12:34:43 CEST 2009
As an additional information, I've seen that :
1)
coreboot was running at 0x4000. I've changed Options.lb in
mainboard\intel\truxton :
-- default CONFIG_RAMBASE=0x00004000
++ default CONFIG_RAMBASE=0x00100000
This did not compile so I've had to add :
++ uses CONFIG_LB_MEM_TOPK
++ default CONFG_LB_MEM_TOPK = 2 * 1024 * 1024
This did not change anything to the VGA problem, I think I will keep
this that way, what
you guys are thinking about this?
2)
My auto.c patch is not consistent as this is called prior the
enable_resource function in
fact. The function enable_resource is using logical or operations. In
this case I still gets
some unwanted bits obviously. Actually yesterday I was very tired I
guess. The value
0xb means 0b1011 :
2PERRE = 1, 2SERRE = 1 and VGAEN = 1.
I am not sure 2PERRE or 2SERRE would be any relevant around my problem.
But the
legacy BIOS do not set these to 1, this is a fact.
Actually what is the best way to get pciexp_porta.c to be included and
replace the
default PCI functions in src\devices ?
As an additional question:
1)
Can these memory holes be cached or not. I guess these ranges should not
correspond to a
cacheable RAM section. Does coreboot cache the complete 0x0 to
CONFIG_LB_MEM_TOPK area.
The chipset configuration provide the complete memory range as coherent
memory.
Thank you
Arnaud
Arnaud Maye wrote:
> Myles Watson wrote:
>>> The ep80579 has two x4 lanes peripherals (00:02.0 and 00:03.0) both of
>>>
>> You mean the i3100 here, right?
>>
>>
> Yeah the EP80579 is a SOC ( System on chip ). It includes a IA32 core,
> a North Bridge and a
> South Bridge all on the same chip. In this respect talking about i3100
> is not very correct I believe.
> It is clear they have a i3100 core there inside. it is just not named
> in fact. The ep80579 has an
> IMCH and a IICH.
>
> The northbridge and southbridge are connected by a NSI ( North-South
> Interface ). This is in
> fact a custom transparent PCIe implementation. So finally most of the
> devices are on bus 0.
>
>>> them having a register 0x3E. If you set
>>> ISAEN on 00:02.00 you have to set ISAEN on 00:03.00 as well. This is a
>>> requirement provided by Intel in fact.
>>> It makes sense as the address decoding is different as soon ISAEN is
>>> set. All th bridges should be set correctly.
>>>
>>> These two peripherals can be coupled together providing x8 lanes.
>>>
>>> Note that ISAEN is not set by the legacy BIOS, and the VGA output is
>>> working flawlessly. So in fact I just want
>>> to write 0x8 instead 0xb in register 0x3E. But this I can already do,
>>> just not at the correct place.
>>>
>> So where have you tried? File and function?
>>
>> It looks like if that's the bit you want to set you need to have your
>> own
>> enable_resources function in pciexp_porta.c. Right now you're using the
>> default.
>>
>>
> In auto.c ( mainboard\intel\truxton ) I've created a enable_vga()
> function which only
> pci_write_config(dev, 0x3e, 8).
>
> This function is called at the end of auto.c's main() after the
> ram_fill/ram_verify.
>
> I agree, I need my own enable_resources function. This is the patch
> I've tried to do. I've attached
> the patch. In fact it is not called because I did not include it. I
> did expect this file to be
> correctly included as it is part of the initial port.
>
> As you can see I have added a printk in pcie_init and I do not see
> that on the log.
>
>>> With the GFX card connected to SLOT0, the PCIe is operating in coupled
>>> mode and actually configured as x8.
>>> This is because the current coreboot port does not set PEACAPA.SIMP
>>> to 1
>>> in both bridge. As soon both 00:02.0
>>> and 00:03.0 get PEACAPA.SIMP is set to 1, the two port are configured
>>> in x4. We can see that in
>>> PEALNKCAP.MLW. Checking legacy BIOS settings confirm PEACAPA.SIMP
>>> should
>>> be 1 in both PCIe
>>> ports.
>>>
>> So this should probably be done even earlier. That's not something
>> that is
>> fixed, right? Or do you want it coupled (or not) depending on what card
>> gets plugged in?
>>
>>
> Actually for a very generic port we should come up with some config
> options. About the truxton board,
> We have an architecture like the following :
>
> PCIe PEA0 (4x) -> SLOT0
> PCIe PEA1 (4x) -> PCIe SWITCH -> SLOT1 (1x), SLOT2 (1x), SLOT3 (1x),
> SLOT4 (1x)
>
> For a truxton BSP we should not have both ports coupled as a (8x),
> Just imagine if you decide to have
> a GFX card on slot 0 and a ethernet card on SLOT2, this is not going
> to go very well.
>
> I think having some CONFIG option for this would be great. And I think
> this should indeed happen
> in pcie_init().
>
> Actually, there a are a few other things like that which are not
> important to describe so far I believe.
> Verifying all the registers value takes time. lspci legacy vs coreboot
> shows a lot of differences and
> in this respect I am checking them one by one using the datasheet. So
> it is likely some other things
> will pop up.
>>> I guess the only thing left is that coreboot does not allocate a hole
>>> for the VGA, two holes are required I guess,
>>> MEM and IO. how can I check if a hole is actually reserved or not?
>>>
>> Look through the last resource tree in the boot log. It should be
>> there.
>>
>> You can always add them in read_resources.
>>
>
> I have attached my last log. I believe we have the correct hole :
>
> PCI_DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0
> flags e0004200 index 3
> PCI_DOMAIN: 0000 resource base c0000 size 1ff40000 align 0 gran 0
> limit 0 flags e0004200 index 4
>
> We do not have anything between 0xa0000 and 0xc0000. These areas are
> in fact VGAA, MDA and
> VGAB.
>
> Anything else I should verify?
>
> Thank you,
>
> Arnaud
*
*
More information about the coreboot
mailing list