On 22 April 2016 at 11:31, Heyi Guo heyi.guo@linaro.org wrote:
On 04/22/2016 05:16 PM, Ard Biesheuvel wrote:
On 22 April 2016 at 11:13, Heyi Guo heyi.guo@linaro.org wrote:
Hi Ard,
I actually found this patch caused SERR on D02, for the library constructor it is using.
The function AArch64LibConstructor will be called in every module if it directly or indirectly invokes ArmLib.
Our case is like below:
- We have a PEIM, which invokes HobLib -> PeiServicesLib ->
PeiServicesTablePointerLib -> ArmLib. 2. So it will integrate this constructor and flush the code at the beginning of module entry. 3. For the code is running on Flash, we actually flush the flash area, and then a SERR occurs.
I'm not sure if it is a common issue of generating SERR when flush flash space, but, as ArmLib is such a fundamental library, do we really need to make the function as a library constructor instead of being called on demand?
I think the issue here is that the ordinary ArmLib may not be suitable for PEIMs. There is also AArch64LibSec.inf, which is the same library but without the constructor. Could you try that please?
We have memory initialization PEIM, which needs to configure MMU after memory initialization is done. So AArch64LibSec is not sufficient, and it will still cause issue on our platform.
Ah yes, that doesn't have the MMU code. In any case, the cache maintenance is only necessary if not executing in place, so we should be able to create a PEI version without the constructor, but with the MMU routines. We should probably have an alternate version of ArmReplaceLiveTranslationEntry that asserts that the MMU is disabled.