OSDev.org

Yoda wrote:Since there are many things to do and there is a plenty of complicated file systems, devices and kernel formats, even second stage loader may become too big to fit in 1Mb. So it is not really plenty of room.

Wow, what would you put in a stage 2 loader to make it > 640kb (as that is the actual free space available under 1mb mark) ? My OS is 24kb. You could probably fit all kinds of hardware probing, mode switching, graphics initialization even a JPEG and a JPEG decoding lib (for splash screen) into 640kb without problems. "640kb ought to be enough for everybody"

My non-optimized stage 2 is 1169 bytes, and it does the following:
- A20
- get memory map
- detect CPU, halt if CPU not supported.
- according to the CPU detected, load 32 or 64bit kernel+initrd pair from FAT partition.
- if 32-bit, setup protected mode and jump to 32-bit kernel
- if 64-bit, setup identity mapped PML4T and long mode, and jump to 64-bit kernel

So, unless you put a movie trailer on the boot loader, it is very unlikely you run out of memory

To raise OS it is quite insufficient just to detect CPU, basic hardware and switch to proteced mode. It is necessary to load at once file system drivers, I/O drivers, basic display drivers, network drivers. Simple hobbuist OS of course may start in a couple of kilobytes. Old linux kernels were loaded at once. Then kernel compression was added to fit base memory. Now even compression doesn't help, only second stage loader.

Having a light-weight loader does not make it lame; on the other hand having a bloated loader does not make it look better.

Anyway, I would not blindly load kernel and full set drivers, and I expect many people prefer to just load and kick start the kernel, with the minimal supported drivers like disk access, and the kernel load the rest for its own needs/upon detection.
Furthermore, the kernel is not counted in the "conventional memory", as it will be movs into 1MiB mark.

So, it is really hard to write a boot loader that requires the whole "conventional memory" for it's runtime memory, you may utilize the available memory for disk/fs cache, but that's hardly software requirement to run the loader.

Yoda wrote:To raise OS it is quite insufficient just to detect CPU, basic hardware and switch to proteced mode. It is necessary to load at once file system drivers, I/O drivers, basic display drivers, network drivers. Simple hobbuist OS of course may start in a couple of kilobytes. Old linux kernels were loaded at once. Then kernel compression was added to fit base memory. Now even compression doesn't help, only second stage loader.

How did you start talking about the kernel size, this is about whether or not the second stage loader would fit in low memory - everything not related to the second stage loader can be loaded elsewhere. I never said that 640kb would be enough for the complete OS.

I never said that it's lame or something of that kind. Just warn that inefficiently architectured system on early stage may hurt project at later stages. That's all. I don't want to sink in sophisticated blah-blah about particular projects.
"640K ought to be enough for anybody" (c) Bill Gates.

Yoda wrote:To raise OS it is quite insufficient just to detect CPU, basic hardware and switch to proteced mode. It is necessary to load at once file system drivers, I/O drivers, basic display drivers, network drivers.

Most of this, I'll wager, can be done after the switch to protected mode, and thus doesn't need to be done in the first MB. The only things that absolutely *have* to be done in real mode are things that require BIOS calls. (In fact, looking at the GRUB 2 source code, it doesn't even do much of what I'd do before switching to protected mode: It actually switches *back* to real mode for most things requiring BIOS functions, such as getting a memory map).

Yoda wrote:"640K ought to be enough for anybody" (c) Bill Gates.

And for first stage boot code, it still is. Second stage boot code can use protected mode.

Well, IF you want to keep compatibility with chainloading (eg. continue normal booting if 2nd stage fails), you should put it below 7C00h. Simply because using memory above that offset could be overwritten by a sector load, and making efforts to avoid that creates unnecessary complications in loader code. It's much much simplier not using it.
So what I do is:
1. 1st stage loads at 7C00h, I relocate it to 600h
2. it loads 2nd stage in 800h-7C00h, and the first few sectors of boot partition or GPT at 7C00h
3. 2nd stage puts it's stack in 500h-800h
It means that the maximum size of 2nd stage can be 7400h (29696 bytes) including text, data and bss (but not stack). That's more than enough. I'm not able to use all of it, my loader is only 25600 bytes, and it really does everything before it jumps to the kernel (including setting up VBE LFB, displaying graphical logo, parsing GPT, detecting hardware (E820, ACPI tables, SMBios tables, MP tables etc.), mapping APIC and IOAPIC, setting up paging, long mode, local stack frame for kernel, creates ramdisk, locates kernel in it, saves running configuration to a file on ramdisk etc. etc. etc.). It even has a nice boot shell (also available through serial console) in that 26k.

@Solar: we've already went through that You're absolutely right, that's why I wrote 1st stage instead of MBR code. Also that's why my 1st stage can work without modification if placed in VBR, and that's why my 2nd stage can be loaded as a MultiBoot kernel as well. It's not bad we having your warning here too, repetitio est mater studiorum.

Also that's why my 1st stage can work without modification if placed in VBR

Actually, you're wrong for 99% of the cases. See the article why.

Combuster wrote:

Also that's why my 1st stage can work without modification if placed in VBR

Actually, you're wrong for 99% of the cases. See the article why.

Have you tried it? Please provide me the details of the bug if any.
It can be used as VBR, tested. I'm pretty sure you do not give it a try. And you wrote no "why" in the article, just troll without required knowledge.

* It should not be used as a VBR as it occupies the same space as the superblock of several filesystems

You have serious problems with reading. "This tutorial is useful for developers with more specific needs, like a custom filesystem or binary format. " Most filesystem has it's own boot code, so you won't have to write your own. I think it's part of required knowledge.

It can't be used on floppy drives.

Floppy drives does not have partitions, therefore it's no point in speaking of Volume Boot Record. What's more, any usbstick's FAT32 boot record cannot be used on floppies too, so what?

turdus wrote:

* It should not be used as a VBR as it occupies the same space as the superblock of several filesystems

You have serious problems with reading. "This tutorial is useful for developers with more specific needs, like a custom filesystem or binary format. " Most filesystem has it's own boot code, so you won't have to write your own. I think it's part of required knowledge.

I.e. you will have to modify so that it will actually cooperate with your filesystem of choice. Q.E.D.

My point was that it's only practical use is as an MBR, or as a template for other bootsectors. The rest is pretty much drifting between hyperboles and factually incorrect propaganda. Call it spam if you want.

turdus wrote:Well, IF you want to keep compatibility with chainloading (eg. continue normal booting if 2nd stage fails), you should put it below 7C00h.

I don't think so. Chain-loading mechanism does not require fail-over to next OS.
If I were about to choose my OS from boot manager, and it somehow failed to boot, I want it to halt (with message) but not show up a Windows or Linux on other partition.