Marginality with UFS chip change?

Hi,

I got a batch of Hikey960 boards which I’m almost unable to reflash properly.

I’m using https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md

to rebuild edk2/atf/l-loader etc.

It looks like the trigger is change in UFS chip. With older boards using chip marked “KLU8G…” (Samsung?) everything works like a charm using tools-image-hikey960 script then flashing l-loader’s ptable-aosp-32g.img, l-loader.bin, fip.bin.

Now with boards using chips marked “THGBF…” (Toshiba?), I get issues flashing ptable, or board not booting after BL2 stage such as:

when flashing ptable
Downloading 24576 bytes
24576 / 24576 bytes downloaded (100%)
Flashing partition ptable

Synchronous Exception at 0x0000000000000000

or later when booting:

NOTICE: BL2: Built : 13:46:43, Mar 29 2018
INFO: BL2: Doing platform setup
INFO: UFS LUN0 contains 1024 blocks with 4096-byte size
INFO: UFS LUN1 contains 1024 blocks with 4096-byte size
INFO: UFS LUN2 contains 2048 blocks with 4096-byte size
INFO: UFS LUN3 contains 7805952 blocks with 4096-byte size
INFO: ufs: change power mode success
INFO: BL2: Loading image id 2
WARNING: Firmware Image Package header check failed.
WARNING: Failed to obtain reference to image id=2 (-2)
ERROR: BL2: Failed to load image (-2)

Do you know about flashing issues after switching to this UFS chip and how to stabilize it?

Thanks and Regards.

When did you last pull the tools? Does your tree have:

Hi,
Thanks for your reply.
Yes I have this patch when flashing with tools-image-hikey960 scripts, and indeed this way of recovery always work even on fresh boards.

Moving forward I wonder if this fix related to UFS init might be present in ATF where UFS chip is accessed (e.g. from BL2 to load subsequent images).
That’s where it seems I enter into trouble when rebuilding ATF from scratch… BL2 is not able to init properly and does not load further images ?..

Thanks & Regards.

Let me forward your question to HiSilicon. I’ll come back to you as soon as I got formal response. At the same time, would you mind to tell me the exact string on UFS “THGBF…”, and the number of boards you have with these THG UFS?

So far, I’m not aware of such UFS.

And please confirm one thing: the problem happens with ATF/UEFI only, and doesn’t happen when using the hisi bootloader (https://github.com/96boards-hikey/tools-images-hikey960/blob/master/recovery-flash.sh). Correct?

Hi,

Thanks for your reply.

I can confirm the number by tomorrow; this is from a batch of ~15 boards purchased within the last few weeks.

Best Regards.

Hi,

Yes exactly. No issue with the tools-image-hikey960 repository scripts.
I can flash the “faulty” boards without issue.

But for our own purposes, we need to rebuild ATF/edk2 from scratch.
Then trouble happens with those new boards after flashing the generated aosp ptable, fastboot image (l-loader.bin) then fip.bin. After reboot, it generally hangs around BL2 loader with:

ERROR: BL2: Failed to load image (-2)

So it made me think that the UFS device is not properly initialized and that BL2 is unable to load further images …

Best Regards.

Thanks, @baru for pointing out this issue. We can reproduce it. Linaro and HiSilicon are now working for a solution. Will update you soon.

Thanks for confirming and looking into it!!

to follow up on this thread

boards with the new UFS chip are recovered from edk2 fix:

reference build:
https://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/69/hikey960/debug/

Awesome. Thanks for the update!

the reference build is not available anymore I tried the build:
https://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/70/hikey960/debug/
and
https://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/74/hikey960/debug/
but still have the same issue, i checked the source:
MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c

and the delay is not present. Was the delay implemented in master?

F

Hi,

I must tell I think the issue is not totally gone. I got better results per latest fix but I still have 3 boards (out of 12) showing the issue consistently.

So I guess we should kindly highlight it to Huawei/Linaro folks to have a look at it again.

Cheers.

Hi @baou,
i agree with you, today I tested the build with the patch to be sure the edk2 fix was in and the boot is still failing.

Hi @guodong could you please follow up?

Thanks,
F

branch name is: https://github.com/96boards-hikey/edk2/commits/testing/hikey960_v2.5
@francesco_camarda

@hzhuang1 Please follow up this with HiSilicon.

Thanks @guodong

Hi @hzhuang1 ,
I have tried on 5 different boards and have still the same issue:

storage type is UFS
ufs retry: 6 count v_tx:0 v_rx:0
ufs set v_tx:0 v_rx:0
Hikey960[5301] no need avs_init.
ddr ft:0xf20332a3,mode:1 target:4
UceLdOk
density: 0x08080808,0x08080808,0x08080808,0x08080808,0x08080808,0x08080808,0x08080808,0x08080808 
ddr info 0x000004ff 
400M
685M
1067M
C1R,V0x00000031 e:66
C2R,V0x00000031 e:193
C3R,V0x00000030 e:66
C1R,V0x00000032 e:66
C2R,V0x00000032 e:66
C3R,V0x00000031 e:66
C0R,V0x00000032 e:66
C1R,V0x00000033 e:66
C2R,V0x00000033 e:66
C3R,V0x00000032 e:66
C0R,V0x00000033 e:66
C1R,V0x00000034 e:65
C2R,V0x00000034 e:65
C3R,V0x00000033 e:65
C0R,V0x00000031 e:113
C2R,V0x00000031 e:66
C3R,V0x00000031 e:66
C0R,V0x00000032 e:66
C1R,V0x00000032 e:66
C2R,V0x00000032 e:66
C3R,V0x00000032 e:66
C0R,V0x00000033 e:66
C1R,V0x00000033 e:66
C2R,V0x00000033 e:66
C3R,V0x00000033 e:66
C0R,V0x00000034 e:66
C1R,V0x00000034 e:66
C2R,V0x00000034 e:65
C3R,V0x00000034 e:66
1244M
1866M
pack0Idx0Dcc:0
pack1Idx0Dcc:1
pack2Idx0Dcc:0
pack3Idx0Dcc:1
iomcu_subsys_init
boot_c0 PROFILE 4
slave0 irq0:0x00000004
slave1 irq0:0x00000004
NOTICE:  BL2: v1.5(release):v1.5-615-g781842e
NOTICE:  BL2: Built : 09:48:20, Aug  8 2018
ERROR:   BL2: Failed to load image (-2)

at this point I am not sure it’s the same issue, i got only the final error message.

Regards,
F

It seems that you’re building firmware by yourself. Please list all commits that you’re using.

If you try build #76, what happens?

Hi @hzhuang1,
with build #76:

Build Date: Dec  6 2017, 15:31:59
[clock_init] ++
hikey960 [hikey960_clk_init]
hi3660 [clk_setup]
[clock_init] --
storage type is UFS
ufs retry: 6 count v_tx:0 v_rx:0
ufs set v_tx:0 v_rx:0
Hikey960[5301] no need avs_init.
ddr ft:0xf20332a3,mode:1 target:4
UceLdOk
density: 0x08080808,0x08080808,0x08080808,0x08080808,0x08080808,0x08080808,0x08080808,0x08080808 
ddr info 0x000004ff 
400M
685M
1067M
C1R,V0x00000031 e:66
C3R,V0x00000030 e:66
C1R,V0x00000032 e:66
C2R,V0x00000031 e:193
C3R,V0x00000031 e:66
C0R,V0x00000032 e:66
C1R,V0x00000033 e:66
C2R,V0x00000032 e:66
C3R,V0x00000032 e:66
C0R,V0x00000033 e:66
C1R,V0x00000034 e:65
C2R,V0x00000033 e:66
C3R,V0x00000033 e:65
C0R,V0x00000031 e:113
C2R,V0x00000031 e:66
C3R,V0x00000031 e:66
C0R,V0x00000032 e:66
C1R,V0x00000032 e:66
C2R,V0x00000032 e:66
C3R,V0x00000032 e:66
C0R,V0x00000033 e:66
C1R,V0x00000033 e:66
C2R,V0x00000033 e:66
C3R,V0x00000033 e:66
C0R,V0x00000034 e:66
C1R,V0x00000034 e:66
C2R,V0x00000034 e:65
C3R,V0x00000034 e:66
1244M
1866M
pack0Idx0Dcc:0
pack1Idx0Dcc:1
pack2Idx0Dcc:0
pack3Idx0Dcc:1
iomcu_subsys_init
boot_c0 PROFILE 4
slave0 irq0:0x00000004
slave1 irq0:0x00000004
NOTICE:  BL2: v1.5(release):v1.5-649-g7e8a891f
NOTICE:  BL2: Built : 09:20:38, Aug 14 2018
ERROR:   BL2: Failed to load image (-2)

in my build i only added the delay of 100ms in MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c

Regards,
Francesco

Just want to double check. You’re using recovery.bin in recovery mode, and flush l-loader.bin & fip.bin into UFS. And you’re using all hisi-*img in build #76 in recovery mode. Is it right?