On Sun, Aug 10, 2014 at 02:35:46PM -0700, ron minnich wrote:
You can't assume much of anything. That commit seems not that harmful. What would help is if you tell us more about when the problem happens. There's just not enough info in your note, but I'd love to try to help.
I will try to do my best.
Problem occurs at very early phase. There is no coreboot gdb support so I used qemu '-s -S'. Whole qemu command:
qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom -s -S
Exactly at address 0x6001024f qemu tries to execute:
0x60010249: adds r3, #1 0x6001024b: cmp r3, #7 0x6001024d: bne.n 0x6001019c => 0x6001024f: ldmia.w sp!, {r2, r3, r4, r5, r6, r7, r9, r10, r11, pc} 0x60010253: movs r3, #0 0x60010255: mcr 15, 0, r3, cr8, cr7, {0} 0x60010259: mcr 15, 0, r3, cr8, cr6, {0} 0x6001025d: mcr 15, 0, r3, cr8, cr5, {0}
I can't find this instruction in coreboot code.
Registers before executing ldmia: R0: 0x00000002 R1: 0x00000000 R2: 0xFFFFFFFE R3: 0x00000007 R4: 0x00000000 R5: 0x00000000 R6: 0x09000003 R7: 0x00000004 R8: 0x00000000 R9: 0x00000000 R10: 0x00000000 R11: 0x00000000 R12: 0x00000000 SP: 0x0007FEA8 LR: 0x6001032F PC: 0x6001024E
And after: R0: 0x00000002 R1: 0x00000000 R2: 0x00000000 R3: 0x00000000 R4: 0x00000000 R5: 0x00000000 R6: 0x00000000 R7: 0x00000000 R8: 0x00000000 R9: 0x00000000 R10: 0x00000000 R11: 0x00000000 R12: 0x00000000 SP: 0x0007FED0 LR: 0x6001032F PC: 0x00000000
PC goes to 0 and we jumping to code where is 'andeq r0, r0, r0'. Qemu execute the same instruction till PC reach 0x4000000, then ends execution with:
qemu: fatal: Trying to execute code outside RAM or ROM at 0x04000000
Hope this is enough information.
Thanks, Piotr