OSDev.org

Posted: **Tue Apr 21, 2015 12:02 am**

I think this needs to be discussed thoroughly. Octocontrabass has written many times that the BIOS may skip the MBR.

Octocontrabass wrote:I've seen at least one BIOS that also examines the contents of the bootable partition's VBR during boot, and if the VBR looks like a FAT filesystem, it will skip the MBR and directly load the VBR.

Some questions:

What is the name and version of the BIOS?
Does it implement the MBR to VBR interface, i.e. DS:SI pointing to the partition entry?
Does it reliably run the MBR code if there are no bootable partitions?
Does it reliably run the MBR code if there is a bootable partition but it does not contain a FAT filesystem?

For boot managers and GUID-partition-aware MBRs, this has to be taken into account. Boot loaders should not care.

Posted: **Tue Apr 21, 2015 1:46 am**

I figured I'd have to go back and re-test this some day. I guess I know what I'll be working on this weekend.

Anyway, I'll see how many of your questions I remember the answers to.

Antti wrote:

What is the name and version of the BIOS?

Does it implement the MBR to VBR interface, i.e. DS:SI pointing to the partition entry?

Does it reliably run the MBR code if there are no bootable partitions?

Does it reliably run the MBR code if there is a bootable partition but it does not contain a FAT filesystem?

The BIOS is for this motherboard, but I don't know what version I'm running.
I didn't check DS:SI. A regular bootloader won't need it anyway; the FAT BPB contains enough information.
I don't remember. I found at least one BIOS that will not run the MBR code if there is no bootable partition, but it might not be this one.
Yes.

If you have anything you'd like me to boot and run as a test, let me know. Otherwise, I'll hack up my own MBR/VBR code.

Posted: **Tue Apr 21, 2015 4:19 am**

Thank you for your answer but no need to make extensive tests. Was it a surprise when you figured this out, like your MBR code always worked very well on that computer but not on other computers? Anyway, I am almost sure that for many bootable USB images (using MBR/VBR) this is an unpleasant surprise.

Posted: **Tue Apr 21, 2015 5:57 am**

Antti wrote:Was it a surprise when you figured this out, like your MBR code always worked very well on that computer but not on other computers?

I wrote a MBR that displayed a message and halted. I was very surprised to see the error message from the VBR displayed on the screen!

Antti wrote:Anyway, I am almost sure that for many bootable USB images (using MBR/VBR) this is an unpleasant surprise.

How many of those are using FAT? It behaves normally when the bootable partition is not FAT, so it shouldn't be an issue unless you have DOS-incompatible MBR code and store your OS on a FAT filesystem.

Posted: **Thu Apr 23, 2015 11:29 pm**

Perhaps there should be a public domain MBR. Would it be possible? Requirements are quite clear but perhaps there is still too much controversy. "Skip the MBR" could mean that "do not write an MBR code section because it must not contain anything special".

Posted: **Fri Apr 24, 2015 5:07 am**

Antti wrote:Perhaps there should be a public domain MBR. Would it be possible?

A MBR that meets the minimum required functionality is trivial to write, even if you're working to maintain backwards-compatibility with the 5160.

Antti wrote:Requirements are quite clear but perhaps there is still too much controversy.

What controversy?

Antti wrote:"Skip the MBR" could mean that "do not write an MBR code section because it must not contain anything special".

Or perhaps "do not write a special MBR because some day someone will want to dual-boot with GRUB, and that means your VBR must be something GRUB can chainload."

If you're really that worried about it, perhaps you should write some test cases that I can run.

Posted: **Fri Apr 24, 2015 5:58 am**

Octocontrabass wrote:What controversy?

This could be a classic quote in the future. There are always some corner cases, code quality issues, et cetera. I may be wrong and I would be happy if I were. In general, I would reserve the words "trivial to write".

Octocontrabass wrote:If you're really that worried about it

I am not very worried about this. This is just an issue among other issues.

Posted: **Fri Apr 24, 2015 6:41 am**

Hi,

Octocontrabass wrote:
Antti wrote:Perhaps there should be a public domain MBR. Would it be possible?
A MBR that meets the minimum required functionality is trivial to write, even if you're working to maintain backwards-compatibility with the 5160.
Antti wrote:Requirements are quite clear but perhaps there is still too much controversy.
What controversy?

While "minimum required functionality" is trivial and relatively well defined; "maximum desired functionality" is a hornet's nest (especially once you realise the MBR is just the first sector of a boot manager like GRUB, GAG, OSL2000, XOSL, Smart BootManager, etc).

Cheers,

Brendan

Posted: **Fri Apr 24, 2015 9:45 am**

All right. I started the public domain MBR that will boot the active partition. This is a quick start so before writing any more code, we all (hopefully) need to stop and design it. Feel free to comment and contribute.

Code: Select all

ORG 0x0600

; At "0x07C00" (position independent)

        xor cx,cx                       ; cx = 0
        mov si,0x7C00                   ; si = source
        mov di,0x0600                   ; di = destination
        cli                             ; disable interrupts
        mov ss,cx                       ; ss = 0
        mov sp,si                       ; sp = 0x7C00
        sti                             ; enable interrupts
        mov es,cx                       ; es = 0
        mov ds,cx                       ; ds = 0
        mov ch,0x01                     ; cx = 0x0100
        cld                             ; clear direction flag
        rep movsw                       ; relocate 0x07C00 -> 0x00600 (512)
        mov bx,0x55AA                   ; bx = 0x55AA (for INT 13h check)
        push dx                         ; save register dx (dl=boot drive)
        jmp 0x0000:0x0620               ; far jump to the relocated code


; At 0x0000:0x0620

        mov ah,0x41                     ; INT 13h installation check
        stc                             ; preset carry flag
        int 0x13                        ; bios disk service call
        pop dx                          ; restore register dx (dl=boot drive)
        jc NoInt13hExtensions           ; if cf = 1, no INT 13h extensions
        cmp bx,0xAA55                   ; compare return value
        jne NoInt13hExtensions          ; if not equal, no INT 13h extensions
        shr cx,1                        ; check bit 0, function support

        ; Note: cx was set to zero before INT 13h call. If bit 0 was set,
        ; this gives very good confidence that INT 13h extensions are
        ; available. This also gives good confidence that the CPU is >= 80386.

        jnc NoInt13hExtensions          ; if bit 0 = 0, no INT 13h extensions


; NOT IMPLEMENTED AREA

Int13hExtensions:

NoInt13hExtensions:

Posted: **Fri Apr 24, 2015 11:25 am**

I am curious as to why you would want to write another MBR. The following page has tons of them:

http://thestarman.narod.ru/asm/mbr/

Posted: **Fri Apr 24, 2015 12:56 pm**

And they are not public domain - they are all Microsoft ones which are proprietary, and illegal to distribute with your OS without permission.

Posted: **Fri Apr 24, 2015 3:30 pm**

Certainly the Grub MBR ("stage 1") isn't by Microsoft...

http://thestarman.pcministry.com/asm/mbr/GRUB.htm

Posted: **Fri Apr 24, 2015 8:08 pm**

Hi,

kiznit wrote:Certainly the Grub MBR ("stage 1") isn't by Microsoft...

http://thestarman.pcministry.com/asm/mbr/GRUB.htm

GRUB's MBR ignores the partition table and loads GRUB's stage 2; it doesn't check the partition table and load the first sector of an active partition (which I assume is the goal here).

Cheers,

Brendan

Posted: **Fri Apr 24, 2015 9:12 pm**

Hi,

Antti wrote:All right. I started the public domain MBR that will boot the active partition. This is a quick start so before writing any more code, we all (hopefully) need to stop and design it. Feel free to comment and contribute.

Looks fine so far; except you can do this:

Code: Select all

    
        jmp 0x0000:.here               ; far jump to the relocated code
.here:
        mov ah,0x41                     ; INT 13h installation check

However, in my experience with only 512 bytes it's impossible to have acceptable error handling (e.g. with a good descriptive error string for each possible problem) and there are other "not required but desired" things I'd want to include (see list below). Fortunately you've got the entire first track to play with; which means the first sector only needs to load the next sector and handle any errors that may have occurred while loading that next sector (which can be done without "int 0x13 extensions", saving more space for error handling).

For a list of "not required but potentially desired" features:

Make PC speaker beep if there's any kind of error (headless systems)
Redundancy - have 2 copies of everything it loads from disk, so that if there's a read error it can use an alternative copy to avoid boot failure (possibly including taking a copy of the first sector of the active partition/s and storing them somewhere else)
Diddling with TPM to maintain the "chain of trust"
Support for GPT. This makes it easier for people to have (e.g.) a USB flash stick with both BIOS boot loader and UEFI boot loader. Notes: for GPT the "partition attributes" has a "legacy BIOS bootable" flag for this purpose, and for redundancy there's 2 copies of the GPT partition table.

The ability to have multiple operating systems installed (where the MBR/boot manager allows the user to choose which to boot) is also relatively important (especially for hobbyist OS developers - e.g. end users installing the hobby OS alongside something like Windows, rather than end users replacing Windows with the hobby OS). Of course this is the beginning of a "slippery slope" - it would mean having some sort of boot menu/user interface; and then leads to other features, like partition hiding, auto-detecting installed OSs, a boot-time configuration utility, potential support for other boot protocols (e.g. chain-loading, multi-boot, Linux boot protocol, etc), various built-in utilities (e.g. for partitioning disks, copying/cloning/backing up partitions, testing hard disks for faulty sectors, testing RAM), etc.

Cheers,

Brendan

Posted: **Fri Apr 24, 2015 9:54 pm**

That missing label will be fixed but the point was to underline this nice 32-byte aligned code section before jumping to the relocated code. It is pointless, I know, but if that code section would be used at the beginning of millions of storage drives, why not made it like a "signature boilerplate".

Brendan, you are right but I doubt I/we are able to finish this if we extend the scope too much. I think it could be realistic to make this 512-byte fully polished and bug-free. Using the first track is possible but I would like to reserve it for GUID partition tables. The primary GPT header is at LBA 1, so it is the next sector.

What I am thinking at the moment:

Check for GPT-partition scheme. If available, the main target is to read the first sector of some kind of "BIOS Boot Partition" at 0x0000:0x7C00 and jump into it.
Check for MBR-partition scheme, If valid, the main target is to read the first sector of an active partition (bootable) at 0x0000:0x7C00 and jump into it. Also, implement the "MBR-VBR interface".

Nothing else. It is not a boot manager. Would be better if it were, but that project would fail.

OSDev.org

Skip the MBR

Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR

Re: Skip the MBR