head.S
hello every one ! I am trying to trace Linux kernel booting process for ARM architecture. Right now i am doing it manually . I am getting problem in reading assembly codes (like in head.s and other files) . Can any body tell me the correct way of tracing the linux kernel booting process ? Is there any guide which perfectly document Linux kernel files function by function ? Thank You! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: head.S
On Mon, 02 Jun 2014 21:23:16 +0530, Saurabh Jain said: I am trying to trace Linux kernel booting process for ARM architecture. Right now i am doing it manually . I am getting problem in reading assembly codes (like in head.s and other files) . Can any body tell me the correct way of tracing the linux kernel booting process ? Is there any guide which perfectly document Linux kernel files function by function ? Guide? When there's literally a million lines of new or changed code every release? Who is going to maintain the guide? Hint: Even the *source* doesn't perfectly document things function by function. pgpIOGU6uVrwl.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: head.S
Hi, On Mon, Jun 2, 2014 at 7:53 PM, Saurabh Jain saurabh4768j...@gmail.com wrote: I am trying to trace Linux kernel booting process for ARM architecture. Right now i am doing it manually . I am getting problem in reading assembly codes (like in head.s and other files) . Can any body tell me the correct way of tracing the linux kernel booting process ? Is there any guide which perfectly document Linux kernel files function by function ? Not *the* (supposedly only) correct way, just one possible way is to use gdb connected to qemu to step through your kernel code. Google suggests the following, which looks pretty decent: http://files.meetup.com/1590495/debugging-with-qemu.pdf -- Thanks. -- Max ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: head.S
On Mon, Jun 2, 2014 at 12:53 PM, Saurabh Jain saurabh4768j...@gmail.com wrote: hello every one ! I am trying to trace Linux kernel booting process for ARM architecture. Right now i am doing it manually . I am getting problem in reading assembly codes (like in head.s and other files) . Can any body tell me the correct way of tracing the linux kernel booting process ? Is there any guide which perfectly document Linux kernel files function by function ? Hi Saurabh, I don't know of any guide for Linux ARM boot code. But there are some guides for Linux x86 boot code for ancient Linux Kernels, like this: http://www.oldlinux.org/Linux.old/study/eclk-03-boot.pdf Best regards! -- Augusto Mecking Caringi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: head.S
Hi Saurabh, You can take a look at the DOC mentioned here. Its kind of gives an overview (not in depth) of every function in Booting process in ARM linux : http://www.linux-arm.org/pub/LinuxPlatform/RealViewLink/Booting_ARM_Linux_SMP_on_MPCore.doc Its a good start to dive into the internals. Thanks and regards, Vignesh Radhakrishnan On Mon, Jun 2, 2014 at 11:32 PM, Augusto Mecking Caringi augustocari...@gmail.com wrote: On Mon, Jun 2, 2014 at 12:53 PM, Saurabh Jain saurabh4768j...@gmail.com wrote: hello every one ! I am trying to trace Linux kernel booting process for ARM architecture. Right now i am doing it manually . I am getting problem in reading assembly codes (like in head.s and other files) . Can any body tell me the correct way of tracing the linux kernel booting process ? Is there any guide which perfectly document Linux kernel files function by function ? Hi Saurabh, I don't know of any guide for Linux ARM boot code. But there are some guides for Linux x86 boot code for ancient Linux Kernels, like this: http://www.oldlinux.org/Linux.old/study/eclk-03-boot.pdf Best regards! -- Augusto Mecking Caringi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- http://vigneshradhakrishnan.blogspot.com/ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ARM : Kernel : Setting up of MMU in head.S
Hi Dave. On Thu, Mar 31, 2011 at 7:29 PM, Dave Hylands dhyla...@gmail.com wrote: Hi Prakash, On Wed, Mar 30, 2011 at 11:01 PM, Prakash K.B. prakash...@gmail.com wrote: Merci mate. :-) On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands dhyla...@gmail.com wrote: Hi Prakash, On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands dhyla...@gmail.com wrote: ...snip... When the MMU table is turned on, the PC is still at 0x800, so even though the kernel has 0xc00x mapped to 0x800x it also has to have 0x800x mapped to 0x800x. [Prakash] I think you meant to say So even though the kernel intends to map 0xc00 to 0x800XXX in the future, it has currently mapped 0x800xxx to 0x800xxx. No. the create_page_table function creates a page table which has 0x800x and 0xc00x both mapped to 0x800x. The one store intrustion saves the identity mapping (for 1 Mb) and the loop sets up the 0xc00x to 0x800x 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 0x800x space to the 0xc00x 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ARM : Kernel : Setting up of MMU in head.S
Hi Prakash, On Wed, Mar 30, 2011 at 11:01 PM, Prakash K.B. prakash...@gmail.com wrote: Merci mate. :-) On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands dhyla...@gmail.com wrote: Hi Prakash, On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands dhyla...@gmail.com wrote: ...snip... When the MMU table is turned on, the PC is still at 0x800, so even though the kernel has 0xc00x mapped to 0x800x it also has to have 0x800x mapped to 0x800x. [Prakash] I think you meant to say So even though the kernel intends to map 0xc00 to 0x800XXX in the future, it has currently mapped 0x800xxx to 0x800xxx. No. the create_page_table function creates a page table which has 0x800x and 0xc00x both mapped to 0x800x. The one store intrustion saves the identity mapping (for 1 Mb) and the loop sets up the 0xc00x to 0x800x 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 0x800x space to the 0xc00x 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ARM : Kernel : Setting up of MMU in head.S
Merci mate. :-) On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands dhyla...@gmail.com wrote: Hi Prakash, On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands dhyla...@gmail.com wrote: Hi Prakash, On Wed, Mar 30, 2011 at 8:19 AM, Prakash K.B. prakash...@gmail.com wrote: 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. Some further explanation is due. When the kernel starts, the MMU is off, and ther ARM is running with an implicit identity mapping (i.e. each virtual address maps to the same physical address). [Prakash] Aha...So what I ignored as a routine code comment had a deeper meaning.. :-) If your physical memory starts at 0x8000, then the PC will be 0x800x. [Prakash] Agreed. When the MMU table is turned on, the PC is still at 0x800, so even though the kernel has 0xc00x mapped to 0x800x it also has to have 0x800x mapped to 0x800x. [Prakash] I think you meant to say So even though the kernel intends to map 0xc00 to 0x800XXX in the future, it has currently mapped 0x800xxx to 0x800xxx. 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? So this mapping of 0x800x to 0x800x is the identity portion and is needed while switching the MMU on. The 0xc00x to 0x800x mapping is what's used while the kernel is running. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com -Prakash ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
ARM : Kernel : Setting up of MMU in head.S
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:
pgtblr4@ page table address
/*
* Clear the 16K level 1 swapper page table
*/
movr0, r4 @r0 = 0x80004000
movr3, #0
addr6, r0, #0x4000 @r6 = 0x80008000
1:strr3, [r0], #4
strr3, [r0], #4
strr3, [r0], #4
strr3, [r0], #4
teqr0, r6
bne1b
/* r10 contains proc_info pointer */
ldrr7, [r10, #PROCINFO_MM_MMUFLAGS] @ mm_mmuflags
/*
* Create identity mapping to cater for __enable_mmu.
* This identity mapping will be removed by paging_init().
*/
adrr0, __enable_mmu_loc
ldmiar0, {r3, r5, r6}
subr0, r0, r3@ virt-phys offset
addr5, r5, r0@ phys __enable_mmu
addr6, r6, r0@ phys __enable_mmu_end
movr5, r5, lsr #20
movr6, r6, lsr #20
1: orrr3, r7, r5, lsl #20@ flags + kernel base
strr3, [r4, r5, lsl #2]@ identity mapping
teqr5, r6
addner5, r5, #1@ next section
bne1b
The 2 lines above
1: orrr3, r7, r5, lsl #20@ flags + kernel base == Correct
strr3, [r4, r5, lsl #2]@ identity mapping == ??
create a section entry using index based on physical address.
Am I missing something here?
Regards,
Prakash
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ARM : Kernel : Setting up of MMU in head.S
Hi Prakash, On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands dhyla...@gmail.com wrote: Hi Prakash, On Wed, Mar 30, 2011 at 8:19 AM, Prakash K.B. prakash...@gmail.com wrote: 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. Some further explanation is due. When the kernel starts, the MMU is off, and ther ARM is running with an implicit identity mapping (i.e. each virtual address maps to the same physical address). If your physical memory starts at 0x8000, then the PC will be 0x800x. When the MMU table is turned on, the PC is still at 0x800, so even though the kernel has 0xc00x mapped to 0x800x it also has to have 0x800x mapped to 0x800x. So this mapping of 0x800x to 0x800x is the identity portion and is needed while switching the MMU on. The 0xc00x to 0x800x mapping is what's used while the kernel is running. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
