{{{#!html
          <div id="wikipage" class="trac-content"><p>
</p><div class="wiki-toc">
<ol>
  <li>
    <a href="#LagunaBoardErrata">Laguna Board Errata</a>
    <ol>
      <li>
        <a href="#LAGUNA_ERR_1:PowerSupplyLimits">LAGUNA_ERR_1: Power Supply Limits</a>
      </li>
      <li>
        <a href="#LAGUNA_ERR_2:PCIeSpecwithregardstoPCIeclockandPERST">LAGUNA_ERR_2: PCIe Spec with regards to PCIe clock and PERST#</a>
      </li>
      <li>
        <a href="#LAGUNA_ERR_3:PCIBridgecancomeupinexternalarbitermode">LAGUNA_ERR_3: PCI Bridge can come up in external arbiter mode</a>
      </li>
      <li>
        <a href="#LAGUNA_ERR_4:GSCLock">LAGUNA_ERR_4: GSC Lock</a>
      </li>
      <li>
        <a href="#LAGUNA_ERR_6:PCIeBusClockSignal">LAGUNA_ERR_6: PCIe Bus Clock Signal</a>
      </li>
      <li>
        <a href="#LAGUNA_ERR_7:Tamperswitchnon-functional">LAGUNA_ERR_7: Tamper switch non-functional</a>
      </li>
    </ol>
  </li>
</ol>
</div><p>
</p>
<h1 id="LagunaBoardErrata">Laguna Board Errata</h1>
<p>
The below errata only affects certain models and certain revisions.
</p>
<p>
Please contact support@… with any questions.
</p>
<h2 id="LAGUNA_ERR_1:PowerSupplyLimits">LAGUNA_ERR_1: Power Supply Limits</h2>
<p>
Issue:
</p>
<ul><li>The CPU VCore supply may not provide enough power during high loads at higher ambient temperatures (typically over 70C) resulting in a CPU hang.
</li></ul><p>
Affected Product:
</p>
<ul><li>GW2380-A,B,B.1
</li><li>GW2380-SP232-A,B
</li><li>GW2380-SP242-A,B
</li><li>GW2382-A,B
</li></ul><p>
Resolution:
</p>
<ul><li>The following product versions and onward were revised with a BOM change resolving the issue:
<ul><li>GW2380-B.2
</li><li>GW2380-SP232-B.1
</li><li>GW2380-SP242-B.1
</li><li>GW2382-B.1
</li></ul></li><li>If update required on affected product contact sales@… to inquire about our RMA process
</li></ul><h2 id="LAGUNA_ERR_2:PCIeSpecwithregardstoPCIeclockandPERST">LAGUNA_ERR_2: PCIe Spec with regards to PCIe clock and PERST#</h2>
<p>
Issue:
</p>
<ul><li>A PCIe spec non-conformity exists where PERST# is not properly asserted before the PCI Clock is stable. On product with miniPCI support this can occasionally cause (typically at high temperatures) the TI XIO2001 PCI bridge to not link and thus disallows any PCI device access. On product with MiniPCIe support (no bridge) this can cause various PCIe device issues typically seen on soft resets.
</li></ul><p>
Affected Product:
</p>
<ul><li>GW2388 with PCB 02210082 revision 00-02
</li><li>GW2387 with PCB 02210086 revision 00
</li><li>GW2380 with PCB 02210087 revision 00-01
</li></ul><p>
Resolution:
</p>
<ul><li>The following products were updated to connect PERST# to an ARM GPIO. This requires a bootloader update (present in svn <a class="changeset" href="/changeset/368" title="fixed: assert PERST# until PCI clock is stable
  - this addresses some ...">r368</a> onward) to pulse and leave de-asserted the GPIO:
<ul><li>GW2388-D (PCB 02210082-04)
</li><li>GW2387-B (PCB 02210086-01)
</li><li>GW2380-C (PCB 02210087-03)
</li></ul></li><li>For affected products with a TI XIO2001 PCI bridge: GW2388, GW2387:
<ul><li>If PCI bridge link not found, warm reset the board (software workaround)
</li><li>a pullup resistor can be added to one of the PCI clock signals removes glitches from the clock
</li></ul></li><li>For affected products without a PCI bridge: GW2380
<ul><li>if a soft reboot is necessary, use instead the Gateworks System Controller to hard reset the board by telling it to put the board to sleep for 1 or more seconds
</li><li>reboot via hard reset with GSC if link is not detected
</li></ul></li></ul><h2 id="LAGUNA_ERR_3:PCIBridgecancomeupinexternalarbitermode">LAGUNA_ERR_3: PCI Bridge can come up in external arbiter mode</h2>
<p>
Issue:
</p>
<ul><li>In environments with both low temperature and high humidity it has been found that the Texas Instruments XIO2001 PCIe to PCI bridge with its EXT_ARB_EN pin unconnected can power up thinking the pin is asserted. TI found the cause to be that the documented internal pulldown was missing.  The ball routes to a trace on the underside of the BGA to the edge representing a trace which is highly sensitive. When the XIO2001 powers up in external arbiter mode the result is the kernel hangs during PCI enumeration. Depending on software the last thing seen over the serial console can be any of the following lines:
<pre class="wiki">&lt;&lt;0000:02:03.00 00(4)= master_abort on read
</pre><pre class="wiki">PCI: bus1: Fast back to back transfers enabled
</pre></li></ul><p>
Affected Product (All product using the TI XIO2001 (02120635):
</p>
<ul><li>GW2388 with PCB 02210082 revision 00-05
</li><li>GW2387 with PCB 02210086 revision 00-01
</li></ul><p>
Resolution:
</p>
<ul><li>Existing Product: Applying epoxy around the edges of the XIO2001 covering all exposed copper test traces increases the noise immunity of the EXT_ARB_EN signal and has shown in extensive testing to eliminate the issue. This has been done at the factor for affected product and you should see black epoxy around the bridge chip as a resolution.
</li><li>On the following product revisions and forward, the EXT_ARB_EN signal was brought out and pulled down to resolve this:
<ul><li>GW2388-4-F (PCB 02210082-05)
</li><li>GW2387-C (PCB 02210086-02)
</li></ul></li></ul><h2 id="LAGUNA_ERR_4:GSCLock">LAGUNA_ERR_4: GSC Lock</h2>
<p>
Issue:
</p>
<ul><li>A glitch on the RST# line can cause the Gateworks System Controller (GSC) to 'hang' requiring its battery to be removed (for 10+ seconds) in order for the board to be able to boot. At high supply voltages (ie 48V) and high powerup load (ie 2x+ DNMA-H92 radios) any bouncing of Vin can cause the CPU to assert its WD output at power-up which keeps the system monitor un-powered and results in a 3.3V signal on the RST# line. In some circumstances this can cause the GSC to get in a locked up state. As the GSC provides the EEPROM device needed to be read by the bootloader, if the GSC is not responsive the board will not boot. The 3.3V Power LED will come on indicating board power but no output over the serial port will be seen.
</li></ul><p>
Affected Product:
</p>
<ul><li>GW2380 with PCB 02210087 revision 00-02
</li><li>GW2382 with PCB 02210105 revision 00-01
</li><li>GW2383 with PCB 02210113 revision 00
</li><li>GW2388 with PCB 02210082 revision 00-03 (other than E.1)
</li></ul><p>
Resolution:
</p>
<ul><li>The following product revisions were modified by replacing a 0ohm resistor with a 7.15kohm which will allows VCC to drop below the 3.08V tripping point, but not below 0.65V allowing the system monitor to effectively clamp RST# down to a max of 0.65V eliminating the large glitch producing the issue.
<ul><li>GW2380-D (PCB 02210087-03)
</li><li>GW2382-C (PCB 02210105-02)
</li><li>GW2383-B (PCB 02210113-01)
</li><li>GW2388-4-E.1 (02210082-04)
</li></ul></li></ul><h2 id="LAGUNA_ERR_6:PCIeBusClockSignal">LAGUNA_ERR_6: PCIe Bus Clock Signal</h2>
<p>
Issue:
</p>
<ul><li>A high error rate (~10/min) of SERR's and a somewhat lesser rate of PERR's and MABORT's on the PCIe bus can occur at high clock frequencies on designs that have both the CNS3420 600MHz and the TI XIO2001 bridge and under heavy load. This is realized by inspecting PCI configuration register 0x06. This is caused by a CNS3xxx errata where excessive jitter can exist on the PCIe refclk provided by the CPU. The work-arounds suggested by Cavium were followed but turned out to only help reduce the issue and not resolve it completely.
</li></ul><p>
Affected Product:
</p>
<ul><li>CNS3420 600MHz boards with TI XIO2001 bridge (mini-PCI slots) using PCB 02210082-00 to -05
<ul><li>GW2388 with PCB 02210082 rev 00-05
</li></ul></li></ul><p>
Resolution:
</p>
<ul><li>This is resolved in the following models by switching to an external PCIe clock generator:
<ul><li>GW2388-4-G (PCB 02210082-06)
</li><li>This change also required a bootloader update to configure the PCIe controller to use the external clock instead of its own internal clock:
<ul><li><a class="ext-link" href="http://trac.gateworks.com/changeset/521/laguna/trunk/u-boot-2008.10"><span class="icon">​</span>r521</a>
</li><li>board detection is done by looking at GPIOB block - based what is pulled up
</li><li>a new line is output that displays the fact there is a PCI_RST# gpio and what it is, and whether the PCI clock is internal or external:
<pre class="wiki">U-Boot 2008.10-mpcore-svn512 (Feb  5 2014 - 10:15:12)

CPU: Cavium Networks CNS3000
ID Code: 410fb024 (Part number: 0xB02, Revision number: 4)
CPU ID: 900
PCI:   PERST:GPIOA11 clock:internal
</pre></li></ul></li></ul></li><li>The following workarounds can be used for boards with a dual-core CNS3420 600MHz and an internal PCIe clock:
<ul><li>disable TI bridge Master abort mode. This will cause the bridge to not forward master aborts to the PCI side of the bus and thus would hide the failure from the PCI device/driver (which may have undesirable side-effects depending on the device/driver used)
<pre class="wiki">pciset -s 00:01.0 0x3E.W=0x481
</pre></li><li>lower Vcore loading by disabling L2 Cache (in some I/O bound cases disabling L2 cache improves performance as well). You can disable L2 cache by adding 'nol2x0' to the kernel command-line for the 3.8.x kernel. For the 2.6.39 kernel you must rebuild the kernel with L2X0 disabled.
</li><li>implement proper handling for master aborts in the device driver. PCI bus errors should always be handled properly. The ath9k driver for Atheros AR9xxx 802.11n radios for example has a driver bug that causes a crash when a master abort is detected during an aggregated frame. A patch exists in the Gateworks <a class="wiki" href="/wiki/OpenWrt">OpenWrt</a> BSP (13.06 onward) to take care of this
</li></ul></li></ul><h2 id="LAGUNA_ERR_7:Tamperswitchnon-functional">LAGUNA_ERR_7: Tamper switch non-functional</h2>
<p>
Issue:
</p>
<ul><li>The GW2388-4 has a capacitor loaded on the tamper circuit which makes it un-usable for the GSC tamper feature (Note that it still works as a GSC GPIO)
</li></ul><p>
Affected Products:
</p>
<ul><li>GW2388-4-B and above
</li></ul><p>
Resolution:
</p>
<ul><li>Remove C40, C303 if you wish to use the tamper feature
</li></ul
}}}