<div><font color="#996633">Hi vladimir</font></div>
<div><font color="#996633">>I think this kind of behaviour could be configurable. In case you have<br>>described bootloader can protect its code. Actually, kernel does not<br>>know itself how much RAM is presented. Bootloader must provide kernel<br>
>with memory configuration through ATAGs (see mem boot option).<br>>Therefore, bootloader can reserve some RAM for itself and does not say<br>>kernel about it. As you have already get kernel use all memory which<br>
>is provided with bootloader and it is not always an entry RAM.</font></div>
<div> </div>
<div>In our bootloader, it seems they arent sending any ATAG_MEM as such,</div>
<div>but the are calling start_kernel() function, in which start_kernel is a 'type casted function pointer'</div>
<div>of the "kernel starting address".</div>
<div> </div>
<div>if ATAG_MEM is not sent..how wil the kernel treat the available memory.</div>
<div> </div>
<div>By the way ATAG_MEM has only start memory address.</div>
<div>How to specify that "this much memory need to be reserved" for bootloader?<br><br></div>
<div class="gmail_quote">On Mon, Jul 25, 2011 at 10:49 AM, Vladimir Murzin <span dir="ltr"><<a href="mailto:murzin.v@gmail.com">murzin.v@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi sandeep!<br>
<div class="im"><br>On 7/25/11, sandeep kumar <<a href="mailto:coolsandyforyou@gmail.com">coolsandyforyou@gmail.com</a>> wrote:<br>> Hi all,<br>> In Android target mobiles there is a facility called "Ramdump", where the<br>
> entire Ram image is copied to a file<br>> as the kernel goes to panic.<br>><br>> Ramdump is implemented like this<br>> 1) As the panic() function is called target will be reset.<br>> 2) Bootloader boots up in specific mode, where it enables the USB driver in<br>
> uploading mode.<br>> 3) Through USB entire RAM content is copied to a file in the host computer.<br>> 4) This file is parsed through different tools and we can get the logs info<br>> wat exactly happened just before kernel panic happend.<br>
><br>><br>> Now here is the interesting part,<br>> While the mobile's RAM image is being uploaded to host computer, our<br>> bootloader is still running in the mobile's RAM.<br>> How can it copy its own running region.<br>
><br>> This triggered me the following questions,<br>><br>> 1) When bootloader runs, will it run in a specific reserved region of RAM or<br>> it takes entire RAM?<br><br></div>AFAIK, it runs in specific region. For instance, for Das U-boot<br>
bootloader you can get this with<br>$file ./uImage<br>uImage: u-boot legacy uImage, Linux-2.6.35-g6d019da-dirty, Linux/ARM,<br>OS Kernel Image (Not compressed), 2733288 bytes, Thu Sep 2 01:11:09<br>2010, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC:<br>
0xEA95BF09, Data CRC: 0xF652AF6B<br>
<div class="im"><br>> 2) When it hands over the control to kernel, will it relinquish the entire<br>> RAM or certain part of RAM is reserved for it?<br>> 3) Does kernel use the entire RAM while running?<br><br></div>
I think this kind of behaviour could be configurable. In case you have<br>described bootloader can protect its code. Actually, kernel does not<br>know itself how much RAM is presented. Bootloader must provide kernel<br>with memory configuration through ATAGs (see mem boot option).<br>
Therefore, bootloader can reserve some RAM for itself and does not say<br>kernel about it. As you have already get kernel use all memory which<br>is provided with bootloader and it is not always an entry RAM.<br>
<div>
<div></div>
<div class="h5"><br>> 4) When the kernel is running, is ther any chance that, control again be<br>> taken back to bootloader?(coz i saw in bootloader code kernel is being<br>> called,<br>><br>> after that code also some code is there,some printks and error handling<br>
> stuff)<br>><br>> Pls help me out here..<br>><br>><br>><br>> --<br>> With regards,<br>> Sandeep Kumar Anantapalli,<br>><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>With regards,<br>
Sandeep Kumar Anantapalli,<br><br>