Hello again,
Now that I've got my BIOS booting properly AFAICT, I am running into a problem when I jump to my Boot Loader. I get to the adjusted_boot_notes line, and then my Boot Loader is started, but it gets a memory map error that I don't understand and fails to load my menu.lst. This Boot Loader (FILO ver 0.5) works with an older version of CoreBoot (specifically a version from when it was called LinuxBIOS) but in my current build does not seem to work. You can see my full boot sequence at http://coreboot.pastebin.com/f4ebea109 -- the relevant lines start at line 1006:
FILO version 0.5 (me@mymachine.com) Wed Jul 15 13:14:58 EDT 2009 Can't get memory map from firmware. Using hardcoded default. Press <Enter> for default menu.lst (hda1:/filo/menu.lst), or <Esc> for prompt... 2 1 timed out menu: hda1:/filo/menu.lst Detected floating bus No drive detected on IDE channel 0
A proper boot should look like this:
FILO version 0.5 (me@mymachine.com) Sun Oct 19 14:32:35 EDT 2008 Press <Enter> for default menu.lst (hda1:/filo/menu.lst), or <Esc> for prompt... 2 1 timed out menu: hda1:/filo/menu.lst hda: LBA48 40GB: IC25N040ATMR04-0 hdb: ATAPI: MATSHITACD-RW CW-8124 Mounted ext2fs
Has anyone experienced this before? Any ideas how to get FILO to recognize the mounted hardware? I'm guessing it's something I missed in my CoreBoot modifications since it clearly works in the older version.
Thanks in advance,
Jeffrey.
Jeffrey C. Jacobs schrieb:
This Boot Loader (FILO ver 0.5) works with an older version of CoreBoot (specifically a version from when it was called LinuxBIOS) but in my current build does not seem to work. You can see my full boot sequence at http://coreboot.pastebin.com/f4ebea109 -- the relevant lines start at line 1006:
FILO version 0.5 (me@mymachine.com) Wed Jul 15 13:14:58 EDT 2009 Can't get memory map from firmware. Using hardcoded default.
Update your FILO. coreboot now has the capability to move parts of its tables to high memory, and your FILO won't know about that.
Regards, Patrick Georgi
Thanks for the advice, Patrick.
So, I also have the source for GRUB 2, revision 2202 (10 May 2009) that I've compiled with the CoreBoot option and further linked with a bunch of the GRUB modules to create a payload.elf package. This, I linked to my LinuxBIOS build and it booted fine. However, when I try it with CoreBoot, I can't seem to jump to the boot loader at all; it dies right after the line stating the setting for adjusted_boot_notes: http://coreboot.pastebin.com/f15277438
I would update my GRUB checkout but every time I try to, I get "svn: Server sent unexpected return value (502 Bad Gateway) in response to OPTIONS request for 'http://svn.savannah.gnu.org/svn/grub/trunk'" and even in verbose mode I can't figure that one out. But since we're talking GRUB 2 and a version within the last 3 months, I think it should be compatible with HIMEM. So why, when I try it with LinuxBIOS, GRUB is able to load, but when I do with CoreBoot, it fails to jump to the boot loader?
Thanks in advance,
Jeffrey.
Patrick Georgi wrote:
Jeffrey C. Jacobs schrieb:
This Boot Loader (FILO ver 0.5) works with an older version of CoreBoot (specifically a version from when it was called LinuxBIOS) but in my current build does not seem to work. You can see my full boot sequence at http://coreboot.pastebin.com/f4ebea109 -- the relevant lines start at line 1006:
FILO version 0.5 (me@mymachine.com) Wed Jul 15 13:14:58 EDT 2009 Can't get memory map from firmware. Using hardcoded default.
Update your FILO. coreboot now has the capability to move parts of its tables to high memory, and your FILO won't know about that.
Regards, Patrick Georgi
Jeffrey C. Jacobs schrieb:
I would update my GRUB checkout but every time I try to, I get "svn: Server sent unexpected return value (502 Bad Gateway) in response to OPTIONS request for 'http://svn.savannah.gnu.org/svn/grub/trunk'" and even in verbose mode I can't figure that one out. But since we're talking GRUB 2 and a version within the last 3 months, I think it should be compatible with HIMEM. So why, when I try it with LinuxBIOS, GRUB is able to load, but when I do with CoreBoot, it fails to jump to the boot loader?
Given that there is absolutely no output by GRUB, that might as well be another problem - but it might also be high tables support. I don't know if they support it, as I don't monitor their efforts. However, I don't think there are any developers left that work on both codebases, so that feature in coreboot might have happened without them noticing. As not all boards use high tables yet, they might have missed the need to implement support for it.
One option for now could be to disable HAVE_HIGH_TABLES in your coreboot build. Eventually, this config flag will disappear, with high tables activated in all of coreboot, so this would mostly be something to get past that road bump _for now_.
You could also try the current, maintained FILO tree. See http://www.coreboot.org/FILO for information on how to fetch it.
Regards, Patrick
Danke vielmals Patrick and many thanks to everyone else,
So, I decided to take your advice about switching (back to) FILO using the latest version (svn 103) and latest libpayload (svn 4505) but am still having problems recognizing my First Partition on the Primary Master IDE device, namely hda1. Specifically, using the FILO build settings specified here: http://coreboot.pastebin.com/f4e644a72
I got the boot sequence found at:
http://coreboot.pastebin.com/f5b707efb
Now, in that sequence, at the very end, where I've highlighted, I get the 'boot:' prompt instead of it loading what's in my menu.lst file (whose path is highlighted in the first link under the FILO configuration options). Also, note in the configuration that I am trying to build FILO in GRUB mode and have specified a prompt of "filo-as-grub", not "boot", which you see in my boot sequence. In fact, when I first tried to built the latest FILO, I found it would not build because the build/config.h file was generated improperly. The file was missing the CONFIG_PROMPT definition, which I also hardcoded to "filo-as-grub". None the less, when I boot, I still get "boot".
Anyway, since my menu.lst could not be loaded, I typed in the full boot command replete with kernel boot parameters, and as you can see I got a generic error stating that FILO could not find Device 0 (obviously meaning it could not find hda1). So, I'm not sure if this is a problem with FILO, but it seems much more likely I have some errant settings in Coreboot which is not allowing FILO to see my drives. Does anyone have any ideas?
Thanks in advance,
Jeffrey.
Patrick Georgi wrote:
Jeffrey C. Jacobs schrieb:
I would update my GRUB checkout but every time I try to, I get "svn: Server sent unexpected return value (502 Bad Gateway) in response to OPTIONS request for 'http://svn.savannah.gnu.org/svn/grub/trunk'" and even in verbose mode I can't figure that one out. But since we're talking GRUB 2 and a version within the last 3 months, I think it should be compatible with HIMEM. So why, when I try it with LinuxBIOS, GRUB is able to load, but when I do with CoreBoot, it fails to jump to the boot loader?
Given that there is absolutely no output by GRUB, that might as well be another problem - but it might also be high tables support. I don't know if they support it, as I don't monitor their efforts. However, I don't think there are any developers left that work on both codebases, so that feature in coreboot might have happened without them noticing. As not all boards use high tables yet, they might have missed the need to implement support for it.
One option for now could be to disable HAVE_HIGH_TABLES in your coreboot build. Eventually, this config flag will disappear, with high tables activated in all of coreboot, so this would mostly be something to get past that road bump _for now_.
You could also try the current, maintained FILO tree. See http://www.coreboot.org/FILO for information on how to fetch it.
Regards, Patrick
Jeffrey C. Jacobs schrieb:
Danke vielmals Patrick and many thanks to everyone else,
So, I decided to take your advice about switching (back to) FILO using the latest version (svn 103) and latest libpayload (svn 4505) but am still having problems recognizing my First Partition on the Primary Master IDE device, namely hda1. Specifically, using the FILO build settings specified here: http://coreboot.pastebin.com/f4e644a72
How did you change that configuration, simply by editing .config, or by going through the "make config" routine? Editing .config doesn't adapt the files in build/, so it should always be completed with a "make oldconfig" (and then look if it took your values or overwrote it with something else due to dependencies) To be extra careful, always run "make clean" after changing the configuration to force a full build.
Anyway, since my menu.lst could not be loaded, I typed in the full boot command replete with kernel boot parameters, and as you can see I got a generic error stating that FILO could not find Device 0 (obviously meaning it could not find hda1). So, I'm not sure if this is a problem with FILO, but it seems much more likely I have some errant settings in Coreboot which is not allowing FILO to see my drives. Does anyone have any ideas?
The device numbering might be weird at times. It's reasonably stable once you found the right device name, but it can differ from what you see elsewhere, so try hdb, hdc, and hdd, too.
Patrick
A simple question which I can not tell from your boot line. Is this disk partitioned?
ron
Hi,
Maybe it is a filesystem issue. I had some problems with ext3 volumes. Why don;t you try SeaBIOS payload instead and boot with classic grub?
It would show if it is this or another issue.
Rudolf
ron minnich wrote:
A simple question which I can not tell from your boot line. Is this disk partitioned?
Sorry that was confusing; yes, it is partitioned using standard MBR partition tables (fdisk) and the first partition on the disk is an ext3fs partition containing my kernel and initrd.
Jeffrey.
Patrick et al.,
Thanks again for the help and advice. Rudolf, I may try to look into your solution since I too am trying to boot off an ext3fs system but Patrick you have been a great help so far. I don't as a rule manually edit .config scripts, they're just convenient for reviewing settings. Actually, I used "make menuconfig", which is what is suggested in the FILO README, but that did not seem to generate build/config.h correctly so I tried the basic "make config" as you suggested and that seems to have generated the correct build.
So I loaded up my CoreBoot+FILO payload and booted and got the result listed in: http://coreboot.pastebin.com/f432f39bc
Now, with all those ANSI Escape Codes, I tried to clean up the last bit which has my FILO prompt and output: http://coreboot.pastebin.com/f7cb33b5
It's probably so busy because I have all the debugging output turned on. All that said, the bad news is that I still can't boot and it looks like it still doesn't recognize my hard drive. I've highlighted a few lines that I think may be relevant. Firstly, we have:
ERROR: No such CMOS option (boot_devices) menu: hda1:/boot/filo/menu.lst
I guess we can safely ignore the first line since we've not AFAICT entered the IDE probe yet and the second line just reiterates the menu.lst location.
There follows a series of probes of memory addresses which are mostly uneventful. The exception is a failure to access the bridge at 01:09.00:
Misconfigured bridge at 01:09.00 skipped.
It seems to reprint this each time it tries to scan that memory area. I'm not sure what this represents, but I guess it's okay to ignore for the time being.
Finally, we have a better description of my error:
found PCI IDE controller 8086:24cb prog_if=0x8a primary channel: compatibility mode skipping 0 native PCI controllers, new index=0 cmd_base=0x1f0 ctrl_base=0x3f4 init_controller: drive 0 Detected floating bus No drive detected on IDE channel 0 Failed to open IDE. dev=hda1, path=/boot/filo/menu.lst Drive 0 does not exist Failed to open IDE. Could not open menu.lst file 'hda1:/boot/filo/menu.lst'. Entering command line.
So I get this "No drive detected on IDE channel 0", which implies to me it's something lower-level that the file system.
So, does anyone have any better idea, given this new information, why this version of FILO can't detect my hard drive?
Thanks in Advance!
Jeffrey.
Patrick Georgi wrote:
Jeffrey C. Jacobs schrieb:
Danke vielmals Patrick and many thanks to everyone else,
So, I decided to take your advice about switching (back to) FILO using the latest version (svn 103) and latest libpayload (svn 4505) but am still having problems recognizing my First Partition on the Primary Master IDE device, namely hda1. Specifically, using the FILO build settings specified here: http://coreboot.pastebin.com/f4e644a72
How did you change that configuration, simply by editing .config, or by going through the "make config" routine? Editing .config doesn't adapt the files in build/, so it should always be completed with a "make oldconfig" (and then look if it took your values or overwrote it with something else due to dependencies) To be extra careful, always run "make clean" after changing the configuration to force a full build.
Anyway, since my menu.lst could not be loaded, I typed in the full boot command replete with kernel boot parameters, and as you can see I got a generic error stating that FILO could not find Device 0 (obviously meaning it could not find hda1). So, I'm not sure if this is a problem with FILO, but it seems much more likely I have some errant settings in Coreboot which is not allowing FILO to see my drives. Does anyone have any ideas?
The device numbering might be weird at times. It's reasonably stable once you found the right device name, but it can differ from what you see elsewhere, so try hdb, hdc, and hdd, too.
Patrick
On Thu, 06 Aug 2009 11:53:52 -0400, "Jeffrey C. Jacobs" jacobs@itd.nrl.navy.mil wrote:
There follows a series of probes of memory addresses which are mostly uneventful. The exception is a failure to access the bridge at 01:09.00:
Misconfigured bridge at 01:09.00 skipped.
It seems to reprint this each time it tries to scan that memory area. I'm not sure what this represents, but I guess it's okay to ignore for the time being.
This means that there is some bridge that claims is new client bus has the bus id 0. That leads to an endless loop (as any bridge is a child of bus 0 directly or indirectly)
Detected floating bus
This indicates that you're using the "old" IDE driver. You could also try CONFIG_IDE_NEW_DISK, which is another IDE driver that sometimes helps and sometimes doesn't. It's worth a try.
Regards, Patrick
Patrick Georgi wrote:
On Thu, 06 Aug 2009 11:53:52 -0400, "Jeffrey C. Jacobs" wrote:
Detected floating bus
This indicates that you're using the "old" IDE driver. You could also try CONFIG_IDE_NEW_DISK, which is another IDE driver that sometimes helps and sometimes doesn't. It's worth a try.
Hmm. Okay, so I updated to the latest coreboot v2 just in case and then since that option is for FILO I ran make config and activated the new disk driver and made clean and then all. None the less, I still get:
found PCI IDE controller 8086:24cb prog_if=0x8a primary channel: compatibility mode skipping 0 native PCI controllers, new index=0 Failed to open IDE. Could not open menu.lst file 'hda1:/boot/filo/menu.lst'. Entering command line.
Alas. Do you have any other ideas, Patrick? Or anyone else?
Thanks in advance,
Jeffrey.