Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Memory view and addressable size 
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

Back to the top