linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Kumar Gala" <kumar.gala@linaro.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Nicolas Pitre" <nico@fluxnic.net>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Lukasz Stelmach" <l.stelmach@samsung.com>,
	"Russell King" <linux@armlinux.org.uk>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"Chris Brandt" <chris.brandt@renesas.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Eric Miao" <eric.miao@nvidia.com>,
	"Dmitry Osipenko" <digetx@gmail.com>,
	"Laura Abbott" <labbott@redhat.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB
Date: Sat, 15 Aug 2020 01:28:35 -0700	[thread overview]
Message-ID: <159748011515.33733.12886780037889852900@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CACRpkdaN22OjWsG+d-hp_NEw==3VVAsWHkFsiG642KmbjD_6Mg@mail.gmail.com>

Quoting Linus Walleij (2020-08-14 07:03:41)
> On Thu, Jul 23, 2020 at 3:19 AM Stephen Boyd <sboyd@kernel.org> wrote:
> 
> > > > textofs-$(CONFIG_ARCH_IPQ40XX) := 0x00208000
> > > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000
> > > > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
> > >
> > > But what on earth is this? I just deleted this and the platform
> > > boots just as well.
> >
> > We need to shift the kernel text to start 2MB beyond the start of memory
> > because there is the shared memory region used to communicate with other
> > processors in the SoC there. It took a while for us to convince other OS
> > folks in the company to put shared memory somewhere else besides the
> > start of RAM, but eventually we won that battle.
> >
> > Does your booted kernel have its text section at the start of RAM or is
> > it offset by 2MB without this change? Check out /proc/iomem to see where
> > the kernel text is in relation to the start of RAM.
> 
> The memory on this machine starts at 0x40200000 since the effect
> of the current code is to take pc &= 0xf8000000 and that results in
> 0x40000000 and then this adds textofs 0x00208000 to that
> resulting in 0x40208000 for the kernel physical RAM. Which
> is what we want to achieve since the RAM starts at
> 0x40200000.

The bootloader is telling the kernel that memory starts at 0x40200000
but in reality RAM or DDR starts at 0x40000000 and the first 2MB are
reserved for shared memory. In the old days the bootloader would remove
the shared memory region from the memory layout and update ATAGs to
indicate that memory started at 0x40200000.

> 
> But TEXT_OFFSET is also used inside the kernel to offset the
> virtual memory. This means that when we set up the virtual
> memory split, the kernel virtual memory is also bumped by
> these 2 MB so the virtual memory starts at 0xC0208000
> instead of 0xC0008000 as is normal.
> 
> It looks weird to me but maybe someone can explain how
> logical that is?

Yes, that's intentional. I believe that's because it will map the first
2MB of memmory otherwise with the wrong attributes. The kernel needs to
map shared memory as non-cacheable or something like that so that
communication to the modem isn't going through the cache and needing
constant cleaning.

Hope it helps! If not, we can probably dig up mailing list discussions
on this.

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

  parent reply	other threads:[~2020-08-15  8:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06 15:02 [PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB Geert Uytterhoeven
2020-07-07  6:50 ` Ard Biesheuvel
2020-07-07  7:39   ` Geert Uytterhoeven
2020-07-07  7:45     ` Ard Biesheuvel
2020-07-07  7:58       ` Geert Uytterhoeven
2020-07-07  8:35         ` Ard Biesheuvel
2020-07-07  8:40           ` Ard Biesheuvel
2020-07-07  9:09             ` Ard Biesheuvel
2020-07-20  9:45 ` Linus Walleij
2020-07-20  9:53   ` Arnd Bergmann
2020-07-21 12:58     ` Linus Walleij
2020-07-23  1:19       ` Stephen Boyd
2020-08-03 10:18         ` Geert Uytterhoeven
2020-08-03 19:46           ` Stephen Boyd
2020-08-14 14:03         ` Linus Walleij
2020-08-14 14:06           ` Ard Biesheuvel
2020-08-15  9:18             ` Russell King - ARM Linux admin
2020-08-15  8:28           ` Stephen Boyd [this message]
2020-08-15  9:16           ` Russell King - ARM Linux admin
2020-08-15 10:28             ` Linus Walleij

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=159748011515.33733.12886780037889852900@swboyd.mtv.corp.google.com \
    --to=sboyd@kernel.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=chris.brandt@renesas.com \
    --cc=digetx@gmail.com \
    --cc=eric.miao@nvidia.com \
    --cc=geert+renesas@glider.be \
    --cc=kumar.gala@linaro.org \
    --cc=l.stelmach@samsung.com \
    --cc=labbott@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=masahiroy@kernel.org \
    --cc=nico@fluxnic.net \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).