How can a BIOS update affect my EFI boot?
In UEFI, each installed OS is supposed to have their own boot variable stored in the NVRAM used for firmware settings. I've seen some UEFI firmware updates cause those NVRAM variables to be lost. It should not happen; yet, you should be aware that this can happen and know how to fix it.
Most Linux distributions that are capable of booting in UEFI mode will also include the efibootmgr command, which is designed for viewing and manipulation of the boot variables. If you have a UEFI system running Linux, it would be a good idea to run efibootmgr -v as root and save the output onto some external media, or even print it. Although the missing boot variable information is usually not too difficult to figure out, having a print-out of a known-good state is extremely helpful when you need to recover.
If the problem is about update indeed, should I try to roll it back?
If the reason was that the NVRAM variables were reset to factory defaults as part of the update, rolling it back will not help: most likely returning to a previous firmware version would just cause another NVRAM variable reset.
For my problem, is it possible to repair EFI by using Arch Linux live USB? If it is, how?
Yes, assuming the live USB is booted in UEFI style, and not in legacy BIOS style. Access to UEFI NVRAM boot variables from the running OS is only possible when the system is booted in UEFI style. If the boot from USB uses legacy BIOS-style boot process, the UEFI standard interface for changing the NVRAM variables will be hidden away to maximize compatibility with the traditional BIOS.
You should first mount the EFI System Partition that contains the installed OS's bootloader to its customary location (usually /boot/efi or /boot, depending on distribution). Chrooting to the existing OS installation should also work, if the EFI System Partition is then mounted within the chroot.
Using the efibootmgr command, you can write the lost NVRAM boot variable like this:
efibootmgr --create --disk /dev/sdX --part Y --loader "\EFI\systemd\systemd-bootx64.efi" --label "Linux Boot Manager" --verbose
Note that the --loader pathname uses Windows pathname conventions and is relative to the root of the EFI System Partition. Because it uses backslashes, you must either quote the path or double the backslashes or else the shell will mis-interpret it.
The --part Y option is only needed if you have multiple EFI System Partitions on a single disk or your EFI System Partition is not the first partition on the disk.
If you can get into Windows, it can also be used to recover the UEFI boot variable for Linux. However, Nabeel Kirmani's method in another answer is slightly incomplete: it overwrites the path in Windows's UEFI boot variable with the pathname of the Linux bootloader. It might work with Windows 8.x, but Windows 10 will detect the "tampering" and will write its own value back in as an attempt to "self-heal". Instead, you'll need to create an independent UEFI boot variable for Linux:
Start a Windows Command Prompt as an Administrator.
Then run this command
bcdedit /copy {bootmgr} /d "Linux Boot Manager"
This will create a new UEFI boot variable, name it appropriately, and output a GUID string, which you will need to use in the second command:
bcdedit /set {guid} path \EFI\systemd\systemd-bootx64.efi
Replace {guid} above and in the next command with whatever was returned by the first command. This second command will configure the new boot variable to start the Linux systemd-boot bootloader instead of the Windows one.
Finally, set the new boot variable as the first one in the system boot order:
bcdedit /default {guid}
(Windows instructions from Arch Wiki.)
