• Fixture: Hardware and software that is not part of the production device which is used to perform and evaluate the results of tests. Processor which coordinates tests is referred to as the "test host".
  • DUT (Device Under Test): The device whose quality we wish to qualify using the results of tests.

Initial Board Bring-up

  1. Does power work? Measure the voltages, yes no. (This seems like a good application of a hardware fixture, especially if we want to do this for production boards before going on to the subsequent tests.) Voltages to test: 1.5V (DDR3), …
  2. Does plugging in only USB-OTG have it (DS-113?) show up on (test host's?)"lsusb", yes no?
  3. Load the FEL. Does that work, yes no?
  4. Now does loading u-boot directly into DDR3 RAM work, yes, no?

The FEL (u-boot-spl) loader has a nice debug feature of displaying a few lines of early UART so that's a really good way to tell if the A20's alive.

External Interfaces

The microdesktop 1.7 brings everything out. as it's only 68 pins, 24 of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for micro-sd and 4 are for USB2, there's actually not a lot left.

  • SD/MMC: Compile u-boot to look for a particular micro-sd card slot, which it will scan, and show debug messages "SD card detected" and so on. Commands can be issued which list the partitions and so on.
  • UART: Add a USB-to-UART adapter onto a "test" microdesktop unit, if there's output on the console and it's not garbage, that's good enough.
  • USB: 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.
  • I2C: EEPROM on-board the Micro-desktop PCB
    Scan the I2C bus (lmsensors debian package), see if a peripheral at address 0x51 comes up, if it does great. It's a few lines of shell script.
  • SPI
  • GPIO: There's actually only a few pins spare, they're all on the 14-pin header of the microdesktop board. Except for two which are intended for bit-banging a separate I2C driver for VGA "EDID" detection....
    A simple program that tests GPIO, assuming that say 4 resistors are connected between 8 GPIOs in pairs, turning one into an input and the other an output, then setting 0 and 1 and seeing if it's read correctly... then inverting each pair (out becomes in, in becomes out) and re-running the test.
    Something in either c or python that uses the sunxi-3.4 gpio driver: [drivers/gpio/gpio-sunxi.c]
    That should be exposed as /dev/gpio which should in turn appear in either /sys or /proc... It should be a standard interface, with a standard way to set which banks are activated... You might have to do some digging.