[Q] Went over 512 bytes (16-bit real mode). What's next?

[Sophite]

Hello everyone!

I was working in assembly (nasm, 16-bit real mode), and now I'm over 512 bytes.

At least I think I am, here's the assembler error:

Code: Select all

boot.asm:38: panic: assertion output_ins.times >= 0 failed at asm/nasm.c:1342

I want to have a loader load the main kernel (Bootable program? What am I supposed to call this thing?), the main thing should then figure out filesystem stuff.

So... What should I do now?

I'm not really sure how to start with the loader.


Thanks

-Sophite

[Kevin]

Make your code smaller; or get enough code into the first 512 bytes that you can load the rest of the bootloader with it; or simply use an existing bootloader like GRUB because from your question I conclude that you're a beginner and shouldn't be writing a bootloader anyway. Writing a good bootloader is an advanced topic, and writing a bad bootloader is just a waste of time.

[Geri]

write a boot loader:

1. bios places to DL the default the disk id (for example 0x80)

2. https://en.wikipedia.org/wiki/INT_13H

3. you just simply read the sectors (in 512 byte sizes) into the needed memory location. your ,,payload'' can begin on the disk from 512 byte.

4. jmp to that code.

[Sophite]

Make your code smaller; or get enough code into the first 512 bytes that you can load the rest of the bootloader with it; or simply use an existing bootloader like GRUB because from your question I conclude that you're a beginner and shouldn't be writing a bootloader anyway. Writing a good bootloader is an advanced topic, and writing a bad bootloader is just a waste of time.

write a boot loader:

1. bios places to DL the default the disk id (for example 0x80)

2. https://en.wikipedia.org/wiki/INT_13H

3. you just simply read the sectors (in 512 byte sizes) into the needed memory location. your ,,payload'' can begin on the disk from 512 byte.

4. jmp to that code.

Thanks guys, I'll look into making it multiboot compliant.

Yes, I am quite new to this, thanks for the advice Kevin.

[Brendan]

Hi,

So... What should I do now?

For my boot loaders, all I do is put code in the first sector that loads more sectors of the boot loader.

More specifically, I have code in the first sector that loads the second sector, then the second sector contains better error reporting (a bunch of ASCII strings and a routine to convert BIOS error codes into human readable error messages) and loads the third sector, then code in the third sector contains much better disk IO routines (LBA, multi-sector reads, etc) and loads the remainder of the boot loader.

Note that for NASM and "flat binary" you can create your own sections, which can be useful for controlling where things end up. For example, this is what I'm using for one of my boot loaders:

Code: Select all

	SECTION .sector1 progbits start=0x0000 vstart=0x2000
	SECTION .sector2 progbits start=0x0200 vstart=0x2200
	SECTION .sector3 progbits start=0x0400 vstart=0x2400
	SECTION .publicKey progbits start=0x0600 vstart=0x2600
	SECTION .text progbits follows=.publicKey align=4 vfollows=.publicKey valign=4
	SECTION .data progbits follows=.text align=4 vfollows=.text valign=4
	SECTION .bss nobits follows=.data align=4

Note: my first sector also relocates itself from 0x00007C00 to 0x00002000, which is why I'm using "vstart=0x2000" and not "vstart=0x7C00".


Cheers,

Brendan

[dozniak]

If you want a multiboot-compliant loader in 512 bytes, take a look.

[glauxosdever]

Hi,

I'll look into making it multiboot compliant.

I don't think there is much point into writing a multiboot-compliant bootloader yourself, since you could just as well use GRUB in this case.

If you want to write your own bootloader, I suggest you use GRUB and multiboot for some time (but don't tie your kernel to it), until you figure out how you can improve on it so it fits your OS better. Then write your bootloader using your improved boot specification and finally make the needed changes in your kernel so it adheres to your boot specification.

Hope this helps.


Regards,
glauxosdever

[Brendan]

Hi,

If you want a multiboot-compliant loader in 512 bytes, take a look.

Nobody wants a multiboot-compliant loader that fits in 512 bytes, because the only way to make a multiboot-compliant loader fit in 512 bytes is to cripple it so badly that it becomes an unusable piece of trash.

• Acceptable code to enable A20 (and test it actually worked)? No.
• Acceptable code to obtain a memory map? No.
• Actually complies with multi-boot specs (including setting video mode)? No.
• No potentially false assumptions about the existence of random pieces of hardware that might not exist (PS/2 controller, floppy controller)? No.
• Sanity checks (for OS's multi-boot header checksum, if RAM actually exists at 0x00100000, if the kernel is larger than RAM, ...)? No.
• Nice descriptive error messages (so the user can figure out what went wrong, and what to do about it) for any/all problems? No.

Cheers,

Brendan

[dozniak]

Hi,

If you want a multiboot-compliant loader in 512 bytes, take a look.

Nobody wants a multiboot-compliant loader that fits in 512 bytes, because the only way to make a multiboot-compliant loader fit in 512 bytes is to cripple it so badly that it becomes an unusable piece of trash.

I know that, Mr.knowitall.

Instead, you should've suggested to split the loader into two parts like grub does (stage1 to load the stage2 that does more, like reading fs modules and doing actual read and boot).

the 512 byte mboot loader was an interesting challenge and is still fun to read, so there, enjoy your righteousness.

[Sophite]

If you want a multiboot-compliant loader in 512 bytes, take a look.

Not making a bootloader, making the OS multiboot-bootable.

[thepowersgang]

If you're writing a kernel to be loaded by multiboot, then the 512 byte limit doesn't apply (and you shouldn't be writing real-mode code). Multiboot loads your entire image and starts you in protected mode.

[dozniak]

I'm not really sure how to start with the loader.

Not making a bootloader, making the OS multiboot-bootable.

You may try learning to express yourself better.

There's OSDev Wiki article on how to make your kernel Multiboot-capable.

If you want to further support modular approach to support different filesystems and drivers in your multiboot kernel you have multiple ways:

* pass these components as multiboot modules, then load them in the kernel and use them to work with your filesystem
* invent your own image format and load that, then parse out the modules
* third option

[LtG]

I'm not really sure how to start with the loader.

Not making a bootloader, making the OS multiboot-bootable.

You may try learning to express yourself better.

Dozniak, you conveniently left out the following part in the thread (between those two quotes):

or simply use an existing bootloader like GRUB

Thanks guys, I'll look into making it multiboot compliant.

Yes, I am quite new to this, thanks for the advice Kevin.

The "it" in "making _it_ multiboot compliant" is referring to the kernel I thought, not the bootloader Sophite was initially making. So the thread started with making a loader, Kevin suggested using GRUB (or something) and that means making the kernel MB compliant so it can be loaded and making your own loader can be skipped.

Sure, Sophite could have been more explicit, but I don't think it's nearly as bad as the two quotes you used make it out to be..

[glauxosdever]

Hi,


To be fair, I also thought the bootloader would be multiboot-compliant.

A suggestion: don't quote whole posts, but only the parts of these posts that are relevant to what you are talking about. This is the reason it wasn't apparent (at least to me) you were referring to the kernel.

Hope this helps.


Regards,
glauxosdever