Introduction of ARM_PATCH_PHYS_VIRT as default would make the platform to support dynamic reallocation of memory and also allows phy-to-virt and virt-to-phy translations functions at boot time and module loading time. AUTO_ZRELADDR would introduce address calculation of decompressed kernel from the location of zImage in RAM.

EXYNOS platforms mostly uses Onenand which was developed as replacement of NOR devices, it is developed such that it plugs directly into existing NOR interface. OneNAND supports NOR interfaces also for backward compatibility with NOR supporting system.

Below explaination by Russel in LKML clears the concept of AUTO_ZRELADDR and ARM_PATCH_PHYS_VIRT

AUTO_ZRELADDR=n ZBOOT_ROM=n => fixed address for decompressed kernel image to be decompressed to from zreladdr make variable, decompressor can be loaded to any RAM address.

AUTO_ZRELADDR=y ZBOOT_ROM=n => address for decompressed kernel calculated from location of zImage in RAM, decompressor must be loaded to the correct place in RAM and must always copy itself out of the way prior to decompressing.

AUTO_ZRELADDR=n ZBOOT_ROM=y => fixed address for decompressed kernel image to be decompressed to from zreladdr make variable, decompressor can be loaded to any RAM address which doesn't overlap its BSS segment, or decompressor programmed into read-only memory at the address to which it was compiled.

AUTO_ZRELADDR=y ZBOOT_ROM=y => invalid (think about it - this results in a zImage which is built to be run from read-only memory, and try to write the decompressed image into that read-only memory.)

This has nothing to do with XIP or not - XIP is a completely separate story, and if you're building an XIP kernel you're not using the decompressor (so AUTO_ZRELADDR and ZBOOT_ROM don't even feature.) Neither does the dynamic code patching stuff like ARM_PATCH_PHYS_VIRT.

ARM_PATCH_PHYS_VIRT has no bearing on AUTO_ZRELADDR or ZBOOT_ROM; that is a property of the decompressed kernel image itself, and while your decompressor may restrict where it can decompress the kernel image to, the decompressed image itself remains free of those dependencies (and eg, can be turned into a uImage with the appropriate load address for other platforms.)

As I've said in the past, what I'd _like_ to see is that ARM_PATCH_PHYS_VIRT be enabled for everything irrespective of any other configuration, and we're just left with AUTO_ZRELADDR / ZBOOT_ROM to worry about. The overhead from the P:V patching is soo small that it's not really worth even having the option in the general case - the only time when P:V patching doesn't work is with non-linear translations found on some sparsemem platforms.

But... one thing to note is that it _is_ common to load the decompressor at a _different_ address to that where the kernel ultimately ends up residing to avoid the additional copy in the decompressor. My experience shows that this is quite common on the platforms I had supplied. This means that if we default to AUTO_ZRELADDR for !ZBOOT_ROM, we end up having to have developers change their uboot setups to avoid unexpected results.

panchaxari (1): ARM:EXYNOS:Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+)