FAQ

Which BeagleBone will work?

The classic BeagleBone Black is what is supported. Others:

Black Wireless	Community-tested.
Green	Not fully compatible and does not work out of the box — the GPIO impedance differs, which matters for nanosecond-timed PRU signals. It can be made to run with different terminator resistors on the PCB, but never reaches the Black’s speed or safety margin.
Enhanced (Blue)	Would not make a network connection on a standard image. Probably needs an adapted Debian.
White	Not tested. Do not.

Can I power the card outside a machine?

Yes, and it is worth doing for software work rather than spending backplane hours on it. The card runs on +5 V only, drawing well under 1.5 A — though consumption rises sharply when it is driving bus terminator arrays.

Option
Bus +5 V — the silver capacitor leads or the 5VUB pins	Best. Everything is powered and you should hear the delay relay click.
The BeagleBone’s 5 V jack	Works, but the driver chips and the I²C panel power stay dead — they are fed from bus +5 V.
A strong (>2 A) USB supply into the BeagleBone’s USB port	Works.
A PC’s USB port	No. USB 2.0 data ports supply about 500 mA, enough for a bare bone but not for bone plus card.

The green power LED indicates the BeagleBone’s 3.3 V is good.

Which backplanes take the card?

UNIBUS · UniBone

UniBone needs an SPC slot. Four kinds of backplane look identical from the front:

1. Standard expansion backplanes like the DD11-DK — SPC slots in every socket row on slots C–F. What you want.
2. CPU backplanes — special slots for processor boards, then perhaps rows wired for core memory (11/05) or local memory (11/44, 11/84). Whatever is left over is SPC, enough for a console and a boot device.
3. Specially wired controller backplanes for older multi-board controllers (RK11, DL11). No SPC slots at all.
4. QBUS backplanes. Do not even think about it.

QBUS · QBone

Any quad QBUS slot. The complication is not which backplane but the C/D rows and the slot ordering — see Fitting it to a backplane.

The bus latch test fails on SACK

UNIBUS · UniBone

The stress test drives every bus line to a random state and reads them all back. An M9302 or any terminator with active SACK logic will fail it — the terminator is driving the line. Use a passive terminator: resistors only, no logic and no boot ROM.

Will it be damaged if I pull the power without shutting down?

In practice, no. The journalled filesystem tolerates it and SD cards have some protection of their own; QUniLators have been power-cycled hundreds of times without harm. A clean shutdown is still tidier.

How do I shut it down cleanly?

Either of these shuts the BeagleBone down cleanly, and its power LED goes out when it is done:

• In the web interface: System › Shut down, from version 1.28.0.
• Over ssh: sudo poweroff, as the operator.
• The BeagleBone’s POWER button (S3, next to the Ethernet jack): a short press asks the system to shut down, the same as poweroff. Holding it for about eight seconds cuts the power without a shutdown.

Halt or switch off the machine’s operating system first: a disk it is writing to stops at an arbitrary point when the board goes down.

It boots, but I do not see the QUniLator software

The BeagleBone has an on-board eMMC carrying a factory Debian, and if anything is wrong with the SD card or the boot selection it will come up on that instead.

When the BeagleBone is unplugged from the card it loses the resistors that encode the boot device, and will always boot from eMMC. So the BeagleBone must be on the card to boot your image at all. Holding the S2 button while applying power forces SD boot.

It boots from the card only while S2 is held

Without S2 the BeagleBone’s boot ROM tries the eMMC first, and the U-Boot it finds there decides what starts. A recent Debian on the eMMC boots the eMMC; the U-Boot of older eMMC images looked at the SD card first, which is why an older card may boot without the button. With the eMMC’s boot area erased, the ROM finds no bootloader there and goes on to the SD card by itself.

The card’s image switches the eMMC off, because with the card fitted its pins belong to the cape. So the eMMC is erased with the BeagleBone off the card:

1. Boot from the card, holding S2. In /boot/uEnv.txt, put a # in front of both enable_uboot_overlays=1 and disable_uboot_overlay_emmc=1. Shut down.
2. Take the BeagleBone off the card and power it on its own with the microSD in, holding S2. lsblk now lists the eMMC as mmcblk1.
3. Erase its boot area. This also erases the Debian on the eMMC, which QUniLator does not use:

   sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=16 && sync

4. Remove both # again, before the BeagleBone goes back onto the card: without the overlays the cape does not work. Shut down.
5. Fitted to the card again, it boots from the microSD without S2.

My machine will not start with the card fitted

The card closes the grant chain in software, by watching the pins and forwarding the signals. So while QUniLator is not running, the chain through its slot is open — and an open chain with an active terminator raises SACK, which allocates the bus and stops the machine.

The usual checks:

• Is the card actually running? Watch the LEDs (Reading the LEDs).
• Are the continuity cards seated properly in every unoccupied slot?

UNIBUS · UniBone

Is the NPG chain closed at CA1–CB1 on every unoccupied row, and open in the slot UniBone occupies?

You can close the grant chain on the card with jumpers permanently — but then it can do no interrupts and no DMA, which rules out device emulation.

A UniProbe or QProbe terminator shows open BG/NPG signals and a raised SACK on its LEDs, which turns this from guesswork into a glance.

The emulator has crashed or stopped responding

The emulator is a systemd service — qbone on a QBone, unibone on a UniBone — and restarting that service brings it back without rebooting the BeagleBone. Log in with ssh as the operator account, which has sudo, and run:

sudo systemctl restart qbone      # unibone on a UNIBUS board

The service does not restart itself: a crashed emulator stays down until it is restarted by hand or the board reboots. How it looks depends on what happened:

• It exited. The LEDs fall back to the three-LED XXX blink, and the web interface does not answer. systemctl status qbone reads failed.
• It hangs. The process is still alive, so the LEDs keep their ready sweep even though the web interface and the machine have stopped responding.

The restart works for both. A hung emulator that ignores the stop request is killed after 15 seconds, and the new one starts in its place. It reloads the PRU firmware and selects the configuration by the DIP switches, as at boot, and the machine comes up dark: switch it on with AUX ON/OFF on the control panel. A configuration marked autostart switches itself on.

While the emulator is down, the grant chain through its slot is open, which usually stops the machine on the bus as well (see My machine will not start with the card fitted).

To see why it stopped, and to report it:

systemctl status qbone                     # state and the last log lines
journalctl -u qbone -b                     # everything since the board booted
journalctl -u qbone -b -1                  # the boot before, after a reboot

A crash also leaves a core dump as /var/lib/qunilator/core. Mention it in the issue along with the journal; the next crash overwrites it.

Only when systemctl restart itself does not return does the board need a reboot (sudo reboot).

XXDP boots from an emulated drive but nothing else does

XXDP’s disk drivers — the RL11 one at least — use DMA but no interrupts. So a fault on the BG4–7 interrupt grant chain does not affect it.

In other words: XXDP is tolerant of missing interrupt continuity cards, and intolerant of a broken DMA chain. If XXDP boots and your operating system does not, look at the interrupt grant chain first.

A disk image boots and then crashes

Two popular causes beyond the grant chain:

1. The operating system does not match the machine. RSX in particular is generated for target hardware — an RSX built for an 11/34 will not run on an 11/84. Model your physical machine in SimH and boot the image there first.
2. Missing line-time clock. Unixes will not boot without one, and RSX needs it for task scheduling. See The line-time clock.

Do I need a boot ROM in the machine?

Not necessarily. QUniLator can emulate the bootstrap — an M9312, an MRV11-D or an MXV11-B2 — so a machine whose ROM is missing or wrong for the device can still boot. A configuration from the catalogue brings whatever it needs with it.

How do I get a file onto the running guest, or off it?

Through its console. Send file on the dashboard’s console, or a file dropped on it, types a text file into whatever reads the terminal, or sends any file by XMODEM or Kermit to a receiver started on the guest; Receive file fetches files the guest sends by XMODEM or Kermit. See Sending and receiving files.

Where do I ask something not answered here?

• GitHub issues for the software.
• The UniBone Google group for the hardware and general discussion.