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:
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
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
Thanks in advance,
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
for information on how to fetch it.