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 wrote: > On Mon, Jun 2, 2014 at 12:53 PM, Saurabh Jain > 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: head.S
On Mon, Jun 2, 2014 at 12:53 PM, Saurabh Jain 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, On Mon, Jun 2, 2014 at 7:53 PM, Saurabh Jain 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, 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
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: ARM : Kernel : Setting up of MMU in head.S
Hi Dave. On Thu, Mar 31, 2011 at 7:29 PM, Dave Hylands wrote: > Hi Prakash, > > On Wed, Mar 30, 2011 at 11:01 PM, Prakash K.B. > wrote: > > Merci mate. :-) > > > > On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands > wrote: > >> > >> Hi Prakash, > >> > >> On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands > 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
Merci mate. :-) On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands wrote: > Hi Prakash, > > On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands wrote: > > Hi Prakash, > > > > On Wed, Mar 30, 2011 at 8:19 AM, Prakash K.B. > 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
Re: ARM : Kernel : Setting up of MMU in head.S
Hi Syed. On Thu, Mar 31, 2011 at 12:55 AM, sk.syed2 wrote: > > 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. > Lets say before mmu is turned on PC is at physical address XXX, also > say at XXX there is going to be mmu on instruction. The next > instruction fetch would be from XXX + 4 which would now be VIRTUAL > address(as mmu is turned on), which should still get converted to (via > page tables set up as above) to XXX + 4 (in physical). This is called > identity mapping as specified in the comments. Hope this helps. > > [Prakash]Awesome. This is indeed very insightful. I am now starting to understand this portion of the kernel better. Thanks a lot. :-) > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -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. wrote: > Merci mate. :-) > > On Thu, Mar 31, 2011 at 3:59 AM, Dave Hylands wrote: >> >> Hi Prakash, >> >> On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands 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
Hi Prakash, On Wed, Mar 30, 2011 at 2:35 PM, Dave Hylands wrote: > Hi Prakash, > > On Wed, Mar 30, 2011 at 8:19 AM, Prakash K.B. 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
Re: ARM : Kernel : Setting up of MMU in head.S
Hi Prakash, On Wed, Mar 30, 2011 at 8:19 AM, Prakash K.B. 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. > > 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. So the initial mapping is done using a single level table. The top 12 bits (3 nibbles) of the virtual address is used as the index into the table, and each entry in the table maps 1Mb of memory. At this stage of the boot, only the kernel direct memory is mapped. So, if your physical memory starts at 0x8000 and the kernel virtual space starts at 0xc000 then you should see entries like 0x800x 0x801x 0x802x 0x803x starting at 0x80007000. The first level table starts at an offset of 0x4000 into physical memory (0x80004000 - 0x80007fff physical or 0xc0004000 - 0xc0007fff virtual). If you take the top 3 nibbles of 0xc000 you get 0xc00 which when multipled by 4 (each entry is 4 bytes long), gives 0x3000. 0x80004000 + 0x3000 = 0x80007000. Later on, when the kernel is up and running it uses a 2 level table for memory allocated with get_pages. The 2-level table allows for 4k pages. The kernel direct memory remains mapped with 1 Mb entries. If you have access to it (you'll need to register and create an account), https://silver.arm.com/download/ARM_and_AMBA_Architecture/AR570-DC-11001-r0p0-00rel4/DDI0406B_arm_architecture_reference_manual_errata_markup_8_0.pdf on page B3-8 shows the layout of the entries which can exist in this top-level table. -- 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
> 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. Lets say before mmu is turned on PC is at physical address XXX, also say at XXX there is going to be mmu on instruction. The next instruction fetch would be from XXX + 4 which would now be VIRTUAL address(as mmu is turned on), which should still get converted to (via page tables set up as above) to XXX + 4 (in physical). This is called identity mapping as specified in the comments. Hope this helps. -syed ___ 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
