[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