|
Message
From: Matjaz Breskvar<phoenix@o...>
Date: Fri May 13 23:11:27 CEST 2005
Subject: [openrisc] [or1ksim #85] [RFC] Overhoul memory code
* Gy?rgy 'nog' Jeney (nog@s...) wrote:
> > well yes, this is the Right Way (tm). probably ;)... i've got a funny feeling that
> > doing the Right Thing might break things... well i'll trust your judgment on
> > this one...
>
> I decided to do the Right Way (tm). We are in a development cycle so if it
> happens to break, we can always re-evaluate the Right Way (tm) or fix broken
> assumptions. It Works For Me (tm). I've attached an updated patch.
>
> [snip stuff about endianess]
> > this is what i had in mind.
>
> I'll stick this in some comment somewere in the sim, sometime.
>
> ChangeLog:
> * Seporate out the code used for handling the memory peripheral to
> peripheral/memory.c
> * Mostly decouple the memory controller from the internals of the memory
> handling.
> * Rewrite memory handling to be more linear and thus much faster.
> * Issue a bus error on read/write with invalid granularity.
i still don't understand the evalsim_mem* and setsim_mem* changes, in
particular the virtual address part. (my notation is: virtual == effective
address == [EA])
[EA] ---> [xMMU] ---> [Physical Addr] ---> [xCACHE] ---> [memory controler]
-----------------> [memory controler]
-----------------> [peripheral]
actually after the cache 'memory' access goes to wishbone bus, where some
device 'owns' that portion of the memory (like memory controler, some
peripheral). if nobody owns it you get (in priciple) bus error.
i always thought of evalsim_mem* functions as an abbstraction of you access
to the bus (and depending on the address, appropriate device generates
response). so you can see why i get confused when this function takes an
virtual address parameter...
about the endianness stuff i'm ok with it either way if it will end up
working in the end, and it woun't be a black magic to implement a new
peripheral...
best regards,
p.
|
 |
Browse
