Hi Setfan,
Stefan Reinauer stefan.reinauer@coreboot.org writes:
- Sven Schnelle svens@stackframe.org [110503 21:41]:
Stefan Reinauer stefan.reinauer@coreboot.org writes:
Can you do a new analysis on where the boot time goes now? It would be nice to see if there are more optimizations we can do...
Will do. But right now i have the problem that the Keyboard isn't working on cold boot - seabios is probably started so early that some hardware parts are not finished with reset or similar things.
Just enabling debug output in coreboot slows down things enough to make the Keyboard working again.
Does just putting in a delay of some 100ms fix the issue, too? Do you do keyboard init in coreboot? Did you do it before? Just want to make sure there are no side effects coming in through debugging. However, having an EC/SuperIO that needs more than 200ms to boot up does not sound too unlikely.
I do not initialize the Keyboard in coreboot, i'll leave that to seabios. (Enabling it in coreboot doesn't help either).
The original Vendor BIOS talks after around ~1s to the Keyboard controller, so that's quite different to coreboot (coreboot is handing over to seabios after ~200ms)
Getting through all of coreboot in as little as 200ms? This is totally awesome!
So i want to figure out first if there's some 'i-finished-reset-you-can-talk-to-me' flag, or if that problem is caused by another reason.
Does the keyboard init code get any type of timeout?
Well, i've enabled some debugging in seabios, and it's pretty obvious what's happening here. SeaBIOS sends command 0xff (which is RESET i think), and SeabIOS gets 0xfe as response (which is RESEND, but seabios handles that as NAK, and doesn't resend the command).
You can find the boot log here:
http://stackframe.org/seriallog-20110503_175245.log
Sven.