Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/39187 )
Change subject: mb/emulation/qemu-armv7: Fix board ......................................................................
Patch Set 2:
(4 comments)
https://review.coreboot.org/c/coreboot/+/39187/2/src/arch/arm/armv7/bootbloc... File src/arch/arm/armv7/bootblock.S:
https://review.coreboot.org/c/coreboot/+/39187/2/src/arch/arm/armv7/bootbloc... PS2, Line 70: _ebootblock Actually, this needs to be _eprogram, not _ebootblock (and for consistency the start should probably be _program, although there it makes no difference). _eprogram is for the actual size linked, _ebootblock is for however much is reserved for it in memlayout.
https://review.coreboot.org/c/coreboot/+/39187/2/src/arch/arm/armv7/bootbloc... PS2, Line 73: ldmia r2!, {r7-r8} How confident are we that program segment sizes will always be divisible by 8? Is there any guarantee for that (I'm not aware of any)?
Would be another good reason to use memcpy() if you can make it work.
https://review.coreboot.org/c/coreboot/+/39187/1/src/mainboard/emulation/qem... File src/mainboard/emulation/qemu-armv7/bootblock_asm.S:
https://review.coreboot.org/c/coreboot/+/39187/1/src/mainboard/emulation/qem... PS1, Line 59: stmia r0!, {r9-r10}
I tried that but it doesn't work. as it's only 3 instructions I didn't investigated further.
Oh shit, yeah, the memcpy() for arm32 actually uses the stack. That would be why. Maybe just move the relocation to after the stack initialization?
https://review.coreboot.org/c/coreboot/+/39187/1/src/mainboard/emulation/qem... PS1, Line 67: mov pc, lr
no "bl" modifies the state while "mov pc" doesn't. […]
Sorry, you're right. Forgot the details about how this works.