5 Replies Latest reply on Jul 11, 2011 10:19 AM by tedk

    Shared memory TTY "device"?

    mziwisky

      I've seen posts and documents around here casually mentioning the following shared memory allocations:

       

      SHM TTY1 & Perfmeter 8000 0000 - 8018 0FFF (1540KB @ 0MB)

      SHM TTY2 8100 0000 - 8118 0FFF (1540KB @ 0MB)

      SHM TTY3 8200 0000 - 8218 0FFF (1540KB @ 0MB)

      SHM TTY4 8300 0000 - 8318 0FFF (1540KB @ 0MB)

       

      What are those TTY regions actually for?  Is there some sort of "device" on the MCPC which makes these memory regions look like TTY devices?  If so, how are they written and read from both the MCPC and the SCC?  Any references to source files in SCC Linux and/or MCPC software?

        • 1. Re: Shared memory TTY "device"?
          tedk

          We were cautioned to skip over them when we started to use shared memory.  All I know about them is probably what you have already read ... that they are used by system services such as the "on-die network driver that allows TCP traffic from core to core."

           

          I've grep'ed thorugh the src for SHM and TTY and don't see anything obvious.  What were you hoping to use them for?

          • 2. Re: Shared memory TTY "device"?
            mziwisky

            I'm porting the Xinu operating system to the SCC.  So far, my scheme for outputting from the SCC to the MCPC is this: SCC Xinu writes to a ring buffer in shared memory and updates the head index.  The MCPC runs a script that uses sccDump to check the head and tail indeces, and when they're different, it uses sccDump to get the characters and print them to the console.  Then it uses sccWrite to update the tail index.  The head/tail dump is done once a second in a loop until the user kills it.  It's gotten me pretty far, but now I'm to the point where I also want to be able to send characters to the SCC, not just read from it.  So I need a device.

             

            We have a telnet server for Xinu, so I've been trying to pick apart the rckpc network driver to figure out how to talk to the MCPC through the FPGA, but it's been difficult.  If there were a simpler serial device to work with, I could probably figure that out much faster.

            • 3. Re: Shared memory TTY "device"?
              tedk

              I remember Xinu from school ... Comer's book. A long time ago ... I suspect it's changed a lot.

               

              Are you interested in having the SCC talk to the MCPC through the FPGA? There's some limited communication ... more in 1.4.1 than in 1.4.0.  I'll pass on your question to Intel Germany who wrote the driver you referred to. There's not really any doc beyond the source code, but we should be able to answer specific questions. Are you going to the symposium in Germany next week?

              • 4. Re: Shared memory TTY "device"?
                mziwisky

                Yep, Comer's book. My lab maintains a few ports of Embedded Xinu, the most active of which is for the Linksys WRT54GL.  Now I'm bringing it to the SCC.  Unfortunately I'm not going to the symposium next week.

                 

                A few specific questions to start out with:

                (1) When I do `ping rck00` from the MCPC, where does the ICMP packet get written to (from the perspective of the SCC)?  In the MPB of tile 0?  In some shared memory location?  Or elsewhere?

                (2) After the packet is written there, does the FPGA toggle one of core 0's APIC LINT pins?  Or does it interrupt the core some other way?  (In the MCPC driver, it looks like the INT1 pin gets toggled.  Is that right?)

                (3) Does anything on the SCC core need to be configured for this write and interrupt to happen?  (Clearly the APIC must be configured in order to tell the operating system to run the handler that reads in the packet, but will the writing and pin toggling happen no matter what?  I would assume so, but when I had a test program attach a handler to that interrupt and tried pinging from  the MCPC, the handler didn't run.  It did run, however, when I used  `sccWrite -c` to toggle the bit.)

                 

                Thanks,

                Mike

                • 5. Re: Shared memory TTY "device"?
                  tedk

                  Mike, please fee free to ask for more detial if needed.

                  <quote from Mike>

                  When I do `ping rck00` from the MCPC, where does the ICMP packet get written to (from the perspective of the SCC)?  In the MPB of tile 0?  In some shared memory location?  Or elsewhere?

                  </quote from Mike>

                   

                  Are you using the eMAC interface> MichaelR tells me the following. If you are not using eMAC, I'm guessing the same thing happens over PCIe.

                  When using the EMAC device driver (emac0 .. emac3) the traffic is written to a buffer in DDR3 (private space of the core) . The FPGA reads them (the core publishes the address to the FPGA during driver initialization) and transfers them to the Ethernet IP (hardware port). The opposite way works the same (DDR3 buffer and IRQ notification).

                   

                  <quote> from Mike>

                  After the packet is written there, does the FPGA toggle one of core 0's APIC LINT pins?  Or does it interrupt the core some other way?  (In the MCPC driver, it looks like the INT1 pin gets toggled.  Is that right?)

                  </quote from Mike>

                  MichaelR tells me the following.

                  The FPGA uses the Global IRQ controller that has been introduced in 1.4.0…

                   

                  <quote from Mike>

                  Does anything on the SCC core need to be configured for this write and interrupt to happen?  (Clearly the APIC must be configured in order to tell the operating system to run the handler that reads in the packet, but will the writing and pin toggling happen no matter what?  I would assume so, but when I had a test program attach a handler to that interrupt and tried pinging from  the MCPC, the handler didn't run.  It did run, however, when I used  `sccWrite -c` to toggle the bit.)

                  </quote from Mike>

                  From MichealR ...

                  In order to use user-IRQs in combination with the EMAC driver IRQs, he should use the global IRQ controller. Otherwise he will not have deterministic behavior.