title: Occasional lockup during boot on ARM (zynq)
body: <p>I have a ARM (zynq) board which was developed by a third party on which I am trying to run xilinx's vanilla Linux, compiled using build-root.  I seem to have everything working just fine, however every 1 in 10 boots or so the board hangs while booting the kernel.  In each of the boots power is completely removed, so everything about the boot should be the same.  I don't see any errors, but the last few things said are realted to PCIe, and nothing about the messages changes from a sucesfful boot.</p>
  
  <p>On a failed boot the last thing said is:  </p>
  
  <pre><code>PCI: bus0: Fast back to back transferred disabled
  pci 0000:00:00.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  PCI: bus1: Fast back to back transferred disabled
  pci 0000:01:00.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  </code></pre>
  
  <p>On a successful boot the very next thing that would be said is:  </p>
  
  <pre><code>PCI: bus2: Fast back to back transferred disabled
  pci 0000:02:00.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  pci 0000:02:01.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  pci 0000:02:02.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  pci 0000:02:04.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  pci 0000:02:05.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  pci 0000:02:06.0 bridge configuration invalid ([bus 00-00]), reconfiguring
  </code></pre>
  
  <p>For this very same board I have an image made with an old version of petalinux.  This version has never had a problem booting.  I have tried to match the configuration between the two (kernel.config, and the dts files) as closely as possible but keep in mind that the old petalinux build is with kernel 3.x and the new build is 4.x</p>
  
  <p>Full disclosure... I don't have access to the PS-PL design files, which means the design implemented in the zynq was done using tools from 2013.  I have no idea if this is even a remotely supported operation.  I believe the design uses only hard ip, specifically pcie and i2c, which I imagine can't really change from year to year.  I updated the device tree to reflect changes to driver names and whatnot, and both the I2C and PCIe seem to be working fine otherwise (I am successfully accessing I2C device on the board, and I am using PCIe peripherals).</p>