Synchronous Exception at 0x0000000000000000 while flashing prm_ptable.img

I replaced my UFS with a 128GB one, then I try to install debian on this new UFS, but I got this Synchronous Exception at 0x0000000000000000 after flashing prm_ptable.img.
My operation steps are as below:

Step 1:
./hikey_idt -c config -p /dev/ttyUSB0

For this step no any problem, it just downloads three images into Dram:
Config name: config
Port name: /dev/ttyUSB0
0: Image: sec_usb_xloader.img Downalod Address: 0x20000
1: Image: sec_uce_boot.img Downalod Address: 0x6a908000
2: Image: l-loader.bin Downalod Address: 0x1ac00000
Serial port open successfully!
Start downloading sec_usb_xloader.img@0x20000…
file total size 99648
downlaod address 0x20000
Finish downloading
Start downloading sec_uce_boot.img@0x6a908000…
file total size 23680
downlaod address 0x6a908000
Finish downloading
Start downloading l-loader.bin@0x1ac00000…
file total size 1081344
downlaod address 0x1ac00000
Finish downloading

Meanwhile, on my console, i got the fastboot shell.

Step 2: fastboot flash ptable prm_ptable.img
According to the Debian tutorial, I start to flash the partition table, but i got this error:

**downloading 24576 bytes **
** 24576 / 24576 bytes downloaded (100%) **
**Flashing partition ptable **
Synchronous Exception at 0x0000000000000000

who can tell me what is wrong? and how to fix this issue?

I suppose that maybe there is something wrong in previous downloaded three images. but i don’t know how to fix this.

please tell me where I can get these three files source code???
let me fix myself.

@jackyard For board recovery, I generally use this guide [1]. Here you can find the steps to generate l-loader.bin and partition table from source. I doubt the issue you are facing could be due to “sec_usb_xloader.img” or “sec_uce_boot.img” binaries. So I would firstly suggest you to try this guide [1].


I’m afraid HiSilicon do not release the source code for these binaries.

What’s the vendor for the new UFS chip?

The issue looks very much like Marginality with UFS chip change? - #27 by baou

What’s the vendor for the new UFS chip?

Hikey960 has had to update UFS chip twice… but I think it was the
Hynix part that motivated code changes.

hi, @baou
it is Micron UFS, when I flash android bootload images, no problem.
this only happens on debian.
I suppose there is something wrong in these three images:

sec_usb_xloader.img 0x00020000
sec_uce_boot.img 0x6A908000
l-loader.bin 0x1AC00000

would you please forward this problem to Hisilicon? it is very easy to reproduce this issue.


After much time looking around I think the “synchronous exception at 0x0000…” problem (in my case occurring with boards provisioned with Toshiba UFS device specifically) recovers from this EDK2 commit:

commit 245344ea5421ba126e1eb76484d00b590a4a78f7 (HEAD → testing/hikey960_v1.3.4, origin/testing/hikey960_v1.3.4)
Author: qwx495460
Date: Tue Apr 23 15:09:29 2019 +0800

Drivers/DwUfsHcDxe: add memory barrier

UFS device couldn't be initialized by UEFI on some HiKey960 platforms
if it's built in release mode. Since UFS device is not initialized
successfully, UEFI couldn't read any valuable data from UFS device.
Then it hangs.

After adding memory barrier, UFS device could be initialized successfully.
So this issue may be related to instructions out of order by CPU

I’m now able to flash such boards appropriately. It is worth checking if you would not be affected by the same problem with Micron device.


This change doesn’t work on my side, also we removed memoryfence(), also doesn’t work.
we did some debug, found that it is because edk2 didn’t read UFS device descriptor properly.

UfsControllerInit Finished
Query Response with General Failure
DBG INFO: UPIU Response value 0xFF, status is 0x0, ocs 0x0.
Ufs Get Dev Descriptor Error, Status = Device Error

Okay, that may be a different problem then.
The timings issue with THG UFS device seems almost gone with this change.
Your issue might be because of yet another vendor is used aka Micron, for which EDK2 does not know the UFS device descriptors. You might get same kind of problem with kernel boot, right? (like it happened for Hynix devices at the time)?

No, Linux doesn’t have any problem at all. it can detect UFS and read all descriptor. I can use recovery.bin directly load Linux image from SD card, then Linux can access UFS very well. The problem is that I cannot flash any image to UFS in fastboot with recovery.bin, just because of edk2 problem, which can not read out UFS device descriptor.
I think there is something wrong in edk2 during UFS host PA initialization. Challenge is that we don’t have its PA datasheet, cannot do debug.

another weirder condition is that this issue doesn’t happen on Android, I think because we didn’t flash edk2, the last image in the config file is fastboot.bin.

./hisi-sec_usb_xloader.img 0x00020000
./hisi-sec_uce_boot.img 0x6A908000
./hisi-sec_fastboot.img 0x1AC00000 --------------fastboot for android

For the debian, that is recovery.bin or l-loader.bin, both images have the same problem:
./hisi-sec_usb_xloader.img 0x00020000
./hisi-sec_uce_boot.img 0x6A908000
./recovery.bin or l-loader.bin 0x1AC00000 --------------edk2 for debian