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.
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 filw 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), thsi is just to eb aligned with crash internal implementations.
but nontheless it is a separate ELF 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 ...]
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.
please feel free to ask anymore questions.
Oza.
On Wednesday, 28 May 2014 9:50 PM, Dave Anderson <anderson@xxxxxxxxxx> wrote:
----- Original Message -----
> Hi Dave,
>
> I am typing this reply from phone, so keeping it short, will give elaborate
> reply tomorrow if need.
Yes -- please answer all of the questions in my email.
>
> I am doing it in one step only,
> If you give something like below
>
> Crash vmlinux bin_file kernel_base
>
> Crashutility creates virtual elf32
> once you exit crash, crash will delete temporary arm elf file which we
> created in one step process.
>
> It will look like vmcore, but actually it is just conversion to elf, in fact
> vmcore is in elf format,
>
> Like kdump and merino lets call this one more format raw_ramdump_elf32
What is "merino"?
Dave
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
