Hi all,

I've been reading and familiarizing myself with how to save and flash a BIOS using my newly acquired CH341A SPI Programmer with SOIC8 Test Clip and @Lost_N_BIOS guide on programming (really nicely done by the way, super helpful) and have managed to save a BIOS .bin backup from an Alienware 15 R2 I've inherited. It just turns on and off a few times before giving a 7 beep error code. I've tried replacing the RAM and reseating it - even replaced a burnt up DC jack that was a bit crispy on the connector plugging into the motherboard but the female DC jack connector on the motherboard was clean - so hopefully all is okay there. Tried a new power adapter. Tried jumping the pins under the RAM slot to clear CMOS. Tried removing the CMOS battery and draining flea power. Still no signs of life.

I'm curious if there's a possibility that there's a corrupt BIOS/NVRAM/ME (whatever that is) that's preventing this system from powering up as Lost_N_BIOS seems to have quite a bit of experience in recovering funky BIOS's from bad flashes. I don't know if a bad flash caused this - but I wanted to try and fix it as well, it's dead already (to an extent) and a replacement motherboard is more than the entire system is worth (even if it was working!!!). Markings on the board are: aap21 la-c912p rev 2.0 A01 2015-10-01

I noticed when I was trying to pull info from chips, only one, in particular, was giving me a lot of issues reading/detecting. No matter how the clip was placed, it would detect for a second, read, and mostly give FF's except 1 single 01 or 0E in the hundreds of lines of FFs. Dead chip maybe? I could move the clip over to another chip and it would read and detect first time, first go.

I've uploaded a copy of the backup I made from the chips I could get at with my SOIC8 clip, and included the chip names and positions on the board.

https://imgur.com/a/6BGlFTm

Any ideas anyone? Much appreciated, and thanks for all the great info on these forums so far that I've come across !!! :)

PW: pizza

@calpwns - Nice research and good job figuring stuff out on your own!
That is not my guide, I just helped advise the user as he put it together

The one chip you had issue dumping may just need battery and or PSU connected to the board while reading >> Both (RED) dumps 100% Blank (All FF)
That may be all that's on there, but I doubt it, due to how you mentioned having issues dumping it. For now, lets just hope all those 1MB chips are OK

Purple "looks" OK but I don't know what this version is so I have no direct comparison, so this only means it does not "Look" corrupted, in what data I see there.
Some areas I question, and I don't know how much should contain data or not, we'd need dump of this chip from known working sample using same exact version of BIOS and EC FW to be 100% sure what's what
I compared this to another users dump I have and it looks "Similar", probably OK just different version (Chip location UT2)

Same applies to yellow, minus "some areas I question" - I compared this to another users dump I do have, and it's 100% hex match so this chip is OK (Chip location UT5)

Crispy connector does not sound good! When you inherited this, what were you told about it?

Green = BIOS. What software/version did you use to dump this chip? For write to W25Q128FV, only Colibri (included below) or ASProgrammer has been confirmed working here by others.
For reads quite a few other programs and versions have been OK, but I don't keep a list and try to have users dump again with known working software/version
Here in this package is Colibri and or ASProgrammer 1.41, please dump this chip again with one of those, Colibri is more user friendly if you prefer that.
http://s000.tinyupload.com/index.php?fil...213094641136166

Generally speaking, after a few quick checks, this BIOS looks "OK", but that is just quick check to be sure nothing badly or obviously broken. The only way to know for sure if BIOS was bad or not is a full rebuild.
Then if system fails to start still, it could be one of those other chips, or a dead CPU, or some other part on the board is bad/shorted etc (SB, or NB, or voltage/surge protectors, or anything relating to power area since you mentioned crispy/Burnt up DC jack)
Sadly, the BIOS version this dump is, 1.2.3, is not available on Dell's site anymore.
Have you happened to copy that drives contents, or can you pull it and look around, see if you can find BIOS in desktop, download folder, or temp etc? A copy may also be in C\Dell or C\Drivers
File we're looking for would be named >> Alienware_15R2_17R3_1.2.3.EXE Never mind, found it in google!

Send me new dump with Colibri of green chip, then I will make you two new BIOS to try, one or both should start the system if the BIOS is the only issue.

@Lost_N_BIOS Morning and thanks for the response!

The strange thing is, when I was dumping it - it appears to be all FF's except one single line way near the end - just a single value was changed, which I thought was strange. I hope they're okay too!

I have no idea the BIOS version was or what else was done to this poor beast, just someone who bought it new many years ago and spent wayyyy too much money on it and when it stopped working, they bought another new one :)

I'm using... *checks* SkyGz Series Soft Programmer, v 1.18... but I'll for sure dump that chip again for you with the software recommended.

Fingers crossed for a bad BIOS or something... thanks for much for the rebuild and the info!!!

I did attach the newest BIOS in the zip - and it's 1.8 something - any difference in using 1.2.3 you mentioned vs 1.8? Would Dell have pulled this BIOS update if its not so easy to find per chance because there was issues?

Cheers, dump incoming shortly!
----------------------------

Here you are, my friend! Both verified successfully. Dumped it once with ASP, and with Colibri.

PW:pizza

https://www.dropbox.com/s/bsm95l7q15ptu3j/A15R2BIOS.zip?dl=0

@calpwns - You're welcome! What appears to be all FF's, what chip/dump do you mean??
Thanks for the info, I thought maybe you were told something like "I killed it with BIOS update" or "it died due to the crispy power supply always messing up"

1.18 can read that BIOS chip OK "usually", but read/write properly is the main concern here, so best to do both with known working software
Verify will happen even if software is not compatible sometimes, due to it can verify it's own failed read or write, so this why it's best to use known working version/software.
When we write, you can manually verify before you try to power on, if you do not trust the software verification, by closing app, open app, read, verify, save and then compare that in hex editor with what you wrote, if 100% match OK

Yes, there would be many changes between 1.2.3 BIOS, but you'd have to read all the change logs at the BIOS download pages to know what all those were (at least what they publicly say is changed)
I will use the same version first, in case the EC FW must be matched to the BIOS version, this is often the case for at least some if not all versions. Then once you get it working, you can update usual way to 1.8
They could have pulled it for any number of reasons, hard to say without asking them directly or maybe finding some reason in an old google search result.

Both of the new dumps match your original 1.18 dump, so you again confirm what we already know, 1.18 can read this chip OK.
But, when it comes time to write, best to use Colibri or ASProgrammer, I already know 1.18 will fail at write of this chip.

Here, please test both of these, in order below, if first one works go ahead and try second one as well (it has more of your system specific info, first one is more "Stock")
1. outimageNV1UEFIT25WipNV2vol1-3SH.bin
2. outimageNV1UEFIT25WipNV2Pad1vol1-3SH.bin

Be sure each time to do the write in this order >> erase, then blank check, then open file, write, verify
https://ufile.io/lbc7uiae

Once running, if we can get it working, then we'll do follow up to fix system info if any still missing (which there probably will be, due to neither of these contain your original NVRAM)
Then, after that you can update to the latest BIOS.

@Lost_N_BIOS I believe the two chip dumps (red and purple?) were all FF's, except one random line buried somewhere there was a 1 off variance where it wasn't FF, but rather 2 bits of data. I'd have to scan through them again. I thought that might have pointed to corruption or something on the chip or a bad read or something - but after switching to the next chip over with my clip and reading they read and verify fine. But like you said earlier, maybe it's a power thing or they are bonked, who knows for sure :)

Awesome, I will do exactly that. I've been waiting to do this in excitement for a few days now!!!! Feel like a kid at Christmas, fingers and toes crossed. WIll report back shortly with results!

@calpwns - Red was the only one that was blank, and that was the one you had issue reading, so it probably isn't blank.
Purple chip was not like this, I explained what I see there in above post #2

Good luck, hopefully the above BIOS gets you going and that is the only issue here!

@Lost_N_BIOS no go, my friend, I still get 7 beeps with both bins flashed with Colibri. Both write and verify okay. Tried POSTing with and without RAM.

@calpwns - Sorry to hear!!
Then some other chip is the issue here, or some other hardware is dead/shorted etc. That could be CPU, graphics card if one is separate from CPU, NB, SB, or any of the voltage regulation protection, or voltage delivery (VRM) system.
Can you test the CPU and ram on another system to be sure it's OK, or is CPU soldered to board, not in a socket, on this model?

Please wait, tonight I will make you other BIOS to try, using latest or at lest newer BIOS and an update to flash into "purple"
Meanwhile, see if you can get a non-blank dump from that "Red" chip >> Connect main battery and try, then try with ONLY PSU, then try with BOTH main battery AND PSU and try.
Unsure what software version works best for this chip, but whatever you dumped "Yellow" with was OK, and "Red" is same chip, so use that again and it should be valid, once you can actually get a good connection on the chip that is.

@Lost_N_BIOS That’s what I fear... unfortunately the GPU/CPU are both soldered on so no go there :(

I will try again with the new programs to get that red chip dumped for you and see what’s up with it. Is the purple chip this “EC” controller? I’ve read somewhere that chip could also cause these 7 beeps... something about it not sending enable signals? Is that also the Super IO chip? Sorry for all the questions - I find all this stuff super fascinating but it’s quite the learning curve haha.
--------------------------------------

@Lost_N_BIOS

With trying to read it again (red chip) after at least a few dozen tries on the clip, I was only able to pull this from the chip - it read for a second, then a second click to identify the chip again flipped it all back to FF's.

JEDEC ID(9F) = 0xEF4014
RES ID(AB) = 0x001313
REMS ID(90) = 0x00EF13

Almost seems like the chip works for a split second then dies/shorts... could that be a thing? Not sure what this chip is responsible for. Tried with and without the CMOS battery in, then the main battery, then with the DC jack connector to the Dell power adapter. Same behavior. Detects, but reads all FF's on a read command.

Oooh, if I attached the clip super fast, and instead of clicking the little ID chip picture in Colibri and click Read instead, I get a little info. Can't seem to get more than this without it dying out and not detecting anymore before I have to take the clip off and put it back on.

Attached, pw: pizza

@calpwns - Bummer! I am not sure what the purple chip is, but it's contents are similar to another dump I have as I mentioned above, and contents looked OK, but not same, probably due to different version.
Why are you trying to identify the chip twice? Connect, then ID once, or just pick correct ID yourself, read and save?

It simply could be this chip needs to be removed from the board, for any number of reasons, one being power which is why I mentioned battery/PSU
Chip may need removed to read or write, sometimes this is just how it is. But, if you can't read or write to it, then nothing we can do and must assume it's OK for now.
Redchipattempt2.bin dump has more data than first, but yeah, we can't know what is actually on there until you get a full proper dump.

If you want to pay, you can get valid dumps for each of these small chips at site below, I think you can buy one day pass $3
https://vinafix.com/threads/dell-alienwa...are-17r3.19813/

I also found a package that includes the "Red" chip contents properly dumped, and it's very little info, and looks similar to yours Redchipattempt2.bin, so I think we can safely say this one is OK too just like the purple one.
https://www.laboneinside.com/alienware-15-r2-bios-bin/

So now, I have to assume some other part is probably bad, due to we've checked all chips and all look "OK" and tested new BIOS x2, and one damn near 100% stock
If you pay vinafix, you can try that "clear ME" BIOS they posted, but it would be similar/same as what I already did for you in BIOS I made you above
Clean ME is the proper term, and I did that, but it's possible your ME something bad carried over and theirs did not during the processes, so something you can try and see if any change or not
And yes, since I linked you to that vinafix discussion, I am well aware of bootguard and worked around it in this case on the rebuild by direct hex replacements of the BIOS volumes so boot guard hash was not violated and I checked final builds for this in tool that lets you know.

Please see if anything on screen when you next test my BIOS again or vinafix, if you connect an external monitor to any/all of the external ports.
This would need to be connected before you start the system, so if you test more than one, you will need to shut down, then connect cable to next one, then try power on again.
This will only show display if the add-in PCIE graphics is bad, but the internal graphics on CPU is still functional, and of course this will only work if/when it's actually booting too, so if it's not booting and running at all then this may never show anything.
Does the CPU warm up at all if you let it sit there "ON"?

@Lost_N_BIOS thanks for the explanation and in such detail. I’ll try flashing your two files from the early post to see if it helps - and then maybe try the vinafix files and flash them to all the corresponding chips based on chip locations? Or did you have another file for me to try in the works?

I’ll test for external display next time too - I do have the original panel hooked up to the LVDS connector on the motherboard and get no output. CPU and GPU do warm up which is a good thing... I think? Ha!

Yes, try the BIOS I sent you again, but testing each external port one by one, just to rule out dead external graphics causing boot fail and no display out.
As for the vinafix files, if you use those program all in, including the BIOS in case BIOS/EC FW etc has to match. Yes, beside each chip you should see a marker on the PCB, such as UT2, UT5 etc as noted on that page.
If you try those and it fails, be sure to also then test BIOS w/ clear ME at post #8. Then if all still fail, program back in the original chip contents to each of the non-BIOS chips.

I don't think making you another newer BIOS will help, but if you want I can make you one? The issue here is, and why I did not do that initially, is usually BIOS and EC FW need to match, and I don't have EC FW dump for the latest BIOS, so not sure what EC FW goes with it nor where to find that.
That's why I made you test BIOS using the exact same old version that was on there, and why I said to flash all vinafix files at same time too so those match the BIOS.

Yes, CPU and GPU warming up is a good sign, that at least means SB and CPU are working, but does not necessarily mean CPU is not dead/dying and same for the external GPU.

@Lost_N_BIOS Got the files from vinafix and have attached them for your viewing pleasure and hopefully, it may help someone in the future, too.

I'll try flashing those today (vinafix first, then I'll retry your two files submitted above) as I've got the time to tinker and see if anything springs to life. Hopefully, that dump will contain the red chips info you're looking for to compare. I will report back with results shortly!

@calpwns - Thanks!
I assume UE2 marker is near the red chip, correct? I can't see the print on the PCB in your image, so you'll have to check and let me know
Grab that "Clear ME" BIOS at post #8 (I think) too while you can, just for more things you can try

I looked at that UE2 from vinafix, and it looks "Similar" to your Redchipattempt2.bin, much the same as I posted above about the laboneinside file I compared it with too. So I don't think your chip is corrupted, just different version than the ones we've compared the contents against.
Same for yellow/Purple too, I think ALL these are OK in your system now, and you've tested good matching BIOS already too So sadly I suspect some hardware fault really now that I've been able to compare three different files against your red chip dump.

But, you can still try programming all these in, there is very slim possibility the 2 BIOS I sent you have ME broken so badly it's causing a boot failure, even after cleaning of ME FW with stock image, something maybe carried over.
That would be super rare though, generally if ME FW is messed up, broken, or even remove/missing, it just causes ME FW Failure and symptoms associated with that (not brick)

@Lost_N_BIOS Oh dear, my worst fears. Hardware failure. Im half way done the flashes from vinafix so wish me luck on that front.

Now to maybe try and find a motherboard repair place and hopefully its just a bad cap or something... a bad flow? I'm so new at this I'm just using terms others have done with success :)

Someone mentioned elsewhere too that flashing the Super I/O chip through the KB connector with another flasher brought his system back from 7 beeps. I can't seem to find the article now, of course... never mind:

https://boards.rossmanngroup.com/threads...re-17-r2.50967/

So far, all 3 chips except red programmed successfully. I just can't get this red chip to read/write/verify for more than a few seconds before it loses connectivity to the programmer and I have to take the clip off and try a few more times before it detects. Seems like weird behavior. Can't seem to find a schematic for this board, either...

UE2 is the red chip, yes
------------------

@Lost_N_BIOS Interesting development... after rebooting my computer I get the little "run" LED very dimly (the power light is BRIGHT), blinking, rapidly as if it's reading from the chip when it's clipped onto the red guy. But none of the flasher programs can detect it. Strange...

Is this maybe too much power? Too little? This is with just the motherboard sitting on my workbench with the CMOS battery attached. Same behavior with the main battery attached and DC power attached, too. It hasn't done that before...

But still can't read/access the red chip.

When I clip the programmer onto the identical yellow chip next to it, the first time it detects in the programmer, and the programmer PCB LED doesn't do that weird dim "run" blinky LED.

What's your take? Worth replacing the chip or maybe trying to desolder to read it?