Hi,
After upgrading to 9.2.4, which seems to be more strict with unaligned
accesses, and after fixing the cortex-a76 alignment faults by enabling the mmu,
I have a related issue with the cortex-a15 tests.
From what I read, this is not related to mmu, apparently the core itself must
handle unaligned accesses.
However, even after explicitly clearing the A bit in SCTLR, I still get a data
fault.
The code is quite simple:
```
.globl _interrupt_vectors
// "x" makes it visible in the listing.
.section .interrupt_vectors,"awx",%progbits
.align 7
_interrupt_vectors:
.balign 4
b Reset_Handler
b undefined_handler
b swi_handler
b prefetch_handler
b data_handler
nop // Reserved vector
b irq_handler
b fiq_handler
...
.section .after_vectors,"awx",%progbits
.align 2
.globl Reset_Handler
.type Reset_Handler, %function
Reset_Handler:
#if defined(__ARM_ARCH_7A__)
// DEN0013D_cortex_a_series_PG.pdf
// 13.1 Booting a bare-metal system
// Only CPU 0 performs the initializations. All other CPUs go into WFI.
// To do this, first work out which CPU this is by reading MPIDR.
mrc p15, 0, r1, c0, c0, 5 // Read Multiprocessor Affinity Register
and r1, r1, #0x3 // Extract CPU ID bits
cmp r1, #0
beq .Lcpu0_initialize // If we’re on CPU0 goto the start.
.Lcpu_sleep:
wfi // Other CPUs are left sleeping.
b .Lcpu_sleep
.Lcpu0_initialize:
ldr r0, =__stack
mov sp, r0
ldr r0, =_interrupt_vectors
mcr p15, 0, r0, c12, c0, 0
dsb
// Configure SCTLR in one operation: disable MMU + configure unaligned
access
mrc p15, 0, r1, c1, c0, 0 // Read SCTLR once
bic r1, r1, #0x1 // Clear M bit (MMU)
bic r1, r1, #(1 << 1) // Clear A bit (alignment faults)
orr r1, r1, #(1 << 22) // Set U bit (unaligned access model)
mcr p15, 0, r1, c1, c0, 0 // Write SCTLR once
dsb // Data Synchronization Barrier
isb // Instruction Synchronization Barrier
// Test unaligned access
ldr r0, =0x40000001 // Odd address (unaligned for 32-bit load)
ldr r1, [r0] // This should work with hardware handling
// Use bl instead of b to have a proper stack record for GDB
// to display a full stack trace.
bl _start
```
If I run this in a debugger, when executing the `ldr r1, [r0]` instruction, the
debugger halts at address 0x40000010, which is the branch to the data_handler,
with DFSR = 1 (unaligned access) and DFAR = 0x40000001 (the odd address).
I don't have a physical board at hand, so I do not know if my initialisation
sequence is correct or not.
Is there anything else I have to configure for the emulated cortex-a15 in order
to accept unaligned accesses?
Thank you,
Liviu
