Base Address at Which The Linux Kernel Is Loaded

Dynamically find the address at which the kernel is loaded

From where do you want to find it? From kernel space or user space? If you want to get it from userspace you can parse output of the /proc/iomem:

cat /proc/iomem | grep "Kernel code"
01000000-0168b523 : Kernel code

If you want to get it from kernel space, you can __pa_symbol macro which returns physical address of a given symbol. In your case you will need to do something like this:

__pa_symbol(_text)

Does linux kernel assume that it is located at a particular physical address?

The kernel does expect to be at a specific location. That location is architecture specific. You can reconfigure and recompile the kernel to adjust this.

I was actually researching this recently for x86/x86_64, which is well documented. I would expect to find Sparc documentation there, though it doesn't jump out at me. Some information can be found here, though.

The relevant bit seems to be:

The boot sector that gets loaded is what you find in /boot/first.b in
your Linux-Sparc system, and is a bare 512 bytes. It is loaded to
address 0x4000 and its role is retrieving from disk /boot/second.b and
putting it to address 0x280000 (2.5 megs); the address has been chosen
because the Sparc specifications state that at least three megabytes
of RAM are mapped at boot time.

How to get the address of a kernel module that was inserted using insmod?

cat /proc/modules should give you a rough guide to where things are loaded. You might get more of a clue about exactly where the kernel crash is by looking at /proc/kallsyms.

why my x64 process base address not start from 0x400000?

I learned from this link Why is address 0x400000 chosen as a start of text segment in x86_64

That address is used for executables (ELF type ET_EXEC).

I only found my bash process starts from a very high base address (0x55971cea6000). Any one knows why?

Because your bash is (newer) position-independent executable (ELF type ET_DYN). It behaves much like a shared library, and is relocated to random address at runtime.

The 0x55971cea6000 address you found will vary from one execution to another. In contrast, ET_EXEC executables can only run correctly when loaded at their "linked at" address (typically 0x400000).

how does dynamic linker choose the start address for a 64-bit process?

The dynamic linker doesn't choose the start address of the executable -- the kernel does (by the time the dynamic linker starts running, the executable has already been mmaped into memory).

The kernel looks at the .e_type in the ELF header and .p_vaddr field of the first program header and goes from there. IFF .e_type == ET_EXEC, then the kernel maps executable segments at their .p_vaddr addresses. For ET_DYN, if ASLR is in effect, the kernel performs mmaps at a random address.

why is load address of kernel, ramdisk important in booting?

After the U-boot finished, it needs to handover the further execution to kernel so that kernel takes care for all further processes. Plus Kernel have some set of routines which are essential to initialize the board.

These set of routines have a entry point start_kernel(). Before this some other routines are also called to execute start_kernel. That can be identified by this linker script and this init.S.

To maintain execution in this procedure kernel need to be started from a particular address, moreover its data segments and other memories are also attached with that so to load and run all these in a proper manner, exact memory location need to be provided.

With this kernel needs the device tree blob for probing the devices attached to it and the rootfs to bring up the user space, here to load the device tree and rootfs exact offsets are needed so that any data should not be missed or corrupted. Every single byte is important for all these execution.

So to safely bootup all these values are being stored in bootloader's configuration.