[U-Boot] bootefi failures on armv7

[Ilias Apalodimas]

> 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 <asm/pgtable-3level.h>
> #else
> #include <asm/pgtable-2level.h>
> #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] [<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|  |  |  ]
> 
> 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