Hello list,
I´m trying to boot a Via pc2500e motherboard with coreboot and seabios (built from coreboot, stable).
Everything is ok, I can see the bootmenu (I have only one hard disk at the moment), but when I press "1" it seems coreboot is restarting entering in a loop.
Is this a normal behaviour? I tried attaching a bootorder file with cbfstool with same result.
I attach you the log.
Thanks in advance.
Best regards,
Elisenda
On Tue, Dec 27, 2011 at 08:03:41PM +0100, Elisenda Cuadros wrote:
Hello list,
I´m trying to boot a Via pc2500e motherboard with coreboot and seabios (built from coreboot, stable).
Everything is ok, I can see the bootmenu (I have only one hard disk at the moment), but when I press "1" it seems coreboot is restarting entering in a loop.
Is this a normal behaviour? I tried attaching a bootorder file with cbfstool with same result.
That is not normal. Does the machine boot okay if you don't hit F12 to enter the boot menu?
-Kevin
Hello,
I tried it too, same result. Coreboot reboots.
I attach a new log with debug set to 10 on SeaBIOS.
Thanks for your reply.
Regards,
Elisenda
On 28/12/2011 1:50, Kevin O'Connor wrote:
That is not normal. Does the machine boot okay if you don't hit F12 to enter the boot menu?
-Kevin
On Wed, Dec 28, 2011 at 09:59:24AM +0100, Elisenda Cuadros wrote:
Hello,
I tried it too, same result. Coreboot reboots.
I attach a new log with debug set to 10 on SeaBIOS.
The logs indicate that you have both coreboot and seabios executing option roms. This is known to confuse some roms - please configure coreboot so it does not execute any roms. I don't know if this will correct the issue or not.
The output indicates that seabios is halting within post.c between the call to memmap_finalize() and the memset in startBoot() - so if the above doesn't fix the issue, adding debugging in that area should track down what is going wrong.
-Kevin
Hi,
I tried what you said, but it seems this is not the problem.
I changed the ram module too, it didn´t fix anything.
How can I add the debugging code you told me?
I attach a new log.
Thank you for your valuable help.
Best Regards,
Elisenda
On 29/12/2011 2:58, Kevin O'Connor wrote:
The logs indicate that you have both coreboot and seabios executing option roms. This is known to confuse some roms - please configure coreboot so it does not execute any roms. I don't know if this will correct the issue or not.
The output indicates that seabios is halting within post.c between the call to memmap_finalize() and the memset in startBoot() - so if the above doesn't fix the issue, adding debugging in that area should track down what is going wrong.
-Kevin
On Thu, Dec 29, 2011 at 07:23:44PM +0100, Elisenda Cuadros wrote:
Hi,
I tried what you said, but it seems this is not the problem.
I changed the ram module too, it didn´t fix anything.
How can I add the debugging code you told me?
Change the code with something like the below.
-Kevin
--- a/src/post.c +++ b/src/post.c @@ -197,6 +197,7 @@ void VISIBLE32FLAT startBoot(void) { // Clear low-memory allocations (required by PMM spec). + dprintf(1, "d\n"); memset((void*)BUILD_STACK_ADDR, 0, BUILD_EBDA_MINIMUM - BUILD_STACK_ADDR);
dprintf(3, "Jump to int19\n"); @@ -272,12 +273,15 @@ maininit(void) memmap_finalize();
// Setup bios checksum. + dprintf(1, "a\n"); BiosChecksum -= checksum((u8*)BUILD_BIOS_ADDR, BUILD_BIOS_SIZE);
// Write protect bios memory. + dprintf(1, "b\n"); make_bios_readonly();
// Invoke int 19 to start boot process. + dprintf(1, "c\n"); startBoot(); }
Hello,
Happy New Year to everyone :-)
Kevin, thank you very much for your help.
I changed the code according to your message.
Now "a,b,c,d" appears in the log. I don´t know if this is a good symptom or not.
What can I do to debug more into this problem? I feel pretty useless...
Thank you.
Best regards,
Elisenda
On 04/01/2012 4:12, Kevin O'Connor wrote:
On Thu, Dec 29, 2011 at 07:23:44PM +0100, Elisenda Cuadros wrote:
Hi,
I tried what you said, but it seems this is not the problem.
I changed the ram module too, it didn´t fix anything.
How can I add the debugging code you told me?
Change the code with something like the below.
-Kevin
--- a/src/post.c +++ b/src/post.c @@ -197,6 +197,7 @@ void VISIBLE32FLAT startBoot(void) { // Clear low-memory allocations (required by PMM spec).
dprintf(1, "d\n"); memset((void*)BUILD_STACK_ADDR, 0, BUILD_EBDA_MINIMUM - BUILD_STACK_ADDR);
dprintf(3, "Jump to int19\n");
@@ -272,12 +273,15 @@ maininit(void) memmap_finalize();
// Setup bios checksum.
dprintf(1, "a\n"); BiosChecksum -= checksum((u8*)BUILD_BIOS_ADDR, BUILD_BIOS_SIZE);
// Write protect bios memory.
dprintf(1, "b\n"); make_bios_readonly();
// Invoke int 19 to start boot process.
dprintf(1, "c\n"); startBoot(); }
On Wed, Jan 04, 2012 at 10:32:35PM +0100, Elisenda Cuadros wrote:
Hello,
Happy New Year to everyone :-)
Kevin, thank you very much for your help.
I changed the code according to your message.
Now "a,b,c,d" appears in the log. I don´t know if this is a good symptom or not.
What can I do to debug more into this problem? I feel pretty useless...
[...]
On 04/01/2012 4:12, Kevin O'Connor wrote:
On Thu, Dec 29, 2011 at 07:23:44PM +0100, Elisenda Cuadros wrote: startBoot(void) { // Clear low-memory allocations (required by PMM spec).
dprintf(1, "d\n"); memset((void*)BUILD_STACK_ADDR, 0, BUILD_EBDA_MINIMUM - BUILD_STACK_ADDR);
dprintf(3, "Jump to int19\n");
Well, since you saw "d", but not "Jump to int19" it would indicate that it died in the memcpy (I assume your debug level was set to something higher than 3). That's really strange - I don't know why it would halt there. You could change the first dprintf to read something like:
dprintf(1, "d addr=%p len=%x\n", (void*)BUILD_STACK_ADDR, BUILD_EBDA_MINIMUM - BUILD_STACK_ADDR);
If the output makes sense (it should report 0x7000 and 0x89000) and it is really halting in the memset, then maybe coreboot is mapping something into the first 1 meg of ram - though that's just a wild guess.
-Kevin
Hello,
I tried what you said and I can see the following:
<snip>
6: 00000000ff000000 - 0000000100000000 = 2 RESERVED a b c d addr=0x00007000 len=89000
coreboot-4.0-1929-g79cfe7e-dirty Thu Jan 5 17:41:55 CET 2012 starting...
</snip>
Debug level of SeaBIOS is set to 10.
How can we guess which thing is causing the problem?
Thank you.
Best regards,
Elisenda
On 05/01/2012 0:55, Kevin O'Connor wrote:
Well, since you saw "d", but not "Jump to int19" it would indicate that it died in the memcpy (I assume your debug level was set to something higher than 3). That's really strange - I don't know why it would halt there. You could change the first dprintf to read something like:
dprintf(1, "d addr=%p len=%x\n", (void*)BUILD_STACK_ADDR, BUILD_EBDA_MINIMUM - BUILD_STACK_ADDR);
If the output makes sense (it should report 0x7000 and 0x89000) and it is really halting in the memset, then maybe coreboot is mapping something into the first 1 meg of ram - though that's just a wild guess.
-Kevin
On Thu, Jan 05, 2012 at 06:11:34PM +0100, Elisenda Cuadros wrote:
Hello,
I tried what you said and I can see the following:
<snip>
6: 00000000ff000000 - 0000000100000000 = 2 RESERVED a b c d addr=0x00007000 len=89000
coreboot-4.0-1929-g79cfe7e-dirty Thu Jan 5 17:41:55 CET 2012 starting...
</snip>
Debug level of SeaBIOS is set to 10.
Well, you could comment out the memset() command and see how far it gets. I suspect though that it will just crash somewhere else. I think you'll need to ask on the coreboot mailing list.
-Kevin
Hello,
I commented out:
memset((void*)BUILD_STACK_ADDR,0,BUILD_EBDA_MINIMUM -BUILD_STACK_ADDR);
Now I can see some debug messages after "Jump to int19", but coreboot is already restarting.
Is it worth testing with FILO? In any case I want to use this setup to boot FreeBSD and I think SeaBIOS is the only choice.
I will ask on the coreboot mailing list.
Thank you very much for your help.
Best regards,
Elisenda
On 06/01/2012 2:29, Kevin O'Connor wrote:
Well, you could comment out the memset() command and see how far it gets. I suspect though that it will just crash somewhere else. I think you'll need to ask on the coreboot mailing list.
-Kevin