USB-Ethernet with latest Debian build

Hello everyone,

I recently flashed the newest Debian build from 4.19.5 kernel based Debian snapshot image release for HiKey960 onto a Hikey 960 board in order to try out the new Mali driver support from Debian mali g71 drivers

However, I have found that the USB-Ethernet adapter I use is no longer working since flashing it, and I have tried others to no success. I have tried both USB-A ports but there is no sign of a connection - the lights on the connector do not flash and nothing shows in the OS.

ifconfig only shows localhost:

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536                                    
        inet  netmask                                       
        loop  txqueuelen 1000  (Local Loopback)                                 
        RX packets 14400  bytes 1166400 (1.1 MiB)                               
        RX errors 0  dropped 0  overruns 0  frame 0                             
        TX packets 14400  bytes 1166400 (1.1 MiB)                               
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0              

dmesg does seem to have the following acknowledgment of the USB being plugged in on boot, and will show this message again if I disconnect and reconnect the USB-Ethernet adapter:

[    4.664945] usb 1-1.5: new high-speed USB device number 4 using xhci-hcd     
[    4.776409] [drm] +.                                                         
[    4.778846] [drm] wait for external HDMI bridge driver. 

Is there something I need to do, e.g. with nmtui, to connect this? The only way for me to get Internet access on the board is with Ethernet so I need it for installing the Mali driver - I cannot use WiFi instead.

Hi @foxen,

Few suggestions on this:

  • Check which driver is been used in the working case from the dmesg logs.
  • Find the kernel configs which enables this driver.
  • Check whether those configs are enabled in new kernel zcat /proc/config.gz | grep "CONFIG_XXXXX"
  • Also check whether dt binding for this device is present in your new dtb.
  • If type-c cable is connected, I think host port will not work.(as per hardware design)

When I wanted a network on hikey960, I had tried to setup a usb gadget ethernet on type-c port.
See below comment.

My host machine is Ubuntu. For windows, RNDIS configs need to be enabled I think.

Once Type-C cable is connected to host PC, you have to configure usb0 interface.
ifconfig usb0 <ip> netmask <>
And you can share your host PC’s internet to target board.
Set default gateway on target board. Then you can connect to internet over this emulated usb eth.
Refer, as example for sharing internet from host PC.

Other option:
Wifi is working in 4.19.5 debian kernel.
You can use nmtui to connect to Wifi AP. (example: Wifi tethering on your phone)

Hi @sreenad,

Thank you for you reply.

I have had a look at the working case and it looks like the missing driver is the “MOSCHIP usb-ethernet driver”.

The kernel config for this appears to be CONFIG_USB_NET_MCS7830:

In the working case, the command you provided gives:

root@debian:/mnt/sdcard# zcat /proc/config.gz | grep CONFIG_USB_NET_MCS7830

In the non-working case, the output is:

root@linaro-developer:~# zcat /proc/config.gz | grep CONFIG_USB_NET_MCS7830     

From this, am I right in saying that the newer build was not compiled with support for this driver in the kernel?

If that is the case, how would I go about rebuilding it with support for that driver?


I looked into this further and I think I found the driver, however attempting to load it failed as it appears to have only been built for earlier versions:

root@linaro-developer:~# insmod /lib/modules/4.19.5-hikey/kernel/drivers/net/usb
[  207.279035] mcs7830: version magic '4.19.5-hikey SMP preempt mod_unload aarch
64' should be '4.14.0-rc7-linaro-hikey960+ SMP preempt mod_unload aarch64'      
insmod: ERROR: could not insert module /lib/modules/4.19.5-hikey/kernel/drivers/
net/usb/mcs7830.ko: Invalid module format    

You are using kernel 4.14.0-rc7, you might need to update your boot.img so can use the kernel 4.19.5 [1], thus the module can match the kernel’s version.


Thank you @leo-yan - I thought I had updated it but perhaps I had used the wrong version. I will attempt to use that one and edit this reply once I have had the chance.


I have tried installing that boot image and had the same result. It showed as a duplicate in my downloads folder so I think it was the same one I had already tried.

I followed the instructions from to flash the board.

I noticed during booting that during inital booting the following errors occur during driver loading:

Loading driver at 0x000BF014000 EntryPoint=0x000BF015048 FaultTolerantWriteDxe.efi
Ftw: Workspace or Spare block does not exist!
Error: Image at 000BF014000 start failed: Invalid Parameter

And just before the boot menu:

Press ESCAPE for boot options UfsExecScsiCmds() fails with Target Failure
UfsExecScsiCmds() fails with Target Failure
UfsExecScsiCmds() fails with Target Failure
UfsExecScsiCmds() fails with Target Failure

During the boot process I noticed that my UEFI firmware version seems to be correct:

UEFI firmware (version Alpha built at 11:21:17 on Dec 19 2018)
add-symbol-file /home/buildslave/workspace/96boards-reference-uefi-staging/84/edk2/Build/HiKey960/DEBUG_GC
C5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xBF18C000

But my OS version does not:

[    0.000000] Linux version 4.14.0-rc7-linaro-hikey960+ (bas@hikey960) (gcc version 6.3.0 20170516 (Debia
n 6.3.0-18)) #8 SMP PREEMPT Thu Mar 8 11:34:37 UTC 2018

The OS download I used were the boot and rootfs packages from, and there were no errors during the process of flashing the board.

On the page [1], it suggests to use below commands to flash images:

$ sudo fastboot flash boot boot-linaro-stretch-developer-hikey-*.img
$ sudo fastboot flash system rootfs-linaro-stretch-developer-hikey-*.img

This two commands don’t specify the exactly image names, not sure if this will cause issue if in your local folder there have multiple images. So suggest you could flash images with below explicit commands:

$ sudo fastboot flash boot boot-linaro-stretch-developer-hikey-20190822-37.img
$ sudo fastboot flash system rootfs-linaro-stretch-developer-hikey-20190822-37.img

Also please note, the kernel image is stored in the root FS but not in the boot.img, so the rootFS should be flashed so can upgrade kernel image.


Hi @leo-yan,

Thank you for your suggestion to use explicit commands. I tried it and still had the same issue. Out of curiosity I also tried setting the permissions on all of the files to 777 and writing using explicit commands again, but this did not fix the issue.

Before writing I ensured there was only one “boot” file and one “rootfs” file in the directory. The output from the write commands is:

$ fastboot flash ptable prm_ptable.img
< waiting for any device >
target reported max download size of 134217728 bytes
sending 'ptable' (24 KB)...
OKAY [  0.041s]
writing 'ptable'...
OKAY [  0.002s]
finished. total time: 0.043s

$ fastboot flash fastboot l-loader.bin
target reported max download size of 134217728 bytes
sending 'fastboot' (25 KB)...
OKAY [  0.041s]
writing 'fastboot'...
OKAY [  0.053s]
finished. total time: 0.094s

$ fastboot flash fip fip.bin
target reported max download size of 134217728 bytes
sending 'fip' (1478 KB)...
OKAY [  0.155s]
writing 'fip'...
OKAY [  0.065s]
finished. total time: 0.219s

$ fastboot reboot-bootloader
rebooting into bootloader...
OKAY [  0.001s]
finished. total time: 2.204s

$ fastboot flash boot boot-linaro-stretch-developer-hikey-*.img
target reported max download size of 134217728 bytes
sending 'boot' (65536 KB)...
OKAY [  2.674s]
writing 'boot'...
OKAY [  0.598s]
finished. total time: 3.272s

$ fastboot flash system rootfs-linaro-stretch-developer-hikey-*.img
target reported max download size of 134217728 bytes
erasing 'system'...
OKAY [  0.577s]
sending sparse 'system' 1/12 (118868 KB)...
OKAY [  4.741s]
writing 'system' 1/12...
OKAY [  2.125s]
sending sparse 'system' 2/12 (131028 KB)...
OKAY [  5.295s]
writing 'system' 2/12...
OKAY [  1.505s]
sending sparse 'system' 3/12 (125228 KB)...
OKAY [  4.988s]
writing 'system' 3/12...
OKAY [  1.677s]
sending sparse 'system' 4/12 (131068 KB)...
OKAY [  5.301s]
writing 'system' 4/12...
OKAY [  1.196s]
sending sparse 'system' 5/12 (128439 KB)...
OKAY [  5.175s]
writing 'system' 5/12...
OKAY [  1.186s]
sending sparse 'system' 6/12 (130831 KB)...
OKAY [  5.244s]
writing 'system' 6/12...
OKAY [  1.431s]
sending sparse 'system' 7/12 (119465 KB)...
OKAY [  4.846s]
writing 'system' 7/12...
OKAY [  1.333s]
sending sparse 'system' 8/12 (130986 KB)...
OKAY [  5.221s]
writing 'system' 8/12...
OKAY [  1.245s]
sending sparse 'system' 9/12 (117506 KB)...
OKAY [  4.643s]
writing 'system' 9/12...
OKAY [  1.126s]
sending sparse 'system' 10/12 (129851 KB)...
OKAY [  5.186s]
writing 'system' 10/12...
OKAY [  1.324s]
sending sparse 'system' 11/12 (128547 KB)...
OKAY [  5.168s]
writing 'system' 11/12...
OKAY [  1.509s]
sending sparse 'system' 12/12 (65694 KB)...
OKAY [  2.761s]
writing 'system' 12/12...
OKAY [  0.734s]
finished. total time: 75.538s

Through UART, I also got the following output while flashing the boot image and rootfs:

Fastboot platform: check for partition-type:boot
Downloading 67108864 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:67108864
67108864 / 67108864 bytes downloaded (100%)
Flashing partition boot
Fastboot platform: check for partition-type:system
Erasing partition system
Downloading 121721544 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:121721544
121721544 / 121721544 bytes downloaded (100%)
Flashing partition system
Downloading 134173640 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:134173640
134173640 / 134173640 bytes downloaded (100%)
Flashing partition system
Downloading 128233480 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:128233480
128233480 / 128233480 bytes downloaded (100%)
Flashing partition system
Downloading 134214648 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:134214648
134214648 / 134214648 bytes downloaded (100%)
Flashing partition system
Downloading 131521540 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:131521540
131521540 / 131521540 bytes downloaded (100%)
Flashing partition system
Downloading 133971220 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:133971220
133971220 / 133971220 bytes downloaded (100%)
Flashing partition system
Downloading 122332440 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:122332440
122332440 / 122332440 bytes downloaded (100%)
Flashing partition system
Downloading 134130104 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:134130104
134130104 / 134130104 bytes downloaded (100%)
Flashing partition system
Downloading 120326388 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:120326388
120326388 / 120326388 bytes downloaded (100%)
Flashing partition system
Downloading 132968260 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:132968260
132968260 / 132968260 bytes downloaded (100%)
Flashing partition system
Downloading 131633104 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:131633104
131633104 / 131633104 bytes downloaded (100%)
Flashing partition system
Downloading 67271280 bytes
#FastbootTransportUsbRequestReceive, 255, BufferSize:67271280
67271280 / 67271280 bytes downloaded (100%)
Flashing partition system

This all looks like it has worked okay to me, yet the OS isn’t updated when I boot into it. I have made sure to remove all USB peripherals and my SD card before using Fastboot as well.

Hi @foxen,

From the log I cannot find any issue. I only can see your usage have a difference than mine is: I usually use “sudo” for fastboot commands, but not sure if this is the root cause or not; maybe it’s good to give a try for rootFS image.

Hi @leo-yan,

I was running as root (sudo su before commands) instead, but I will try running it on my user with sudo as well.

For proving if really flash to “system” file system, you could choose any “bad” image and flash into “system” partition, then check if the system can boot up; we can use this way to quickly narrow down if we are really using the flashed rootFS or not.

Hi @leo-yan,

I tried this by doing:

sudo fastboot flash system boot-linaro-stretch-developer-hikey-20190822-37.img

I can confirm the system image is being written as the end result was a kernel panic:

[    3.761888] ---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to ke
rnel. See Linux Documentation/admin-guide/init.rst for guidance.


I also tried doing this with the boot image. To do this I used the following, otherwise using the correct files:

sudo fastboot flash boot prm_ptable.img 

The result of doing so was the following error:

Loading driver at 0x000B9ADB000 EntryPoint=0x000B9ADC000 AndroidBootApp.efi
Failed to get Abootimg Size: Invalid Parameter
Failed to load boot image from boot partition: Invalid Parameter
Failed to boot from partition: Invalid Parameter
Error: Image at 000B9ADB000 start failed: Invalid Parameter
remove-symbol-file /home/buildslave/workspace/96boards-reference-uefi-staging/84/edk2/Build/HiKey960/DEBUG
_GCC5/AARCH64/EmbeddedPkg/Application/AndroidBoot/AndroidBootApp/DEBUG/AndroidBootApp.dll 0xB9ADC000
Image Return Status = Invalid Parameter

This appears to confirm that writing both the boot image and root filesystem is working as it should.

As an additional note, on a successful boot with the 4.19 image, I get the following message on boot:

Debian GNU/Linux 9 linaro-developer ttyAMA6
linaro-developer login: root (automatic login)
Last login: Thu Nov  3 17:16:47 UTC 2016 on ttyAMA6
Linux linaro-developer 4.14.0-rc7-linaro-hikey960+ #8 SMP PREEMPT Thu Mar 8 11:34:37 UTC 2018 aarch64

These are with build #37. I also tried with build #36 in-case something had been broken by the latest build, but got the same output and Ethernet issues.

Hi @foxen,

After UEFI boot up, can you see grub menu? Usually, when the grub menu is displayed, we can input ‘e’ so can see the detailed for the boot entry, e.g. it displays the kernel image name, this is the most straight way we can check the boot image.

And could you share the whole booting log so this can allow me and my colleagues to look more closely for the booting sequence?

Hi @leo-yan,

I checked the grub menu and the result of hitting e on the Debian option was:

 |setparams 'Debian 9.0 (Stretch)'                                            | 
 |                                                                            |
 |    linux /boot/Image console=tty0 console=ttyAMA6,115200n8 root=/dev/sdd10\|
 | rootwait rw efi=noruntime                                                  |
 |    devicetree /boot/hi3660-hikey960.dtb   

This led me to check the boot folder, and the contents of that are:

-rw-r--r--  1 root root 4798630 Aug 22  2019            
-rw-r--r--  1 root root  184190 Aug 22  2019 config-4.19.5-hikey                
drwxr-xr-x  3 root root   16384 Jan  1  1970 efi                                
drwxr-xr-x  5 root root    4096 Aug 22  2019 grub                               
-rw-r--r--  1 root root 4216138 Aug 22  2019 initrd.img-4.19.5-hikey            
-rw-r--r--  1 root root 8769505 Aug 22  2019 vmlinuz-4.19.5-hikey    

The full boot log is long so I uploaded it to Pastebin - this is the log from when I checked the boot menu options with e, so that part may look odd:

Thank you for investigating.

Hi @foxen,

UEFI needs to read grub.cfg and display menu entries according to its content.

By default we can see boot.img is pretty simple and the grub.cfg is not stored into it. UEFI uses the grub.cfg from /boot/grub/grub.cfg, the file actually is in a folder in rootfs.

So I suspect the UEFI is not really reading grub.cfg from /boot/grub/grub.cfg; you could see the UEFI log reports:

[Bds]Booting Boot from SD

Could you confirm your SD card is inserted or not? If so, it might be it’s caused by UEFI using boot.img from SD card but not on-board flash.

Hi @leo-yan,

There is no SD card inserted into the board, so I am not sure why it is displaying this.

Hi @foxen,

NOTICE:  BL2: v2.0(release):v2.0-427-g72b3226f
NOTICE:  BL2: Built : 11:21:36, Dec 19 2018
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.0(release):v2.0-427-g72b3226f
NOTICE:  BL31: Built : 11:21:36, Dec 19 2018

From the log you shared, the booting images are relatively old. After discussed with my colleague, we suspect you hit some corner case with booting images and the suggestion is to reflash the booting images [1] in recovery mode; then you could flash boot.img and root.img in recovery mode or normal fastboot mode.


Hi @leo-yan,

Would the way to reflash the boot images in recovery mode to be to use these instructions with relevant files (e.g. bl1.bin) replaced with those from


I attempted to this using the method I mentioned above but still see

NOTICE:  BL2: v2.0(release):v2.0-427-g72b3226f
NOTICE:  BL2: Built : 11:21:36, Dec 19 2018
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.0(release):v2.0-427-g72b3226f
NOTICE:  BL31: Built : 11:21:36, Dec 19 2018

It appears that my guess was incorrect.

[1] contains the legacy booting images, [2] contains UEFI/ARM-TF open-sourced images.

So if flash booting images from [2], you should can see ARM-TF has commit tag: 482fc9c88840c7d9c74e1fa57a8e25a291cc02be and building time is about 17-May-2019; please check if you have downloaded all booting images (ptable, l-loader.bin and fip.bin) and flash all of them; and could refer to script [3] for flashing related images.


Hi @leo-yan,

I tried doing this by using:

sudo ./ -r -v latest

I modified the script to remove the “96boards” part of the base URL as this appears to be outdated. I also submitted a fix for this to the tools-hikey-960 repository so it being outdated should not be an issue anymore:

Examples of files it downloaded:

--2019-09-12 11:12:48--

However after it reboots as part of the script, the board attempts to boot into Debian:

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

The script then gets stuck.

I also tried downloading all of the files from your link manually and using:

sudo ./ -u ~/Downloads/hikey-firmware/

where hikey-firmware is the directory I downloaded the files to, but had the same result.

I tried flashing the firmware manually anyway (including xloader) but still have the same issues once I boot into the OS - it still boots as

Linux linaro-developer 4.14.0-rc7-linaro-hikey960+ #8 SMP PREEMPT Thu Mar 8 11:34:37 UTC 2018 aarch64

However the BL2 appears to have updated succesfully:

NOTICE:  BL2: v2.1(release):v2.1-190-g482fc9c8
NOTICE:  BL2: Built : 00:59:51, May 17 2019
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.1(release):v2.1-190-g482fc9c8
NOTICE:  BL31: Built : 00:59:51, May 17 2019

The full boot log is on Pastebin:

Hi @leo-yan,

Do you know if there is anything else we could try with this? We have not yet had any success.