2nd stage bootloader tutorial

[turdus]

Dear All,

I've updated my bootloader tutorial: http://wiki.osdev.org/2_stage_bootloader

The 2nd stage now can be booted:
- by my stage1 code in MBR (included in tutorial)
- by my stage1 code in VBR
- by GRUB with MultiBoot
- by BIOS as an expansion ROM

Either way, when IP reaches the label "protmode_start", you'll face a consistent, protected mode environment. Hope it will be useful.

Cheers.

[bluemoon]

It worth mentioning that the first partition started on the second cylinder (or at the number_of_headth sector), so there was always a gap after the master boot record.

I suspect that is just an optional performance optimization since hdiutil on mac creates partition right on the 2nd sector.

[turdus]

I suspect that is just an optional performance optimization since hdiutil on mac creates partition right on the 2nd sector.

Strange, since mac uses gpt, which starts on the 2nd sector, so it's not available for partitions. I know diskutil though, never used hdiutil. Anyway, if your partition starts right after the mbr, there'll no space for additional code. So it's still not recommended to put stage 2 on 2nd sector.
And yes, it was an optimization in the CHS era. Nowdays partitions usualy megabyte aligned (some EFI implementation checks this, and refuse to use EFI System Partition if it's not). So you can have

Code: Select all

sector 0 PMBR
sector 1 GPT header
sector 2 GPT partitions
         ...gap...
         stage 2 code
1M       EFI System Partition

without any problem.

[bluemoon]

So instead of assuming the first partition started on the second cylinder, the specification itself seems place no limitation and you should use values from the partition table.

[turdus]

assuming

No. Far from assuming. That's the empiric truth. You checked it with a modern, LBA aware partition creator. Use an old MSDOS fdisk. Or use linux's backward compatible fdisk, by default it will start first partition on number_of_headsth sector too.

Code: Select all

Command (m for help): u
Changing display/entry units to sectors

Command (m for help): p
...
   Device Boot      Start         End      Blocks   Id  System
/dev/hda1              63      498014      248976   83  Linux
/dev/hda2          498015     4401809     1951897+  82  Linux swap / Solaris
...

[bluemoon]

I would say the first partition start on the 37268 sectors is perfectly valid. (The previous "first partition" may got deleted)
While most tools create partitions at a number_of_headsth location, it's a tradition but does not means it is mandatory.
On the other hand, any sane boot code is smart enough to read the partition table instead of assuming it's on a fixed sector.

Anyway, it's your freedom of choice to accept my idea or not.

[Nable]

I'll just leave this here

Code: Select all

# fdisk -l /dev/sda

Disk /dev/sda: 80.1 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders, total 156368016 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00029862

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1       138790912   156366847     8787968   82  Linux swap / Solaris
/dev/sda2   *        2048   138788863    69393408   83  Linux

Partition table entries are not in disk order

And one more: > MSDOS compatible > 2012

[Solar]

Erm...

I just went through the tutorial, applying what writing skill I have to "polish" the prose a bit, when I stopped dead in my tracks.

GRUB not being compatible with chainloading as it executes the boot loader in protected mode?

Who gave you that idea?

GRUB is capable of more than one way of booting. One is Multiboot, in which you end up in protected mode with a nice data package handed to you.

Another is loading the Linux kernel directly.

Yet another is chainloading, which... well, you get the idea.

Oh, and last time I looked, GRUB predated the EFI / GPT specs by a comfortable margin...


<rant>

I always wonder why people, when they decide they don't want to be dropped into PM by GRUB, start to "roll their own" - but start at the MBR level instead of the VBR level. The VBR is where "you" - the OS - take over from the system chainloader. The system chainloader should be none of your concern; that particular itch has been scratched over and over and over again. There is just so much you could do different in chainloading a VBR...

</rant>

[turdus]

GRUB not being compatible with chainloading as it executes the boot loader in protected mode?[/b]

Who gave you that idea?

How on earth did you read that? What I wrote: "...standard called Multiboot. It was not compatible with classic chainloading..."

GRUB is capable of more than one way of booting.

No way! Tell me! I didn't know that! I was writing several ways of booting via GRUB in section "The goal" by mistake!

I always wonder why people, when they decide they don't want to be dropped into PM by GRUB, start to "roll their own" - but start at the MBR level instead of the VBR level.

I always wonder why people look but can't see. My 1st stage IS a VBR, that can be used as MBR too. My purpose with that bootloader was to create an unified code that can be used as both, no need to have 2 different. What's not clear about this?

The VBR is where "you" - the OS - take over from the system chainloader. The system chainloader should be none of your concern;

Wrong.
1st: you may have partitionless layout
2nd: my 1st stage code is NOT an OS loader (it does not load any kernel or such); it's a 100% chainloader by design.

I know you as a man who's able to read, so please stop trolling, and teaching me things that are covered in my article (therefore obviously I'm aware of).

[Solar]

How on earth did you read that?

Because your history section is quite confusingly not written in the historic sequence of events, and stays silent on some crucial facts.

The way it is written now, the impression is:

• first there were no partitions;
• then there were partitions;
• then came GPT;
• because it all was very confusing, there came GRUB and invented Multiboot, which however is incompatible with chainloading;
• so instead follow this tutorial, which brings to you the concept of 2-stage bootloading.

I think we both know that this is not a good (or correct) way to present things. Multiboot predates GPT, and GRUB is capable of chainloading as well - I know that, you know that, the article implies it at some places, but doesn't really say so.

I see you're already getting defensive about this; I'm sorry about that, I didn't want to offend. It's just that I feel the article in its current form is quite confusing the matter, I want to improve it, and didn't want to get into an edit war, thus I addressed it here. I might have slipped in tone a bit, as I blamed on ignorance what now appears to be just a deficit in presentation.

I'll come back on this later.

[turdus]

I see you're already getting defensive about this; I'm sorry about that, I didn't want to offend. It's just that I feel the article in its current form is quite confusing the matter, I want to improve it, and didn't want to get into an edit war, thus I addressed it here. I might have slipped in tone a bit, as I blamed on ignorance what now appears to be just a deficit in presentation.

I'll come back on this later.

Yep, and I haven't got a good night rest for a while, and overreacted a bit. Sorry.
But I understood your confusion, so I've reordered some sections and I've modified some sentences. I hope it became better, and it's not confusing now.
And thank you for your language corrections. English is not my first language so I appreciate that.

[Solar]

And thank you for your language corrections. English is not my first language so I appreciate that.

Mine neither, so I take that as a compliment.

[Love4Boobies]

[Solar]

I love you too.