How can we deploy latest image with UEFI on hikey960?


I haven’t tried oe builds in a while, maybe @leo-yan can help…

So I switched to UEFI debug build. It pretty much hangs at the same location, but with 2 extra output lines. Maybe that gives someone a clue? Would really appreciate.

  Booting `CE Reference Platform (HiKey960 rpb)'

  Loading driver at 0x000B789E000 EntryPoint=0x000B8712440
  Loading driver at 0x000B789E000 EntryPoint=0x000B8712440

The recommended version for sec_xloader.img is 23, latter uefi-staging versions are reported as bad.

Thanks for the pointer, Loic. Unfortunately the results are same for build 23, at least in my case.

However, I did discover something interesting. After the step “sudo ./hikey_idt -c config -p /dev/ttyUSB1”, if I don’t press “f” to enter fastboot mode, it seems to go through normal boot up sequence and I got a bunch of what appears to be kernel messages (see some of them below). However, I still don’t get to console mode. Any more ideas?

[ 484.218635] [E/GPIO_HUB] gpio_hub_switch_to_hub: switch to hub
[ 484.775777] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 484.785466] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 484.952205] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 484.961807] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 484.971363] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 484.980903] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 484.990404] [E/hisi_pd] typec_unattached_power_entry:!!!+++++++++++
[ 484.998752] [E/hisi_pd] typec_unattached_power_entry:!!!-----------
[ 485.029662] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 485.039172] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 485.048659] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 485.058115] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 485.067548] [E/hisi_pd] typec_unattached_power_entry:!!!+++++++++++
[ 485.075837] [E/hisi_pd] typec_unattached_power_entry:!!!-----------
[ 485.671450] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 485.680911] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 485.690334] [E/GPIO_HUB] gpio_hub_switch_to_typec: switch to typec
[ 485.698625] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 485.708169] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 485.862750] [E/hisi_pd] pd_dpm_handle_pe_event:!!!,event=2,+++
[ 485.870715] [E/hisi_pd] pd_dpm_vbus_notifier_call: pd_dpm_vbus_notifier_call+
[ 486.115214] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!++++++++
[ 486.124802] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!--------
[ 486.134405] [E/hisi_pd] pd_dpm_handle_pe_event:!!!,event=7,+++

I think Loic has tried the booting images in the folder:

At my side, I tried two versions booting images:
Both cannot boot up successfully :frowning:

As another alternative solution, you can use all images in the 25 folder except the bad sec_xloader.img, you could rollback to use sec_xloader.img in 23 folder.

Thanks to everybody’s help, I was able to get it working with both console version and desktop version. I needed to run some browser benchmarks and thus really needed desktop version.

Here are some recap of the whole process so that others can duplicate exactly.

  • Download UEFI build from latest snapshot 100 (not UEFI stagging build which is 1 month older),

  • Follow previous instruction to install UEFI, Install UEFI on HiKey960 from Binaries [Instructions].

  • Note you don’t need to git clone image tools. All files are already present in the bootloader/ folder downloaded in the previous step

  • Download latest boot-.img and rpb-console-.rootfs.img.gz or rpb-desktop*.img.gz files. Unzip the rootfs images.


  • Use “sudo fastboot flash boot|system …” to flash them respectively. Reboot and it should be good to go.

  • On desktop version, you need to create the following file before executing “startx”

  • /usr/share/X11/xorg.conf.d/42-fbdev.conf

    Section "Device"
    Identifier "hikey960-fbdev"
    Driver "fbdev"
    Option “fbdev” "/dev/fb0"

  • twm is not present, but you can use x-window-manager (/etc/X11/xinit/xinitrc)

  • You can auto start X window by changing to “ExecStart=/usr/bin/startx” in /etc/systemd/system/display-manager.service

Hope that helps anyone who wants to try.


@juliansun Thanks for sharing , nice summary.

I’m following your linked instructions to build UEFI, but I’m getting an undefined symbol ‘__stack_chk_guard’ and ‘__stack_chk_fail’. I see where they’re defined, but I’m not sure how to fix it. Did you come across this issue when building?

I haven’t built uefi in a while now. I use this script to install using pre compiled binaries

Which GCC version you are using? Before I also received the reporting for building failure, this should be related with GCC options. At my side I am using 6.2.1 version:

leoy@leoy-linaro:~$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
Copyright © 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

I thought that might be an issue, but I recently updated, and now, I’m using 7.2.0.

What was the version you were using before? You might want to go the other way and try something older, like the Leo is using above or even gcc5.

If possible, could you try to use below script for building ATF + UEFI? I tried GCC4.9 and UEFI can build successfully as well (GCC4.9 cannot be used anymore for ATF, due it lacks the CA53 ERRATA fixing so report building error: aarch64-linux-gnu-ld: unrecognized option ‘–fix-cortex-a53-843419’).

Do you have an idea of how long it should take to flash system? I’ve done it in the past and it seems to take a very long time. Today, I tried flashing 107; it’s been flashing for over 3 hours with no indication of progress or encountering an error.

Hi @cdicker, usually take less than 10 minutes can flash all images (include Android system/data images) if use relative old UEFI image; recently UEFI has several patches for USB speed improvement, so can be faster. Flashing 3 hours+ is not reasonable.

I tried 107 images, they are okay at my side, just reminding one thing I tried Sahaj script to flash images, after the script print out “Sleeping till device resets… zzz”, you need input character ‘f’ in the console so the board can run into “fastboot” mode. Otherwise, the sequential “fastboot” commands cannot run properly.

Thanks for the help. I’ve only ever had a problem flashing boot and system. flashing boot usually takes about 20 seconds for me and hangs roughly 50% of the time. Is there a safe way to back out of flashing when I see it hang like this? Usually, when I get into this state, I go through the steps to recover the system and try again.

Where is Sahaj’s script to flash images (including system)? The only scripts I see in the tools-image-hikey960 repo are to recover the system and flash uefi.

If you don’t need to flash booting firmwares, I suggest you could refer the code in the file:, this code is written by ARM team and I use it at my side as well for automatic testing. You could see every time it will reboot board into fastboot mode and checking if really enter “fastboot” mode, then flash boot.img/dt.img. At my side the process is reliable on Hikey960.

Sahaj’s script is:; I think it’s a really good script for recovery mode to flash booting firmwares, this script doesn’t include flashing Android images.

1 Like

I tried on build 121 and it can boot up but with no /dev/fb0. Then I followed your steps, the output I got when startx as below:
Fatal server error:
(EE) no screens found(EE)

Check into the log in /var/log/Xorg.0.log, it looks like:
[ 36.013] (II) LoadModule: “glx”
[ 36.014] (WW) Warning, couldn’t open module glx
[ 36.014] (II) UnloadModule: “glx”
[ 36.014] (II) Unloading glx
[ 36.014] (EE) Failed to load module “glx” (module does not exist, 0)
[ 36.014] (II) LoadModule: “fbdev”
[ 36.014] (II) Loading /usr/lib64/xorg/modules/drivers/
[ 36.014] (II) Module fbdev: vendor=“X.Org Foundation”
[ 36.014] compiled for 1.19.3, module version = 0.4.4
[ 36.014] Module class: X.Org Video Driver
[ 36.014] ABI class: X.Org Video Driver, version 23.0
[ 36.014] (II) FBDEV: driver for framebuffer: fbdev
[ 36.014] (–) using VT number 2

[ 36.015] (WW) Falling back to old probe method for fbdev
[ 36.015] (II) Loading sub module “fbdevhw”
[ 36.015] (II) LoadModule: “fbdevhw”
[ 36.015] (II) Loading /usr/lib64/xorg/modules/
[ 36.015] (II) Module fbdevhw: vendor=“X.Org Foundation”
[ 36.015] compiled for 1.19.3, module version = 0.0.2
[ 36.015] ABI class: X.Org Video Driver, version 23.0
[ 36.015] (EE) open /dev/fb0: No such file or directory
[ 36.015] (EE) No devices detected.
[ 36.015] (EE)
Fatal server error:
[ 36.015] (EE) no screens found(EE)
[ 36.015] (EE)
Please consult the The X.Org Foundation support
for help.
[ 36.015] (EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
[ 36.015] (EE)
[ 36.015] (EE) Server terminated with error (1). Closing log file.

Have you tried recent build on your side?

I just wanted to ask on this thread if this is still the way to go to install the latest image of UEFI in order to get the linux images working?

Yes, except that builds have been move to (e.g.

1 Like