Unofficial Minix/arm Test Plan

This page provides a list of actionable items to perform a thorough set of tests on Minix/arm to validate the functionality of various device drivers. It's designed to be manually executed by a person when major changes are made and before releases to ensure that everything still functions as expected. The majority of tests included here are tests that cannot easily be automated; for example, testing the response of a light sensor (TSL2550) to a lamp turning on in a room. To complete the entire test script, you'll need all of the supported hardware: BeagleBone, BeagleBone Black, BeagleBoard-xM, Weather Cape. Additional I2C devices that can be plugged into the expansion header would be helpful too.

The tests are broken down by board (BeagleBone, BeagleBone Black, BeagleBoard-xM). Some tests are duplicated for multiple boards, but they should still be done due to differences in the chips on each board. For example, the BeagleBone and BeagleBone Black use different revisions of the TPS65217 PMIC. Additionally, it may be beneficial to try the tests on different revisions of each board.

These tests should work across all of the supported boards.

/!\ Warning: running the test suite could take several hours.

/!\ Warning: at time of writing, not all tests pass on arm.

There is a suite of tests which can be run to ensure that many of the software features are working properly.

cd /usr/tests/minix-posix
sh run

The boards each have a hardware real time clock, similar to the CMOS clock on i386. It should keep track of time while the board is running and between reboots.

Run the date command to see the current date/time. It should be wrong due to the board's lack of a battery back-up. Set the system date/time and run date again to see the new, correct, date/time.

date
date 201309161200
date

Write the date/time to the hardware real time clock.

readclock -w

Check that the system date/time is still going. Next, set the system date back in time. We're going to verify that the hardware clock contains the right date/time be reading the hardware clock. Run date to see that the system clock is back in time. Run readclock to read the hardware clock. Run date again to see that the correct date/time have been read from the hardware clock.

date
date 201301010000
date
readclock
date

Next we'll test the reboot feature and ensure that the real time clock keeps working between reboots.

reboot

Log in and run the date command. It should have the right date/time.

date

Testing this driver requires either additional hardware or a multi-meter and wire. TODO expand this section.

You can test this implicitly by using the serial console for some or all of the other tests. You can also try transfering small files with zmodem. In picocom, just do Ctrl+a+s. Full instructions can be found here.

This driver is also tested implicitly since without it, you wouldn't be able to do much. You can do more intense tests by copying and moving files around and checking their md5 checksums.

The padconf (i.e. pinmux) is another hard to test peripheral. Some notes: when the padconf call isn't functioning properly, the 3rd i2c bus on the BeagleBone and BeagleBone Black will fail.

Configure the network the normal Minix way with netconf and then reboot to apply the settings.

netconf
reboot

Try some network-enabled commands to transfer files. Check that they transfered OK.

fetch http://www.minix3.org/doc/raccoon-3.jpg
ping minix3.org
ftp ftp.minix3.org

You can also run servers like telnet. On the BeagleBone, run these commands to create a user, setup the telnet server, and reboot. When the system comes back up, you should be able to telnet to your BealgeBone and login as 'dummy' with the chosen password.

useradd -m dummy
passwd dummy
echo "daemonize tcpd telnet in.telnetd" > /etc/rc.daemons
reboot

Running shutdown -p should cause the board to power-off. The system will halt and the power lights will turn off.

shutdown -p

The BeagleBones each have an EEPROM with board information. Read the data off of the EEPROM and display it.

dd if=/dev/eepromb1s50 of=/root/eeprom.dat bs=128 count=1
hexdump -C /root/eeprom.dat

Verify the data. The first 4 bytes in the hex display should be “aa 55 33 ee”. In the ASCII display, you should see “A335BONE” on the BeagleBone and “A335BNLT” on the BeagleBone Black.

For this test, just watch the boot messages. If the utility is working properly, after the “Starting i2c device drivers” message you should see “Detected BeagleBone” for the original BeagleBone and “Detected BeagleBone Black” for the BeagleBone Black.

This is tricky to test as it uses the user level /dev/i2c interface. The /dev interface only exposes devices not being managed by a driver. All of the on-board devices have drivers; therefore, the i2cscan program won't find any of the on-board devices. The solution is to add additional devices (example: wire in an EEPROM chip to the expansion header) or temporarily disable some of the i2c devices in the rc script.

When you've got devices on the bus that aren't being managed by a driver, run the i2cscan program like this (devices are labelled /dev/i2c-1 to /dev/i2c-3):

i2cscan -r /dev/i2c-3

For this test, just watch the boot messages. The cape should be automatically detected. Where it says “Starting i2c device drivers:”, you should see “tsl2550 sht21 bmp085 http” in addition to the regular drivers.

The BMP085 senses temperature and pressure. Temperature is in Celsius and pressure is in Pascals. The temperature value might be slightly higher than room temperature due to heat coming from the BeagleBone.

cat /dev/bmp085b3s77

The SHT21 senses temperature and humidity. Temperature is in Celsius and humidity is relative (0-100%). The temperature value might be a few degrees above the temperature reported by the BMP085, again this is likely due to self-heating.

cat /dev/sht21b3s40 

The TSL2550 senses ambient light. Illuminance is in Lux. Turning on and off lights in the room should cause the value to go up and down.

cat /dev/tsl2550b3s39 

This test requires the BeagleBone be connected to the network. Use ifconfig to determine your BeagleBone's IP address.

ifconfig

Then, on another system, enter that address into your web browser. After a few seconds, a visual display of the weather sensor values should come up.

Press the power button; it's the button closest to the ethernet connector. It should cause the board to do a safe shutdown and power-off. Pressing the power button again should cause it to boot back up.

The frame buffer driver doesn't support the BeagleBone Black yet, but a driver for reading EDID via the TDA19988 HDMI Transmitter has been developed. With it, the frame buffer driver can ask the attached display what modes/resolutions it supports. While the TDA19988 driver is meant to be accessed directly by the frame buffer driver, it can be tested from the shell by creating a block device file with an unused major number and doing a read with the dd command. Here are the commands to run:

cd /dev
mknod tda19988 b 32 0
chmod 600 tda19988
/bin/service down tda19988.1.3470
/bin/service up /usr/sbin/tda19988 -label tda19988.1.3470 \
 -dev /dev/tda19988 \
 -args 'cec_bus=1 cec_address=0x34 hdmi_bus=1 hdmi_address=0x70'
dd if=/dev/tda19988 of=/root/edid.dat count=1 bs=128
hexdump -C /root/edid.dat

The data should start with the magic number “00 ff ff ff ff ff ff 00” and be 128 bytes long. Note, be sure the uHDMI connector is inserted properly; with a bulky uHDMI to HDMI adaptor, the uHDMI connector can become unseated easily.

The frame buffer driver is pretty limited. For example, there isn't support for console on frame buffer yet. However, we can test out what's been implemented so far. You'll need to get the splash program. It isn't in mainline Minix, but you can get it here. Simply boot the board with a display connected. Login and run the splash program:

splash

If everything worked, you should be seeing some raccoons on the display.

EDID is data stored on a chip inside the display. The data contains information about the display and it's supported modes/resolutions. On the xM, it's read by the frame buffer driver via a direct call to the cat24c256 driver. We can get at the data through the cat24c256's /dev interface. The hexdump command will display the data that was read. Note: due to a limitation of the EEPROM driver's /dev interface, the first by will be missing from the dump.

dd if=/dev/eepromb3s50 of=/root/eeprom.dat bs=128 count=1
hexdump -C /root/eeprom.dat

The data should start with the magic number “ff ff ff ff ff ff 00”. The missing 0th byte is “00”.