Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

About main() in bootloader



Sorry, I will pay attention to wrapping.

The bootloaders for embedded system may be a little different with bootloaders on PC.
The first stage really do some settings in an embedded system. As same as you said, however, it is usually tiny. 

And stage 2, I mean, pass arguments, not receive arguments from the first stage.

For trampoline, I mean that why a trampoline can make main() function like a normal fuction in usual C program, for instance, using arguments, return values.

And the example code is copy from the blob, and the method is also used by Redboot.  

>On Tue, Nov 30, 2004 at 09:17:24PM +0800, George Wong wrote:
>> 
>>  
>> I am studying bootloaders in embedded system.
>> Generally speaking, there are two stages in a bootloader.
>> The first stage, which is usually written in assembler, does some necessary settings.
>> The second stage, which is usually written in C, provides more complex functions,such as setting specific devices, loading kernel image.
>> My questions occurs on the moment that bootloader jumps from stage 1 to the entrance of C of stage 2. The most comman method is to consider the address of main() function as the entrance of executable of code of stage2. It, however, may cause two problems: the one is that we cannot pass arguments by main() fuction and the other is that we cannot deal with the situation which main function return value. But the problem can be fixed by a skillful method that is using a "trampoline" which is usually a piece of assembler. Following is an example:
>
>Please wrap your lines.
>
>If I understand your question properly, you have failed to
>notice an important distinction between the first and second
>stage of the bootloader: the first stage exists only to pull the
>second stage from storage into memory, and start it running.
>Since the first stage is truly tiny -- often less than 512 bytes
>-- it can't do *anything* else, including read configuration
>data or pass it along. So the second stage cannot expect to
>receive any arguments, and the first stage is irrelevant after
>execution, and it could not process any results anyway.
>
>The trampoline is to catch any errors in the only suitable
>fashion -- by restarting the second stage.
>
>Reading through the GRUB sourcecode should help.
>
>-dsr-
>
>









BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org