Hikey960 hangs when writing ptable. #33
Comments
|
booting loop? Please share your log to us. What images are you using? |
|
I may have caused this problem by incorrectly flashed an AOSP image with some code for kernel security hardening, but am not really sure how to reproduce this problem. I have attempted to recover using this repositories recovery-flash.sh, and alternatively just the ./hikey_idt program which works well but then when I proceed to use fastboot flash [ptable | xloader | fastboot | etc] with each respective .img file the Hikey does not accept it as it appears to be stuck in a fastboot booting loop as shown below. I believe this is the log for one complete loop: |
|
You're using Hisilicon property bootloader. Maybe it's time to switch to ATF/UEFI now. |
|
Your suggesting i follow the recovery-flash-uefi.sh script to restore? |
|
As an update i tried to install via prebuilt uefi, as described in the folder "install-prebuilt-uefi", It appeared to be successful for all steps until i had to leave recovery mode to normal mode and then the same behavior as above was observed. Looking closer at some of the log does it appear y hardware is damaged? I have been careful when handling it, no observable events have occurred that would seem to have damaged it. Same log as above: |
|
It's the same log of Hisilicon property bootloader. It's not the log of ATF/UEFI. When you download images into the hardware in recovery mode, you need to run "fastboot flash" commands to burn l-loader.bin & fip.bin first. You need to reference the scripts, "recovery-flash-uefi.sh". |
|
Thanks for the guidance, but still having issues.
It has been writing the 'ptable' for 5 hours now. It seems i must write the ptable in order to burn l-loader.bin & fip.bin first. The serial port of the hikey960 displays Synchronous Exception at 0x0000000000000000 when the writing 'ptable' hangs. |
|
Does it mean that you always meet hang when you flush ptable? |
|
Yes, flashing the ptable is always as far as i can make it. I have discovered how to access the Android Fastboot boot manager menu through the serial line that my serial board provides if that can be helpful for solving this issue? |
|
Could you help to check whether you're fetching the latest code of all repositories? Or, you can use the prebuilt binaries to test first. (https://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey/release/) Now the latest one is build #70. |
|
I remember downloading the #70 build but my folder contained hisi_idt binaries not hisi-idt.py. It was also missing the ptable-aosp-4g.img / ptable-aosp-8g.img. I will try this idt version and ptable image in a few hours. Thanks for the link. |
|
Oh, you're running on HiKey960. I'm sorry to give the wrong link. The right one is at here. (https://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey960/release/) |
|
Here I am trying again with the latest hikey960 release files as linked above.
ttyUSB1 Console:
But then again i attempt to flash the ptable and fails:
ttyUSB1 Console:
|
Erik-Koning
changed the title
|
How many boards do you have? Do you have the same issue on other boards? |
|
We have two identical boards, the other one is able to be recovered. |
|
Up to now, I doubt it's a hardware issue. Since we don't have the synchronous exception issue in recovery mode. |
|
Other guy is also reporting this issue. Maybe there's something wrong in UFS driver. Need to investigate it. |
|
Could you help to check what the difference on the two boards? vendors on UFS chips? |
|
It is a LeMaker Hikey960 (specifies Ver.B on the board), 4 cortex A73 + 4 cortex A53 Big.Little CPU architecture, ARM Mali G71 MP8 GPU |
|
SOLVED by following these steps: git clone https://github.com/96boards-hikey/tools-images-hikey960.git The above line downloads & installs the uefi on the board If the device becomes stuck waiting for devices, I found restarting the device in recovery-mode, and then running either the recovery-flash-uefi.sh, or the recovery-flash.sh script for whatever reason cleared out the device rom memory so i was able to go back and try the "install-prebuilt-uefi" step again. Use fastboot to flash OS after this point. On hikey board switch to fastboot mode 1:on 2:off 3:on #!/bin/bash for cases that don’t run "lunch hikey960-userdebugif [ -z “${ANDROID_BUILD_TOP}” ]; then if [ ! -d “${ANDROID_PRODUCT_OUT}” ]; then echo “android out dir:${ANDROID_PRODUCT_OUT}” fastboot flash fastboot “${INSTALLER_DIR}”/fastboot.img fastboot flash boot “${ANDROID_PRODUCT_OUT}”/boot.img
|
|
Could you help to format a patch? |
|
Hi , i did as Erik-Koning said , all was ok before
what am I wrong , and what to do ? |
|
@mpadiy Sorry for the late respone. Im not sure why this procedure was necessary, but for me it fixed the device from being stuck waiting for devices. |
|
Refined instructions: If the board experiences an interrupt when flashing or a mysterious event occurs that causes the board to software brick, the boards base firmware/UEFI must be flashed before an OS can be flashed. The following steps restored a software bricked Hikey960 that was observed to be in a fastboot booting-loop, back to being flashed with AOSP source code, and a fastboot boot rom: git clone https://github.com/96boards-hikey/tools-images-hikey960.git #!/bin/bash INSTALLER_DIR=" #for cases that don't run "lunch hikey960-userdebug" if [ ! -d "${ANDROID_PRODUCT_OUT}" ]; then echo "android out dir:${ANDROID_PRODUCT_OUT}" fastboot flash fastboot "${INSTALLER_DIR}"/fastboot.img fastboot flash boot "${ANDROID_PRODUCT_OUT}"/boot.img to flash the AOSP fastboot and image files to bring back original flashing functionality. |
|
@Erik-Koning Could you help to format a patch on it? Then we could merge your patch. |
Regarding the steps for releaving a booting process loop, when removing the 3-4 pin after the hikey_idt config command when specifically should i power cycle the device? I have tried a few different ways and non are successfuly flashing the device with the base image files. There is a section in the doc labeled "flash images by bootloader", is that process one I can try to fix a booting loop?
The text was updated successfully, but these errors were encountered: