[U-Boot] Fwd: Crash in U-Boot
Hello Alex,
on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least since U-Boot v2019.01. See below.
In the code for SetVirtualAddressMap I saw the that the pointer to the list of configuration tables is adjusted:
if ((map_start <= (uintptr_t)systab.tables) && (map_end >= (uintptr_t)systab.tables)) { char *ptr = (char *)systab.tables; ptr += off; systab.tables = (struct efi_configuration_table *)ptr; }
Shouldn't the pointers to the individual configuration tables be adjusted too? I found no such code.
Best regards
Heinrich
-------- Forwarded Message -------- Subject: Re: Crash in U-Boot reported by you in IRC Date: Sun, 23 Jun 2019 14:44:07 +0200 From: Heinrich Schuchardt xypron.glpk@gmx.de To: vagrant@debian.org
Hello Vagrant,
I checked if I could reproduce you problem on a Wandboard. But it did not show the error you reported. Instead I got a Kernel oops.
I used a Kernel with
CONFIG_DEBUG_LL=y CONFIG_DEBUG_IMX6Q_UART=y CONFIG_DEBUG_IMX_UART_PORT=1 CONFIG_EARLY_PRINTK=y
added and earlyprintk on the command line.
Loading Linux 4.19.34-armmp ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.19.34-armmp (zfsdt@family) (gcc version 8.3.0 (Debian 8.3.0-5)) #1 SMP Sat Apr 13 13:34:54 CES9 [ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Wandboard i.MX6 Quad Board rev B1 [ 0.000000] OF: fdt: Ignoring memory range 0x10000000 - 0x41000000 [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: EFI v2.70 by Das U-Boot [ 0.000000] efi: SMBIOS=0x8dd81000 [ 0.000000] OF: fdt: Ignoring memory block 0x10000000 - 0x12000000 [ 0.000000] OF: fdt: Ignoring memory block 0x12000000 - 0x1240a000 [ 0.000000] OF: fdt: Ignoring memory block 0x1240a000 - 0x17d00000 [ 0.000000] OF: fdt: Ignoring memory block 0x17d00000 - 0x17f00000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f00000 - 0x17f0c000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f0c000 - 0x2e1f2000 [ 0.000000] OF: fdt: Ignoring memory block 0x2e1f2000 - 0x2ffff000 [ 0.000000] OF: fdt: Ignoring memory range 0x2ffff000 - 0x41000000 [ 0.000000] INITRD: 0x2e1f2000+0x01e0d000 is not a memory region - disabling initrd [ 0.000000] cma: Reserved 16 MiB at 0x8e000000 [ 0.000000] BUG: not creating mapping for 0x41000000 at 0x99000000 in user region [ 0.000000] Unable to handle kernel paging request at virtual address 6fd00000 [ 0.000000] pgd = (ptrval) [ 0.000000] [6fd00000] *pgd=00000000 [ 0.000000] Internal error: Oops: 5 [#1] SMP ARM [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.34-armmp #1 [ 0.000000] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 0.000000] PC is at fdt_check_header+0xc/0x80 [ 0.000000] LR is at __unflatten_device_tree+0x4c/0x274 [ 0.000000] pc : [<c0ae7ee8>] lr : [<c0967e34>] psr: 200000d3 [ 0.000000] sp : c1201ec0 ip : c1201ed0 fp : c1201ecc [ 0.000000] r10: c1316280 r9 : 00000000 r8 : c135e1f8 [ 0.000000] r7 : 00000000 r6 : 6fd00000 r5 : c1074ac0 r4 : c1074ac0 [ 0.000000] r3 : c1074ac0 r2 : c135e1f8 r1 : 00000000 r0 : 6fd00000 [ 0.000000] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none [ 0.000000] Control: 10c5387d Table: 6820404a DAC: 00000051 [ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval)) [ 0.000000] Stack: (0xc1201ec0 to 0xc1202000) [ 0.000000] 1ec0: c1201efc c1201ed0 c0967e34 c0ae7ee8 c1074ac0 c1074ac0 c1209900 8fffffff [ 0.000000] 1ee0: 8f797000 c1349768 e7fffcc0 c1316280 c1201f1c c1201f00 c1075de4 c0967df4 [ 0.000000] 1f00: 00000000 c1201f10 c0358188 c1082ddc c1201fa4 c1201f20 c1004a34 c1075dac [ 0.000000] 1f20: ffffffff 10c5387d c03bc990 c03bc47c c0d61538 c0d630cc c1205dcc c1201fbc [ 0.000000] 1f40: c0e330c8 fffff000 c1201fa4 c1201f58 c10220c8 c0af6cf0 c1205dcc c1205dcc [ 0.000000] 1f60: c1205dcc ffffffff c1201f94 c1201f78 c03bcd08 00000000 c1201f9c 00000000 [ 0.000000] 1f80: c1205dcc c1205dcc ffffffff c1205dc0 412fc09a 10c5387d c1201ff4 c1201fa8 [ 0.000000] 1fa0: c1000c2c c10040f4 00000000 00000000 00000000 00000000 00000000 c1091e40 [ 0.000000] 1fc0: 00000000 00000000 00000000 c1000330 00000051 10c0387d ffffffff 17d00000 [ 0.000000] 1fe0: 412fc09a 10c5387d 00000000 c1201ff8 00000000 c1000bbc 00000000 00000000 [ 0.000000] [<c0ae7ee8>] (fdt_check_header) from [<c0967e34>] (__unflatten_device_tree+0x4c/0x274) [ 0.000000] [<c0967e34>] (__unflatten_device_tree) from [<c1075de4>] (unflatten_device_tree+0x44/0x54) [ 0.000000] [<c1075de4>] (unflatten_device_tree) from [<c1004a34>] (setup_arch+0x94c/0xd88) [ 0.000000] [<c1004a34>] (setup_arch) from [<c1000c2c>] (start_kernel+0x7c/0x504) [ 0.000000] [<c1000c2c>] (start_kernel) from [<00000000>] ( (null)) [ 0.000000] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903000) [ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x5c with crng_init=0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
Hello Alex,
on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least since U-Boot v2019.01. See below.
In the code for SetVirtualAddressMap I saw the that the pointer to the list of configuration tables is adjusted:
if ((map_start <= (uintptr_t)systab.tables) && (map_end >= (uintptr_t)systab.tables)) { char *ptr = (char *)systab.tables; ptr += off; systab.tables = (struct efi_configuration_table *)ptr; }Shouldn't the pointers to the individual configuration tables be adjusted too? I found no such code.
We have to adapt the systable, because RT code may use it. However, I thought tables are not guaranteed to be around after SVAM? Ard?
I tend to agree that in that case, adjusting the table pointer does not sound very useful either. Can we legally just set the table count to 0 there?
If however they are indeed legal to access via virtual addresses afterwards, I do agree that we should patch the individual table pointers too, yes.
Alex
Best regards
Heinrich
-------- Forwarded Message -------- Subject: Re: Crash in U-Boot reported by you in IRC Date: Sun, 23 Jun 2019 14:44:07 +0200 From: Heinrich Schuchardt xypron.glpk@gmx.de To: vagrant@debian.org
Hello Vagrant,
I checked if I could reproduce you problem on a Wandboard. But it did not show the error you reported. Instead I got a Kernel oops.
I used a Kernel with
CONFIG_DEBUG_LL=y CONFIG_DEBUG_IMX6Q_UART=y CONFIG_DEBUG_IMX_UART_PORT=1 CONFIG_EARLY_PRINTK=y
added and earlyprintk on the command line.
Loading Linux 4.19.34-armmp ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.19.34-armmp (zfsdt@family) (gcc version 8.3.0 (Debian 8.3.0-5)) #1 SMP Sat Apr 13 13:34:54 CES9 [ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Wandboard i.MX6 Quad Board rev B1 [ 0.000000] OF: fdt: Ignoring memory range 0x10000000 - 0x41000000 [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: EFI v2.70 by Das U-Boot [ 0.000000] efi: SMBIOS=0x8dd81000 [ 0.000000] OF: fdt: Ignoring memory block 0x10000000 - 0x12000000 [ 0.000000] OF: fdt: Ignoring memory block 0x12000000 - 0x1240a000 [ 0.000000] OF: fdt: Ignoring memory block 0x1240a000 - 0x17d00000 [ 0.000000] OF: fdt: Ignoring memory block 0x17d00000 - 0x17f00000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f00000 - 0x17f0c000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f0c000 - 0x2e1f2000 [ 0.000000] OF: fdt: Ignoring memory block 0x2e1f2000 - 0x2ffff000 [ 0.000000] OF: fdt: Ignoring memory range 0x2ffff000 - 0x41000000 [ 0.000000] INITRD: 0x2e1f2000+0x01e0d000 is not a memory region - disabling initrd [ 0.000000] cma: Reserved 16 MiB at 0x8e000000 [ 0.000000] BUG: not creating mapping for 0x41000000 at 0x99000000 in user region [ 0.000000] Unable to handle kernel paging request at virtual address 6fd00000 [ 0.000000] pgd = (ptrval) [ 0.000000] [6fd00000] *pgd=00000000 [ 0.000000] Internal error: Oops: 5 [#1] SMP ARM [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.34-armmp #1 [ 0.000000] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 0.000000] PC is at fdt_check_header+0xc/0x80 [ 0.000000] LR is at __unflatten_device_tree+0x4c/0x274 [ 0.000000] pc : [<c0ae7ee8>] lr : [<c0967e34>] psr: 200000d3 [ 0.000000] sp : c1201ec0 ip : c1201ed0 fp : c1201ecc [ 0.000000] r10: c1316280 r9 : 00000000 r8 : c135e1f8 [ 0.000000] r7 : 00000000 r6 : 6fd00000 r5 : c1074ac0 r4 : c1074ac0 [ 0.000000] r3 : c1074ac0 r2 : c135e1f8 r1 : 00000000 r0 : 6fd00000 [ 0.000000] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none [ 0.000000] Control: 10c5387d Table: 6820404a DAC: 00000051 [ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval)) [ 0.000000] Stack: (0xc1201ec0 to 0xc1202000) [ 0.000000] 1ec0: c1201efc c1201ed0 c0967e34 c0ae7ee8 c1074ac0 c1074ac0 c1209900 8fffffff [ 0.000000] 1ee0: 8f797000 c1349768 e7fffcc0 c1316280 c1201f1c c1201f00 c1075de4 c0967df4 [ 0.000000] 1f00: 00000000 c1201f10 c0358188 c1082ddc c1201fa4 c1201f20 c1004a34 c1075dac [ 0.000000] 1f20: ffffffff 10c5387d c03bc990 c03bc47c c0d61538 c0d630cc c1205dcc c1201fbc [ 0.000000] 1f40: c0e330c8 fffff000 c1201fa4 c1201f58 c10220c8 c0af6cf0 c1205dcc c1205dcc [ 0.000000] 1f60: c1205dcc ffffffff c1201f94 c1201f78 c03bcd08 00000000 c1201f9c 00000000 [ 0.000000] 1f80: c1205dcc c1205dcc ffffffff c1205dc0 412fc09a 10c5387d c1201ff4 c1201fa8 [ 0.000000] 1fa0: c1000c2c c10040f4 00000000 00000000 00000000 00000000 00000000 c1091e40 [ 0.000000] 1fc0: 00000000 00000000 00000000 c1000330 00000051 10c0387d ffffffff 17d00000 [ 0.000000] 1fe0: 412fc09a 10c5387d 00000000 c1201ff8 00000000 c1000bbc 00000000 00000000 [ 0.000000] [<c0ae7ee8>] (fdt_check_header) from [<c0967e34>] (__unflatten_device_tree+0x4c/0x274) [ 0.000000] [<c0967e34>] (__unflatten_device_tree) from [<c1075de4>] (unflatten_device_tree+0x44/0x54) [ 0.000000] [<c1075de4>] (unflatten_device_tree) from [<c1004a34>] (setup_arch+0x94c/0xd88) [ 0.000000] [<c1004a34>] (setup_arch) from [<c1000c2c>] (start_kernel+0x7c/0x504) [ 0.000000] [<c1000c2c>] (start_kernel) from [<00000000>] ( (null)) [ 0.000000] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903000) [ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x5c with crng_init=0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
On Sun, 23 Jun 2019 at 23:47, Alexander Graf agraf@csgraf.de wrote:
Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
Hello Alex,
on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least since U-Boot v2019.01. See below.
In the code for SetVirtualAddressMap I saw the that the pointer to the list of configuration tables is adjusted:
if ((map_start <= (uintptr_t)systab.tables) && (map_end >= (uintptr_t)systab.tables)) { char *ptr = (char *)systab.tables; ptr += off; systab.tables = (struct efi_configuration_table *)ptr; }Shouldn't the pointers to the individual configuration tables be adjusted too? I found no such code.
We have to adapt the systable, because RT code may use it. However, I thought tables are not guaranteed to be around after SVAM? Ard?
Only the system table pointers are updated for virtual remapping. I'm not entirely sure why, but this permits the runtime firmware components themselves to access the array. However, runtime firmware typically has no way to translate a physical address into a virtual address, so if they need to access such tables, they have to grab the address *before* SVAM(), which means it doesn't matter whether the config table array point is translated as well.
I tend to agree that in that case, adjusting the table pointer does not sound very useful either. Can we legally just set the table count to 0 there?
No. The OS expects to be able to locate config tables, and the OS itself does not care about runtime remapping.
If however they are indeed legal to access via virtual addresses afterwards, I do agree that we should patch the individual table pointers too, yes.
Please don't do the sane thing. Where's the fun in that? :-)
Am 24.06.2019 um 00:01 schrieb Ard Biesheuvel ard.biesheuvel@linaro.org:
On Sun, 23 Jun 2019 at 23:47, Alexander Graf agraf@csgraf.de wrote:
Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
Hello Alex,
on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least since U-Boot v2019.01. See below.
In the code for SetVirtualAddressMap I saw the that the pointer to the list of configuration tables is adjusted:
if ((map_start <= (uintptr_t)systab.tables) && (map_end >= (uintptr_t)systab.tables)) { char *ptr = (char *)systab.tables; ptr += off; systab.tables = (struct efi_configuration_table *)ptr; }Shouldn't the pointers to the individual configuration tables be adjusted too? I found no such code.
We have to adapt the systable, because RT code may use it. However, I thought tables are not guaranteed to be around after SVAM? Ard?
Only the system table pointers are updated for virtual remapping. I'm not entirely sure why, but this permits the runtime firmware components themselves to access the array. However, runtime firmware typically has no way to translate a physical address into a virtual address, so if they need to access such tables, they have to grab the address *before* SVAM(), which means it doesn't matter whether the config table array point is translated as well.
I tend to agree that in that case, adjusting the table pointer does not sound very useful either. Can we legally just set the table count to 0 there?
No. The OS expects to be able to locate config tables, and the OS itself does not care about runtime remapping.
If however they are indeed legal to access via virtual addresses afterwards, I do agree that we should patch the individual table pointers too, yes.
Please don't do the sane thing. Where's the fun in that? :-)
I keep forgetting that we talk UEFI here ;). So the status quo is correct? Or do we have to drop the relocation part for the table array pointer?
Alex
On 6/24/19 7:56 AM, Alexander Graf wrote:
Am 24.06.2019 um 00:01 schrieb Ard Biesheuvel ard.biesheuvel@linaro.org:
On Sun, 23 Jun 2019 at 23:47, Alexander Graf agraf@csgraf.de wrote:
Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
Hello Alex,
on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least since U-Boot v2019.01. See below.
In the code for SetVirtualAddressMap I saw the that the pointer to the list of configuration tables is adjusted:
if ((map_start <= (uintptr_t)systab.tables) && (map_end >= (uintptr_t)systab.tables)) { char *ptr = (char *)systab.tables; ptr += off; systab.tables = (struct efi_configuration_table *)ptr; }Shouldn't the pointers to the individual configuration tables be adjusted too? I found no such code.
We have to adapt the systable, because RT code may use it. However, I thought tables are not guaranteed to be around after SVAM? Ard?
Only the system table pointers are updated for virtual remapping. I'm not entirely sure why, but this permits the runtime firmware components themselves to access the array. However, runtime firmware typically has no way to translate a physical address into a virtual address, so if they need to access such tables, they have to grab the address *before* SVAM(), which means it doesn't matter whether the config table array point is translated as well.
I tend to agree that in that case, adjusting the table pointer does not sound very useful either. Can we legally just set the table count to 0 there?
No. The OS expects to be able to locate config tables, and the OS itself does not care about runtime remapping.
If however they are indeed legal to access via virtual addresses afterwards, I do agree that we should patch the individual table pointers too, yes.
Please don't do the sane thing. Where's the fun in that? :-)
I keep forgetting that we talk UEFI here ;). So the status quo is correct? Or do we have to drop the relocation part for the table array pointer?
EDK2 is doing it just like U-Boot. Change the pointer to the array. Do not change the array.
Regards
Heinrich
On 6/23/19 11:47 PM, Alexander Graf wrote:
Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt xypron.glpk@gmx.de:
Hello Alex,
on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least since U-Boot v2019.01. See below.
In the code for SetVirtualAddressMap I saw the that the pointer to the list of configuration tables is adjusted:
if ((map_start <= (uintptr_t)systab.tables) && (map_end >= (uintptr_t)systab.tables)) { char *ptr = (char *)systab.tables; ptr += off; systab.tables = (struct efi_configuration_table *)ptr; }Shouldn't the pointers to the individual configuration tables be adjusted too? I found no such code.
We have to adapt the systable, because RT code may use it. However, I thought tables are not guaranteed to be around after SVAM? Ard?
I tend to agree that in that case, adjusting the table pointer does not sound very useful either. Can we legally just set the table count to 0 there?
If however they are indeed legal to access via virtual addresses afterwards, I do agree that we should patch the individual table pointers too, yes.
The UEFI 2.8 has this sentence:
"All the addresses reported in these table entries will be referenced as physical and will not be fixed up when transition from preboot to runtime phase."
It is unclear to me if this refers to the addresses inside the individual tables or the addresses pointing to the tables.
But it is evident that tables must survive into runtime.
Regards
Heinrich
Alex
participants (3)
-
Alexander Graf -
Ard Biesheuvel -
Heinrich Schuchardt