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 :)
By the way, such a bug is much less likely to ever happen in v3.
Regards, Carl-Daniel
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.
Regards, Elia Yehuda.