Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel wrote: > > Hello Chester, > > On Fri, 2 Aug 2019 at 08:40, Chester Lin wrote: > > > > In some cases the arm32 efistub could fail to allocate memory for > > uncompressed kernel. For example, we got the following error message when > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] : > > > > EFI stub: Booting Linux Kernel... > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. > > EFI stub: ERROR: Failed to relocate kernel > > > > After checking the EFI memory map we found that the first page [0 - 0xfff] > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to > > set the dram base at 0, which was actually in a reserved region. > > > > This by itself is a violation of the Linux boot protocol for 32-bit > ARM when using the decompressor. The decompressor rounds down its own > base address to a multiple of 128 MB, and assumes the whole area is > available for the decompressed kernel and related data structures. > (The first TEXT_OFFSET bytes are no longer used in practice, which is > why putting a reserved region of 4 KB bytes works at the moment, but > this is fragile). Note that the decompressor does not look at any DT > or EFI provided memory maps *at all*. > > So unfortunately, this is not something we can fix in the kernel, but > we should fix it in the bootloader or in GRUB, so it does not put any > reserved regions in the first 128 MB of memory, > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The ARM boot protocol docs are unclear about whether this memory should be used or not, but it is no longer used for its original purpose (page tables), and the RPi loader already keeps data there. Can you check whether the following patch works for you? diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index 0460c7581220..ee0661ddb25b 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o random.o \ lib-$(CONFIG_ARM) += arm32-stub.o lib-$(CONFIG_ARM64)+= arm64-stub.o +CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) # diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c index e8f7aefb6813..66ff0c8ec269 100644 --- a/drivers/firmware/efi/libstub/arm32-stub.c +++ b/drivers/firmware/efi/libstub/arm32-stub.c @@ -204,7 +204,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table, * loaded. These assumptions are made by the decompressor, * before any memory map is available. */ - dram_base = round_up(dram_base, SZ_128M); + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET; status = reserve_kernel_base(sys_table, dram_base, reserve_addr, reserve_size); > > > grub> lsefimmap > > Type Physical start - end #PagesSize Attributes > > reserved -0fff 0001 4KiB WB > > conv-mem 1000-07ef5fff 7ef5 130004KiB WB > > RT-data 07ef6000-07f09fff 0014 80KiB RT WB > > conv-mem 07f0a000-2d871fff 00025968 615840KiB WB > > . > > > > To avoid a reserved address, we have to ignore the memory regions which are > > marked as EFI_RESERVED_TYPE, and only conventional memory regions can be > > chosen. If the region before the kernel base is unaligned, it will be > > marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit > > will not be sticked with a very low address such as 0x1000. > > This is a separate issue, so it should be handled in a separate patch. > > Signed-off-by: Chester Lin > > --- > > arch/arm/mm/mmu.c | 3 ++ > > drivers/firmware/efi/libstub/arm32-stub.c | 43 ++- > > 2 files changed, 37 insertions(+), 9 deletions(-) > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c > > index f3ce34113f89..909b11ba48d8 100644 > > --- a/arch/arm/mm/mmu.c > > +++ b/arch/arm/mm/mmu.c > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void) > > phys_addr_t block_start = reg->base; > > phys_addr_t block_end = reg->base + reg->size; > > > > + if (memblock_is_nomap(reg)) > > + continue; > > + > > if (reg->base < vmalloc_limit) { > > if (block_end > lowmem_limit) > > /* > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c > > b/drivers/firmware/efi/libstub/arm32-stub.c > > index e8f7aefb6813..10d33d36df00 100644 > > --- a/drivers/firmware/efi/libstub/arm32-stub.c > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c > > @@ -128,7 +128,7 @@ static efi_
arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
Hi, I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm64 macchiatobin board and I get the following error when loading the kernel (using grub-efi on top of edk ii): EFI stub: Booting Linux Kernel... EFI stub: ERROR: efi_get_random_bytes() failed EFI stub: ERROR: Failed to relocate kernel The kernel boots fine with that option disabled, but strangely presents the same error when disabling only CONFIG_RANDOMIZE_BASE. Let me know if I can provide more info or do some tests. Thanks
Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote: > Hi, > > I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm64 > macchiatobin board and I get the following error when loading the > kernel (using grub-efi on top of edk ii): > > EFI stub: Booting Linux Kernel... > EFI stub: ERROR: efi_get_random_bytes() failed > EFI stub: ERROR: Failed to relocate kernel > > The kernel boots fine with that option disabled, but strangely > presents the same error when disabling only CONFIG_RANDOMIZE_BASE. That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE) guard around the efi_get_random_bytes() call, so something sounds wrong. Are you certain that you're running the same kernel Image that you rebuilt? Ard, do you reckon it would be worth adding the UTS_RELEASE and UTS_VERSION to the " Booting Linux Kernel..." string? It would make debugging that potential issue easier. > Let me know if I can provide more info or do some tests. Maybe there's a problem with stale objects. If you're not doing so already, could you try a clean build with CONFIG_RANDOMIZE_BASE deselected? Thanks, Mark.
Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
On Thu, 15 Aug 2019 at 14:03, Mark Rutland wrote: > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote: > > Hi, > > > > I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm64 > > macchiatobin board and I get the following error when loading the > > kernel (using grub-efi on top of edk ii): > > > > EFI stub: Booting Linux Kernel... > > EFI stub: ERROR: efi_get_random_bytes() failed > > EFI stub: ERROR: Failed to relocate kernel > > > > The kernel boots fine with that option disabled, but strangely > > presents the same error when disabling only CONFIG_RANDOMIZE_BASE. > > That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE) > guard around the efi_get_random_bytes() call, so something sounds wrong. > > Are you certain that you're running the same kernel Image that you > rebuilt? > > Ard, do you reckon it would be worth adding the UTS_RELEASE and > UTS_VERSION to the " Booting Linux Kernel..." string? It would make > debugging that potential issue easier. > Use of the UTS_xxx macros already triggers an annoying number of object rebuilds every time you change anything entirely unrelated in your kernel sources, so I'd prefer to avoid this tbh. > > Let me know if I can provide more info or do some tests. > > Maybe there's a problem with stale objects. If you're not doing so > already, could you try a clean build with CONFIG_RANDOMIZE_BASE > deselected? > Also, can you try booting with the nokaslr command line option added?
Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
On Thu, Aug 15, 2019 at 02:21:26PM +0300, Ard Biesheuvel wrote: > On Thu, 15 Aug 2019 at 14:03, Mark Rutland wrote: > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote: > > > Hi, > > > > > > I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm64 > > > macchiatobin board and I get the following error when loading the > > > kernel (using grub-efi on top of edk ii): > > > > > > EFI stub: Booting Linux Kernel... > > > EFI stub: ERROR: efi_get_random_bytes() failed > > > EFI stub: ERROR: Failed to relocate kernel > > > > > > The kernel boots fine with that option disabled, but strangely > > > presents the same error when disabling only CONFIG_RANDOMIZE_BASE. > > > > That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE) > > guard around the efi_get_random_bytes() call, so something sounds wrong. > > > > Are you certain that you're running the same kernel Image that you > > rebuilt? > > > > Ard, do you reckon it would be worth adding the UTS_RELEASE and > > UTS_VERSION to the " Booting Linux Kernel..." string? It would make > > debugging that potential issue easier. > > Use of the UTS_xxx macros already triggers an annoying number of > object rebuilds every time you change anything entirely unrelated in > your kernel sources, so I'd prefer to avoid this tbh. Fair enough; saves me writing a patch! :) Mark.
Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
(adding Mike) On Thu, 15 Aug 2019 at 14:28, Chester Lin wrote: > > Hi Ard, > > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote: > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel > > wrote: > > > > > > Hello Chester, > > > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin wrote: > > > > > > > > In some cases the arm32 efistub could fail to allocate memory for > > > > uncompressed kernel. For example, we got the following error message > > > > when > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] : > > > > > > > > EFI stub: Booting Linux Kernel... > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. > > > > EFI stub: ERROR: Failed to relocate kernel > > > > > > > > After checking the EFI memory map we found that the first page [0 - > > > > 0xfff] > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to > > > > set the dram base at 0, which was actually in a reserved region. > > > > > > > > > > This by itself is a violation of the Linux boot protocol for 32-bit > > > ARM when using the decompressor. The decompressor rounds down its own > > > base address to a multiple of 128 MB, and assumes the whole area is > > > available for the decompressed kernel and related data structures. > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is > > > why putting a reserved region of 4 KB bytes works at the moment, but > > > this is fragile). Note that the decompressor does not look at any DT > > > or EFI provided memory maps *at all*. > > > > > > So unfortunately, this is not something we can fix in the kernel, but > > > we should fix it in the bootloader or in GRUB, so it does not put any > > > reserved regions in the first 128 MB of memory, > > > > > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The > > ARM boot protocol docs are unclear about whether this memory should be > > used or not, but it is no longer used for its original purpose (page > > tables), and the RPi loader already keeps data there. > > > > Can you check whether the following patch works for you? > > > > diff --git a/drivers/firmware/efi/libstub/Makefile > > b/drivers/firmware/efi/libstub/Makefile > > index 0460c7581220..ee0661ddb25b 100644 > > --- a/drivers/firmware/efi/libstub/Makefile > > +++ b/drivers/firmware/efi/libstub/Makefile > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o > > string.o random.o \ > > > > lib-$(CONFIG_ARM) += arm32-stub.o > > lib-$(CONFIG_ARM64)+= arm64-stub.o > > +CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) > > CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) > > > > # > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c > > b/drivers/firmware/efi/libstub/arm32-stub.c > > index e8f7aefb6813..66ff0c8ec269 100644 > > --- a/drivers/firmware/efi/libstub/arm32-stub.c > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c > > @@ -204,7 +204,7 @@ efi_status_t > > handle_kernel_image(efi_system_table_t *sys_table, > > * loaded. These assumptions are made by the decompressor, > > * before any memory map is available. > > */ > > - dram_base = round_up(dram_base, SZ_128M); > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET; > > > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr, > > reserve_size); > > > > I tried your patch on rpi2 and got the following panic. Just a reminder that I > have replaced some log messages with ".." since it might be too long to > post all. > OK. Good to know that this change helps you to get past the EFI stub boot issue. > In this case the kernel failed to reserve cma, which should hit the issue of > memblock_limit=0x1000 as I had mentioned in my patch description. The first > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align > with PMD_SIZE so the cma reservation failed because the memblock.current_limit > was extremely low. That's why I expand the first reservation from 1 PAGESIZE > to > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know > if any suggestion, thank you. > This looks like it is a separate issue. The memblock/cma code should not choke on a reserved page of memory at 0x0. Perhaps Russell or Mike (cc'ed) have an idea how to address this? > boot-log: > > > Loading Linux test ... > EFI stub: Booting Linux Kernel... > EFI stub: Using DTB from configuration table > EFI stub: Exiting boot services and installing virtual address map... > Uncompressing Linux... done, booting the kernel. > [0.00] Booting Linux on physical CPU 0xf00 > [0.00] Linux version 5.2.1-lpae (chester@linux-8mug) (..) > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d > [0.00] CPU: div instructions available: patching division code > [0.00] CPU: PIPT / VIPT non
Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
Hi Ard, On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote: > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel wrote: > > > > Hello Chester, > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin wrote: > > > > > > In some cases the arm32 efistub could fail to allocate memory for > > > uncompressed kernel. For example, we got the following error message when > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] : > > > > > > EFI stub: Booting Linux Kernel... > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. > > > EFI stub: ERROR: Failed to relocate kernel > > > > > > After checking the EFI memory map we found that the first page [0 - 0xfff] > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to > > > set the dram base at 0, which was actually in a reserved region. > > > > > > > This by itself is a violation of the Linux boot protocol for 32-bit > > ARM when using the decompressor. The decompressor rounds down its own > > base address to a multiple of 128 MB, and assumes the whole area is > > available for the decompressed kernel and related data structures. > > (The first TEXT_OFFSET bytes are no longer used in practice, which is > > why putting a reserved region of 4 KB bytes works at the moment, but > > this is fragile). Note that the decompressor does not look at any DT > > or EFI provided memory maps *at all*. > > > > So unfortunately, this is not something we can fix in the kernel, but > > we should fix it in the bootloader or in GRUB, so it does not put any > > reserved regions in the first 128 MB of memory, > > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The > ARM boot protocol docs are unclear about whether this memory should be > used or not, but it is no longer used for its original purpose (page > tables), and the RPi loader already keeps data there. > > Can you check whether the following patch works for you? > > diff --git a/drivers/firmware/efi/libstub/Makefile > b/drivers/firmware/efi/libstub/Makefile > index 0460c7581220..ee0661ddb25b 100644 > --- a/drivers/firmware/efi/libstub/Makefile > +++ b/drivers/firmware/efi/libstub/Makefile > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o > string.o random.o \ > > lib-$(CONFIG_ARM) += arm32-stub.o > lib-$(CONFIG_ARM64)+= arm64-stub.o > +CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) > CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) > > # > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c > b/drivers/firmware/efi/libstub/arm32-stub.c > index e8f7aefb6813..66ff0c8ec269 100644 > --- a/drivers/firmware/efi/libstub/arm32-stub.c > +++ b/drivers/firmware/efi/libstub/arm32-stub.c > @@ -204,7 +204,7 @@ efi_status_t > handle_kernel_image(efi_system_table_t *sys_table, > * loaded. These assumptions are made by the decompressor, > * before any memory map is available. > */ > - dram_base = round_up(dram_base, SZ_128M); > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET; > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr, > reserve_size); > I tried your patch on rpi2 and got the following panic. Just a reminder that I have replaced some log messages with ".." since it might be too long to post all. In this case the kernel failed to reserve cma, which should hit the issue of memblock_limit=0x1000 as I had mentioned in my patch description. The first block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align with PMD_SIZE so the cma reservation failed because the memblock.current_limit was extremely low. That's why I expand the first reservation from 1 PAGESIZE to 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know if any suggestion, thank you. boot-log: Loading Linux test ... EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0xf00 [0.00] Linux version 5.2.1-lpae (chester@linux-8mug) (..) [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Raspberry Pi 2 Model B Rev 1.1 [0.00] printk: bootconsole [earlycon0] enabled [0.00] Memory policy: Data cache writealloc [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: System Table: 0x3df757c0 [0.00] efi: MemMap Address: 0x2c1c5040 [0.00] efi: MemMap Size: 0x03c0 [0.00] efi: MemMap Desc. Size: 0x0028 [0.00] efi: MemMap Desc. Version: 0x0001
Re: arm64/efistub boot error with CONFIG_GCC_PLUGIN_STACKLEAK
On Thu, Aug 15, 2019 at 7:21 AM Ard Biesheuvel wrote: > On Thu, 15 Aug 2019 at 14:03, Mark Rutland wrote: > > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote: > > > The kernel boots fine with that option disabled, but strangely > > > presents the same error when disabling only CONFIG_RANDOMIZE_BASE. > > > > That shouldn't be possible, given the IS_ENABLED(CONFIG_RANDOMIZE_BASE) > > guard around the efi_get_random_bytes() call, so something sounds wrong. > > > > Maybe there's a problem with stale objects. If you're not doing so > > already, could you try a clean build with CONFIG_RANDOMIZE_BASE > > deselected? > > > Also, can you try booting with the nokaslr command line option added? You were right, I haven't tried with nokaslr, but it worked fine by rebuilding the kernel after a distclean with CONFIG_RANDOMIZE_BASE disabled and CONFIG_GCC_PLUGIN_STACKLEAK enabled. That's what I was expecting the first time and this is the reason why I mentioned it. I've been recompiling too many times, sorry about that. Anyhow, the main issue is the efi_get_random_bytes() fail with CONFIG_GCC_PLUGIN_STACKLEAK enabled, and that's still valid. Thanks
Re: [PATCH] efi/arm: fix allocation failure when reserving the kernel base
On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote: > (adding Mike) > > On Thu, 15 Aug 2019 at 14:28, Chester Lin wrote: > > > > Hi Ard, > > > > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote: > > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel > > > wrote: > > > > > > > > Hello Chester, > > > > > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin wrote: > > > > > > > > > > In some cases the arm32 efistub could fail to allocate memory for > > > > > uncompressed kernel. For example, we got the following error message > > > > > when > > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] : > > > > > > > > > > EFI stub: Booting Linux Kernel... > > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. > > > > > EFI stub: ERROR: Failed to relocate kernel > > > > > > > > > > After checking the EFI memory map we found that the first page [0 - > > > > > 0xfff] > > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried > > > > > to > > > > > set the dram base at 0, which was actually in a reserved region. > > > > > > > > > > > > > This by itself is a violation of the Linux boot protocol for 32-bit > > > > ARM when using the decompressor. The decompressor rounds down its own > > > > base address to a multiple of 128 MB, and assumes the whole area is > > > > available for the decompressed kernel and related data structures. > > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is > > > > why putting a reserved region of 4 KB bytes works at the moment, but > > > > this is fragile). Note that the decompressor does not look at any DT > > > > or EFI provided memory maps *at all*. > > > > > > > > So unfortunately, this is not something we can fix in the kernel, but > > > > we should fix it in the bootloader or in GRUB, so it does not put any > > > > reserved regions in the first 128 MB of memory, > > > > > > > > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The > > > ARM boot protocol docs are unclear about whether this memory should be > > > used or not, but it is no longer used for its original purpose (page > > > tables), and the RPi loader already keeps data there. > > > > > > Can you check whether the following patch works for you? > > > > > > diff --git a/drivers/firmware/efi/libstub/Makefile > > > b/drivers/firmware/efi/libstub/Makefile > > > index 0460c7581220..ee0661ddb25b 100644 > > > --- a/drivers/firmware/efi/libstub/Makefile > > > +++ b/drivers/firmware/efi/libstub/Makefile > > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o > > > string.o random.o \ > > > > > > lib-$(CONFIG_ARM) += arm32-stub.o > > > lib-$(CONFIG_ARM64)+= arm64-stub.o > > > +CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) > > > CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET) > > > > > > # > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c > > > b/drivers/firmware/efi/libstub/arm32-stub.c > > > index e8f7aefb6813..66ff0c8ec269 100644 > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c > > > @@ -204,7 +204,7 @@ efi_status_t > > > handle_kernel_image(efi_system_table_t *sys_table, > > > * loaded. These assumptions are made by the decompressor, > > > * before any memory map is available. > > > */ > > > - dram_base = round_up(dram_base, SZ_128M); > > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET; > > > > > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr, > > > reserve_size); > > > > > > > I tried your patch on rpi2 and got the following panic. Just a reminder > > that I > > have replaced some log messages with ".." since it might be too long to > > post all. > > > > OK. Good to know that this change helps you to get past the EFI stub boot > issue. > > > In this case the kernel failed to reserve cma, which should hit the issue of > > memblock_limit=0x1000 as I had mentioned in my patch description. The first > > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align > > with PMD_SIZE so the cma reservation failed because the > > memblock.current_limit > > was extremely low. That's why I expand the first reservation from 1 > > PAGESIZE to > > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me > > know > > if any suggestion, thank you. > This looks like it is a separate issue. The memblock/cma code should > not choke on a reserved page of memory at 0x0. > > Perhaps Russell or Mike (cc'ed) have an idea how to address this? Presuming that the last memblock dump comes from the end of arm_memblock_init() with the this memory map memory[0x0] [0x-0x0fff], 0x1000 bytes flags: 0x4 memory[0x1] [0x1000-0x07ef5fff], 0x07ef5000 bytes flag
Early EFI-related boot freeze in parse_setup_data()
Hi, We're working with a new consumer MiniPC based on AMD E1-7010. It fails to boot Linux when booting in EFI mode - it hangs with nothing on screen. earlycon=efifb doesn't show any output. Looking closer, I was able to confirm that we reach EFI ExitBootServices() via efi_printk in the efi stub. But you can't use EFI's console functionality after that point, so I then resorted to inserting calls to: idt_invalidate(NULL); __asm__ __volatile__("int3"); throughout the early boot code that follows in order to force a system reset. That way I could deduce if execution was reaching that point (system reset) or not (system hang as before). As a side-question I'd be curious if there is any better way to debug such early boot failures on consumer x86 hardware without a serial port... Anyway, the system freeze occurs in parse_setup_data(), specifically: data = early_memremap(pa_data, sizeof(*data)); data_len = data->len + sizeof(struct setup_data); Dereferencing data->len causes the system to hang. I presume it triggers an exception handler due to some kind of invalid memory access. By returning early in that function, boot continues basically fine. So I could then log the details: pa_data has value 0x892bb018 and early_memremap returns address 0xff200018. Accessing just a single byte at that address causes the system hang. This original pa_data value (from boot_params.hdr.setup_data) was set by the EFI stub in setup_efi_pci(). I confirmed that the same 0x892bb018 value is set there, it is not being corrupted along the way. Any suggestions for how to diagnose further? dmesg output: https://gist.github.com/dsd/199bed7b590e90efdf73f9f6384ca551 Thanks Daniel