Hi Stephen,
On Thu, Jul 23, 2020 at 3:19 AM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
> Quoting Linus Walleij (2020-07-21 05:58:59)
> > On Mon, Jul 20, 2020 at 11:53 AM Arnd Bergmann <arnd@xxxxxxxx> 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?
As this patch adds C code to extract the start of memory from DT, it
should be quite easy to add code to filter out regions marked reserved
in DT. In fact that would be a prerequisite for making this work with
crashkernel support (+ making the crashkernel code mark its memory as
reserved in DT).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
