[U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB
Hello Leif,
the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. GRUB loads the initial ramdisk into an area which the the mainline 4.19.55 kernel simply does not accept because it thinks the minimum address is 0x68000000 and not 0x10000000. Booting via bootz works without problem.
Did you see a similar problems before?
This is the memory map when it is last read from U-Boot.
typ, phys, virt, pages, attrib 00000002, 8f797000, 8f797000, 869, 8 00000005, 8f796000, 8f796000, 1, 8000000000000008 00000002, 8dd8c000, 8dd8c000, 1a0a, 8 00000000, 8dd8b000, 8dd8b000, 1, 8 00000006, 8dd8a000, 8dd8a000, 1, 8000000000000008 00000000, 8dd83000, 8dd83000, 7, 8 00000006, 8dd82000, 8dd82000, 1, 8000000000000008 00000000, 8dd7e000, 8dd7e000, 4, 8 00000001, 8dd67000, 8dd67000, 17, 8 00000004, 8dd66000, 8dd66000, 1, 8 00000000, 8dd64000, 8dd64000, 2, 8 00000002, 8dd63000, 8dd63000, 1, 8 00000006, 8dd62000, 8dd62000, 1, 8000000000000008 00000002, 8dd61000, 8dd61000, 1, 8 00000001, 6e60c000, 6e60c000, 1f755, 8 00000002, 6e1f8000, 6e1f8000, 414, 8 00000001, 6dded000, 6dded000, 40b, 8 00000002, 6ddec000, 6ddec000, 1, 8 00000004, 6ddeb000, 6ddeb000, 1, 8 00000002, 6dde9000, 6dde9000, 2, 8 00000007, 2ffff000, 2ffff000, 3ddea, 8 00000002, 2e1f1000, 2e1f1000, 1e0e, 8 00000007, 17f0c000, 17f0c000, 162e5, 8 00000004, 17f00000, 17f00000, c, 8 00000002, 17d00000, 17d00000, 200, 8 00000007, 1240b000, 1240b000, 58f5, 8 00000002, 12000000, 12000000, 40b, 8 00000004, 10000000, 10000000, 2000, 8
The initial ramdisk is loaded at 2e1f1000.
The problem occurs in drivers/of/fdt.c where some memory areas including the one containig the initial ramdisk are excluded. I have added some extra debug lines to early_init_dt_add_memory_arch().
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.19.55-armmp (zfsdt@family) (gcc version 8.3.0 (Debian 8.3.0-6)) #8 SMP Sat Jun 29 17:04:52 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: base 10000000 < phys_offset 68000000 [ 0.000000] OF: fdt: Ignoring memory range 0x10000000 - 0x68000000 [ 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.80 by Das U-Boot [ 0.000000] efi: SMBIOS=0x8dd82000 [ 0.000000] OF: fdt: base 0000000010000000 + size 0000000002000000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x10000000 - 0x12000000 [ 0.000000] OF: fdt: base 0000000012000000 + size 000000000040b000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x12000000 - 0x1240b000 [ 0.000000] OF: fdt: base 000000001240b000 + size 00000000058f5000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x1240b000 - 0x17d00000 [ 0.000000] OF: fdt: base 0000000017d00000 + size 0000000000200000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17d00000 - 0x17f00000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 0000000017f00000 + size 000000000000c000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f00000 - 0x17f0c000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 0000000017f0c000 + size 00000000162e5000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f0c000 - 0x2e1f1000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 000000002e1f1000 + size 0000000001e0e000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x2e1f1000 - 0x2ffff000 [ 0.000000] INITRD: 0x2e1f1000+0x01e0e000 is not a memory region - disabling initrd [ 0.000000] cma: Reserved 16 MiB at 0x8e000000 [ 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.55-armmp #8 [ 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 : [<c0ae9d48>] lr : [<c09696dc>] psr: 200000d3 [ 0.000000] sp : c1201ec0 ip : c1201ed0 fp : c1201ecc [ 0.000000] r10: c1316340 r9 : 00000000 r8 : c135e308 [ 0.000000] r7 : 00000000 r6 : 6fd00000 r5 : c1074be8 r4 : c1074be8 [ 0.000000] r3 : c1074be8 r2 : c135e308 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 c09696dc c0ae9d48 c1074be8 c1074be8 c1209900 8fffffff [ 0.000000] 1ee0: 8f980000 c1349880 e7fffc80 c1316340 c1201f1c c1201f00 c1076000 c096969c [ 0.000000] 1f00: 00000000 c1201f10 c0358230 c1083028 c1201fa4 c1201f20 c1004a38 c1075fc8 [ 0.000000] 1f20: ffffffff 10c5387d c03bcd50 c03bc83c c0d61908 c0d6349c c1205dcc c1201fbc [ 0.000000] 1f40: c0e340c8 fffff000 c1201fa4 c1201f58 c1022158 c0af8b54 c1205dcc c1205dcc [ 0.000000] 1f60: c1205dcc ffffffff c1201f94 c1201f78 c03bd0c8 00000000 c1201f9c 00000000 [ 0.000000] 1f80: c1205dcc c1205dcc ffffffff c1205dc0 412fc09a 10c5387d c1201ff4 c
Best regards
Heinrich
Hi Heinrich,
On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote:
Hello Leif,
the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. GRUB loads the initial ramdisk into an area which the the mainline 4.19.55 kernel simply does not accept because it thinks the minimum address is 0x68000000 and not 0x10000000. Booting via bootz works without problem.
Did you see a similar problems before?
Hmm... It's been about 5 years since I looked at this code in Linux last, so I may need to start with some stupid questions.
This is the memory map when it is last read from U-Boot.
typ, phys, virt, pages, attrib 00000002, 8f797000, 8f797000, 869, 8 00000005, 8f796000, 8f796000, 1, 8000000000000008 00000002, 8dd8c000, 8dd8c000, 1a0a, 8 00000000, 8dd8b000, 8dd8b000, 1, 8 00000006, 8dd8a000, 8dd8a000, 1, 8000000000000008 00000000, 8dd83000, 8dd83000, 7, 8 00000006, 8dd82000, 8dd82000, 1, 8000000000000008 00000000, 8dd7e000, 8dd7e000, 4, 8 00000001, 8dd67000, 8dd67000, 17, 8 00000004, 8dd66000, 8dd66000, 1, 8 00000000, 8dd64000, 8dd64000, 2, 8 00000002, 8dd63000, 8dd63000, 1, 8 00000006, 8dd62000, 8dd62000, 1, 8000000000000008 00000002, 8dd61000, 8dd61000, 1, 8 00000001, 6e60c000, 6e60c000, 1f755, 8 00000002, 6e1f8000, 6e1f8000, 414, 8 00000001, 6dded000, 6dded000, 40b, 8 00000002, 6ddec000, 6ddec000, 1, 8 00000004, 6ddeb000, 6ddeb000, 1, 8 00000002, 6dde9000, 6dde9000, 2, 8 00000007, 2ffff000, 2ffff000, 3ddea, 8 00000002, 2e1f1000, 2e1f1000, 1e0e, 8
According to this, we have an allocation of somewhat below 8MB, I assume this matches the size of the initrd?
00000007, 17f0c000, 17f0c000, 162e5, 8 00000004, 17f00000, 17f00000, c, 8 00000002, 17d00000, 17d00000, 200, 8 00000007, 1240b000, 1240b000, 58f5, 8 00000002, 12000000, 12000000, 40b, 8 00000004, 10000000, 10000000, 2000, 8
The initial ramdisk is loaded at 2e1f1000.
The problem occurs in drivers/of/fdt.c where some memory areas including the one containig the initial ramdisk are excluded. I have added some extra debug lines to early_init_dt_add_memory_arch().
Do you have a pointer to the device tree sources? If the DT is explicitly excluding regions not marked such in the UEFI memory map ... that would cause problems.
Best Regards,
Leif
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.19.55-armmp (zfsdt@family) (gcc version 8.3.0 (Debian 8.3.0-6)) #8 SMP Sat Jun 29 17:04:52 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: base 10000000 < phys_offset 68000000 [ 0.000000] OF: fdt: Ignoring memory range 0x10000000 - 0x68000000 [ 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.80 by Das U-Boot [ 0.000000] efi: SMBIOS=0x8dd82000 [ 0.000000] OF: fdt: base 0000000010000000 + size 0000000002000000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x10000000 - 0x12000000 [ 0.000000] OF: fdt: base 0000000012000000 + size 000000000040b000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x12000000 - 0x1240b000 [ 0.000000] OF: fdt: base 000000001240b000 + size 00000000058f5000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x1240b000 - 0x17d00000 [ 0.000000] OF: fdt: base 0000000017d00000 + size 0000000000200000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17d00000 - 0x17f00000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 0000000017f00000 + size 000000000000c000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f00000 - 0x17f0c000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 0000000017f0c000 + size 00000000162e5000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f0c000 - 0x2e1f1000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 000000002e1f1000 + size 0000000001e0e000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x2e1f1000 - 0x2ffff000 [ 0.000000] INITRD: 0x2e1f1000+0x01e0e000 is not a memory region - disabling initrd [ 0.000000] cma: Reserved 16 MiB at 0x8e000000 [ 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.55-armmp #8 [ 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 : [<c0ae9d48>] lr : [<c09696dc>] psr: 200000d3 [ 0.000000] sp : c1201ec0 ip : c1201ed0 fp : c1201ecc [ 0.000000] r10: c1316340 r9 : 00000000 r8 : c135e308 [ 0.000000] r7 : 00000000 r6 : 6fd00000 r5 : c1074be8 r4 : c1074be8 [ 0.000000] r3 : c1074be8 r2 : c135e308 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 c09696dc c0ae9d48 c1074be8 c1074be8 c1209900 8fffffff [ 0.000000] 1ee0: 8f980000 c1349880 e7fffc80 c1316340 c1201f1c c1201f00 c1076000 c096969c [ 0.000000] 1f00: 00000000 c1201f10 c0358230 c1083028 c1201fa4 c1201f20 c1004a38 c1075fc8 [ 0.000000] 1f20: ffffffff 10c5387d c03bcd50 c03bc83c c0d61908 c0d6349c c1205dcc c1201fbc [ 0.000000] 1f40: c0e340c8 fffff000 c1201fa4 c1201f58 c1022158 c0af8b54 c1205dcc c1205dcc [ 0.000000] 1f60: c1205dcc ffffffff c1201f94 c1201f78 c03bd0c8 00000000 c1201f9c 00000000 [ 0.000000] 1f80: c1205dcc c1205dcc ffffffff c1205dc0 412fc09a 10c5387d c1201ff4 c
Best regards
Heinrich
On 7/1/19 4:02 PM, Leif Lindholm wrote:
Hi Heinrich,
On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote:
Hello Leif,
the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. GRUB loads the initial ramdisk into an area which the the mainline 4.19.55 kernel simply does not accept because it thinks the minimum address is 0x68000000 and not 0x10000000. Booting via bootz works without problem.
Did you see a similar problems before?
Hmm... It's been about 5 years since I looked at this code in Linux last, so I may need to start with some stupid questions.
This is the memory map when it is last read from U-Boot.
typ, phys, virt, pages, attrib 00000002, 8f797000, 8f797000, 869, 8 00000005, 8f796000, 8f796000, 1, 8000000000000008 00000002, 8dd8c000, 8dd8c000, 1a0a, 8 00000000, 8dd8b000, 8dd8b000, 1, 8 00000006, 8dd8a000, 8dd8a000, 1, 8000000000000008 00000000, 8dd83000, 8dd83000, 7, 8 00000006, 8dd82000, 8dd82000, 1, 8000000000000008 00000000, 8dd7e000, 8dd7e000, 4, 8 00000001, 8dd67000, 8dd67000, 17, 8 00000004, 8dd66000, 8dd66000, 1, 8 00000000, 8dd64000, 8dd64000, 2, 8 00000002, 8dd63000, 8dd63000, 1, 8 00000006, 8dd62000, 8dd62000, 1, 8000000000000008 00000002, 8dd61000, 8dd61000, 1, 8 00000001, 6e60c000, 6e60c000, 1f755, 8 00000002, 6e1f8000, 6e1f8000, 414, 8 00000001, 6dded000, 6dded000, 40b, 8 00000002, 6ddec000, 6ddec000, 1, 8 00000004, 6ddeb000, 6ddeb000, 1, 8 00000002, 6dde9000, 6dde9000, 2, 8 00000007, 2ffff000, 2ffff000, 3ddea, 8 00000002, 2e1f1000, 2e1f1000, 1e0e, 8
According to this, we have an allocation of somewhat below 8MB, I assume this matches the size of the initrd?
Thanks a lot for taking a look at this.
31516827 bytes actually. 74715648 bytes after unzipping.
00000007, 17f0c000, 17f0c000, 162e5, 8 00000004, 17f00000, 17f00000, c, 8 00000002, 17d00000, 17d00000, 200, 8 00000007, 1240b000, 1240b000, 58f5, 8 00000002, 12000000, 12000000, 40b, 8 00000004, 10000000, 10000000, 2000, 8
The initial ramdisk is loaded at 2e1f1000.
The problem occurs in drivers/of/fdt.c where some memory areas including the one containig the initial ramdisk are excluded. I have added some extra debug lines to early_init_dt_add_memory_arch().
Do you have a pointer to the device tree sources? If the DT is explicitly excluding regions not marked such in the UEFI memory map ... that would cause problems.
Please, find appended the device tree passed to U-Boot (dtb) and the printout of the devicetree upon entering SetVirtualAddressMap.
Regards
Heinrich
Best Regards,
Leif
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.19.55-armmp (zfsdt@family) (gcc version 8.3.0 (Debian 8.3.0-6)) #8 SMP Sat Jun 29 17:04:52 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: base 10000000 < phys_offset 68000000 [ 0.000000] OF: fdt: Ignoring memory range 0x10000000 - 0x68000000 [ 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.80 by Das U-Boot [ 0.000000] efi: SMBIOS=0x8dd82000 [ 0.000000] OF: fdt: base 0000000010000000 + size 0000000002000000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x10000000 - 0x12000000 [ 0.000000] OF: fdt: base 0000000012000000 + size 000000000040b000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x12000000 - 0x1240b000 [ 0.000000] OF: fdt: base 000000001240b000 + size 00000000058f5000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x1240b000 - 0x17d00000 [ 0.000000] OF: fdt: base 0000000017d00000 + size 0000000000200000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17d00000 - 0x17f00000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 0000000017f00000 + size 000000000000c000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f00000 - 0x17f0c000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 0000000017f0c000 + size 00000000162e5000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x17f0c000 - 0x2e1f1000 [ 0.000000] OF: fdt: phys_offset 0000000068000000 [ 0.000000] OF: fdt: base 000000002e1f1000 + size 0000000001e0e000 < phys_offset 0000000068000000 [ 0.000000] OF: fdt: Ignoring memory block 0x2e1f1000 - 0x2ffff000 [ 0.000000] INITRD: 0x2e1f1000+0x01e0e000 is not a memory region - disabling initrd [ 0.000000] cma: Reserved 16 MiB at 0x8e000000 [ 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.55-armmp #8 [ 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 : [<c0ae9d48>] lr : [<c09696dc>] psr: 200000d3 [ 0.000000] sp : c1201ec0 ip : c1201ed0 fp : c1201ecc [ 0.000000] r10: c1316340 r9 : 00000000 r8 : c135e308 [ 0.000000] r7 : 00000000 r6 : 6fd00000 r5 : c1074be8 r4 : c1074be8 [ 0.000000] r3 : c1074be8 r2 : c135e308 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 c09696dc c0ae9d48 c1074be8 c1074be8 c1209900 8fffffff [ 0.000000] 1ee0: 8f980000 c1349880 e7fffc80 c1316340 c1201f1c c1201f00 c1076000 c096969c [ 0.000000] 1f00: 00000000 c1201f10 c0358230 c1083028 c1201fa4 c1201f20 c1004a38 c1075fc8 [ 0.000000] 1f20: ffffffff 10c5387d c03bcd50 c03bc83c c0d61908 c0d6349c c1205dcc c1201fbc [ 0.000000] 1f40: c0e340c8 fffff000 c1201fa4 c1201f58 c1022158 c0af8b54 c1205dcc c1205dcc [ 0.000000] 1f60: c1205dcc ffffffff c1201f94 c1201f78 c03bd0c8 00000000 c1201f9c 00000000 [ 0.000000] 1f80: c1205dcc c1205dcc ffffffff c1205dc0 412fc09a 10c5387d c1201ff4 c
Best regards
Heinrich
Hi,
On Mon, Jul 01, 2019 at 07:19:10PM +0200, Heinrich Schuchardt wrote:
According to this, we have an allocation of somewhat below 8MB, I assume this matches the size of the initrd?
Thanks a lot for taking a look at this.
31516827 bytes actually. 74715648 bytes after unzipping.
Yeah, so probably grub unzips it.
00000007, 17f0c000, 17f0c000, 162e5, 8 00000004, 17f00000, 17f00000, c, 8 00000002, 17d00000, 17d00000, 200, 8 00000007, 1240b000, 1240b000, 58f5, 8 00000002, 12000000, 12000000, 40b, 8 00000004, 10000000, 10000000, 2000, 8
The initial ramdisk is loaded at 2e1f1000.
The problem occurs in drivers/of/fdt.c where some memory areas including the one containig the initial ramdisk are excluded. I have added some extra debug lines to early_init_dt_add_memory_arch().
Do you have a pointer to the device tree sources? If the DT is explicitly excluding regions not marked such in the UEFI memory map ... that would cause problems.
Please, find appended the device tree passed to U-Boot (dtb) and the printout of the devicetree upon entering SetVirtualAddressMap.
Thank you.
Hmm. Well, my main concern is that we *should* be ignoring whatever is in the DT when booting through UEFI (see Linux commit 500899c2cc3e3).
Could you try deleting the "memory" and "memory@10000000" nodes from the DT and see if that changes behaviour? (You probably want to delete one of them regardless, since they describe the same region :)
If that doesn't change anything, how far back would we be able to bisect and still be able to boot on this platform?
Is this a distro kernel? Is the behaviour the same on upstream?
Regards,
Leif
On 7/1/19 9:56 PM, Leif Lindholm wrote:
Hi,
On Mon, Jul 01, 2019 at 07:19:10PM +0200, Heinrich Schuchardt wrote:
According to this, we have an allocation of somewhat below 8MB, I assume this matches the size of the initrd?
Thanks a lot for taking a look at this.
31516827 bytes actually. 74715648 bytes after unzipping.
Yeah, so probably grub unzips it.
00000007, 17f0c000, 17f0c000, 162e5, 8 00000004, 17f00000, 17f00000, c, 8 00000002, 17d00000, 17d00000, 200, 8 00000007, 1240b000, 1240b000, 58f5, 8 00000002, 12000000, 12000000, 40b, 8 00000004, 10000000, 10000000, 2000, 8
The initial ramdisk is loaded at 2e1f1000.
The problem occurs in drivers/of/fdt.c where some memory areas including the one containig the initial ramdisk are excluded. I have added some extra debug lines to early_init_dt_add_memory_arch().
Do you have a pointer to the device tree sources? If the DT is explicitly excluding regions not marked such in the UEFI memory map ... that would cause problems.
Please, find appended the device tree passed to U-Boot (dtb) and the printout of the devicetree upon entering SetVirtualAddressMap.
Thank you.
Hmm. Well, my main concern is that we *should* be ignoring whatever is in the DT when booting through UEFI (see Linux commit 500899c2cc3e3).
Could you try deleting the "memory" and "memory@10000000" nodes from the DT and see if that changes behaviour? (You probably want to delete one of them regardless, since they describe the same region :)
setenv bootargs console=$console earlyprintk load mmc 2:2 $fdt_addr_r dtb fdt addr $fdt_addr_r fdt rm /memory fdt rm /memory@10000000 load mmc 2:1 $kernel_addr_r EFI/debian/grubarm.efi bootefi $kernel_addr_r $fdt_addr_r
leads to the same result.
If that doesn't change anything, how far back would we be able to bisect and still be able to boot on this platform?
I do not know if it ever worked for this board. U-Boot v2019.01 fails too.
I have not seen the problem on 32bit Amlogic (OrangePi PC).
Is this a distro kernel? Is the behaviour the same on upstream?
I have used 4.19.55 upstream together with the Debian config file but with earlyprintk enabled.
Best regards
Heinrich
Regards,
Leif
On Mon, Jul 01, 2019 at 10:22:46PM +0200, Heinrich Schuchardt wrote:
Hmm. Well, my main concern is that we *should* be ignoring whatever is in the DT when booting through UEFI (see Linux commit 500899c2cc3e3).
Could you try deleting the "memory" and "memory@10000000" nodes from the DT and see if that changes behaviour? (You probably want to delete one of them regardless, since they describe the same region :)
setenv bootargs console=$console earlyprintk load mmc 2:2 $fdt_addr_r dtb fdt addr $fdt_addr_r fdt rm /memory fdt rm /memory@10000000 load mmc 2:1 $kernel_addr_r EFI/debian/grubarm.efi bootefi $kernel_addr_r $fdt_addr_r
leads to the same result.
Well, it was a bit optimistic hoping it would work...
If that doesn't change anything, how far back would we be able to bisect and still be able to boot on this platform?
I do not know if it ever worked for this board. U-Boot v2019.01 fails too.
I was basically wondering if 500899c2cc3e3 would be likely to work on this board in any environment?
I have not seen the problem on 32bit Amlogic (OrangePi PC).
Is this a distro kernel? Is the behaviour the same on upstream?
I have used 4.19.55 upstream together with the Debian config file but with earlyprintk enabled.
Ah, that makes sense.
Best Regards,
Leif
Hello Heinrich,
On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote:
Hello Leif,
the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. GRUB loads the initial ramdisk into an area which the the mainline 4.19.55 kernel simply does not accept because it thinks the minimum address is 0x68000000 and not 0x10000000. Booting via bootz works without problem.
Did you see a similar problems before?
Rereading your original report, I realise that the OF error messages comletely distracted me from what you say in the text above: The kernel thinks the minimum address is 0x68000000 (suggesting that is the address the zImage decompresses the runtime kernel to?).
Presumably when booting with 'bootz', the minimum address is correctly determined to be 0x10000000?
Where the 32-bit ARM kernel locates itself is unfortunately a bit of a Rube Goldberg machine: 1) Grub/U-Boot loads the zImage *somewhere* 2) zImage decompresses itself to *somewhere*else* and jumps to the decompressed copy.
When booting with UEFI, *upstream* arm/arm64 GRUB loads the kernel image with grub_efi_allocate_any_pages() and then calls LoadImage/StartImage. (This step goes in between 1 and 2 above.) Some of the distros carry addional patches for "shim" support that modify this behaviour.
After LoadImage is called, the EFI stub of the kernel image determines where the runtime kernel is going to be decompressed to (and I think relocates zImage if necessary), and reserves this area, before actually jumping to the zImage: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver...
This always felt somewhat precarious to me.
Could you possibly: - add 'set debug=linux' in your grub.cfg and paste the logs - add some printouts to arm32-stub.c ?
Also, what is the uncompressed size of your kernel image?
Best Regards,
Leif
On 7/2/19 6:55 PM, Leif Lindholm wrote:
Hello Heinrich,
On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote:
Hello Leif,
the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. GRUB loads the initial ramdisk into an area which the the mainline 4.19.55 kernel simply does not accept because it thinks the minimum address is 0x68000000 and not 0x10000000. Booting via bootz works without problem.
Did you see a similar problems before?
Rereading your original report, I realise that the OF error messages comletely distracted me from what you say in the text above: The kernel thinks the minimum address is 0x68000000 (suggesting that is the address the zImage decompresses the runtime kernel to?).
Presumably when booting with 'bootz', the minimum address is correctly determined to be 0x10000000?
Where the 32-bit ARM kernel locates itself is unfortunately a bit of a Rube Goldberg machine:
- Grub/U-Boot loads the zImage *somewhere*
- zImage decompresses itself to *somewhere*else* and jumps to the decompressed copy.
When booting with UEFI, *upstream* arm/arm64 GRUB loads the kernel image with grub_efi_allocate_any_pages() and then calls LoadImage/StartImage. (This step goes in between 1 and 2 above.) Some of the distros carry addional patches for "shim" support that modify this behaviour.
After LoadImage is called, the EFI stub of the kernel image determines where the runtime kernel is going to be decompressed to (and I think relocates zImage if necessary), and reserves this area, before actually jumping to the zImage: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver...
This always felt somewhat precarious to me.
Could you possibly:
- add 'set debug=linux' in your grub.cfg and paste the logs
- add some printouts to arm32-stub.c
Is kernel v4.19.55 fine or should I use 5.2-rc7?
Regards
Heinrich
?
Also, what is the uncompressed size of your kernel image?
Best Regards,
Leif
On Tue, Jul 02, 2019 at 07:12:11PM +0200, Heinrich Schuchardt wrote:
After LoadImage is called, the EFI stub of the kernel image determines where the runtime kernel is going to be decompressed to (and I think relocates zImage if necessary), and reserves this area, before actually jumping to the zImage: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver...
This always felt somewhat precarious to me.
Could you possibly:
- add 'set debug=linux' in your grub.cfg and paste the logs
- add some printouts to arm32-stub.c
Is kernel v4.19.55 fine or should I use 5.2-rc7?
Well, you're seeing the issue on 4.19.55, so I think we should investigate that. The only value I would see would be a sanity check if the behaviour still exists with 5.2-rc7 (and if it doesn't use that as help to determine what's going on).
I would be surprised if the behaviour has changed.
Regards,
Leif
On 7/2/19 6:55 PM, Leif Lindholm wrote:
Hello Heinrich,
On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote:
Hello Leif,
the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. GRUB loads the initial ramdisk into an area which the the mainline 4.19.55 kernel simply does not accept because it thinks the minimum address is 0x68000000 and not 0x10000000. Booting via bootz works without problem.
Did you see a similar problems before?
Rereading your original report, I realise that the OF error messages comletely distracted me from what you say in the text above: The kernel thinks the minimum address is 0x68000000 (suggesting that is the address the zImage decompresses the runtime kernel to?).
Presumably when booting with 'bootz', the minimum address is correctly determined to be 0x10000000?
Where the 32-bit ARM kernel locates itself is unfortunately a bit of a Rube Goldberg machine:
- Grub/U-Boot loads the zImage *somewhere*
- zImage decompresses itself to *somewhere*else* and jumps to the decompressed copy.
When booting with UEFI, *upstream* arm/arm64 GRUB loads the kernel image with grub_efi_allocate_any_pages() and then calls LoadImage/StartImage. (This step goes in between 1 and 2 above.) Some of the distros carry addional patches for "shim" support that modify this behaviour.
After LoadImage is called, the EFI stub of the kernel image determines where the runtime kernel is going to be decompressed to (and I think relocates zImage if necessary), and reserves this area, before actually jumping to the zImage: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver...
This always felt somewhat precarious to me.
Could you possibly:
- add 'set debug=linux' in your grub.cfg and paste the logs
- add some printouts to arm32-stub.c
?
That debug output is ever so strange. Why would loader/arm64/linux.c be invoked on a 32bit system?
This is the output on my Wandboard that fails to boot (I do not see much of a difference to the output for the OrangePi PC below):
Loading Linux 4.19.55-armmp ... loader/arm64/linux.c:60: UEFI stub kernel: loader/arm64/linux.c:61: PE/COFF header @ 00004550 loader/arm64/linux.c:313: kernel file size: 4231680 loader/arm64/linux.c:316: kernel numpages: 1034 loader/arm64/linux.c:332: kernel @ 0x6e202000 Loading initial ramdisk ... loader/arm64/linux.c:257: Loading initrd loader/arm64/linux.c:274: [addr=0x2e1f0000, size=0x1e0e89b] kern/efi/fdt.c:38: found registered FDT @ 0x17f00000 loader/efi/fdt.c:62: allocating 37888 bytes for fdt loader/arm64/linux.c:89: Initrd @ 0x2e1f0000-0x2fffe89b loader/arm64/linux.c:143: linux command line: 'BOOT_IMAGE=/vmlinuz-4.19.55-armmp root=UUID=14868a8b-ade1-432a-896f-eb16f9a36bfd ro earlyprintk' loader/arm64/linux.c:158: starting image 0x8edb9d80 EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map...
This is the output on an OrangePi PC also with Debian Buster which boots successfully:
Loading Linux 4.19.0-5-armmp-lpae ... loader/arm64/linux.c:60: UEFI stub kernel: loader/arm64/linux.c:61: PE/COFF header @ 00004550 loader/arm64/linux.c:313: kernel file size: 4370944 loader/arm64/linux.c:316: kernel numpages: 1068 loader/arm64/linux.c:332: kernel @ 0x6a72b000 Loading initial ramdisk ... loader/arm64/linux.c:257: Loading initrd loader/arm64/linux.c:274: [addr=0x5ec96000, size=0x1368074] kern/efi/fdt.c:38: found registered FDT @ 0x47f00000 loader/efi/fdt.c:62: allocating 21504 bytes for fdt loader/arm64/linux.c:89: Initrd @ 0x5ec96000-0x5fffe074 loader/arm64/linux.c:143: linux command line: 'BOOT_IMAGE=/vmlinuz-4.19.0-5-armmp-lpae root=UUID=61ca5c77-c7f1-4d01-9260-983fa9a7477a ro' loader/arm64/linux.c:158: starting image 0x79fbf840 EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... EHCI failed to shut down host controller.
Best regards
Heinrich
Also, what is the uncompressed size of your kernel image?
Best Regards,
Leif
On Tue, Jul 02, 2019 at 07:35:31PM +0200, Heinrich Schuchardt wrote:
This always felt somewhat precarious to me.
Could you possibly:
- add 'set debug=linux' in your grub.cfg and paste the logs
- add some printouts to arm32-stub.c
?
That debug output is ever so strange. Why would loader/arm64/linux.c be invoked on a 32bit system?
Yes, this is a bit counterintuitive (and my fault). Effectively, the arm64 loader is now effectively a generic UEFI linux loader for DT platforms. Once the 2.04 release is out, I intend to drop the last mentions of ARM*, shuffle it out to loader/efi, and enable it also for Risc-V.
This is the output on my Wandboard that fails to boot (I do not see much of a difference to the output for the OrangePi PC below):
Loading Linux 4.19.55-armmp ... loader/arm64/linux.c:60: UEFI stub kernel: loader/arm64/linux.c:61: PE/COFF header @ 00004550 loader/arm64/linux.c:313: kernel file size: 4231680 loader/arm64/linux.c:316: kernel numpages: 1034 loader/arm64/linux.c:332: kernel @ 0x6e202000
Hmm...
I will investigate this off-list with Heinrich, since it's far from certain the problem is with U-Boot.
/ Leif
participants (2)
-
Heinrich Schuchardt -
Leif Lindholm