OSDev.org

Posted: **Fri Jun 15, 2018 4:31 am**

I am trying to create a VHD so I can put my kernel onto it and then load it in my boot sector but the problem is... where do I put my kernel if i am not using a vfd?

It seems that VMWare cannot boot the VHD made with Windows ("user cancelled operation" error). I have also tried VMWare s own vhds but you cant mount them when they are already empty.

Are there working and better way? I just need to create a vhd and boot from it. I dont mind if i have to switch from vmware

Posted: **Fri Jun 15, 2018 5:30 am**

Hi,

I've never used VMWare, but I'll describe a standard way that should work everywhere.

The BIOS starts by loading the Master Boot Record (MBR) to address 0x7C00. The MBR relocates itself, checks the partition table and loads the first sector of the active partition (Volume Boot Record, VBR) again to address 0x7C00. The partition may have a filesystem (in which case the VBR needs to parse the filesystem and load the file from there) or it may have N "reserved sectors" before the filesystem (something Brendan does), so you just place the file after the VBR. It's all described on the wiki and/or other forum topics.

Note that, usually, the file loaded by the VBR is not the kernel yet. It's the "real" bootloader that should at least do things from this list and should probably do way more:

Detect CPU and BIOS features;
Get the memory map;
Load the kernel and the modules (from either the filesystem or "reserved sectors") to a memory area that exists and is free according to the memory map;
Enable A20;
Enable PM/LM + paging;
Map the kernel to some virtual address (e.g. 1 MiB, higher-half, etc);
Jump to the kernel.

The things above don't probably fit in 440 bytes. Other ideas may include (but are not limited to and are not mandatory, in fact I'm considering not implementing the 2nd and the 5th):

Check if a display is indeed attached before printing any messages;
Setup a default video mode (VBE is a good way to get higher resolutions and higher bit depths if you don't have native video drivers);
Use descriptive warning/error messages if something fails (good for user experience);
Set up a Boot Abstraction Layer (BAL) that allows the kernel to use information gathered during boot time without caring if it's booted from BIOS or UEFI or something else;
Display a menu to allow booting different kernel versions and loading different modules (in case your newly compiled kernel doesn't work or you want to test a new module you didn't get around to add to the list of modules, adds a lot of complexity though). Don't do a menu for booting other OSes though, that's the role of a boot manager that the user can install separately in case they want to dual or triple boot.

Hope this helps!

Regards,
glauxosdever

Posted: **Fri Jun 15, 2018 5:52 am**

glauxosdever wrote:Hi,

I've never used VMWare, but I'll describe a standard way that should work everywhere.

The BIOS starts by loading the Master Boot Record (MBR) to address 0x7C00. The MBR relocates itself, checks the partition table and loads the first sector of the active partition (Volume Boot Record, VBR) again to address 0x7C00. The partition may have a filesystem (in which case the VBR needs to parse the filesystem and load the file from there) or it may have N "reserved sectors" before the filesystem (something Brendan does), so you just place the file after the VBR. It's all described on the wiki and/or other forum topics.

Note that, usually, the file loaded by the VBR is not the kernel yet. It's the "real" bootloader that should at least do things from this list and should probably do way more:

Detect CPU and BIOS features;

Get the memory map;

Load the kernel and the modules (from either the filesystem or "reserved sectors") to a memory area that exists and is free according to the memory map;

Enable A20;

Enable PM/LM + paging;

Map the kernel to some virtual address (e.g. 1 MiB, higher-half, etc);

Jump to the kernel.
The things above don't probably fit in 440 bytes. Other ideas may include (but are not limited to and are not mandatory, in fact I'm considering not implementing the 2nd and the 5th):

Check if a display is indeed attached before printing any messages;

Setup a default video mode (VBE is a good way to get higher resolutions and higher bit depths if you don't have native video drivers);

Use descriptive warning/error messages if something fails (good for user experience);

Set up a Boot Abstraction Layer (BAL) that allows the kernel to use information gathered during boot time without caring if it's booted from BIOS or UEFI or something else;

Display a menu to allow booting different kernel versions and loading different modules (in case your newly compiled kernel doesn't work or you want to test a new module you didn't get around to add to the list of modules, adds a lot of complexity though). Don't do a menu for booting other OSes though, that's the role of a boot manager that the user can install separately in case they want to dual or triple boot.
Hope this helps!

Regards,
glauxosdever

That is definitely helpful, thank you very much. There's things you mentioned which I hadn't yet considered and it'll help me a lot. My boot loader is quite simple currently. My boot loader is simple right now but it consists of the first 512 bytes sector, then the first sector will load my second-stage loader from disk (using BIOS interrupts for this as of right now - but the second-stage is linked into the same BIN file) and then I enter p-mode (verified that all is working). I've also setup VBE with BIOS interrupt and verified that using it after entering p-mode is working fine.

The thing is, I can't implement my kernel loader into the boot loader (so after entering p-mode and then doing anything else I want to do before moving to the kernel, i can jump to the kernel) until there's a way for the kernel to be on the OS environment. I need to somehow make a virtual hdd so I can put my boot loader at the first sector of that VHD and then place my kernel image onto the VHD so I can find it within my boot loader with FAT.

I am compiling an empty kernel (just a routine which returns 0) with GCC like so:

Code: Select all

i686-gcc.exe -g -m32 -c -ffreestanding -o kernel.o kernel.c -lgcc
i686-ld.exe -melf_i386 -Tlinker.ld -nostdlib --nmagic -o kernel.elf kernel.o
i686-elf-objcopy.exe -O binary kernel.elf kernel.bin

linker:

Code: Select all

OUTPUT_FORMAT(elf32-i386)
ENTRY(main)

SECTIONS
{
. = 0x9000;
.text : { *(.text) }
.data : { *(.data) }
.bss : { *(.bss) *(COMMON) }
}

I get back the kernel.bin but... I don't know what to do with it because I don't have a way to boot the OS and also have a place to put the kernel.bin so the boot loader will be able to find it..

OOI How do you boot your OS? Do you use a VFD or do you use a VHD/real HDD boot?

Posted: **Fri Jun 15, 2018 6:03 am**

I use GRUB.

Posted: **Fri Jun 15, 2018 6:56 am**

Hi,

My boot loader is simple right now but it consists of the first 512 bytes sector, then the first sector will load my second-stage loader from disk (using BIOS interrupts for this as of right now - but the second-stage is linked into the same BIN file) and then I enter p-mode (verified that all is working). I've also setup VBE with BIOS interrupt and verified that using it after entering p-mode is working fine.

If the second stage is linked into the same binary, then you probably want to do the way of N "reserved sectors" instead of bothering with filesystems yet. So it becomes like this:

Code: Select all

MBR => VBR => Stage2 from reserved sectors => Kernel from reserved sectors

instead of:

Code: Select all

MBR => VBR => Stage2 from filesystem => Kernel from filesystem

If you want to use a filesystem, you would probably need to do it the second way, as FAT leaves only 512 bytes for boot code, so stage2 cannot even fit there. But then again, in addition to what your stage1 already does, a basic read-only FAT driver is hard to fit in 512 bytes (not that it cannot be done though).

Note: The "reserved sectors" can be concatenated using:

Code: Select all

cat vbr.bin stage2.bin kernel.bin > reserved.bin

where "vbr.bin" is your VBR binary, "stage2.bin" is your stage2, "kernel.bin" is your kernel and "reserved.bin" is the file you can write to the start of the first partition of the virtual HDD.

OOI How do you boot your OS? Do you use a VFD or do you use a VHD/real HDD boot?

I returned to OS development about a week ago, after a break of about 2 years. I ditched my old code (I used GRUB there) and so far I managed to experiment with a MBR (which I ditched too because making partitioned disk images automatically is a hassle and because a pre-built partitioned disk image doesn't fit the geometry of the target HDD/USB drive, unless it's built specifically for it, practically it shouldn't matter though), with PXE (which I'm planning to continue later) and currently I'm writing a bootloader for CDs that are booted using El Torito in no-emulation mode. I suggest you don't try PXE yet, unless you want to mess a bit with a DHCP server setup (TFTP is trivial to setup a server for it though). As for CD images, you will have to burn a CD each time you want to test your OS on real HW (unless you make your CD images "hybrid", i.e. additionally put a MBR/GPT into the CD image, so the BIOS recognises the CD image as a HDD image that can be booted from USB -- the partitions of this masqueraded CD image still don't fit the geometry of the target USB drive, unless it's built specifically for it, practically it shouldn't matter though).

Regards,
glauxosdever

OSDev.org

how to manage the os files?

how to manage the os files?

Re: how to manage the os files?

Re: how to manage the os files?

Re: how to manage the os files?

Re: how to manage the os files?