Hello Markau, thanks for joining the Intel Community.
It looks like you already performed some good troubleshooting but you are still having the same behavior.
I suggest you trying to install the previous BIOS version 0032 Intel® Download Center using the BIOS recovery method. Desktop Boards — Instructions for Recovery BIOS Update
Have you tried to set the BIOS settings to default?
I will try with the previous bios, and let you know the results.
Yes, I have reset the bios back to the defaults, then only change is to set the boot device in the UEFI config of the Visual BIOS.
After the first post, I then reverted to only setting the TESTSIGNING ON boot option from the bcdedit tool and this will always cause the ACPI_BIOS_ERROR. The current OS is Windows 8 Embedded Standard. If I reboot using a bootable USB into a Windows 8 installation, open a Windows PE command prompt, remove the TESTSIGNING option, and reboot, the device will boot successfully again into Windows 8 Embedded. Does this indicate that there may be issues with a driver(s)?
Also, I did create a bootable USB with XP live and when booting to this, with the BCD option TESTSIGNING ON, I also get a boot failure and an ACPI error, just displayed a little differently, as acpi,sys. I don't have the parameters that were given with this error, but could recreate this scenario also if it helps resolve this.
Finally, I can probably set up a kernel debug environment to see if I can get more information about the problem.
regards, and thanks for listening,
Markau, if you reboot the system using a bootable USB to get into the Windows 8 installation and remove the TESTSIGNING option and reboot and then the system is able to get into Windows 8 Embedded wouldn’t that be an indication that TESTSIGNING is perhaps corrupted? Also keep in mind that Windows 8 Embedded has not been validated, it doesn’t mean it wont work but we just have not tested it, see the list of validated Operating Systems here: Intel® NUC — Supported Operating Systems.
Would it be possible for you to make sure that the system is running latest BIOS version and try any of the validated operating systems? This will take us back to defaults and them we can understand if the issue is with the ASL compilation or with the device itself.
Also, after reading some documentation about Microsoft ASL compiler there is a recommendation to have access to another operating system with NTFS file system support since this process may leave your Windows system in a non-bootable state.
Since my last post, I decided to rebuild the NUC, so I downloaded the evaluation copy of Windows Embedded 8.1 Industry Pro, installed the ISO onto a USB and then proceeded to replace the Windows Embedded 8 Standard 64 bit.
Once this completed, and disconnected from the Internet, so and with no additional updates, I set the TESTSIGNING ON option and rebooted successfully. At this point I still had BIOS 32. I then updated to BIOS 34, and again rebooted successfully. I checked and set TESTIGNING ON option again.
I then progressively installed each NUC driver from the latest update package, with a reboot and a check after each, and completed them all successfully. I also check the "Devices" list at each step to see that the drivers were consuming the "Other devices" resources.
So then I installed the Microsoft debugging environment, and from my development computer, provisioned the debugging environment using Visual Studio Express Edition, over a network connection. At each stage I also rebooted and checked that I could restart and test signing was still active. All still fully functional.
I then generated a new SSDT ASL file from the computer, inserted my changes to enable resources for I2C and GPIO hardware, recompiled the ASL to AML, and executed a /loadtable to save this into the registry. I rebooted again successfully, then checked the Devices list to see that I now had some new devices listed in the "Other devices" children.
Back to my development computer, rebuild the SpdTestTool project, but with device name changes in the 'inx' file and the device driver code, matching the name in the ASL changes I made, and then I deployed the driver package to the NUC. I had the device drivers list open on the NUC display, and saw the driver being correct deployed, and the drivers list updated to move my "Other devices" driver to sit under "Samples/SPB ....".
I rebooted successfully a final time, test signing still on, and my driver installed as expected.
So, although I still do not know the root cause of the issue, I do have a working environment, and can proceed from here. I was on Embedded 8 Standard, so perhaps there is an incompatibility there, but from memory, that installation had no additional drivers installed, except those from Intel for the NUC. I may come back to this later if I need to have this driver on a Windows Embedded 8 Standard OS installation.