OS Boot Tools

[Yoda]

Let me present to your attention the new tool for OS developers – OS Boot Tools.
This toolset is for those developers who don't want to use monstruous Linux loaders GRUB/SYSLINUX/LILO, but want to boot their kernel image file in a simple and fast manner from any device and media (floppy disks, HDD, flash-drives, CD/DVD...) with file systems FAT12/16/32, exFAT, NTFS, Ext2/3/4, Minix1/2/3, ISO9660, from disks partitioned both in traditional MBR scheme and in progressive GUID (GPT) scheme even beyond 2TiB limit. Dual boot supported. Also there is a Windows/Linux console utility in the package that allows to store proper boot code in any device or file with virtual device image. This toolset allows to start directly to develop your OS without poring over the file systems structure and falling into a stupor from the lack of space for debugging your bootloader. The package contains demo-kernel that shows correct initialization, saving and usage of passed parameters. You may use this demo-kernel as startup for your own project.
Advantages of this tool are:
– A simplicity of disk preparation, you won't accidentally loose files on your disk;
– An ultimate simplicity of usage – after you once prepared your disk for booting, just copy your OS kernel image file to the root directory of this disk and boot from it;
– Your image file may be sufficiently large – up to 620 kB;
– Your OS will easily know, what disk/partition it was booted from;
– Your OS may easily be shared with your friends for checking, debugging and demonstration – just pass them your kernel file and they will copy it to the disk prepared the same way for booting.
Toolset doesn't abolish existing bootloaders, such as GRUB or SYSLINUX. It supplements them! These loaders have poor first stage loading that makes installation and using them on new disks complicated and risky. The package contains modificated versions of loaders that don't require installation procedure, they easily may be booted with this toolset.
Specifications, usage instructions and much more you may read at the official project's page.

Welcome to download, use and have fun...
OS Boot Tools v3.3
...discuss here.

[Yoda]

The boot recording utility doesn't. The boot code works on x86 architecture. The MAC style partitions yet not supported and I'm not sure that it is really needed. But this project is alive and I have plans to develop it further.

[egos]

OS X supports MBR and GPT partitioning schemes as well so you can use PC BIOS booting for your kernel and EFI booting for OS X.

[Rudster816]

So basically it's just a set of boot sectors without source? Without source, I think a lot of people will avoid it all together because their projects are open source. It's also not very complete since it's basically just the first stage to a boot loader. A user would have to write file system code to get a working boot loader, which would nearly defeat the purpose of using your boot sector at all.

I don't mean to be a hater, but my honest opinion is that it really isn't useful. If you wrote second stages that could load an ELF file, that would change everything though. You'd still probably have to open source it though if you wanted to see people use it. It'd also be very helpful to release a Linux version, seems like it would be trivial to port it, since you really only needed to use the standard C library.

[Yoda]

So basically it's just a set of boot sectors without source?

That's a set of uniform boot sectors (i.e. behaving the same way independently of file system or device used and well documented) and a utility that simplifies the usage of these boot sectors. In some cases (modifying GPT) it may not be a simple task just to perform it by low-level disk editor utility.

Without source, I think a lot of people will avoid it all together because their projects are open source.

That's my choice not to open sources. People need functionality first. Often they think that they need sources but actually they don't. The only thing is that it is just unpleasant for them that they can't stare at the internals of the project, that's all.
On the other hand, I don't see any real obstacle for open source projects to use these boot codes. For example, Linux kernel does not have any loader at all and completely relies on other, standalone, boot loaders. It may be either free/open-source or proprietary loader.

It's also not very complete since it's basically just the first stage to a boot loader.

In many cases developers prefer to do all initialization things by themselves or to write a really simple kernel by FASM/NASM. And they hate digging the GRUB sources, recompilation, installation of that monster, learning it's config/commands and learning GNU toolchain and ELF format. All that they want is just to load their pure binary file into memory and execute it. This tool is for them. There is a lot of second stage bootloaders around but a lack of standardized and well documented first stage loaders suitable for a small and simple kernels. This project is to fill this gap.

A user would have to write file system code to get a working boot loader, which would nearly defeat the purpose of using your boot sector at all.

Sorry, I didn't get... do you mean that developer should write file system driver or should generate file system on a disk? Anyway, in both cases that are completely independent tasks. File system driver means full access to directories and files both for reading and for writing and doesn't need to fit in just a couple of sectors. File system generation (formatting) doesn't have to fill in any code at all. Many format utilities just fill in zeroes to the place of the boot code. The boot code is option not necessary for file system to function.

I don't mean to be a hater, but my honest opinion is that it really isn't useful. If you wrote second stages that could load an ELF file, that would change everything though.

But what if I don't use ELF format for my kernel and use just a plain binary? I hate GRUB, although my kernel supports Multiboot specs also and tested with GRUB2 as well.
This tool is a part of my own (yet incomplete) OS. I've seen that this part may be shared with others. Since I've made (IMHO) a good job and offer it to others for free, I don't see any reason for hatred.

You'd still probably have to open source it though if you wanted to see people use it.

That's up to them, to choose, what do they want - to use it or to stare at the internals. As for functionality, open source is not required. For example, I prefer to use closed source Windows rather than open source Linux.

It'd also be very helpful to release a Linux version, seems like it would be trivial to port it, since you really only needed to use the standard C library.

I think that the next step will be towards Linux users. I didn't announce first versions of loaders because it was very basic set of file systems, but the second version supports "gentleman set" of FS and devices. I suppose that the third version will be handy enough for Linux users.

[egos]

Yoda, first of all, I adhere to the same philosophy as you. Maybe except the point to have built-in FS and storage device drivers in kernel image (that your booting technology assumes). Also I do not pursue the aim of popularization of my stage 1 boot loaders. Though I once had an idea to publish their binaries and setup tools. As I said to you earlier I just had published the MBR boot loader that has a little bit of my OS-specific features but still useful for non-my OS users (even I have a WinGUI-oriented setup tool for it). I'm saying about this now because I have seen one slip in your words. You told about defence of Windows users but to make possible booting our kernels by your loaders we should refuse booting Windows from the same disk. But I had installed only your NTFS boot loader into data volume, then I had set up my MBR boot loader for booting from this partition instead of booting second OS, then I had put system files into kernel.sys and I had copied it into the volume (I have no NTFS driver, so I had put RAM disk image into FS driver instead). As to the stage 2 boot loader, nothing interferes to write it who needs it. But I prefer to use some existent stage 2 boot loader if it is needed (in original or to convert it into my kernel image format and to boot it by my stage 1 boot loaders) because my kernel supports Multiboot Spec. as well. It's a pity that your boot loaders have no support for identification of boot partition by the partition number. My boot loaders do it, so it's easy to make GRUB's stage 2 booted by them.

Code: Select all

CFGNAME equ "menu.lst"

format binary as "os"

org 8000h

xor bx,bx
cli
mov ss,bx
mov sp,2000h
sti
mov ds,bx
dec dh ; converts partition number from my format to GRUB/Multiboot Spec. one
mov [820Ah],dh
jmp 0:8200h
rb 81FCh-$
dw 0,0

file "stage2":$-$$,23
db "/",CFGNAME,0
db 8270h-$ dup 0
file "stage2":$-$$

rb 3FFh - ($+1) and 3FFh
dw 0AA55h

[Chandra]

Let me present to your attention the new tool for OS developers – OS Boot Tools.

Yet another. Anyway, how is it any better than GRUB?

[egos]

Yet another. Anyway, how is it any better than GRUB?

Yet another. Open your eyes: This toolset is for those developers who don't want to use monstruous Linux loaders GRUB/LILO... And I will reveal a great secret: GRUB is not so good as you think.

[gravaera]

Is there a reason why you people couldn't just say a nice "Ah, interesting project. Wish you well."

Was all of this nonsense necessary? If you don't like his licensing or distribution doctrine...don't use his code. If you think his project is pointless or aren't sure what the point is, ask once what the point is, let him explain, and then leave it alone once you're sure you understand his reason. Why all of this stupid, unwarranted hostility?

[Chandra]

Is there a reason why you people couldn't just say a nice "Ah, interesting project. Wish you well."

Ah, interesting project. Wish you well.

No offense! Took me a while to realize.

[Yoda]

You told about defence of Windows users but to make possible booting our kernels by your loaders we should refuse booting Windows from the same disk. But I had installed only your NTFS boot loader into data volume, then I had set up my MBR boot loader for booting from this partition instead of booting second OS, then I had put system files into kernel.sys and I had copied it into the volume (I have no NTFS driver, so I had put RAM disk image into FS driver instead).

So, what do you suggest? As for NTFS, no need to use it if it is not supported by your OS as an FS driver or virtualization mechanism.
As for alternative boot without reinstallation, I plan to add support for it in a future releases of MBR/GPT code.

It's a pity that your boot loaders have no support for identification of boot partition by the partition number. My boot loaders do it, so it's easy to make GRUB's stage 2 booted by them.

Do you think that GRUB2 may be loaded by my loader?? What is needed for that? Support of partition number? In what protocol?

how is it any better than GRUB?

It is not better or worse. It is different.
1. GRUB is second stage loader whilst my is first stage. And I said that I never heard about standardized and convenient tool for first stage.
2. GRUB is complicated in installation and usage whilst my is simple.
3. GRUB installation leads in a lot of executable and configuration junk in bootable drive even if you need to run a primitive BIOS-oriented kernel. My loader doesn't create/require any files/directory in bootable drive and doesn't take space at all.
4. GRUB passes control in protected mode. So if you prefer to communicate with BIOS first you need to take additional measures, - quit PM, organize virtual 86 or emulate real mode.

Please don't spoil the topic with bananas.

[egos]

So, what do you suggest? As for NTFS, no need to use it if it is not supported by your OS as an FS driver or virtualization mechanism.

I just wanted to say that it works! So everybody who has support for initrd-like mechanism (but has no NTFS driver) can boot own OS from NTFS partition now.

As for alternative boot without reinstallation, I plan to add support for it in a future releases of MBR/GPT code.

This will be good.

Do you think that GRUB2 may be loaded by my loader?? What is needed for that? Support of partition number? In what protocol?

Of course! Moreover, if your stage 1 boot loaders could pass boot partition number then the stage 2 could be installed by file copying without patching it during installation! I showed above the source for converting GRUB's stage 2 to my kernel image format. For GRUB 2 it's made similar: its stage 2 (core.img) keeps installation partition number in dword at disp 0x214 (look at GRUB sources for details). You can use the same converting technique for your format.

[Yoda]

Of course! Moreover, if your stage 1 boot loaders could pass boot partition number then the stage 2 could be installed by file copying without patching it during installation! I showed above the source for converting GRUB's stage 2 to my kernel image format. For GRUB 2 it's made similar: its stage 2 (core.img) keeps installation partition number in dword at disp 0x214 (look at GRUB sources for details). You can use the same converting technique for your format.

Thank you, egos! I'll try to dig that...

[Yoda]

Version 2.01 released.

In this version:

• GPT, VBRs:
  • Fixed a series of bugs with loading beyond 2TiB.
  VBRs:
  • Increased reservation of space for BIOS Data Area up to 12kiB.
• Fixed set of minor bugs.

The most important that I managed to boot any partition on GPT drives that are located beyond the magic limit 2TiB. In previous version the work with LBA48 was made blindly and, of course, there were problems booting on a real hardware. This version is completely debugged on 3TiB HDD with corresponding mainboard!

[Yoda]

Version 3.0 released.

In this version:

• Added Linux support (boot utility in ELF32 format);
• Added boot from hybrid systems MBR+FAT;
• Added boot from Ext2/3 file systems;
• Fixed set of minor bugs;
  FAT12/16:
  • Fixed error loading large files.
  boot.exe:
  • Totally reorganized internal structure;
  • Added possibility to change activity flags without recording boot code;
  • Added possibility to remove activity flags from all partitions;
  • Added possibility of separate recording of MBR and VBR boot code;
  • Provided reliable recording of boot code to the volumes, mounted by system;
  • In device listing added the detailed output of partition structure with flags and attributes;
  • Improved detection of file systems and partition structure.

Download and try.
http://goncharov.pp.ru/en/osboot.htm