[coreboot] vga not working

Arnaud Maye arnaud.maye at 4dsp.com
Fri Aug 21 10:21:12 CEST 2009

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 

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

Anything else I should verify?

Thank you,

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090821/0fa45c75/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: boot.TXT
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090821/0fa45c75/attachment.ksh>

More information about the coreboot mailing list