Interesting case while taking Ramdump of Linux kernel based device
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? 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? 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,
Hi sandeep, On Sun, Jul 24, 2011 at 9:18 PM, sandeep kumar <coolsandyforyou@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?
Some do - it depends on the processor. Some processors have a bunch of internal static RAM that the bootloader runs out of.
2) When it hands over the control to kernel, will it relinquish the entire RAM or certain part of RAM is reserved for it?
Not sure.
3) Does kernel use the entire RAM while running?
It depends on how things are configured.
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)
I don't think that the kernel ever gives control back to the bootloader. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
Hi sandeep! On 7/25/11, sandeep kumar <coolsandyforyou@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,
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@gmail.com>wrote:
Hi sandeep!
On 7/25/11, sandeep kumar <coolsandyforyou@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,
On 7/25/11, sandeep kumar <coolsandyforyou@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@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@0M specify 512M starting at 0x0 mem=512M@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@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,
participants (3)
-
Dave Hylands -
sandeep kumar -
Vladimir Murzin