It may occur that the NVRAM of a mainboard loses its content and as a result,
the grub bootloader cannot be started in the boot process anymore. A sign,
that this happened would be, that also the date and time of the system have
been reset and should be quite wrong in most cases.

This has happened to me and I will list the steps that I undertook to reenable
the start of grub as the bootloader for the OS still present on your drive.

The main step is step 9 from below, which adds the boot entry back to the
system but it requires some steps in advance to setup the environment to be
able to properly execute this command.
# efibootmgr --create --gpt --disk /dev/nvme0n1 --part 1 --write-signature \
--label "gentoo" --loader "\\EFI\\gentoo\\grubx64.efi" 

Prerequisite is a pen-drive with a linux installer to boot from or any rescue
CD.

When you plug this drive into the computer and start your device, you should
find yourself in the grub environment of your rescue system. If not, you need
to enable to boot from the removable USB device in your UEFI/BIOS setup.

The grub environment of your rescue CD/installer should give you any option
which is named like rescue, in my case in was a debian netinstaller with
minimal software on it, no wifi drivers, but you don't need network access for
the procedure.

1. The rescue CD should ask you which partition is the root partition of your
system. For example, if /dev/nvme0n1p1 is the EFI-boot partition,
/dev/nvme0n1p2 is the swap partition, then maybe /dev/nvme0n1p3 may be your
root partition. When it asks you for a separate /boot partition say yes, which
should be the case as described.
2. Select the command line of your installer system and check for the kernel
module efivarfs
# modprobe efivarfs
3. When you are in the command line of the installer CD system, you may still
check, whether everything on your native root partition is present as you
would expect it.
4. When the kernel versions of your rescue CD and your natively installed
linux kernels differ, you need to copy the /lib/modules directory into your
native /lib/modules directory, where target below is where the rescue CD
mounted your native system.
# cp -r /lib/modules/5.10.0-20-amd64 target/lib/modules/
5. Close this shell and use the option to enter and command line shell in your
native system. The rescue CD will take care of doing the chroot and some
directly necessary stuff. Otherwise you would need to find out which steps
need to be performed from other sources. In the chroot, also modprobe the
efivarfs
# modprobe efivarfs
6. Mount the efivarfs
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
There is no f in efivars in this last instance, but use autocompletion to be
sure or check the path manually.
7. Look at the efi boot order with efibootmgr -v
# efibootmgr -v
You should see one or two entries belonging to your rescue CD which is
currently booted.
8. Check the files in your /boot partition which should all the previously
available kernels etc, the grub directory and a directory named EFI which will
be important. Check what is inside this EFI directory. In my case, it is
another directory named gentoo and inside there is the efi file grubx64.efi
9. Create a new efi boot manager entry
# efibootmgr --create --gpt --disk /dev/nvme0n1 --part 1 --write-signature \
--label "gentoo" --loader "\\EFI\\gentoo\\grubx64.efi" 
10. Check your efi boot entries again with
# efibootmgr -v
which should list your newly created entry as well.
11. Reboot and you should be able to boot from your normal grub again, as soon
as you removed your rescue CD drive.