From mboxrd@z Thu Jan 1 00:00:00 1970 From: murzin.v@gmail.com (Vladimir Murzin) Date: Tue, 26 Jul 2011 09:19:00 +0400 Subject: Interesting case while taking Ramdump of Linux kernel based device In-Reply-To: References: Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On 7/25/11, sandeep kumar 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 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 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, >