Headless bringup

[NovTechEng]

Hi,
I am trying to do the wint10 iot core bring up on a imx6s based custom board. As of right now I can verify that I am booting into the windows default app. My issue is that I cant seem to figure out a way to move forward from here.
As far as I can tell most of the ways of interacting with a headless board involve having some sort of internet connection between the board and my host computer, so I looked into enabling Ethernet in windows 10 iot core first. Unfortunately, I am currently having trouble with getting the Ethernet driver to work.
Am I moving in the right direction as far as bringup or should I be working on a different aspect first (such as uart)?
If Ethernet is the first step, how should I go about debugging the Ethernet driver?
Thanks,

[NovTechEng]

Well I made some progress. Found out how to enable debug messages in the Ethernet driver by compiling a debug.ffu in visual studio and uncommenting some lines in dbg.h for the ethernet driver. I progressed from there and can now successfully ping the board and I can see it on IoT Core Dashboard. From this point I was hoping to use either PowerShell, Windows Device Portal, or Remote display to interact with the board. Unfortunately It seems like none of these are enabled by default and all are enabled by interacting with the board (which I still cannot do).

Is there an alternative way of enabling either PowerShell, Windows Device Portal or Remote Display that can be done from my development laptop?

[christopherco]

Hi @NovTechEng

Powershell, Windows Device Portal, and Remote Display features can be enabled by default when you do an FFU build. Make sure the following features are enabled in your OEMInput.xml

https://docs.microsoft.com/en-us/windows-hardware/manufacture/iot/iot-core-feature-list

• IOT_POWERSHELL
• IOT_WEBB_EXTN
• IOT_NANORDPSERVER

An example: https://github.com/ms-iot/imx-iotcore/blob/public_preview/build/board/HummingBoardEdge_iMX6Q_2GB/HummingBoardEdge_iMX6Q_2GB_TestOEMInput.xml

[NovTechEng]

Ok, so all those features are enabled in my OEMInput.xml as I am using the HummingBoardEdge_iMX6S build. Despite this, none of them are working. I cant connect to either the powershell or the remote display and although I can connect to the Windows Device Portal, the page is completely blank. I think the latter issue might be caused by the build being headless and I am working to solve that right now, but I am confused as to why I am unable to connect to the powershell or Remote Display.

[christopherco]

I'll bring up my Hummingboard Solo here to see if I can replicate the issue. In the meantime, have you tried using a USB NIC dongle to supply the ethernet? It could be that the onboard ethernet is not fully enabled/stable, which would then impact your powershell/Remote Display/WDP.

[NovTechEng]

Alright so I double checked the ethernet and saw that although it could sucessfully ping, I was dropping a lot of packets due to a poor ethernet clock signal. I fixed this issue and removed the headless config setting in UEFI and now I can successfully use powershell and the Windows Device Portal. For some reason I still cannot connect to the remote display.

[NovTechEng]

This page on Remote Display https://docs.microsoft.com/en-us/windows/iot-core/manage-your-device/remotedisplay suggests that my issue could be related to the fact that I have no display connected to the device. To fix this it says to edit a config.txt file. I don't seem to see this file. Should I add it and if so to what partition?

[christopherco]

I don't see that config.txt in my setup either. config.txt looks to be a raspberry-pi specific file to inform its early bootrom of specific configs like a display parameter.

How are you configuring headless mode? Are you configuring headless mode in IoT Core using these instructions? https://docs.microsoft.com/en-us/windows/iot-core/learn-about-hardware/headlessmode
If so, then without a UI stack, I'm not sure that the Remote Display app will work with this type of headless config.

If you are not configuring headless this way, then in the web portal homepage, do you see a display resolution? The GOP driver in imx-edk2-platforms advertises a basic display device to Windows so even if you don't have a display connected, Windows should still think it has a frame buffer available and draw to it. With this setting I would expect Remote Display to function.

[NovTechEng]

I was previously configuring headless mode by including the line
DEFINE HEADLESS = TRUE
in my .dsc file (UEFI). I have since removed this line and believe I am no longer running headless, I am just running without any display connected.

In the device portal homepage I do see a display resolution, but still cant use the Remote Display or the screenshot feature.

[christopherco]

I got my system together and am able to reproduce the blank screen when connected via Remote Display app. I do see the mouse cursor move on the local display when I move it in the Remote Client so the input side of the app still works.

• With Windows IoT Remote Server disabled in the Web Portal, I can get a screenshot of the display on the Web Portal.
• With Remote Server enabled, screenshot still works.
• With Remote Server enabled and I am connected via the Remote Display app, screenshot does not work unless I press "Capture" and quickly move the mouse in the Remote Client window.

Can you check if you see the same behavior? In the meantime, I will check with the Remote Display team to try and get more info to debug this blank display problem.

[NovTechEng]

Unfortunately I am not having the same behavior. With the Remote Display enabled or disabled, the screenshot feature displays a blank rectangle. I also tried connecting to the Remote Client and pressing capture but then moving the mouse in the Remote Client window, but that still resulted in a blank screenshot.

[christopherco]

Hmm, do you have headless enabled in UEFI? Screenshot feature does not work with headless mode enabled.

One quick way to check if headless is enabled in UEFI is to look at the reported Display Resolution.

• If CONFIG_HEADLESS = TRUE, Display Resolution is 640x480 (64Hz)
• If not headless, GOP driver reports a default Display Resolution of 1024x768 (64Hz)

Also, I have to click the "Capture" button twice to get a screenshot. The first attempt to pull a screenshot always yields a blank picture. Another odd behavior we need to fix...

[NovTechEng]

I do not have CONFIG_HEADLESS = TRUE in my .dsc file for the UEFI that I am using, yet the Display Resolution according to the Device Portal is 640x480 (64Hz). What could be causing this behavior?

[christopherco]

It could be that you are not loading the GOP driver at all in your .dsc/.fdf. Do you have the following sections defined in your dsc/fdf?

https://github.com/ms-iot/imx-edk2-platforms/blob/df6a6a54c499ec5b42b138a7c6c7a68bbf6265e8/Platform/SolidRun/HummingBoardEdge_iMX6Q_2GB/HummingBoardEdge_iMX6Q_2GB.dsc#L54-L67

https://github.com/ms-iot/imx-edk2-platforms/blob/df6a6a54c499ec5b42b138a7c6c7a68bbf6265e8/Platform/SolidRun/HummingBoardEdge_iMX6Q_2GB/HummingBoardEdge_iMX6Q_2GB.fdf#L97-L109

[NovTechEng]

I am pretty sure the GOP driver is being loaded. When I first removed the Headless config from my .dsc file the board would crash when loading that driver (I needed to turn on the clock for the IPU in uboot to fix this). But to answer your question, yes I do have those sections in my dsc/fdf.

Here is a link to my console output from booting the board:
Log.txt

[christopherco]

Thank you for the log.

GopDxeInitialize: Enter 
HdmiDdcRead: Timeout waiting for interrupt 0x00
Imx6DdcRead: HdmiDdcRead failed
InitHdmi: Fail to read HDMI EDID data
GetEdidPreferredTiming: Insufficient EDID data
GetPreferredTiming: EDID data not available, falling back to default timing
**********************
Preferred Timing
**********************
PixelClock 65000000
HActive 1024
HBlank 320
VActive 768
VBlank 38
HSync 136
VSync 6
HSyncOffset 24
VSyncOffset 3
HBorder 0
VBorder 0
EdidFlags 0
Flags 0
PixelRepetition 1
BPP 32
PixelFormat 1
**********************
GetPreferredTiming: --GetPreferredTiming
GopDxeInitialize: - Allocate frame buffer
GopDxeInitialize: Display Memory: Needed=3145728, Available=8388608
GopDxeInitialize: - allocating frame buffer... 
AllocateFrameBuffer: Enter
AllocateFrameBuffer: Frame Buffer AddrP=10000000h
AllocateFrameBuffer: Frame Buffer Size=800000h
AllocateFrameBuffer: Allocate FB PhyAddr 10000000 VirtAddr 10000000
AllocateFrameBuffer: Exit = 0h
GopDxeInitialize: - Initialize the frame buffer to black
GopDxeInitialize: - set display configuration to single HDMI
ImxSetPll5ReferenceRate: PLL 5 setting (65000000) Target Freq 650000000 Divider 5 PostDiv 2
SetHdmiPhy: Fail to write to HDMI_PHY_CPCE_CTRL A0
SetHdmiDisplay: SetHdmiPhy failed
ApplyDisplayConfig: Fail to set HDMI timing
GopDxeInitialize: Fail to set display. Exit Status=Device Error
GopDxeInitialize: Exit = 80000007h

The GOP driver is loaded but it is erroring out during GopInitialize because it could not talk to the HDMI PHY. This error occurs just before the GOP protocol is installed so the display resolution information is never exposed for Windows to see.

It might make sense for us to provide a GopNull driver that just provides display resolution information to the OS and does not attempt to set any hardware. I'll look into writing this driver up today.

In the meantime, could you try modifying the GopDxe driver to remove the ApplyDisplayConfig() call here - https://github.com/ms-iot/imx-edk2-platforms/blob/df6a6a54c499ec5b42b138a7c6c7a68bbf6265e8/Silicon/NXP/iMX6Pkg/Drivers/GopDxe/GopDxe.c#L254-L263
This should remove the attempt to setup the HDMI Phy and allow the GopInitialize to succeed.

[NovTechEng]

Awesome, that definitely helped. I now have the proper resolution on the Device Portal and the Screenshot function is essentially working (Like you mentioned earlier, the first screenshot is blank. Additionally, for subsequent screenshots the preview doesn't update unless you refresh the page but the download option does have an updated image). Unfortunately the remote display is still blank, although I can verify that the input side of the app works (similar behavior to what you mentioned earlier).

[christopherco]

Good to hear that we're on the right track. I made a GopNullDxe driver that just advertises a 1920x1080 display to the OS and does not do any HW configuration. It is in PR right now (ms-iot/imx-edk2-platforms#30) and I hope to merge it in the next couple days.

To use it, you'll need to point your platform dsc/fdf Gop description to this GopNullDxe driver.

The Remote Display Client being blank looks to be a completely independent issue. Will update once I have input from the team that owns it.

[christopherco]

Unfortunately we are not making any major updates to the Remote Display Client at this time. I have queued the issue in the team's backlog but would not expect any updates in the near future.