On Fri, Jun 22, 2018 at 11:57:32AM -0400, Nicolas Pitre wrote: > That is no longer a kernel config/build issue if you the system > integrator put an XIP kernel on a target with the wrong DT. > > The XIP kernel does require that you provide the actual memory base > address as a constant to the build system but that could be extracted > directly from the DT data if having a kconfig prompt for that is too > unwieldy. The new kconfig macro language in mainline could even be > leveraged to do that at config time. That is actually incorrect - you're too used to the dynamic fixup of virt_to_phys() and friends now! Given that XIP is typically used in environments where the kernel text is very much unmodifyable, we disable CONFIG_ARM_PATCH_PHYS_VIRT. When disabled, we use a constant translation, based upon the build-time CONFIG_PHYS_OFFSET and CONFIG_PAGE_OFFSET settings. The early assembler relies upon these settings - which must be known before we enable the MMU. As such, DT parsing is not available to us at that point (as we can't run any C code, because we won't be calling it at the address it was linked for.) I suppose someone who was sufficiently motivated could write assembly- based parsing of DT to extract the memory regions and work out what the right settings are. Is there really the motivation to do that - there was a burst of XIP interest a few releases ago but it seems to have tailed off. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html