On 8/27/19 4:48 AM, Bin Meng wrote:
Hi Heinrich,
On Tue, Aug 27, 2019 at 10:43 AM Heinrich Schuchardt <[email protected]> wrote:
On 8/27/19 3:18 AM, Bin Meng wrote:
Hi Heinrich,
On Tue, Aug 27, 2019 at 1:26 AM Heinrich Schuchardt <[email protected]> wrote:
On 8/26/19 8:13 AM, Bin Meng wrote:
Hi Heinrich,
On Mon, Aug 26, 2019 at 1:55 AM Heinrich Schuchardt <[email protected]> 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 <[email protected]>
---
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
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
