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@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