On 04/22/2016 06:03 PM, Mark Rutland wrote:
On Fri, Apr 22, 2016 at 11:39:48AM +0200, Ard Biesheuvel wrote:
On 22 April 2016 at 11:32, Mark Rutland mark.rutland@arm.com wrote:
On Fri, Apr 22, 2016 at 05:13:08PM +0800, Heyi Guo 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 take it by 'flush' you mean the Clean+Invalidate (i.e. the DC CIVAC).
That should only cause a writeback if data is dirty, and should be a NOP otherwise, so if this is causing problems then there is a latent issue regardless.
Dirty data can be naturally evicted from the cache at any time, for any reason, regardless of explicit cache maintenance.
Assuming that this code executes with the MMU off, it probably means there is junk in the caches?
Perhaps.
That itself is a major/worse problem; platform-specific initialisation code on the secure side must initialise (i.e. invalidate) caches out-of-reset if they reset to garbage, or the caches are effectively unusable even ignoring issues from natural evictions.
So I don't think there will be junk in the caches, or else we would have had problems before. I will check with our silicon developers to find out the reason.
Thanks and Regards.
Heyi
Thanks, Mark.