Hello,
Kevin asked to handle this via e-mail, so here we go.
I tried booting with SeaBIOS on DBE63 for some fun and profit, but it unfortunately stalls with some register dumps. I haven't been able to really play with SeaBIOS before, as it can't boot from NAND flash that is on DBE61 and DBE62, but now with the DBE63 prototype on my table I can boot from IDE CompactFlash. On a slightly related note, does SeaBIOS really need to do the bootloader job - could I have it just provide the 16bit services or do we need to implement a geode NAND flash driver in it to have it work for those devces?
The log output at default loglevel of 1 is attached. At higher log levels the last dump seems to come from a different place. Should I gather such logs with a larger loglevel or does this say something revealing already? Anything else I can provide here?
The device boots the GRUB on that CompactFlash fine with legacy BIOS. SeaBIOS gives a similar output when trying a CF with XPe on it.
Regards, Mart Raudsepp
Hi,
On Tue, Jan 27, 2009 at 08:28:13PM +0200, Mart Raudsepp wrote:
I haven't been able to really play with SeaBIOS before, as it can't boot from NAND flash that is on DBE61 and DBE62, but now with the DBE63 prototype on my table I can boot from IDE CompactFlash. On a slightly related note, does SeaBIOS really need to do the bootloader job - could I have it just provide the 16bit services or do we need to implement a geode NAND flash driver in it to have it work for those devces?
You might want to see if there is a NAND flash option rom out there somewhere. If it exists, it could add "drop in" support for booting from flash.
Otherwise, there have been two proposals for this - the first is to have SeaBIOS return to coreboot instead of "booting" the system. Then coreboot could be extended to launch the real boot program (eg, grub) from flash. The other proposal is to implement LAR support in SeaBIOS - then seabios could pull a boot image (eg, grub) from the lar and launch it. I've been a proponent of the second proposal.
The log output at default loglevel of 1 is attached. At higher log levels the last dump seems to come from a different place. Should I gather such logs with a larger loglevel or does this say something revealing already? Anything else I can provide here?
Those messages aren't reporting a problem - I see them on my epia-cn and on qemu. You'll need to increase the debugging level to see if something else is seen before a failure.
BTW, does the DBE63 implement all the legacy hardware (like ioport access to timers, cmos, etc.)?
-Kevin
On T, 2009-01-27 at 20:02 -0500, Kevin O'Connor wrote:
The log output at default loglevel of 1 is attached. At higher log levels the last dump seems to come from a different place. Should I gather such logs with a larger loglevel or does this say something revealing already? Anything else I can provide here?
Those messages aren't reporting a problem - I see them on my epia-cn and on qemu. You'll need to increase the debugging level to see if something else is seen before a failure.
The output at loglevel 20 is very noisy, it will be probably too high for attachment even. The end few kilobytes of output should be as good probably? I can put it on some webspace though if there's a chance the non-tail parts of it could help.
BTW, does the DBE63 implement all the legacy hardware (like ioport access to timers, cmos, etc.)?
I need to research into that... Are these things coreboot would be supporting, or the hardware design itself? Off-hand I just know that there is a cmos layout file in the port.
Thanks, Mart Raudsepp
On Wed, Jan 28, 2009 at 04:25:56AM +0200, Mart Raudsepp wrote:
On T, 2009-01-27 at 20:02 -0500, Kevin O'Connor wrote:
The log output at default loglevel of 1 is attached. At higher log levels the last dump seems to come from a different place. Should I gather such logs with a larger loglevel or does this say something revealing already? Anything else I can provide here?
Those messages aren't reporting a problem - I see them on my epia-cn and on qemu. You'll need to increase the debugging level to see if something else is seen before a failure.
The output at loglevel 20 is very noisy, it will be probably too high for attachment even. The end few kilobytes of output should be as good probably? I can put it on some webspace though if there's a chance the non-tail parts of it could help.
You can gzip it and mail it to me directly, put it on a website, etc.
Debug level 20 tends to show all the irqs - which can adversely impact the boot because of timing. So sending both the log from debug level 20 and a log with debug level 8 would help.
-Kevin
-
Kevin O'Connor -
Mart Raudsepp