title: why is load address of kernel, ramdisk important in booting?
body: <p>I am dealing with android boot.img which is a combination of compressed kernel, ramdisk, and dtb. I see from the serial console log from uboot about the booting process and here's the part that triggers my curiosity</p>
  
  <pre><code>CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
  CPU:   Temperature 27 C
  Reset cause: POR
  Board: MX6-SabreSD
  I2C:   ready
  DRAM:  1 GiB
  PMIC:  PFUZE100 ID=0x10
  MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
  No panel detected: default to Hannstar-XGA
  Display: Hannstar-XGA (1024x768)
  In:    serial
  Out:   serial
  Err:   serial
  check_and_clean: reg 0, flag_set 0
  Fastboot: Normal
  flash target is MMC:1
  Net:   FEC [PRIME]
  Normal Boot
  Hit any key to stop autoboot:  3  2  1  0 
  boota mmc1 
  kernel   @ 14008000 (7272352)
  ramdisk  @ 15000000 (869937)
  fdt      @ 14f00000 (44072)
  ## Booting Android Image at 0x12000000 ...
  Kernel load addr 0x14008000 size 7102 KiB
  Kernel command line: console=ttymxc0,115200 init=/init video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32 video=mxcfb1:off video=mxcfb:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consolebalank=0 androidboot.hardware=freescale cma=384M
  ## Flattened Device Tree blob at 14f00000
     Booting using the fdt blob at 0x14f00000
     Loading Kernel Image ... OK
     Using Device Tree in place at 14f00000, end 14f0dc27
  switch to ldo_bypass mode!
  
  Starting kernel ...
  </code></pre>
  
  <p>The kernel's address is 14008000, ramdisk 15000000, fdt 14f00000.
  I have found out that these values are saved in the boot.img header and when I manually mess with this values, the image will not boot even though the actual contents are not modified.</p>
  
  <p>Why is this address so critical? Why does it have to be these values? why not other values?</p>
  
  <p>One of my own guess is: 
  these load address values are hardcoded inside the kernel so if I change it in the boot.img header it will cause side-effects. To elaborate my own theory, loading the kernel to the 'modified' load addr won't be a problem. But when actually executing the lines, it will cause severe problems because these codes are fixed to work with the proper 'load addr'.</p>
  
  <p>Is my theory wrong? If so, I'd be grateful if you could correct me.</p>