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

Groups > comp.arch.fpga > #7483

Re: data memory mapping microblaze

Cross-posted to 2 groups.

Followups directed to: comp.arch.embedded

Show all headers | View raw

Hi Tim,

Tim Wescott <seemywebsite@myfooter.really> wrote:
[]
>> I'm using a mb-gcc and I've looked to the ld refernce, but how can you
>> specify that a set of registers need to go to the data memory to a
>> specific address? Or is it implicitely assumed that .data segments
>>  would go to a 'data memory'?
>> 
> Sorry I missed this on c.a.e.  In fact, I'm cross-posting 

I'm doing it for you, since I believe c.a.e. is more appropriate. It's 
kind of funny the thread picked up more momentum here than there.

> Am I correct that all you need to do is to read/write from a register or 
> set thereof, which is mapped to a specific location in the processor's 
> memory space?

Not really. Being able to map registers into a specific location is an 
important thing, but here the subject is a bit different.

On an Harvard Architecture data memory and program memory are simply two 
different worlds. They can both start at location 0x00000000, but I 
didn't find a way to say that to the linker without getting a 
'memory/section overlap'.

> In that case, there are a number of things you can do.  Doing a Google 
> search of "memory mapped registers in C" is a good start.  If you find 
> something by Michael Barr or Jack Gansle -- believe it, even if I 
> contradict it below.

I knew Ganssle from 'The Art of Embedded Systems Designs', a must, but I 
wasn't aware about Barr, I'll definitely have a look at his advices.

> I'm going to assume that these memory-mapped registers are not part of the 
> "real" data memory -- e.g., if the real data memory runs from 0x00000000 
> to 0x00007ffff, then you won't find the registers there.

Actually I need to map the 'real memory', memory mapped registers are 
just the second in line, but they should follow the same 'reasoning'.

I have a data memory space and I want to place it at address 0, but it 
ain't working (section overlap). One thing I thought about was tricking 
the linker into thinking that pm and dm are in different locations but 
since I do not need 32bit address for my embedded system I can say 
0x00000000 for pm and 0x80000000 for my dm. Say only 20bit for the dm 
address are used, I can safely say that my dm really starts from 
physical address 0. But is that really ortodox? It sounds a nasty 
workaround to me.

> The thoroughly C way to do this, without really demanding much "gnu-ness", 
> is to declare your registers something like:
> 
> #define REGISTER_0 (*((volatile int32_t *)(0x00010000)))
> #define REGISTER_1 (*((volatile int32_t *)(0x00010004)))
> 
> Etc.  Then you use REGISTER_0, REGISTER_1 as if they were integers.
> 
> The way I do this, which is probably wrong on many levels, is to define 
> the register addresses directly in a linker script:
> 
> TIM2      = 0x40000000;
> TIM3      = 0x40000400;
> 
> (This is for an ST STM32F303)
> 
> Then in the code I have these long structure definitions that match the 
> stackup of the registers in the pertinent register sets, and the header 
> files end with something like:
> 
> extern volatile SGenTimer1Regs  TIM2;
> extern volatile SGenTimer1Regs  TIM3;

Interesting, but how do you make sure you don't incur into memory 
overlaps? I used to have some sort of BASEADDRESS and refer all 
addressing w.r.t. it:

#define REGISTER_0 (*((volatile int32_t *)(BASEADDRESS + 0x00000000)))
#define REGISTER_1 (*((volatile int32_t *)(BASEADDRESS + 0x00000004)))

still there's high risk that you may fall into temptetion to change the 
type without readjusting the address location.
An alternative might be doing something like:

#define REGISTER_0 (*((volatile int32_t *)(BASEADDRESS + 0*sizeof(int32_t))))
#define REGISTER_1 (*((volatile int32_t *)(BASEADDRESS + 1*sizeof(int32_t))))

but again you need to be rigourous, should a change in type occourr, to 
change both the type and the address.

Anyway, this is off topic since I'm not able to specify the dm address 
for .data section and others.

Al

Back to comp.arch.fpga | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

data memory mapping microblaze alb <al.basili@gmail.com> - 2015-02-07 07:17 +0100
  Re: data memory mapping microblaze Brian Drummond <brian@shapes.demon.co.uk> - 2015-02-07 10:54 +0000
    Re: data memory mapping microblaze al.basili@gmail.com (alb) - 2015-02-08 20:42 +0000
  Re: data memory mapping microblaze Tim Wescott <seemywebsite@myfooter.really> - 2015-02-07 19:16 -0600
    Re: data memory mapping microblaze Tim Wescott <seemywebsite@myfooter.really> - 2015-02-07 19:21 -0600
    Re: data memory mapping microblaze al.basili@gmail.com (alb) - 2015-02-08 21:38 +0000

csiph-web