@elektron
Dunno, chance are it’s just software, also, I’m not getting the method you are using (iFlash work in bootable DOS environment)
Since you are getting into the “Power Button Menu” I take for granted that [ESC] Normal Boot, [F4] BIOS Recovery and [F7] Update Bios doesn’t work.
So, download the *.UEFI.zip from the support page and place the XXX.BIO and UefiFlash.efi on the non-bootable FAT32 USB while in the “Power Button Menu”.
Plug the non-bootable FAT32 USB in the NUC and hit [F10] Enter Boot Menu - Select the UEFI: Built-in EFI Shell
At the UEFI shell without quote type “MAP -r” and hit enter.
The command should display and refresh the mapping list on which you need to locate the non-bootable FAT32 USB by size (should be something along fsX).
Once you got the right file system number for the non-bootable FAT32 USB type
fsX:
(where X is the current non-bootable FAT32 USB file system number) and hit enter.
now if you sure type
UefiFlash.efi XXX.bio
(where XXX is the bio file name) and hit enter.
There should by now a graphical output during the flashing procedure.
This could also be eventually adapted via AMT if the system is know to be alive but there no video output duo something wrong with the igpu firmware\setting.
See the UEFI Shell Update for reference.
The UEFI Shell is not set as a Boot Option. So I can’t start the update process this way. Only USB device and Ethernet is shown in the F10 Boot menu.
Visual Bios is accessible from “Power Button Menu”, but no settings can be altered due to hang on reboot until reset procedure of CMOS/Jumper is done as described before.
I tried to boot from Windows USB stick to get an UEFI Shell from there, but ended with “Stop Code: MACHINE CHECK EXCEPTION”.
Meanwhile I managed to make an image of my 024 BIOS with FPT (without ME part, locked) from an attached FreeDOS USB stick.
Another thing, when I type memanuf from DOS it throws an “Error 142: Power source is not AC”. What does this mean? Does it think I’m on battery power?
Edit:
With a prepared USB stick I managed to get into EFI Shell and to start the BIOS update as you suggested. But with no luck. I can see update countdown 3… 2… 1… and then the screen go blank, blue system LED blinks once and stays on and fan is at full speed.
The system hangs the same as with any other procedure.
savedBIOS.zip (3.86 MB)
@elektron
To get the EFI shell if none are available just create on the non-bootable FAT32 USB the "EFI\Boot" folder structure and place the “shellx64.efi” of your choice within the boot directory and rename the “shellx64.efi” file to “bootx64.efi”.
The NUC shouldn’t restart with the UefiFlash.efi till the whole process is done, but I don’t own the device, so I can’t confirm.
Are you doing the following procedure with the yellow jumper on normal (1-2) to enter on the “Power Menu”?
Also don’t use that truncated FPT image if anything use the “fptw64 -D out.bin” to dump the readable content.
If none of the option within the previously posted PDF work you need to backup the FD part of the bios image or all the content with an hardware programmer before anything else.
There also the possibility that you can’t directly upgrade from the initial release (BIOS Version 0024 -SYSKLi35.86A.0024.2015.1027.2142) to the latest, did the NUC worked before, was something changed?
attached the extracted shell from your own savedBIOS image
shellx64.zip (245 KB)
A new situation today.
One attempt with prepared USB stick and the yellow jumper pulled finally gave me a screen with BIOS restore (update) option.
The update failed with the information provided in the screenshot. This was the good news.
The bad news: since this failed update no blue power LED is shining, fan at 100% and no screen output. No matter what I do.
Pulling CMOS battery, pulling yellow jumper and setting back is without any effect.
The unit seems fully bricked. Is there a chance to get it back to life?
Probably you bricked both’s FD and ME.
Should I give the hardware flash programmer a try, or is it useless without a full dump original image? By the way, when I tried to make a fpt -D out.bin it told me something is "locked", so only a partial dump was possible.
Well, I’m not exactly sure what you did followed and what not, so, if the system doesn’t boot or always give the no output and no documented recovery option is available even after swapping or removing the memory or by forcing a substantial hardware change then you’ll need to read the full content of the hardware chip and restore with a backup what’s missing by hands.
@elektron
First thing first,I think you should find a full bios dumped by spi programmer and flashed it by SPI programmer later.
I will try to find a full spi BIOS dump (could be difficult), and get a spi programmer.
@noInk
The only thing I did (wrong) was to start the bios recovery in “yellow jumper open mode”. I can’t find a way to get a screen output or even a blue power LED since.
Thank you so much for your support to this point.
I would appreciate very much, if anyone could provide a spi BIOS dump from the SYSKLi35.86A
@elektron
Maybe the FD part survived and you just need to replace the ME segment with a factory new one but if the NUC doesn’t boot now you need an hardware programmer capable to read it out and write it back.
By the image you posted it seems you used the recovery method with an update or something like that.
Supposedly, without the jumper and locked\broken ME you should have used the same ME bios version for the recovery first ( state change/reset ) and update it later from the shell or other normal boot path.
But it’s intel software, so, who know what they where thinking.
@eivrah
Hey eivrah,
can you document in detail (PIN TO PIN, etc etc) how you got the DX58SO programmed without the SOW8 (Socketed SPI) and with the CH134A?
I’ve got an good condition DX58SO2 (Soldered SPI Flash) and it has the same DX58SO (501) issue at hardware programming with either the FLASHCAT and CH134A but I found the DediProg SF100 and it’s SO8 CLIP is capable to reprogram in-circuit intel board.
( power on, forced power off 4 sec - power supply on system off )
@noInk I just clip using the diagram I sent, with or without peripherals it just works with my board. Us your CH134A the black model?
@eivrah
Yea, I’m using a Pomona SOIC-CLIP but same thing happen also with an hook type pin grabber.
If I connect the VCC on PIN8 the chip become undetected with the CH134A (CH134A ribbon cable soldered with the black CLIP = no detection ).
Can you spot any difference with your CH134A? Are you powering on the PSU? battery in/out?
are you sure it wasn’t a fluke? can you check how high you can set the TRFC under the memory configuration page, should be 200 if the bios got written.
SIDE_A
SIDE_B
@noInk have you tried changing the jumper wires to a shorter ones? My clip is just free from the CH134A that I bought, it’s the same as yours. I didn’t attached any power/pin. I’ll check again later after I get home.
@eivrah
I’m using standard jump wire (dupont type) 20cm.
I’m in this situation where using all PIN in the assumed right position like in the CH341A ribbon cable cause the soldered in-circuit chip to become non-recognizable.
With the single head hook or the pin of the pomona clip I can test the following;
NO VCC on PIN8 >> right JEDEC ID chip detected equal FF content
3.3 VCC on PIN8 >> wrong JEDEC ID chip undetected NO content
This happen also with the FLASHCAT.
I did many other check on the pin-out and I m able to just read some partial data while in-circuit.
@gyrator
I just re-read your post and I’m experiencing the same issue with multiple intel board without the chip carrier for out-of-circuit programming.
I think the CH134A or other cheap hardware\software solution are not capable on handling the in-circuit bios chip operation whatsoever on these board.
The DX58SO2 I have naked here in front of me has all the required resistor and circuit to allow SPI flashing ( it’s pretty much the same on the DQ77MK ).
Either some other signaling operation are required to allow the on-circuit flash or the hardware programmer provider didn’t ever checked what going on with a logic analyzer / oscilloscope.
@eivrah
Your CH134A is different, can you point me exactly where you got it? might be that?
Yep, if it’s 200 then it got written by ISP.
It’s from Shopee Ph page here it is CH341A Shopee Ph since I’m from Ph, but it ships from China around $5+. Why did you think it’s different from yours? From the looks of it it’s the same only the label at the back is different positioning?
@eivrah
That’s would be hard for me but I probably found one with the same PCB as your.
I’ll let you know when it arrive!
Yea, TEXT, resistor and some trace are different.