Hikey board booting problem


#1

Hello ,
I modified memory layout to give more RAM to OPTEE.
I compiled with my modifications and flashed and now , the board is not booting.

serial logs stopped at :

INFO: TEE-CORE: Initialized
DEBUG: [0x0] TEE-CORE:init_primary_helper:628: Primary CPU switching to normal world boot

Also , recovery also not working. dmesg output is :

[ 8164.033094] option 1-5:1.0: GSM modem (1-port) converter detected
[ 8164.033225] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB0
[ 8164.705737] usb 1-5: USB disconnect, device number 24
[ 8164.705993] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
[ 8164.706008] option 1-5:1.0: device disconnected

Is there any other way to recover my board ? Pls help


#2

[deepakmnvl] deepakmnvl http://discuss.96boards.org/users/deepakmnvl
May 22

Hello ,
I modified memory layout to give more RAM to OPTEE.
I compiled with my modifications and flashed and now , the board is not
booting.

serial logs stopped at :

INFO: TEE-CORE: Initialized
DEBUG: [0x0] TEE-CORE:init_primary_helper:628: Primary CPU switching
to normal world boot

I’m afraid I can’t really help too much here. There are simply too many
ways a broken memory map can lead to a hang during boot.

Also , recovery also not working. dmesg output is :

[ 8164.033094] option 1-5:1.0: GSM modem (1-port) converter detected
[ 8164.033225] usb 1-5: GSM modem (1-port) converter now attached to
ttyUSB0
[ 8164.705737] usb 1-5: USB disconnect, device number 24
[ 8164.705993] option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
[ 8164.706008] option 1-5:1.0: device disconnected

Is there any other way to recover my board ? Pls help

The above message shows the bootloader is not loading so, on Hikey, this
is the only recovery mechanism that can help you.

Its rather odd that there is only a half second window between the USB
connect and disconnect. The disconnect is normal but the timeout should
be much longer than 0.5 seconds.

Are you running Linux in some kind of virtual machine? It is very
difficult to get a successful debrick like that (the board will change
VID/PID depending on which stage of recovery you are in; this messes up
USB device forwarding).


#3

Hi @danielt,
I am connecting the board to native Linux machine


#4

In that case the main things to think about are (in order):

  1. Unplug everything except power and micro-USB (some things matter, some don’t, much easier just to disconnect everything).
  2. Double check time passes correctly in the host dmesg log (i.e. run tail /var/log/messages or journalctl -fk and verify with a stopwatch that the USB is only connect for half a second).
  3. Check with a different micro-USB cable.
  4. Check with a different power supply (this is a long shot)
  5. Sniff traffic on USB bus… we’re interested to see if any service on your workstation is automatically trying to talk to /dev/ttyUSB0 after it enumerates and might convince it to disconnect (this is a very long shot…).

There might be some clues available on the (unpopulated) 1V8 UART header next to the boot jumper switches but this is also in the very long shot category (if you have the hardware its much less effort than trying to read USB capture traces though).


#5

Hi @danielt.
thanks for the reply.

I connected to another PC to get it working again