public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: "Jon Beniston" <jon@beniston.com>
To: <gdb@sourceware.org>
Subject: Memory-mapped peripheral registers, remote protocol and memory maps
Date: Wed, 28 Nov 2012 19:24:00 -0000	[thread overview]
Message-ID: <004701cdcd9d$e487ff90$ad97feb0$@beniston.com> (raw)

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

             reply	other threads:[~2012-11-28 19:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-28 19:24 Jon Beniston [this message]
2012-11-29  9:16 ` Yao Qi
2012-11-29 11:23   ` Jon Beniston
2012-11-29 15:51     ` Yao Qi
2012-11-29 16:32   ` Jon Beniston
2012-11-29 17:23     ` Paul_Koning
2012-11-29 17:57       ` Jon Beniston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004701cdcd9d$e487ff90$ad97feb0$@beniston.com' \
    --to=jon@beniston.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).