ld.dm270.forupgrade.script

Embeded bootloader (rrload by ridgerun) for TI linux based platform v5.36

/* 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
{

  . = 0x02bc0000;
  btldr_start = .; /* required by btldr_pi.o */
	.init : {			/* Init code and data		*/
		stext = .;
    _stext = .;
		__init_begin = .;
			*(.text.init)
		__proc_info_begin = .;
			*(.proc.info)
		__proc_info_end = .;
		__arch_info_begin = .;
			*(.arch.info)
		__arch_info_end = .;
			*(.data.init)
		. = ALIGN(16);
		__setup_start = .;
			*(.setup.init)
		__setup_end = .;
		__initcall_start = .;
			*(.initcall.init)
		__initcall_end = .;
		. = ALIGN(4096);
		__init_end = .;
	}

	/DISCARD/ : {			/* Exit code and data		*/
		*(.text.exit)
		*(.data.exit)
		*(.exitcall.exit)
	}

	.text : {			/* Real text segment		*/
		_text = .;		/* Text and read-only data	*/
			*(.text)
			*(.fixup)
			*(.gnu.warning)
			*(.text.lock)	/* out-of-line lock text */
			*(.rodata)
			*(.kstrtab)

  __KernCommandLineMagicStr = .; /* magic pattern string == "kcmdline-->" */
  . = . + 0xC;                   /* advance to .+strlen("kcmdline-->")+1 */
  __KernCommandLineOverride = .; /* location of kernel command line string */

  . = . + 0xD4;
  __EtherMACMagicStr = .;        /* magic pattern string == "etherMAC-->" */
  . = . + 0xC;                   /* advance to .+strlen("etherMAC-->")+1 */
  __EtherMAC = .;
  . = . + 0x20;                  /* leave room for the mac address */


		. = ALIGN(16);
		__start___ex_table = .;	/* Exception table		*/
			*(__ex_table)
		__stop___ex_table = .;

		__start___ksymtab = .;	/* Kernel symbol table		*/
			*(__ksymtab)
		__stop___ksymtab = .;

		*(.got)			/* Global offset table		*/

		_etext = .;		/* End of text section		*/
    etext = .;
	}

  __RONLY_end = ABSOLUTE(.); /* Please See Appendix A */

	. = ALIGN(8192);
  . = ALIGN(8192);
	.data : {
     __data_start = ABSOLUTE(.);	/* DATA */
		/*
		 * first, the init task union, aligned
		 * to an 8192 byte boundary.
		 */
		*(.init.task)

		/*
		 * then the cacheline aligned data
		 */
		. = ALIGN(32);
		*(.data.cacheline_aligned)

		/*
		 * and the usual data section
		 */
		*(.data)
		CONSTRUCTORS

		__data_end = ABSOLUTE(.);
		_edata = .;
	}
 btldr_end = .; /* required by btldr_pi.o */
	.bss : {
		. = ALIGN(32);    /* for SDRAM burst mode use */
		__bss_start = .;	/* BSS				*/
		*(.bss)
		*(COMMON)
  	. = ALIGN(0x1000);
		_end = . ;
	}

  __BSSSEG_end = ABSOLUTE(.); /* Please See Appendix A */


					/* Stabs debugging sections.	*/
	.stab 0 : { *(.stab) }
	.stabstr 0 : { *(.stabstr) }
	.stab.excl 0 : { *(.stab.excl) }
	.stab.exclstr 0 : { *(.stab.exclstr) }
	.stab.index 0 : { *(.stab.index) }
	.stab.indexstr 0 : { *(.stab.indexstr) }
	.comment 0 : { *(.comment) }

 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.
*/