Universal BIOS Backup ToolKit 2.0.exe

Status
Not open for further replies.
L

Linea Recta

I have been testing the utility above for making a backup of my CMOS
settings.
I seem to have made a backup to file succesfully:
PhoenixTechnologiesLTD-M2.03A.rom
But now what can I do with it??
They seem to have forgotten to implement an option for restoring the file?

I had a look into the backup with a text editor, but it seems unreadable
crap.

Any other good suggestions for an alternative program like this?

Or do I have to resort to making photographs of all CMOS screens??



--


|\ /|
| \/ |@rk
\../
\/os
 
P

Paul

Linea said:
I have been testing the utility above for making a backup of my CMOS
settings.
I seem to have made a backup to file succesfully:
PhoenixTechnologiesLTD-M2.03A.rom
But now what can I do with it??
They seem to have forgotten to implement an option for restoring the file?

I had a look into the backup with a text editor, but it seems unreadable
crap.

Any other good suggestions for an alternative program like this?

Or do I have to resort to making photographs of all CMOS screens??

The output file size will hint at what it is for.

The thread here, implies it backs up the
entire contents of the BIOS flash chip.

http://forums.mydigitallife.info/printthread.php?t=9856&pp=40&page=1

The flash chip consists of a number of components, such
as main code block (checksum protected), DMI/ESCD (computed
and written on demand, stores hardware information), microcode cache
segment, boot block, and so on. Even when you start with
manufacturer BIOS, flash it, reboot computer once, then
run a backup of the BIOS, the file will no longer match
what you flashed in, as the DMI will have been written
by the POST/reboot. As long as you know what sections are
non-volatile, you can figure out whether it is a "match" for some
downloaded BIOS flash image.

*******

If the tool backs up the CMOS RAM, that should be very
small, like 256 bytes in total.

Paul
 
L

Linea Recta

Paul said:
The output file size will hint at what it is for.

The thread here, implies it backs up the
entire contents of the BIOS flash chip.

http://forums.mydigitallife.info/printthread.php?t=9856&pp=40&page=1


Yes, but nobody mentions the restoring proces.

The flash chip consists of a number of components, such
as main code block (checksum protected), DMI/ESCD (computed
and written on demand, stores hardware information), microcode cache
segment, boot block, and so on. Even when you start with
manufacturer BIOS, flash it, reboot computer once, then
run a backup of the BIOS, the file will no longer match
what you flashed in, as the DMI will have been written
by the POST/reboot. As long as you know what sections are
non-volatile, you can figure out whether it is a "match" for some
downloaded BIOS flash image.

*******

If the tool backs up the CMOS RAM, that should be very
small, like 256 bytes in total.


Mine is 1024 kB.



--


|\ /|
| \/ |@rk
\../
\/os
 
P

Paul

Andy said:
So it's backing up the contents of the flash BIOS program, not the CMOS
BIOS settings ...

To reflash a BIOS, you use the motherboard company provided
flashing tool. Alternatives to that, include some
third=party flashing tools (Uniflash?).

The safety of flashing a BIOS is never guaranteed. And
you need to manage the risk.

For example, my current motherboard has a socketed PLCC
BIOS chip, and I can buy a new one from Badflash if
I screw up. I might also have the option of using
a BIOS Savior, except they aren't developing products
for newer BIOS chip designs.

If the flash chip is soldered to the motherboard, it's
going to be a lot of work to escape from a bad flash update.

The Gigabyte motherboards with two BIOS chips, offer some
protection against bad flashing operations. If the boot
block only exists, or can only be access from one of the
two chips though, that reduces the chances of recovering
from a bad flash. (If the flash operation happens to
wipe out the boot block, say.)

*******

Also, you don't need to use the Universal BIOS Backup ToolKit,
because many flash tools have "-i" and "-o" options. You
can actually make a backup, using the manufacturer provided
tool. Do a "-o" run first, to do the backup. Do a "-i" run,
to flash in a new BIOS. If the flash goes wrong, immediately
do a "-i" using the archived flash file.

There is a utility for backing up the 256 byte CMOS area,
but since the definition of what is stored in there,
changes on a BIOS revision basis, the backed up
information has hardly any lasting value.

Paul
 
L

Linea Recta

Paul said:
To reflash a BIOS, you use the motherboard company provided
flashing tool. Alternatives to that, include some
third=party flashing tools (Uniflash?).

The safety of flashing a BIOS is never guaranteed. And
you need to manage the risk.

For example, my current motherboard has a socketed PLCC
BIOS chip, and I can buy a new one from Badflash if
I screw up. I might also have the option of using
a BIOS Savior, except they aren't developing products
for newer BIOS chip designs.

If the flash chip is soldered to the motherboard, it's
going to be a lot of work to escape from a bad flash update.

The Gigabyte motherboards with two BIOS chips, offer some
protection against bad flashing operations. If the boot
block only exists, or can only be access from one of the
two chips though, that reduces the chances of recovering
from a bad flash. (If the flash operation happens to
wipe out the boot block, say.)

*******

Also, you don't need to use the Universal BIOS Backup ToolKit,
because many flash tools have "-i" and "-o" options. You
can actually make a backup, using the manufacturer provided
tool. Do a "-o" run first, to do the backup. Do a "-i" run,
to flash in a new BIOS. If the flash goes wrong, immediately
do a "-i" using the archived flash file.

There is a utility for backing up the 256 byte CMOS area,
but since the definition of what is stored in there,
changes on a BIOS revision basis, the backed up
information has hardly any lasting value.


OK, first thanks for your input,

There seems confusion between BIOS and CMOS(settings) backup.
I'm not going to experiment with BIOS versions because of the risk.
Besides that I already have the latest version except for a beta.

So I just wanted to backup my settings. I was already making photo's, when I
saw the options under tools in the BIOS setup.
I found it pretty hard and clumsy to operate these menus, but I suppose it
is me beeing clumsy.
After I dared pressing "profile" I got a sub menu which indicated I have
options to backup and restore CMOS settings.
That's what I needed!
Only to FAT formatted media, so I used an 1.4 floppy for this.

(CMOSBKUP.CMO 1 kB.)

The other option seems to be for backing up the BIOS program itself, so
while I was at it I copied that to the floppy too.

(A0903-00.ROM 512 kB.)

So after all I don't need other utilities for my Windows 7 (Asus) PC.

However, I would like to achieve the same for my notebook, and I don't thing
it has this sort of options in the BIOS setup.
I'll be looking into that shortly.




--


|\ /|
| \/ |@rk
\../
\/os
 
P

Paul

Linea said:
However, I would like to achieve the same for my notebook, and I don't
thing it has this sort of options in the BIOS setup.
I'll be looking into that shortly.

"Profile" capability is usually reserved for higher end
motherboards. I only have one motherboard here that can
remember a profile. The rest don't have the profile thing.

Some motherboards can record as many as four profiles.
Presumably for overclockers who do a lot of experiments.

Saving the CMOS (or using a Profile for that matter), they
don't usually work with a BIOS update. So if your BIOS goes
from 3.7 to 3.8, that invalidates your 1KB recovery file.
They don't seem to be able to keep a definition for
the non-standard CMOS locations, from one release to the
next. (Just as they change the boot block willy-nilly,
when the boot block is supposed to be "constant" for the
life of the product.)

The CMOS is typically 256 bytes in the Southbridge. The upper
128 bytes are completely non standard. Only the first bit
of the lower 128 bytes, have defined functions, established
many years ago. There is a web page, that documents that
stuff. The lower area has a checksum, the password storage
area has its own checksum. I don't think I've seen any
info on how a modern motherboard uses that area, or what
percentage of the 256 bytes is now in usage.

The archived CMOS values, come in handy if you change
the CR2032 coin cell. If the battery has a residual charge,
you might not need your archived settings, and you can swap
the battery fast enough to not lose anything (a capacitor on
the VCC3 line could save enough charge to hold
the settings). If the battery is completely flat (zero volts),
then you'll need some help.

My laptop has only one setting in the BIOS (AHCI or IDE),
so you don't need an extensive photo album for that one :)

Paul
 
L

Linea Recta

Paul said:
"Profile" capability is usually reserved for higher end
motherboards. I only have one motherboard here that can
remember a profile. The rest don't have the profile thing.

Some motherboards can record as many as four profiles.
Presumably for overclockers who do a lot of experiments.


I believe I can save two profiles, but I only saved one for the time being.
I never practise overclocking.
However, it takes me some exercise to get used to the BIOS tools interface.
I'm very wary when investigating this sort of menu options. It isn't always
clear whether there are sub options, or whether it gallops ahead doing
something irreversible!

Saving the CMOS (or using a Profile for that matter), they
don't usually work with a BIOS update. So if your BIOS goes
from 3.7 to 3.8, that invalidates your 1KB recovery file.
They don't seem to be able to keep a definition for
the non-standard CMOS locations, from one release to the
next. (Just as they change the boot block willy-nilly,
when the boot block is supposed to be "constant" for the
life of the product.)


I'll try to keep that in mind to always also save new profile after a new
BIOS update.

The CMOS is typically 256 bytes in the Southbridge. The upper
128 bytes are completely non standard. Only the first bit
of the lower 128 bytes, have defined functions, established
many years ago. There is a web page, that documents that
stuff. The lower area has a checksum, the password storage
area has its own checksum. I don't think I've seen any
info on how a modern motherboard uses that area, or what
percentage of the 256 bytes is now in usage.


I assume that passwords are also in the CMOS backup?

The archived CMOS values, come in handy if you change
the CR2032 coin cell. If the battery has a residual charge,
you might not need your archived settings, and you can swap
the battery fast enough to not lose anything (a capacitor on
the VCC3 line could save enough charge to hold
the settings). If the battery is completely flat (zero volts),
then you'll need some help.


I never understood why the don't use some rechargeable battery connected to
the mains (even when the system is down). I suppose it all about $$$.
My laptop has only one setting in the BIOS (AHCI or IDE),
so you don't need an extensive photo album for that one :)


Yes, mine also has very few options. I'll reexamine that ASAP.
Ciao.


--


|\ /|
| \/ |@rk
\../
\/os
 
P

Paul

Linea said:
I assume that passwords are also in the CMOS backup?

Yes, and you never know, they might be stored in plaintext.
I never understood why the don't use some rechargeable battery connected
to the mains (even when the system is down). I suppose it all about $$$.

Someone brought this topic up a while back. There are
devices that use a LR2032 instead of a CR2032. The two
are not interchangeable. (You cannot charge a CR2032, and
the motherboards uses low leakage diodes in that area
of the circuit board.)

http://www.batteryjunction.com/lir2032----.html

The LR2032 is rechargeable lithium.
The amp-hour rating is pretty low. If the product is
unplugged for just a few days, the coin cell can run
down to zero. The LR2032 is practical (in say a laptop),
as long as the user doesn't leave the laptop with no
main battery pack in it.

If you have an electronics product that already
uses one of those, then you can buy a similar
type if it ever needs to be replaced.

It just doesn't seem all that practical, to me.

Paul
 
L

Linea Recta

Paul said:
Yes, and you never know, they might be stored in plaintext.


Someone brought this topic up a while back. There are
devices that use a LR2032 instead of a CR2032. The two
are not interchangeable. (You cannot charge a CR2032, and
the motherboards uses low leakage diodes in that area
of the circuit board.)

http://www.batteryjunction.com/lir2032----.html

The LR2032 is rechargeable lithium.
The amp-hour rating is pretty low. If the product is
unplugged for just a few days, the coin cell can run
down to zero. The LR2032 is practical (in say a laptop),
as long as the user doesn't leave the laptop with no
main battery pack in it.

If you have an electronics product that already
uses one of those, then you can buy a similar
type if it ever needs to be replaced.

It just doesn't seem all that practical, to me.


Deaming further on about this while driving my car today, I wondered
wouldn't it be better if they used a non-volatile memory, something like an
SD card, for keeping all the settings, and perhaps also the BIOS code
itself? No current of any sort needed to keep the information available?




--


|\ /|
| \/ |@rk
\../
\/os
 
P

Paul

Linea said:
Deaming further on about this while driving my car today, I wondered
wouldn't it be better if they used a non-volatile memory, something like
an SD card, for keeping all the settings, and perhaps also the BIOS code
itself? No current of any sort needed to keep the information available?

Absolutely. The current practice is "barbaric" :)

*******

But consider that, they want to run a real time clock, even
when the computer is not powered. So the computer always
has a local time_of_day reference for stamping file
system entries. The computer must "work properly", with
no network connection to use NTP protocol.

An RTC draws around 2 microamps, if implemented in the
Southbridge. You need the battery, to power that clock
time piece. The clock runs off a 32768 Hertz quartz crystal
(just like your digital watch), and will drift a bit in
terms of time keeping. (It's not "atomic clock" quality
in any case.)

Adding the 256 bytes of RAM, doesn't change things
all that much. The total power is 10 microamps,
with both RTC and CMOS RAM. Part of that is likely
to be "CMOS well" transmission gate leakage, through the
stuff that prevents the battery powered portion of
the Southbridge, leaking into the larger part of the chip.
If transmission gates were not used, for electrical isolation,
current from the CR2032 would "leak" into the rest of the
Southbridge, and the battery would drain in no time. The usage
of transmission gates, helps make this "chip emulation" inside
the Southbridge a practical possibility. Where the letter "T"
is like a moat, they "lift the drawbridge" so the little
island stays electrically isolated, when the computer
is powered off. When the chip is fully powered, the OS
reads the registers of the RTC, via some sort of
transmission gate protected path.

+--------------------------------------+
| Southbridge - SATA, PCI, LPC I/O etc |
| |
| | | | | The letter "T" is
| T T T | where transmission gates
| | | | | for I/O, are located.
| +----------+ |
| | RTC and |--------------------------- CR2032 3V power
| | CMOS RAM |--------------------------- 32768Hz crystal
| +----------+ |
| |
+--------------------------------------+

The end result, with a CR2032, is you can power that
time piece (and the 256 byte RAM sitting next to it),
for about three years with no AC power.

So if we replaced the 256 byte RAM with 256 bytes or
NOR flash, we still need a clock function, we still
need a battery, and the battery lasts a bit longer.

At one time, this function was a separate chip, and
the emulation that puts it into the Southbridge,
is intended to make PCs cheaper to build. You might
have had a Dallas chip in really old PCs. And the problem
with the old solution to this problem, is the entire
Dallas chip needed to be replaced, when the internal
battery in the chip went flat. At least the battery
is easy to replace now. Dallas used to pot the whole
thing in epoxy, so you couldn't repair it. It was
"Dremel time", for the people who used to retrofit
an external battery to their Dallas.

http://classic-computers.org.nz/blog/2009-10-10-renovating-a-dallas-battery-chip.htm

Paul
 
G

Gene E. Bloch

Deaming further on about this while driving my car today, I wondered
wouldn't it be better if they used a non-volatile memory, something like an
SD card, for keeping all the settings, and perhaps also the BIOS code
itself? No current of any sort needed to keep the information available?

The BIOS code is in non-volatile memory. It *has* to be...
 
P

Paul

Gene said:
The BIOS code is in non-volatile memory. It *has* to be...

True in the most general sense. But there are details
as to how the BIOS chip is used. It's not "read-only" in the
way you might think. The DMI/ESCD area can be updated
during POST.

Paul
 
G

Gene E. Bloch

True in the most general sense. But there are details
as to how the BIOS chip is used. It's not "read-only" in the
way you might think. The DMI/ESCD area can be updated
during POST.

Paul

I don't recall saying read-only...nor thinking it.

In fact, in my post I intentionally didn't talk about BIOS updates,
which, IIRC :), involve *writing* to the BIOS's non-volatile memory,
since I saw it as irrelevant to the remark I made.

Many[1] BIOSes do have read-only portion(s) which contain, among other
things, the firmware needed to update the BIOS firmware itself.

[1] It's now 2014. That probably should read *all*, not *many*,
BIOSes...
 
P

Paul

Gene said:
True in the most general sense. But there are details
as to how the BIOS chip is used. It's not "read-only" in the
way you might think. The DMI/ESCD area can be updated
during POST.

Paul

I don't recall saying read-only...nor thinking it.

In fact, in my post I intentionally didn't talk about BIOS updates,
which, IIRC :), involve *writing* to the BIOS's non-volatile memory,
since I saw it as irrelevant to the remark I made.

Many[1] BIOSes do have read-only portion(s) which contain, among other
things, the firmware needed to update the BIOS firmware itself.

[1] It's now 2014. That probably should read *all*, not *many*,
BIOSes...

You could draw it like this. For a legacy BIOS.

+-------------------------------------+
| Main BIOS code
| Many separate code modules
+--
| (Read Only, except on a BIOS update)
+--
| Checksum protected
+--------------------------------------+
| Microcode Cache
| (Read Only, except when updated
| by the insertion of a new processor)
+--------------------------------------+
| DMI/ESCD
| (Read/write, in the presence of
| POST detected hardware changes,
| or user updates with Intel utility)
+--------------------------------------+
| Boot Block
| (Should really be read-only, but
| frequently gets updated on a BIOS
| upgrade.)
+--------------------------------------+

The BIOS main code, is mirrored in RAM. This
allows updates to the Flash chip, without
concern for whether the code is being used
right now.

The chip has erasable pages, so the whole device
doesn't have to be erased, to update a small area.
The size of the pages, helps define the boundaries
of the smaller areas. Maybe the boot block is 8KB,
the Microcode Cache 2KB, and so on.

The bytes in the main code area are compressed. If
you intended to disassemble the code, you need to
decompress it first. It's a lot easier to read
that way, and has give-away text strings in it.

The boot block on the other hand, is less likely
to be compressed. It's probably got a decompresser,
or knows where to find one. I've never attempted
to do anything with a boot block, so haven't a clue
how it is structured. I've taken apart a number
of main BIOS code blocks, for a quick look.

The UEFI BIOS is much more complicated than this,
and one article I was reading hinted at as many
as 200 files being present inside. And the UEFI BIOS
also offers some sort of access to the file system,
when the OS is running. I haven't really found any
good tutorial articles, on just how exposed to exploits
a UEFI BIOS might be. It sounds complicated enough, to
be a disaster area waiting to happen.

Paul
 
K

Ken Blake

The BIOS main code, is mirrored in RAM. This
allows updates to the Flash chip, without
concern for whether the code is being used
right now.


Interesting, thanks! I never realized that before.
 
P

Paul

Ken said:
Interesting, thanks! I never realized that before.

https://web.archive.org/web/20000831124455/http://www.pcguide.com/ref/ram/umaShadowing-c.html

"One problem with ROMs such as those used for the
system BIOS and video BIOS, is that it is relatively slow."

"I'm sure you can see where this is heading. Since there
is RAM hiding underneath the ROMs anyway, most systems have
the ability to "mirror" the ROM code into this RAM to
improve performance. This is called ROM Shadowing, and is
controlled using a set of BIOS parameters. There is normally
a separate parameter to control the shadowing of the system BIOS,
the video BIOS and adapter ROM areas."

The details have likely changed with time. Partially, because
the Flash chip is larger than it used to be. There is certainly
lots of RAM to go around, but the archaic usage rules (and
backward compatibility), kinda handcuff things. Maybe my first
motherboard, is guaranteed to have that feature.

And the comment about "relatively slow", still applies. The
current generation of 8 pin serial flash chips, are no
speed demons. Moving from a byte wide interface to a
serial interface, did not help matters.

One of the slowest flash ever put on a motherboard, was
the Asus "bitching betty" vocal error reporter setup. It
used a serial chip to hold canned vocal error messages.
It would take somewhere around 20 minutes to half an hour
to reprogram one of those. The BIOS Flash chip is faster
than that, by quite a bit.

Paul
 
J

J. P. Gilliver (John)

In message <[email protected]>, Paul <[email protected]>
writes:
[]
But consider that, they want to run a real time clock, even
when the computer is not powered. So the computer always
has a local time_of_day reference for stamping file
system entries. The computer must "work properly", with
no network connection to use NTP protocol.

An RTC draws around 2 microamps, if implemented in the
Southbridge. You need the battery, to power that clock
time piece. The clock runs off a 32768 Hertz quartz crystal
(just like your digital watch), and will drift a bit in
terms of time keeping. (It's not "atomic clock" quality
in any case.)
[]
It certainly isn't; it is highly likely to use a 32768 hertz* crystal
that was indeed designed for the digital watch market; such crystals are
designed to run at a fairly constant temperature (strapped to your
wrist!), so drift quite a bit in a cold PC case. Only relatively - I
doubt more than a few seconds a day in practice - but more than when
used in a wristwatch, and certainly more than the PC when it's turned on
and getting reasonably regular timechecks over the 'net.

* ISTR reading somewhere that the SI units, when written out in full
(hertz, joule, newton, watt etc.) _don't_ take a capital letter;
obviously if you're talking about the person they're named after, they
do. Also, the SI _abbreviation_ - Hz, J, N, W - may be capitalised. (I'm
trying to think of one where the abbreviation/symbol _isn't_, but the
only one I can think of is gram[me] [symbol g], and I don't think that
one's named after anyone.)
 
K

Ken Blake

I'm
trying to think of one where the abbreviation/symbol _isn't_, but the
only one I can think of is gram[me] [symbol g], and I don't think that
one's named after anyone.)


If you pronounce her name the way my wife does, perhaps it's named
after Martha Graham.
 
G

Gene E. Bloch

the SI _abbreviation_ - Hz, J, N, W - may be capitalised. (I'm
trying to think of one where the abbreviation/symbol _isn't_, but the
only one I can think of is gram[me] [symbol g], and I don't think that
one's named after anyone.)

Actually, it's named after by grandmother, whom we called Gram.

Her husband was Gramps, but I don't know of any unit named after him.
 
G

Gene E. Bloch

I'm
trying to think of one where the abbreviation/symbol _isn't_, but the
only one I can think of is gram[me] [symbol g], and I don't think that
one's named after anyone.)

If you pronounce her name the way my wife does, perhaps it's named
after Martha Graham.

My bad - I should have read your reply before posting mine.

But great minds and all that :)
 
Status
Not open for further replies.

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top