This is a cache of https://discuss.96boards.org/t/fastboot-not-responding/1095. It is a snapshot of the page at 2024-10-31T04:51:23.428+0000.
Fastboot not responding - DragonBoard410c - 96Boards Forum

Fastboot not responding

Products Support DragonBoard410c
#1

System Specifics:

Host OS: x86_64 ubuntu 16.04 LTS
$ uname -a
Linux t430 4.4.0-53-generic #74-ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ java -version
openjdk version “1.8.0_111”
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

$ fastboot --version
fastboot version 302830efc153-android

Problem description:

I am trying to use fastboot to boot my own kernel from a Debian[1] based installation but the dragon board (consumer edition) is not recognised, i.e “fastboot devices” returns nothing.

From the board’s factory Image I installed Debian using the SD card method. Installation was successful and Debian booted just fine. From there I switched off the board, removed the SD card, reset S6 to 0-0-0-0, held the S4 button, powered the card again and released S4. No matter how long I wait “fasboot devices” (called as “root”) never finds anything.

The serial port is connected to the host and “/dev/ttyUSB0” is created, so that part is alive.

On ubuntu 16.04 “fastboot” can be installed using apt-get. Two packages are available: “fastboot” and “android-tools-fastboot”. I tried both (with root privileges) and neither is working. I also installed exactly the same android SDK[3] as described in the youtube video[4] to no avail.

The same happens when an Android Image[2] is installed on the board.

Is this a bootloader problem? Is anyone else experiencing issues?

Thanks,
Mathieu

[1]. https://www.96boards.org/documentation/ConsumerEdition/DragonBoard-410c/Downloads/Debian.md/
[2]. https://www.96boards.org/documentation/ConsumerEdition/DragonBoard-410c/Downloads/Android.md/
[3]. https://downloads.puresoftware.org/files/android/SDK/android-sdk_r24.4.1-linux.tgz
[4]. - YouTube

#2

Hi Mathieu

I’m running Debian 16.09 and cannot reproduce this. I’m able to get fastboot connected with the S6 in both 0-0-0-0 and 0-1-0-0 and regardless of whether or not I have something plugged into the type A sockets.

You mentioned that you could see, via the serial port, that the part is alive. Does the serial port show that the bootloader has switched to fastboot mode? Something like:

...
[80] fastboot_init()
[80] Error: ssd partition not found
[190] USB init ept @ 0x8f691000
[210] udc_start()
[420] -- reset --
[430] -- portchange --
[490] -- reset --
[490] -- portchange --
[570] fastboot: processing commands

If do you see hotplug activity on both ttyUSB0 and the host PC kernel logs when you insert/remove the USB micro-B?

PS For kernel development, a really great trick is to zero out the boot partition! That relieves you of the burden of having to hold down SW4 every time you turn the board on.

#3

I found the problem this morning.

Next to the SDCARD outlet (J5) is a hole for a screw. Flipping the card over and looking at that same hole one can notice the edge of the rounded bronze circle is very close to the component next to J15. So close that it is easy for a slightly bigger leg to make contact with the closest pins and introduce a short. Remove the leg and everything works properly.

Thanks,
Mathieu

#4

Am trying to figure out if you are/were suffering from a potentially common fault or just had a bit of freakishly weird bit of bad luck (either way its great that you solved it).

IIRC J15 is the (unpopulated) debug connector isn’t it. Agree that one of the pads for this is very near the bronze circle. Did you populate J15 yourself or was a solder bridge between the pads and the earth on the bronze circle formed during manufacture (or have I just got completely the wrong idea)?

#5

J15 is still unpopulated but I used a set of legs to prep-up the board. The diameter of the leg is smaller than the bronze circle on the card but the hole in the card bigger than the screw I used (as it is usually the case). When securing the leg in place it shifted in the hole and made contact with the closest pins, creating some sort of short that held the processor in reset.

#6

Wow! Interesting problem! That said, it does sound freakish enough that there’s no need to FAQ it…