GDB/mapper cache problems

[Robert Shideleff <bigbob@shideleff.com>]

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

Alright, I figured the gdb problem. I hadn't connected the gdb yield pins to 
the yield bus. gdb debugging now seems to work perfectly.

I think the second part of my problem where data doesn't seem to reliably make 
its way into the dual port ram is due to mapper cache. How can I cause a 
particular bus access to poke the yield net? I think that when a yield occurs 
the mapper flushes its cache, hence the proper behavior when I set the 
instruction counts to 1. (Is this correct?)

Bob

On Monday 21 June 2004 11:19 pm, Robert Shideleff wrote:
> I'll try it tomorrow.
> 
> In the mean time, I have also found that in order for the simulation to run
> sensibly and to use gdb properly, I have had to set the step count for both
> processors to 1. Does this make sense to you?
> 
> If I don't set the step count to 1, then I find the that gdb on the second
> processor will jump some large number of instructions for every step
> instruction command to gdb. The problems seem to extend to the hardware
> interaction as well. I haven't characterized this very well yet, but it 
seems
> like interactions between the processors is not getting tracked/handled
> correctly. Data going through the dual port RAM seems to get lost. Of course
> the real pain in the a** here is that it is probably not just a sim bug, but
> an interaction between a sim bug and my specific code. (My code runs on
> actual hardware correctly, so I am reasonably confident in it.)
> 
> As long as I keep both step sizes set at 1, everything seems to work more or
> less correctly up until it accesses a new AMD CFI flash component I have
> written. It fails here, but even the failure is a 'good' failure in that the
> processors reacted correctly to bogus flash. This is well past the first set
> of Dual Port RAM interactions, which seem to go correctly.
> 
> (I'll provide patches for the flash device once I get it working right.)
> 
> Bob
> 
> 
> On Monday 21 June 2004 10:46 pm, you wrote:
> > Hi -
> >
> > > [...]
> > > There is no core dump when it crashes.
> > > (gdb) run
> > > Starting program: /usr/local/bin/sid --board=basic --cpu=arm7t
> --board=basic --cpu=arm7t
> > > [...]
> >
> > You may have better luck with the crash diagnosis if you build
> > sid statically linked (configure with "--disable-shared").
> >
> >
> > - FChE
> >
> >
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2Fl48XjOGQDr37YRArNiAKCCgSktHx9hy2umxLZQpbeKsPr5eQCfTE6e
JuzHoCglubfvZD0/qVkEE1U=
=nFZ2
-----END PGP SIGNATURE-----