boot in C
Posted: Mon Dec 12, 2011 2:20 pm
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?
Page 1 of 1
Re: boot in C
Posted: Mon Dec 12, 2011 2:21 pm
That's because it is not possible. C can't do the necessary instructions.
Re: boot in C
Posted: Mon Dec 12, 2011 2:28 pm
d'ouch!Combuster wrote:That's because it is not possible. C can't do the necessary instructions.
and what about a very simple boot?
Re: boot in C
Posted: Mon Dec 12, 2011 2:40 pm
Hi,
No - you won't find it. Anything you do manage to find written in C will rely heavily on inline assembly.
Cheers,
Adam
No - you won't find it. Anything you do manage to find written in C will rely heavily on inline assembly.
Cheers,
Adam
Re: boot in C
Posted: Mon Dec 12, 2011 2:47 pm
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?!
Re: boot in C
Posted: Mon Dec 12, 2011 3:38 pm
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.
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.
Re: boot in C
Posted: Tue Dec 13, 2011 4:18 am
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.
Actually I was looking for a pink pony!start looking for a bootloader written in Python.
Re: boot in C
Posted: Tue Dec 13, 2011 11:29 am
Well, for me it isn't enough, because then is not as portable as I want.berkus wrote:GRUB is 98% in C, is that not enough?
Or start looking for a bootloader written in Python.
And why not, a bootloader in Python
.But you won't read that because I'm in your ignoring list
Re: boot in C
Posted: Tue Dec 13, 2011 11:40 am
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.
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.
Re: boot in C
Posted: Tue Dec 13, 2011 11:52 am
Where do you want to port it to?arming wrote:Well, for me it isn't enough, because then is not as portable as I want.
You are aware that booting processes differ wildly between architectures, so that a "portable" bootloader doesn't make much sense to begin with?
Re: boot in C
Posted: Tue Dec 13, 2011 12:25 pm
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.Nable wrote: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.
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.Re: boot in C
Posted: Tue Dec 13, 2011 2:24 pm
Hi,
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
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.arming wrote: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.
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
Re: boot in C
Posted: Tue Dec 13, 2011 2:32 pm
I've understood. Thanks!Brendan wrote:Hi,
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.arming wrote: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.
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