At this point I got the original board with the damaged iDRAC, a second one I got off eBay but whose RAM slots were busted (and wasn't worth shipping back, according to the seller) and a third one which works. I have tried dumping each of them using different machines and the various versions you packaged - thanks for that btw, getting the right software for it isn't as easy as one would naively think - as well as flashrom from Linux, and the result is still the same. None of the dumps verifies correctly against the chip it was taken from for the second and third board whose iDRAC works, some parts are not read correctly and filled with 0xFF or 0x00, or differ between dumps for the same board.

My doubt stemmed from some reading I did regarding the black ch341a model versus the green one - I'm not good enough at electronics to properly grasp the issue, but it seems the black model has been wired/cloned wrong and provides incorrect power. I noticed that the board's LED indicator tends to dim lightly once about every second.

You only verify against the chip you are taking image from, any other chip is not going to match. So read, then verify, then if matches save. That's what you do on the working one, then figure out how to take to non-working, ie is serial or some other numbers needed, or does straight erase, program, verify, test work?

That info you mentioned about the black one is not valid in the way you think, I used to think that too, but even if it was it's only overvoltage causing chip to be warmer, it does not affect data. And I found later, this does not really apply when using like we use anyway, so it can be safely forgotten about.

Keep at it, you will get verified dump. Maybe remove the PCB if you did not solder it to the pins, and then make sure connection on the BIOS chip end is secure and does not move while you are doing the read/verify process before hitting save.

I'm verifying each dump against its own chip, and the verification fails. If the voltage is not an issue that could make certain parts unreadable or get certain bits stuck, then I can only guess there's an incompatibility between the programmer and the chip. The iDRAC SPI chip is soldered on and not removable, and I don't trust my hand to be steady enough to re-solder it again.

OK, I was not sure Is the chip a 1.8v chip, that can matter, look up it's PDF and see (I checked, it's not, it's 3.3v). I doubt there is a compatibility issue, I will check now though, I have some of the same roms on hand.
I checked MX25L3206E with black CH341A and software 1.30 (erase, blank check, open file then auto write, verify) did not choose any chip ID left default 25L3205D, and then same steps again with 1.31/1.40 except write/verify manually due to no auto (Detecting chip, set 4MB, detects chip ID C2201615) and no issues with either version

So the issue you are having has to be some connection issue.

It seems odd to me that it happens only with a specific chip whereas the 4-5 others I've tried don't have this issue. Eventually, in chinese-snailmail-time, I should get a new clip to try

It could be the clip then, or maybe a partially faulty BIOS on there, but not on all three of them at same time. Can you desolder or no?

I cannot desolder. I've tried a different programmer and cable but the result seems the same. I'm investigating on the possibility to rebuild uboot from source - the source bundle is available at http://opensource.dell.com/releases/idrac8 (iDRAC7 2.x shares the same codetrain of iDRAC8)

There's also some clue on the SPI flash layout here https://github.com/Fohdeesha/idrac-7-8-r...r/Flash-Map.txt

Should be possible to rebuild or correct the current image, or from source you linked, using that layout if it's 100% correct

I'm wary of flashing the image I've rebuilt onto the board with failed iDRAC due to the risk the flasher will fail to write the same way it fails to read. I am also sufficiently doubtful about this being an issue related to a broken u-boot - IMO this is due to a broken MMC.

The opensource package from dell includes all that is needed to regenerate firmimg.d7, but not the source of u-boot, which instead seems to be provided in binary form. I'm inclined to believe it is still possible to break u-boot but I have yet to figure out the keys and timings.

Since you have programmer, it will be OK, it's already failed and you have a backup image of the failed chips contents, so you can't loose anything by trying. But yes, there is what you mentioned, not being able to get a consistent verified read, so write will probably be the same until you can get that sorted out.
I tested your exact programmer and that chip MX25L3206E, with the version of software and CHIP ID selection I mentioned previously, so we know that works. If it continues to fail for you, fail in a "verify" way during programming, not fail to boot/work, then we know there is an issue with your programming process somewhere and not a problem with the chip/programmer/software. Of course, knowing if the new image works or not is another issue, only someone else with one of these can test, or you can test on another working one provided you can backup it's chip contents confidently enough to erase/reprogram that with your new image.

Just ordered a kit to modify SOP8 chipset, did the same upgrade to latest 2.x version and bricked the motherboard on a R620.
Will let you know how it went!

Just curious if anyone was able to figure something out, just ran into this same issue

@DreddKLC - I think everyone still working on figuring it out.

Thanks for the update, I just fell into the same hole that @kwaleeb did...step by step, in the same exact way...it was pretty funny (you have to laugh) that I succeeded then failed in the same manner...it was kinda sad, kinda funny..what can I say. The fix is "easy", if I can find a way to get the 1.66 bios flashed on the idrac7. In case it helps, below is the link to the correct update path. I have the file that should bring this thing back to life, but no means of flashing it.

https://www.dell.com/support/article/us/...e-path-?lang=en


Update Path for iDRAC 7


If the iDRAC firmware is still running on a version between 1.0.0 and 1.57.57, follow these steps:

Update the iDRAC to version 1.66.65, which is the last one separated from LCC firmware

Next version to install is 2.10.10.10, the first one with combined LCC and iDRAC firmware

Now update to latest version provided on the Dell Support webpage (Section 1 of this article)

There are tricks which can work around the need to use a chip programmer, which is kind of hit and miss at least in my experience, as long as the SPI chip is functional. Said tricks are however covered by a NDA as Dell is working on an update that supposedly fixes the security hole revealed by iDRACula - and credit for them goes to fohdeesha. The next iDRAC release is estimated to happen around December/January, I'd expect them to become public after that.