software-wise i need something that does nothing more complex than mount stuff on a micro-sd card, show boot messages on both screens, and maybe has 2 keyboards plugged in (one into each USB socket) so that they can bash some keys and see that crud comes up on-screen for each.

going beyond that... testing I2C, UART and the GPIO.... *sigh*... that involves writing some software.

Speaking about I2C, UART and GPIO testing - it sounds easy. I don't yet know which defects you'd want to cover with tests (mechanical, soldering, faulty parts, maybe all of them), but, as far as my research goes, you can test both UART and GPIOs with a loopback test, and I2C could be tested using a simple device - such as an EEPROM.

Now, I don't have as much testing experience, but I've done a couple of DIY jigs - not automated, but that's yet to come - and I've been thinking about a way to make testing jigs. First thing is - it's best if the test program runs on the computer card itself. I see that's what you plan to do, and, if I'm not mistaken, cards are going to boot from a MicroSD card anyway - which is what's needed.

Testing GPIOs can be done easily from software - connect GPIOs in pairs using resistors (say, 470ohm, just in case one of GPIOs is shorted to ground/VCC for some mechanical reason). Set first GPIO as input, second as output, then toggle the second GPIO and check that value that's read from the input is the same as value that's on the output.

With more complicated interfaces, it depends. I2C should be testable by using an I2C device - since you have an EEPROM inside the card, it makes sense to first test if that's accessible, then test another device that's located in the test header (say, a GPIO expander or an ADC, you could use both of those for testing, too.) You can test SPI in loopback mode by connecting MISO and MOSI together, though you won't test SCK and CS that way. UART should easily be testable with a loopback - though I think you won't want to have the loopback hard-wired, to make sure that U-Boot messages won't get into U-Boot input and stop the boot process, or something of that kind =)

If you want to test USB, you don't even need to have engineers mash on the keyboard, attach two USB devices with unique IDs (say, CP2012 - you can program those through USB connection) and make sure they're recognized - in case of CP2012, you can make a loopback test of their UART, just to make sure data passes through... Not sure how much sense it'll make, though =)

Now, speaking about SDIO and parallel video interfaces that you have in EOMA68 pinouts, I have no idea how to test them automatically =( But the test I listed cover most mechanical pins, and half of the peripherals, which is already pretty good for avoiding RMAs of cards with bad solder joints in the USB or I2C lines. They're also cheap enough in terms of hardware& software required.

So, the end result could be: a MicroSD card with a stripped down image of something something Linux that boots as quickly as possible (with cruft like networking disabled), shows the boot log on HDMI monitor - then draws a table on the monitor (I imagine it being a fullscreen application working with framebuffer, to avoid having to wait for X to load). Cells of that table would be filled with green or red, depending on whether tests pass on fail - and an all-green monitor would indicate all is well =) This should make for streamlined&quick testing and avoid lots of manual work (excluding that, well, you still have to plug the card into the testing jig and plug the cables in).

Now, I don't have *that* much experience, I don't know which failures you want to protect against, but if I were to test these cards, this is what I'd do.

Cheers! Arsenijs