Can't Get Hummingboard to Boot From eMMC

[kiwikissling]

I'm having problems getting IotCore os and default app firmware into eMMC. We are looking for ways to deploy our product into the field without having the OS and our app on SD card. The first step is to get vanilla IoT Core booting from eMMC, ie long before we add our app package

Setup:

• 1 old, not-familiar-with bootloder-stuff coder(!)
• Hummingboard + Edge carrier board
• Successful build of imx-iotcore for my target board.
• Successful use of IoT Dashboard to flash a SD card that successfully boots iot core on the target board
• Successful use of winpe-mmc.cmd to build, and then apply a WinPE image to a SD card following this guidance

Actions:

• Leave Hummingboard jumpers set to boot-from-SD
• Place SD card in Hummingboard and power up
• Windows starts to boot and then flips to command shell running, if I remember, winpeinit. This takes quite a while. The device re-boots, and I can confirm the EFI directory in the root of the SD card had been renamed to _EFI
• Wait 3 seconds to bypass boot options

Result:

I would have expected Windows to have booted from eMMC, and the default app to startup.

@dvescovi1 @jordanrh1 - Any suggestions as to what I'm doing wrong and/or what I should try?

[christopherco]

From the output, looks like the eMMC was not provisioned while in WinPE. After a successful flash, your EFI shell should see multiple block partitions like this:

To debug further, I recommend booting into WinPE again and making sure the eMMC flashing step succeeds

imx-iotcore/build/tools/make-winpe.cmd

Line 107 in 3cccdb0

echo dism /Apply-Image /ImageFile:c:\Flash.ffu /ApplyDrive:\\.\PhysicalDrive%FFU_DISK_NUM% /skipplatformcheck >> "%STARTNET_CMD%"

(minus echo and console redirection to file)
In our WinPE startup script, we hardcode %FFU_DISK_NUM% to 1 since we always assume the same SD/eMMC enumeration pattern. If you want to confirm the physical drive number, you can do the following in the WinPE command line:

diskpart
list disk

and confirm which disk number corresponds with the eMMC.

If the dism command fails, there is a debug log that gets printed. Please post that here.

[kiwikissling]

Thanks @christopherco. I will give this a try

[kiwikissling]

@christopherco, This is pretty uncharted waters for me, so I'm not sure if I'm even asking the right thing. I can confirm our SD card presents as Disk1 on my build machine.

Regarding dism /Apply-Image /ImageFile:c:\Flash.ffu /ApplyDrive:\\.\PhysicalDrive1 /skipplatformcheck, I worked out that this command gets baked into startnet.cmd on the SD card, and I presume this script is executed when booting the Hummingboard with the SD inserted.

Are you suggesting that I execute dism /Apply-Image /ImageFile:c:\Flash.ffu /ApplyDrive:\\.\PhysicalDrive1 /skipplatformcheck from the UEFI Shell> _ prompt? I have tried this and it's bugged out saying 'dism' is not recognized as an internal or external command ..

[christopherco]

Overall, this can be a bit confusing. I'll try my best to explain.

The SD card gets loaded with a WinPE image. WinPE is a very lightweight Windows image and the UI is a minimal desktop UI and a command prompt. We set up a startnet.cmd to be a startup script that runs on bootup into WinPE. Dism is a executable built in the WinPE environment and is meant to provision images onto drives.

In the boot sequence, UEFI finds a bootable Windows image by searching for and executing a EFI/boot/bootarm.efi application in the FAT32 partition (typically dubbed the EFI partition). So after we run WinPE once, to prevent further booting into the WinPE image the script renames the EFI folder to _EFI which prevents UEFI from finding the WinPE's bootarm.efi application.

I think what you'll want to do is:

1. Plug in the SD card into your build machine and rename the _EFI folder to EFI. This will re-enable the boot into the WinPE image.
2. Remove the SD card and place it in the Hummingboard. Boot up with keyboard connected. It should boot into the WinPE desktop environment and you should be greeted with a command prompt.
3. Since there is a startup script set to run, you'll want to mash Ctrl-C to quit out of the start up script and gain control of the command prompt.
4. At this stage, you should be able to execute the dism command:
   dism /Apply-Image /ImageFile:c:\Flash.ffu /ApplyDrive:\\.\PhysicalDrive1 /skipplatformcheck

Hope this helps. If you have further questions, I'm happy to answer.

[kiwikissling]

@christopherco thanks for this detailed response. You clearly know this stuff pretty well, and I'm learning lots from you. Appreciated. I will get back to this eMMC spike shortly. Current working on an end-to-end script supporting a retail build.

[kiwikissling]

Hi @christopherco, after quite a break I'm back working on this. While I'm still using a Hummingboard, significantly we now have our own carrier board and are no longer using Solid-Run's 'Edge' carrier board. Our own carrier board ('Scout') had no display, and no keyboard - It's an automotive IoT device, and we've been booting from SD, loading apps etc.

Today I have worked through the Booting WinPE and Flashing eMMC guidance, resulting in an error-free creation of a boot image. So far, so good.

I then booted successfully, and later noted that the EFI directory on the SD was renamed to _efi. But... it looks to me that flashing to eMMC hasn't worked. I've attached a boot log. Would you mind having a quick look and suggest what I might try next?
HummingboardBootWithWinPE.txt

[christopherco]

The boot log appears to indicate you are indeed booting into Windows on both of the boots.

KDTARGET: Refreshing KD connection

is the message printed from within Windows where the Windows Kernel debugger is trying to establish a connection with the host Windbg session. Usually a good sign that things are up and running successfully. And you can attach to Windbg to confirm everything is still working.

Unfortunately we do not print out which boot device we are booting from so it is not possible to definitively tell if we actually did boot from eMMC or not. Probably something we should add 😃

But if your SD card has the efi folder renamed to _efi, then UEFI will not attempt to boot Windows from that renamed folder. UEFI scans through all boot devices (in "Boot Order") for \efi\boot\bootarm.efi and boot the first one it finds. So by process of elimination, you should be booting from eMMC then.

What is the behavior you are seeing?

[kiwikissling]

Hi Christopher, I may have re-represented what happened here. That boot log was from the first boot on WinPE. However I've now ended up with a (bricked?) SOM.

Regardless of how the boot jumpers are configured, it won't boot without a SD inserted, and it won't boot with a SD card inserted (generic IoT Core build). I've gone back to doing all on Solid Run's OEM carrierboard known a 'Edge' to remove any likelihood of our own carrier board cause some kind of fault.

So the issue has shifted from getting WinPE to boot, to getting the SOM back from the brickyard! Any suggestions on that very gratefully received :)