LPC2368 gcc eclipse demo lpc2368ld error?

geah wrote on Wednesday, December 12, 2007:

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?

rtel wrote on Tuesday, December 18, 2007:

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.