Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #20008 > unrolled thread

MicroBlaze program memory vs data memory

Back to article view | Back to comp.arch.embedded

Contents

  MicroBlaze program memory vs data memory charles.ingels@syderal.ch - 2015-02-05 01:04 -0800
    Re: MicroBlaze program memory vs data memory Richard Damon <Richard@Damon-Family.org> - 2015-02-11 23:20 -0500
      Re: MicroBlaze program memory vs data memory al.basili@gmail.com (alb) - 2015-02-12 07:36 +0000

#20008 — MicroBlaze program memory vs data memory

Hi everyone,

I am currently writing a linker script to build my final executable to fit into the memory space visible from within the MB. Since that CPU is an Harvard architecture based, program memory and data memory are separated. 
This means that I have instructions at address 0 of the program memory, and a data at the same address but in data memory.
If I try to force the .data section in the linkes script at address 0, the linker complains with an overlap error.
How can I modify my linker script to reflect the fact that I have two separated memory area, one for the program and another for the data ?

Currently, if I do not specify particular requirements in the linker script, the linker places the .data section just after the .text section. Do I have to take care the the data section address or is there any kind of "internal address translation" when an instruction (taken from the program memory) accesses to the data memory for which I do not have to take care ?

Are there specific directives I have to insert into my linker script to specify the type of memory (program vs data) ?

Thanks in advance for your answers !

Charles

[toc] | [next] | [standalone]

#20064

On 2/5/15 4:04 AM, charles.ingels@syderal.ch wrote:
> Hi everyone,
>
> I am currently writing a linker script to build my final executable
> to fit into the memory space visible from within the MB. Since that
> CPU is an Harvard architecture based, program memory and data memory
> are separated. This means that I have instructions at address 0 of
> the program memory, and a data at the same address but in data
> memory. If I try to force the .data section in the linkes script at
> address 0, the linker complains with an overlap error. How can I
> modify my linker script to reflect the fact that I have two separated
> memory area, one for the program and another for the data ?
>
> Currently, if I do not specify particular requirements in the linker
> script, the linker places the .data section just after the .text
> section. Do I have to take care the the data section address or is
> there any kind of "internal address translation" when an instruction
> (taken from the program memory) accesses to the data memory for which
> I do not have to take care ?
>
> Are there specific directives I have to insert into my linker script
> to specify the type of memory (program vs data) ?
>
> Thanks in advance for your answers !
>
> Charles
>

I haven't used this particular processor so these are mostly general
comments.

First, if you are just specifying addresses without some qualifier for 
which address space, and the linker is accepting them, then the linker 
isn't working in "Harvard" mode. You will need to read the Fine 
documentation to see how (if it is possible) to use it in a "Harvard" mode.

A Harvard architecture linker will need to have addresses somehow 
modified by being code or data space.

The issue might be that even though the processor uses a Harvard 
architecture, it is commonly used (and the tools thus configured) in a 
mode combining the two address spaces to make it more like "traditional" 
processors. In this configuration, you can't have data and code at the 
same address space.

[toc] | [prev] | [next] | [standalone]

#20065

Hi Richard,

Richard Damon <Richard@damon-family.org> wrote:
[]
> First, if you are just specifying addresses without some qualifier for 
> which address space, and the linker is accepting them, then the linker 
> isn't working in "Harvard" mode. You will need to read the Fine 
> documentation to see how (if it is possible) to use it in a "Harvard" mode.

The docs do not seem to refer in anyway to a 'Harvard' architecture. The 
microblaze uses gcc and AFAIK the same issue appears on AVRs where the 
toolchain takes care about 'adding' an offset for data memory in order 
not to overlap instruction and data memory.

> A Harvard architecture linker will need to have addresses somehow 
> modified by being code or data space.

IMO the OP would be better off defining an offset which is beyond the 
address space handled by the hardware. Let's say the hardware handles 
20bit address for both instructions and data, it would be sufficient to 
specify the ORIGIN for the data memory to 0x100000 to fool the linker 
into thinking that there's only one address space, yet have the data 
memory aligned at 0x00000 (only 20 LSB considered).

> The issue might be that even though the processor uses a Harvard 
> architecture, it is commonly used (and the tools thus configured) in a 
> mode combining the two address spaces to make it more like "traditional" 
> processors. In this configuration, you can't have data and code at the 
> same address space.

Another possibility would be to disable the check for overlapping 
sections, but I would not recommend that approach.

Al

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web