<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:clearspace="http://www.jivesoftware.com/xmlns/clearspace/rss" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
  <channel>
    <title>Intel Communities: Message List</title>
    <link>http://communities.intel.com/index.jspa?view=discussions</link>
    <description>Most recent forum messages</description>
    <language>en</language>
    <pubDate>Mon, 15 Nov 2010 17:36:03 GMT</pubDate>
    <generator>Jive SBS 5.0.2.0  (http://jivesoftware.com/products/clearspace/)</generator>
    <dc:date>2010-11-15T17:36:03Z</dc:date>
    <dc:language>en</dc:language>
    <item>
      <title>Re: How do I/O ports work on an SCC core?</title>
      <link>http://communities.intel.com/message/107485?tstart=0#107485</link>
      <description>&lt;!-- [DocumentBodyStart:3b1074df-c767-45c4-85bc-508b9cd921b7] --&gt;&lt;div class="jive-rendered-content"&gt;&lt;p&gt;During the MARC symposium in Braunschweig last week, I had the same idea as you: To answer I/O port accesses from other cores on the SCC, you would have to forward them via some shared memory protocol. It's not pretty, but should work. For now, I guess, I am going to prototype this on the MCPC. That should be enough to evaluate it.&lt;/p&gt;&lt;p style="min-height: 8pt; height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;For the use case: We have modular device models and some BIOS code lying around. It is not trivial, but straight-forward to wire them together to create something that runs an out-of-the-box bootloader (e.g. GRUB or gPXE). From that point, at least our OS (L4 Fiasco) should run unmodified[1], which would be great for further experiments. I hope it is also sufficient to boot an umodified Linux. Of course, you would still need special drivers for efficient I/O (i.e. the upcoming ethernet and framebuffer features), but the diff to vanilla Linux shrinks considerably and you wouldn't have to touch the baroque bootstrap code. The bar for porting other OSs is reduced as well.&lt;/p&gt;&lt;p style="min-height: 8pt; height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Btw, The symposium in Braunschweig has helped me a lot to improve my mental picture of how the SCC works. So thanks for doing that @ Intel.&lt;/p&gt;&lt;/div&gt;&lt;!-- [DocumentBodyEnd:3b1074df-c767-45c4-85bc-508b9cd921b7] --&gt;</description>
      <pubDate>Mon, 15 Nov 2010 17:36:03 GMT</pubDate>
      <author>webadmin@intel.com</author>
      <guid>http://communities.intel.com/message/107485?tstart=0#107485</guid>
      <dc:date>2010-11-15T17:36:03Z</dc:date>
      <clearspace:dateToText>2 years, 6 months ago</clearspace:dateToText>
      <clearspace:objectType>0</clearspace:objectType>
    </item>
    <item>
      <title>Re: How do I/O ports work on an SCC core?</title>
      <link>http://communities.intel.com/message/106311?tstart=0#106311</link>
      <description>&lt;!-- [DocumentBodyStart:3ec9e458-f4ab-42b1-9217-c551d5f363bd] --&gt;&lt;div class="jive-rendered-content"&gt;&lt;p&gt;Yes, I meant IN/OUT instructions and to put it in perspective, we are currently evaluating whether device emulation on the SCC is feasible. A desirable goal would be to run unmodified operating systems (not just SCC Linux).&lt;/p&gt;&lt;p style="min-height: 8pt; height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Being able to respond to I/O port accesses from the MCPC is definitely helpful and example code would be more than appreciated. But the original goal of my question was to find out whether you can route them not to the MCPC, but to another core on the mesh. Correct me if I am wrong, it sounds like this should be possible with modifications to the "chipset". The obvious advantage would be that the latency of handling I/O port accesses is greatly reduced.&lt;/p&gt;&lt;/div&gt;&lt;!-- [DocumentBodyEnd:3ec9e458-f4ab-42b1-9217-c551d5f363bd] --&gt;</description>
      <pubDate>Mon, 01 Nov 2010 12:22:30 GMT</pubDate>
      <author>webadmin@intel.com</author>
      <guid>http://communities.intel.com/message/106311?tstart=0#106311</guid>
      <dc:date>2010-11-01T12:22:30Z</dc:date>
      <clearspace:dateToText>2 years, 6 months ago</clearspace:dateToText>
      <clearspace:replyCount>2</clearspace:replyCount>
      <clearspace:objectType>0</clearspace:objectType>
    </item>
    <item>
      <title>How do I/O ports work on an SCC core?</title>
      <link>http://communities.intel.com/message/106078?tstart=0#106078</link>
      <description>&lt;!-- [DocumentBodyStart:eca85de7-931b-49fa-bfcd-90f84db98db8] --&gt;&lt;div class="jive-rendered-content"&gt;&lt;p&gt;Hello,&lt;/p&gt;&lt;p style="min-height: 8pt; height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;I am looking for information on how I/O port accesses work on the SCC. I skimmed through the SCC Linux code and it seems it uses in/out instructions to communicate with the MCPC (in include/asm-i386/mach-mcemu/mcemu_debug.h). Is there any documentation on how this exactly works? I am particularly interested in how port accesses are communicated over the mesh and how the core knows where to route them.&lt;/p&gt;&lt;p style="min-height: 8pt; height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Regards, Julian&lt;/p&gt;&lt;/div&gt;&lt;!-- [DocumentBodyEnd:eca85de7-931b-49fa-bfcd-90f84db98db8] --&gt;</description>
      <pubDate>Fri, 29 Oct 2010 12:16:26 GMT</pubDate>
      <author>webadmin@intel.com</author>
      <guid>http://communities.intel.com/message/106078?tstart=0#106078</guid>
      <dc:date>2010-10-29T12:16:26Z</dc:date>
      <clearspace:dateToText>2 years, 6 months ago</clearspace:dateToText>
      <clearspace:replyCount>9</clearspace:replyCount>
      <clearspace:objectType>0</clearspace:objectType>
    </item>
  </channel>
</rss>

