----- 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