Talk:Nonvolatile BIOS memory

Article contradition

You can't call it "CMOS" memory and call it "non-volatile" at the same time. Remove power to CMOS circuitry and it loses its initial information, usually in a matter of seconds. Battery backup is not the same as NonVolatile memory. Consider FLASH or EPROM or EEPROM or PROM or other forms of memory that are much less volatile. Given time, ALL memory is volatile! --71.10.146.139 (talk) 23:59, 14 October 2013 (UTC)

Replaced by Flash?

CMOS memory can't simply be replaced with flash mem or EEPROM, because the latter are written in a different way. Since CMOS data is to be written byte for byte it's still working. However, there are certain extensions (ESCD for PCI, proprietary data, sometimes BIOS password - esp. in Notebooks) that are stored in BIOS flash (in a reserved area). But the CMOS RAM is still there. --Zac67 08:26, 31 May 2007 (UTC)

Assumptions made about the advancement of the technology have been fixed.

--Riluve 15:53, 28 March 2007 (UTC)

The article states

"Non-volatile BIOS memory refers to the memory on a personal computer motherboard containing BIOS settings and sometimes the code used to initialize the computer and load the operating system. The non-volatile memory was historically called CMOS RAM or just CMOS because it traditionally used a low-power CMOS memory chip (the Motorola MC146818, or one of its higher-capacity clones), which was powered by a small battery when the system power was off. The term remains in wide use in this context, but has also grown into a misnomer. The non-volatile BIOS storage in contemporary computers might be in an EEPROM or flash memory chip and not in CMOS itself."

BIOS is stored in a ROM chip on the motherboard. BIOS stores setup information in CMOS. You access CMOS Setup to change the setup configuration information that BIOS reads from CMOS. CompTIA's A+ exam makes this distinction. When you "flash" the BIOS, you are changing the code for the Basic Input/Output System, not the configuration information in CMOS RAM.

Wheelzz9 04:23, 26 May 2007 (UTC)

I can see several incorrect statements.

The contents of the CMOS NVRAM are typically not stored in Flash, certainly not "often", certainly not a misnomer. The CMOS NVRAM is nowadays technically a SRAM block, a part of the South Bridge chip, which can stay alive on just the lithium battery (the South Bridge has a battery "power rail" input). The same applies to the RTC block. There are other registers in the South Bridge and in the SuperIO chip that are backed by the battery - e.g. some power on/off circuitry in ATX motherboards (there's a register that remembers if the motherboard was in "power on" state, when mains power went off). This arrangement, i.e. that "CMOS NVRAM" is actually a SRAM block in the South Bridge, has been common to all Intel / VIA / AMD chipsets (including the Geode) for years. It's upwards of 95% of PC's ever made. If there is some hardware that stores "NVRAM settings" in the flash, it would be rather custom, would need quite a hack in the BIOS. I believe I've met this kind of logic on a particular odd model of an Advantech industrial motherboard, and it was more hassle than it was worth. All in all, except for occasional board-vendor-specific flash-based experiments, the CMOS NVRAM of the PC BIOS still is what it always has been.

Some of the more obscure data managed by the BIOS (hidden, "behind the scenes") may indeed be stored in the flash. Typically, those are not editable via the SETUP screen. The ESCD is an example = a table of PCI (and historically ISA PnP devices) that the BIOS has discovered on the last boot, their individual bus resources assigned/allocated. There's also the "DMI pool data", which is partly static stuff (Motherboard vendor and model, some custom strings) and partly "variable" stuff derived from devices slotted in (the names of your CPU, DIMM Vendor/model and basic parameters, possibly PCI cards etc). When the BIOS boots, it walks the ESCD and compares it to the PCI device list actually enumerated in the current hardware setup. When it finds a difference (device added or removed), or it had to change the config of the allocations due to some BIOS SETUP option being changed, it says "updating ESCD and DMI pool data". In some BIOSes, you could force this update of ESCD manually: the SETUP menu entry would be called "reset device data" or some such. In some cases, you may see side effects of this (bugs / resource collisions manifesting themselves or not), such as when you insert a new physical device (PCI board), or you enable some onboard device in the BIOS SETUP (Ethernet or USB option ROM for instance), you may get a hang/collision during POST on the very next boot (or at least some defunct option ROM), but the system may magically boot fine if you power-cycle the system once more, or after you force a reset of the ESCD data table, or if you plug the PCI boards in across several reboots in a different order in time (while keeping the same PCI slots) etc. I've also seen this happen when inserting maximum possible RAM and a fat graphical card into an older motherboard etc. (some ordering worked, some did not).

A "CMOS mismatch" means exactly a "CMOS NVRAM checksum error". There are actually multiple checksums across several areas of the CMOS NVRAM. Inserting or removing a PCI board will NOT cause a CMOS NVRAM mismatch. It may stir the ESCD/DMI pool, possibly with interesting side effects. But it will not cause a CMOS NVRAM checksum error. "Finds a device that has different settings than those recorded for it in CMOS" - that's not the way it works, AFAIK. Firstly: any PCI or ISAPnP resources are configured by the BIOS upon the power-on bus enumeration (device tree discovery) = during the POST. The bus resources, once assigned, are indeed stored in ESCD. On the next boot, they're once again assigned (configured in the devices) by the BIOS in the first place. The BIOS *could* check back in the ISAPnP and PCI config spaces, if the settings are stored intact - but I doubt that the BIOS actually does this (not much point). Even if such a check did take place during POST, it would not possibly result in a CMOS NVRAM checksum error. Obviously the raw PCI config space (= the combined set of individual devices' own config space registers) itself is NOT battery-backed, doesn't remember its state across power cycles, the PCI bus does not have a "battery power rail".

One last note on "NVRAM being actually stored in Flash": makes me wonder what's cheaper: a 24C02 Flash EEPROM or a Lithium battery? And, note that if the vendor chose to ditch the battery, he would also lose the RTC. And, if a motherboard vendor wanted to make sure that a motherboard boots even with a CMOS NVRAM checksum error detected (= battery died), the BIOS vendors provide utilities to provide your preferred BIOS defaults, and allowing you to configure the BIOS to "just go ahead" upon a CMOS checksum error (or keyboard error). Been there, done that. To an outsider, this has been relatively best accessible in AWARD BIOSes (the modbin utility), with other BIOS vendors it's more difficult to edit the BIOS defaults in the flashable image (no tools available to an outsider). — Preceding unsigned comment added by 77.104.253.227 (talk) 11:40, 3 September 2013 (UTC)

Battery

What would happen if the battery is dead?

how to find that the battery is dead? —Preceding unsigned comment added by 210.18.107.2 (talk) 16:30, 15 October 2007 (UTC)

Normally the CMOS-settings and the Time and Date are reset to default every time the system is powered off.

Some BIOSes will show an error at POST an require, that you go into the BIOS and reconfigure the settings.

Most modern BIOSes support monitoring the vbat (battery voltage), so if you don't have a replacement battery, you can use this to test, if the battery can be the reason (some motherboards have a defect, taht they "forget" CMOS-settings even w/ a fully charged battery. If you cannot read the battery voltage in the BIOS, you can maybe use a tool like CPUCool. From my ecxperience the battery voltage should always be at over 3V, althought some BIOSes may require higher voltages, i.E. my old motherboard's BIOS keeps "forgetting" at 3.26V. Generally, BIOSes of motherboards which can also use CR2025 (i.E. Epox 8RDA+) batteries and not only CR2032, will accept lower voltages, because CR2025 batteries have a Open-circuit voltage of only about 3.1V, CR2032 have about 3.3V. The rated voltage ist 3.0V for both types, but the measured voltage is much closer to the OCV, because the batteries are only under a very small load, when the PC is turned on. --Qaywsxedc (talk) 03:28, 12 February 2008 (UTC)

I personally think this whole paragraph is bullshit — Preceding unsigned comment added by 12.18.245.215 (talk) 16:35, 3 November 2012 (UTC)

Non-volatile?

Correct me if I'm wrong, but isn't CMOS volatile memory? Since it requires a battery to maintain the data, it's volatile, like RAM. Non-volatile memory maintains the data stored in it, even when powered off (e.g. flash memory, EEPROM). It functions like non-volatile memory, since it's always powered (if the battery has power), but it's actually volatile memory. 85.76.253.210 (talk) 16:05, 21 January 2008 (UTC)

Strictly speaking maybe that is correct but everyone refers to this as nvram. It is nonvolatile in the sense that the memory contents persist when you unplug the computer. 207.241.238.217 (talk) 22:02, 10 July 2008 (UTC)

Well, CMOS RAM is RAM...! "CMOS" stands for "complementary metal–oxide–semiconductor" - a way to build chips with low static power consumption, and, as you both have realized, an ordinary static RAM chip may become non-volatile with the help of some circuitry and a backup battery. HenkeB (talk) 01:45, 21 August 2008 (UTC)

Why does CMOS Setup redirect here?

This article doesn't really say much, if anything, about the CMOS setup "application" built into most BIOS firmware. This should either have a section in the page or its own article, as it's certainly notable enough. flarn2006 [u t c] time: 23:25, 8 February 2012 (UTC)

Needs total re-write

• Seems like it should be an article on BIOS memory as it tries to cover both non-volatile and CMOS systems. Currently seems to conflate the two without a clear understanding of the how both are used in a modern computer.
• Doesn't explain the history of BIOS memory well.
• Spends an inordinate amount of time on battery types.
• Riddled with inaccuracies.

smnc (talk) 18:56, 11 May 2021 (UTC)