Board does not boot from eMMC nor via Fastboot Method on neither Mac nor Linux

I have multiple identical Dragonboard 410c boards. I have both Mac OSX and a separate Linux (debian) PC.

Hello, I want to install the Debian Linux image onto the board using the “Install and boot from eMMC SD Card Method.” I have the dragonboard-410c-sdcard-installer-sid-1125.img downloaded. And I followed the Mac OS host computer instructions on how to boot. I have used multiple 128Gb and 32Gb SanDisk SD Cards to download the image on to. I ensured that the S6 Switch is set to 0-1-0-0. When I try to turn on the board, the visual display through the monitor does not display anything. I’ve tried on the other identical Qualcomm boards with the same issue. I’ve tried multiple HDMI cables and monitors, all of which seem to function normally. I’ve retried the procedure on my Linux Host machine following the Linux Host instructions with the same failure.

I then tried flashing via Fastboot Method. The board does not turn on (green LED flashing) after I ensure I’ve turned it on in Fastboot Mode (Holding the S4 Vol (-) button before connecting and thenr eleasing after it’s connected.) Running commands like sudo fastboot devices and lsusb does not display the board while it’s connected via MicroUSB cable to the Host PC. I’ve tried different ports, boards, microUSB cables all with the same issue.

The board does boot up normally (to the Android OS) in default mode (S6 to 0-0-0-0). I’ve tried going to the Storage settings in the default mode and seeing how it’s reads the SD Cards. It says that the SD Card is damaged and cannot be mounted.

Hmmm… I never tried it with a 128GB or 32GB SDCard, I always used a 8GB card and it worked fine. That said, I haven’t personally tested dragonboard-410c-sdcard-installer-sid-1125.img so I can’t say if that particular image works or not.

I’m pretty certain there is a bug in the latest installer images that can make booting it unreliable (details here: ).

In my case the installer fails to boot about 75% of the time. However, with patience and lots of power cycles, I am eventually able to get the installer to boot.

Note that you can use the LEDs to distinguish a good boot from a bad boot (which allows you to power cycle more quickly). A good boot has LED3 (disk activity) flashing for a fairly long time. During a “bad” boot LED3 flashes for only half a second before going out and leaving nothing but the “heartbeat” pattern on LED1.

The LED3 does flash for quite a bit of time. I’d say around 30 seconds of sporadic flashing, as well as LED 2 and 1. But after about 30 seconds only LED 1 flashes the “heartbeat” signal periodically.

If you are getting that much disk activity then I don’t think you are experiencing the problem I described in the bug report. Settling down to just the heartbeat is normal (the heartbeat is there to show the kernel is “alive”… and it flashes a little faster as the kernel gets busy).

The best tool to debug further is a 1.8v UART to USB adapter since you’d be able to see the kernel messages and figure out what is going on.

Other things worth trying are different power supply if you have one (what spec have you currently got connected to the board?) and/or a different HDMI display device.

So I’ve tried flashing with Ubuntu-Core for the Dragonboard 410c and it works (hdmi shows, I can begin the setup process). It seems like the Debian image may be the issue.

I’m currently using a 12V 6A power supply. I started with a 12v 2A (I believe the minimum requirements are 6-18V, 2000mA) and I kept moving up to 3A, 4.5A and 6A. I’ve tried a different HDMI cable and monitor.

I currently don’t have access to a 1.8v UART to USB adapter but I can get one.

So I’m pretty sure the problem is with the image itself. I went to the Debian Releases page (copied the download link for the SD Card image Option 1 and edited the url) and installed multiple earlier versions of the Debian Images. 1089 (from 21.08) didnt work. But from 17.06 worked. I will be using that version. Though this seems to be an image problem and should be resolved by Linaro/Qualcomm.