On 28.03.18 14:15, Heinrich Schuchardt wrote: > I have an EFI payload which causes a data abort exception on arm32: > > data abort > pc : [<79e7afe6>] lr : [<79e7aff5>] > > > reloc pc : [<44f15fe6>] lr : [<44f15ff5>] > > > sp : 7af3a740 ip : 7efb0420 fp : 7af774f8 > > > r10: 7af3a7f0 r9 : 7af44ed8 r8 : 7ef9b1d0 > > > r7 : 00000000 r6 : 00000000 r5 : 7ef8af21 r4 : 7af774f8 > > > r3 : 00000003 r2 : 79f2f040 r1 : 00000000 r0 : 79f2f079 > > > Flags: Nzcv IRQs off FIQs off Mode SVC_32 > > > Resetting CPU ... > > > > resetting ... > > "reloc pc" is calculated as > instruction_pointer(regs) - gd->reloc_off > > This relocation offset is the one used for U-Boot not the one used for > the EFI payload. > > When a data abort occurs we may have multiple loaded EFI images. For the > analysis we need the offset, the start address, and the end address for > each of these. Then we can determine to which image the PC points to and > via the offset find the assembly instruction in the image file. > > Printing this information when an image is started may destroy the > screen content. Furthermore the screen may be cleared afterwards. > > So the most appropriate time for printing the information would be when > the abort occurs. If the memory is not corrupted we could loop over all > loaded image handles and retrieve the information from there. We could > call an efi function for this purpose right after show_regs(pt_regs) in > arch/arm/lib/interrupts.c. > > What is your view on this?
I think it's a great idea. Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot