Porting the 2.6.38 linux kernel to ARM11 MPcore

[Molnár Gábor]

> Does your physical RAM start at 0xc0000000 and it is all ignored?
> Setting highmem would fix as all your lowmem (including the kernel
> code) would be unmapped, hence the fault. What's the VMALLOC_END
> defined to?

#define VMALLOC_END             0xf8000000

For the platform i use. The size of vmalloc is the default (128MB).

If HIGHMEM is not set, this area is executed:

>/*
>792                  * Check whether this memory bank would entirely overlap
>793                  * the vmalloc area.
>794                  */
>795                 if (__va(bank->start) >= vmalloc_min ||
>796                     __va(bank->start) < (void *)PAGE_OFFSET) {
>797                         printk(KERN_NOTICE "Ignoring RAM at %.8lx-%.8lx "
>798                                "(vmalloc region overlap).\n",
>799                                bank->start, bank->start + bank->size - 1);
>800                         continue;
>801                 }

static void * __initdata vmalloc_min = (void *)(VMALLOC_END - SZ_128M);

The kernel is loaded on the phisical address: 0xc0000000-0xc05000000.
(This region is given as atag_mem as well).

At the current configuration i believe vmalloc should be at
0xF0000000-0xF8000000.

Why does this overlap with 0xC0000000-0xC0500000?



2011/11/22 Molnár Gábor <conqrx at gmail.com>:
> Thank you for your reply!
>
> 2011/11/21 Catalin Marinas <catalin.marinas at arm.com>:
>> On 18 November 2011 11:54, Molnár Gábor <conqrx at gmail.com> wrote:
>>> im working on a project wich aims at porting the 2.6.38 kernel to an
>>> arm11 mpcore based board.
>>>
>>> The kernel fails to boot, in the paging_init func, it throws an
>>> exception (pc: FFFF_000C) when executing the third mcr instruction in
>>> the list below:
>>>
>>> 0xc000bf34  <>:    blx  r3
>>> 0xc000bf38  <>:    mov  r5, #0  ; 0x0
>>> 0xc000bf3c  <>:    mcr  15, 0, r5, cr7, cr10, {4}
>>> 0xc000bf40  <>:    mcr  15, 0, r5, cr8, cr6, {0}
>>> 0xc000bf44  <>:    mcr  15, 0, r5, cr8, cr5, {0} //throws an exception
>>> here, Invalidate Instruction TLB Register
>>> 0xc000bf48  <>:    mcr  15, 0, r5, cr7, cr5, {6}
>>> 0xc000bf4c  <>:    mcr  15, 0, r5, cr7, cr10, {4}
>>> 0xc000bf50  <>:    mcr  15, 0, r5, cr7, cr5, {4}
>>> 0xc000bf54  <>:    ldr  lr, [pc, #176]  ; 0xc000c00c
>>
>> So you get a prefetch abort as soon as the TLBs are invalidated, which
>> means that the page table is not set up correctly.
>>
>> What's your RAM configuration (start address, size)?
>
> In the current configuration the start address is c0000000 and the
> size is 500000.
> The .elf kernel image is loaded at the c0008000 'start' address.
>
>>> The kernel has been patched with the 2.6.38-arm1 patch, and configured
>>> to be as minimal as possible (the vmlinux.elf is 1.8MB) and
>>> cross-compiled with the Codesourcery gcc toolchain.
>>> The minimal size is improtant because the aim is to make the kernel
>>> run with only 5-6MB of memory (from c0000000 to c0500000).
>>> The 'boot_loader' i wrote passes the atag pointers (basically core and
>>> memory) and the kernel seemingly reads and parses them fine. The
>>> __log_buf before the exception:
>>>
>>> <5>Linux version 2.6.38-rc8 (VirtualBox) (gcc version 4.5.2 (Sourcery
>>> G++ Lite 2011.03-41) ) #6 Wed Nov 9 21:59:29 CET 2011
>>> <4>CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=08c5387f"
>>> <4>CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> <4>Machine: ARM-RealView PB11MPCore
>>> <5>Ignoring RAM at c0000000-c04fffff (vmalloc region overlap).
>>
>> Does your physical RAM start at 0xc0000000 and it is all ignored?
>> Setting highmem would fix as all your lowmem (including the kernel
>> code) would be unmapped, hence the fault. What's the VMALLOC_END
>> defined to?
>
> Yes it seems to be all ignored, i will check VMALLOC_END as soon as i can.
>