From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] bootefi failures on armv7
Date: Wed, 10 Apr 2019 19:57:04 +0300 [thread overview]
Message-ID: <20190410165704.GA10242@apalos> (raw)
Hi Alexander, Heinrich,
(Resending since i was too quick on the trigger forgot to cc the public
mailing list. Sorry for the mess)
I can't get an armv7 board (STM32MP157C-DK2) to boot with bootefi on
specific kernel/uboot configurations.
u-boot version: U-Boot 2019.04-rc3
kernel version: 5.0.0-rc3
What works:
- bootefi + 'dtb=' on kernel cmdline regardless of kernel config
- bootefi + fdtcontroladdr if CONFIG_ARM_LPAE=y on my kernel config
What doesn't work:
bootefi + fdtcontroladdr if CONFIG_ARM_LPAE is not set.
Once this config is selected the kernel hangs on a BUG_ON() in arm_pte_alloc()
Adding a dump_stack() there throws the relevant information.
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc3-29427-g769f1f8f9b56-dirty #127
[ 0.000000] Hardware name: STM32 (Device Tree Support)
[ 0.000000] [<c03123ec>] (unwind_backtrace) from [<c030ce0c>] (show_stack+0x10/0x14)
[ 0.000000] [<c030ce0c>] (show_stack) from [<c0e27250>] (dump_stack+0x8c/0xa0)
[ 0.000000] [<c0e27250>] (dump_stack) from [<c1507e9c>] (arm_pte_alloc+0x74/0xb8)
[ 0.000000] [<c1507e9c>] (arm_pte_alloc) from [<c15081ec>] (__create_mapping+0x30c/0x36c)
[ 0.000000] [<c15081ec>] (__create_mapping) from [<c15089f8>] (paging_init+0x234/0x648)
[ 0.000000] [<c15089f8>] (paging_init) from [<c1504950>] (setup_arch+0x660/0xcac)
[ 0.000000] [<c1504950>] (setup_arch) from [<c1500a4c>] (start_kernel+0x70/0x458)
[ 0.000000] [<c1500a4c>] (start_kernel) from [<00000000>] ( (null))
Kernel's EFI map:
[ 0.000000] efi: 0x0000c0000000-0x0000c1ffffff [Boot Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2000000-0x0000c2860fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2861000-0x0000c7cfffff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7d00000-0x0000c7efffff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7f00000-0x0000c7f0bfff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7f0c000-0x0000dc705fff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc706000-0x0000dc709fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc70a000-0x0000dcf6afff [Loader Code | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6b000-0x0000dcf6bfff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6c000-0x0000dcf72fff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf73000-0x0000dcf73fff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf74000-0x0000dcf75fff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf76000-0x0000dff80fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff81000-0x0000dff81fff [Runtime Code |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff82000-0x0000dfffffff [Loader Data | | | | | | | | |WB| | | ]
I've found some hacky workarounds on that and i'd like some input on what's
actually wrong
- Workaround 1, add a bogus bootefi cmd
instead of
load mmc 0:5 $kernel_addr_r efi/BOOT/zImage;
bootefi $kernel_addr_r $fdtcontroladdr
doing
bootefi $kernel_addr_r $fdtcontroladdr
load mmc 0:5 $kernel_addr_r efi/BOOT/zImage
bootefi $kernel_addr_r $fdtcontroladdr' works
The first bootefi command will fail since there's nothing loaded on
that address yet. What happens is that u-boot adds an extra
memory_map, via efi_add_memory_map() and the kernel boots
Kernel's EFI map:
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x0000c0000000-0x0000c1ffffff [Boot Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2000000-0x0000c2860fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2861000-0x0000c7cf3fff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7cf4000-0x0000c7ef3fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7ef4000-0x0000c7f0bfff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7f0c000-0x0000dc704fff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc705000-0x0000dc708fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc709000-0x0000dcf69fff [Loader Code | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6a000-0x0000dcf6cfff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6d000-0x0000dcf6dfff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6e000-0x0000dcf74fff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf75000-0x0000dcf75fff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf76000-0x0000dff80fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff81000-0x0000dff81fff [Runtime Code |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff82000-0x0000dfffffff [Loader Data | | | | | | | | |WB| | | ]
- Workaround 2, copy fdt one page before the 127mb limit
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3619a20e6433..a0b6156845da 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -108,11 +108,13 @@ static efi_status_t copy_fdt(void **fdtp)
* Safe fdt location is at 127 MiB.
* On the sandbox convert from the sandbox address space.
*/
- new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f00000 +
- fdt_size, 0);
+ //new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f00000 +
+ //fdt_size, 0);
+ new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f00000, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
EFI_RUNTIME_SERVICES_DATA, fdt_pages,
&new_fdt_addr);
+ printf("FDTADDR: %llx pages %lu sz %x\n", new_fdt_addr, fdt_pages, fdt_size);
if (ret != EFI_SUCCESS) {
/* If we can't put it there, put it somewhere */
new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
This loads the fdt on c7ef4000 (which is more than a page). Changing
the address from 0x7f00000 to 7EFF000, on the original code, works as
well
Kernel's EFI map (with the patch) :
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x0000c0000000-0x0000c1ffffff [Boot Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2000000-0x0000c2860fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2861000-0x0000c7cf3fff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7cf4000-0x0000c7ef3fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7ef4000-0x0000c7efffff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7f00000-0x0000dc705fff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc706000-0x0000dc709fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc70a000-0x0000dcf6afff [Loader Code | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6b000-0x0000dcf6bfff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6c000-0x0000dcf72fff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf73000-0x0000dcf73fff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf74000-0x0000dcf75fff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf76000-0x0000dff80fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff81000-0x0000dff81fff [Runtime Code |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff82000-0x0000dfffffff [Loader Data | | | | | | | | |WB| | | ]
- Workaround 3, align fdt on 1mb boundries
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3619a20e6433..37e849fad773 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -101,7 +101,8 @@ static efi_status_t copy_fdt(void **fdtp)
* needs to be expanded later.
*/
fdt = *fdtp;
- fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
+ //fdt_pages = efi_size_in_pages(fdt_totalsize(fdt) + 0x3000);
+ fdt_pages = efi_size_in_pages(0x100000);
fdt_size = fdt_pages << EFI_PAGE_SHIFT;
/*
Kernel's EFI map:
[ 0.000000] efi: Processing EFI memory map:
[ 0.000000] efi: 0x0000c0000000-0x0000c1ffffff [Boot Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2000000-0x0000c2860fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c2861000-0x0000c7cfffff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7d00000-0x0000c7efffff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c7f00000-0x0000c7ffffff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000c8000000-0x0000dc705fff [Conventional Memory| | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc706000-0x0000dc709fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dc70a000-0x0000dcf6afff [Loader Code | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6b000-0x0000dcf6bfff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf6c000-0x0000dcf72fff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf73000-0x0000dcf73fff [Runtime Data |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf74000-0x0000dcf75fff [Reserved | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dcf76000-0x0000dff80fff [Loader Data | | | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff81000-0x0000dff81fff [Runtime Code |RUN| | | | | | | |WB| | | ]
[ 0.000000] efi: 0x0000dff82000-0x0000dfffffff [Loader Data | | | | | | | | |WB| | | ]
Thanks
/Ilias
next reply other threads:[~2019-04-10 16:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 16:57 Ilias Apalodimas [this message]
2019-04-10 18:27 ` [U-Boot] bootefi failures on armv7 Heinrich Schuchardt
2019-04-10 18:38 ` Ilias Apalodimas
2019-04-10 20:15 ` Heinrich Schuchardt
2019-04-10 20:35 ` Ilias Apalodimas
2019-04-11 18:15 ` Ard Biesheuvel
2019-04-11 18:44 ` Ilias Apalodimas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190410165704.GA10242@apalos \
--to=ilias.apalodimas@linaro.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox