[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] Memory view and addressable size
|
Hi John,
Thanks for the clarifications. I have opened the following enhancement
request to track this requirement.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=150517
Samantha
John Cortell
<john.cortell@fre
escale.com> To
Sent by: Device Debugging developer
dsdp-dd-dev-bounc discussions
es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>, Device
Debugging developer discussions
<dsdp-dd-dev@xxxxxxxxxxx>
06/22/2006 08:24 cc
AM
Subject
Re: [dsdp-dd-dev] Memory view and
Please respond to addressable size
Device Debugging
developer
discussions
<dsdp-dd-dev@ecli
pse.org>
Samantha,
See comments inline...
At 10:12 PM 6/21/2006, Samantha Chan wrote:
>Hi John -
>
>I am curious about how the user knows what the correct addressable size is
>when reading memory from different locations?
>Is there some sort of spec that the user knows about? Or is it something
>provided by the back-end on the fly?
The user would have to know about it--he's either familiar with MMRs
at that location or he's looked it up in a spec.
>To make sure that I understand this correctly, the reason why the
Registers
>View knows how to do the "right" thing is because the Registers View knows
>the type of data that it is showing and knows how to read the data
>correctly.
Yes.
> For the Memory View, it's just a big chunk of memory, and there
>is no way for the view / back-end to know how to read that memory because
>we no longer have that information?
Well, the backend still has the information. In many cases, that's
enough. E.g., if the memory configuration file says memory in the
range of 0x5000-0x51000 *must* be read in 16 bit chunks, then the
backend can take care to read that memory 16 bits at a time. But the
problem is that it's not always that simple. There can be spots in
memory where it's valid to read in more than one way, but the
different ways don't necessarily provide the same results. In the
context of an MMR definition (what the registers view would show),
there isn't that ambiguity; in the context of simply viewing memory, there
is.
> As a result, we need to provide some
>ways for the user to specify the size of the addressable units?
I recommend we not use the word "addressable" because that rings of
addressable-size, which is a slightly different concept. I recommend
we consider this notion "accessible-size" with the following
definition: the granularity in which the backend accesses memory; if
represented in bytes, it is some multiple of the addressable size.
However, to avoid the possibility of conflicting settings, the
accessible size shouldn't be represented in bytes, but as a "number
of addressable units". For example, it wouldn't make sense to have an
addressable size of 4 bytes and an access size of 6 bytes.
So, you could have an addressable size of 1, but an access size of 2.
These settings would say that address 0x5000 represents 8 bits and
0x5001 represents the next 8 bits. However, when reading memory from
the target, all 16 bits should be read in one operation.
If you had an addressable size of 2 and an access size of 2, then
0x5000 represents 16 bits and 0x5001 represents the next 16 bits.
However, when reading memory from the target, all 32 bits should be
read in one operation.
Addressable size is not something the user would control, access size
is...for the memory view.
To those with experience with these memory configurations: does this
description/explanation make sense?
>Also, users
>can look at the same memory with different addressable unit size
>specifications and they would get different results?
Access size, and yes these scenarios exist. Our current non-Eclipse
product supports this level of control in the memory view. When the
user changes the access size, the memory is re-read.
>Is it correct to say that you need support for a memory block that has
>variable addressable size?
Yes; variable access size.
>Thanks...
>Samantha
>
>
>
>
> John Cortell
> <john.cortell@fre
> escale.com>
To
> Sent by: Device Debugging developer
> dsdp-dd-dev-bounc discussions
> es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>,
> dsdp-dd-dev@xxxxxxxxxxx
>
cc
> 06/21/2006 05:42
> PM
Subject
> Re: [dsdp-dd-dev] Memory view and
> addressable size
> Please respond to
> Device Debugging
> developer
> discussions
> <dsdp-dd-dev@ecli
> pse.org>
>
>
>
>
>
>
>At 04:37 PM 6/21/2006, Daniel Jacobowitz wrote:
> >On Wed, Jun 21, 2006 at 04:16:29PM -0500, John Cortell wrote:
> > > At 03:42 PM 6/21/2006, Daniel Jacobowitz wrote:
> > > >OK, that's what I had in mind and was interested in. I still think
we
> > > >could do this without user interface for it (by providing those two
as
> > > >"different" memory mapped registers, and the memory mapped register
> > > >description indicating the access width), but that's much weaker
than
> > > >"there's always one right answer".
> > >
> > > That's fine for a register view, but it doesn't apply to the memory
> > > view, right?
> >
> >I would speculate that if you have a memory view window pointed at a
> >bank of MMIO registers, you may already be in bad straits. A
> >significant portion of MMIO registers are active on read.
>
>Well, yes, but MMIO is just one type of MMR.
>
>BTW, the context for my inquiry was strictly the memory view
>window. For other views (registers), I believe the debugger backed
>can just "do the right thing" based memory configuration and register
>description files.
>
>John
>
>_______________________________________________
>dsdp-dd-dev mailing list
>dsdp-dd-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>
>
>_______________________________________________
>dsdp-dd-dev mailing list
>dsdp-dd-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
