Multiple arm7t processors in pbb causes seg fault

Multiple arm7t processors in pbb causes seg fault

[Robert Shideleff]

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

I am currently trying to set up a simulation using two arm7t processors
communicating via dual port ram, simulated by a single port ram mapped onto
both processors. I have found that the sim works relatively well when either
or both processors are in scache mode, but that the entire thing segfaults
when both are in pbb mode. This seems to be true no matter what the
configuration. It even happens if I use no configuration files and call sid
with the following options:

sid --board=basic --cpu=arm7t --board=basic --cpu=arm7t

I am using the current anonymous cvs as of a week ago.

Thanks,
	Bob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0Ppl8XjOGQDr37YRAocOAJ9zW+NZz7+qHKiVsx6QRBGXbeoRHQCdGYaI
tWZmpR1MtDG9fQlp9djOroM=
=PDFL
-----END PGP SIGNATURE-----

Re: Multiple arm7t processors in pbb causes seg fault

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Hi, Robert -

On Wed, Jun 16, 2004 at 09:56:53PM -0400, Robert Shideleff wrote:
> I am currently trying to set up a simulation using two arm7t processors
> communicating via dual port ram [...]

I'm glad you're finding it not hard to use sid in this way.

> [crash in pbb]

This doesn't sound familiar.  Would you mind trying to run the sid
binary under a debugger, and collecting a backtrace upon the crash?

- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

GDB/mapper cache problems

[Robert Shideleff]

-----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-----

Re: GDB/mapper cache problems

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

Hi -


> 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.

OK.  I believe that the C++ sid configuration engine in sid/main/dynamic
is not well customized yet for the arm family of targets, so you may
encounter a few such problems.

Regarding interleaving the processors, what you are seeing intentional.
The CPU models are parametrized to allow you to trade off speed versus
accuracy.  (Executing N instructions in one CPU before switching context
to the rest of the sim can be significantly faster.)


> 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. 

The mapper cache probably does not relate to this - you probably mean
something other than the little internal TLB in the memory-mapper
component that helps classify incoming read/write addresses.


> How can I cause a particular bus access to poke the yield net? [...]

For example, you could use the hw-glue-bus-probe component: wire up one
instance of it into the bus structure by mapping it at some address;
use its pin outputs to trigger any desired pin-based event in the simulator.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: GDB/mapper cache problems

[Robert Shideleff]

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

> For example, you could use the hw-glue-bus-probe component: wire up one
> instance of it into the bus structure by mapping it at some address;
> use its pin outputs to trigger any desired pin-based event in the simulator.

This worked great for me, and I got my amdcfi component to more or less work, 
but have one more hurdle to overcome:

The processor is an arm7t with a 32 bit bus. The flash is a 16 bit device. 
(The component can also be an 8 bit device, but I don't need this 
particularly.) 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. (This allows 
us to execute non-thumb instructions out of flash for example.) I haven't yet 
found a way to make the SID mapper do this. Is this currently possible? Am I 
looking in the wrong place? Am I going to have to do some re-writing?

Bob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA2NPu8XjOGQDr37YRAvXWAKCf9HEMDgWQ6TBAd/BblsIATzqO3QCfVD8R
D6CqwMAHAIaaYC46E/mNTGQ=
=UuG9
-----END PGP SIGNATURE-----

Re: GDB/mapper cache problems

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: GDB/mapper cache problems

[Robert Shideleff]

-----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-----