Hi Heinrich,
On Tue, Aug 27, 2019 at 10:43 AM Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
> On 8/27/19 3:18 AM, Bin Meng wrote:
> > Hi Heinrich,
> >
> > On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <xypron.g...@gmx.de>
> > wrote:
> >>
> >> On 8/26/19 8:13 AM, Bin Meng wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.g...@gmx.de>
> >>> wrote:
> >>>>
> >>>> If a crash occurs, show the loaded UEFI images to facilitate analysis.
> >>>>
> >>>> This is an example output:
> >>>>
> >>>> => bootefi 0x1000000
> >>>> Found 0 disks
> >>>> Hello world of bugs!
> >>>> Invalid Opcode (Undefined Opcode)
> >>>> EIP: 0010:[<06ceb06e>] EFLAGS: 00010206
> >>>> Original EIP :[<fec9906e>]
> >>>> EAX: 00000000 EBX: 06cec000 ECX: 00000fd0 EDX: 00000001
> >>>> ESI: 06ced18a EDI: 07d0fe10 EBP: 07fe27a0 ESP: 07d0fde0
> >>>> DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> >>>> CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000000
> >>>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> >>>> DR6: ffff0ff0 DR7: 00000400
> >>>> Stack:
> >>>> 0x07d0fde8 : 0x00000000
> >>>> 0x07d0fde4 : 0x06ced040
> >>>> --->0x07d0fde0 : 0x07fe27a0
> >>>> 0x07d0fddc : 0x00010206
> >>>> 0x07d0fdd8 : 0x00000010
> >>>> 0x07d0fdd4 : 0x06ceb06e
> >>>> UEFI image [0x06cea000:0x06cf0fff] pc=0x106e '/bug-i386.efi'
> >>>> ### ERROR ### Please RESET the board ###
> >>>>
> >>>> With the additional information provided by this patch we know that the
> >>>> problem occurred 0x106e after the load address of bug-i386.efi.
> >>>>
> >>>> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> >>>> ---
> >>>> arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++
> >>>> 1 file changed, 14 insertions(+)
> >>>>
> >>>> diff --git a/arch/x86/cpu/i386/interrupt.c
> >>>> b/arch/x86/cpu/i386/interrupt.c
> >>>> index 47df3172b7..1445204878 100644
> >>>> --- a/arch/x86/cpu/i386/interrupt.c
> >>>> +++ b/arch/x86/cpu/i386/interrupt.c
> >>>> @@ -12,6 +12,7 @@
> >>>>
> >>>> #include <common.h>
> >>>> #include <dm.h>
> >>>> +#include <efi_loader.h>
> >>>> #include <asm/control_regs.h>
> >>>> #include <asm/i8259.h>
> >>>> #include <asm/interrupt.h>
> >>>> @@ -64,6 +65,18 @@ static char *exceptions[] = {
> >>>> "Reserved"
> >>>> };
> >>>>
> >>>> +/**
> >>>> + * show_efi_loaded_images() - show loaded UEFI images
> >>>> + *
> >>>> + * List all loaded UEFI images.
> >>>> + *
> >>>> + * @eip: instruction pointer
> >>>> + */
> >>>> +static void show_efi_loaded_images(uintptr_t eip)
> >>>> +{
> >>>> + efi_print_image_infos((void *)eip);
> >>>> +}
> >>>> +
> >>>> static void dump_regs(struct irq_regs *regs)
> >>>> {
> >>>> unsigned long cs, eip, eflags;
> >>>> @@ -144,6 +157,7 @@ static void dump_regs(struct irq_regs *regs)
> >>>> printf("0x%8.8lx : 0x%8.8lx\n", sp, (ulong)readl(sp));
> >>>> sp -= 4;
> >>>> }
> >>>> + show_efi_loaded_images(eip);
> >>>
> >>> Should we wrap the call with #ifdef CONFIG_EFI_LOADER or something?
> >>
> >> In include/efi_loader.h we have
> >>
> >> static inline void efi_print_image_infos(void *pc) { }
> >>
> >> if EFI_LOADER is not defined.
> >>
> >> Best regards
> >>
> >
> > I feel a little bit strange of show_efi_loaded_images() being called
> > in the dump_regs(). The dump_regs() is called in the exception
> > handler. It's a bit odd we show the EFI image info in the exception
> > handler. Shouldn't we print the EFI image info from the command line
> > interface?
>
> We have a command to display loaded images from the command line
> (efidebug images). But when a crash occurs in an UEFI application, I
> cannot reach the command line anymore.
>
> When running complex UEFI applications like the SCT multiple UEFI images
> are involved with loading addresses which I cannot control from the
> command line. So it is hard to find out where a crash occurred.
>
> For ARM we already have the same information in crash dumps.
>
> If not UEFI image is loaded, no line is added to the crash dump.
OK, could you please provide a sample EFI image of such to trigger the
issue? I would like to have a test.
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
