[Crash-utility] ARM support for CONFIG_SPARSEMEM:(was Re:DDimage)
takuo.koguchi.sw at hitachi.com
takuo.koguchi.sw at hitachi.com
Thu May 26 15:37:31 UTC 2011
Dave, Mika,
memory.h I am using is probably the same as this,
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=arch/arm/mach-msm/include/mach/memory.h;h=afe6051b9826d788849aafa52b55b3760b6cf1ec;hb=debd216b762a87da0faf0eb4f991ed10c7a052cc
19 /* physical offset of RAM */
20 #define PHYS_OFFSET UL(CONFIG_PHYS_OFFSET) <-- 0x00200000
21
22 #define MAX_PHYSMEM_BITS 32
23 #define SECTION_SIZE_BITS 28
24
25 /* Certain configurations of MSM7x30 have multiple memory banks.
26 * One or more of these banks can contain holes in the memory map as well.
27 * These macros define appropriate conversion routines between the physical
28 * and virtual address domains for supporting these configurations using
29 * SPARSEMEM and a 3G/1G VM split.
30 */
31
32 #if defined(CONFIG_ARCH_MSM7X30)
33
34 #define EBI0_PHYS_OFFSET PHYS_OFFSET
35 #define EBI0_PAGE_OFFSET PAGE_OFFSET
36 #define EBI0_SIZE 0x10000000
37
38 #define EBI1_PHYS_OFFSET 0x40000000
39 #define EBI1_PAGE_OFFSET (EBI0_PAGE_OFFSET + EBI0_SIZE)
40
41 #if (defined(CONFIG_SPARSEMEM) && defined(CONFIG_VMSPLIT_3G))
42
43 #define __phys_to_virt(phys) \
44 ((phys) >= EBI1_PHYS_OFFSET ? \
45 (phys) - EBI1_PHYS_OFFSET + EBI1_PAGE_OFFSET : \
46 (phys) - EBI0_PHYS_OFFSET + EBI0_PAGE_OFFSET)
47
48 #define __virt_to_phys(virt) \
49 ((virt) >= EBI1_PAGE_OFFSET ? \
50 (virt) - EBI1_PAGE_OFFSET + EBI1_PHYS_OFFSET : \
51 (virt) - EBI0_PAGE_OFFSET + EBI0_PHYS_OFFSET)
52
53 #endif
54
55 #endif
So my previous description of actual memory mapping was not correct.
The correct description is,
Virtual 0xc0000000-0xcfdfffff -> Physical 0x00200000-0x0fffffff
and
Virtual 0xd0000000-0xdfffffff -> Physical 0x40000000-0x4fffffff
Tomorrow I will check if vmcore with the following header is recognized by crash.
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000094 0xc0000000 0x00200000 0x0fe00000 0x0fe00000 RWE
LOAD 0x0fe00094 0xc0000000 0x40000000 0x10000000 0x10000000 RWE
And I guess VTOP/PTOV needs modification in accordance with __phys_to_virt and __virt_to_phys.
For your information,
The vmcore file with the following header is recognized by crash and many commands works fine,
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE
if the patches for unwind_arm.c, arm.c and defs.h posted in this ML thread applied and readmem error_handle for FILL_PTBL is change to RETURN_ON_ERROR.
Without the last modification above crash exits when readmem fails at FILL_PTBL before reaching the first prompt.
Best Regards,
Takuo Koguchi
>
>
>----- Original Message -----
>> On Thu, May 26, 2011 at 11:53 AM, <takuo.koguchi.sw at hitachi.com> wrote:
>
>> > It might come form my vmcore file's incorrectness.
>> > Currently my vmcore contains the following,
>> > Program Headers:
>> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> > NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
>> > LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0
>> >
>> > But actual mapping is,
>> > Virtual 0xc0000000-0xcfffffff corresponds Physical 0x00000000-0x0fffffff
>> > and
>> > Virtual 0xd0000000-0xdfffffff corresponds Physical 0x40000000-0x4fffffff
>> >
>> > Then I tried to prepend the following header instead,
>> > Program Headers:
>> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> > NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
>> > LOAD 0x000094 0xc0000000 0x00000000 0x10000000 0x10000000 RWE 0
>> > LOAD 0x10000094 0xd0000000 0x40000000 0x10000000 0x10000000 RWE 0
>> >
>> > This time crash does not recognize the vmcore file.
>> >
>> > Perhaps I have to change VTOP/PTOV macros accordingly?
>>
>> It should be enough if you have machdep->machspec->phys_base set to
>> correct value, which is 0 in your case. You can see this by running
>> 'crash -d1 ...'. Also if possible, can you post the full output here
>> so that we can analyze it further.
>
>Hey guys,
>
>Pardon my confusion/interruption, but the "actual mapping" above would
>be unique for unity-mapping. The 0xc0000000-0xcfffffff segment is
>"traditionally" unity-mapped, where VTOP() would strip off the kvbase,
>and then apply a physical base if appropriate. But then the second
>0xd0000000-0xdfffffff segment could not use the same logic.
>
>Looking at the upstream ARM sources, __pa() is:
>
> #define __pa(x) __virt_to_phys((unsigned long)(x))
>
>where __virt_to_phys() does something different if CONFIG_ARM_PATCH_PHYS_VIRT
>is configured:
>
> #ifdef CONFIG_ARM_PATCH_PHYS_VIRT
>
> /*
> * Constants used to force the right instruction encodings and shifts
> * so that all we need to do is modify the 8-bit constant field.
> */
> #define __PV_BITS_31_24 0x81000000
> #define __PV_BITS_23_16 0x00810000
>
> extern unsigned long __pv_phys_offset;
> #define PHYS_OFFSET __pv_phys_offset
>
> #define __pv_stub(from,to,instr,type) \
> __asm__("@ __pv_stub\n" \
> "1: " instr " %0, %1, %2\n" \
> " .pushsection .pv_table,\"a\"\n" \
> " .long 1b\n" \
> " .popsection\n" \
> : "=r" (to) \
> : "r" (from), "I" (type))
>
> static inline unsigned long __virt_to_phys(unsigned long x)
> {
> unsigned long t;
> __pv_stub(x, t, "add", __PV_BITS_31_24);
> #ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> __pv_stub(t, t, "add", __PV_BITS_23_16);
> #endif
> return t;
> }
>
> static inline unsigned long __phys_to_virt(unsigned long x)
> {
> unsigned long t;
> __pv_stub(x, t, "sub", __PV_BITS_31_24);
> #ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> __pv_stub(t, t, "sub", __PV_BITS_23_16);
> #endif
> return t;
> }
> #else
> #define __virt_to_phys(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
> #define __phys_to_virt(x) ((x) - PHYS_OFFSET + PAGE_OFFSET)
> #endif
>
>Is that what's happening here? I don't understand the __pv_stub()
>stuff, but if the virtual-to-physical unity-mapping is as Takuo
>described, then there would have to be a change to the ARM VTOP/PTOV
>macros.
>
>Anyway, as to why crash doesn't recognize the vmcore with the second
>PT_LOAD segment added, you'll have to debug why is_netdump() is
>rejecting it.
>
>Dave
>
>--
>Crash-utility mailing list
>Crash-utility at redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
More information about the Crash-utility
mailing list