Linux Virtual memory mapping to Board memory map
 

I am trying to understand how i should change/configure the kernel to run in a custom board from the RAM, running an arm processor.

Linux Kernel is mapped in the virtual memory area starting
PAGE_OFFSET to HIGHMEMORY-1. Then comes the VMALLOC_START to VMALLOC_END area and other areas. The actual physical ram has to be mapped starting from PAGE_OFFSET and ending at HIGHMEMORY. so, i should
define the macros VIRT_TO_PHYS(x) and PHYS_TO_VIRT(x) according to that.

So, if my ram starts at 0xA0000000(physical address) i should define the macros as below

VIRT_TO_PHYS(x) (X - PAGE_OFFSET + 0xA0000000)
PHYS_TO_VIRT(x) (X + PAGE_OFFSET - 0xA0000000).

This takes care of the user space mapping and the kernel space mapping.
In the sense, kernel can use these macros to fill the entries in the page table, when it maps the user space and kernel space.
But there will be CPU reigsters in the physical area of 0x10000000 to 0x10041FFF. Obviously to map this area, above macros cannot be used by the kernel.
So, how to map these areas correctly in the page table maintained by the linux kernel. Am i missing something here in my understanding here, in the sense this macro is used only for memory mapping and all other things like CPU REGISTER AREA and IO area will be mapped in a different way, in the page table.

Can anybody explain as to how kernel can be made to map the SDRAM at OxA0000000 and CPU REGISTER area from Ox10000000-0x10041FFF, in the page table, so that it can access both SDRAM and CPUREGISTER area , when MMU is enabled?

This appears to be a cross-post of http://www.linuxquestions.org/questi...apping-677347/

Yep. Since the topic comes under both embedded and kernel, i have posted in both the places.

Please don't do that. It's against the rules of the forum, and splits the efforts to help with the problem.

Please post your thread in only one forum. Posting a single thread in the most relevant forum will make it easier for members to help you and will keep the discussion in one place. This thread is being closed because it is a duplicate.