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

Stephen Boyd sboyd at kernel.org
Sat Aug 15 04:28:35 EDT 2020


Quoting Linus Walleij (2020-08-14 07:03:41)
> On Thu, Jul 23, 2020 at 3:19 AM Stephen Boyd <sboyd at 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.



More information about the linux-arm-kernel mailing list