* Multiple arm7t processors in pbb causes seg fault @ 2004-06-17 1:57 Robert Shideleff 2004-06-17 21:54 ` Frank Ch. Eigler [not found] ` <20040622024603.GB22793@redhat.com> 0 siblings, 2 replies; 7+ messages in thread From: Robert Shideleff @ 2004-06-17 1:57 UTC (permalink / raw) To: sid -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Multiple arm7t processors in pbb causes seg fault 2004-06-17 1:57 Multiple arm7t processors in pbb causes seg fault Robert Shideleff @ 2004-06-17 21:54 ` Frank Ch. Eigler [not found] ` <20040622024603.GB22793@redhat.com> 1 sibling, 0 replies; 7+ messages in thread From: Frank Ch. Eigler @ 2004-06-17 21:54 UTC (permalink / raw) To: Robert Shideleff; +Cc: sid [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <20040622024603.GB22793@redhat.com>]
[parent not found: <200406212319.30979.bigbob@shideleff.com>]
* GDB/mapper cache problems [not found] ` <200406212319.30979.bigbob@shideleff.com> @ 2004-06-22 16:08 ` Robert Shideleff 2004-06-22 16:23 ` Frank Ch. Eigler 0 siblings, 1 reply; 7+ messages in thread From: Robert Shideleff @ 2004-06-22 16:08 UTC (permalink / raw) To: Frank Ch. Eigler, sid -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB/mapper cache problems 2004-06-22 16:08 ` GDB/mapper cache problems Robert Shideleff @ 2004-06-22 16:23 ` Frank Ch. Eigler 2004-06-23 0:51 ` Robert Shideleff 0 siblings, 1 reply; 7+ messages in thread From: Frank Ch. Eigler @ 2004-06-22 16:23 UTC (permalink / raw) To: Robert Shideleff; +Cc: sid [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB/mapper cache problems 2004-06-22 16:23 ` Frank Ch. Eigler @ 2004-06-23 0:51 ` Robert Shideleff 2004-06-23 1:47 ` Frank Ch. Eigler 0 siblings, 1 reply; 7+ messages in thread From: Robert Shideleff @ 2004-06-23 0:51 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: sid -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB/mapper cache problems 2004-06-23 0:51 ` Robert Shideleff @ 2004-06-23 1:47 ` Frank Ch. Eigler 2004-06-23 23:35 ` Robert Shideleff 0 siblings, 1 reply; 7+ messages in thread From: Frank Ch. Eigler @ 2004-06-23 1:47 UTC (permalink / raw) To: Robert Shideleff; +Cc: sid [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GDB/mapper cache problems 2004-06-23 1:47 ` Frank Ch. Eigler @ 2004-06-23 23:35 ` Robert Shideleff 0 siblings, 0 replies; 7+ messages in thread From: Robert Shideleff @ 2004-06-23 23:35 UTC (permalink / raw) To: Frank Ch. Eigler; +Cc: sid -----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----- ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-06-23 23:35 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-06-17 1:57 Multiple arm7t processors in pbb causes seg fault Robert Shideleff 2004-06-17 21:54 ` Frank Ch. Eigler [not found] ` <20040622024603.GB22793@redhat.com> [not found] ` <200406212319.30979.bigbob@shideleff.com> 2004-06-22 16:08 ` GDB/mapper cache problems Robert Shideleff 2004-06-22 16:23 ` Frank Ch. Eigler 2004-06-23 0:51 ` Robert Shideleff 2004-06-23 1:47 ` Frank Ch. Eigler 2004-06-23 23:35 ` Robert Shideleff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).