Memory-mapped peripheral registers, remote protocol and memory maps

Memory-mapped peripheral registers, remote protocol and memory maps

[Jon Beniston]

Hi,

How is the access of memory-mapped peripheral registers handled over the
remote protocol? By this, I mean how can you force a 32-bit read/write,
rather than 4 byte accesses, to read/write a 32-bit memory-mapper register?

I can see that you can define memory regions with the mem command, and set
the memory access size to 32, but how does this map over the remote
protocol?   The remote protocol documentation for the 'm' packet says: "The
stub need not use any particular size or alignment when gathering data from
memory for the response; even if addr is word-aligned and length is a
multiple of the word size, the stub is free to use byte accesses, or not.
For this reason, this packet may not be suitable for accessing memory-mapped
I/O devices.". Is there another packet that is suitable? It doesn't look
like the code in remote.c uses this attribute.

Also, in the documentation of the memory map format, it seems the only
memory types are ram, rom and flash, with the only property being blocksize.
Should there not be additional properties to correspond to the attributes
supported by the mem command (i.e. an access size property)?

Cheers,
Jon

Re: Memory-mapped peripheral registers, remote protocol and memory maps

[Yao Qi]

On 11/29/2012 03:23 AM, Jon Beniston wrote:
> How is the access of memory-mapped peripheral registers handled over the
> remote protocol? By this, I mean how can you force a 32-bit read/write,
> rather than 4 byte accesses, to read/write a 32-bit memory-mapper register?
>
> I can see that you can define memory regions with the mem command, and set
> the memory access size to 32, but how does this map over the remote
> protocol?   The remote protocol documentation for the 'm' packet says: "The
> stub need not use any particular size or alignment when gathering data from
> memory for the response; even if addr is word-aligned and length is a
> multiple of the word size, the stub is free to use byte accesses, or not.
> For this reason, this packet may not be suitable for accessing memory-mapped
> I/O devices.". Is there another packet that is suitable? It doesn't look
> like the code in remote.c uses this attribute.

I don't understand your problem.  Anything wrong when you use 'm' packet 
to read the content of memory-mapped register?  Supposing a 32-bit 
register is mapped at address 0x00d000, packet 'm 0x0x00d000 4' should 
be able read the contents of this register.  Your stub should know where 
each register is mapped, and when gets a 'm' packet, get the content of 
register by some way, and reply it to GDB.  In this way, the 
memory-mapped registers are transparent to GDB, and user has to access 
them via address.

-- 
Yao (齐尧)

RE: Memory-mapped peripheral registers, remote protocol and memory maps

[Jon Beniston]

Hi Yao,

> I don't understand your problem.  Anything wrong when you use 'm' packet
> to read the content of memory-mapped register?  Supposing a 32-bit register
> is mapped at address 0x00d000, packet 'm 0x0x00d000 4' should be able read
> the contents of this register.  Your stub should know where each register is
> mapped, and when gets a 'm' packet, get the content of register by some
> way, and reply it to GDB.  In this way, the memory-mapped registers are
> transparent to GDB, and user has to access them via address.

In some cases, there might be a large variety of inter-mixed 8/16/32-bit registers, which you might not have the space to cater for in a small stub. Can we be sure that GDB will only generate a 'm 0x0x00d000 4' packet? It would be tricky for a stub to deal with a packet of a larger size (say if the register area is opened in a memory viewer). Also, it would be nice to prevent reads from certain addresses, in case they have side effects (i.e FIFOs, etc).

I would have thought it would be better to have this logic in GDB, rather than each stub, given that it already has the relevant commands.

Cheers,
Jon

Re: Memory-mapped peripheral registers, remote protocol and memory maps

[Yao Qi]

On 11/29/2012 07:22 PM, Jon Beniston wrote:
> In some cases, there might be a large variety of inter-mixed
> 8/16/32-bit registers, which you might not have the space to cater
> for in a small stub. Can we be sure that GDB will only generate a 'm
> 0x0x00d000 4' packet? It would be tricky for a stub to deal with a

The following command 'p' will only generate 'm' packet with the right size.

(gdb) p *(unsigned int *) 0x8048608
Sending packet: $m8048608,4#3f...Packet received: 5589e583

(gdb) p *(char *) 0x8048608
Sending packet: $m8048608,1#3c...Packet received: 55

I admit they are tricky.

> packet of a larger size (say if the register area is opened in a
> memory viewer). Also, it would be nice to prevent reads from certain
> addresses, in case they have side effects (i.e FIFOs, etc).
>

Something similar was done in codesourcery (by other people) to handle 
memory-mapped register and side effect of reading registers (we call it 
read sensitiveness, IIRC).  The target description mechanism
(http://sourceware.org/gdb/current/onlinedocs/gdb/Target-Descriptions.html) 
was enhanced, in which the name, width, mapped address and read 
sensitiveness of each register is described.  With these knowledge, GDB 
can take care of memory-mapped register.  However, these patches didn't 
go to upstream.

-- 
Yao (齐尧)

RE: Memory-mapped peripheral registers, remote protocol and memory maps

[Jon Beniston]

> The following command 'p' will only generate 'm' packet with the right size.
> 
> (gdb) p *(unsigned int *) 0x8048608
> Sending packet: $m8048608,4#3f...Packet received: 5589e583
> 
> 
> (gdb) p *(char *) 0x8048608
> Sending packet: $m8048608,1#3c...Packet received: 55
> 
> I admit they are tricky.

Yes, this is fine from the command line, but ideally I would like something that works when GDB is being driven by a GUI such as Eclipse, which may not necessarily know the correct size to use. It does work in some cases, but not all (i.e. when dumping memory).

Thanks for the pointer, I'll see if I can find the patches you mention.

Cheers,
Jon

Re: Memory-mapped peripheral registers, remote protocol and memory maps

[Paul_Koning]

On Nov 29, 2012, at 11:31 AM, Jon Beniston wrote:

>> The following command 'p' will only generate 'm' packet with the right size.
>> 
>> (gdb) p *(unsigned int *) 0x8048608
>> Sending packet: $m8048608,4#3f...Packet received: 5589e583
>> 
>> 
>> (gdb) p *(char *) 0x8048608
>> Sending packet: $m8048608,1#3c...Packet received: 55
>> 
>> I admit they are tricky.
> 
> Yes, this is fine from the command line, but ideally I would like something that works when GDB is being driven by a GUI such as Eclipse, which may not necessarily know the correct size to use. It does work in some cases, but not all (i.e. when dumping memory).

If so, that would be the GUI's issue.  If GDB can be told what to do -- which appears to be the case -- then it's up to whoever does the telling to tell correctly.  If GDB can do it but you ask it the wrong thing, it will obey and do the wrong thing.  So don't do that.

What's not clear to me is whether there is a *guarantee* that certain UI requests will produce certain "m" packets.  Clearly there are a bunch of things that fall out of the current implementation, but if somehow the implementation were to change and, say, that "p" command above is split into two m packets, what then?  By the current remote protocol specification, such a change would be legal.  Not terribly rational perhaps, but legal.

For reliable access to memory mapped device registers, you'd need to have a guarantee.  For example: "A request for 1, 2, 4, or 8 bytes with a p or x command, where the memory address is naturally aligned, will always become a single remote protocol memory read of that same size.  For other transfer sizes and alignments, the request may or may not be split into pieces, and the behavior for those is subject to change."

Clearly you can propose any number of rules, but for starters you'd need a documented rule so that users know what they can count on and implementers know what they are required to preserve.

	paul

RE: Memory-mapped peripheral registers, remote protocol and memory maps

[Jon Beniston]

Hi Paul,

> > Yes, this is fine from the command line, but ideally I would like
something
> that works when GDB is being driven by a GUI such as Eclipse, which may
not
> necessarily know the correct size to use. It does work in some cases, but
not
> all (i.e. when dumping memory).
> 
> If so, that would be the GUI's issue.  If GDB can be told what to do --
which
> appears to be the case -- then it's up to whoever does the telling to tell
> correctly.  If GDB can do it but you ask it the wrong thing, it will obey
and do
> the wrong thing.  So don't do that.

It doesn't seem like the right approach to me to require each GDB GUI (or
user) to have detailed knowledge of the target h/w. Wouldn't it be better if
this info came from the target, in the same way the memory map or target
description does?  GDB already has the hooks to deal with this (via the mem
command), it's just a case of how to best get that info and then actually
make use of it. 

I don't think it would make sense to propagate this target information to
the GUI to require it to only generate correct commands, otherwise you are
requiring the problem to be solved in each GUI, rather than just in one
place in GDB.

> What's not clear to me is whether there is a *guarantee* that 
> certain UI requests will produce certain "m" packets.  Clearly 
> there are a bunch of things that fall out of the current implementation,
>  but if somehow the implementation were to change and,
>  say, that "p" command above is split into two m packets, what then?  

Well, I would expect that any command should respect the attributes set via
the 'mem' command, if it doesn't, it's a bug, if it can't, it should
generate an error message?

Cheers,
Jon