2

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

Anurag
  • 651
  • 4
  • 18
  • Um, usually it just replaces the old stuff. No reason to keep it around, right? So no reason to keep "space" for future stuff because the it will just be written over anyways. – AbstractDissonance Apr 08 '16 at 03:01
  • what do you mean by replaces the old stuff? the new update is definitely not the same size as the older one then how ? I dont think the entire OS software is reinstalled – Anurag Apr 08 '16 at 03:07
  • Ever wondered why you usually need to reboot after such an update? No need to update the running OS in memory, as you can update the files on disk and reboot so the new files are loaded. – Macmade Apr 08 '16 at 03:10
  • The more I read your question, the less I understand it. Are you actually thinking an OS is just one large, several gigs, binary file? – Macmade Apr 08 '16 at 03:17
  • It depends on the update type. Also, most OS's persistent memory are segmented into different parts. An update only touches those that it will change. It is analogous to a file system. You can overwrite the files that are needed and keep the ones that are not. Apple knows what files/memory areas changed and just has to overwrite the ones that changed. No need to keep all the old stuff in the binary. Essentially a simple diff tool can tell them what changes and what doesn't and then they just have to overwrite/modify the old that that needs to be changed. There are many ways this can be done. – AbstractDissonance Apr 08 '16 at 03:21

1 Answers1

0

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.

take it easy
  • 16
  • 3