/* ld script to make rrload * taken from the arm Linux kernel version * Cadenux (Todd Fischer) */OUTPUT_ARCH(arm)/* rrload loader script used when upgrading rrload.  This version   of the loader script simply stores rrload where the kernel usually   goes. */ENTRY(main)SECTIONS{  . = 0x00900000;  __KernCommandLineMagicStr = .; /* magic pattern string == "kcmdline-->" */  . = 0x0090000C;                /* advance to .+strlen("kcmdline-->")+1 */  __KernCommandLineOverride = .; /* location of kernel command line string */  . = 0x009000E0;  __EtherMACMagicStr = .; /* magic pattern string == "etherMAC-->" */  . = 0x009000EC;         /* advance to .+strlen("etherMAC-->")+1 */  __EtherMAC = .;  . = 0x00900100;  btldr_start = .; /* required by btldr_pi.o */  .reset : {     head_dm270.o  }  .text : {*(.text)}  .rodata : {*(.rodata)}  btldr_end = .; /* required by btldr_pi.o */  __bss_start = .; /* required by head_dm270.o */  .bss : {*(.bss)}  __bss_end = .; /* required by head_dm270.o */  .data : {*(.data)}  __stack_start =0x6ff0; /* required by head_dm270.o */  ForUpGrade = 0x1;  FlashFileSysStart = 0x0; /* See Appendix-A below */  FlashFileSysEnd = 0x0;   /* See Appendix-A below */}/*   ------------------------------   --        Appendix-A        --   -- Special Override Feature --   ------------------------------   When a user requests that rrload erase the   filesystem component, how does it know what range of   flash to actually erase? The answer is that the   internal source code defines the flash memory range   that each of the components will occupy (components   such as the bootloader itself, the bootloader   params, the kernel and the filesystem).   The filesystem storage always follows the range set   aside for the kernel image storage which means that   if the kernel you store is significantly less than   the space set aside for it you will have a large pad   between the actual stored kernel image and the start   of the filesystem image. And likewise, if you have   kernel that is too large for the space set aside   then you will collide with the space set aside for   the filesystem. So...   -- The Controls Offered --   The rrload linker script offers the user the ability   to override the internal location of the filesystem   and move the range of address that are set aside to   store it. This then becomes the new default for all   filesystems downloaded and stored to flash and   becomes the new default used when the user requests   rrload to erase the filesystem range. The two   controls offered to the user are FlashFileSysStart   and FlashFileSysEnd.  Each can be adjusted   independently and if either is set to 0x0 then this   turns off the override for that control and allows   the system to resort to the internal factory default   for that value.   --FlashFileSysStart--   This setting also influences the size of the   filesystem storage area as well as the kernel   storage area. If you make the FlashFileSysStart   address lower than the internal factory default then   you will be increasing the filesystem storage area   and decreasing the kernel storage area that proceeds   it. And likewise if you increase the FlashFileSysStart   address beyond the internal factory default then you   will be decreasing the filesystem storage area and   increasing the kernel storage area.   --FlashFileSysEnd--   If you redefine the FlashFileSysEnd address then you   can control the high address of the flash range   involved in the storage set aside for the filesystem   and likewise sets the end of the range effected by a   user request to erase the flash component. Changing   this number has no effect on the amount of storage   set aside for the kernel which proceeds the filesystem   storage area.   -- Some Rules When Picking Values --   Legal values for FlashFileSysStart is any value that   begins on a flash block erase boundary.  For   this platform that would be numbers such as   0x00040000, 0x00060000, 0x00080000, etc, since the   erase unit size of our flash is 128Kbytes (2*64; two   chips interleaved).   Legal values for FlashFileSysStart is any value that   ends on a flash chip erase block boundary.  For this   platform that would be numbers such as 0x00003fff,   0x00005fff, 0x00007fff, etc, since    -- Ramifications to your XIP Kernel/FS Builds --   Don't forget that the range of address set asided   for storing filesystem images has a header reserved   at the start of the range used for rrload meta-data   meaning that the first address actually available   for the user bits of a filesystem image are   FlashFileSysStart+0x20. See BSPCONF_FILESYS_START in   asm/arch/memconfig.h. This only applies however if you   are creating an XIP kernel/filesystem build since   otherwise the BSPCONF_FILESYS_START will be set to a SDRAM   address and not a flash address and doesn't apply to   this discussion.   -- Some Examples --   If FlashFileSysStart is set to 0x00080000 then the earliest   location I could use for my downloaded filesystem   is 0x00080020. This would honor the reserved space mentioned.   This FlashFileSysStart setting would allow the kernel images   stored in flash to extend to address 0x00080000-1.   And for XIP Kernel/FS builds, the following applies...   e.g. `mkimage --LAddr 00080020 romdisk.img romdisk.img.rr   which is used when the xconfig session has 0x00080020   value defined for BSPCONF_FILESYS_START.   If FlashFileSysStart is set to 0x00120000 then the earliest   location I could use for my downloaded filesystem   is 0x00120020. This would honor the reserved space mentioned.   This FlashFileSysStart setting would allow the kernel images   stored in flash to extend to address 0x00120000-1.   And for XIP Kernel/FS builds, the following applies...   e.g. `mkimage --LAddr 00120020 romdisk.img romdisk.img.rr   which is used when the xconfig session has 0x00120020   value defined for BSPCONF_FILESYS_START.*/