Re: [Crash-utility] ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)
----- Original Message -----
>I agree. We need to start to separate different ARM platforms
where
>normal
>v<->p rules don't apply and add necessary code to perform the
>translations.
Thank you very much for your effort and patience. I am looking forward
to see it.
There is only one question left in my mind.
Why a vmcore file with the following header is OK for crash to work
fine even though the PhysAddr is totally wrong? (I am very happy with
this)
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE
Well, if the memory that is copied to the dumpfile at file offset
0x000074 is actually physical memory from 0x00200000 (instead of
physical address 0), then it's essentially working "by mistake".
Dave
Takuo
>On Thu, May 26, 2011 at 12:11:35PM -0400, Dave Anderson wrote:
>>
>> >
>> > And I guess VTOP/PTOV needs modification in accordance with
>> > __phys_to_virt and __virt_to_phys.
>>
>> Right...
>>
>> Ultimately it will be advisable to extract the ARM VTOP() and
>> PTOV()
>> macros into machine-dependent functions, i.e., similar to the
>> X86_64
>> and IA64 architectures. And in those functions, intelligence will
>> have to be applied to determine how to handle the various ARM
>> types.
>
>I agree. We need to start to separate different ARM platforms where
>normal
>v<->p rules don't apply and add necessary code to perform the
>translations.
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility