Hi all, Recently, I have been debugging the "Synchronous Exception" issue in UEFI. This issue is very strange.If I used the Hisilicon bootloader and 1.3 ATF to launching UEFI,the UEFI could be booted successfully without any issues.But if I used the "l-loader" and 1.3ATF on github to boot UEFI, it would arose a "Synchronous Exception" issue accidentally in FaultTolerantWriteDxe driver in UEFI. That means,with the same "l-loader" boot image on github, sometimes we can launching the UEFI successfully,and sometimes we will get into "Synchronous Exception" in UEFI. And sometimes before exit from the FaultTolerantWriteInitialize function,UEFI will get into "Synchronous Exception".
I debugged this issue for several days,and finally I found that,in front of the "problematic code",there are some "BlockIo" functions in BlockVariableDxe driver which have some relations with the "Synchronous Exception". If the "BlockIo" functions can read and write the EMMC correctly,the UEFI can get into OS loader and boot the kernel successfully without any issues;But sometimes the "BlockIo" functions can't work "really". That means,when we use these functions,we can't make sure these functions have operated the EMMC rightly or not,even though these BlockIo functions return success after being executed. I used the BlockRead function to read one block from the EMMC to a Buffer, sometimes I can get the right value in the Buffer,but sometimes they are all zero or wrong data.
When the BlockRead can't "really" read data from EMMC,the UEFI will get into "Synchronous Exception" in FaultTolerantWriteDxe driver.
I think it is the issue of EMMC which led to the "Synchronous Exception" in UEFI. The "Hiboot" is a full function bootloader,it will initialize the EMMC when we power on the system. But the "l-loader" and 1.3 ATF(not include BL33) didn't initialize the EMMC .
I'm not sure about the relationship between BlockIo function in UEFI and EMMC initialization in previous loader. Does UEFI rely on the eMMC being initialized by previous loader? As we know,the BlockIo functions are the system function supplied by UEFI,and do you know which factors will influence their functionality? Can you give me some advises about this issue? Thanks very much!
Best regards, Wengang
On 2017/8/1 21:39, zhufuwengang wrote:
Hi all, Recently, I have been debugging the "Synchronous Exception" issue in UEFI. This issue is very strange.If I used the Hisilicon bootloader and 1.3 ATF to launching UEFI,the UEFI could be booted successfully without any issues.But if I used the "l-loader" and 1.3ATF on github to boot UEFI, it would arose a "Synchronous Exception" issue accidentally in FaultTolerantWriteDxe driver in UEFI. That means,with the same "l-loader" boot image on github, sometimes we can launching the UEFI successfully,and sometimes we will get into "Synchronous Exception" in UEFI. And sometimes before exit from the FaultTolerantWriteInitialize function,UEFI will get into "Synchronous Exception".
I think it is the issue of EMMC which led to the "Synchronous Exception" in UEFI. The "Hiboot" is a full function bootloader,it will initialize the EMMC when we power on the system. But the "l-loader" and 1.3 ATF(not include BL33) didn't initialize the EMMC .
I porting the EMMC initialization module from "Hiboot" to the BL31 of Arm Trusted Firmware, and reduce the frequency of EMMC from 100MHz to 90MHz. And then, the "l-loader" and ATF can launching UEFI without any issues. I will go deep into this issue,and try to find out the real reason.
I'm not sure about the relationship between BlockIo function in UEFI and EMMC initialization in previous loader. Does UEFI rely on the eMMC being initialized by previous loader? As we know,the BlockIo functions are the system function supplied by UEFI,and do you know which factors will influence their functionality? Can you give me some advises about this issue?
I looked over the MmcDxe driver which was supplied by EDKII. And I found it had a EMMC initialize module,but I think we lack a previous initialization to initialize the EMMC registers for clock and power on module. Regards, Wengang
Thanks very much!
Best regards, Wengang
-
zhufuwengang