cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
1,585 Views
Registered: ‎06-29-2015

Alignment Fault only on second core

Jump to solution

We have two legacy applications that I have to run on the Zynq7000.  They are running BareMetal in AMP mode on the two CPUs.

 

My problem is that we get a data abort - Alignment fault on the second CPU when accessing 32-bits on a non-word aligned address with a STR instruction.  It only happens on CPU#1 and not CPU#0 even though their initialization is almost identical.

 

SCTLR.A is cleared on both CPUs.

 

Any idea of why this is happening?

 

Thanks.

0 Kudos
1 Solution

Accepted Solutions
2,165 Views
Registered: ‎06-29-2015

Thanks, that helped.

 

The problem is that the MMU was not enabled on the second core and neither was cache.

 

The MMU was not enabled on the second core because doing so would crash it.  The root cause of my problem is that DACR has a different reset value on CPU0 and CPU1.  All the memory groups are not available on the second core, so it has no memory as soon as the MMU is enabled.

 

To fix my problem I had to set DACR to 0xFFFFFFFF on both cores (I don't use memory groups) and then enable the MMU on both CPUs.

View solution in original post

0 Kudos
5 Replies
hpoetzl
Voyager
Voyager
1,550 Views
Registered: ‎06-24-2013

Hey pieter.winter@stonethree.com,

 

It only happens on CPU#1 and not CPU#0 even though their initialization is almost identical.

What about the address where the unaligned access happens?

 

By default, unaligned access with load/store is broken down into aligned accesses, which works fine for memory but might not work that well with AXI mappings or peripherial registers.

 

Best,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
ericv
Scholar
Scholar
1,532 Views
Registered: ‎04-13-2015

pieter.winter@stonethree.com

 

Did  you try adding to the command line

-mno-unaligned-access

to force the compiler to only generate aligned accesses?

0 Kudos
1,509 Views
Registered: ‎06-29-2015

Hi guys,

 

Access is to OCM.  Even if the code was accessing a peripheral, then it should not abort but I agree it could have strange effects as reads are broken up.

 

This is not a compiler issue.  I have a pointer to data that will be misaligned (by design) and this should not cause a data abort.  My issue is not that I have misaligned access but that misaligned access is causing a data abort, which I thought should not happen with SCTLR.A cleared (given a simple load instruction in OCM - See A3.2.1 Unaligned data access in DDI0406C ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition).

 

Regards,

 

Pieter

0 Kudos
ericv
Scholar
Scholar
1,499 Views
Registered: ‎04-13-2015

pieter.winter@stonethree.com

 

Is the OCM set to cached in the MMU table?

From what I've observed, it seems SCTLR.A applies to the L1 cache.

 

0 Kudos
2,166 Views
Registered: ‎06-29-2015

Thanks, that helped.

 

The problem is that the MMU was not enabled on the second core and neither was cache.

 

The MMU was not enabled on the second core because doing so would crash it.  The root cause of my problem is that DACR has a different reset value on CPU0 and CPU1.  All the memory groups are not available on the second core, so it has no memory as soon as the MMU is enabled.

 

To fix my problem I had to set DACR to 0xFFFFFFFF on both cores (I don't use memory groups) and then enable the MMU on both CPUs.

View solution in original post

0 Kudos