OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Sep 19, 2019 11:00 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Why relocate MBR?
PostPosted: Wed Sep 04, 2019 10:02 pm 
Offline
Member
Member

Joined: Thu May 25, 2017 10:41 pm
Posts: 28
The wiki page about MBRs recommends that you relocate your MBR to "0x500 to 0x600". Is there a reason for this?

Sorry if this is kind of a noob question, I can't really think of a reason why.


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Wed Sep 04, 2019 10:51 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 975
thumble wrote:
The wiki page about MBRs recommends that you relocate your MBR to "0x500 to 0x600". Is there a reason for this?

Sorry if this is kind of a noob question, I can't really think of a reason why.


Because if it stays at 0x7c00, you lose ~30KB of contiguous RAM (and you only have ~630-something in real mode). But if you don't need that much at or after boot time, you may avoid the move. (Also remember that you need to have a functional stack somewhere, so the stack needs to be moved out of the way. AFAIR, when your bootsector receives control, the exact location of the stack isn't generally known, which is why it's moved.)


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Wed Sep 04, 2019 11:31 pm 
Offline
Member
Member

Joined: Thu May 25, 2017 10:41 pm
Posts: 28
That makes sense, thanks for the quick response.

My entire bootloader never uses more than 128 bytes of stack so I don't think memory will be a problem :D


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Thu Sep 05, 2019 12:47 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1636
The wiki page recommends relocating your MBR because you need to load the VBR to 0x7C00, and you can't do that when your MBR is already there. (Well, you could do it, but it probably wouldn't work very well.)


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Thu Sep 05, 2019 3:59 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 370
Hi

Octocontrabass is right. The MBR is loaded at 0x7C00 but it has to load the VBR at that address too. In order to do that, it must relocate itself first.

Now why 0x500? It makes sense to relocate the MBR at the beginning of the RAM. But, there's the real-mode IVT from 0 to 0x3FF, you can't overwrite that (or more precisely you can, but you really shouldn't). The memory right after that, from 0x400 to 0x4FF is used by the BIOS. For example, timer counter and the circular keyboard buffer are stored here. So the first really free address you can use is 0x500. Most MBR code put the stack before their code and they generally happy with 256 bytes, so the vast majority of MBR codes are relocating themselves to 0x600.

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 2:30 am 
Offline
Member
Member

Joined: Thu May 19, 2011 5:13 am
Posts: 222
An MBR doesn't have to load a VBR (and a VBR can fit comfortably inside an MBR).
But that's not OS development.

_________________
Mike Gonta
look and see - many look but few see

http://mikegonta.com


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 2:51 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1636
mikegonta wrote:
An MBR doesn't have to load a VBR

Some BIOSes will load the VBR and skip the MBR entirely. You'll have trouble if you're not prepared for this.


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 3:21 am 
Offline
Member
Member

Joined: Thu May 19, 2011 5:13 am
Posts: 222
Octocontrabass wrote:
mikegonta wrote:
An MBR doesn't have to load a VBR
Some BIOSes will load the VBR and skip the MBR entirely. You'll have trouble if you're not prepared for this.
I won't disagree that this is a possibility (although I have found no evidence to support this).
If there is no VBR, "then what" simply happens.
Or, simply embed the VBR in the MBR, with plenty of room left over for a simple loader (but that's not OS development).

_________________
Mike Gonta
look and see - many look but few see

http://mikegonta.com


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 3:53 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1636
mikegonta wrote:
If there is no VBR, "then what" simply happens.

Good question!

If you're lucky, the BIOS decides to load the MBR because it can't find a VBR.

If you're not lucky, the BIOS decides the disk isn't valid and won't boot.

If you're really not lucky, the BIOS finds something it thinks is a VBR and crashes.


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 4:40 am 
Offline
Member
Member

Joined: Thu May 19, 2011 5:13 am
Posts: 222
Octocontrabass wrote:
mikegonta wrote:
If there is no VBR, "then what" simply happens.
Good question!
If you're lucky, the BIOS decides to load the MBR because it can't find a VBR.
If you're not lucky, the BIOS decides the disk isn't valid and won't boot.
If you're really not lucky, the BIOS finds something it thinks is a VBR and crashes.
Actually, it's not a question (note the absence of a question mark) but you have provided a good explanation of "then what".
There is definitely a relationship between:
  • the BIOS checking and then running the first sector
  • the BIOS examining the boot sector (and possibly other sectors) to determine how best to "emulate" a USB device
The BIOS may "load" and examine the VBR, but surely it won't overwrite the MBR. After all the MBR may have other code it needs to run
(such as a boot loader application).
Removeable media doesn't require an MBR (although some people do refer to the VBR as an MBR). There have been postings
(here and/or elsewhere - maybe by you - no offence) alluding to "hard drive emulation" requiring an MBR (even though the original hard drives
had no MBR).
If the BIOS loads and examines - for the purpose of "emulation" - an MBR and there is no VBR then of course, "then what" will surely happen.

_________________
Mike Gonta
look and see - many look but few see

http://mikegonta.com


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 5:19 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 370
mikegonta wrote:
An MBR doesn't have to load a VBR
Yes it does, for backward compatibility. Part of the BIOS boot specification. (Of course an MBR can be written non standard compatible, but you shouldn't.) Even GRUB has an option for chainloading a VBR, because the boot spec demands it.
mikegonta wrote:
(and a VBR can fit comfortably inside an MBR).
This makes absolutely no sense, since MBR (master boot record) is on the first sector of the disk, while VBR (volume boot record) is on the first sector of the partition, both having the same size of 512 bytes. If you have partitioning table (likely) then VBR != MBR. If you don't then there's no MBR, only VBR. Either way you can't interpret "VBR fit inside MBR" that makes no sense.
Octocontrabass wrote:
Some BIOSes will load the VBR and skip the MBR entirely.
Show me one such a BIOS!

The BIOS does not parse the partitioning table, therefore it can't locate or load the VBR. BIOS only loads the first sector, regardless if it's an MBR or VBR.
Read the spec: http://www.intel-assembler.it/portale/5/BIOS-boot-specification/intel-phoenix-compaq-boot-specification.asp

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 5:35 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1636
bzt wrote:
Show me one such a BIOS!

I believe it was the BIOS for this motherboard. I hope to pull it out of storage soon so I can test it further.

bzt wrote:
Read the spec:

I have read the spec. This BIOS doesn't follow the spec correctly.


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 6:30 am 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 478
bzt wrote:
The BIOS does not parse the partitioning table, therefore it can't locate or load the VBR. BIOS only loads the first sector, regardless if it's an MBR or VBR.
Read the spec: http://www.intel-assembler.it/portale/5/BIOS-boot-specification/intel-phoenix-compaq-boot-specification.asp
Some BIOSes do. We've seen it on posts on this forum the last couple of years, and one of the remedies is to create a self referencing partition table in an MBR that points back to itself so that the MBR is also its own VBR (so it contains not only a partition table, but a BPB). The same phenomenon has also been observed in a StackOverflow question as well. Some BIOSes booting as USB HDD media are known to read the partition table for an entry marked active and then automatically load the VBR from that partition completely bypassing the code in the MBR. These BIOSes often consider media unbootable if there is no partition table with an active entry. I've written a Stackoverflow answer about this and we've had a discussion on the OS Dev Wiki and in that case it was a Toshiba Pro NB10-A that seems to exhibit this behaviour.

It is also amazing that to this day there are also people who refuse to believe (I'm not suggesting BZT, but I know some others) that some BIOSes blindly copy drive geometry into an boot sector that has been loaded into memory before control is transferred to it, yet there is an ever growing list of machines with BIOSes that do just that.

There is what a spec may say, and then there is what BIOS manufacturers are actually doing.


Last edited by MichaelPetch on Fri Sep 06, 2019 8:50 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 8:14 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 370
MichaelPetch wrote:
Some BIOSes do. We've seen it on posts on this forum the last couple of years, and one of the remedies is to create a self referencing partition table in an MBR that points back to itself so that the MBR is also its own VBR (so it contains not only a partition table, but a BPB). That's if you want it to appear more like unpartitioned media. The same phenomenon has also been observed in a StackOverflow question as well. Some BIOSes booting as USB HDD media are known to read the partition table for an entry marked active and then automatically load the VBR from that partition completely bypassing the code in the MBR. These BIOSes often consider media unbootable if there is no partition table with an active entry. I've written a Stackoverflow answer about this and we've had a discussion on the OS Dev Wiki and in that case it was a Toshiba Pro NB10-A that seems to exhibit this behaviour.

It is also amazing that to this day there are also people who refuse to believe (I'm not suggesting BZT, but I know some others) that some BIOSes blindly copy drive geometry into an boot sector that has been loaded into memory before control is transferred to it, yet there is an ever growing list of machines with BIOSes that do just that.

There is what a spec may say, and then there is what BIOS manufacturers are actually doing.
Hah, interesting. Thanks for the example.

Those BIOSes are definitely broken. It should be nothing more than reading the first sector, check the 55AA magic and transfer control to it. That's all. Doing anything more is really bad, because:

1) the partitioning table format is OS specific
There's a good reason why the code in the first sector parses the table and not the firmware. Other OSes may use different table formats, like BSD labels, Solaris slices or Minix partitions for example. That's why the Linux kernel has code for so many variants (and that's why "the standard" MBR partitioning table implemented in a file named msdos.c.)

2) the BPB is strictly part of the FAT, other filesystems usually don't have it
Which means those buggy BIOSes will overwrite valuable code or data in the boot sector, and therefore can only boot from FAT, although we all know that other file systems exists and should boot just fine (and they do with non-buggy BIOSes).

3) there's no way to tell MBR and VBR apart, as they both share the same magic
There's no guarantee that bootable flags are really bootable flags, could be just a mere coincidence. There's nothing to clearly identify an MS-DOS partitioning table. Other partition formats and VBR records could have 80 and 00 bytes accidentally at those offsets, which those buggy BIOSes would then interpret as a partitioning table incorrectly.

4) the first sector can either have a partitioning table or a BPB, and regardless the BIOS should be able to boot from it
Needless to say it should. And just for the records, the bochs BIOS, which does comply with the BBS standard, does. Note that "case IPL_TYPE_FLOPPY:" and "case IPL_TYPE_HARDDISK:" shares the same code path to boot the OS.

The question is, how common those broken BIOSes are. Frankly I've never met one in the last 30 years, and believe me, I've seen a few computers. Say if there's 1 in 10000 that's broken, does it really worth it for a hobby OS developer to make a workaround for that special case?

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Why relocate MBR?
PostPosted: Fri Sep 06, 2019 9:12 am 
Offline
Member
Member

Joined: Thu May 19, 2011 5:13 am
Posts: 222
MichaelPetch wrote:
bzt wrote:
The BIOS does not parse the partitioning table, therefore it can't locate or load the VBR. BIOS only loads the first sector, regardless if it's an MBR or VBR.
Read the spec: http://www.intel-assembler.it/portale/5/BIOS-boot-specification/intel-phoenix-compaq-boot-specification.asp
Some BIOSes do. We've seen it on posts on this forum the last couple of years, and one of the remedies is to create a self referencing partition table in an MBR that points back to itself so that the MBR is also its own VBR (so it contains not only a partition table, but a BPB). The same phenomenon has also been observed in a StackOverflow question as well. Some BIOSes booting as USB HDD media are known to read the partition table for an entry marked active and then automatically load the VBR from that partition completely bypassing the code in the MBR. These BIOSes often consider media unbootable if there is no partition table with an active entry. I've written a Stackoverflow answer about this and we've had a discussion on the OS Dev Wiki and in that case it was a Toshiba Pro NB10-A that seems to exhibit this behaviour.

It is also amazing that to this day there are also people who refuse to believe (I'm not suggesting BZT, but I know some others) that some BIOSes blindly copy drive geometry into an boot sector that has been loaded into memory before control is transferred to it, yet there is an ever growing list of machines with BIOSes that do just that.
Those SO beginner observations do not substantiate the claim that the BIOS overwrites the in memory BPB. For example:
Here was the problem with my code: I was writing the program to the first bytes of my flash drive. Those bytes were loaded into memory, but some BIOS interrupts were using those bytes for itself. So my program was being overwritten by the BIOS. To prevent this, you can add a BPB description as shown below. If your BIOS works the same way mine does, it will simply overwrite the BPB in memory, but not your program.
This merely suggests that the BIOS examines the boot sector for the purpose of (automatically) "emulating" the USB device.

_________________
Mike Gonta
look and see - many look but few see

http://mikegonta.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Majestic-12 [Bot], nullplan and 19 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group