I am trying to install win 10 IoT ENTERPRISE eval version on an intel tigerlake board. The BIOS/firmware used is Slimbootloader with UEFI payload built using tianocore EDK2. During windows installation, I get a BSOD with ACPI_BIOS_ERROR. I know it is something to do with ACPI incompatibility but not able to narrow down. Tried playing around with acpi tables but its like shooting in the dark. 1) Is there a way to get a crash dump while installation ? eg enabling registry settings by loading image offline. 2) Can I disable/reduce acpi requirements. 3) I have a serial debug port but only able to see logs until the BIOS hands over to windows installation. (the board does not have EC, TPM and secure boot is disabled) Has anyone managed to do anything similar? Appreciate any suggestions or ideas.
diy bios using slimbootloader/Edk2 instructions to boot windows. Not made any major changes except disabling secure boot etc.
What's your goal? Booting with an open source bios, or just booting a MB which has booting problems/unsupported boot by NVME or alike? If it's the second case, I use Clover to boot a NVME disk on a (old) MB that doesn't boot from such kind of disk, never had problems with it. Duet + refind works as well but I got used with the first option (duet is based on Tianocore as well). If it's the first case I can't help, never played with Slimbootloader.
Thank you, Goal is to boot windows 10 IoT ENT on the board although I am okay to use standard ISO too as I believe the binary is very similar. Have never been able to install windows either from NVME or USB. Any opensource bootloader would do. Due to intel's contributions to slimbootloader, I chose it. Am able to boot/install debian/ubuntu using same UEFI bootloader but getting ACPI error for windows.
Got the iso via MS evaluation download page. microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise Tried both iso and a standard - 19044.1288.211006-0501.21h2_release_svc_refresh_CLIENT_LTSC_EVAL_x64FRE_en-gb. iso - 19044.1288.211006-0501.21h2_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_en-gb. iso Don't mind trying other. Thanks
Ok. While I'm not skilled on your specific case I think that clover or duet are worth a try, no need to flash anything, they are usually installed in a small pendrive, which boots (even on old machines w/o any UEFI support at all), once booted the UEFI environment takes over the original BIOS and allows you to boot any UEFI based OS (including Macos), and can be extended with uefi drivers to support things that didn't even exist at the time the original BIOS was made, say USB keyboards/mice, NVME drives and so on. If it works it can be installed on a small custom partition in the HDD/SSD, allowing to boot w/o a pendrive.
Tried clover which booted fine, but windows still throws ACPI error. Is there a way to debug or dump logs when windows is installing?
Not sure if you noticed it but Clover has a big config file, maybe playing with some params can help. Debug, no idea, I saw people debugging boot failiures, but they did using vmware and its serial debug port. Logs: assuming you reached a point where the setup was already writing on disk, the logs are stored inside the panther folder, which is located inside one of the hidden setup time folders in the root of C: (and later also in \windows\panther)
Thanks, like I said my skill on such low level things is fairly low. And perhaps I never had to do with such kind of boards. But, if the device boots, something that comes after (OS or Clover) isn't supposed to take over the unrecognized devices (if adequate drivers are provided) even if the firmware knows (almost) nothing about them? I mean, think to a very old BIOS machine, with a NVME drive connected to it via a PCIe adapter, the OS can't boot from it, the BIOS knows just it's a PCI device, but once the OS is loaded (from a different drive) it access the NVME drive w/o any problem, CLOVER/DUET I think do the same thing. More or less what Ontrack Disk Manager or Maxblast did in the good old days with large HDDs. So I guess is not Clover per se the problem, but maybe the lack of adequate drivers, for this specific scenario.