My Alienware Area 51 R2 PC is not POST'ing. It's giving me a 1 beep beep code after power on and will not POST. I believe the BIOS may be corrupted causing the system to not POST. I have tested the CPU, VGA and RAM. They all work on another system. I tried to reflash the BIOS using a raspberry pi with the BIOS downloaded here: https://www.dell.com/support/home/ca/en/...nware-area51-r2 but I am not getting much luck. Now the system will won't POST and now it doesn't even beep. Is there special configuration for the downloaded BIOS before I flash it?

Any help would be appreciated, thanks!

@Beepbeep - Did you dump the BIOS with programmer before you wrote to it? If yes, please upload the file and post a link, so I can grab your system details from it. If you did not make a backup, then all lost for now
You cannot write BIOS from Dell with programmer, give me a few minutes and I will see if I have a file already you can use, if not I will try to make one for you * I checked, don't have, only have the Area51 (no R2) so give me a little bit and I'll see if I can do for you.

Hello, I did dump the ROM before I tried to program it. I don't have access to the flash drive that I copied the file to at the moment but I should be able to upload the files in a few hours after I get home. I extracted the A14.bin file from the BIOS installer and checked the dumped ROM with the .bin downloaded and they seem to match in terms of structure. UEFItool also shows the same for both the dumped ROM and the downloaded .bin (I had to paste over the DPK and service tag from the dumped ROM with a hex editor). I noticed there were big sections on the downloaded .bin image that's FF filled while the dumped ROM has nvar filled with data. Not sure if that's where the problem is.

@Beepbeep - OK, good you have backup, so you can restore asset tag, serial, LAN MAC ID. a14.bin from the exe needs edited before you can use in programmer, it has duplicate ME entries and is too large due to that (Dupe at end, see the "Padding" after BIOS region).

Dumped rom's NVRAM you'd want to carry over too, either via extract that entire GUID with UEFITool NE and then replace entire GUID with regular UEFITool, or copy/paste via hex or a mix of those two.
That's where your system specific details will be, or they may also be in the first padding in the BIOS region, or the second padding below the FIT entries (I doubt they'd be here, but sometimes there is a DMI section in the FIT file)

Here is bin for you, since you are familiar with editing stuff from what you mentioned, all you need to do is put your system specific details back in (likely that first padding in BIOS region if not in NVRAM, extract with NE replace with regular UEFITool)
You should make two test one without your NVRAM copied in and another with (in case something in there is messed up in NVRAM)
http://s000.tinyupload.com/index.php?fil...433382313322913

Thank you very much. I will give this a try and let you know in a few hours!

You're welcome and good luck, you can do it!!

Hello, just a quick update. I managed to correct the BIOS with your hints. The system is alive again. Thanks again!

You're welcome, and it's great to hear your Alien is alive and running again!

Sorry to reopen an old thread. I have the same system Alienware Area 51 R2, the system wont post after doing all the basic tests. It happened after running the Alienware command center maintenance, it requested a system reboot, I got a alert "system overclock failed and the bios needs a reset press F2" I was not messing with any overclocking at the time. after pressing F2 the system never came back up. I have a usb ch341a with chip clip, so I'm looking for some help to see if I can get the system backup. I am going to attempt to read the chip and get a dump, but after that I will be lost on what I need to do. I have downloaded the file @Lost_N_BIOS posted above.

@RiggsUSA - here is guide on using CH341A - [GUIDE] Flash BIOS with CH341A programmer
And here is general software package, install driver first and you only need to install it once - http://s000.tinyupload.com/index.php?fil...695330485827902

Do not use any files from here, they are specific to that users board, if you use those you will loose your serial, UUID, and possibly MAC ID too.

Dump both chips if there is two, send me the dumps and tell me each BIOS chips ID (read off the chip, not from software). Then wait, DO NOT erase or write anything!

I'm trying to get the dump and the chip to verify at the minute, so far they are not matching, I Have the chip clip connected and also the power to the system (not turned on) as that is the only way I can get the programmer to read the chip. Using programmer V1.29. The chip is a Winbod 25Q128FVSQ with 1602 under the model number. I'm using a MacBook Pro and USB-C dongle, so I've set up parallels with windows 10 for programming the chip. I assume once I get a verified copy I just post the dump to a file share and send link

@RiggsUSA - For W25Q128FV - From past experience with this chip - MX25L12873F use 1.31Free/1.40, ASProgrammer 1.4 or 1.41, or CH341A v1.1.1.32
Inside this package is 1.31Free/1.40 - http://s000.tinyupload.com/index.php?fil...695330485827902
ASProgrammer - https://github.com/nofeletru/UsbAsp-flash/releases/ << I'd use this first
I also know from others posting, this one works too - CH341A v1.1.1.32 (Post #12) - [Help] Flashed stock Bios on Aero 15, now it won't post

Then you should get read/verify = ch9ip and buffer match, then you can save and send to me.
Unless Mac/USB-C is causing issues as well (1.29 will fail, so that is expected), but I don't know about USB-C and virtual machine use, if that will also cause problems or not

After some trial and error I now have it reading the chip again one of the drivers I tried made it stop working. I assumed it would be fast at reading from what I have read but so far its taking around 11 to 15 minutes at a time. I'm tying out ASProgrammer. I got some dumps last night but did not verify them so they could be bad.
--------------------

I did two dumps the first https000.tinyupload.comindex.phpfile_id=38328684974799831488 is using ch341a programmer that worked and verified, the second http://s000.tinyupload.com/index.php?fil...919875733933655 is using ASProgrammer 1.4.1 I could not find a way to verify that one.
----------------------

Sorry just noticed that first link is messed up here it is http://s000.tinyupload.com/index.php?fil...684974799831488

@RiggsUSA - There is only one driver, it's included in the first linked package I posted above, install it once and that is all, for all programs. Some chips are very slow, some fast (2-4 minutes, depends on size as well), also depends on if power is connected to the board or not sometimes too.
Never make any dumps without pushing verify, otherwise waste of time. Sometimes verify is waste of time too, if incompatible software version or not good ID (Known working ID) is used, it can give you false verification (of it's false read)
Verify IC in ASProgrammer is the box with green = sign next to it, not the drop out arrow there, just click the = sign

If you send me anything else, please zip/rar with max compression, thanks
Looks good, both files = hex match, so since you verified one at least, it should be good!

BIOS A14, so it wasn't a forced windows update or anything, weird how it told you that about the overclock, not sure what "Alienware Maintenance" messes with but it's odd to have this happen from software and BIOS didn't update
BIOS is a hex match for all volumes/padding etc except for windows key and NVRAM area (so issue is in NVRAM, difficult to fix easily and maintain system specific details). So this will take at least two, maybe three programmings, sorry!
First, I would like you to test a BIOS with one copy (backup/old) of your original NVRAM in place of current/main (NV2Test.bin)

However, I suspect that may fail too, because STDDefault volume is missing in it too, but I'm not sure if that is normal/expected from this running machine (it's in stock BIOS, as with all BIOS, but sometimes it's different once system runs)
Second BIOS (NV1StockNV2Removedm.bin) I will replace main NVRAM with ONLY stock (empty/sparse/unpopulated), this will run the system for sure. You boot this, enter BIOS, load optimal defaults, save and exit, reboot back to BIOS if you need to se RAID, otherwise boot to windows, then shut down and dump again with FPT and send to me
I've unlocked FD, so after one programming in you can use FPT from then on out Hopefully, unsure about BIOS Lock or FPRR, we shall see, if set we may be able to disable via grub/setup_var, or you can just show me error and I can unlock and you program in new one and test again.
I see BIOS Lock is disabled, but Host Flash Lock-Down is enabled, unsure if this blocks FPT BIOS region flash or not, so we will have to test and see what error shows up once you are in windows

To program this to chip, erase, then blank check, then write/verify. I prefer to do this partially manual in CH341A software, on the "Auto" function at top, uncheck erase + blank (I always suggest everyone does this by default so no accidents happen)
Then erase and blank check manually, then open BIOS file and hit Auto which has write/verify only checked, that will do those two steps at once.
http://s000.tinyupload.com/index.php?fil...850125673945992

Here's how to use FPT once you get back into windows.

I will make one last dump and verify then I'll follow your instructions and flash NV2Test.bin and follow on from there, and get back to you.
---------------------
This is strange if I install the driver from the folder "Driver-Install-First-Always" and do a dump then verify it will fail, If I remove the driver it verifies and matches, the dumps I uploaded are without the driver, should I continue this way without the driver? or keep trying with the driver, I don't know if it would make a difference in the dumps.