| Message ID | 20190825175512.13911-1-xypron.glpk@gmx.de |
|---|---|
| State | Accepted |
| Commit | 74b76357dfd75550cd9a511e71990d414a4d023e |
| Delegated to: | Bin Meng |
| Headers | show |
| Series | [U-Boot,1/1] x86: show UEFI images involved in crash | expand |
Hi Heinrich, On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@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.glpk@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? > } Regards, Bin
On 8/26/19 8:13 AM, Bin Meng wrote: > Hi Heinrich, > > On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@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.glpk@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 Heinrich > >> } > > Regards, > Bin >
Hi Heinrich, On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <xypron.glpk@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.glpk@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.glpk@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? Regards, Bin
On 8/27/19 3:18 AM, Bin Meng wrote: > Hi Heinrich, > > On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <xypron.glpk@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.glpk@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.glpk@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. Best regards Heinrich
Hi Heinrich, On Tue, Aug 27, 2019 at 10:43 AM Heinrich Schuchardt <xypron.glpk@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.glpk@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.glpk@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.glpk@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
On 8/27/19 4:48 AM, Bin Meng wrote: > Hi Heinrich, > > On Tue, Aug 27, 2019 at 10:43 AM Heinrich Schuchardt <xypron.glpk@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.glpk@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.glpk@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.glpk@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. You can elicit the output with => setenv efi_selftest exception => bootefi selftest Best regards Heinrich
On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@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.glpk@gmx.de> > --- > arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
On Thu, Aug 29, 2019 at 12:46 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <xypron.glpk@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.glpk@gmx.de> > > --- > > arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> > Tested-by: Bin Meng <bmeng.cn@gmail.com> applied to u-boot-x86, thanks!
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); } static void do_exception(struct irq_regs *regs)
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.glpk@gmx.de> --- arch/x86/cpu/i386/interrupt.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) -- 2.20.1