<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div style="" class=""><span style="" class=""><br style="">Hi Dave,</span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br style="" class=""><span style="" class=""></span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span style="" class="">1) what I talked about is pure 32bit (not with PAE, but should not be a problem with PAE)</span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span style="" class="">64 bit ELF headers could also be in place.</span></div><div
class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br style="" class=""></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">but my first and important point is: get 32bit implementation right (rest will fall after that)</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">in other words, the design/framework has to be made in such a way that existing crash utility absorbs both ELF32 and 64 and even any other debugging format or not to mention for long term but 128 bit ELF format as well :)</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color:
transparent; font-style: normal;">kdump should be capable of reading it I think.</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br style="" class=""></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">2) OK, so then after you've created the temporary ELF file, crash internally<br style="" class="" clear="none">would end up setting the pc->readmem() pointers to read_kdump()? Or do<br style="" class="" clear="none">you have your own readmem() function in the new ramdump.c file? <br style="" class=""></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br style="" class=""></div><div class=""
style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">currently I am setting function point to kdump, so I dont have separate readmem function.</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br style="" class=""></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">3) Clarify one more thing please: is the temporary file simply a little standalone ELF<br style="" class="" clear="none">header that describes what's in the ddr.bin file? Or do you concatenate the ELF<br style="" class="" clear="none">header and the ddr.bin file into a single, temporary, ELF vmcore file that<br style="" class="" clear="none">is essentially a clone
of an ELF kdump dumpfile?<br style="" class=""><span style="" class=""></span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br style="" class=""><span style="" class=""></span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">it looks more closer to the former one which you mentioned.</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">standalone ELF object. (Vmcore is ELF format anyway, so should be similar)</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">not sure about kdump format
though.<br><span style="" class=""></span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">PS: It might take some time to post the patch because I wrote it in hurry to make it work at the first point:but now I have to think with the design perspective and more on long term perspective to make this framework scalable and get easily accommodated in crash utility architecture.</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif;
background-color: transparent; font-style: normal;">Regards,</div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;">Oza.<br></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"> <br></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span style="" class=""></span></div><div
class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span style="" class=""></span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span style="" class=""></span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span style="" class=""></span></div><div class="" style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span style="" class=""><br style="" class=""></span></div> <div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div class="" style="font-family: times new
roman, new york, times, serif; font-size: 12pt;"> <div class="" style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="" class="" dir="ltr"> <font style="" class="" face="Arial" size="2"> On Thursday, 29 May 2014 7:09 PM, Dave Anderson <anderson@redhat.com> wrote:<br style="" class=""> </font> </div> <br style="" class=""><br style="" class=""> <div style="" class=""><br style="" class="" clear="none"><br style="" class="" clear="none">----- Original Message -----<br style="" class="" clear="none">> Hi Dave,<br style="" class="" clear="none">> <br style="" class="" clear="none">> please find all my comments/clarifications/answers inline below.<br style="" class="" clear="none">> <br style="" class="" clear="none">> <br style="" class="" clear="none">> Since these raw DDR dumps seem to be an existing feature, it certainly<br style="" class="" clear="none">> seems worth implementing support
for them.<br style="" class="" clear="none">> <br style="" class="" clear="none">> I'm curious as to how these RAM dumps are currently used -- are there other<br style="" class="" clear="none">> tools that use them somehow?<br style="" class="" clear="none">> <br style="" class="" clear="none">> Oza: there could be various tools which organisation might be writing to<br style="" class="" clear="none">> extract some logs, because they know the physical address<br style="" class="" clear="none">> where their private/public logs are stored.<br style="" class="" clear="none">> but none of the tools match the ability of crash utility as we all agree.<br style="" class="" clear="none">> <br style="" class="" clear="none">> Are these DDR RAM dumps specific to embedded 32-bit ARM machines?<br style="" class="" clear="none">> <br style="" class="" clear="none">> Oza: yes it depends, if it is taken on armv7 then 32bit, if
it is armv8,<br style="" class="" clear="none">> then 64 bit.<br style="" class="" clear="none"><br style="" class="" clear="none">Are you thinking of supporting this feature for ARM64 as well?<br style="" class="" clear="none"><br style="" class="" clear="none">Also, by any chance are you working with 32-bit ARM with PAE? Currently<br style="" class="" clear="none">there is no support in the crash utility for ARM/PAE, and I have been <br style="" class="" clear="none">hoping/waiting for ARM developers on this list to develop and post patches<br style="" class="" clear="none">supporting it. Although it's unclear whether the kdump facility would<br style="" class="" clear="none">even work as-is with PAE, if this feature were available, it would be an<br style="" class="" clear="none">an alternative to kdump. Anyway, if/when ARM/PAE support is put in place,<br style="" class="" clear="none">it would require the usage of 64-bit ELF
headers for the 32-bit ARM/PAE dumps. <br style="" class="" clear="none">But I'm getting ahead of myself... ;-)<br style="" class="" clear="none"><br style="" class="" clear="none">> <br style="" class="" clear="none">> <br style="" class="" clear="none">> Your feature sounds like a two-stage process:<br style="" class="" clear="none">> <br style="" class="" clear="none">> (1) invoke crash utility -- passing it the base physical address of the<br style="" class="" clear="none">> contiguous RAM dump, and the RAM dump file name(s) -- and then crash<br style="" class="" clear="none">> creates a single ELF vmcore by pre-pending an ELF header and<br style="" class="" clear="none">> concatenating<br style="" class="" clear="none">> the dump file names.<br style="" class="" clear="none">> (2) invoke crash utility with vmlinux and
newly-created vmcore.<br style="" class="" clear="none">> <br style="" class="" clear="none">> Oza: yes it is 2 stage process, in the first stage crash utility will prepare<br style="" class="" clear="none">> something which crash utility itself can understand.<br style="" class="" clear="none">> which is nothing but ELF format, which every debugger typically understands<br style="" class="" clear="none">> (such as gdb)<br style="" class="" clear="none">> so I do that conversion at the first place.<br style="" class="" clear="none">> once that conversion is in place, crash utility core code takes it over and<br style="" class="" clear="none">> do the rest of the job. <br style="" class="" clear="none">> <br style="" class="" clear="none">> But you mention "generate object files" above. Do you generate more than one<br style="" class="" clear="none">> file?<br style="" class="" clear="none">> <br style=""
class="" clear="none">> Oza: what I meant by object file is ELF file (ELF is something which is ready to be loaded/linked)<br style="" class="" clear="none">> this object file is nothing but one temporary file which crash utility will create...<br style="" class="" clear="none">> so if you give<br style="" class="" clear="none">> <br style="" class="" clear="none">> crash ./vmlinux ./ramdump.bin kernel_base_address<br style="" class="" clear="none">> it woudl have created ramdump_ARM_ELF32 (temporary file) which crash utility will understand).<br style="" class="" clear="none">> after you exit crash, the temporary file would be deleted.<br style="" class="" clear="none">> <br style="" class="" clear="none">> Is the newly-created vmcore subsequently recognized as a netdump or kdump<br style="" class="" clear="none">> ELF vmcore? (i.e, handled by existing code in netdump.c)<br style="" class="" clear="none">>
<br style="" class="" clear="none">> Oza: it would be recognized as kdump (because I am currently using 'flags' of<br style="" class="" clear="none">> kdump), this is just to be aligned with crash internal implementations.<br style="" class="" clear="none">> <br style="" class="" clear="none">> but nontheless it is a separate ELF file<br style="" class="" clear="none"><br style="" class="" clear="none">OK, so then after you've created the temporary ELF file, crash internally<br style="" class="" clear="none">would end up setting the pc->readmem() pointers to read_kdump()? Or do<br style="" class="" clear="none">you have your own readmem() function in the new ramdump.c file? <br style="" class="" clear="none"><br style="" class="" clear="none">> <br style="" class="" clear="none">> Or does it create a new ELF-like dumpfile type that is handled in your new ramdump.c file?<br style="" class="" clear="none">> Oza: it is
separate ELF file.<br style="" class="" clear="none">> <br style="" class="" clear="none">> Could it be done in one step? In other words, something like:<br style="" class="" clear="none">> <br style="" class="" clear="none">> $ crash vmlinux --ddr 80000000 ddr1.bin [ddr2.bin ...]<br style="" class="" clear="none">> <br style="" class="" clear="none">> <br style="" class="" clear="none">> Oza: this is precisely what is hapepning.<br style="" class="" clear="none">> <br style="" class="" clear="none">> <br style="" class="" clear="none">> where there would be a "virtual" ELF header created that could be used<br style="" class="" clear="none">> during the crash session? (perhaps with an optional "-o outputfile"<br style="" class="" clear="none">> command line option to create/save it as an ELF vmcore)<br style="" class="" clear="none">> <br style="" class="" clear="none">> Oza: virtual ELF
header, and one more virtual program header would be created<br style="" class="" clear="none">> in temporary file which, the budle, called ELF32.<br style="" class="" clear="none">> optional command line option could be created as well. but currently we take<br style="" class="" clear="none">> bin file only.<br style="" class="" clear="none"><br style="" class="" clear="none">Clarify one more thing please: is the temporary file simply a little standalone ELF<br style="" class="" clear="none">header that describes what's in the ddr.bin file? Or do you concatenate the ELF<br style="" class="" clear="none">header and the ddr.bin file into a single, temporary, ELF vmcore file that<br style="" class="" clear="none">is essentially a clone of an ELF kdump dumpfile?<br style="" class="" clear="none"><br style="" class="" clear="none">Also, I suggested the "-o outputfile" option -- after which you could simply enter<br style="" class=""
clear="none">"crash vmlinux outputfile" -- because your implementation requires that the<br style="" class="" clear="none">user must be aware of the base physical address value. <br style="" class="" clear="none"><br style="" class="" clear="none">Anyway, this all sounds good, so please post a patch. And can you also make one of<br style="" class="" clear="none">these dumpfiles available to me to download? <br style="" class="" clear="none"><br style="" class="" clear="none">Thanks,<div style="" class="" id="yqtfd23869"><br style="" class="" clear="none"> Dave<br style="" class="" clear="none"> <br style="" class="" clear="none"><br style="" class="" clear="none"><br style="" class="" clear="none"><br style="" class="" clear="none"> <br style="" class="" clear="none"> <br style="" class="" clear="none"></div><br style="" class=""><br style="" class=""></div> </div> </div> </div> </div></body></html>