Re: [PATCH v2 2/2] ARM: move device tree mapping out of linear region

[Marek Szyprowski <m.szyprowski@samsung.com>]

Hi Ard,

On 28.10.2020 13:52, Ard Biesheuvel wrote:
> On Wed, 28 Oct 2020 at 13:05, Joel Stanley <joel@jms.id.au> wrote:
>> On Wed, 28 Oct 2020 at 09:19, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>>> On 07.10.2020 10:39, Ard Biesheuvel wrote:
>>>> On ARM, setting up the linear region is tricky, given the constraints
>>>> around placement and alignment of the memblocks, and how the kernel
>>>> itself as well as the DT are placed in physical memory.
>>>>
>>>> Let's simplify matters a bit, by moving the device tree mapping to the
>>>> top of the address space, right between the end of the vmalloc region
>>>> and the start of the the fixmap region, and create a read-only mapping
>>>> for it that is independent of the size of the linear region, and how it
>>>> is organized.
>>>>
>>>> Since this region was formerly used as a guard region, which will now be
>>>> populated fully on LPAE builds by this read-only mapping (which will
>>>> still be able to function as a guard region for stray writes), bump the
>>>> start of the [underutilized] fixmap region by 512 KB as well, to ensure
>>>> that there is always a proper guard region here. Doing so still leaves
>>>> ample room for the fixmap space, even with NR_CPUS set to its maximum
>>>> value of 32.
>>>>
>>>> Tested-by: Linus Walleij <linus.walleij@linaro.org>
>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>> This patch landed in linux-next 20201028 as commit 7a1be318f579 ("ARM:
>>> 9012/1: move device tree mapping out of linear region"). Sadly it broke
>>> booting  almost all Samsung Exynos-based boards. The only one which
>>> booted, used an appended device tree. I can provide more information if
>>> needed, just let me know what to check. "Starting kernel ..." is the
>>> last message I see here. No output from earlycon.
>> A bisection lead me to this patch after the next-20201028 failed to
>> boot on the aspeed systems in testing (aspeed_g5_defconfig).
>>
>> You can reproduce this with today's next and qemu 5.1:
>>
>> qemu-system-arm -M romulus-bmc -nographic \
>>   -kernel arch/arm/boot/zImage \
>>   -dtb arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \
>>   -initrd any-old-file
>>
>> It requires the initrd option to reproduce, but the initrd doesn't
>> need to be valid as we don't make it that far.
>>
>> There is no output but attaching gdb shows the kernel is stuck in
>> setup_machine_tags. (If we enable CONFIG_ATAGS it is instead stuck in
>> calibrate_delay).
>>
>> (gdb) bt
>> #0  setup_machine_tags (machine_nr=<optimized out>,
>> __atags_vaddr=<optimized out>) at ../arch/arm/kernel/atags.h:12
>> #1  setup_arch (cmdline_p=0x80c01fc4) at ../arch/arm/kernel/setup.c:1100
>> #2  0x80b00d2c in start_kernel () at ../init/main.c:862
>> #3  0x00000000 in ?? ()
>>
>> Reverting 7a1be318f579 on top of next allowed the system to boot again.
>>
> Does this help?
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index bb79e52aeb90..4f355bda872a 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -68,8 +68,8 @@
>   #define XIP_VIRT_ADDR(physaddr)  (MODULES_VADDR + ((physaddr) & 0x000fffff))
>
>   #define FDT_FIXED_BASE         UL(0xff800000)
> -#define FDT_FIXED_SIZE         (2 * PMD_SIZE)
> -#define FDT_VIRT_ADDR(physaddr)        ((void *)(FDT_FIXED_BASE |
> (physaddr) % PMD_SIZE))
> +#define FDT_FIXED_SIZE         (2 * SECTION_SIZE)
> +#define FDT_VIRT_ADDR(physaddr)        ((void *)(FDT_FIXED_BASE |
> (physaddr) % SECTION_SIZE))
>
>   #if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
>   /*

Yes, this fixes booting of my Samsung Exynos-based test boards :)

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland