C K Lui wrote:
> error: no memory region specified for loadable section `.ramfunc'
Are there entries for .ramfunc c-sections in the linker-script?

Martin Thomas wrote:
> C K Lui wrote:
>> error: no memory region specified for loadable section `.ramfunc'
> Are there entries for .ramfunc c-sections in the linker-script?

I cannot find any .ramfunc in the linker-script. How do I add it into
the script?

C K Lui wrote:
> Martin Thomas wrote:
>> C K Lui wrote:
>>> error: no memory region specified for loadable section `.ramfunc'
>> Are there entries for .ramfunc c-sections in the linker-script?
>
> I cannot find any .ramfunc in the linker-script. How do I add it into
> the script?

Add a line *(.ramfunc*) near *(.data)

Martin Thomas wrote:
> C K Lui wrote:
>> Martin Thomas wrote:
>>> C K Lui wrote:
>>>> error: no memory region specified for loadable section `.ramfunc'
>>> Are there entries for .ramfunc c-sections in the linker-script?
>>
>> I cannot find any .ramfunc in the linker-script. How do I add it into
>> the script?
>
> Add a line *(.ramfunc*) near *(.data)

I made the change as below and the linker works. Thanks.

  .data :
  {
    PROVIDE (__data_start = .);
    *(.data)
  *(.data.*)
    *(.gnu.linkonce.d*)
  SORT(CONSTRUCTORS) /* this entry is in the Anglia example */
    /* CONSTRUCTORS */ /* this entry is in the devkitarm script but not
in the Anglia example */
    . = ALIGN(4);
  *(.ramfunc*)

snip wrote:

Please note that this thread is rather old and somehow closed by the OP 
with "works".

> looks like you are adding the ramfunc to data!

You seem to confuse input-section(s) for data and the output-section 
data.

> You should create a separate section for it and locate it in the RAM,

The output-section .data gets located in RAM (there is not much sense in 
locating data in a RO-memory).

This method saves an additional copy-loop since the initial values of 
the data-input-sections get copied anyway in the startup. The 
machine-code of the RAM-functions can be copied in the same loop from 
the non-volatile memory into RAM.

> otherwise there is no point in using that attribute.

So far it's a little difficult to find the point in the remark.

> Also, you placed it before the .ALIGN part.

In the above code-snippet the line for ramfunc input-section(s) is after 
the align-instruction.

> This means that your data
> section is no longer aligned on a 32bit boundary. This can be dangerous.
> At least add a ". = ALIGN(4);" afterwards as well.

Yes, alignment can be critical but the linker and compiler "know" some 
restictions (AFAIK, I have done just a few tests). Since the lines above 
do not show a complete linker-script it's impossible to tell if an 
alignment instruction follows. Maybe it's in the next line not shown or 
maybe the defintion of output-section .bss with an extra aligment 
follows.