Re: ARM : Kernel : Setting up of MMU in head.S
Hi Prakash, On Wed, Mar 30, 2011 at 11:01 PM, Prakash K.B. <prakashk75@gmail.com> wrote:
Merci mate. :-)
On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Prakash,
On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands <dhylands@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
Hi Dave. On Thu, Mar 31, 2011 at 7:29 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Prakash,
On Wed, Mar 30, 2011 at 11:01 PM, Prakash K.B. <prakashk75@gmail.com> wrote:
Merci mate. :-)
On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Prakash,
On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands <dhylands@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.
[Prakash] I confirm I now see this exactly as you describe above and below. Thanks a bunch Dave.
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
-Prakash
participants (2)
-
Dave Hylands -
Prakash K.B.