[PATCH/RFC v7] ARM: boot: Obtain start of physical memory from DTB

[Stephen Boyd]

Quoting Linus Walleij (2020-07-21 05:58:59)
> On Mon, Jul 20, 2020 at 11:53 AM Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > No idea what /exactly/ is going wrong, but I would point out that this is one
> > of the platforms that is handled as a special case in the Makefile when
> > setting TEXT_OFFSET:
> (...)
> > 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. I think the problem
is the decompressor would have to parse the reserved memory sections in
DT to figure out that it shouldn't decompress over shared memory, and
changing the decompressor to do that was deemed "hard". Does this patch
series resolve that?

> 
> It was originally added by Stephen in
> commit 9e775ad19f52d70a53797b4d0eb740c52b0a9567

That was almost a decade ago! Don't remind me of these things ;-)

> "ARM: 7012/1: Set proper TEXT_OFFSET for newer MSMs"
> to patch around memblocks in the board files in
> mach-msm/* These boardfile hacks that seem to relate to this
> textofs are now *GONE* but this is still here!
> 
> Laura, Stephen, Bjorn: can't we just delete these QCOM
> textofs things so as to clean out some confusion?
> 
> Or is my APQ8060 odd once again and the rest of the world
> crashes if we remove this?
>