Change of TEXT_OFFSET for multi_v7_defconfig

Nicolas Pitre nicolas.pitre at linaro.org
Tue Apr 22 10:55:16 PDT 2014


On Tue, 22 Apr 2014, Jason Gunthorpe wrote:

> On Tue, Apr 22, 2014 at 10:44:14AM +0100, Daniel Thompson wrote:
> > On 17/04/14 21:35, Jason Gunthorpe wrote:
> > >>> The above is useful for loading the raw uncompressed Image without 
> > >>> carrying the full ELF baggage.
> > >>
> > >> What exactly is the full ELF baggage? Aren't there existing mechanisms to omit
> > >> debugging symbols, for example, if size is of concern?
> > > 
> > > FWIW, it is a small non-intrusive change to produce ELFs with the
> > > proper LMA, if it is useful for specialized tooling, here is the 3.14
> > > version of the patch I created (I see it needs a bit of cleanup..)
> > > You must also force PATCH_PHYS_VIRT off.
> > > 
> > > The ELF also has the correct entry point address, so ELF tooling can
> > > just jump into it, after setting the proper register values according
> > > to the boot protocol.
> > 
> > That might be a useful approach for single platform kernels but I don't
> > think such an approach can work for multi-arch kernels since, because
> > the RAM can be located anywhere in the address map, the physical load
> > address is platform dependant.
> 
> Right, I think everyone realizes that.
> 
> What this patch does is make kernels that are built with
> PLAT_PHYS_OFFSET set and CONFIG_ARM_PATCH_PHYS_VIRT disabled produce
> an ELF that reflects the build configuration.
> 
> Based on comments from others in the thread this is looking useful for
> a variety of cases.

Well...

We do not want people in general to have PLAT_PHYS_OFFSET defined and
CONFIG_ARM_PATCH_PHYS_VIRT disabled.  In fact a huge effort has been 
deployed to go the exact opposite way over the last few years.

There are special cases where CONFIG_ARM_PATCH_PHYS_VIRT needs to be 
turned off for example.  But those are specialized configurations and 
they should be the exception not the norm.  And you should be knowing 
what you're doing in those cases.

So I doubt it is worth complexifying the linker script for something 
that is meant to be the exception, _especially_ if this is for some 
debugging environment purposes.  You may just adjust some setting in 
your environment or do a quick kernel modification locally instead.  
And if you don't know what to modify then you're probably lacking the 
necessary qualifications to perform that kind of kernel debugging in the 
first place.

Making the patch available on a mailing list is fine.  If it is useful 
to someone else then it'll be found.  But I don't think this is useful 
upstream.


Nicolas



More information about the linux-arm-kernel mailing list