Interesting case while taking Ramdump of Linux kernel based device

[Vladimir Murzin]

On 7/25/11, sandeep kumar <coolsandyforyou at gmail.com> wrote:
> Hi vladimir
>>I think this kind of behaviour could be configurable. In case you have
>>described bootloader can protect its code. Actually, kernel does not
>>know itself how much RAM is presented. Bootloader must provide kernel
>>with memory configuration through ATAGs (see mem boot option).
>>Therefore, bootloader can reserve some RAM for itself and does not say
>>kernel about it. As you have already get kernel use all memory which
>>is provided with bootloader and it is not always an entry RAM.
>
> In our bootloader, it seems they arent sending any ATAG_MEM as such,
> but the are calling start_kernel() function, in which start_kernel is a
> 'type casted function pointer'
> of the "kernel starting address".
>
> if ATAG_MEM is not sent..how wil the kernel treat the available memory.
>
> By the way ATAG_MEM has only start memory address.
> How to specify that "this much memory need to be reserved" for bootloader?
>
> On Mon, Jul 25, 2011 at 10:49 AM, Vladimir Murzin <murzin.v at gmail.com>wrote:
>
If we are discussing the ARM then the bootloader must provide either a
tagged list or a dtb image. Please, see Documentation/arm/Booting for
details. One more way to provide kernel with such sort of information
is specify boot cmdline.
With mem= boot option it's possible to specify not only start memory
address but size as well.  For example,
mem=512M at 0M specify 512M starting at 0x0
mem=512M at 512M specify 512M starting at 0x20000000

In the source three:
arch/arm/include/asm/setup.h

struct tag_mem32 {
            __u32   size;
            __u32   start;  /* physical start address */
};
...
static int __init parse_tag_mem32(const struct tag *tag)
{
         return arm_add_memory(tag->u.mem.start, tag->u.mem.size);
}

>> Hi sandeep!
>>
>> On 7/25/11, sandeep kumar <coolsandyforyou at gmail.com> wrote:
>> > Hi all,
>> > In Android target mobiles there is a facility called "Ramdump", where
>> > the
>> > entire Ram image is copied to a file
>> > as the kernel goes to panic.
>> >
>> > Ramdump is implemented like this
>> > 1) As the panic() function is called target will be reset.
>> > 2) Bootloader boots up in specific mode, where it enables the USB driver
>> in
>> > uploading mode.
>> > 3) Through USB entire RAM content is copied to a file in the host
>> computer.
>> > 4) This file is parsed through different tools and we can get the logs
>> info
>> > wat exactly happened just before kernel panic happend.
>> >
>> >
>> > Now here is the interesting part,
>> > While the mobile's RAM image is being uploaded to host computer, our
>> > bootloader is still running in the mobile's RAM.
>> > How can it copy its own running region.
>> >
>> > This triggered me the following questions,
>> >
>> > 1) When bootloader runs, will it run in a specific reserved region of
>> > RAM
>> or
>> > it takes entire RAM?
>>
>> AFAIK, it runs in specific region. For instance, for Das U-boot
>> bootloader you can get this with
>> $file ./uImage
>> uImage: u-boot legacy uImage, Linux-2.6.35-g6d019da-dirty, Linux/ARM,
>> OS Kernel Image (Not compressed), 2733288 bytes, Thu Sep  2 01:11:09
>> 2010, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC:
>> 0xEA95BF09, Data CRC: 0xF652AF6B
>>
>> > 2) When it hands over the control to kernel, will it relinquish the
>> entire
>> > RAM or certain part of RAM is reserved for it?
>> > 3) Does kernel use the entire RAM while running?
>>
>> I think this kind of behaviour could be configurable. In case you have
>> described bootloader can protect its code. Actually, kernel does not
>> know itself how much RAM is presented. Bootloader must provide kernel
>> with memory configuration through ATAGs (see mem boot option).
>> Therefore, bootloader can reserve some RAM for itself and does not say
>> kernel about it. As you have already get kernel use all memory which
>> is provided with bootloader and it is not always an entry RAM.
>>
>> > 4) When the kernel is running, is ther any chance that, control again be
>> > taken back to bootloader?(coz i saw in bootloader code kernel is being
>> > called,
>> >
>> > after that code also some code is there,some printks and error handling
>> > stuff)
>> >
>> > Pls help me out here..
>> >
>> >
>> >
>> > --
>> > With regards,
>> > Sandeep Kumar Anantapalli,
>> >
>>
>
>
>
> --
> With regards,
> Sandeep Kumar Anantapalli,
>