LPC2368 gcc eclipse demo lpc2368ld error?

A question regarding Freertos version 4.6.1 and ARM7 gcc eclipse: In the lpc2368.ld the __bss_end__ is set to the beginning of ETH Ram. Is this correct? The boot.S file states that the bss region shall be cleared and with __bss_end__ set to to beginning of ETH RAM it tries to clear a lot of RAM? The bss region ranges from ~0x40000000 to 0x7FE00000 according to the lpc2368.ld file. I changed my lpc2368.ld so that __bss_end__ pointed to the end of the bss statement in the lpc2368.ld file. MEMORY {     flash    : ORIGIN = 0x00000000, LENGTH = 500K     ram    : ORIGIN = 0x40000000, LENGTH = 32K     usbram   : ORIGIN = 0x7FD00000, LENGTH = 8K     ethram   : ORIGIN = 0x7FE00000, LENGTH = 16K } __stack_end__ = 0x40000000 + 32K – 4; SECTIONS {     . = 0;     startup : { KEEP(*(.startup))} >flash     prog :     {         *(.text)         *(.rodata)         *(.rodata*)         *(.glue_7)         *(.glue_7t)     } >flash     __end_of_text__ = .;     .data :     {         __data_beg__ = .;         __data_beg_src__ = __end_of_text__;         *(.data)         __data_end__ = .;     } >ram AT>flash     .bss :     {         __bss_beg__ = .;         *(.bss)     } >ram             /* Align here to ensure that the .bss section occupies space up to     _end.  Align after .bss to ensure correct alignment even if the     .bss section disappears because there are no input sections.  */     . = ALIGN(32 / 8);     /*Better. */     _bss_end__ = . ; __bss_end__ = . ;     .usbram (NOLOAD):     {     __usbram_beg__ = .;     *(.dmaram)         __usbram_end__ = .;     } >usbram     .ethram (NOLOAD):     {     __ethram_beg__ = .;     *(.ethram)         __ethram_end__ = .;     } >ethram }     . = ALIGN(32 / 8);     _end = .; /*No correct    _bss_end__ = . ; __bss_end__ = . ; __end__ = . ;*/     __end__ = .;     PROVIDE (end = .); Is this a bug?

LPC2368 gcc eclipse demo lpc2368ld error?

To be honest I just copied this linker script from an existing example.  I think your change is fine, although I don’t think the original is a bug as such, just inefficient. Regards.