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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
