Forums

MicroBlaze program memory vs data memory

Started by Unknown February 5, 2015
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
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.
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