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

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

Re: data memory mapping microblaze

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: data memory mapping microblaze al.basili@gmail.com (alb) - 2015-02-08 21:38 +0000
    Re: data memory mapping microblaze Tim Wescott <tim@seemywebsite.com> - 2015-02-08 18:35 -0600
      Re: data memory mapping microblaze al.basili@gmail.com (alb) - 2015-02-09 17:36 +0000
        Re: data memory mapping microblaze Tim Wescott <seemywebsite@myfooter.really> - 2015-02-09 13:42 -0600

#20013 — Re: data memory mapping microblaze

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

[toc] | [next] | [standalone]

#20017

On Sun, 08 Feb 2015 21:38:37 +0000, alb wrote:

> 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

This is a question for someone who's much more of a linker wonk than I am.

Have you tried Googling on "ld" and "Harvard architecture"?

-- 
www.wescottdesign.com

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

#20026

Hi Tim,

Tim Wescott <tim@seemywebsite.com> wrote:
[]
> This is a question for someone who's much more of a linker wonk than I am.
> 
> Have you tried Googling on "ld" and "Harvard architecture"?
> 

I did and I got some interesting hits on the AVR which is also Harvard:

[http://www.nongnu.org/avr-libc/user-manual/mem_sections.html#harvard_arch]
> Because of the Harvard architecture of the AVR devices, you must 
> manually add 0x800000 to the address you pass to the linker as the 
> start of the section. Otherwise, the linker thinks you want to put the 
> .noinit section into the .text section instead of .data/.bss and will 
> complain.

I'm not sure if this is all about it.

Another hit on a mailing list [1] reported the option -no-check-sections 
which allows to have .data and .text starting both at 0x0, but it would 
be too dangerous to silent this error and find yourself with two data 
sections overlapping.

There's another hit here [2] which might also be interesting but is more 
about having to do with putting .data section into flash.

And after some more search I believe this [3] does shed some light...not 
sure if enough!

Al

[1] http://sourceware.org/ml/binutils/2001-04/msg00366.html 
[2] http://www.embeddedrelated.com/groups/lpc2000/show/54079.php 
[3] http://www.atmel.com/webdoc/AVRLibcReferenceManual/pgmspace_1pgmspace_introduction.html

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

#20033

On Mon, 09 Feb 2015 17:36:25 +0000, alb wrote:

> Hi Tim,
> 
> Tim Wescott <tim@seemywebsite.com> wrote:
> []
>> This is a question for someone who's much more of a linker wonk than I
>> am.
>> 
>> Have you tried Googling on "ld" and "Harvard architecture"?
>> 
>> 
> I did and I got some interesting hits on the AVR which is also Harvard:
> 
> [http://www.nongnu.org/avr-libc/user-manual/
mem_sections.html#harvard_arch]
>> Because of the Harvard architecture of the AVR devices, you must
>> manually add 0x800000 to the address you pass to the linker as the
>> start of the section. Otherwise, the linker thinks you want to put the
>> .noinit section into the .text section instead of .data/.bss and will
>> complain.
> 
> I'm not sure if this is all about it.
> 
> Another hit on a mailing list [1] reported the option -no-check-sections
> which allows to have .data and .text starting both at 0x0, but it would
> be too dangerous to silent this error and find yourself with two data
> sections overlapping.
> 
> There's another hit here [2] which might also be interesting but is more
> about having to do with putting .data section into flash.
> 
> And after some more search I believe this [3] does shed some light...not
> sure if enough!
> 
> Al
> 
> [1] http://sourceware.org/ml/binutils/2001-04/msg00366.html [2]
> http://www.embeddedrelated.com/groups/lpc2000/show/54079.php [3]
> http://www.atmel.com/webdoc/AVRLibcReferenceManual/
pgmspace_1pgmspace_introduction.html

It might be worth it to figure out what is the right mailing list to get 
onto, subscribe, and then ask your question.

It'll probably be better to ask "Using ld for Harvard architectures", or 
"Using ld for two independent memory spaces" -- the reason that I ignored 
your original post was because I don't know, or care about, Microblaze.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[toc] | [prev] | [standalone]

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

csiph-web