[coreboot] vga not working

Arnaud Maye arnaud.maye at 4dsp.com
Fri Aug 21 20:37:42 CEST 2009


Myles Watson wrote:
>> 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?
>>     
> It's fine with me.  I guess it might make a difference for ACPI
> suspend/resume support.
>
>   
>> 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.
>>     
> I don't think they should be a problem, but you can set any value you'd like
> once we get your driver loading.
>
>   
>> Actually what is the best way to get pciexp_porta.c to be included and
>> replace the
>> default PCI functions in src\devices ?
>>     
> The boot log helped, see below.
>
>   
>> 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.
>>     
> Coreboot doesn't cache the VGA hole.
>
>   
>> 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.
>>>       
> OK.  I think we're going to get there.  It looks like your driver doesn't
> get registered for the device because the PCI IDs don't match.
>
> >From your boot log:
>
> PCI: 00:02.0 subordinate bus PCI Express
> PCI: 00:02.0 [8086/5024] enabled
> PCI: 00:03.0 subordinate bus PCI Express
> PCI: 00:03.0 [8086/5025] enabled
>
> Those IDs match the EP80579 defines in /src/include/device/pci_ids.h, but
> there is no driver defined which uses that ID.
>
> Copy the drivers in /src/northbridge/intel/i3100/pciexp_porta.c, rename
> them, and have them use the correct PCI IDs.  That should make your
> functions get called.
>   

Thanks, I am going to try that as soon I reach the office on Monday. I 
will keep you updated.

Would it make sense to create an ep80579 folder for both the north and 
south bridges? That
way we would avoid having things like ep80579_raminit.c and raminit.c in 
the i3100 folder.

src/northbridge/intel/ep80579/ and src/southbridge/ep80579

i3100's codename is toledo and ep80579's codename is tolapai

Thank you,

Arnaud





More information about the coreboot mailing list