On 12/09/08 11:57 -0400, Jake Peavy wrote:
On 9/11/08, Joseph Smith joe@settoplinux.org wrote:
On Thu, 11 Sep 2008 23:53:04 +0200, Peter Stuge peter@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