I took the 2.2.rc4[1] image and burned it into an SD card and tried to boot a minnow board with nothing else connected than the power and the FTDI serial cable. I get to the boot params screen okay then I get this message: error: no suitable video mode found. Booting in blind mode. At this point I don't know if it booted but I would expect to see the terminal populating with the boot messages then a login console. I did md5sum-checked[2] the image before burning. [1] http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc4/machines/genericx86-64/core-image-sato-sdk-genericx86-64.hddimg [2] http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2.rc4/machines/genericx86-64/core-image-sato-sdk-genericx86-64-20161017230136.hddimg.md5sum
Steps to reproduce: 1. Download the 2.2.rc4 sato-sdk image (see link[1] above) 2. burn the image to an sd card then insert it to the minnow board 3. attach an FTDI cable to the minnoboard and to your machine where you can see the terminal output in your favorite serial reader (I use minicom) 4. start the board and try to boot it. Expected behavior: The board boots through the serial console and gives you a login session. Actual behavior: The screen message 'Booting in blind mode' appears and nothing else from there.
I tried to boot it again but this time with a video cable attached and it starts to boot at the video output until: waiting for root device: /dev/mmcblk0p2 Where it gets stuck. So the final result, in any case is that it doesn't boot. Updating the title. My next test is to see if it boots from USB.
The same image is able to boot from USB. Trying another SD card to rule out bad media.
A second SD card was tried and the same error appears so this rules out bad media. Next thing to try is a BIOS update since the minnow board I am testing with has the factory BIOS which is versioned as number 90. Most current is version 93 according to the support page: https://firmware.intel.com/projects/minnowboard-max
Updating the BIOS to the latest available version still doesn't boot the board so ruling out BIOS version.
Tested on an additional Minnowboard also with the latest BIOS version (first minnow board was turbot this one is CircuitCo's) and the error persists, it can't boot. This bug is 100% reproducible and critical as it can't boot from SD cards.
A couple of other people has executed the test and they don't see the issue. Exploring the difference between my procedure and theirs which is that I use mkefidisk.sh as stated in the documentation and they use plain dd. I did my testing with dd as well and got the same image to boot from an SD card which means either my machine or the mkefidisk.sh is failing to transfer correctly to the media. Testing on that now.
I made some tests using the same image (2.2.rc4) with a Minnow Max 64 and bios version 90. My results were: -Using plain dd, I could not reproduce the issue. -Using mkefidisk.sh with '/dev/mmcblk1' as the target device, the startup.nsh script tried to boot from 'fs0:\EFI\BOOootx64.efi' which was not recognized as a command, as for some reason the path and file name was truncated. However, after manually executing 'fso:\EFI\BOOT\bootx64.efi', the DUT completed its booting process correctly. -Using mkefidisk.sh with '/dev/mmcblk0' as the target device, the startup.nsh script tried to boot from 'fs0:\EFI\BOOootx64.efi' again. However, after manually executing 'fso:\EFI\BOOT\bootx64.efi', the DUT got stuck on its boot process waiting for root device: /dev/mmcblk0p2
the issue now points at the mkefidisk.sh script, which is what the docs tell you to use for creating the image. As the image looks fine, I will change product and component for this bug away of runtime/runtime.
I can look at it if needed. I did similar work for wic lately. BTW, wic images are produced by default for genericx86-64 machines and bootable out of the box. 'blind mode' issue is also fixed there.
I booted a wic image earlier today and I saw that the blind mode issue is fixed, that's great. The reason why I am following on mkefidisk.sh up is because it's listed in the documentation. See step 4 of the Building Images guide[3] from the mega-manual. [3]http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#qs-building-images One option would be to change the documentation to refer to the wic procedure instead of fixing the mkefidisk.sh script.
Created attachment 3481 [details] building images doc change proposal This is a suggestion to the YP-2.2 documentation that fixes this bug by deprecating mkefidisk.sh in favor of dd with a wic image. As a side note, this new procedure could be set to use the .hddimg instead with just an extension change.
Benjamin, See http://www.yoctoproject.org/docs/2.2/yocto-project-qs/yocto-project-qs.html#qs-building-images (second step 4) for the change. This change is in the YP Quick Start, which is sucked into the mega-manual. You will see that I did a little re-wording from your suggested change. Also, I am assuming you meant "TARGET_DEVICE" and not "HOST_DEVICE" in the final wrap-up sentence as "HOST_DEVICE" is not in the command. The other option would have been to change the string in the actual command. I took a guess. If I am wrong tell me and I will fix it. So, check out the change and let me know if it is okay. Thanks, Scott
(In reply to comment #13) > Benjamin, > > See > http://www.yoctoproject.org/docs/2.2/yocto-project-qs/yocto-project-qs. > html#qs-building-images (second step 4) for the change. This change is in > the YP Quick Start, which is sucked into the mega-manual. > Thanks, I reviewed it. Comments below. > You will see that I did a little re-wording from your suggested change. > Also, I am assuming you meant "TARGET_DEVICE" and not "HOST_DEVICE" in the > final wrap-up sentence as "HOST_DEVICE" is not in the command. The other > option would have been to change the string in the actual command. I took a > guess. If I am wrong tell me and I will fix it. The way you wrote it as TARGET_DEVICE makes sense. > > So, check out the change and let me know if it is okay. I spotted the following inconsistencies that I believe can be fixed impromptu: - The previous step, numbered 3.Build an Image for MinnowBoard MAX ends up showing an image with the hddimg extension. that should be changed for the wic extension as it is the one we're using in step 4. - On the same step 3, the image that is built is the core-image-base; I wrote the suggestion based on the core-image-minimal which is what 2.1 uses in this same part of the documentation. If core-image-base is to be used, then the command in step 4 has to use core-image-base: $ sudo dd if=tmp/deploy/images/intel-corei7-64/core-image-base-intel-corei7-64.wic of=TARGET_DEVICE > > Thanks, > Scott in sum, 2 changes, use .wic instead of .hddimg and core-image-base instead of core-image-minimal. All of this within that particular set of instructions only.
Benjamin, Check out steps 3 and 4 in http://www.yoctoproject.org/docs/2.2/yocto-project-qs/yocto-project-qs.html#building-an-image-for-hardware. I think we are okay now. Let me know and I will reset the bug. Thanks, Scott
Thank you Scott, seems like your updates are accurately fixing my previous comments. I just spotted there is this sentence at step 4 Write the image: ...(e.g. /dev/sdc, which is most likely a USB stick, or /dev/mmcblk0, which is most likely an SD card. That statement needs a closing parenthesis. I believe that would be the only thing that needs changing at this point. I think you can close it once the parenthesis is added.
Benjamin, Good catch. I fixed it - http://www.yoctoproject.org/docs/2.2/yocto-project-qs/yocto-project-qs.html#building-an-image-for-hardware. Setting the bug to RESOLVED and putting the doc flag to "done." Scott
Good, since I've verified your changes I'm setting it to verified state.