From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilias Apalodimas Date: Wed, 10 Apr 2019 23:35:08 +0300 Subject: [U-Boot] bootefi failures on armv7 In-Reply-To: References: <20190410165704.GA10242@apalos> Message-ID: <20190410203508.GA16290@apalos> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > On 4/10/19 6:57 PM, Ilias Apalodimas wrote: > >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 > > CONFIG_ARM_LPAE=y influences the number of page table levels: > > #ifdef CONFIG_ARM_LPAE > #include > #else > #include > #endif > > Hence in arch/arm/mm/mmu.c, arm_pte_alloc() different values of > PTE_HWTABLE_OFF and PTE_HWTABLE_SIZE will be used. Yes exactly. That was my understanding as well > > > > >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] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > >[ 0.000000] [] (show_stack) from [] (dump_stack+0x8c/0xa0) > >[ 0.000000] [] (dump_stack) from [] (arm_pte_alloc+0x74/0xb8) > >[ 0.000000] [] (arm_pte_alloc) from [] (__create_mapping+0x30c/0x36c) > >[ 0.000000] [] (__create_mapping) from [] (paging_init+0x234/0x648) > >[ 0.000000] [] (paging_init) from [] (setup_arch+0x660/0xcac) > >[ 0.000000] [] (setup_arch) from [] (start_kernel+0x70/0x458) > >[ 0.000000] [] (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| | | ] > > So this seems to be the allocation for the devicetree starting at 127 > MiB from RAM start. >From a u-boot point of view everything seems ok. The start address + size of the DTB are correctly 'fed' into the Linux EFI memory mappings and everything seems properly aligned. > You seem not to be using the Linux device tree: > Linux 5.0 has 25004 bytes in arch/arm/boot/dts/stm32mp157c-ed1.dtb. So > this fits into 7 pages + 3 pages we add to it. But here 12 pages are > allocated. No i am using Patrick's tree from https://github.com/patrickdelaunay/u-boot on the 2019.x branch. I am using that DTB. > > Up to this point I cannot see where U-Boot is doing anything > incorrectly. I would not want to change the 127 MiB value to some other > value that might fail on other boards. Of course. I never suggested we should change that, especially since we don't have any evvidence that says 'it's a uboot problem'. I just tried to move the FDT around and see if anything fixes my issue, while trying to debug page table creation as well. > > Maybe you could contact the Linux mm maintainers to get an understanding > what implicit assumptions the Linux kernel makes when building page > tables or how to debug the problem. Yep that's the next step Thanks for looking at this /Ilias