OSDev.org

I am trying to boot Linux through my simple bootloader(I am always expermental and I will try something else before I finish one) , one problem I have is Linux is too big to load within 1MB and do I need to run my Bootloader in PMode and write drivers for Harddisks,etc and FileSystems and load the kernel.

Or is there any other way to execute data above 1MB.

How can I optimize my Bootloader so that it takes less place.(NASM)

If I am posting too rubbish questions ,tell me ,I will stop it.

boot loaders are complex pieces, that must be designed to work with the OS... in other words, linux will expect you to do the same things its own loader does... which almost certainly includes starting PMode

I'm not really familiar with linux boot process, but most boot-loaders are responsible for detecting at least some hardware (and passing that list to the OS in a way it expects) and entering PMode

my first guess, is that you are confusing boot-loaders with boot-sectors -- they are 2 very different things

the boot sector is first loaded by your firmware (either the BIOS, or the MBR), and is limited to 512 bytes (in BIOS boot mode), starts in RMode, and has a few other limitations -- the boot sector does not load the kernel though, instead it loads the boot-loader

most boot-loaders have at least 2 stages, but might have more (mine has 7 stages), the first stage is the boot sector, and depending on the media and filesystem you are booting from, will either load a 1.5 stage, which contains code to understand the filesystem (usually located at a particular location defined by the filesystem specification) or will parse the filesystem itself to find the 2nd stage

the 2nd stage is responsible for (at the minimum) detecting memory, loading the kernel, and entering PMode -- basically, if you have a 2 stage system like this, the 2nd stage must do everything that should be done in RMode

there are several ways to load a large amount of code above 1MB in your 2nd stage, the hardest is, of course, to code your own disk driver, and use that after entering PMode, the others require loading parts of it below 1MB, and either calling a BIOS call that exists on some (but not all) computers that can move it above 1MB, or enter PMode, move it above, and then return to RMode to load more

JAAman wrote:mine has 7 stages

What do you need 7 stages for?

LindusSystem wrote:one problem I have is Linux is too big to load within 1MB and do I need to run my Bootloader in PMode and write drivers for Harddisks,etc and FileSystems and load the kernel.

Yes, as far as my interpretation of this goes:
http://lxr.linux.no/#linux+v2.6.25/Docu ... 6/boot.txt

Sandras wrote:

JAAman wrote:mine has 7 stages

What do you need 7 stages for?

One for each day of a week?

bluemoon wrote:

Sandras wrote:

JAAman wrote:mine has 7 stages

What do you need 7 stages for?

One for each day of a week?

It takes a week to boot his OS.

Sandras wrote:

JAAman wrote:mine has 7 stages

What do you need 7 stages for?

Depends on what you call a "stage" - I have four bootstrap stages with my own bootloader, and if someone substitutes with grub that count becomes 5 for each separate binary being started.

Basically what I need to get the OS live as a whole is several steps: I need two stages in real mode to get everything from the bios (grub needs three), after which the third stage is started, which initializes the processor into protected mode and loads a payload into userland. Stage 4 runs in userland and starts all the core services - application loader, process manager, device manager, system bus enumerators and the initial user frontend. After stage 4 completed its list I consider bootstrap complete because any further loading is under the user's control instead of being a strict part of the OS' codebase. I can however imagine you extend the bootstrap numbering for example with sysvinit (5), X.org (6), KDM(7) in case of Linux - it all depends on your definitions.

bluemoon, MessiahAndrew, come on guys, now it seems, like I made fun of the 7 stages - I am actually curiuos, I can't think of any reasons for that many stages, but maybe JAAman has some. : )

LindusSystem wrote:Or is there any other way to execute data above 1MB.

Only in protected mode.

LindusSystem wrote:How can I optimize my Bootloader so that it takes less place.(NASM)

Even in hardest optimization it will only be available 620k of memory for the first stage (like in my set of first stage bootloaders).

i have thus far resisted the temptation to list them on several threads up to now, but i guess i will post a basic overview of my bootsystem

1) stage1 is, of course, the boot sector, restricted to 1 sector (usually 512 bytes), and responsible for directly accessing the physical disk (since it must know both the media used, and the filesystem) it either contains stage1.5, or loads it from a location designated by the filesystem (depending on specific combinations of media/filsystem), and provides a function (whose address is at a defined offset within the boot sector, accessible to later stages) for reading disk sectors by LBA

1.5) this "stage" is responsible for understanding the filesystem, and relocates and replaces the address of the "ReadLBA" function provided by stage1 with the address of its own "ReadFile" function which reads a file from disk by filename -- this stage relies on the function provided by stage1 to read the actual disk, thus making it completely media-independent, its initial responsibility is to load stage2 from disk

2) this stage is quite generic, and can be used on any x86-BIOS-PC (regardless of boot media or filesystem, thanks to stage1.5 storing the address of its ReadFile function), runs in RMode, and is primarily responsible for generic hardware detection -- there are a lot of things that must be (or should be) detected and initialized in RMode, and that is the responsibility of stage2 -- this would/could include CPU, RAM, video, etc. -- stage2 also may or may not load a boot file which could contain overrides for auto-detection, and may or may not load stage3 (under some cases, it may load stage4 and skip stage3)

3) this stage also runs in RMode, is primarily resposible for hardware detection, can make use of an override file (actually all stages after 2 can), but is not generic, several versions of stage3 may exist, the appropriate one loaded based on detection from stage2 -- this will be more system-specific, and include various things not common to all/most systems, but may be necessary for some -- this is also the stage which attempts to determine which physical device is booting (if possible), and which physical device(s) may contain JaaOS

4) this stage is primarily responsible for loading the appropriate boot-level PMode drivers (at a minimum, disk and video drivers), and switching into PMode, and initializing PMode (and possibly LMode) including paging, GDT, IDT, etc

5) this stage is responsible for PMode autodetection -- most modern device detection happens here, including advanced CPU detection, as well as device detection and initialization/driver loading

6) this is responsible for loading and initializing the kernel, and critical/initial processes

-and now, after 7 stages of boot-loader, the OS is fully running

this system is designed to be easily extended/altered, without having to make any changes to any other stages, by keeping various tasks, and system specific things separate, it also allows generic code to run unmodified on all systems, while replacing system-specific portions at installation or even at run-time -- but i will admit that this system is a little more complex than most people would prefer


while this makes sense to me, i don't know if it will to anyone else... i tend to have a very hard time putting things in words that other people can understand (when i think, everything seams clear until i try to explain it... the words that come out my mouth never mean what they did while they were still in my head, and it comes out as an unintelligible mess -- which is most likely because my whole head is an unintelligible mess, i just don't notice it till i try to talk to normal people)

Are all the stages in separate executables?

well, obviously not the first 2 stages -- they are not located in files at all (stage1 is, by definition, located in the boot sector, and stage1.5 shares the boot sector unless the filesystem specifically defines a special place for it -- which, of course, means not in a file)

but yes, each one is loaded separately (using stage1.5 "ReadFile" function before stage5, stage5 and later use the appropriate PMode driver loaded by stage4) by the preceding stage -- not only is there a separate file for each stage, but some of the stages may have many different versions each in its own file (one of which should be chosen by the boot system at runtime) plus there can be 1 or more override files which contain system-specific overrides both for auto-detection, and stage selection -- furthermore, some of the stages may have multiple modules located in different files on disk (for instance, stage 3, 4, and 5 load various device drivers, each driver (or set of drivers in some cases) is contained in its own file

for example, stage2 may detect presence of VGA-compatible color graphics, (and ERROR-HALT on failure unsupported graphics), and detect presence of VBE/VBE2/VBE3, but then load a stage3 capable of enumerating available video modes, monitor capabilities, ect using whatever mode was found (1 stage3 handles VBE, another VBE2, and another VBE3... note that this is a hypothetical, and not actual, example)

this isn't going to help with what LindusSystem wants, but it's interesting..

i'm not sure if this is still the case, but with some older linux kernels (i've tried it with 2.0 and 2.2) you could write the kernel binary file directly to a floppy disk raw. no file system. you could then actually boot the kernel by trying to boot the floppy normally.

miker00lz wrote:i'm not sure if this is still the case, but with some older linux kernels (i've tried it with 2.0 and 2.2) you could write the kernel binary file directly to a floppy disk raw. no file system. you could then actually boot the kernel by trying to boot the floppy normally.

Yeah, I heard of this, but they dropped it. My kernel boots similarly now.