OSDev.org

Whats the MBR job apart from holding partition table?

When i want to copy my os (and detect memory), do i do it inside MBR, or VBR?

Currently i use my MBP only to detect any 512byte large memory, copy some part of it there, and then transfer control to copied part.
Copied part read and validate partition table (only 1 active, no overlapping extended, gpt not supported. CHS ignored.), then validate active partitions VBR (0xAA55), and then copy 512bytes into 7c00. Last action of mbr is jmp to 7c00 and start executing VBR. VBR will detect memory sufficient to hold of, and use int13h to copy disk data into memory. gdt, idt and other stuff are handled at 2nd stage of botloading (after vbr is done and transfer control away).


Is it ok? Should i change something?

Yo,

You're getting your terms mixed up:

MBR is the absolute first sector on the physical storage medium, and VBR is the first sector on any particular partition. The first partition's VBR is also by extension the MBR.

The firmware (BIOS) "boots" your kernel by finding the first physical disk with a valid MBR, and your boot manager program in the MBR will then use the disk-id handle passed in the DL register to show you a list of other available valid kernel installations on other partitions on that disk whose MBR was chosen to be valid by the firmware. In the case of an unpartitioned disk, you would just configure your boot manager to load the single kernel on that disk.

So:

When i want to copy my os (and detect memory), do i do it inside MBR, or VBR?

Correct question should be: "Do I do it in the bootsector program's 512B (stage 1), or in a loaded stage2?". Answer is, convention says you would be best off doing it in stage 2, a larger component of the bootloader loaded by the 512B stage 1.

Currently i use my MBP only to detect any 512byte large memory, copy some part of it there, and then transfer control to copied part.

...?

Copied part read and validate partition table (only 1 active, no overlapping extended, gpt not supported. CHS ignored.), then validate active partitions VBR (0xAA55),

Should only be trying to load a valid stage 2 file within stage 1. Don't need to read GPT for that. The firmware detected bootable drive signature, 0x55AA is only relevant to the firmware, and you don't need to check for it.

The rest of your questions can be answered with further reading.

--All the best,
gravaera.

no u misunderstood me. its like:

- bios copy sector 1 from device to 7c00
- bios give control to 7c00
- i find free memory
- i copy sector 1 into free memory (device sector 1)
- i transfer control to copied memory (not to mem+0, but mem+X, mem+X is rest of code contained in MBR)
- this rest of code will check partition table, and copy VBR from active partition to 7c00 (thats why it was copied)
- MBR code (relocated) jump to 7c00 to execute vbr
- vbr will now load the bootloader program for partition, and this bootloader take care of loading OS.

Booting a computer has many steps. On a disk with many partitions, the MBR is the first step. It has only 2 jobs: hold the partition table, and boot the correct vbr on the partition that is marked "bootable" (there is only one marked that way). Relocating itself is always necessary for an MBR.

When a OS is booting from media that has no partitions, then no MBR ever runs. So you do not want to put any code in the MBR that stores important permanent information (except the memory address of the booted partition's table entry). Because if it never runs, then this information will never be stored.

The amount of code space in the MBR is extremely limited. But there are a small number of other features that you may want to add to an MBR. If none of the entries in the initial partition table are marked "bootable", then it may be important to scan and boot the EBRs (Extended Boot Records -- see the wiki, under Partition Table). It may also be fun to code in support for Dual Booting into the MBR. That is, allowing other disks to boot, beyond just "drive C". Loading more than just one sector of the VBR is also smart (16 or 32 sectors are good choices).

Yo,

When i want to copy my os (and detect memory), do i do it inside MBR, or VBR?

Currently i use my MBP only to detect any 512byte large memory, copy some part of it there

Copied part read and validate partition table (only 1 active, no overlapping extended, gpt not supported. CHS ignored.)

then validate active partitions VBR (0xAA55)

and then copy 512bytes into 7c00.

...Etc.

no u misunderstood me. its like:

No, I didn't. Nothing in your first post has anything to do with the sequence you described in your second. In fact the breakdown of your first post brings up an entirely different set of questions from your second.

- bios copy sector 1 from device to 7c00
- bios give control to 7c00
- i find free memory
- i copy sector 1 into free memory (device sector 1)
- i transfer control to copied memory (not to mem+0, but mem+X, mem+X is rest of code contained in MBR)
- this rest of code will check partition table, and copy VBR from active partition to 7c00 (thats why it was copied)
- MBR code (relocated) jump to 7c00 to execute vbr
- vbr will now load the bootloader program for partition, and this bootloader take care of loading OS.

Yes, it's sort of okay, and for the parts you got right, pretty standard. Just that for step 2, you don't need to detect or "find" free memory: you assume free memory between 0x500 and 0x7FFFF, and use that. It's part of the standard PC memory map.

Step 4, wrong, you're already executing code from the MBR, and the firmware loads the entire MBR properly: you can assume that, so there is no need to reload MBR code, like Berkus said. You should be focusing on loading a stage 2.

Step 5: Why would you care about the stage 1 code after you've jumped to stage 2?

Step 6: ...? Same as above.

Step 7: This is where you have got back on the right track.

--All the best
gravaera

Hi,

gravaera wrote:Step 4, wrong, you're already executing code from the MBR, and the firmware loads the entire MBR properly: you can assume that, so there is no need to reload MBR code, like Berkus said. You should be focusing on loading a stage 2.

The OS's boot sector (in the first sector of the active partition) needs to be loaded at 0x7C00. Obviously the MBR can't be at 0x7C00 when this happens, so the MBR needs to be moved somewhere else first. When a5498828 says "copy some part of it there" and "copy sector 1 into free memory", I'm hoping a5498828 means "rep movsw" (as loading the MBR again from disk would be less efficient).

For completeness, the full sequence might go something like:

• "rep movsw" the MBR to somewhere else and "jmp" to the copy
• setup any segment registers, and setup stack
• scan the partition table and find the first active entry
• determine if you need to use the extended disk functions to load the first sector of the active partition
• use the legacy disk functions (if possible) or the extended disk functions (if necessary) to load the first sector of the active partition
• make sure DS:SI points to the partition table entry for the active partition, and DL contains the BIOS drive number
• jmp to 0x0000:0x7C00

There's a large amount of optional stuff that could be added to this. Common examples includes:

• Loading more code from the spare sectors between the MBR and the beginning of the first partition (if 512 bytes isn't enough for everything); or possibly from a special "boot" partition reserved for your code
• Support for hybrid GPT disks
• Support for *BSD style "slices"
• Having a boot menu of some sort so the user can choose which OS/partition to boot
• Using tricks to make it look like more than one partition is active. Note: the most thorough example of this includes having your own partition table somewhere else (which can support more than 4 partitions and multiple active partitions) and (depending on which OS was selected from the menu) dynamically constructing a "fake" partition table by selecting up to 4 partitions from your own partition table and installing this dynamically constructed MBR/partition table on disk before booting the selected OS.
• Support for booting from other drives (e.g. boot an OS on the second hard drive, boot from one of the floppies, etc)
• Support for booting some types of kernels directly (e.g. directly booting a Linux kernel, Multi-boot, etc)
• Security features (e.g. ask for the right password before allowing OSs to be booted)
• Tools for managing partitions (like "fdisk"), potentially including code to resize existing partitions (complex/scary) and potentially including asking for the "admin" password first
• Tools for cloning partitions and disk drives (for backup purposes), potentially including compression, and potentially including asking for the "admin" password first
• Tools for examining the hardware, etc - things like a memory map viewer, showing CPU details, and maybe displaying SMBIOS information
• Tools to create a recovery disk (floppy, CD, etc) in case the MBR gets trashed
• An external Windows utility to restore/reinstall the MBR (so that people can fix their computer after installing a new version of Windows, which overwrites the MBR)
• Anything else you can think of that might be useful

Cheers,

Brendan

you assume free memory between 0x500 and 0x7FFFF, and use that. It's part of the standard PC memory map.

Are you sure? I know it would be way easier, but are you sure? Is it as standard as cmos under 70/71, text mode under b8000-bffff?
Its a half megabyte of memory (512kB), are you sure all computers have that ammount of memory (you wont find cpu supporting 8086 instructions with less that 512kB memory).

IVT takes 0-3ff, whats between ivt and 500?

Anyway int 15h reports me:


does it mean i can use ivt memory or what?

The BDA is there and the IVT is there. Normally you don't want to overwrite them as you might need them later.

yes i know i will need later touse it, i would prefer not to touch anything from real mode, but the problem is i dont know the map.

I can create a structure, put in it all 1's and 3's returned by ax=820, pick the first one that will be able to contain my earliest os configorator (pmode, paging). Then configurator will take care of paging, create a structure with free memory, and transfer control to actual os. In this structure i put every single 1's and 3's from ax=820, including those taken by configurator itself because i wont need it anymore.

However there is a question, what undocumented regions must i avoid?
Readng your wiki i can read that 500-7bff if guaranteed to be free... So why int 15/820 telling otherwise?
Can i skip right to high memory just losing everything bellow 1 MB? And even then, high memory seems to be extremly complicated.
I can of course make it wirk for me, i could even write os bilion times better than windows, but the question is when someone plugs in something wich will be mapped to some strange memory i used how this would work. I need to know 100% sure memory from where to allocate memory and where to copy initial configurator.

guaranteed usable memory is a subset of usable memory on your current machine, which is a subset of installed memory, which is a subset of potentially installed memory, which is a subset of the entire physical address space.

There are no undocumented regions - E820 gives you everything you are allowed to write to. It's just not a good idea to wipe the IVT or BDA when the processor is still using it.