Board fails to boot after Lebian load

Products Support HiKey970
#1

I loaded the Lebian image downloaded from the Lemaker downloads page using the method in the accompanying text file. Everything seemed to go OK.

The output was:

Flashing ptable  
target reported max download size of 134217728 bytes
sending ‘ptable’ (24 KB)…
OKAY [  0.001s]
writing ‘ptable’…
OKAY [  0.005s]
finished. total time: 0.006s
target reported max download size of 134217728 bytes
sending ‘xloader’ (164 KB)…
OKAY [  0.007s]
writing ‘xloader’…
OKAY [  0.008s]
finished. total time: 0.016s
target reported max download size of 134217728 bytes
sending ‘fastboot’ (1152 KB)…
OKAY [  0.039s]
writing ‘fastboot’…
OKAY [  0.057s]
finished. total time: 0.096s
target reported max download size of 134217728 bytes
sending ‘fip’ (1224 KB)…
OKAY [  0.047s]
writing ‘fip’…
OKAY [  0.058s]
finished. total time: 0.106s
target reported max download size of 134217728 bytes
sending ‘boot’ (65536 KB)…
OKAY [  2.194s]
writing ‘boot’…
OKAY [  0.414s]
finished. total time: 2.608s
Please be patient…
target reported max download size of 134217728 bytes
erasing ‘system’…
OKAY [  0.053s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.593s]
writing ‘system’…
OKAY [  0.684s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.591s]
writing ‘system’…
OKAY [  0.768s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.599s]
writing ‘system’…
OKAY [  0.730s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.569s]
writing ‘system’…
OKAY [  0.722s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.569s]
writing ‘system’…
OKAY [  0.721s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.561s]
writing ‘system’…
OKAY [  0.725s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.583s]
writing ‘system’…
OKAY [  0.719s]
sending sparse ‘system’ (126368 KB)…
OKAY [  4.397s]
writing ‘system’…
OKAY [  0.836s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.609s]
writing ‘system’…
OKAY [  0.867s]
sending sparse ‘system’ (131068 KB)…
OKAY [  4.599s]
writing ‘system’…
OKAY [  0.734s]
sending sparse ‘system’ (130912 KB)…
OKAY [  4.580s]
writing ‘system’…
OKAY [  0.650s]
sending sparse ‘system’ (121600 KB)…
OKAY [  4.253s]
writing ‘system’…
OKAY [  0.805s]
finished. total time: 63.520s

Then I reset the DIP Switches to ON OFF OFF OFF. I attached a mouse and keyboard and an HDMI monitor. I waited for 10 minutes but saw nothing on the monitor. I then powered down the system and attached a USB cable to the USB-C port that is near the two switches and the LS connector. Attached the other end to my Linux PC (Centos 7.5) and used minicom with the following settings 11520 8N1 software flow control ON

Applied power to the board. It starts booting and then reaches the following spot and hangs

Booting `Lebian 9 (HiKey970 Lebian)’

EFI stub: Booting Linux Kernel…
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map…
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.78-147538-g244928755bbe (andy@andy-virtual-m8
[ 0.000000] Boot CPU: AArch64 Processor [410fd034]
[ 0.000000] earlycon: pl11 at MMIO 0x00000000fff32000 (options ‘115200’)
[ 0.000000] bootconsole [pl11] enabled
[ 0.000000] Ion: insert heap-name carveout_gralloc
[ 0.031938] /soc/interrupt-controller@0xf4000000: Unable to locate ITS domn
[ 0.039266] /soc/interrupt-controller@0xf4000000: unable to locate ITS domn
[ 0.408709] dmi: Firmware registration failed.
[ 0.413369] Ion: invalid heap-name in node iommu_info, please check the na
[ 0.420519] Ion: invalid heap-name in node linear, please check the name
[ 0.427329] Ion: node name [heap_sys_user], heap-name [sys_heap]
[ 0.433335] Ion: heap index 0 : name sys_heap base 0x0 size 0x0 id 0 type 0
[ 0.440295] Ion: heap sys_heap base =0, try to find dynamic area
[ 0.446386] Ion: name = sys_heap, table name carveout_gralloc
[ 0.452216] Ion: name = sys_heap, table name
[ 0.456655] Ion: name = sys_heap, table name
[ 0.461093] Ion: name = sys_heap, table name
[ 0.465531] Ion: name = sys_heap, table name
[ 0.469976] Ion: node name [heap_carveout_gralloc], heap-name [carveout_gr]
[ 0.477370] Ion: heap index 1 : name carveout_gralloc base 0x0 size 0x0 id2
[ 0.485022] Ion: heap carveout_gralloc base =0, try to find dynamic area
[ 0.491806] Ion: name = carveout_gralloc, table name carveout_gralloc
[ 0.498329] Ion: have found heap name carveout_gralloc base = 0xbc800000, 0
[ 0.506344] of_get_iova_info:start_addr 0x40000, size 0xbffc0000 align 0x80
[ 0.517742] no hisilicon,hisi-pmic-irq-num1 property set
[ 0.523055] hisi_pmic 2-00: the platform don’t support ext-interrupt.
[ 0.537016] <[hisi_dt_parse_ip_atf]: regulator_id=0, ppll0_clock_set_rate_>
[ 0.544664] <[hisi_dt_parse_ip_atf]: regulator_id=1, ppll0_clock_set_rate_>
[ 0.552227] <[hisi_ip_to_atf_is_enabled]:regulator_id=1>
[ 0.557669] <[hisi_dt_parse_ip_atf]: regulator_id=8, ppll0_clock_set_rate_>
[ 0.565268] <[hisi_dt_parse_ip_atf]: regulator_id=2, ppll0_clock_set_rate_>
[ 0.572790] <[hisi_ip_to_atf_is_enabled]:regulator_id=2>
[ 0.578196] <[hisi_dt_parse_ip_atf]: regulator_id=3, ppll0_clock_set_rate_>
[ 0.585720] <[hisi_ip_to_atf_is_enabled]:regulator_id=3>
[ 0.591136] <[hisi_dt_parse_ip_atf]: regulator_id=4, ppll0_clock_set_rate_>
[ 0.598657] <[hisi_ip_to_atf_is_enabled]:regulator_id=4>
[ 0.604061] <[hisi_dt_parse_ip_atf]: regulator_id=5, ppll0_clock_set_rate_>
[ 0.611581] <[hisi_ip_to_atf_is_enabled]:regulator_id=5>
[ 0.616986] <[hisi_dt_parse_ip_atf]: regulator_id=6, ppll0_clock_set_rate_>
[ 0.624503] <[hisi_ip_to_atf_is_enabled]:regulator_id=6>
[ 0.629925] <[hisi_dt_parse_ip_atf]: regulator_id=7, ppll0_clock_set_rate_>
[ 0.637442] <[hisi_ip_to_atf_is_enabled]:regulator_id=7>
[ 0.652065] Kirin-pcie f4000000.pcie: eye_param_vboost = [0xffffffff]
[ 0.658530] Kirin-pcie f4000000.pcie: eye_param_iboost = [0xffffffff]
[ 0.664973] Kirin-pcie f4000000.pcie: eye_param_pre = [0xffffffff]
[ 0.671156] Kirin-pcie f4000000.pcie: eye_param_post = [0xffffffff]
[ 0.677422] Kirin-pcie f4000000.pcie: eye_param_main = [0xffffffff]
[ 0.779550] ion domain already init return domain

It hangs there for a fair amount of time (several minutes) then the system reboots.

Any help would be mightily appreciated. Thanks

I am getting extremely frustrated with this board - Please help
#2

I’ve not tried Lebian before but decided to try it out on my own board.

First I followed the board recovery guide to install up to date firmware (BoardRecovery for HiKey970 - 96Boards ). It’s many, many months since my 970 last got powered up so I figured I’d better make sure my firmware is up to date. I submitted a few small corrections (https://github.com/96boards/documentation/pull/663 ) but it basically worked… Having said that I did have to run the hisi-idt.py a lot of times before it eventually gave me a successful download .

After that I followed the install instructions (Linux Host Installation for HiKey970 - 96Boards ). This works exactly as written and, using the debug UART I can see the system boot as far as the login prompt.

Basically where you output stops, mine continues with further boot steps:

...
[    0.645145] Kirin-pcie f4000000.pcie: eye_param_vboost = [0xffffffff]
[    0.651609] Kirin-pcie f4000000.pcie: eye_param_iboost = [0xffffffff]
[    0.658054] Kirin-pcie f4000000.pcie: eye_param_pre = [0xffffffff]
[    0.664247] Kirin-pcie f4000000.pcie: eye_param_post = [0xffffffff]
[    0.670517] Kirin-pcie f4000000.pcie: eye_param_main = [0xffffffff]
[    0.775079] ion domain already init return domain
[    0.981459] [drm:adv7511_detect.isra.7] *ERROR* Read connector status timout, time = 10 
[    1.103401] gpio_hub_power_on:regulator_enable
[    1.163548] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!+++++++++++
[    1.170950] [E/hisi_pd] typec_wait_ps_change: typec_wait_ps_change!!!-----------
[    1.178350] [E/hisi_pd] typec_unattached_power_entry:!!!+++++++++++
[    1.184852] [E/hisi_pd] tcpci_disable_vbus_control: !!!++++++++
[    1.190773] [E/hisi_pd] pd_dpm_handle_pe_event:!!!,event=0,+++
[    1.196604] [E/hisi_pd] typec_unattached_power_entry:!!!-----------
...

The messages above were captured without a HDMI device attached to the system (since that is easier for you to reproduce). The messages are slightly different if I attach my KVM to the board but I still can’t reproduce anything like your results.

What do you get in the logs if you boot without a HDMI device attached?

#3

The same thing. It always seems to hang at one of two spots during the boot cycle, either on the last kirin-pcie line or the iondomain line right after that and then sits there for a while (several minutes) before it reboots.

I haven’t used the hisi-idt.py to do the firmware load. It seemed to me like the recovery script loads the same images as the hisi-idt.py script does. Am I wrong about that. I am using a Centos 7 host and the hisi-idt.py script fails to run. I had at one time tried to load a Python 3 onto Centos 7 and it turned out to cause all sorts of issues. Looks like Centos uses Python 2.x in some of its own things.

I guess I could try load some other Linux onto a laptop and try that. One thing that has bothered me is that they keep telling us the Lebian load should take 3-4 minutes, and all our machine takes is about 1 minute. Could we be missing something? Do you remember how long it took you to load all the Lebian images.

I have one other question. As we were poring over the documentation we noticed an inconsistency in the specifications for a compatible power supply. At one spot they said 8-18V 2 Amps, and at another location they said 3 Amps. We are using a 2 Amp supply. Could that be our issue?

The other issue is that at some spots they tell us to connect the debug UART through a TTL to USB converter attached to the Low speed connectors. Others seem to imply that you can connect it to the USB-C close to the reset and power switches. We have been using the USB-C port. Is that the wrong thing to do?

Thanks for your help.

#4

The same thing. It always seems to hang at one of two spots during the boot cycle, either on the last kirin-pcie line or the iondomain line right after that and then sits there for a while (several minutes) before it reboots.

I haven’t used the hisi-idt.py to do the firmware load. It seemed to me like the recovery script loads the same images as the hisi-idt.py script does. Am I wrong about that. I am using a Centos 7 host and the hisi-idt.py script fails to run. I had at one time tried to load a Python 3 onto Centos 7 and it turned out to cause all sorts of issues. Looks like Centos uses Python 2.x in some of its own things.

The recovery proceedure is to use one of hisi_idt or hisi-idt.py to load
a fastboot implementation into RAM. It shouldn’t matter which tool you
use to load it.

However the payload you burn to the UFS once you have loaded could
certainly make a difference.

I guess I could try load some other Linux onto a laptop and try that. One thing that has bothered me is that they keep telling us the Lebian load should take 3-4 minutes, and all our machine takes is about 1 minute. Could we be missing something? Do you remember how long it took you to load all the Lebian images.

I didn’t remember so I ran it again. It took 56 seconds.

I have one other question. As we were poring over the documentation we noticed an inconsistency in the specifications for a compatible power supply. At one spot they said 8-18V 2 Amps, and at another location they said 3 Amps. We are using a 2 Amp supply. Could that be our issue?

I’m using a 12V 2A supply. Note however that power supplies are
one of the more fragile components (big caps, constant switching of
fairly high current, etc) so it’s always worth checking with a
second power supply if you can (even if it the same spec).

The other issue is that at some spots they tell us to connect the debug UART through a TTL to USB converter attached to the Low speed connectors. Others seem to imply that you can connect it to the USB-C close to the reset and power switches. We have been using the USB-C port. Is that the wrong thing to do?

If the docs are inconsistent its best to provide links (although even
with links we can probably only easily change docs located on
96boards.org ).

Anyhow, AFAIK the USB-C port is read only (e.g. you can observe log
messages but can’t send any characters to it). Hard to figure out why,
the schematic looks like it should work but since I don’t know what type
of level shifters are used I can’t do searching deeper to figure
out what it wrong (and I’m also only marginally qualified to do so
anyway).

#5

The recovery script loads everything there is in the distribution. So I suppose that’s ok. The hisi-idt.py loads three files all of which are also loaded by the recovery script. I hope that works.

I’m starting to think there may be a hardware issue on the board we have, since it seems to make absolutely no difference what load we try and we’ve now tried Lebian, Leubuntu and the standard Android load. I’m not sure what exactly is going on in the boot cycle at that stage. But all three fail at the same spot, which would tend to point to some common underlying issue.

The guys at LeMaker have sent me a completely new load which we will try tomorrow. If that doesn’t work we’ll try a new board.

#6

Sounds plausible. Let us know how you get on!

#7

Hey, I’m currently in the process of flashing/installing lebian on my hikey 970 for the first time and am kind of new to this. I just wanted to know what OS you were using on the host machine to complete the steps you listed in this post?

#8

Probably Fedora 29 but I think I may have spun up a Ubuntu 16.04 container to build UEFI (IIRC the host tools could not be built using gcc-8 so I had to switch to a distro based on an old compiler).

#9

I would suggest you to use Ubuntu-16.04 for flashing Lebian or any of the lemaker images.

#10

Ubuntu 16.04 LTS worked for me. I tried a Centos 7.5 and Fedora 26. Those had issues. Also use picocom as opposed to minicom or putty. Seems to work better