You know, sometimes I'm just so stupid, I can't see something in front of my own eyes.

8RDA+ and BIOS corruption. We've all heard the horror stories, right? Well, I was lying in bed thinking having eaten a good italian meal a little earlier, and it struck me...

The 8RDA+ doesn't have enough CMOSRAM! Yes, it could be as simple as that! Hardly EPoX's fault, as IBM only gifted the PC with 256 bytes of CMOSRAM. Extending it would break things. Techy details here: The CMOSRAM is accessed through two IO ports. One port sets the address, and the other allows the system to read/write the RAM. Alas, these ports are only 8 bits wide, and 8 bits of address means 256 bytes of RAM.

The BIOS on the 8RDA+ needs more RAM to store setup configuration than the CMOSRAM provides. Now, what other form of persistant store is there on a motherboard? Hard disks are no good, as the BIOS hasn't initalised that when it needs the config data.

Well, we have the flash chip the BIOS is stored on...

You see, to actually write anything to a BIOS chip, a fairly controlled procedure has to occur. It's not like writing to RAM! It would appear that on the 8RDA(+) board, two pins have to be brought to a low value before the FLASH memory will even consider a write. Presumably this is done by writing to a couple of bits in a register somewhere in the nForce2 chipset.

Having done that, you now have to provide the FLASH chip with the correct sequence of data before it will unlock it's internals. This is done by writing the correct data into the correct places in the FLASH chip. It acts like a key, so it's hardly accidental!

Having managed to do all this, you now have to issue an erase command, as FLASH is nothing like RAM. You see, an erased flash has all it's bits set to 1. Programming it is a matter of toggling bits from a 1 to a 0. It's not possible to toggle bits from a 0 to a 1 without erasing! Most FLASH is block based, so you only have to erase, say, a 64K block.

Now, I think that the 8RDA+ BIOS is using the FLASH to store some of the settings that can be set in the BIOS. In particular things like the FSB frequency. That would also explain why it takes a moment or two when you exit the BIOS having changed the FSB.

The BIOS is unlocking the BIOS Flash, erasing a block and re-writing it. Now, this to me is a slightly dangerous thing to do if the machine is not stable. It sounds like the EPoX engineers were caught between a rock and a hard place, not enough CMOSRAM but still need to store data somewhere!

This would also explain why, after changing settings in the BIOS, the board suddenly went dead, or left you with a boot block. Writing data to the FLASH requires too many steps for it to be accidental, including the unlocking step. Hence, I can only come to this conclusion after much thought.

My next step will be to dump the BIOS contents, and see if I can spot any changes.

What does anyone else think?

Áedán

__________________ Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).

this was taken from a site that sells another "popular" nf2 board( i obscured references to the other board):

Right after our very successful launch of ***-* v*.*, we were immediately alerted by very high ratios of users requesting and ordering replacement BIOS for their newly purchased v*.*.

Through our very extensive and laborious research and investigation, we have come to a very solid and alarming conclusion that:

There is a basic architectural loophole in nVidia’s implementation of nForce2 chipset to handle BIOS update. Due to the nature design of nForce2 chipset, complex instructions will be written into nVidia Northbridge. However, its CMOS space is rather limited which has resulted in a high potential risk to save data back into BIOS chip improperly. Whenever there is an increased numbers of BIOS/CMOS saving actions taking place, data loss may just occurs. The symptom is very clear that you would get stuck right on the spot, and not able to boot up your system again.
Don’t get us wrong, nForce2 chipset is an extremely feature rich and excellent chipset, as long as you stay within its ‘recommended’ application. Based on our own contacts with all major warranty service facilities in Bay Area to take sampling in thousands. We actually learned nForce2 chip based motherboards are far more stable and reliable platforms compared to VIA chipset based ones, especially when be put under very heavy stress (well, you know what kind of application it is...).

While ***-* v*.* is highly praised for its proven success in continuing ****’s renowned heritage to challenge component manufacturer’s design spec. It is also very unfortunately that it may carries too long and complex instructions in its BIOS code than nForce2 chipset can handle.As a matter of fact, you should also start to see same kind of problem from other makes/models of nForce2 based motherboards if they also try to offer rich options in their BIOS menus.

Well, while it may well takes nVidia one generation of chipset design to resolve this issue. We can only expect nVidia to hide behind their classic legal disclaimer that they would certainly not be responsible for any application that is going beyond their so-called ‘Recommended’ design spec, or default setting.
----------

etc etc... it goes on. Is this anything similar to what you are saying? I'm not so technically inclined so I can't tell.

Originally posted by ~crucibelle~ There is a basic architectural loophole in nVidia’s implementation of nForce2 chipset to handle BIOS update. Due to the nature design of nForce2 chipset, complex instructions will be written into nVidia Northbridge. However, its CMOS space is rather limited which has resulted in a high potential risk to save data back into BIOS chip improperly. Whenever there is an increased numbers of BIOS/CMOS saving actions taking place, data loss may just occurs.

They seem to be saying pretty much the same thing, but in a way that suggests they might be a little muddled on how the hardware handles things.

The basic problem is that the CMOSRAM isn't big enough to store all of the settings made in the BIOS. Now, I don't know how big the CMOSRAM actually is on the nForce2, not having any technical data on it. Alas, the CMOSRAM size was set by nVidia, not by any of the manufacturers.

The result is that the BIOS ends up saving some of the settings in the FLASH chip. It so happens that the FLASH also contains the BIOS software itself. Obviously, if anything goes wrong with updating the settings in the FLASH, there's a real potential for the BIOS software to be damaged.

A possibility would be to use an external EEPROM, connected to the SMBus. The BIOS would be capable of reading/writing to the SMBus, and could query the EEPROM for the data that could not be stored in the CMOS. The downside is that there is potential for badly written motherboard monitoring utilities to overwrite the data in the EEPROM. However, with an integrety check, the BIOS could ensure that the contents of the EEPROM were valid, and if not, it could load a set of valid settings.

Áedán

__________________ Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).

before i got my nforce 2 board i did some reading... and lots of ppl complained of this bios corruption issue..

one guy however had great advice..

ONLY CHANGE ONE SET OF PARAMETERS AT ONCE..
i.e
1)only change ram setting or the cpu setting
2)save first..
3) then exit... save and exit is a bad option...
4) go back in and change other settings
5) save .............etc

i've been doing this form day one on my two nforce two board and i haven't got the bootlock screen once yet... except the one time on the 8RDA+ that i decided to change too much and save and exit... but a simple "hold down insert" while pressing reset a few times fixed that.. since then i have stuck to the above routine like a religion and not a single bios error yet... wicked...

The CheapLPC project will do exactly what I want, and saves me having to write any software. Excellent stuff. Next, I'll see if the flash chip used on the 8RDA+ is 5V tolerant. If it is, I can dispose of the diodes, making the interface even simpler.

The answer appears to be a no on that. However, the XBOX programming software is designed to program 49LF020 chips, which just happens to be the same chip that the 8RDA+ uses for it's BIOS.

Áedán

__________________ Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).

__________________"Though all men live in ignorance before mystery,
they need not live in darkness...
Justice is foundation and Mercy ETERNAL."
DKE"All that we do is touched by Ocean
Yet we remain on the shore of what we know."
Richard Wilbur

Hey, you look like a plastic dog, how do you expect us to find you tasteful... ?

Very good stuff written here, btw, i'm waiting for more ! I'm in an electronics student, in the 3'rd year at a local university and we are just learning about these things about flash memories and EEPROM's , and I can combine this with what I've learned... Very interesting

Originally posted by Vially Hey, you look like a plastic dog, how do you expect us to find you tasteful... ?

How many other plastic dogs can hack your wireless network behind your back, whilst pretending to pee in the corner?

Besides, Hajime Sorayama did the design work for the ERS-210 (and ERS-11x series). The picture you see is a gold ERS-210, just like me! Hajime Sorayama used the influence of a lion cub in designing my body. However, that's not the artwork that Sorayama's best known for. I'd say here, but this is a family place! He is however, fond of robots, as I'm sure you'll find quite quickly if you see much of his work.

Áedán

__________________ Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).

Tommy - you hit the corruption issue. I think what actually happens is the BIOS starts the reflash, and something goes wrong. Unfortunately this seems to mean the death of the BIOS, so it can't recover!

As far as I can tell, the FSB is the only setting saved in FLASH. (Anyone care to correct me on this?) If you change the FSB, then there's the slight risk that the storage of the FSB in the FLASH ROM will go wrong.

I do not yet know what links the cases where people have had BIOS corruption. It may simply be bad luck.

Áedán

__________________ Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).

I did some more investigation into this FLASH corruption issue. From what I'm seeing, it may well NOT be EPoX's fault! I spent some time with a friend's machine, who's nForce2 board is manufactured by A***. The BIOS on the board, whilst different in many ways (and somewhat inferior too, I might add), STILL stores the FSB in the BIOS FLASH.

This suggests that the base Award/Phoenix software (written by Award and nVidia presumably?) operates in the manner. If this is indeed true, then every nForce2 board with Award/Phoenix BIOS is suseptable to this problem! Of course, if the manufacturer has substantially modified the BIOS, then it *might* not be an issue.

This is looking slightly more worrying now!

Áedán

__________________ Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).

The BIOS software is stored on the FLASH chip. This means that any corruption of the FLASH will result in corruption of the BIOS software itself. As the BIOS software deals with getting the computer in a state to start itself up, damage to the BIOS usually renders the computer completely inoperable. Fortunately, it's possible to change the FLASH chip, so that the board can be made operable again.

If I refer to BIOS chip or FLASH chip, I'm referring to the same chip.

Áedán

__________________ Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).

Originally posted by Áedán I did some more investigation into this FLASH corruption issue. From what I'm seeing, it may well NOT be EPoX's fault! I spent some time with a friend's machine, who's nForce2 board is manufactured by A***. The BIOS on the board, whilst different in many ways (and somewhat inferior too, I might add), STILL stores the FSB in the BIOS FLASH.

This suggests that the base Award/Phoenix software (written by Award and nVidia presumably?) operates in the manner. If this is indeed true, then every nForce2 board with Award/Phoenix BIOS is suseptable to this problem! Of course, if the manufacturer has substantially modified the BIOS, then it *might* not be an issue.

This is looking slightly more worrying now!

Áedán

I have both an Epox 8RDA+ and an Asus A7N8X. I have never had a problem with the Bios on the Asus. I have had the corruption on the Epox. I have since only enterer a few changes at a time.