USB-Ethernet with latest Debian build

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.


Hi @foxen,

Below is detailed steps what I tried at my side:

  • Step 1: Power off board and change the switch to recovery mode (switch 1 & 2 to ON state and switch 3 to OFF state)

  • Step 2: Power on board and the board enters recovery mode, so cannot see any output in the console

  • Step 3: Use the script ‘’ with the command:

sudo ./ -d -t /dev/ttyUSB3 -v 95

On my PC, the USB node is /dev/ttyUSB3; and please note now the latest release is broken so I rollback to use build 95 with debug version.

  • Step 4: The script hikey_idt downloads binaries into SRAM:
Running hikey_idt...
Config name: config
Port name: /dev/ttyUSB3
0: Image: hisi-sec_usb_xloader.img Downalod Address: 0x20000
1: Image: hisi-sec_uce_boot.img Downalod Address: 0x6a908000
2: Image: recovery.bin Downalod Address: 0x1ac00000
Serial port open successfully!
Start downloading hisi-sec_usb_xloader.img@0x20000...
file total size 99584
downlaod address 0x20000
Finish downloading
Start downloading hisi-sec_uce_boot.img@0x6a908000...
file total size 23680
downlaod address 0x6a908000
Finish downloading
Start downloading recovery.bin@0x1ac00000...
file total size 1179648
downlaod address 0x1ac00000
Finish downloading
Sleeping till device resets... zzz
  • Step 5: On the console, press f so let the board enter into fastboot mode. Since you didn’t press f thus the system booted Linux kernel.

  • Step 6: On the window for running script, it will output logs as below:

target reported max download size of 134217728 bytes
sending 'ptable' (24 KB)...
OKAY [  0.008s]
writing 'ptable'...
OKAY [  0.003s]
finished. total time: 0.011s
target reported max download size of 134217728 bytes
sending 'xloader' (151 KB)...
OKAY [  0.010s]
writing 'xloader'...
OKAY [  0.011s]
finished. total time: 0.021s
target reported max download size of 134217728 bytes
sending 'fastboot' (25 KB)...
OKAY [  0.008s]
writing 'fastboot'...
OKAY [  0.053s]
finished. total time: 0.061s
target reported max download size of 134217728 bytes
sending 'fip' (1482 KB)...
OKAY [  0.063s]
writing 'fip'...
OKAY [  0.062s]
finished. total time: 0.125s
  • Step 7: Don’t reboot the board, directly flash boot and rootFS images:
sudo fastboot flash boot boot-linaro-stretch-developer-hikey-20190822-37.img                                                                                           
sudo fastboot flash system rootfs-linaro-stretch-developer-hikey-20190822-37.img                                                                                       
  • Step 8: Power off the board, change switch to normal mode (set switch 1 to ON and switch 2 & 3 to OFF state); power on the board again.

  • Step 9: After the sytem boot up, use modprobe to insmod module:

root@linaro-developer:~# modprobe mcs7830
root@linaro-developer:~# lsmod
Module                  Size  Used by
mcs7830                16384  0

Hi @leo-yan,

Trying to access Fastboot by pressing f does not appear to do anything for me. Scrolling down to the option and hitting enter gives:

error: no such device: boot.
error: no server is specified.

Press any key to continue...

I think I may have broken something while trying the earlier recommendations.

You need to press F in the short time, especially after the string “UEFI firmware (version Alpha built at 00:59:22 on May 17 2019)”. Otherwise, after timeout (three seconds?), it will continue to run and you might see the logs for “error: no such device: boot.”.

Hi @leo-yan,

Thanks, hitting the F key earlier worked for getting the image to flash. However, trying to use modprobe gives me:

root@linaro-developer:~# modprobe mcs7830
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.
modprobe: FATAL: Module mcs7830 not found in directory /lib/modules/4.14.0-rc7-linaro-hikey960+

Yeah, we come back to the original issue :slight_smile:

How about below steps when board is in fastboot mode (Or press F after UEFI booting)?

$ sudo fastboot erase system                      
$ sudo fastboot erase userdata                    

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

Hi @leo-yan,

This worked, thank you. I think that erasing the userdata must have been required.

I will mark your answer as the solution.

You are welcome! and thanks a lot for reporting back.

This means there has potential bug in UEFI; if both ‘userdata’ and ‘system’ partitions flash root FS images, it will by default load kernel images from ‘userdata’ partition rather than ‘system’ partition.

If wrongly flash an old root.img into ‘userdata’ partition, later UEFI will load kernel images from ‘userdata’ partition but it boots rootFS from ‘system’ partition based on kernel command line. So the kernel version and modules version cannot match with each other.

Updated: I tried to flash another rootFS image into ‘userdata’ partition, and I can confirm the UEFI will load kernel image from ‘userdata’ partition rather than ‘system’ partition.