booting crashes on custom i.mx8M Mini platform

[UweSteinkohl]

after the UEFI jumped into the windows kernel itself I can see the blue windows logo and the wait cursor doing a few turns on my display. But, after a few seconds everything is freezing. Debug output always stops at the same point (Please see the output attached).

does anybody know how to debug that?

LOG_31_07_2019_1.txt

[neilsh-msft]

Generally if the output stops during boot and the device becomes unresponsive, then quite often it's because the processor attempted to read or write from a memory range of an IP block that hasn't had its clock ungated.

You can look at the devices in the DSDT ACPI tables in MU_PLATFORM_NXP\NXP\MCIMX8M_MINI_EVK_2GB\AcpiTables\Dsdt.asl or the Dsdt.asl file you're using for your platform and compare that with the clocks and IP blocks you enable in your U-Boot code. Possibly, you haven't enabled a specific IP block such as ESPI, or I2C, or some other peripheral.

If you're sure that the ACPI tables are correct, then you can 1: set windbg to break in at boot time (ctrl -alt k I believe) and set deferred breakpoints in the kernel debugger for each imx8 specific driver that is loaded ( bm imxecspi!DriverEntry , bm imxi2c!DriverEntry , etc.) and then step through each one and see if it hangs inside a specific driver.

Or 2: remove all the devices from the dsdt.asl, rebuild UEFI and flash it to your boot device. If you get a fully booting platform, you can add devices back and iterate until you find the offending driver and then debug that.

[UweSteinkohl]

I alraedy had tried method 2 before I wrote you, but without success. Now I found my fault. I used C-comments to comment out a few lines in dsdt.asl, that did not work. I found this after examining the Dsdt.iiii file in the output folder. Meanwhile, the Windows IOT boots on my platform. Thank you for your help.

[neilsh-msft]

Good to hear you found your issue.