Re: ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> 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?
Sorry. It's my typo as this was not real output of readelf. The second start from 0xd0000000.
>> LOAD 0x0fe00094 0xd0000000 0x40000000 0x10000000 0x10000000 RWE


Takuo

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

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility


[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux