The BeagleBone Black is a handy little board. It has a 1GHz ARM processor and 4GB of on-board Flash storage, and runs Linux very easily. In particular, the Debian distribution is available ready-made to just copy on to the board from an SD card. I’ve been using them in various embedded applications recently.

One of the applications I’m working on at the moment will be deploying BeagleBone Black boards in hundreds of locations, and we have to manage them sensibly. When managing all these boards, it will make our lives much easier to know their identities. Happily, the BeagleBone Black is fitted with an EEPROM which contains various useful information about it, including its serial number and a copy of the barcode stuck to the board.

The EEPROM is accessible via the I²C bus. The bus itself is accessible via /dev/i2c-0 at address 0x50. As standard, Debian Linux is set up so that the group i2c has access to this device. However, the kernel device tree is one step ahead of us. A special at24 driver takes over access to the EEPROM, so any attempt to access it directly via /dev/i2c-0 just gets denied with ‘Device or resource busy’. The contents of the EEPROM are available, however, in sysfs under /sys/bus/i2c/0-0050/eeprom.

There is also a bone-capemgr driver which presents some of the EEPROM contents in a more convenient way, as a series of files elsewhere in sysfs, under /sys/devices/bone_capemgr.9/baseboard/

This is all very handy, but all the files in sysfs are only readable by root. That’s not helpful for my applications. I don’t want to be running things as root if I can possibly help it. I wanted to find a reasonably legitimate way to make the relevant sysfs files available to a group of users. We can’t just change the permissions on those files because sysfs is created dynamically, so any changes would be lost after a reboot.

The obvious way to do this would be via a udev rule so that the permissions are set up when the relevant devices are found. However, udev rules don’t seem to have a direct way to change the permissions and ownership of files in sysfs. After some experimentation I came up with a couple of rules which did what I wanted. They match on the narrowest set of keys I could work out, and run chmod and chown to set the permissions the way I’d like them:

DRIVER=="bone-capemgr", RUN+="/bin/chown root:i2c /sys$env{DEVPATH}/baseboard/serial-number"
SUBSYSTEM=="i2c", DEVPATH=="*0-0050", RUN+="/bin/chown root:i2c /sys$env{DEVPATH}/eeprom", RUN+="/bin/chmod 0640 /sys$env{DEVPATH}/eeprom"

Put those lines in a suitable rules file. I used /etc/udev/rules.d/30-bone-capemgr.rules. Then, running

udevadm trigger

Should trigger the rules and set the permissions. Because sysfs is recreated at boot time when the various devices are found and added, the rules will trigger each time and leave the permissions the way we want them.

The board serial number is to be found in bytes 16-28 of the EEPROM, and the barcode is in bytes 80-103. The hexdump utility is handy for extracting the data. For example,

hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -s 80 -n 23

should show the barcode. Wrap that up in a script and we have a programmatic way of finding the board’s identity.

In the beginning, or at least in 1972, there was Pong. It was one of the first video games to become widely popular, and made Atari’s name in the games industry. It wouldn’t be overstating the case to call it seminal, even though the game itself involved only bouncing a ball between two bats. Four years later, Pong begat Breakout, which extended the bat-and-ball mechanics of Pong to knocking bricks out of a wall. Then came Super Breakout, a similar game, but more complex, with three different modes of play and even multiple bats and balls. Adding the new features needed a new, powerful ingredient: Super Breakout was one of the earliest arcade games to feature a microprocessor. This was in 1977, before Space Invaders, before Pac-Man, before Donkey Kong.

I picked up this PCB several years ago on eBay. The price was keen because, of course, it was ‘untested’. We all know what that means. Broken. That’s the way I like them. It’s hard to get to know a game board that’s in perfect working order.

Getting this one running was more than the usual challenge. From about 1980 onwards, a few conventions about how arcade games were built and wired got established. This game pre-dates those, so the usual rules don’t apply. Power? Instead of 5V and 12V DC supplies, it wants 10V and 22V AC, centre-tapped. Video? Instead of the usual colour RGB with separate sync, it delivers black-and-white composite video, and expects a screen with strips of coloured film stuck to it. Controls? No joystick here. Not even a trackball. Just an analogue potentiometer to control the paddle, and various flashing lights and switches.

My aim with every arcade game I acquire is to adapt it to the JAMMA standard, so it’s easy to plug it in and play it. This one was going need more than just a bit of wiring.

The first job was to get the board running. I rigged up temporary power supplies and a black-and-white monitor which could handle its video output.

The most serious fault was faulty RAM chips. Super Breakout has eight RAM chips of a whole one kilobit each, totalling a spectacular 1 Kbyte of RAM. Six of them were faulty. Fortunately a kind member of the most excellent UKVAC forum had some available. Identifying the faults was made easier by the board’s test mode, which makes beep-boop-boop noises to indicate which chips it thinks are faulty.

The sockets holding the program ROMs and the processor were all rubbish and had to be replaced with modern ones. Cleaning them never worked reliably. This particular version of the game uses 12 ROM chips, each holding 4 kilobits. That’s a generous 6 Kbyte of program code, but it’s also 216 pins in sockets to go wrong.

There was one faulty logic gate ( a 7420) associated with the ‘game select’ and ‘serve’ switches, and the DIP switches for choosing the game options needed a squirt of DeoxIT switch cleaner. Success!

With those problems attended to the board passed all its self tests and seemed to run quite happily. Now to design that JAMMA adapter.