Grub2 by default will install the grub2.efi where ? /boot/efi/EFI/BOOT/ or /boot/efi/EFI/GRUB2/

I'm afraid I don't know offhand; it's been a while since I did this. This page has the best GRUB 2 EFI installation documentation I know about, so you might check there and experiment yourself.

Quote:

2. How does Grub2 knows that now the /boot/grub2/grub.cfg is now inside /boot/efi/EFI/GRUB2 ?

If you mean, how do you control it, I'm not sure, offhand.

Quote:

3. Can you explain to me what is difference between /boot/efi/EFI/BOOT and /boot/efi/EFI/GRUB2 ? Why Grub2 needs a separate entry ?

The ESP's EFI/BOOT directory is where the default EFI boot loader goes (bootx64.efi on x86-64 systems). Originally this location and name was intended only for bootable removable disks, but it's become standard (and recognized in the EFI spec) as a fallback boot loader location for hard disks, too. This default boot loader doesn't need an entry in the NVRAM to work, although it's usually tried after all the other boot loaders...

Other subdirectories of EFI hold OS boot loaders that get registered with the NVRAM. When such entries exist, the pointed-to boot loaders are launched prior to the default boot loader.

Quote:

Can we create an entry with efibootmgr that point to /boot/efi/EFI/GRUB2 instead of /boot/efi/EFI/BOOT ?

Yes, that's the point of efibootmgr. If you're having problems getting that working, it indicates a bug somewhere. Some EFI implementations "forget" their NVRAM entries and/or there are problems with efibootmgr that cause it to not interface quite correctly with the NVRAM. (I've got one system like this; I need to use the default EFI/BOOT/bootx64.efi filename rather than another name registered via NVRAM.)

Yes, but if these are all directory names, you'd need to register the boot loaders within each directory with the firmware via efibootmgr (or some other similar tool in another OS). None of those directories will be scanned automatically by the firmware. (Some implementations do go looking for a file called EFI/Windows/boot/bootmgfw.efi, though.)

Basically, yes. In both EFI and modern BIOSes, the NVRAM holds information on the order in which to try various boot loaders. The difference is that in BIOS, only the MBRs of various disks can be tried, so the number of options is limited. In EFI, any file on the ESP can theoretically be a boot loader, although the convention is for these to be .efi files in subdirectories of the EFI directory on the ESP. Also, most BIOSes will auto-detect a new disk device and give you an option to boot from it, but most EFI implementations provide limited or no tools for specifying a new (unregistered) boot loader at boot time; you must register a new boot loader via one tool or another. The exception is the EFI/BOOT/bootx64.efi boot loader, which EFI systems auto-detect.

EFI also provides what it calls runtime services, which are a way for a running OS to modify EFI NVRAM settings. In Linux, you can do this manually through the /sys/firmware/efi/vars directory tree; but the efibootmgr utility provides a user interface to do this for the variables that control the order in which the firmware launches various boot loaders. Note that efibootmgr isn't involved at boot time; it just lets you adjust the boot-time settings from a running Linux system.