After over 1 year since I used this utility on my NUCs (to add SLIC 2.4) I thought I would update to 2.5 and found the utilities did not work (same error as posted before) on some NUCs. No amount of changing date back, BIOS settings, and so on helped. What I found is that on Server 2016 NUC the utility (X007) worked fine to get status/erase/insert new SLIC. But on Windows 1809/1903 on other NUCs the utility did not work (the SLIC was naturally not used there just added it in the past to see whether it worked). Booting off Server 2016 (1607) install on these NUCs did work - so something must have changed in "recent" Windows builds with regard to EFI variable manipulation which is why the utility would fail. After erase/insert the new 2.5 SLIC would be seen fine in Windows 1809/1903. Tested NUC7 (i3), NUC6 (i5) and NUC5 (i7) latest BIOSes from this month. So for anyone that gets errors on NUC regarding EFI - make sure you're using an older Windows build, did not try 8.1 / 7 but I would think it would work.
when i apply to patch (i modifyed the files for 2.5) i get this error : This Tool is not authorized to update this Bios can someone help ?
See just above what I said - your Windows is too "new". Try server 2016 or similarly older Windows not any '18 or '19 or later. Server 2019 does not work with utility nor does Windows 1903 or 1809. I have not tried others there's no point. Just install Server 2016 temporarily, change SLIC. Remove then install Server 2019.
Intel seems to have a new utility "iFlashV. I purchased a new 10 series NUC and was trying to see what my activation options were. This is what the utility "iFlashVEfi64.efi" can do from inside an EFI shell: - /Q Silent execution - /K1 Program the non-critical block for Splash Screen Logo update - /A: OEM Activation file - /OAD Delete OEM Activation Key - /JBC Don't Check AC adapter and battery - /cmd:"{OAID:OEMID:OEMTBLID}" Input of the OEM ID and OEMTABLE ID that will be associated with the key. The OEM ID must be 6 characters and the OEM Table ID must be 8 characters. If ID string is less than 6 or 8, please fill with spaces. It is used for updating the BIOS from a EFI shell but it seems to contain OEM activation tools also: OEM Activation file This command usage is for /A command which inserts a specific OEM activation key into the empty key inside current system BIOS. The command line is as follows: iFlashV /A: <OEM Activation Key Bin File Name> [/cmd:"{OAID:OEMID:OEMTBLID}"] Where OEM Activation Key Bin File Name is used to specify path/filename of the OEM activation key file with extension. Please make sure that the OEM Activation Key region is empty before inserting the key, or please perform /OAD command before insertion. Does anyone know how this tool works?
Bios: Intel EFI bios revision: BX97520J Is there anyway I could read the bios chip of my intel board with my USB Programmer and upload it here for decompiling and maybe a slic 2.1 from the .bin file its self so i could possibley reflash the bios with slic 2.1 activated? just a thought. It would be amazing if I could colab with someone and test... if anyone has any suggestion please let me know! I would be willing to work with someone with my board as a test bench, I know there are no tools for this bios and board but if there was a fundamental acpi in the .bin we could deconstruct and recompile with slic 2.1 for these motherboards!
Just FYI - if any of you are using Windows Server / ESX on your NUC (reason for the SLIC right? - e.g. as a Hyper-V or VmWare host - you may find your "V" Ethernet adapter is not supported - Intel only provides drivers for LM on servers. You can naturally try USB adaptor (not great) or if you are lucky and have Thunderbolt there may be some PCIe/TB Ethernet adapters but not cheap. Therefore the built-in Ethernet is pretty "precious" I have 3 NUCs (gen 5, 6 and 7) and performed this mod to all of them. Naturally the PCI ID of each is different so all used different patches. I haven't seen a way/guide on the 'net to update/change GBE firmware - generally you mess with the drivers (disable signature and so on) to load other drivers - but to me it seems easier to just change the firmware. Especially if you change/upgrade software regularly and thus can "lose" you Ethernet. 1. Somewat easy way is to use the corresponding CSME/ME tools (e.g. from "Win-Raid" forum) and dump the GBE region with "Flash Programming Tool": fptw64 -gbe -d gbe.spi Note: Save/backup this dump and keep safe just in case you need to revert, e.g. if a future BIOS update fails, you sell the NUC, etc. - Now use HxD editor (or any other) to change the PCI ID from the GBE you just dumped from the "V" to the "LM" version. Usually you need to add or substract "1" from the ID: @18h you should see 8680h (aka 8086 reversed Intel's PCI Vendor ID) @1Ah you should see the PCI Device ID to change (e.g. B815h - reversed 15B8h) - Just modify B8 to B7 aka from i219V to i218LM or similar. You can check PCI ID lists to find out the corresponding LM PCI ID. - Save it to say "gbe-lm.spi". Technically you need to fix the checksum also but generally this is not a problem (some Linux kernels may not load the driver though but then again Linux supports both V and LM). Flash it back: fptw64 -gbe -f gbe-lm.spi - Now your V adaptor should load the LM driver just fine. 2. The hard but proper way is to actually find a GBE region for the "LM" version of your Ethernet card and transfer your MAC to it as per above, rather than change ID. This is preferred since the GBE region does have some other changes beside the PCI ID. - Before you do anything, save/dump the orignal GBE and keep safe. You will need it to know your MAC address: fptw64 -gbe -d gbe.spi - You will need to look on the 'net for busines laptops of same family/generation as your NUC but LM Ethernet and extract GBE region from their BIOS update with "UEFI tool" or similar. Just open the BIOS update, navigate to GBE region and dump it to say "gbe-lm.spi". - Once you have it open it with HxD: @0 you should see the generic MAC i.e. 88 88 88 88 87 88 - Change that with the MAC from your dumped gbe region above and save. As above, technically we need to update checksum, but should be OK without it. Flash it back: fptw64 -gbe -f gbe-lm.spi There you go, now your NUC can load the official Windows / ESX server Ethernet drivers and you can run your VMs off it. My NUCs 5, 6, 7 have worked as both Hyper-V and ESX hosts with no issues... so far. You can always flash the original GBE back. In case you are wondering, I have not seen any performance improvement, you don't get more queues (still 2) or VMQ or SR-IOV but in the future you never know. Note: Some BIOS updates also include ME updates (see release notes) but while I've not seen one to update/wipe GBE region, it is possible. In this case you will revert to the original V firmware so just do the above steps again. Naturally your NUC will lose network connection (since the Ethernet adaptor is now "missing") so don't update BIOS remotely just in case.
can you please share working link for oa2intel, also where can I get file so windows 10 oem activation will work on nuc8i3beh? EDIT: tool is here https://forums.mydigitallife.net/threads/slp-marker-file-update-utilities.9055/#post-131390 Thought I dunno, maybe the way is to use OA3 (vcust) somehow?
I don't have a NUC8 but as mentioned above the tool works for NUC7, 6, 5 which I personally have and tested. But you need old Windows 10/8 or Server 2016/2012 to run it, not the current ones as the tool cannot update EFI with the SLIC. Otherwise it's plain sailing SLIC 2.5, 2.4, etc.
If you're still around, what version of BIOS did/does your DG965RY have? I found (working) one in a dumpster, literally (ok it was on top), with cpu and 3GB of ram, but it's the very first revision of the board that was sold (BIOS MQ96510J.86A.0816.2006.0716.2308, i.e. version 0816). This one complains on oa2intel that Code: INT 15h EF01h failed to return EFI Varialbe Size -- FAILURE AH = 8Eh - NOT_FOUND. This tool is not authorized blah, blah. Unfortunately there are dozens of revisions of the BIOS for this board floating around (and not on Intel's site, since that one is not hosting board stuff anymore.) So I need some clue which one to try... Also I'm using FreeDOS if that makes a difference.. Ok, I''ve tried the Millenium DOS and it didn't make any difference. Then I installed XP SP3 on the machine and oa2intelwin also didn't want to even status. But since I had XP now up and running... I flashed the last BIOS revision I could find for this board (1754), which I could only find in an "Express" variant, meaning needs Windows to install. Actually that Express thing flashes using the Intel ME (Management Engine) after a reboot. And despite the board's age it seems it flashed fine, although the BIOS event log does show a "Failed (1)" after the flash. The BIOS is clearly different though, given the changes in the menu options (and the string it prints). But in XP again, oa2intelwin now says "Windows Marker: NOT PROGRAMMED" instead of complain about the INT (which was different in XP than in DOS, but that doesn't matter.) So, long story short, the earliest versions of the Intel BIOS for this board simply didn't support oa2intel (either variant dow/win). Looking through their BIOS change log: Also, the oa2intelwin reports writing the tables ok, but they cannot be read back by SLIC Toolkit 3.2 until after a reboot. I suspect the actual flashing of those tables only happens in ME time, just like the flashing of BIOS "from Windows", but for the SLIC tables there are no ME boot messages (or logging), although the reboot takes slighly longer and pauses at black screen with blinking cursor for a second or two. (Writing the whole flash is very fast on this board, with all the ME messages on the "full flash" it took maybe 5 seconds.) Thee most weird thing about this is that SLIC Toolkit 3.2 reported the old BIOS (version 0816) as being a 512K BIOS, but says that the new one (1754) is a 1024K BIOS.
Or use the DOS version, that still works (you have to change the date though) I just "fixed" A NUC8i5BEH, using DOS version inside OA2Intel007.rar (taken from mega link https://forums.mydigitallife.net/threads/slp-marker-file-update-utilities.9055/#post-131390) that even includes a script/tool to automatically (temporary) adjust the date
Trying to update my NUC6CAYH that i "touched" earlier to include SLIC v2.6 but i experience trouble clearing / writing the new data Tried various thing, eg: DOS version, Temporary install windows Server 2016, DaRT Windows 10 image (build 1607) none of them work, that is strange as i have been able to insert slic 2.4 and after that 2.5 successfully on this unit in the past the error messages below are captured from a clean Windows Server 2016 install oa2intelwin.exe erase Code: OEM Activation 2.0 Utility - X007 Copyright (C) 2004-2012, Intel Corporation Distributed under restricted license. Do not redistribute. SetVariable() failed to write EFI Variable Data -- FAILURE 3h - INVALID_PARAMETER oa2intelwin.exe update DELLPUBK.BIN DELLMARK.BIN JSIGN.BIN Code: OEM Activation 2.0 Utility - X007 Copyright (C) 2004-2012, Intel Corporation Distributed under restricted license. Do not redistribute. SetVariable() failed to write EFI Variable Data -- FAILURE 3h - INVALID_PARAMETER The only command that seems to work, oa2intelwin.exe status Code: OEM Activation 2.0 Utility - X007 Copyright (C) 2004-2012, Intel Corporation Distributed under restricted license. Do not redistribute. Windows Marker: PROGRAMMED Public Key: PROGRAMMED Signed Public Key: PROGRAMMED Requested operations completed successfully. Anyone has a idea what can be causing this? Or how to fix this?
Update: I managed to insert DELL 2.6 SLIC into my NUC6CAYH (had a broken NUC6CAYS unit laying around to test out some stuff) I had to downgrade system bios to a bios dated a few years back (you can do this only by the bios recovery method, eg: removing the yellow jumper!) With the old BIOS in place, all methods (DOS, WINPE, Server 2016) described above worked without issues