From: prakashk75@gmail.com (Prakash K.B.)
To: kernelnewbies@lists.kernelnewbies.org
Subject: ARM : Kernel : Setting up of MMU in head.S
Date: Wed, 30 Mar 2011 20:49:39 +0530 [thread overview]
Message-ID: <AANLkTikbzjKepm7+ZhmA-3Vq33vADPaXrVdJGRc284OS@mail.gmail.com> (raw)
Hello.
Please do not hesitate to let me know if this must be posted elsewhere.
I have been trying to understand the code that sets up the MMU. I do have a
fair understanding of the way MMU is meant to be setup, but something in the
kernel code is tripping me.
The code that kickstarts setting up of MMU is __create_page_tables in
/arch/arm/kernel/head.S.
This code is position independent.
It basically
- Reserves 16KB of memory in RAM just before the start of the uncompressed
kernel.
- Clears the 16KB meant to serve as L1 lookup table containing 4096 entries
- Creates a section entry in L1 table for the kernel code to be mapped into
physical memory
It is this creation of section entry code that is puzzling me.
The index used to program this entry is based on physical address of the
kernel base.
The way it ought to work is this. When the CPU issues a virtual address,
the top bits are used as an index into this L1 table and then through a
couple of table walk throughs, the physical address is arrived at. So the
index used to program the L1 table ought to have been
Now look at this code.
__create_page_tables:
pgtbl r4 @ page table address
/*
* Clear the 16K level 1 swapper page table
*/
mov r0, r4 @r0 = 0x80004000
mov r3, #0
add r6, r0, #0x4000 @r6 = 0x80008000
1: str r3, [r0], #4
str r3, [r0], #4
str r3, [r0], #4
str r3, [r0], #4
teq r0, r6
bne 1b
/* r10 contains proc_info pointer */
ldr r7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
/*
* Create identity mapping to cater for __enable_mmu.
* This identity mapping will be removed by paging_init().
*/
adr r0, __enable_mmu_loc
ldmia r0, {r3, r5, r6}
sub r0, r0, r3 @ virt->phys offset
add r5, r5, r0 @ phys __enable_mmu
add r6, r6, r0 @ phys __enable_mmu_end
mov r5, r5, lsr #20
mov r6, r6, lsr #20
1: orr r3, r7, r5, lsl #20 @ flags + kernel base
str r3, [r4, r5, lsl #2] @ identity mapping
teq r5, r6
addne r5, r5, #1 @ next section
bne 1b
The 2 lines above
1: orr r3, r7, r5, lsl #20 @ flags + kernel base ==> Correct
str r3, [r4, r5, lsl #2] @ identity mapping ==> ??
create a section entry using index based on physical address.
Am I missing something here?
Regards,
Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110330/046219e1/attachment.html
next reply other threads:[~2011-03-30 15:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 15:19 Prakash K.B. [this message]
2011-03-30 19:25 ` ARM : Kernel : Setting up of MMU in head.S sk.syed2
2011-03-31 6:31 ` Prakash K.B.
2011-03-30 21:35 ` Dave Hylands
2011-03-30 22:29 ` Dave Hylands
2011-03-31 6:01 ` Prakash K.B.
2011-03-31 13:59 ` Dave Hylands
2011-04-03 8:01 ` Prakash K.B.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikbzjKepm7+ZhmA-3Vq33vADPaXrVdJGRc284OS@mail.gmail.com \
--to=prakashk75@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).