ARM : Kernel : Setting up of MMU in head.S

[Dave Hylands]

Hi Prakash,

On Wed, Mar 30, 2011 at 11:01 PM, Prakash K.B. <prakashk75 at gmail.com> wrote:
> Merci mate. :-)
>
> On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands <dhylands at gmail.com> wrote:
>>
>> Hi Prakash,
>>
>> On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands <dhylands at gmail.com> wrote:
...snip...
>> When the MMU table is turned on, the PC is still at 0x800xxxx, so even
>> though the kernel has 0xc00xxxxx mapped to 0x800xxxxx it also has to
>> have 0x800xxxxx mapped to 0x800xxxxx.
>
> [Prakash] I think you meant to say "So even though the kernel intends to map
> 0xc00XXXX to 0x800XXX in the future, it has currently mapped 0x800xxx to
> 0x800xxx.

No. the create_page_table function creates a page table which has
0x800xxxxx and 0xc00xxxxx both mapped to 0x800xxxxx. The one store
intrustion saves the identity mapping (for 1 Mb) and the loop sets up
the 0xc00xxxxx to 0x800xxxxx mapping.

The identity portion is used as we discussed, and a few instructions
after turning on the MMU, the CPU then does a jump from the 0x800xxxxx
space to the 0xc00xxxxx space. After that, the identity mapping is no
longer needed. Shortly after this, head.S calls into the start_kernel
function (from init/main.c) and the paging_init function reinitializes
the MMU removing the identity mapping.

>
> Now that I know this identity mapping is done on purpose, I hope to make
> good progress with the succeeding sequence.
>
> Do you confirm that only one entry is written into this L1 table because
> both mmu_enable and enable_mmu_end are on the same section?

Yeah - essentially, that one mapping entry covers 1Mb of code space,
which is sufficient to cover all of head.S, which is always at the
front of the kernel image.

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com