[coreboot] Convert Assembly JMP to C

[Corey Osgood]

On Fri, Sep 12, 2008 at 12:19 AM, Joseph Smith <joe at settoplinux.org> wrote:
>
>
>
> On Fri, 12 Sep 2008 00:13:18 -0400, "Corey Osgood" <corey.osgood at gmail.com>
> wrote:
>> On Thu, Sep 11, 2008 at 10:31 PM, Peter Stuge <peter at stuge.se> wrote:
>>> Joseph Smith wrote:
>>>> So for Linux do you mean reading /etc/fstab to find the /boot label
>>>> and going from there???
>>>
>>> No, that is a much later problem.
>>>
>>> We are at the stage when all we know are physical hard drives, and we
>>> want to look up where an operating system is, and how we start it.
>>>
>>> The how may be answered by multiboot.
>>>
>>> The where is your mission, should you choose to accept it.
>>>
>>> Where in this case means which physical drive, which partition and
>>> which file.
>>>
>>> Look at the different existing solutions for this problem to see if
>>> one of them will work for us, or if they can be improved upon to fit.
>>
>> Alright, this is an entirely honest question, how complex is the mbr?
>> And how standardized is it? What's required to access it? And the big
>> question, would it be possible to create a new mbr that could be
>> easily parsed by FILO, but still compatible with fuctory BIOS,
>> possibly by using a method similar to windows chainloading? Just
>> throwing this out there, no idea if/how it would actually work.
>>
> It is pretty darn simple, it tells a few bits about the drive and where to
> find the first boot sector of the Active partition. But it is a 16bit
> binary blob normally executed in real mode. We could create our own FILO
> MBR, but I don't know if that would be the right solution eithor....

Why not? If legacy free is the way we're gonna go, why not get rid of
the legacy MBR while we're at it?

-Corey