[coreboot] fixing i810 onboard vga

[Carl-Daniel Hailfinger]

On 08.11.2008 02:09, Elia Yehuda wrote:
> On Fri, Nov 7, 2008 at 9:46 AM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 07.11.2008 07:00, Elia Yehuda wrote:
>>     
>>> before anything else :-)
>>> right when i turn on the pc, those zeros (0x00) starts to show on the
>>>       
>> screen
>>     
>>> (i use gtkterm in hexmode since minicom wont show me those hexed zeros),
>>> fill the screen slowly for 2 minutes, and only then the following
>>>       
>> coreboot
>>     
>>> messages shows up and the boot starts :
>>>
>>> coreboot-2.0.0.0Fallback Fri Nov  7 04:00:16 IST 2008 starting...
>>> Ram1.00
>>> i810 Initial registers have been set.
>>> Ram2.00
>>> ...
>>>
>>> so, to sum it up -
>>> turn on computer
>>> zeors on the screen for 2 minutes
>>> coreboot starts
>>>
>>> hope this clears matters up ;)
>>>
>>>       
>> That's a known bug with quite a few boards. Nobody has tracked it down
>> yet. You're probably the first person to notice these zeros.
>>
>> Can you sprinkle POST codes liberally all over the map and note down
>> when the zero sending starts? Since the delay is so long, observing POST
>> codes on a POST card should work fine.
>>
>>     
>
> if you could just say it again in a way i can understand what you are
> talking about, it would be great :)
>   

Try to find the code paths which are executed between powerup and the
first boot message. Insert instructions like
post_code(0x01);
post_code(0x02);
or
outb(0x01, 0x80);
outb(0x02, 0x80);
and check with a POST card after which POST code the delays happen.


> and since this thread had been hijacked already, i'd like to add my 2 cents
> on the "fixing bad vendor/device id" issue -
>
> as a new coreboot user, i would expect coreboot (plus its payload) to
> perform at least as good as my current bios (although it exceeds it imo...).
> having coreboot to fail on bad vendor/device id, is a bad practice just like
> having those bad vendor/device id in the first place - if there is a known
> bug, instead of ignoring it and saying "oh yes, its THEIR bug, we're not
> going to fix it, but the user can run this xxx tool which might" is only
> making matters worse. the best thing is having a warning on coreboot
> signaling that it uses fallback vendor/device id due to (...) and still
> having a tool to fix those roms, which is always a good thing to have.
>   

You see, the decision about which ROM to execute for a given PCI device
is partially derived from that vendor and device ID.
Separate cards with their own on-card ROM chips don't have that bug.
(They would  fail with a normal BIOS as well.)
And PCI devices where the ROM lives inside the normal mainboard flash
can be checked at coreboot build time once my tool is done. If anyone
wants to ignore warnings/errors from that tool, it's his fault if stuff
doesn't work.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/