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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ard,

On 28.10.2020 10:24, Ard Biesheuvel wrote:
> On Wed, 28 Oct 2020 at 10:22, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>> On Wed, 28 Oct 2020 at 10:19, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> 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@xxxxxxxxxx>
>>>> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
>>>> Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
>>> 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.
>>>
>> Thanks for the report. I will have a look later today.
>>
>> Do these platforms happen to have any static device mappings that may
>> collide with this mapping of the FDT? Also, could this be related to
>> device drivers making changes in memory to the FDT image? Because the
>> permanent mapping of the FDT is read-only now.
>>
> IOW, does using MT_MEMORY_RW instead of MT_ROM for the mapping make a
> difference?

Nope, chaning it to MT_MEMORY_RW doesn't fix anything.

The only static mapping I'm aware is S5P_VA_CHIPID at 0xF6000000 + 
0x02000000.

Best regards

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




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux