MPB A1502/EMC2836 and MBA A1466/EMC2925 junk dumps

Hi!

I have an MPB A1502 EMC2836 and also an MBA A1466 EMC2925. My Raspi works, have done other models today with no problems. But on both i got only junk dumps. My hardware is an working raspi and the easy flash adapter 4.03.

I`ve read the eeproms around 20 times. Every time different md5 sums and only junk inside. Funny thing is, chip is recognized (macronix, 8mb). I`ve tried all 4 different chip identifiers in flashrom, same result. Also tried with and without power supply and removed battery.

Any ideas?

Problem solved

CygnusX1 wrote: How did you clean the MPB A1502 bin file?

KingBonecrusher wrote: Hi!

I have an MPB A1502 EMC2836 and also an MBA A1466 EMC2925. My Raspi works, have done other models today with no problems. But on both i got only junk dumps. My hardware is an working raspi and the easy flash adapter 4.03.

I`ve read the eeproms around 20 times. Every time different md5 sums and only junk inside. Funny thing is, chip is recognized (macronix, 8mb). I`ve tried all 4 different chip identifiers in flashrom, same result. Also tried with and without power supply and removed battery.

Any ideas?

Hi CygnusX1

I have used the good old scan-n-patch script. Works till today fine for me. No problems since the release.

I have tested it with only pressing the power button without removing vc and bridging! Works on both, so no additional work to do for flashing, ONLY holding power button!

Instructions
1) shut down mbp
2) open mbp cover
3) put it on the display, keyboard part straight up
4) add power supply, let it boot to the [ ? ]
5) remove battery cable
6) add easy flasher clip
7) find somebody who will hold the button
after 5 seconds of pressing the eeprom is available trough flashrom
9) use spispeed=8000 to boost the flash time down to 15secs!!!
10) make at least 2 backups, compare with md5sum
11) use scan-n-patch and remove the SVS area
12) flash back the clean image
13) release power button
14) remove power supply
15) pram/vram reset

with an automated script this should take:
--- read flash 2x ~ 30secs
--- patch bin with scan-n-patch ~ 2min *perl is f***** slow!
--- reflash ~ 45sec

** during the full flash/reflash process hold the power button! **


This is my Hardware -->

Thanks KingBonecrusher!

I have an A1466 E2925 MacBook Air. This seems to be a model giving people a lot of problems.

I attempted to flash it using the EFIDL, and with various combinations of power states was able to detect the chip, but regardless of ending up with flashing red or flashing green at the end, it was still locked.

I then tried to use the EZ Flash Clip v4.0.3 with my Raspberry Pi, using the techniques described originally with the SOIC8 chips ( ghostlyhaks.com/blog/blog/hacking/18-apple-efi-bypass ), but kept getting different MD5 checksums. I finally found your post here, which was very helpful.

It is also worth noting that during all of those prior attempts, I was able to reset the SMC, but I _could not_ reset the NVRAM/PRAM (seemed to be locked from doing that too).

So here was my successful process:
1) Battery power attached and the MagSafe attached on the MBA.
2) Fired up the Raspberry Pi and attached the V4.0.3 clip. (All GPIO pins attached to the clip, there have been reports about keeping the VCC off, but it worked fine here with it on.)
3) Got most of my commands ready in a text editor so I could do a lot of it one-handed while I had to hold the power button (as you described).
4) Started up the MBA, then detached the MagSafe and started holding the power button.
5) Dumped the EFI three times and verified the checksums (finally they were the same!!).

-- Note, I tried to stop holding the power button here as a test and the checksums diverged for any subsequent testing, so I started over. Truly, you really have to hold the power button the whole time. I am guessing something about the EFI security is using the power to vary its flash data in real-time, so it seems that holding the power button short-circuits that mechanism.

6) SSH'ed the EFI dump to my desktop.
7) Used a text editor to replace the data for the 128 characters starting with the first instance of $SVS with all hex ff (ÿ), as previously described.
SSH'ed the edited dump back to the Raspberry Pi.
9) Dumped the EFI again just to double-check the MD5 again, and it was still the same (whew! And yes, still holding the power button).
10) Erased the EFI as previously described.
11) Wrote the edited dump back to the EFI.
12) Immediately flashed the SMC and the PRAM three times (through three reboots); I was able to finally able to reset the PRAM, so this seemed promising.
13) I let it boot on its own after that and ended up booting to the circle with the slash through it (I think because the hard drive was blank).
14) Alt-booted to High Sierra USB no problem and installed fine.
15) No further issues booting up.

Notably, the chip automatically detected in my earlier unsuccessful tests and in my successful tests was always "W25Q64.V" (Winbond - I'm not 100% sure of this, going from memory and looking at "flashrom -L", as I forgot to document this on the way), although I agree with reverendalc that the documentation suggests it is a MX25L6473E chip (See here: ghostlyhaks.com/forum/macbook-pro-retina-2015-2016/571-a1466-emc2925-read-issues ). Ultimately, flashrom did fine autodetecting the chip driver it wanted to use, so that's my recommendation.

Also note I used flashrom 0.9.9; for some reason flashrom 1.0.0 was borking. I have historically used 0.9.8 and 0.9.7 with success.

What I wonder now is whether the EFIDL may have worked using the same method of holding the power button the whole time. Anyway, hope this is helpful.

So for the next effort, someone (or me?) should engineer a "hold the power button down" tool. That would have made this less annoying.

I also strongly agree on the point about spispeed=8000. Historically I never used that, but it works fine and decreases the dump time dramatically.

Thanks all for all your efforts for the rest of the community here!

Nice to see it works for you!

There seems to be another way to unlock the dumps, not tested yet but i think this is so easy if it works. At least only changing one byte...