The handover from the bootloader to the kernel necessarily involves some architecture-specific considerations such as memory addresses and register use. Consequently, the place to look is in the architecture-specific directories (
arch/*). Furthermore, handover from the bootloader involves a precise register usage protocol which is likely to be implemented in assembler. The kernel even has different entry points for different bootloaders on some architectures.
For example, on x86, the entry point is in
arch/x86/boot/header.S (I don't know of other entry points, but I'm not sure that there aren't any). The real entry point is the
_start label at offset 512 in the binary. The 512 bytes before that can be used to make a master boot record for an IBM PC-compatible BIOS (in the old days, a kernel could boot that way, but now this part only displays an error message). The
_start label starts some fairly long processing, in real mode, first in assembly and then in
main.c. At some point the initialization code switches to protected mode. I think this is the point where decompression happens if the kernel is compressed; then control reaches
arch/x86/kernel/head_*.S depending on whether this is a 32-bit or 64-bit kernel. After more assembly,
head64.c is invoked. Finally, the architecture-independent
start_kernel function in
init/main.c is invoked.
start_kernel is where the kernel starts preparing for the real world. When it starts, there is only a single CPU and some memory (with virtual memory, the MMU is already switched on at that point). The code there sets up memory mappins, initializes all the subsystems, sets up interrupt handlers, starts the scheduler so that threads can be created, starts interacting with peripherals, etc.
The kernel has other entry points than the bootloader: entry points when enabling a core on a multi-core CPU, interrupt handlers, system call handlers, fault handlers, …