----- Original Message ----- > 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 Shouldn't the second PT_LOAD segment have a p_vaddr of 0xc0000000? Although, in the case of ARM, I believe that the p_vaddr field is not used by the crash utility, as it is only interested in the p_paddr and p_memsz/p_filesz fields. But I presume you meant 0xd0000000 for the second one. > > 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. > > 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. But I'm thinking that if the VTOP/PTOV issue is resolved, then you won't see that readmem() error in FILL_PTBL(), because the address that was failing was generated by PTOV(): /* * pte_offset_map(pmd, vaddr) */ page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr); FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE()); Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
