----- Original Message ----- > Hi Dave, > > please find all my comments/clarifications/answers inline below. > > > Since these raw DDR dumps seem to be an existing feature, it certainly > seems worth implementing support for them. > > I'm curious as to how these RAM dumps are currently used -- are there other > tools that use them somehow? > > Oza: there could be various tools which organisation might be writing to > extract some logs, because they know the physical address > where their private/public logs are stored. > but none of the tools match the ability of crash utility as we all agree. > > Are these DDR RAM dumps specific to embedded 32-bit ARM machines? > > Oza: yes it depends, if it is taken on armv7 then 32bit, if it is armv8, > then 64 bit. Are you thinking of supporting this feature for ARM64 as well? Also, by any chance are you working with 32-bit ARM with PAE? Currently there is no support in the crash utility for ARM/PAE, and I have been hoping/waiting for ARM developers on this list to develop and post patches supporting it. Although it's unclear whether the kdump facility would even work as-is with PAE, if this feature were available, it would be an an alternative to kdump. Anyway, if/when ARM/PAE support is put in place, it would require the usage of 64-bit ELF headers for the 32-bit ARM/PAE dumps. But I'm getting ahead of myself... ;-) > > > Your feature sounds like a two-stage process: > > (1) invoke crash utility -- passing it the base physical address of the > contiguous RAM dump, and the RAM dump file name(s) -- and then crash > creates a single ELF vmcore by pre-pending an ELF header and > concatenating > the dump file names. > (2) invoke crash utility with vmlinux and newly-created vmcore. > > Oza: yes it is 2 stage process, in the first stage crash utility will prepare > something which crash utility itself can understand. > which is nothing but ELF format, which every debugger typically understands > (such as gdb) > so I do that conversion at the first place. > once that conversion is in place, crash utility core code takes it over and > do the rest of the job. > > But you mention "generate object files" above. Do you generate more than one > file? > > Oza: what I meant by object file is ELF file (ELF is something which is ready to be loaded/linked) > this object file is nothing but one temporary file which crash utility will create... > so if you give > > crash ./vmlinux ./ramdump.bin kernel_base_address > it woudl have created ramdump_ARM_ELF32 (temporary file) which crash utility will understand). > after you exit crash, the temporary file would be deleted. > > Is the newly-created vmcore subsequently recognized as a netdump or kdump > ELF vmcore? (i.e, handled by existing code in netdump.c) > > Oza: it would be recognized as kdump (because I am currently using 'flags' of > kdump), this is just to be aligned with crash internal implementations. > > but nontheless it is a separate ELF file OK, so then after you've created the temporary ELF file, crash internally would end up setting the pc->readmem() pointers to read_kdump()? Or do you have your own readmem() function in the new ramdump.c file? > > Or does it create a new ELF-like dumpfile type that is handled in your new ramdump.c file? > Oza: it is separate ELF file. > > Could it be done in one step? In other words, something like: > > $ crash vmlinux --ddr 80000000 ddr1.bin [ddr2.bin ...] > > > Oza: this is precisely what is hapepning. > > > where there would be a "virtual" ELF header created that could be used > during the crash session? (perhaps with an optional "-o outputfile" > command line option to create/save it as an ELF vmcore) > > Oza: virtual ELF header, and one more virtual program header would be created > in temporary file which, the budle, called ELF32. > optional command line option could be created as well. but currently we take > bin file only. Clarify one more thing please: is the temporary file simply a little standalone ELF header that describes what's in the ddr.bin file? Or do you concatenate the ELF header and the ddr.bin file into a single, temporary, ELF vmcore file that is essentially a clone of an ELF kdump dumpfile? Also, I suggested the "-o outputfile" option -- after which you could simply enter "crash vmlinux outputfile" -- because your implementation requires that the user must be aware of the base physical address value. Anyway, this all sounds good, so please post a patch. And can you also make one of these dumpfiles available to me to download? Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility