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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot