[coreboot] Boot order? [Was: Convert Assembly JMP to C]

[Jordan Crouse]

On 12/09/08 11:57 -0400, Jake Peavy wrote:
> On 9/11/08, Joseph Smith <joe at settoplinux.org> wrote:
> >
> >
> >
> >
> > On Thu, 11 Sep 2008 23:53:04 +0200, Peter Stuge <peter at stuge.se> wrote:
> > > Joseph Smith wrote:
> > >> My JMP question is about copying a drives mbr to memory 0x7c00 and
> > >> or 0x0600 at 512 byte blocks.
> > > ..
> > >> What do you think?
> > >
> > > I think you should just use SeaBIOS.
> > >
> >
> > Nope. This will be a autoboot_mbr option of FILO. Here is how it will work:
> >
> > It will comb through each drive and attempt to boot the first drive with a
> > valid mbr signature bit (0xAA55). Maybe a slight delay for user
> > intervention, and then boot boot the drive based on the info in the mbr.
> >
> 
> So, let me just expose my ignorance here, does Coreboot provide an interface
> like a traditional, proprietary BIOS which allows the user to configure
> different settings?  Settings like boot order?  Because I guess I don't
> understand the purpose behind the whole discussion.
> 
> I would have expected Coreboot to work it's way down a prioritized list
> looking for boot media (MBR in x86).  Is it accurate to replace the words
> "boot media" above with "payload"?  Is MBR code (be it FILO, GRUB, whatever
> Windows' bootloader is called) a payload?

Forget the term MBR all together.  Back in the beginning of the x86
world with limited resources, it turned out to be a pretty clever idea
to put executable code in the first sector of the disk.  The BIOS could
just load that sector, jump to it, and then let the DOS bootloader take
over and do whatever it was it had to do.  Of course, the DOS bootloader
(like all of DOS) relied on the BIOS for driver services, so it
was liberally sprinkled with software interrupt calls.

Now, fast forward today, and despite the fact that we have more resources,
and are much smarter, most systems still rely on the legacy method.  Oh,
sure, we've dressed it up with menus, and graphics and such, but underneath,
the behavior is still identical - the BIOS loads the first sector and
executes it, and the first sector uses software interrupt calls to load
the filesystem, so that grub can locate its proper drivers.

Now obviously, Coreboot eschews legacy.  We don't need the MBR anymore,
because gosh darn it, we are smart enough to be able to read the disk
ourselves and load a kernel.  Unfortunately, that causes problems when
we try to play well with others.  Traditionally, the BIOS would find
and enumerate drives - 0x80 was the first drive, 0x81 was the second,
and so on.  When you re-organize the boot order in your BIOS setup 
screen, you are re-arranging those numbers.  GRUBs legacy behavior
was to get the list of drives when it booted, and then translate
0x80 -> (hd0), 0x81 -> (hd1) and so forth.  This could be confusing - 
even more so when you consider that USB keys and other media are
also enumerated as hard drives, so now you have to deal with
drives moving around and possibly not being there.  Completing the
confusion is that the Linux kernel uses a completely different boot
nomenclature (hda vs sda etc).

So what we need is a good standard for enumerating drives and finding
the media we want to load.  There are a number of possibilities -
GRUB2 prefers to scan each device for unique drive IDs - this is a
fine method when the bootloader is attached to the drive (as GRUB2
is in a traditional system), but less optimal when the bootloader is
attached to the ROM which may see hundreds of drives in its lifetime.
We can also scan every drive for a specific file, which prompted
the previous discussion about drive spin up times.  There might be
a dozen other alternatives that we haven't considered, which is why
we want to fire up the discussion in earnest.

Did this help?
Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.