Hi Prakash, On Wed, Mar 30, 2011 at 11:01 PM, Prakash K.B. <prakashk75@xxxxxxxxx> wrote: > Merci mate. :-) > > On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands <dhylands@xxxxxxxxx> wrote: >> >> Hi Prakash, >> >> On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands <dhylands@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
