search

ms-iot / imx-iotcore

Windows 10 IoT Core BSP for NXP i.MX Processors
MIT License
64 stars 42 forks source link

Build EVK_iMX6ULL_512MB #28

Open tmengicam opened 5 years ago

tmengicam commented 5 years ago

We would like to build the Windows IoT Core for EVK_iMX6ULL_512MB. We have started to build the bootloader but the defconfig (imx6ull_14x14_evk_nt_defconfig) in the Makefile (imx-iotcore/build/firmware/EVK_iMX6ULL_512MB/Makefile) in ms-iot/u-boot repository. Maybe the defconfig get lost in the migration from private preview to public preview. Does anybody try the EVK_iMX6ULL_512MB? Thank you.

Best regards,

Tommaso Mazzoni

christopherco commented 5 years ago

@henie did the initial EVK_iMX6ULL_512MB bringup. Do you happen to know?

tmengicam commented 5 years ago

Any update? @henie did you try the EVK_iMX6ULL_512MB?

christopherco commented 5 years ago

Hi Tommaso (@tmengicam) Looks like we recently merged in the EVK_iMX6ULL_512MB files into the public u-boot repo.

https://github.com/ms-iot/u-boot/pull/10

Please check it out and let us know if you have any issues.

christopherco commented 5 years ago

Closing issue. Please reopen if you encounter issues building the iMX6ULL.

tmengicam commented 5 years ago

Hi, we have got custom board with the iMX6ULL and now we are able to boot the system. The board is very similar to the EVK_iMX6ULL_512MB so the standard u-boot and uefi are good to perform a complete boot of Windows 10 IoT Core. On our board we a have an LCD display (as on the EVK_iMX6ULL_512MB) so we try also to use the graphics. I modified the driver for iMX7 (LcdifGop), I set all the register address and the driver is working fine. The problem is that after the uefi boot the LCD data disappears. If I enter in the UEFI menu the display disappears after 4-5 seconds. If Windows starts the boot the display disappears during the Windows boot. Does anybody succeed in use the LCD on iMX6ULL? Thank you. Best regards,

Tommaso Mazzoni

christopherco commented 5 years ago

Unfortunately, I do not have access to a ULL platform. Adding @henie in case he can help here.

As far as debugging goes, you can limit the variables by first getting the display stable in the EFI environment (i.e. stable when in EFI Shell). Does your U-Boot implementation also bring up the LCD? If so, you can try comparing the LCD registers when in U-Boot Shell vs. EFI Shell through the serial debug console.

Also if U-Boot does initialize the LCD, you could also modify LcdifGop to only do the frame buffer configuration in the hardware (see https://github.com/ms-iot/imx-edk2-platforms/blob/3904ea6e96b9d2a1b739791bdef0fc3614849762/Silicon/NXP/iMX7Pkg/Drivers/LcdifGop/Lcdif.c#L171-L177) and keep the rest of the LCD settings from U-Boot.

tmengicam commented 5 years ago

Dear christoperco, I cannot get the display stable in the EFI environment, after entering in the UEFI menu the display disappear. We don't implement the LCD bring up in the U-boot but we can try to do it. In any case I believe that LCD driver in UEFI is working fine, otherwise we cannot see anything on the dispaly. After the display disappear we can dump the LCD registers in the debug console, the registers seems to be well configured (even the framebuffer) but the FIFO is empty (no data coming from the framebuffer) and no data is transmitted by the LCDIF. Thank you again.

tmengicam commented 5 years ago

Dear all, disabling the LCD I can start the windows boot but it stacked soon. I attached the log of windbg. The problem seems to be related with the boot device. We are using a custom board with iMX6ULL based on the evaluation board. I already set the uSD (boot device) in the .dsc file and I configure the card detect GPIO in the in the iMX6BoardInit.c. Could someone help me? windbg01.txt

christopherco commented 5 years ago

Looks like Windows could not access the SD device. Since you were able to load Windows and get to this point, your uSDHC PADs and CLKs seem to be fine.

Which SDHC controller are you booting from? And did you update your board's ACPI tables? The EVK Dsdt-Sdhc.asl table only enables SDHC1 - https://github.com/ms-iot/imx-edk2-platforms/blob/imx/Platform/NXP/iMX6ULL_EVK_512MB/AcpiTables/Dsdt-Sdhc.asl

tmengicam commented 5 years ago

I solved the problem selecting the right ALT function of the SDHC card detect MUX. Now the boot seems to go over and the debugger doesn't connect after the messages: IOINIT: Built-in driver \Driver\sacdrv failed to initialize with status - 0xC0000037 KDTARGET: Refreshing KD connection Since the LCD is not working well (see previous comments), I'm now trying to turn on the ethernet and use it to communicate with Windows IoT Core.

tmengicam commented 5 years ago

Dear all, I'm still trying to use the ethernet. I fuse the mac address with u-boot and I initialize the device in the iMX6BoardInit.c. Ethernet LEDs are blinking but I cannot see the board on the LAN. I even did not understand if we can finish the boot. The Windbg shows the messages in my last comment and then nothing... How can I debug my system?

christopherco commented 5 years ago

Best bet is to use Windbg to debug your system.

In the current headless state, to get confidence that you've finished Windows boot you can check if you've launched the IoTCoreDefaultApp.exe in Windbg.

  1. Let the system run for a few minutes to allow all the processes and drivers to start up
  2. Break in in Windbg
  3. In Windbg, run .reload to load the debugging symbols
  4. Dump the running processes using !process 0 0
  5. Look for the IoTCoreDefaultApp.exe or IoTShell.exe processes. If they are running, you've booted into the default application.

I've uploaded the output from my system - process.txt

To debug the networking driver, I believe you need to rebuild the driver with DEBUG on.

  1. Set Solution to DEBUG/ARM
  2. Uncomment this line in the imxnetmini.sys driver: https://github.com/ms-iot/imx-iotcore/blob/9e82401a927cdb396c43d892b8e74106f0ebb953/driver/net/ndis/imxnetmini/mp_dbg.h#L110
  3. Rebuild the driver
  4. Locate where to copy your new imxnetmini.sys on the SD card. Typically it is in the MainOS partition:\Windows\System32\DriverStore\FileRepository\imxnetmini.inf_arm_<random characters>\imxnetmini.sys. If you do not see the MainOS partition, you can use disk management utility to assign a letter to the MainOS volume.
  5. Copy imxnetmini.sys to your main OS. Couple ways to do this - you could copy it manually to the location you found above or you could use Windbg .kdfiles (https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-kdfiles--set-driver-replacement-map-).

Adding @mvarecha as he is more familiar with the ENET driver.

tmengicam commented 5 years ago

I've booted into the default application and I've rebuild the driver with DBG_MESSAGE_PRINTING but I don't understand how to see debug messages. With the windbg I check the status of the device node (devnode) and I get:

  DevNode 0x905f0c28 for PDO 0x904f74d8
    InstancePath is "ACPI\NXP010D\0"
    ServiceName is "imxnetmini"
    State = DeviceNodeRemoved (0x312)
    Previous State = DeviceNodeStartCompletion (0x306)
    Problem = CM_PROB_FAILED_START
    Problem Status = 0xc0000001
    Failure Status 0000000000

I have the same problem also on the SabreLite. We have Boundary SabreLite so try to build an image and boot it. We fuse the mac address and boot the system, everything seem to work fine except the Ethernet that give the same error message. What I'm doing wrong?

mvarecha commented 5 years ago

How to enable imxnetmini.sys debug messages 1) Uncomment lines 110, 119 and 132 in mp_dbg.h

define DBG_MESSAGE_PRINTING

#define DBG_DRV
#define DBG_ENET_DEV

2) Rebuild the driver 3) Switch OFF the board 4) Start WinDbg (Be sure the debugger will breakin at the next boot "Debug\Kernel Connection\Cycle initial break" or Ctrl+Alt+K) 5) Switch ON the board 6) Wait until debugger is connected 7) Type: .kdfiles -m imxnetmini.sys E:\Win10\Git\iMX6_SX_NXP\imx-iotcore\build\solution\iMXPlatform\Build\ARM\Debug\imxnetmini\imxnetmini.sys where the third parameter is full path to the "imxnetmini.sys" you have compiled in step 2. You can type ".kdfiles" (without parameters) to check it mapping is OK. 8) Type: ed nt!Kd_IHVDRIVER_Mask 0xFFFFFFFF 9) Type: g

If everything is OK you should first see:

KDFILES: Replacing '\SystemRoot\System32\DriverStore\FileRepository\imxnetmini.inf_arm_3258f91516197878\imxnetmini.sys' with 'E:\Win10\Git\iMX6_SX_NXP\imx-iotcore\build\solution\iMXPlatform\Build\ARM\Debug\imxnetmini\imxnetmini.sys'. File size 68KB. KdPullRemoteFile(86B11080): About to overwrite \SystemRoot\System32\DriverStore\FileRepository\imxnetmini.inf_arm_3258f91516197878\imxnetmini.sys and preallocate to 10ef8 KdPullRemoteFile(86B11080): Return from ZwCreateFile with status 0

and then ENET driver debug information:

C0 D0 ENETx:DriverEntry +++ Driver: 0x8A5ECA58, '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\imxnetmini') C0 D0 ENETx:DriverEntry ***** C0 D0 ENETx:DriverEntry * NXP ndis miniport driver, date: May 17 2019 15:30:34 * C0 D0 ENETx:DriverEntry ***** C0 D0 ENETx:DriverEntry --- [0x00000000] C0 D0 ENETx:MpInitializeEx +++ Adapter handle: 0x8A5DF0E8 C0 D0 ENETx:MpAllocAdapterBlock +++ Adapter handle: 0x8A5DF0E8 C0 D0 :MpAllocAdapterBlock --- [0x00000000] C0 D0 ENET0:MpInitializeEx ENET MAC address: 00-04-9F-03-36-D6 (from ACPI) C0 D0 ENET0:NICReadRegParameters +++ C0 D0 ENET0:NICReadRegParameters --- [0x00000000] C0 D0 ENET0:MpInitializeEx ENET MAC address: 00-04-9F-03-36-D6 (used by device) C0 D0 ENET0:MpInitializeEx MemPhysAddress(Low) = 0x02188000 C0 D0 ENET0:MpInitializeEx MemPhysAddress(High) = 0x00000000 C0 D0 ENET0:MpInitializeEx InterruptLevel = 0x96 C0 D0 ENET0:MpInitializeEx InterruptVector = 0x96 C0 D0 ENET0:MpInitializeEx InterruptLevel = 0x97 C0 D0 ENET0:MpInitializeEx InterruptVector = 0x97 C0 D0 ENET0:MpInitializeEx MDIO Controller address was not found in ACPI. ENET Controller address will be used. C0 D0 ENET0:MpInitializeEx ENET Controller Physical Address = 0x00000000_02188000 C0 D0 ENET0:MpInitializeEx MDIO Controller Physical Address = 0x00000000_02188000 C0 D0 ENET0:MpInitializeEx MDIO bus ENET PHY Address: 1 C0 D0 ENET0:MpInitializeEx ENET PHY interface type was not found in ACPI. RGMII will be used as default. C0 D0 ENET0:NICAllocAdapterMemory +++ C0 D0 ENET0:NICAllocAdapterMemory --- [0x00000000] ENET0 ENET device address: 0x00000000_02188000, Irq: 0x96, MAC: 00-04-9F-03-36-D6 MDIO device address: 0x00000000_02188000(MDIO0), ENET_PHY address: 1, MDIO clock 2357[kHz], MDIO hold time 15[ns], Preamble: Yes ENET PHY ID: 0x004DD074, type: RGMII, name: AR8031/AR8033 C0 D0 ENET0:MpInitializeEx --- [0x00000000]

10) Check if MAC address is valid. (ENET MAC address: 00-04-9F-03-36-D6 (used by device)) Check if ENET PHY address is valid (see your board schema). (ENET_PHY address: 1) Check if ENET PHY is supported by the driver. (ENET PHY ID: 0x004DD074, type: RGMII, name: AR8031/AR8033) Marek Varecha

tmengicam commented 5 years ago

Thank you Marek!!! I start to debug the ENET interface. We have a LAN8710 PHY that is not in the devices list of imxnetmini so I added the device. Since it similar to the KSZ8091 I use the KSZ8091 configuration. Now the device is UP but I got an error after the setup, "C0 D2 ENET0:MpCheckForHangEx ERROR !!!TX is hang!C0 D0 ENET0:MpCheckForHangEx ERROR !!!Requesting Reset by NDISC0 D2 ENET0:PHYDev_UpdateLinkStatus +++". The device seems UP but the LAN connection is not working. I attach the complete debug log. windbg04.txt

tmengicam commented 5 years ago

We solved the problem with the ENET. Now we start again to debug the LCD interface, we will keep update. If someone has some suggestions we will appreciate.

tmengicam commented 5 years ago

Dear all, I am still working on this (annoying) problem with the LCD. I try to summarize the problem to see if someone could help us. We are able to setup the LCD: we setup the MUX and PAD in the iMX6BoardInit.c and we build the LcdifGop driver starting from iMX7 one. During the startup the LCD is working, the framebuffer is properly configured and we are to see even the frontpage of the edk2 UiApp. We the UiApp disappear when, in the function "CallFrontPage" in edk2/MdeModulePkg/Application/UiApp/FrontPage.c, it is called the "SendForm". I had to set PcdPlatformBootTimeOut to 0 (zero) to launch the UiApp because otherwise the LCD disappear when is called the function BdsWaitForSingleEvent in BdsWait of edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c. Setting the timeout to 0 I skip the function BdsWaitForSingleEvent. Any ideas? Thank you again.

christopherco commented 5 years ago

One random idea - could your frame buffer be allocated in memory that other UEFI components could possibly write over?

This shouldn't be an issue if you are using the NoncoherentDmaLib and the DmaAllocateBuffer() call to create and reserve memory for your frame buffer but I figure I would mention this possibility since we ran into it before.

https://github.com/ms-iot/imx-edk2-platforms/blob/9249fd6ad62317ae9e6e7218dd70a7699f8bad31/Silicon/NXP/iMX7Pkg/Drivers/LcdifGop/LcdifGop.c#L195

tmengicam commented 5 years ago

We already had a look to the allocation of the frame buffer and we change the allocation using:

LcdifDisplayContext.FrameBuffer = (VOID*)FixedPcdGet32(PcdFrameBufferBase)

were PcdFrameBufferBase point to 0x80000000. In both case (DmaAllocateBuffer and fixed address) the result is the same.

tmengicam commented 5 years ago

An update: when the display disappear the LCDif goes in UNDERFLOW (UNDERFLOW_IRQ_EN bit 14 of LCDIF_CTRL1n). I hope that this could help

christopherco commented 5 years ago

I wonder if the panel timings are correct. Are you able to read the EDID from the panel or are you falling back to the DefaultTiming? We have seen some panels report back incorrect timings in their EDID and it caused some unexpected display behaviors.

You could try hardcoding the expected timing settings by forcing the use of the default timing structure and changing the hardcoded values.

https://github.com/ms-iot/imx-edk2-platforms/blob/9249fd6ad62317ae9e6e7218dd70a7699f8bad31/Silicon/NXP/iMX7Pkg/Drivers/LcdifGop/LcdifGop.c#L92

tmengicam commented 5 years ago

We are already forcing a fixed timing for our display. Panel timings are good. We didn't implement the possibility to read the EDID from the panel. We don't have a panel link transmitter and we are not using part of the driver in: https://github.com/ms-iot/imx-edk2-platforms/blob/9249fd6ad62317ae9e6e7218dd70a7699f8bad31/Silicon/NXP/iMX7Pkg/Drivers/LcdifGop/LcdifBoard.c Thanks again.

christopherco commented 5 years ago

Just FYI - There is a new PR to enable RGB display on the ULL https://github.com/ms-iot/imx-edk2-platforms/pull/44 Wonder if this can help you out.

tmengicam commented 5 years ago

Great! Thank you so much. Looking the code of DachunRao I found the problem. I developed the driver and the libraries very similar to DachunRao but I was setting the lcd_clock_enable (in https://github.com/DachunRao/imx-edk2-platforms/blob/imx/Silicon/NXP/iMX6Pkg/Library/iMX6ULLClkPwrLib/iMX6ULLClkPwr.c) with IMX6ULL_RUN_ONLY instead IMX6ULL_RUN_AND_WAIT. Now the display is working in Windows IOT and in the UEFI BIOS setup. I still cannot use Windows IoT Remote client, we I connect I got only a blank screen. If I move the mouse on the blank screen the pointer on the display moves to so the connection is working. If I ask for a snapshot from the "Device Portal" I got a good one but the remote IoT client still gives me a blank screen.

christopherco commented 5 years ago

Great to hear display is stable now!

Regarding the Windows IoT Remote Client, unfortunately it does not work with the current i.MX+IoT Core setup. https://github.com/ms-iot/imx-iotcore/issues/66 We've filed a bug against the Remote Client but would not expect any updates in the near future.

tmengicam commented 5 years ago

Dear all, I'm still working on our IMX6ULL based custom board. Now I am trying to get work the USB. Our board has an USB type A connected to the USB PHY1, like the EVK_iMX6ULL. The design of our USB is the same of the Evaluation Board so I was expecting to get it work without problems. USB is really working on EVK_iMX6ULL?

tmengicam commented 5 years ago

Some update: USB keyboard is not working during the boot (UEFI) and on Windows. On Windows "devcon" command get this error message: administrator@MINWINPC C:\Data\Users\Administrator>devcon status usb USB\ROOT_HUB20\3&3AB19331&0 Name: USB Root Hub Driver is running. USB\VID_0000&PID_0001\4&25973D74&0&1 Name: Unknown USB Device (Port Reset Failed) The device has the following problem: 43

USB pen drive instead are working.

christopherco commented 5 years ago

Please add the following Name (_HRV, 0x1) to your board's Dsdt-Usb table. This will advertise the TT block to Windows and allow for low-speed device enumeration.

https://github.com/ms-iot/imx-edk2-platforms/commit/836a212a811f78549f5399cae433255e8ebad86c