Quoting Geert Uytterhoeven (2020-08-03 03:18:08) > 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). > Cool. Sounds like that may need to be done then before it works on these particular qcom platforms.
