Hi LinuxBIOS hackers,
I checked in a new target: emulation/qemu-i386
It allows to exchange the BIOS image of the multi target CPU emulator QEMU (http://fabrice.bellard.free.fr/qemu/) with a LinuxBIOS image.
Since failsafe handling does not make much sense in an emulator, I only have one image built, with more space being available for the payload. The payload is about 155k, the image is 256k and LinuxBIOS occupies 64k, so there's quite some room left.
Now, LinuxBIOS starts and executes all the romcc generated code in auto.c. But after that output suddenly stops. All of the resource allocation seems completely skipped. The first thing I get after this is when the payload has taken over. What can I do to get the output of the gcc compiled code again?
In the beginning it did show these messages, but I was unable to reproduce this behaviour, unfortunately.
I would guess it is not really skipped, since otherwise the payload is not executed. Attached see a log of the serial console and a log of port 80 activity.
Can anyone point me into how to debug this? I am a bit confused. Am I using crappy compilers again?
LinuxBIOS-1.1.6-OpenBIOS Mon Jun 28 16:54:53 CEST 2004 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. boot eax = 0xe1fb007 boot ebx = 0x3ff5878 boot arg = 0x3ff5878 Bootloader: elfboot Version: 1.3 Searching for LinuxBIOS tables... Found canidate at: 00000500 header checksum o.k. table checksum o.k. record count o.k. Found LinuxBIOS table at: 00000500 0x00000000000000 0x00000000000000 1748 0x000000000006d4 0x00000000000000 67107116
00000000000006d4-0000000004000000 RAM 64 MB Current location: 0x100000-0x1982e7 Relocating to 0x3f67d10-0x3fffff7... ok forth started. initializing memory...done Initializing PCI devices... 0:0.0 - 8086:1237 - /pci/pci8086,1237 - host 0:1.0 - 8086:7000 - /pci/pci8086,7000 - isa 0:1.1 - 8086:7010 - /pci/pci8086,7010 - ide 0:2.0 - 1234:1111 - /pci/pci1234,1111 - display 0:3.0 - 10ec:8029 - /pci/pci10ec,8029 - ethernet ide0: [io ports 0x1f0-0x1f7,0x3f6] drive0 [ATA disk]: QEMU HARDDISK ide1: [io ports 0x170-0x177,0x376] drive0 [ATAPI cdrom]: QEMU CD-ROM Welcome to OpenBIOS v1.0.RC1 Built on Jun 28 2004 17:29 Type 'help' for detailed information
[x86] Booting default not supported.
0 > ok 0 >
----------------------------------------------
Port80 log: outb: 0080 10 outb: 0080 05 outb: 0080 11 outb: 0080 12 outb: 0080 13 outb: 0080 fe outb: 0080 80 outb: 0080 39 outb: 0080 40 outb: 0080 5f outb: 0080 24 outb: 0080 25 outb: 0080 55 outb: 0080 66 outb: 0080 88 outb: 0080 89 outb: 0080 70 outb: 0080 60 outb: 0080 6a outb: 0080 92 outb: 0080 9b outb: 0080 75 outb: 0080 9a outb: 0080 96 outb: 0080 f8 outb: 0080 fe
Stefan Reinauer stepan@openbios.org writes:
Hi LinuxBIOS hackers,
I checked in a new target: emulation/qemu-i386
Now, LinuxBIOS starts and executes all the romcc generated code in auto.c. But after that output suddenly stops. All of the resource allocation seems completely skipped. The first thing I get after this is when the payload has taken over. What can I do to get the output of the gcc compiled code again?
Try commenting out console_init(); It looks like something bad is going on there. The post codes seem to be working so you can likely use those to narrow down what is going wrong.
In the beginning it did show these messages, but I was unable to reproduce this behaviour, unfortunately.
I would guess it is not really skipped, since otherwise the payload is not executed. Attached see a log of the serial console and a log of port 80 activity.
Can anyone point me into how to debug this? I am a bit confused. Am I using crappy compilers again?
Possibly it is an emulator bug. But seriously dig into console_init() using port 0x80 or just by commenting/uncommenting pieces until you know what breaks.
Eric
* Eric W. Biederman ebiederman@lnxi.com [040630 04:53]:
Try commenting out console_init(); It looks like something bad is going on there. The post codes seem to be working so you can likely use those to narrow down what is going wrong.
hm. commenting console_init() out does not change anything. But thanks for the direction. I'll look into this
Possibly it is an emulator bug. But seriously dig into console_init() using port 0x80 or just by commenting/uncommenting pieces until you know what breaks.
Stefan
Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [040630 04:53]:
Try commenting out console_init(); It looks like something bad is going on there. The post codes seem to be working so you can likely use those to narrow down what is going wrong.
hm. commenting console_init() out does not change anything. But thanks for the direction. I'll look into this
Ok then most likely you have managed to get the debugging printk's compiled out or something like that. It should be possible to insert a -g statement into the build and then to step through the code execution with gdb. qemu appears to have support for gdb stubs.
The real interesting part is what is the debug level set to. And you can get that with port 0x80.
Maybe we are attempting to use cmos options and that is not properly implemented?
Eric
* Eric W. Biederman ebiederman@lnxi.com [040630 19:10]:
Ok then most likely you have managed to get the debugging printk's compiled out or something like that. It should be possible to insert a -g statement into the build and then to step through the code execution with gdb. qemu appears to have support for gdb stubs.
The real interesting part is what is the debug level set to. And you can get that with port 0x80.
Maybe we are attempting to use cmos options and that is not properly implemented?
Actually that sounds very reasonable. all my builds where this happens are built without cmos support, and in this case the get_option() function always returns -2 iirc.
I will give it a try enabling option tables
Stefan
Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [040630 19:10]:
Ok then most likely you have managed to get the debugging printk's compiled out or something like that. It should be possible to insert a -g statement into the build and then to step through the code execution with gdb. qemu appears to have support for gdb stubs.
The real interesting part is what is the debug level set to. And you can get that with port 0x80.
Maybe we are attempting to use cmos options and that is not properly
implemented?
Actually that sounds very reasonable. all my builds where this happens are built without cmos support, and in this case the get_option() function always returns -2 iirc.
I will give it a try enabling option tables
Actually I was suggesting disabling option tables, to work around this issue.
Anyway good luck.
Eric
-
ebiederman＠lnxi.com -
Stefan Reinauer