From mboxrd@z Thu Jan 1 00:00:00 1970 From: coolsandyforyou@gmail.com (sandeep kumar) Date: Mon, 25 Jul 2011 14:00:45 +0530 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 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: > 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, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110725/9a47369a/attachment-0001.html