Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to realize Linux memory initialization". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Create a startup page table:

In the head.S file in the assembly code phase, the function responsible for creating the mapping relationship is create_page_tables. The create_page_tables function is responsible for identity mapping and kernel image mapping.

Identity map: refers to mapping the physical address of the idmap_text area to the equivalent virtual address. When this mapping is completed, the virtual address is equal to the physical address. The idmap_text area is full of code related to opening MMU. Kernel image map: map the addresses (kernel txt, rodata, data, bss, and so on) needed for kernel to run. Arch/arm64/kernel/head.S:

ENTRY (stext)

Bl preserve_boot_args

Bl el2_setup / / Drop to EL1, w0=cpu_boot_mode

Adrp x23, _ _ PHYS_OFFSET

And x23, x23, MIN_KIMG_ALIGN-1 / / KASLR offset, defaults to 0

Bl set_cpu_boot_mode_flag

Bl _ _ create_page_tables

/ *

* The following calls CPU setup code, see arch/arm64/mm/proc.S for

* details.

* On return, the CPU will be ready for the MMU to be turned on and

* the TCR will have been set.

, /

Bl _ _ cpu_setup / / initialise processor

B _ _ primary_switch

ENDPROC (stext)

_ _ create_page_tables mainly executes identity map and kernel image map:

_ _ create_page_tables:

.

Create_pgd_entry x0, x3, x5, x6

Mov x5, x3 / / _ _ pa (_ _ idmap_text_start)

Adr_l x6, _ _ idmap_text_end / / _ _ pa (_ _ idmap_text_end)

Create_block_map x0, x7, x3, x5, x6

/ *

* Map the kernel image (starting with PHYS_OFFSET).

, /

Adrp x0, swapper_pg_dir

Mov_q x5, KIMAGE_VADDR + TEXT_OFFSET / / compile time _ _ va (_ text)

Add x5, x5, x23 / / add KASLR displacement

Create_pgd_entry x0, x5, x3, x6

Adrp x6, _ end / / runtime _ _ pa (_ end)

Adrp x3, _ text / / runtime _ _ pa (_ text)

Sub x6, x6, x3 / / _ end-_ text

Add x6, x6, x5 / / runtime _ _ va (_ end)

Create_block_map x0, x7, x3, x5, x6

.

Create_pgd_entry is called to create PGD and all intermediate level (PUD, PMD) page tables, and create_block_map is called to map PTE page tables. The relationship between the four-level page table is shown in the following figure, so there is no further explanation here.

The memory mapping after assembly is shown in the following figure:

After executing the above map, the MMU is open and the C code is running, so the next step is to map the dtb.

Dtb map of fixmap area:

In the execution of setup_arch, early_fixmap_init () is performed first, and this function is used for map dtb, but it only establishes the page table entry of the level in the middle of the physical address corresponding to the dtb, and the page table mapping of the last level is created by fixmap_remap_fdt in the setup_machine_fdt function.

Void * _ init fixmap_remap_fdt (phys_addr_t dt_phys)

{

Void * dt_virt

Int size

Dt_virt = _ _ fixmap_remap_fdt (dt_phys, & size, PAGE_KERNEL_RO)

If (! dt_virt)

Return NULL

Memblock_reserve (dt_phys, size)

Return dt_virt

}

Fixmap_remap_fdt mainly establishes address mapping for fdt, and at the end of this function, the memory is reserved by calling memblock_reserve by the way.

It can be seen that the mapping of dtb uses fixmap, and the so-called fixmap is a fixed mapping, which requires us to clearly know the physical address we want to map and map this address to the virtual address we want to map. Of course, fixed mapping is also a bit one-sided here, because in the implementation of the fixmap mechanism, there is also a feature that supports dynamic allocation of virtual addresses, which is mainly used for temporary fixmap mapping (this temporary mapping is used to perform early ioremap. While the mapping of dtb is a permanent mapping

Early ioremap of fixmap area:

For hardware that needs to work before the memory management system gets up, we can use this mechanism to map memory to the hardware driver. After using the address of early ioremap, each module needs to release the mapped virtual address as soon as possible, so that it can be repeatedly applied for use by other modules.

Early_ioremap_init calls early_ioremap_setup:

It can be seen that its implementation depends on fixmap, so it must be run after early_fixmap_init.

Note: if you want to access device registers before the partner system is initialized, consider the early IO remap mechanism.

So far, we know that both dtb and early ioremap are in the fixmap area, as shown below:

Layout of system memory:

After completing the map of dtb, the kernel can access this section of memory. By parsing the contents of the dtb, the kernel can outline the entire memory layout, laying the foundation for subsequent memory management initialization. This step is mainly done in setup_machine_fdt. Instead of looking at the code here, the calling process is: setup_machine_fdt- > early_init_dt_scan- > early_init_dt_scan_nodes

As shown in the comments, the kernel outlines the corresponding memory area of the dtb according to the different node of the choosen node,root node,memory node.

In addition to these three node, there is also a reserved-memory node, which is done by the fixmap_remap_fdt function when dtb map is mentioned above. Let's take a look at the specific implementation of these four node.

Choosen node this node has a bootargs attribute that defines kernel startup parameters, such as mem= xx, and handles initrd-related property, which is stored in the initrd_start and initrd_end global variables. Root node has nothing to do with memory, so I won't elaborate on it for the time being. I'll talk about the device tree series later. Memory node

Add it to the memblock_type linked list corresponding to memblock.memory through memblock_add for management.

Next, come to the arm64_memblock_init function:

Void _ init arm64_memblock_init (void)

{

.

Memblock_reserve (_ _ pa_symbol (_ text), _ end-_ text); 1.kernel image reservation

# ifdef CONFIG_BLK_DEV_INITRD

If (initrd_start) {

Memblock_reserve (initrd_start, initrd_end-initrd_start); 2.initrd reservation

/ * the generic initrd code expects virtual addresses * /

Initrd_start = _ _ phys_to_virt (initrd_start)

Initrd_end = _ _ phys_to_virt (initrd_end)

}

# endif

Early_init_fdt_scan_reserved_mem (); the area configured to be reserved in the 3.dts

.

}

Reserve kernel code, datazone, etc. (from _ text to _ end, for more information, please refer to the kernel link script) keep the initital ramdisk image area (from initrd_start to initrd_end area) reserved-memory node as follows:

Through the above series of operations, the memory that needs to be dynamically managed has been put into the two region memory type and reserved type, and now the memory has been managed by the memblock module, which is only the first step after startup.

This is the end of "how to implement Linux memory initialization". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.