I was thinking about how when I program my target board the PROGRAMMER programs the target board based on the information present in the executable generated, which I feel is done by the linker script, linking the various files and creating information of .init, .text, .data, .fini, etc
I was wondering when for example Apple rolls out an iOS update which is for example 100MB in size, this update has its own set of variables- global static const, initialized, uninitialized, etc. This would result in a new memory map. So now when this update installs on the processor of consider an iPhone then how does this work? Is there some additional memory left in the .init, .text, .data, etc section of the OS code for such future updates?
PS: I might have made some technical errors in my description above, I will appreciate any edits to it
The answer to your question is pretty simple to be honest. Your primary question is "where do you get the memory for future software updates". The answer is the DRAM of the system. In the first part of your question, your talking about bare metal programming. Your second part of the question is about OS level programming. For the first part you basically put the processor in isp mode and program the flash or other nv memory. In the second part, the way it works is completely different.
Basically, (stripped down mechanism) your update is divided in parts viz: bootloader, kernel, initramfs, firmware, application. You first transfer the code(bundled package) to the device using some protocol like say ftp. This transfer really puts the code on the DRAM of the system. Then on your system (example running Linux) you have code (logic) to uncompress this code and make integrity checks (checksum of files). Then the system has further code to analyse all these components and determine if any of its existing components need an update (check the md5 sum of the incoming component and compare with the existing one). Example say if you made changes in the init scripts of the kernel or you want some new script in the init.d, you basically changed the initramfs. So the code on the system sees this and determines that alright I need an update on the initramfs.
Also the ultimate destination for the new code is the flash. Since flash has certain rules you need to follow to make writes and erases to it, you basically mount a flash file system on the flash. But you can't use that to burn code to it since filesystems like jffs2 use wear leveling mechanisms and hence the data is scattered in the physical flash (with jffs2 mounted on it). This is unacceptable by the way because you want your complete bootloader, kernel, initramfs etc on contiguous locations in flash. So in our example system running Linux, you have something called mtd driver. You can use this driver to program the flash with all the components. Long story short, the DRAM is the interim location for software updates. So you have to make sure one of two 1. You have sufficient memory 2. Your software update bundle fits in the DRAM.