Re: GDB/mapper cache problems

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It didn't work. (I had already tried it before I sent the last email.) It was 
fairly easy to whip up a custom bus passthrough device to do the translation. 
This seems like a good wish list item in the 'glue' category: A full featured 
configurable bus resizer. This should probably support endian swapping as 
well. I guess the mapper could be extended to support this, but it would 
require some complicated attribute setups. I got a little lost in the 
mapper's implementation when I looked at it.

I now have a reasonably full application running in simulation on two arm 
processors communicating via a shared ram. It runs at something like 100 
times real time, which is WAY better than the RTL simulations I was working 
with. It took about 6 days of total effort on my part, and I had to write 3 
or 4 custom devices to match our proprietary hardware, which I didn't find 
hard to do, but some more detailed docs on the short cuts available in all of 
the utility header files would have cut a day or two out of my effort.

One of those devices I implemented is a trap filter to cause one of the arm7's 
to more closely emulate the coprocessor instructions available on an arm9. It 
works by basically taking any illegal instruction trap and telling the 
processor to simply skip the instruction. Any other trap it passes to its 
downstream connection. So another wish list item for me is arm9 emulation.

On the whole, this is a pretty cool/useful project for me. It's unfortunate 
that the total population of people who would make use of something like this 
is probably pretty small. (Compared to other main stream projects like 
Mozilla or KDE.) Still the code base is pretty complete and useful in its 
current state.

Thanks for your help. I'll be submitting the amdcfi device I wrote as soon as 
I can prove that it works in all modes. (I only use it in 16 bit mode in our 
sim.)

Bob

On Tuesday 22 June 2004 09:47 pm, Frank Ch. Eigler wrote:
> Hi -
> 
> > The processor is an arm7t with a 32 bit bus. The flash is a 16 bit device. 
> > [...] In our actual hardware, we have a mapper that will read and 
> > register two 16 bit addresses on the flash and shift/concatenate them to 
form 
> > a single 32 bit word when the processor executes a 32 bit read. [...]
> 
> I don't recall exactly now, but it may be that the plain memory mapper
> component's optional stride/width syntax might specify exactly this.
> Append ",2,2" after your flash address-range string and see what bus
> API calls flow downstream.  (See siddoc hw-mapper-basic.)
> 
> 
> - FChE
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2hPA8XjOGQDr37YRAiv7AKCmgx5Se5PgEr1MSg01KfS+pwfm1gCeLpiQ
Ph12i1R//AVGJhWofPfG9yc=
=7+hz
-----END PGP SIGNATURE-----