Navigation: Linux Kernel Driver DataBase - web LKDDB: Main index - P index

CONFIG_PHYSICAL_START: Physical address where the kernel is loaded

General informations

The Linux kernel configuration item CONFIG_PHYSICAL_START has multiple definitions:

Physical address where the kernel is loaded found in arch/x86/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

This gives the physical address where the kernel is loaded.

If the kernel is not relocatable (RELOCATABLE=n) then bzImage will decompress itself to above physical address and run from there. Otherwise, bzImage will run from the address where it has been loaded by the boot loader. The only exception is if it is loaded below the above physical address, in which case it will relocate itself there.

In normal kdump cases one does not have to set/change this option as now bzImage can be compiled as a completely relocatable image (RELOCATABLE=y) and be used to load and run from a different address. This option is mainly useful for the folks who don't want to use a bzImage for capturing the crash dump and want to use a vmlinux instead. vmlinux is not relocatable hence a kernel needs to be specifically compiled to run from a specific memory area (normally a reserved region) and this option comes handy.

So if you are using bzImage for capturing the crash dump, leave the value here unchanged to 0x1000000 and set RELOCATABLE=y. Otherwise if you plan to use vmlinux for capturing the crash dump change this value to start of the reserved region. In other words, it can be set based on the "X" value as specified in the "crashkernel=YM@XM" command line boot parameter passed to the panic-ed kernel. Please take a look at Documentation/admin-guide/kdump/kdump.rst for more details about crash dumps.

Usage of bzImage for capturing the crash dump is recommended as one does not have to build two kernels. Same kernel can be used as production kernel and capture kernel. Above option should have gone away after relocatable bzImage support is introduced. But it is present because there are users out there who continue to use vmlinux for dump capture. This option should go away down the line.

Don't change this unless you know what you are doing.

Physical address where the kernel is loaded found in arch/sh/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

This gives the physical address where the kernel is loaded and is ordinarily the same as MEMORY_START.

Different values are primarily used in the case of kexec on panic where the fail safe kernel needs to run at a different address than the panic-ed kernel.

Physical address where the kernel is loaded found in arch/powerpc/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

(none)

Physical address where the kernel is loaded found in arch/mips/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

This gives the CKSEG0 or KSEG0 address where the kernel is loaded. If you plan to use kernel for capturing the crash dump change this value to start of the reserved region (the "X" value as specified in the "crashkernel=YM@XM" command line boot parameter passed to the panic-ed kernel).

found in arch/powerpc/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

(none)

Physical address where the kernel is loaded found in arch/loongarch/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

This gives the XKPRANGE address where the kernel is loaded. If you plan to use kernel for capturing the crash dump change this value to start of the reserved region (the "X" value as specified in the "crashkernel=YM@XM" command line boot parameter passed to the panic-ed kernel).

Physical address where the kernel is loaded found in arch/x86_64/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

This gives the physical address where the kernel is loaded. It should be aligned to 2MB boundary.

If kernel is a not relocatable (RELOCATABLE=n) then bzImage will decompress itself to above physical address and run from there. Otherwise, bzImage will run from the address where it has been loaded by the boot loader and will ignore above physical address.

In normal kdump cases one does not have to set/change this option as now bzImage can be compiled as a completely relocatable image (RELOCATABLE=y) and be used to load and run from a different address. This option is mainly useful for the folks who don't want to use a bzImage for capturing the crash dump and want to use a vmlinux instead.

So if you are using bzImage for capturing the crash dump, leave the value here unchanged to 0x200000 and set RELOCATABLE=y. Otherwise if you plan to use vmlinux for capturing the crash dump change this value to start of the reserved region (Typically 16MB 0x1000000). In other words, it can be set based on the "X" value as specified in the "crashkernel=YM@XM" command line boot parameter passed to the panic-ed kernel. Typically this parameter is set as crashkernel=64M@16M. Please take a look at Documentation/kdump/kdump.txt for more details about crash dumps.

Usage of bzImage for capturing the crash dump is advantageous as one does not have to build two kernels. Same kernel can be used as production kernel and capture kernel.

Don't change this unless you know what you are doing.

Physical address where the kernel is loaded found in arch/i386/Kconfig

The configuration item CONFIG_PHYSICAL_START:

Help text

This gives the physical address where the kernel is loaded.

If kernel is a not relocatable (RELOCATABLE=n) then bzImage will decompress itself to above physical address and run from there. Otherwise, bzImage will run from the address where it has been loaded by the boot loader and will ignore above physical address.

In normal kdump cases one does not have to set/change this option as now bzImage can be compiled as a completely relocatable image (RELOCATABLE=y) and be used to load and run from a different address. This option is mainly useful for the folks who don't want to use a bzImage for capturing the crash dump and want to use a vmlinux instead. vmlinux is not relocatable hence a kernel needs to be specifically compiled to run from a specific memory area (normally a reserved region) and this option comes handy.

So if you are using bzImage for capturing the crash dump, leave the value here unchanged to 0x100000 and set RELOCATABLE=y. Otherwise if you plan to use vmlinux for capturing the crash dump change this value to start of the reserved region (Typically 16MB 0x1000000). In other words, it can be set based on the "X" value as specified in the "crashkernel=YM@XM" command line boot parameter passed to the panic-ed kernel. Typically this parameter is set as crashkernel=64M@16M. Please take a look at Documentation/kdump/kdump.txt for more details about crash dumps.

Usage of bzImage for capturing the crash dump is recommended as one does not have to build two kernels. Same kernel can be used as production kernel and capture kernel. Above option should have gone away after relocatable bzImage support is introduced. But it is present because there are users out there who continue to use vmlinux for dump capture. This option should go away down the line.

Don't change this unless you know what you are doing.

Hardware

LKDDb

Raw data from LKDDb:

Sources

This page is automaticly generated with free (libre, open) software lkddb(see lkddb-sources).

The data is retrived from:

Automatic links from Google (and ads)

Custom Search

Popular queries:

Navigation: Linux Kernel Driver DataBase - web LKDDB: main index - P index

Automatically generated (in year 2024). See also LKDDb sources on GitLab