The older gnuarm in the windows toolchain seems to need the glue_7t section

[proxmark3-svn] / bootrom / ldscript-flash

MEMORY \r
{\r
	/* AT91SAM7S256 has 256k Flash and 64k RAM */\r
	/* Important note: the correct ORIGIN for bootphase1 is 0x00100000 and for bootphase2 is 0x00100200\r
	   However, this will confuse the currently deployed flash code which expects logical and and not\r
	   physical addresses and performs no sanity checks at all. If confronted with physical addresses, \r
	   it will happily erase everything and brick the device. So for the time being pretend these addresses\r
	   to start at 0x0 while updating all the flash code with proper sanity checks, then come back later and\r
	   fix the addresses. -- Henryk Plötz <henryk@ploetzli.ch> 2009-08-27 */\r
        bootphase1 : ORIGIN = 0x00000000, LENGTH = 0x200 /* Phase 1 bootloader: Copies real bootloader to RAM */\r
        bootphase2 : ORIGIN = 0x00000200, LENGTH = 0x2000 - 0x200 /* Main bootloader code, stored in Flash, executed from RAM */\r
        ram     : ORIGIN = 0x00200000, LENGTH = 64K\r
}\r
\r
\r
SECTIONS\r
{\r
    . = 0;\r
    \r
    bootphase1 : {\r
    	*(.startup) \r
    	*(.bootphase1)\r
    } >bootphase1\r
    \r
    bootphase2 : {\r
    	__bootphase2_start__ = .;\r
    	*(.startphase2)\r
    	*(.text)\r
    	*(.glue_7)\r
    	*(.glue_7t)\r
    	*(.rodata)\r
        *(.data)\r
    	. = ALIGN( 32 / 8 );\r
    	__bootphase2_end__ = .;\r
    } >ram AT>bootphase2\r
    \r
    .bss : {\r
    	__bss_start__ = .; \r
    	*(.bss)\r
    } >ram\r
    \r
    . = ALIGN( 32 / 8 );\r
    __bss_end__ = .;\r
}\r