I have ELF kernel. So I need a bootloader that will load my 64 bit ELF file. I don't need obsolete Legacy BIOS bootloaders, I need UEFI bootloader with/without GUI.
I have ELF kernel. So I need a bootloader that will load my 64 bit ELF file.
You have an ELF kernel; so you probably need a boot loader that will:
load the kernel's ELF file
tell the kernel about the memory map
tell the kernel various things about the hardware ("flattened device tree" or ACPI tables or ...), likely including frame buffer details.
also load other files (e.g. initial RAM disk); because (even for a "modular monolithic" kernel) the kernel can't load a disk driver from disk when it hasn't loaded a disk driver from disk yet.
tell the kernel some kind of kernel configuration (could be another file, could be "kernel command line args").
who knows what else (e.g. I expect my boot loaders to set up paging and map kernel at its final virtual address; decompression is worth considering to improve boot times when disk IO is slow; doing sanity checks to see if kernel's file has been tampered with before trusting it makes sense, ...).
In other words; you need a full detailed specification about how any/all of these things happen (e.g. how kernel retrieves memory map from boot loader, which format it's in, if there's guarantees like "2 or more entries in the memory map will not describe the same/overlapping area of memory", etc); where both the boot loader (or all boot loaders) and the kernel (or all kernels) comply with the detailed specification.
"The kernel is ELF" is just a small piece of that detailed specification.
This leaves you with 2 choices:
find a detailed specification designed by someone else that happens to include "the kernel is ELF" (or at least "the boot loader must support ELF"), and adopt their specification, and then put up with all of their design decisions whether they make sense for your OS or not. The only choice here (that I know of) is the multi-boot specification.
create your own detailed specification designed for your OS; then either write your own boot loader/s or let other people write them from your specification. This is what almost every well known kernel (Windows, Linux, FreeBSD, ...) does.
Note 1: typically it's not "one boot loader", but more like a set of them (one for booting from "GPT partitioned hard disk", one for booting from network, another for booting from removable media, ...). It's possible to work around this by splitting "boot loader" into halves (many different "1st stages" that handle the differences, plus a common "2nd stage" that handles the similarities).
Note 2: For UEFI, you could just use UEFI as the "detailed specification designed by someone else" and not bother having a boot loader. In that case you'd have to either convert your ELF into PE format; or insert your ELF file "as is" inside a PE file as data (where the PE file has some code to unpack the ELF contained inside it).
Note 3: In theory it's really about environments; where "boot loader" changes from one environment (e.g. from UEFI) to another environment (e.g. to "the environment your kernel expects"); and these "pieces of code that change environments" can be layered (e.g. maybe "BIOS -> multi-boot -> UEFI emulator -> something else -> what your kernel expects").
Note 4: For the final "environment your kernel expects"; it may be worthwhile considering things like "kexec()" where a previous instance of your kernel is used to start the next instance of your kernel. This has practical benefits of its own (e.g. faster kernel updates), but the main reason to think about it is to refine the design of the "environment your kernel expects" (to help determine what the kernel actually wants and avoid introducing baggage from what other environments provide that aren't quite what your kernel really wanted).
TLDR: You'll probably end up using Multiboot2 (and GRUB). You can find the specification for Multiboot2 here: https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html