Failed mounting rootfs on HiKey960 board with Hynix UFS flash

Products Support HiKey 960
#1

We have two types of HiKey960 boards, one with Samsung flash and another with Hynix flash. On board with Samsung flash, everything worked normally, both Linaro image and my own built image can boot without problem. But on newer board with Hynix flash, the linux kernel failed mounting root fs, and there are some “ufshcd” error messages printed on console:

[ 35.977642] ufshcd-hi3660 ff3b0000.ufs: ufshcd_issue_tm_cmd: task management cmd 0x08 timed-out
[ 35.986602] ufshcd-hi3660 ff3b0000.ufs: ufshcd_eh_device_reset_handler: failed with err -110
[ 36.106284] ufshcd-hi3660 ff3b0000.ufs: dme-link-startup: error code 1
[ 36.288832] ufshcd-hi3660 ff3b0000.ufs: ufshcd_read_desc_param: Failed reading descriptor. desc_id 0 param_offset 0 buff_len 31 ret 0
[ 36.301212] ufshcd-hi3660 ff3b0000.ufs: ufs_get_device_info: Failed reading Device Desc. err = -22
[ 36.310420] ufshcd-hi3660 ff3b0000.ufs: ufs_advertise_fixup_device: Failed getting device info. err = -22
[ 36.322185] ufs final power mode: gear = 3, lane = 2, pwr = 1, rate = 2
[ 36.328946] ufshcd-hi3660 ff3b0000.ufs: set TX_EQUALIZER 3.5db
[ 36.337630] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane0 = 0x1
[ 36.345114] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane1 = 0x1
[ 46.613656] ufshcd-hi3660 ff3b0000.ufs: ufshcd_task_req_compl: failed, ocs = 0xf
[ 46.621450] ufshcd-hi3660 ff3b0000.ufs: ufshcd_abort: failed with err 15

I’m not sure if the failure was caused by the Hynix flash, has somebody ever met similar UFS issue?

Filesystem not available
#2

I found the firmware tools has support Hynix flash, see blew patch information.

linux kernel may also need adding support for Hynix flash device!

commit 6769f8658ba2c286fe209c34365535e1f42bd0c5
Author: Guodong Xu guodong.xu@linaro.org
Date: Thu Mar 15 16:08:27 2018 +0800

xloader: hynix ufs init fail bug fixed

This patch provides support to Hynix UFS device, which is used on
HiKey960 boards manufactured after 2018 April.

Not updating binary in time will block booting of these new
HiKey960 boards.

Signed-off-by: Kaihua Zhong <zhongkaihua@huawei.com>
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>

Who can help to confirm this issue?

#3

+ @guodong, Guodong might know well for this.

#4

I try the 4.4 kernel, the board can startup, but the default 4.9 kernel can not boot!
Who can help to find the root cause and fix this problem on 4.9 kernel ?

#5

Hi @wuzhigang, I’m having the same issue also with latest debian (kernel 4.15), Samsung parts work fine but HK won’t load the rootfs. Did you find a solution?

#6

Hi,

Was there any follow up on this ?
We hit this issue now, Hynix UFS does not mount with stock K4.9 ?..

Cheers.

#7

Hi, no follow up I’m booting the kernel and rootfs from uSD after UEFI bootloader boots in ram with hikey_idt. Then I can play with the UFS as external card…

Regards

#8

Does your kernel have this in it?
https://android.googlesource.com/kernel/hikey-linaro/+/366d8a78174a8be6965909e94bbb81cb67f9a28a^!/#F0

#9

Hi,

Thanks for following up.
Yes actually the kernel I used was from March '18 and I think the relevant fixes for SK Hynix lie in the commits coming after (UFS read descriptor fixes and so on). So I just pulled latest and now kernel progressed with correct UFS init.

Then I’m now facing a new issue possibly related to device tree incorrectly transmitted to kernel.
Basically I get this below on booting and system just reboots to bootloader.
Android images were built from master branch based on Using Reference Boards  |  Android Open Source Project
Strangely vendor and system partitions are not found even though I flashed the various partitions as mentioned in the flashing steps … If you have an idea pls let me know… Thanks

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…
[…]
[ 7.764801] init: init first stage started!
[ 7.769143] init: Using Android DT directory /proc/device-tree/firmware/android/
[ 7.777143] init: [libfs_mgr]dt_fstab: Skip disabled entry for partition vendor
[ 7.784633] init: [libfs_mgr]dt_fstab: Skip disabled entry for partition system
[ 7.792063] init: [libfs_mgr]fs_mgr_read_fstab_dt(): failed to read fstab from dt
[ 7.799711] init: Failed to read fstab from device tree
[ 7.805359] init: [libfs_mgr]fs_mgr_read_fstab_default(): failed to find device default fstab
[ 7.814185] init: [libfs_mgr]dt_fstab: Skip disabled entry for partition vendor
[ 7.821646] init: [libfs_mgr]dt_fstab: Skip disabled entry for partition system
[ 7.829121] init: [libfs_mgr]fs_mgr_read_fstab_dt(): failed to read fstab from dt
[ 7.836911] wlcore: ERROR could not get configuration binary ti-connectivity/wl18xx-conf.bin: -11
[ 7.837123] Bluetooth: hci0: request_firmware failed(errno -11) for ti-connectivity/TIInit_11.8.32.bts
[ 7.837124] Bluetooth: hci0: download firmware failed, retrying…
[ 7.837401] kvm: exiting hardware virtualization

Regards.

#10

Are your bootloaders up to date?

#11

Yes, I pulled/rebuilt all from scratch today. But then I remember in the past there was a special way to generate the boot.img by appending dtb to Image.gz and then using abootimg with Image-dtb and ramdisk.
Is this still relevant now? I wonder if this may conflict with the fastboot flash dts dt.img command.
Is this possible that the kernel the wrong one and messes up?

#12

You may breaking it by running needless steps.

Try this;

. build/envsetup.sh
m -j9
cd device/linaro/hikey/installer/hikey960
./flash-all.sh
#13

I will try that when I get android rebuilt on my pc (takes ages :))

In the meantime I think I narrowed down the issue to the kernel command line, mainly I updated it in bootimg-960.cfg with :
overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab

Now init manages to find system and vendor partitions from DT description…

#14

I am not sure how many Hikey960 board variants totally, some experts has the information here to clarify ?

#15

Not expert here. I could manipulate at least three variants mainly differentiated by the UFS mass storage chip vendor:
Samsung 32GB UFS / 3 GB DRAM
Toshiba 32GB UFS / 3GB DRAM
Hynix 32GB UFS / 4GB DRAM

I actually had various flashing issues with 2nd batch (Toshiba UFS) and those problems are not solved AFAIK. This arises specifically if you need to rebuild whole firmware from scratch (ATF, bootloaders, etc.). I think this is more stable if you use stock firmware images.

#16

Wow, I have yet another configure, Samsung 32GB UFS / 4GB DRAM
I do hope some official information could be posted to clarify things up.

@Baou, thanks.

#17

I’m having the same issue (hikey960 revB with Hynix UFS Flash). How to fix it :slight_smile:
About resource, I use:

Thanks for your help

#18

Hi,

I have used 4.9 as recommended in Using Reference Boards  |  Android Open Source Project

if you compare 4.4 and 4.9 drivers/scsi/ufs/ufshcd.c
I think 4.9 has supplementary patches covering bugs with UFS descriptor reading:

https://android.googlesource.com/kernel/hikey-linaro/+log/android-hikey-linaro-4.4/drivers/scsi/ufs/ufshcd.c
https://android.googlesource.com/kernel/hikey-linaro/+log/android-hikey-linaro-4.9/drivers/scsi/ufs/ufshcd.c

I’m not sure how 4.4 is maintained but most likely you need to merge or cherry pick such patches…

e192845 scsi: ufs: Factor out ufshcd_read_desc_param by Potomski, MichalX · 1 year, 7 months ago
be4d66d scsi: ufs: refactor device descriptor reading by Tomas Winkler · 1 year, 9 months ago
b0a12b4 scsi: ufs: fix failure to read the string descriptor by Subhash Jadavani · 1 year, 10 months ago

Cheers.