TA compilation with SPI driver

[deepakmnvl]

Hi, My task is to communicate with my SPI device through OP-TEE securely. For this , as a trial , I am extending hello_world program to included spi_init() and spi loopback test api. (copy spi_init() from optee_os to hello_world_ta.c)

I am getting many errors during TA compilation as it is not able to find headers, which are in optee_os folders. ( I have solved some by crude way of copying \optee_os\core\include\ folder to my TA folder but other errors appeared )

It would be very helpful if anybody can provide some documentation/usage/how-to tutorial of driver integration in OP-TEE ?

Thanks

[etienne-lms]

Hi @deepakmnvl. Remember TAs operate in userspace while optee_os/core operates in privileged land. The old application / kernel scheme. What you could do is to create a pseudo TA (in 'core' privileged space) from where you can access your SPI driver. And make your TA (user space) to invoke your pseudo TA.

[deepakmnvl]

Hi @etienne-lms , Thanks for the reply.

I am referring to :

My setup is Android REE and OP-TEE . And I have a working SPI driver in Android for my device. So , if I integrate my driver into TEE driver which is in linux kernel space , and I talk to my device via TA->TEE Core->Tee driver ->my SPI driver -> my device .

1. Is this feasible method ?
2. Is this secure way to communicate with a device ?

Thanks

[etienne-lms]

TA->TEE Core->Tee driver ->my SPI driver -> my device .

1. Is this feasible method ?

Yes, but implementation is not straightforward.

2. Is this secure way to communicate with a device ?

No. It would look better if your driver lies in the "HAL" red box of the above figure.

[deepakmnvl]

Hi, I am creating a static TA and a user TA as per your suggestion in 1st comment.

For static TA, my file's path is optee\optee_os\core\tee\foo.c , optee\optee_os\core\include\tee\foo.h Now , how to call my APIs in foo.c from user TA.

Is it the system call way ? they are defined here : optee\optee_os\core\arch\arm\tee\arch_svc.c I picked few sys calls and tried checking their code flow, but couldn't understand. Few calls go to tee_api_operations.c in libutee !!! Its confusing .

Can you help me with any other API which is called from user TA ?

Is it possible to call my API in "core\tee\foo.c" directly from user TA ? or should I need to route the call through some library here (optee\optee_os\lib)

Thanks

[jforissier]

For an example of pseudo-TA, see for instance https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/pta/interrupt_tests.c. You may call a pseudo-TA directly from a client application (normal world).

[deepakmnvl]

hi @jforissier , Thanks for the reply. But I need a mechanism to call my pseudo-TA from user TA.

I have gone through interrupt_tests.c file before. fops is declared for static_ta_register, but not able to figure out how they are invoked from user TA . Any input in this regard would be helpful

Thanks.

[etienne-lms]

hi @deepakmnvl,

A (user) TA can call another (user) TA or a pseudo TA using the GP TEE internal API:

• TEE_OpenTASession(...)
• TEE_InvokeTACommand(...)
• TEE_CloseTASession(...)

These APIs are available to user TAs (in libutee) and already go through syscalls to reach target pseudo-TA in OP-TEE core.

[deepakmnvl]

Hi , I am now trying to attach my framework ( which are a collection of static libs ) with my user ta. I did modifications in "aosp1\external\optee_myprog\ta\sub.mk" as below :

libdirs += include/Debug //my libs are here libnames += test libdeps += include/Debug/libtest.a

In out/target/product/hikey/optee/ta/external_optee_myprog_ta I see an entry in .map file like below - LOAD include/Debug/libtest.a

But , my .ta file size didnt change. Its same to when I didnt include my static libs

I gathered above procedure in the forums, Is this correct ?

I didnt test it yet, as I am still implementing my normal world bin, wanted to check if my method is correct ?

Thanks

[etienne-lms]

hello @deepakmnvl, Look strange, especially if you see the library in the generated TA ELF file which means the TA is effectively linked with the lib. Check that your TA really uses the library resources (functions?). Resources from libraries that are not called from the TA are not be embedded in the TA.

[deepakmnvl]

hi , Now , I managed to build my "Normal World" code to call APIs from libteec.so and subsequently access TA part of my "Secure code". But , I am facing TEEC_ERROR_BAD_FORMAT error during TEEC_OpenSession() call. I cherry-picked commit ef53fb06 , but still problem exists.

EDIT: yes , I did clean build and updated fip.bin Also , should I specifically use any compiler options to make my Binaries compatible to run on Hikey+OPTEE environment ? If so , pls let me know where they are defined in the stack

Any help would be appreaciated. FYI, Am using this branch : link

Also , am using uart0 for logs , and did below changes:

In device/linaro/hikey/uefi-tools/platforms.config, under the [hikey] node, uncomment the 3 lines required to use UART0. Then rebuild fip.bin. In device/linaro/hikey/bootloader/EFI/BOOT/grub.cfg, line 6, change both ttyFIQ0 to ttyAMA0 and rebuild the image. My build command has CFG_CONSOLE_UART=0

This is the only log appearing :

debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1! NOTICE: acpu_dvfs_set_freq: set acpu freq success!NOTICE: BL2: v1.1(release):36aa82d NOTICE: BL2: Built : 18:02:35, May 9 2017 NOTICE: BL3-1: v1.1(release):36aa82d NOTICE: BL3-1: Built : 18:02:35, May 9 20INFO: TEE-CORE: Initializing (2.3.0-dev #46 Tue May 9 12:32:25 UTC 2017 aarch64) INFO: TEE-CORE: Initialized UEFI firmware (version Alpha built at 10:33:12 on Apr 4 2017) EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied EFI stub: Using DTB from configuration table Failed to handle fs_proto EFI stub: ERROR: Failed initrd from command line! EFI stub: Exiting boot services and installing virtual address map...

Are there any more changes required ?

Thanks

[vchong]

The uart0 logging part of the question above is answered in https://discuss.96boards.org/t/android-op-tee-compile-error/1422/49.

Not sure about the TEEC_ERROR_BAD_FORMAT error but in one of your comments above, you had:

libdirs += include/Debug //my libs are here
libnames += test
libdeps += include/Debug/libtest.a

Is the above exactly the same as what you have in your actual makefile? If so, not sure if the //my libs are here comment might cause trouble so you can perhaps try removing it to be sure.

[deepakmnvl]

Hi , I added //my libs are here just in this comment . My actual sub.mk file do not have it

[deepakmnvl]

Hi , @vchong , my OPTEE build was indeed RELEASE, changed that to DEBUG. Now , I could see more logs. Also , now am using "CFG_TEE_TA_LOG_LEVEL=4 CFG_TEE_CORE_LOG_LEVEL=4" in my AOSP build command. Thanks for your help

Regarding my "TEEC_ERROR_BAD_FORMAT" issue , I modified my calls as _TEECRegisterSharedMemory --> TEEC_AllocateSharedMemory and it seems to be fixed.

Another issue now : I need to link by prebuilt static libs to my TA . For that , I did as below :

I did modifications in "aosp1\external\optee_myprog\ta\sub.mk" as below :

libdirs += include/Debug //my libs are here libnames += test libdeps += include/Debug/libtest.a

In addition to above , Should I need to copy my static libs on board ? I think am missing a step here. Can anybody please help here ??

Thanks

EDIT : Presently , am facing error in TEEC_OpenSession with "TEEC_ERROR_BAD_FORMAT" error. I think , during TEEC_OpenSession , TA gets loaded along with its dependencies. and I am doubting loading of my static libs has some problem. Pls correct me if am wrong !!!

[etienne-lms]

Hello @deepakmnvl,

Your libs are statically linked with the TA so they will not appear as separated files in the REE filesystem: You will find only a single xxx.ta file that contains all the binary code/data of your TA. Note that they a no support for shared libraries for the OP-TEE TAs. Each TA is a single binary blob.

Regarding the "TEEC_ERROR_BAD_FORMAT", it looks strange. It cannot be due to a dependency issue as such issue would appear a TA build stage. Is there any error or debug trace together with the error status ?

[jforissier]

About TEE_ERROR_BAD_FORMAT: there are several places that set this error during TA loading, but it seems most of them are meant to detect an invalid ELF file, which is quite unlikely (I assume we can trust the toolchain to generate valid binaries). There is one constraint specific to the OP-TEE ELF loader however: the ELF program headers must start with LOAD header. Can you please check this? Here is an example of a correct TA (note that the headers are LOAD, LOAD, LOAD and DYNAMIC in that order):

$ arm-linux-gnueabihf-readelf -l hello_world/ta/8aaaf200-2450-11e4-abe2-0002a5d5c51b.elf 

Elf file type is DYN (Shared object file)
Entry point 0x20
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x010000 0x00000000 0x00000000 0x05288 0x05288 R E 0x10000
  LOAD           0x015288 0x00005288 0x00005288 0x01a84 0x01a84 R   0x10000
  LOAD           0x017000 0x00007000 0x00007000 0x00094 0x0abe0 RW  0x10000
  DYNAMIC        0x016b50 0x00006b50 0x00006b50 0x00080 0x00080 RW  0x4

 Section to Segment mapping:
  Segment Sections...
   00     .ta_head .text 
   01     .rodata .got .rel.got .dynamic .dynsym .dynstr .hash .rel.dyn 
   02     .data .bss 
   03     .dynamic 

This won't be the case if you build some file with -funwind-tables for instance -- you would get 0x70000001, LOAD, LOAD, LOAD, DYNAMIC.

[deepakmnvl]

hi, In my TA , if I just increment a number (like in hello_world), there's no error If I make a call to an API inside my static lib , I am getting this "TEE_ERROR_BAD_FORMAT" error

I am getting error from "TEEC_OpenSession" res = arg->ret; eorig = arg->ret_origin;

"res" being set to 0xffff0005 "eorig " being set to 0x3

@jforissier I checked on your query . My test TA has "LOAD, LOAD, LOAD and DYNAMIC" sequence

But there is one difference , when I call my static lib , ".eh_frame" is appearing

Elf file type is DYN (Shared object file) Entry point 0x20 There are 4 program headers, starting at offset 64

Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000010000 0x0000000000000000 0x0000000000000000 0x000000000004e130 0x000000000004e130 R E 10000 LOAD 0x000000000005e130 0x000000000004e130 0x000000000004e130 0x00000000000115a0 0x00000000000115a0 R 10000 LOAD 0x0000000000070000 0x0000000000060000 0x0000000000060000 0x000000000006079c 0x000000000006b438 RW 10000 DYNAMIC 0x000000000006ee68 0x000000000005ee68 0x000000000005ee68 0x00000000000000f0 0x00000000000000f0 RW 8

Section to Segment mapping: Segment Sections... 00 .ta_head .text 01 .eh_frame .rodata .rela.dyn .got .rela.got .dynamic .dynsym .dynstr .hash 02 .data .bss 03 .dynamic

Does this make any difference ??

Mine hikey board is 64bit arch , compiling aosp with arm-linux-androideabi- Also , my static libs are compiled with android-ndk-r12b 64bit cross-compiler

Below are compiler flags I am using to build my static libs :

add_compile_options( -ffunction-sections ) add_compile_options( -fcrossjumping) add_compile_options( -funwind-tables ) add_compile_options( -fno-short-enums) add_compile_options( -fno-zero-initialized-in-bss) add_compile_options( -fpic) add_compile_options( -fPIC) add_compile_options( -fPIE) add_compile_options( -Wall) add_compile_options( -Wno-missing-braces) add_compile_options( -Werror) add_compile_options( -Os)

Should I add/remove any ?

Thanks

[jforissier]

Try removing -funwind-tables. That's what causes the .eh_frame section to appear in the second segment. I don't really see how it could cause a problem, but still it's worth checking. As a side note: I'm currently working on making stack unwinding work for user mode TAs (that is, dump the call stack to the console when an abort occurs while executing a TA). For this to work with 32-bit TAs, -funwind-tables is needed, and although the flag is normally not needed for 64-bit TAs I will make sure it doesn't break things at least. But in the mean time, please let me know how things work for you.

[vchong]

Mine hikey board is 64bit arch , compiling aosp with arm-linux-androideabi-

Shouldn't this be aarch64-linux-android-?

[deepakmnvl]

@jforissier I tried removing -funwind-tables and also adding -fno-unwind-tables , but , .eh_frame section doesnt go away. Strange.

@vchong yes, its aarch64- . Its copy-paste error, my bad

@etienne-lms No debug trace. I got the error code printed in my code.

I am linking around 8 static libs with the TA , could it be a memory issue. Should I increase memory sizes for TA somewhere ?

Thanks

[deepakmnvl]

well , I did a small experiment . I compiled a small static lib with my code which just returns a const value, say 72. Now , I have linked this static lib with my TA , and viola, I can retrieve 72.

So , it really seems memory issue while loading the TA ?

I need to link around 14 static libs of total size ~ 4.5mb with my TA. Is that possible ?

[etienne-lms]

Try to add some traces in the core at all point where TEE_ERROR_BAD_FORMAT is set as return value in user_ta.c and elf_load.c. That could help finding out at which point the core complains about your TA, and whether it is related to the ELF format content or to OP-TEE specific expectations from the TA binary content.

[deepakmnvl]

hi , I reduced my static libs size to ~3.3mb , and now , I am able to call TA side from NW side successfully.

So , is there any limitation for memory allocated for each TA ? and any way to increase it ? And how to increase stack and heap size in a TA ? in this file -> user_ta_header_defines.h ?

[deepakmnvl]

hi , I am not getting logs , like below :

DEBUG: [0x0] TEE-CORE:tee_ta_init_static_ta_session:160: Lookup for Static TA 1111a200-2450-11e4-abe2-0002a5d5c51b DEBUG: [0x0] TEE-CORE:init_session_with_signed_ta:775: Load dynamic TA DEBUG: [0x0] TEE-CORE:ta_load:506: Loaded TA at 0x8e100000 DEBUG: [0x0] TEE-CORE:ta_load:507: ELF load address 0x101000 DEBUG: [0x0] TEE-CORE:init_session_with_signed_ta:781: dyn TA : 1111a200-2450-11e4-abe2-0002a5d5c51b FLOW: [0x0] TEE-CORE:trace_syscall:144: syscall #1 (syscall_log) DEBUG: USER-TA: tee_user_mem_alloc:343: Allocate: link:[0x111b98], buf:[0x111ba8:16]

Infact , I never got any logs like "TEE-CORE:"

I am routing all logs to uart0. My build cmd has "CFG_NW_CONSOLE_UART=0 CFG_SW_CONSOLE_UART=0 CFG_CONSOLE_UART=0"

Is there any other flag for this ?

Thanks

[vchong]

Try adding OPTEE_EXTRA_FLAGS ?= CFG_TEE_CORE_LOG_LEVEL=3 CFG_TEE_TA_LOG_LEVEL=3 DEBUG=1 to device/linaro/hikey/optee-packages.mk and rebuild fip.bin.

[vchong]

Add it at the top of the file please.

[deepakmnvl]

hey @vchong , the line you gave already existed in addition , I made below changes: device/linaro/hikey/bootloader/Makefile --------- hardcoded as DEBUG

device/linaro/hikey/bootloade/uefi-tools/opteed-build.sh ----------- modified line as CFG_TEE_CORE_LOG_LEVEL=4 my cmd: make TARGET_TEE_IS_OPTEE=true CFG_NW_CONSOLE_UART=0 CFG_SW_CONSOLE_UART=0 CFG_CONSOLE_UART=0 DEBUG=1

Now , I am getting TEE-CORE logs :)

well, I had to do this since my TA is not getting loaded, and the logs is like this :

127|hikey:/ # DEBUG: [0x0] TEE-CORE:tee_ta_init_static_ta_session:160: Lookup for Static TA d96a5b40-c3e5-21e3-8794-1002a5d5c61b DEBUG: [0x0] TEE-CORE:init_session_with_signed_ta:719: Load dynamic TA DEBUG: [0x0] TEE-CORE:tee_ta_open_session:478: init session failed 0xffff0005 DEBUG: [0x0] TEE-CORE:tee_dispatch_open_session:127: => Error: ffff0005 of 3

Any help here pls ??

[etienne-lms]

Make sure your TA does set TA_FLAG_EXEC_DDR as well as TA_FLAG_USER_MODE. These attributes are mandatory (even if not really meaningful, there should be some cleaning about them). See the optee_test test TAs as example: i.e https://github.com/OP-TEE/optee_test/blob/master/ta/os_test/include/user_ta_header_defines.h#L37.

[deepakmnvl]

hi @etienne-lms I do have #define TA_FLAGS (TA_FLAG_MULTI_SESSION | TA_FLAG_EXEC_DDR )

Also , added TA_FLAG_USER_MODE as you said. Still issue exists.

Another thing is , I removed all my static libs which are being linked with the TA , and verified with a small sample lib , and ITS WORKING FINE I believe , this got something to do with memory for TA .

Is there any way to increase it ?

[etienne-lms]

Check CFG_TA_RAM_SIZE for your platform (check th early logs of OP-TEE core). It should obviously be at least bigger than the few MByte of your target TA (the one with the static lib linked into).

Maybe try to rebuild your core with CFG_TA_RAM_SIZE increased, but I doubt it is the root cause of your issue. Be warn that increasing CFG_TA_RAM_SIZE may have impact on the overall system memory layout.

... Ow ! thinking about it: is the shared memory big enough to store your TA ? The current TA load process does use a single buffer in the nonsecure shared memory (OP-TEE SHM) to fully store the TA binary blob before it gets copied/installed into the secure memory. Check CFG_SHMEM_SIZE. However I would have expected an explicit error trace for such an issue.

Another test, in case CFG_TA_RAM_SIZE and CFG_SHMEM_SIZE were already well sized: Using the TA that currently loads ok (the one without the static lib), try this TA with some dummy content you can increase easily (i.e static const char dummy[1 << 20] = { 1 };, here this should increase your TA binary by 1MByte). Check up to which size the TA gets successfully loaded.

[deepakmnvl]

Hi , I have been adding logs to check exact point of issue

I see that in elf_load.c -> e64_process_rel() ->

  where = (Elf64_Addr *)(vabase + rela->r_offset);
  if (!ALIGNMENT_IS_OK(where, Elf64_Addr))
            {
                return TEE_ERROR_BAD_FORMAT;
            }

At this point , my TA loading failed.

Can you tell me cause of this issue ?

Thanks

[jenswi-linaro]

My guess is that there's a new relocation type that we don't handle. Try to print ELF64_R_TYPE(rela->r_info).

[deepakmnvl]

Hi @jenswi-linaro , thanks for reply , there is some code in my libs which is using pragma(pack) options. I was able to sort that out , and now TA loading is fine

[deepakmnvl]

hi , upto what size RAM for TA (TZDRAM_SIZE) can be allocated. I tried giving 64MB , but got below error : ERROR: Error initializing runtime service opteed_fast

Thanks

[deepakmnvl]

I tried changing in "device\linaro\bootloader\arm-trusted-firmware\plat\hikey\hikey_def.h"

and modified DRAM_SEC_SIZE to 0x02800000 (40MB)

Mem sizes also reflected in boot log

NOTICE: BL3-1: Built : 17:46:23, May 19 201DEBUG: [0x0] TEE-CORE:add_phys_mem:257: CFG_SHMEM_START 4 0x3ce00000 size 0x00a00000 DEBUG: [0x0] TEE-CORE:add_phys_mem:257: CFG_TA_RAM_START 3 0x3e000000 size 0x02000000 DEBUG: [0x0] TEE-CORE:add_phys_mem:257: CFG_TEE_RAM_START 1 0x3d800000 size 0x00800000

Now, Booting went ahead few more steps only to stop at :

Loading driver at 0x00035237000 EntryPoint=0x0003624CC40 Loading driver at 0x00035237000 EntryPoint=0x0003624CC40 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...

Seems , I need to modify in linux kernel too, Can anybody give inputs regarding where to change ? dts file may be ?

Thanks

[jforissier]

The memory used by OP-TEE is reserved by UEFI in edk2/HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c:

STATIC struct HiKeyReservedMemory {
  EFI_PHYSICAL_ADDRESS         Offset;
  EFI_PHYSICAL_ADDRESS         Size;
} HiKeyReservedMemoryBuffer [] = {
  { 0x05E00000, 0x00100000 },    // MCU
  { 0x05F01000, 0x00001000 },    // ADB REBOOT "REASON"
  { 0x06DFF000, 0x00001000 },    // MAILBOX
  { 0x0740F000, 0x00001000 },    // MAILBOX
  { 0x21F00000, 0x00100000 },    // PSTORE/RAMOOPS
  { 0x3E000000, 0x02000000 }     // TEE OS
};

You can also set it aside in the DT thanks to the reserved-memory node (might be a bit easier for experimentation since you need to rebuild only the .dtb).

[deepakmnvl]

Hi , seems , am stuck now.

I modified my total TA RAM size to 64MB (to make it as multiple of 64) Now , log is coming upto :

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

I am not getting "adb devices" or "fastboot devices"

I tried going into board recovery. On uart0 , I am getting :

usb reset intr reset device done. start enum. enum done intr NULL package Enum is starting. NULL package USB ENUM OK. init ser device done....

and am not getting ttyUSB0 to use "hisi-idt.py"

my dmesg output is :

[33045.043018] option 1-6:1.0: GSM modem (1-port) converter detected [33045.043143] usb 1-6: GSM modem (1-port) converter now attached to ttyUSB0 [33045.662154] usb 1-6: USB disconnect, device number 49 [33045.662425] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [33045.662440] option 1-6:1.0: device disconnected

What can be done now to recover my board ?? Pls help :(

[jforissier]

I tried going into board recovery. On uart0 , I am getting :

usb reset intr reset device done. start enum. enum done intr NULL package Enum is starting. NULL package USB ENUM OK. init ser device done....

That looks good, at this point the board is waiting for hisi-idt.py to transfer stuff.

and am not getting ttyUSB0 to use "hisi-idt.py"

Oh?

my dmesg output is :

[33045.043018] option 1-6:1.0: GSM modem (1-port) converter detected [33045.043143] usb 1-6: GSM modem (1-port) converter now attached to ttyUSB0 [33045.662154] usb 1-6: USB disconnect, device number 49

That's weird. I've never seen that :( Disconnection should not occur until after 60s have elapsed (the board switches to UART download). Something else must be happening.

[33045.662425] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [33045.662440] option 1-6:1.0: device disconnected

What can be done now to recover my board ?? Pls help :(

Have you tried powering off the board and rebooting the PC?

[deepakmnvl]

Have you tried powering off the board and rebooting the PC?

Yes , I did but same result.

ttyUSB0 appears for a very very short moment , and then disappears. Is there any other method to recover the board ?

EDIT: Is it possible to boot hikey board from sdcard in this scenario ?

[jforissier]

Is it possible to boot hikey board from sdcard in this scenario ?

~I don't think so :(~ Edit: not sure, see below

One other thing: make sure you don't have any USB device connected to the type A ports when doing recovery. Only the USB OTG (micro USB) should be connected.

[deepakmnvl]

No other cable connected . Just power cable and microUSB cable on hikey board

I dont understand how recovery mode too is failing as bootloader in this mode should be loaded from ROM itself . Strange

So , any way to program from serial port ? What can be done now ??

[vchong]

Try a new cable? Also try sudo apt-get purge modemmanager to see if it helps. Or try installing from an SD card: https://github.com/Linaro/documentation/blob/master/Reference-Platform/Releases/RPB_16.06/ConsumerEdition/HiKey/InstallDebianRPB.md#sd-card-method Hopefully one of these works. :s

[jforissier]

• First about SD card: actually I think I was wrong when I said you can't boot from SD card. I was thinking somehow the eMMC has to take control then switch to SD card. But that's incorrect. Actually, I think the board first tries SD card then eMMC (when not in recovery mode of course). I don't use an SD card that's why I'm not sure how it works actually ;)
• About recovery: what is shown on UART0 after "init ser device done....", if you wait at least 60s? You should see: "usb data recieving 60s time out...." "Switch to UART download...". If so, then please try to flash the bootloader over UART0. For that you kill your terminal program connected to the console on UART0, and you run hisi-idt.py over UART0 like so: sudo python hisi-idt.py -d /dev/ttyUSB0 --img1=path/to/l-loader.bin (of course replace /dev/ttyUSB0 if needed).

[deepakmnvl]

Thanks for your replies @vchong @jforissier

1. tried 2 different cables
2. removed modemmanager
3. no msg comes after "init ser device done...." even after 2mins So , no luck with above trials

Will check booting from SD card

[deepakmnvl]

I inserted an empty micro SD card into hikey board and booted it. Below are few initial logs :

debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1! NOTICE: acpu_dvfs_set_freq: set acpu freq success!NOTICE: BL2: v1.1(release):36aa82d NOTICE: BL2: Built : 18:05:53, May 19 2017 NOTICE: BL3-1: v1.1(release):36aa82d NOTICE: BL3-1: Built : 18:05:53, May 19 201DEBUG: [0x0] TEE-CORE:add_phys_mem:257: CFG_SHMEM_START 4 0x3b600000 size 0x00a00000 DEBUG: [0x0] TEE-CORE:add_phys_mem:257: CFG_TA_RAM_START 3 0x3c800000 size 0x03800000 DEBUG: [0x0] TEE-CORE:add_phys_mem:257: CFG_TEE_RAM_START 1 0x3c000000 size 0x00800000

and they end with

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

Strangely , dmesg is empty :(

and I tried fastboot mode and recovery mode with SDcard in its slot, but nothing worked

[vchong]

"empty micro SD card" means there are no images inside?

[deepakmnvl]

aah.. its a typo, sorry for confusion

@vchong , I followed your post and installed debian image on my sdcard and above is the result

[vchong]

So did the installation go well? If so, you should boot to a command prompt. Did you try Jerome's suggestion of flashing the bootloader over UART0? Or maybe try another USB port on your PC or even another PC? This is a first for me too and running out of ideas as well.

[jforissier]

@vchong flashing over UART0 probably won't work since "init ser device done...." was never followed by "Switch to UART download...". It looks like the FW is dead at this point?

[deepakmnvl]

@vchong , when I used debian loaded SD card, the log shows :

debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!

Seems , SDcard never got started . I also checked with another native linux PC.

Another point to note : We have another hikey board , being used by colleague. It has GOOD bootable image. Now, even for that board , when I enter recovery mode , ttyUSB0 is not appearing.

What can be problem ?

[jforissier]

What can be problem ?

Your PC?