I’m going to reverse course a bit and ask what is it that you need the initrd file for? What makes this so big?
Next, an observation with some history: Normally modules and the initrd share a space in physical address directly below the start of the kernel. The maximum size of a direct branch instruction is what limits the total size. On a 32-bit ARMv7 this was limited to 32MB. I think on 64-vit ARMv8 it grows to 128MB. Within this range of physical address below the start of kernel anything occurring outside of this results in “unreachable code” with undefined side effects. Within this region there is some preset location to define where initrd and modules separate. This isn’t dynamic, it is a fixed location. On 32-bit ARMv7 you had these two mutually exclusive options which defines the split:
CONFIG_TASK_SIZE_3G_LESS_16M
CONFIG_TASK_SIZE_3G_LESS_24M
(EDIT: I'm not actually positive if this is the correct config but probably it is)
On arm32 picking 16MB for one implies 16MB for the other. Picking 24MB for one implies 8MB for the other. If initrd or module combined sizes exceed its limit, then it is essentially a buffer overflow of one into the other.
Picking a combined total size and offset of initrd in the wrong direction would imply the kernel itself may be overwriting the initrd space (or more accurately, the bootloader might be loading the kernel into memory which clobbers the upper address area of your initrd). More available space would imply a lower base physical address since this space preceeds the kernel’s starting address.
I am not sure where that dividing line is for the 128MB direct branch limit of 64-bit ARM, but the placement at 0x92800000 instead of current 0x82800000 might be the opposite of what you think it is since this moves memory closer to the start of the kernel instead of further away. I also don’t know simply putting this at a different address would be interpreted correctly if modules do not also know about this address change (I have neither tried nor researched this). A lot could be simplified if your initrd wasn’t that big. Do you really need this for boot to start (e.g., is it for filesystems)?
Going on to the original question, I did this experiment. I created an environment variable “deleteme_var” set to value “abcxyz” in the U-Boot console. I then ran “saveenv” and restarted without running Linux itself…the variable still existed. Then I booted completely into Linux, and again rebooted back into the U-Boot console. Upon reboot after going through the full Linux boot cycle the variable was still there and correctly set. This tells you how memory is saved when there is nothing overwriting it.
The environment variable ramdisk_addr_r itself is likely not being changed through any U-Boot mechanism forgetting or losing the edited value. Very likely there is some other part of boot editing this before U-Boot gets its environment passed to it. Perhaps something in cboot…I don’t know. Perhaps the device tree…I don’t know. Perhaps it is just a sanity test being performed which doesn’t like this value and is reverting it to a default…I don’t know.
If you really need this address change for a bigger initrd I’ll suggest that you need to research what constraints there are on arm64 initrd/module address space setup. Even if your environment is able to save an edited ramdisk_addr_r it is likely the kernel itself would also need to know about the change (and it is architecture specific how to do this). If that total space from the base address was already 128MB, then there is no possibility of extending it further due to limitations of the direct branch assembler instruction. If the space reserved was less than or equal to 128MB, then perhaps what you need to do is edit the dividing line of how modules and initrd share that space since the total can never exceed the direct branch size (and I don’t know what mechanisms exist under arm64 to do this).