Confusion with Hikey960 and ADB

Products Support HiKey 960
#1

Hellow folks

Just got my hikey960 as we’re looking to use it for our project since db410c is slow for Android

so, I’m experiencing a weird behaviour with it and I hope someone can clarify a bit

I’ve built/flashed the latest master following Using Reference Boards  |  Android Open Source Project

Then, changed the switch to 1-0-0 and power-cycled…

After the boot works fine, I’m on Android Pie again…

The problem is:

If I plug the OTG/USB-C cable, few seconds later, it turn off the board, unplug the power, wait a bit, power again, it powers, but on fastboot mode…

Unplug the power again, plug the power again, it boots on Android again, and I can see it on adb devices list…

So, first question is… how to avoid the reboot when I plug the USB-C cable and also to avoid to always reboot again in order to skip the fastboot mode?

The other question is… once I’m on adb thru USB, I want to change it to TCP, so I can use the other USB ports… the problem is that after I connect the adb thru TCP and then remove the USB-C cable, adb disconnects and show the device as offline on both USB and TCP…

Am I missing something here?

Thank you! Really appreciate any help!

#2

You’re dealing with two oddities at the same time here;

The first one;
I’ve noticed a bug on kernel 4.14 where sometimes usb plug/unplug will cause the board to reboot. Its a kernel panic, not an intentional reboot, and not a shutdown. The easiest way to avoid this is to not plug and unplug USB devices while the board is booted. You can debug using either UART, or ADB-over-IP (to enable this, set the system property service.adb.tcp.port=5555, which you can add to the list of property overrides here; hikey960.mk - device/linaro/hikey - Git at Google)

The second one;
You still have the hisilicon proprietary bootloader installed, which has an “alternating boot mode” feature, where on each board reboot, it alternates between a normal boot and fastboot. This can be solved by installing the uefi bootloader by running this script in your AOSP tree; installer/hikey960/uefi-flash-all.sh - device/linaro/hikey - Git at Google

#3

Awesome!

The “alternate boot mode” was fixed with your suggestion. I’ve noticed that script write an error at some point which is the cache.img file being missing… The device still boots normally and no alternate boots anymore. Perfect!

However, the ADB issue still persist…

I’ve called adb shell setprop service.adb.tcp.port 5555 then adb tcpip 5555 then tried to connect… No success… :frowning:

#4

Don’t you just love it when you give someone instructions, and they disregard it, do something different, then wonder why it isn’t working? Set the property the way I said to set it. Don’t use the setprop command – it’s transient.

On the other machine run adb connect 123.456.654.321 with the proper IP address of your board. You will then have access.

#5

Weill… change that .mk file requires rebuild the AOSP. Shouldn’t that be the same? (yes, transient but should work!).

If you are right, that means every single person in the world that uses Android requires to recompile their OSes in order to use ADB? That doesn’t make much sense.

But if you tell me that this is the only way to do it, I believe on you. It just doesn’t make any sense, at all…

But thanks for the kind reply…

#6

Since you’ve already built it, it should take all of 5 seconds, which is why I suggested editing that file instead of adding it to /vendor/build.prop (which is what that edit will do). Its much easier to edit things on a normal computer than on an android device.

And since you seem to be looking for a longer term debugging, it is much more rational to build it in that to enable it transiently.

And further, how do you expect it to read the property you set unless you restart adbd?

#7

Followed what you said and rebuilt the Android with the settings added to the .mk… Same thing…

Steps:

  1. After rebuild the images, flash them all
  2. Connect the device to wifi and enable developer mode with USB debug
  3. Plug USB cable
  4. adb devices show the device connected (after the kernel panic/reboot you mentioned)
  5. adb tcpip 5555
  6. adb connect DEVICE_IP:5555 and the device is connected
  7. unplug USB cable
  8. connection is gone
#8

Good

Unnecessary to muck around with developer mode.

No.

Irrelevant

No

No need to specify the port adb connect IP

Should not plug in in first place.

Irrelevant, you were connected by USB.

#9
  1. Plug USB cable
    No.
    The device isn’t on tcpip mode unless I plug the USB cable, wait the reboot then adb tcpip 5555.

How do you expect the device to accept ADB connect if it is not on the Wifi?

Unnecessary to muck around with developer mode.
Without that, how am I supposed to debug an app???

$ adb connect 192.168.1.223:5555

  • daemon not running; starting now at tcp:5037
  • daemon started successfully
    failed to connect to ‘192.168.1.223:5555’: Connection refused
    $ adb connect 192.168.1.223
    missing port in specification: tcp:192.168.1.223

So yes, the port is required even if it is 5555/default.

image
image1756×1298 425 KB

And here is the change to the hikey960.mk you asked for…

Can you please be more direct to the point? No and Yes on spare lines are not helping…

#10

The device goes into the correct mode with the system property you added. NO OTHER CHANGES ARE REQUIRED.

I can’t help you if you won’t follow instructions.

$ adb connect 192.168.1.221
connected to 192.168.1.221:5555

Oh look. Works. Imagine that.

Anyway, I’m done here. I’ve given you all the information you need in order to get this working in the manner you want. The choice not to follow instructions is entirely on you. What do they say? You can lead a horse to water, but you can’t make it drink?

#11

Man… I’ve did everything you asked for and guess what? It doesn’t work.

The UEFI thing is the only thing that worked.

The device goes into the correct mode with the system property you added. NO OTHER CHANGES ARE REQUIRED.

It doesn’t look it is going to the correct mode. Otherwise, it would work…

I can’t help you if you won’t follow instructions.
What I’m not following???

  1. Built/flashed with the property as you requested.
  2. Power on the device and JUST connect to wifi
  3. Then from a fresh new terminal adb connect 192.168.1.223
  4. image
    image920×160 11.5 KB

So, which part don’t you understand I’ve followed what you suggested?

#12

Ok folks. Just to update anyone that fall in the same situation.

@ric96 found out the real solution for the ADB problem.

I don’t actually need to change AOSP code at all. All I need is to boot the device with the USB-C cable and do the following:

$ adb shell
hikey960:/ $ su
hikey960:/ # setprop persist.adb.tcp.port 5555
hikey960:/ # exit
hikey960:/ $ exit
$ adb reboot
$ adb connect 192.168.196.77:5555
connected to 192.168.196.77:5555

(after reboot don’t forget to remove the USB-C cable!)

So, in other words, we were setting the wrong prop. All props that need to persistent across reboot are prefixed with persist.

@ric96 himself reported it a while ago here https://bugs.96boards.org/show_bug.cgi?id=502. The solution is on the last comments.

So, thank you for being kind and patient @ric96!

Thank you all! Now my work is finally unblocked and we can move on.

Best regards,
Gutemberg

2 Likes
#13

You don’t need it to be persist if it is inserted in the build.prop.