All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Nicolas Pitre <nico@fluxnic.net>,
	Linus Walleij <linus.walleij@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v2 2/2] ARM: move device tree mapping out of linear region
Date: Wed, 28 Oct 2020 10:43:54 +0100	[thread overview]
Message-ID: <c740495b-2dc1-3e19-27f1-153114f5f96d@samsung.com> (raw)
In-Reply-To: <CAMj1kXGXcNydxXjNnbKcy3qSETuMbqWSwRrTLqZ7-p99P4c2Mg@mail.gmail.com>

Hi Ard,

On 28.10.2020 10:24, Ard Biesheuvel wrote:
> On Wed, 28 Oct 2020 at 10:22, Ard Biesheuvel <ardb@kernel.org> wrote:
>> On Wed, 28 Oct 2020 at 10: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.
>>>
>> 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


WARNING: multiple messages have this Message-ID (diff)
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Nicolas Pitre <nico@fluxnic.net>,
	Linus Walleij <linus.walleij@linaro.org>,
	Russell King <linux@armlinux.org.uk>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] ARM: move device tree mapping out of linear region
Date: Wed, 28 Oct 2020 10:43:54 +0100	[thread overview]
Message-ID: <c740495b-2dc1-3e19-27f1-153114f5f96d@samsung.com> (raw)
In-Reply-To: <CAMj1kXGXcNydxXjNnbKcy3qSETuMbqWSwRrTLqZ7-p99P4c2Mg@mail.gmail.com>

Hi Ard,

On 28.10.2020 10:24, Ard Biesheuvel wrote:
> On Wed, 28 Oct 2020 at 10:22, Ard Biesheuvel <ardb@kernel.org> wrote:
>> On Wed, 28 Oct 2020 at 10: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.
>>>
>> 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-28 22:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07  8:39 [PATCH v2 0/2] ARM: move FDT mapping out of linear region Ard Biesheuvel
2020-10-07  8:39 ` [PATCH v2 1/2] ARM: centralize phys-to-virt conversion of DT/ATAGS address Ard Biesheuvel
2020-10-07 15:28   ` Nicolas Pitre
2020-10-07  8:39 ` [PATCH v2 2/2] ARM: move device tree mapping out of linear region Ard Biesheuvel
2020-10-07 15:28   ` Nicolas Pitre
2020-10-07 15:32     ` Ard Biesheuvel
2020-10-07 16:38       ` Nicolas Pitre
2020-10-07 16:40       ` Nicolas Pitre
2020-10-07 21:32     ` Russell King - ARM Linux admin
2020-10-07 22:05       ` Nicolas Pitre
     [not found]   ` <CGME20201028091912eucas1p13fb9cd947faa6bfd79199ea79648b6af@eucas1p1.samsung.com>
2020-10-28  9:19     ` Marek Szyprowski
2020-10-28  9:19       ` Marek Szyprowski
2020-10-28  9:22       ` Ard Biesheuvel
2020-10-28  9:22         ` Ard Biesheuvel
2020-10-28  9:24         ` Ard Biesheuvel
2020-10-28  9:24           ` Ard Biesheuvel
2020-10-28  9:43           ` Marek Szyprowski [this message]
2020-10-28  9:43             ` Marek Szyprowski
2020-10-28 12:05       ` Joel Stanley
2020-10-28 12:05         ` Joel Stanley
2020-10-28 12:52         ` Ard Biesheuvel
2020-10-28 12:52           ` Ard Biesheuvel
2020-10-28 12:59           ` Joel Stanley
2020-10-28 12:59             ` Joel Stanley
2020-10-28 13:00             ` Ard Biesheuvel
2020-10-28 13:00               ` Ard Biesheuvel
2020-10-28 13:06               ` Joel Stanley
2020-10-28 13:06                 ` Joel Stanley
2020-10-28 13:00           ` Russell King - ARM Linux admin
2020-10-28 13:00             ` Russell King - ARM Linux admin
2020-10-28 13:04             ` Ard Biesheuvel
2020-10-28 13:04               ` Ard Biesheuvel
2020-10-28 13:09               ` Russell King - ARM Linux admin
2020-10-28 13:09                 ` Russell King - ARM Linux admin
2020-10-28 13:16           ` Marek Szyprowski
2020-10-28 13:16             ` Marek Szyprowski
2020-10-11 16:39 ` [PATCH v2 0/2] ARM: move FDT " Ard Biesheuvel

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=c740495b-2dc1-3e19-27f1-153114f5f96d@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=ardb@kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=krzk@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=nico@fluxnic.net \
    --cc=robh+dt@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.