boot in C

[arming]

I have looked for it, but I haven't found it. Do you know any example of a bootloader written in C? something like GRUB but written 100% in C?

[Combuster]

That's because it is not possible. C can't do the necessary instructions.

[arming]

That's because it is not possible. C can't do the necessary instructions.

d'ouch!

and what about a very simple boot?

[AJ]

Hi,

No - you won't find it. Anything you do manage to find written in C will rely heavily on inline assembly.

Cheers,
Adam

[Combuster]

Think about it, if you can boot something simple, then you can use that simple thing to load something less simple, and after some iterations you can boot grub....wait what did we say earlier?!

[neon]

Hello,

It can be written with very little to no inline assembly. Bootloaders that utilize the BIOS will require quite a bit of assembly language for startup and possibly I/O depending on design. Bootloaders that utilize EFI dont really need any. (Speaking from experience with ours.)

Really depends heavily on design I think. In all cases though you will need "some" assembly language. I must emphasize though that writing a bootloader in C takes a lot of patience and time: you should know assembly language.

[ACcurrent]

Generally the 1st stage is always asm because of the size constraints (Bios) though with UEFI it is possible to have 100% C. Speaking of that, the best bet for getting UEFI are apple macs. Qemu and virtualbox can be configured to run EFI though.

start looking for a bootloader written in Python.

Actually I was looking for a pink pony!

[arming]

GRUB is 98% in C, is that not enough?

Or start looking for a bootloader written in Python.

Well, for me it isn't enough, because then is not as portable as I want.

And why not, a bootloader in Python .

But you won't read that because I'm in your ignoring list

[Nable]

When you use HighLevelLanguages, it doesn't mean that you code is portable.
Even more, when you use Asm, it doen't mean that your code is not portable, as you can use different asm blobs for different architectures and compilation script will choose which to link with.
And.. fully portable bootloader - it's nonsence, really.
Is topic-starter a kind of a troll? I'm sorry but his ideas demoralise me.

[Solar]

Well, for me it isn't enough, because then is not as portable as I want.

Where do you want to port it to?

You are aware that booting processes differ wildly between architectures, so that a "portable" bootloader doesn't make much sense to begin with?

[arming]

When you use HighLevelLanguages, it doesn't mean that you code is portable.
Even more, when you use Asm, it doen't mean that your code is not portable, as you can use different asm blobs for different architectures and compilation script will choose which to link with.
And.. fully portable bootloader - it's nonsence, really.
Is topic-starter a kind of a troll? I'm sorry but his ideas demoralise me.

of course I don't want to do 100% portable bootloader, I know that that hasn't sense. But I want to have a boot as portable as it's possible.

And... when the people despise me because I'm a noob... that demoralise me to. I know that I say several stupid things ( ) but I say it to learn, not to be a troll.

[Brendan]

Hi,

of course I don't want to do 100% portable bootloader, I know that that hasn't sense. But I want to have a boot as portable as it's possible.

First step would be to determine everything the kernel could/would want to know, and create a specification that describes how the boot code should present all that information to the kernel.

Second step would be to realise that everything before your boot code hands control to the kernel depends on the firmware you're booting from, and in some cases also depends on which boot device.

In cases where it's possible (where the boot loader doesn't depend on the type of device you're booting from), write a boot loader for each type of firmware. These boot loaders won't be portable to other types of firmware, but might be portable to the same type of firmware on different architectures - e.g. a UEFI boot loader should/could be ported easily from 32-bit 80x86 to 64-bit 80x86 to Itanium.

In cases where it's not possible (where the boot loader has to depend on the type of device you're booting from), write a common module for each type of firmware. These common modules may be portable to the same type of firmware on different architectures (but probably won't be). Then, write a boot loader for each type of device that uses the appropriate common module. In this case the boot loaders should do as little work as possible (e.g. reading files) while the common module should do everything else.


Cheers,

Brendan

[arming]

Hi,

of course I don't want to do 100% portable bootloader, I know that that hasn't sense. But I want to have a boot as portable as it's possible.

First step would be to determine everything the kernel could/would want to know, and create a specification that describes how the boot code should present all that information to the kernel.

Second step would be to realise that everything before your boot code hands control to the kernel depends on the firmware you're booting from, and in some cases also depends on which boot device.

In cases where it's possible (where the boot loader doesn't depend on the type of device you're booting from), write a boot loader for each type of firmware. These boot loaders won't be portable to other types of firmware, but might be portable to the same type of firmware on different architectures - e.g. a UEFI boot loader should/could be ported easily from 32-bit 80x86 to 64-bit 80x86 to Itanium.

In cases where it's not possible (where the boot loader has to depend on the type of device you're booting from), write a common module for each type of firmware. These common modules may be portable to the same type of firmware on different architectures (but probably won't be). Then, write a boot loader for each type of device that uses the appropriate common module. In this case the boot loaders should do as little work as possible (e.g. reading files) while the common module should do everything else.


Cheers,

Brendan

I've understood. Thanks!