No energy on CMOS battery always reset UEFI

Hi! I've a H170M-ITX/DL ASRock motherboard, with last firmware version (at this time 7.10) and it's with problem in CMOS battery connection. I've made a lot of tests like change the battery, check with multimeter, try to boot outside the case, without disks, one memory, all firmware versions etc. No way, every time the power cord is disconnected the UEFI settings are reset.

I've read forums and saw problems like that. Tried other solutions, but no one worked. So, I'm really convinced that the problem is that the board is not being powered by the CMOS battery. I don't know why. I've tried softwares that read VBAT but shows 0.00V.

Anyone could make some suggestion?

And, the second doubt.

I'm a dual boot user with Windows 10 and Ubuntu Linux. Every time the firmware got reset it starts to boot, stop on the screen saying the clock is wrong, F1 is pressed and then a reboot occurs. This procedure saves default UEFI settings and on the next boot the firmware uses that settings.

I've a ESP partition with three directories: Boot, Microsoft and ubuntu. The Boot directory is the fallback EFI system with the bootx64.efi file. Microsoft has the Windows 10 bootloader and ubuntu has de Linux bootloader (grub).

Using the default settings saved when I press F1, Windows bootloader is ALWAYS put as the first option.

Anyone could explain why the firmware always put Windows as the first UEFI boot option?

I would like to use ubuntu one (that is the grub system so I can boot both Linux and Windows). I've already tried to replace de Boot fallback directory with one generated by Grub. It was replaced, but the firmware doesn't use it. I think as it found others EFI boot entries (Microsoft and ubuntu), so it doesn't use the fallback anymore. But, Windows is always the first one.

I've tried reorder the partitions, rename some directories, but the ASRock firmware always put Windows as the first EFI option. Why? How the order of the ESP entries are considered to generate the UEFI boot order when no config exists in the firmware? This is my scenario every time the power cord is disconnected.

avellma wrote: Try this page and deep dice further. https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how-does-that-actually-work-then/ and for background that you might know already bit just in case https://www.howtogeek.com/175649/what-you-need-to-know-about-using-uefi-instead-of-the-bios/

Thank you for the contribution. The first link is really a detailed explanation. I've read it before these tests that I did. As this tutorial says

"The UEFI boot manager is a firmware policy engine that can be configured by modifying architecturally defined global NVRAM variables. The boot manager will attempt to load UEFI drivers and UEFI applications (including UEFI OS boot loaders) in an order defined by the global NVRAM variables."

The firmware can also (it fact the spec requires it to, in various cases) effectively 'generate' entries in this boot menu, according to the disks attached to the system and possibly some firmware configuration settings.

So, in my case that the motherboard hasn't a working CMOS battery, NVRAM is always erased. Any change made with any tool are always lost. The second statement tell about the firmware generate entries in boot menu. That is the point that I would like to know. How ASRock firmware generate the boot menu entries?

I don't know if it will be possible. I think this is more a firmware code issue, how it was written. But it is curious why Windows always stay at the first position.