A neat toy (but not an ESP)

Here I go with yet another not-quite-ESP-related diversion, but one which the audience of this blog this should find interesting, I hope.

A couple of weeks back I bought a cheap USB GPS dongle from Amazon.

U-Blox USB GPS Dongle

It was amazingly cheap (the Yen equivalent of $8 U.S.) and I wasn’t expecting too much, but I have a yearning to get a local reference clock for NTP set up on my local network and I thought that, if nothing else, this would be a good starting point for fiddling around with GPS before paying for (and possibly breaking) something more expensive.USB GPS dongle, antenna side  I have to say that I’m really, really impressed with this little thing.  I’m sitting in a valley with major mountain ranges to both the east and west of me (~3,000m on each side), so I have a fairly narrow view of the sky, but this little unit acquires and holds nine satellites from inside the house and about 1.5m from the window.

The second thing I did (after verifying that the unit did actually work) was to rip the covers off to verify the make and model of the receiver chip and, as you can see from the photo above, the built-in antenna covers most of the board space on the top side of the PCB (the single, other component, top L/H side, is the green, status LED).

USB GPS dongle, component side

The component side has the U-Blox G7020-KT chip in the bottom,R/H corner.  Note that there’s no FDTI (or equivalent) chip, as the G7020 has a USB interface included.

There’s a back-up battery on the board to maintain memory contents between power cycles (which, it turns out, is critical for reasonable start-up times for GPS receivers).

Unlike another (non-GPS) dongle which I bought recently‡, this unit barely gets warm to the touch and there are no ventilation slots or holes in the plastic cover.

Anyway, for anyone else interested in playing with these beasties, here are some hints to get you started:-

  • The very first time you power on this unit, it will take up to 25-minutes to locate the satellites and lock on. Apart from a very brief flash of the green LED when you first connect it, it will appear to be dead. It’s not! Just leave it connected and it will download the data it needs (the “almanac”) from the satellites it can see and eventually the green LED will start flashing once per second to show that it is now operational.
  • After that initial connection, the unit will come to ready (green LED flashing) in only a few seconds the next time you power on. This is because it saves that initial data to internal memory (with battery back-up).
  • If, on that first power-up, you don’t see a green flashing LED after 30-minutes, it’s because the unit can’t get a decent signal. Move it as close as you can to a window, or if you have a laptop, take it outside. If that doesn’t work, grab a 1m or 2m USB extension cable from your local 100-Yen shop and move your GPS dongle as far away from the computer (and as close to a window) as you can.
  • If you’re using Windows, you can get the genuine Windows driver directly from the chip manufacturer’s web site:-        https://www.u-blox.com/ja/support      -or- https://www.u-blox.com/en/support
  • The chip inside this unit is the U-Blox G7020-KT.
  • If you’re using open-source, you will probably find that your OS correctly identifies the USB device as soon as you plug it in. The application you need (as already noted) is the GPS daemon, “gpsd”. When you install “gpsd” you’ll get some additional helper applications bundled in, such as the invaluable “gpsmon” and “gpspipe”, which allow you to view the GPS data in several formats.
  • The device which you use to connect to the USB dongle will be different between various OSes. OpenBSD and FreeBSD will see it as /dev/cuaU0. Linux will see it as /dev/ttyACM0 or /dev/USB0.
  • To run gpsd you should use the “-n” option (“no-wait” – don’t wait for a client to connect before handling GPS data) and the device. So something like this:- /usr/local/sbin/gpsd -n /dev/cuaU0
  • After starting gpsd you should be able to run gpsmon (just type “gpsmon”) and see data coming from the device.
  • If you want to run your GPS dongle as a local source for the NTP daemon, you still need to start “gpsd” (and it’s important to use that “-n” option in this case). The gpsd process will automatically populate shared memory segments, which the ntpd daemon can then read to get time information (you may have to check your OS for sysctl settings for PPS to get this working). There are notes in both the ntpd and gpsd manual pages on how to do this. So far I have only managed to get ntpd to use the GPS embedded time information, not PPS.

As you can see from the photos above, the board has most of the components (including the battery and the G7020-KT chip) on one side and the antenna on the other. The green LED is on the same side as the antenna, so when you position your USB dongle, you should always have the green LED facing –upwards-. If your USB forces it to be downwards (unusual) or sideways (fairly common), you might want to buy an adapter or extender cable to ensure that you can position it so that the antenna (and LED) are pointing upwards.

 

‡ – A generic, black SDR dongle, bought for the advertised “R820T” tuner chip and specifically for receiving 1090Mhz ADS-B traffic from aircraft flying overhead (see the previous post on “PlaneSpotter”).  Not only does this thing get hot, it -doesn’t- have an R820T tuner chip at all (they use a cheaper and completely useless NC00012 tuner, which has a frequency range which cuts off at 985Mhz, so it doesn’t even cover the ADS-B band).  If you want to play with SDR (and especially ADS-B), save your money and buy a NooElec “Mini 2+” bundle (directly from nooelec.com) instead.  It has an R820T2 tuner chip, plus a temperature controlled, 0.5PPM accuracy oscillator and comes with a “starter” antenna and a remote control unit (??? don’t ask me …I have no idea why!) for $21 U.S. + $5 postage to anywhere in the world.

Advertisements

Z83-II Mini-PC (Quad core 8350)

Another departure from the ESP8266, but for something that ESP8266-hackers might find interesting.

Over the past couple of years I’ve been ditching most of the big, ugly, power-hungry desk-top and server machines which used to run my mighty empire (aka “the house”) and replacing them with machines that are a lot smaller and a great deal less power-hungry.  I’ve got a few SBCs of various sorts; all ARM based, mostly multi-core and almost all still shamefully naked and gathering dust, even though they’re alive and kicking and running various essential services on our home network.  In addition to the lack of a case, almost all of them have other drawbacks of some sort (not well supported by the operating systems which I prefer to run, missing critical hardware, etc), so I keep looking for the perfect mini system.

I thought I’d found it a while back when I splashed out on a SolidRun CuBox-i4.  It’s small (very small, in fact), has a quad-core processor, 2GB of memory, GbE, USB ports, HDMI and (a major plus) comes in a diddy little black-plastic case.  Unfortunately, it turned out to be a major pain in the proverbial trying to install and run a reasonable operating system and lots of hoops needed to be jumped through (in the correct order) to even start the OS installation.  It has been running FreeBSD for quite some time now, but it suffers greatly from the lack of a real-time-clock (and unlike a Raspberry-Pi, for instance, it’s not easy to add one), has limited USB functionality and tends to fall over in a messy heap at reboots if the moon happens to be full or the wind is coming from the east.

So the quest goes on for a truly great (cheap) mini system and, right in the middle of the purple Thursday (or was it cerise Saturday?) sales, I found a new system on GearBest that seemed too good to miss.  Because it was on sale, it was a few dollars more expensive than normal (???) , but it was still a pretty good price, given the specs.

ZX83-II Z8350-based mini-pc

It’s an Intel quad-core Atom X5-Z8350 based system, with 2GB of main memory and 32GB of eMMC.  It has GbE, two USB-2.0 ports and one USB-3.0 port.  There’s also an SD-card slot and an HDMI video connector.  For those who care (and I don’t), it also comes pre-loaded with Windows-10 (don’t ask me for more details on what specific version, because I don’t know).  It’s a 64-bit system (but read on for the limitation on that) and it also comes with built in Bluetooth and a/b/g/n/ac WiFi (neither of which I’ve used).  More importantly for me, it’s also a fanless system.  It is advertised as coming with an “English User Manual”, but you can save yourself a few seconds of “I don’t believe this crap!” frustration by throwing said “manual” straight into the bin; there is nothing in it which is even remotely useful.  It does come with a fairly substantial looking mounting bracket (to attach it to a monitor, or wall) and two HDMI cables — one short and one long(er).  A power adapter is also included (but you need to make sure that you order the correct version for your particular country).  The shipping box is also very sturdy and should hold up well if a passing elephant accidentally treads on it.

I would have been quite happy to boot into some sensible operating system and immediately wipe Windows from the disk (eMMC), but it was not to be.  The one, big gotcha with this system is the BIOS.  At first glance, the BIOS menus are very sparse indeed and you’re not going to get very far at all with this system unless you know the magic incantations (it may also help to have a spare chicken to sacrifice …I haven’t actually tried this yet, though).  I did get through quite a few blank CDs and DVDs while trying to get various distributions to boot from a USB-connected DVD.  No matter what I did though, the dang machine just kept on booting into Windows (which was quite disconcerting at first, as I couldn’t see how to shut it down).  Some ‘net searches turned up suggestions for adding BIOS passwords (there are two in the version of BIOS which my machine has) to trigger extra BIOS menu items — Nope, doesn’t work.  You can forget that.  There was also one quite long diversion where some folks (seemingly correctly) noted that some functions which affect BIOS start-up are only available from within Windows, despite how stupidly chicken-and-egg-ish this seems to be (for those who want to try it, you need to select the shutdown function from the start menu and then hold down the shift key while selecting “shutdown”.  This will bring up a whole scad of extra menus which will change the UEFI boot settings …and then it will just merrily boot straight back up into Windows again).

It turns out that the UEFI boot  (which stands for “Unified ‘Effing Firmware Interface, by the way) is the key to all of this.  It’s a versatile system which is replacing the outmoded BIOS of years gone by with an updated and secure method of booting you into Windows …and booting you into Windows …and booting you into Windows (you get the picture), no matter what you actually want to do.   On some systems (and yes, the Z83-II is one of them) it has the added twist of limiting a 64-bit system to booting from 32-bit code (you’d better go back and read that sentence again …I wrote it and I still can’t quite grok  it!).  For some reason (lost in the mists of Redmont),  Windows was/is limited to booting from 32-bit bootloaders, so because everyone-and-his-dog only ever runs Windows, some machines (like the 64-bit, Z83-II) have a UEFI which will –only– handle 32-bit bootloaders.  Now before you start jumping up and down with your hand in  the air shouting “Teacher!  Teacher! I know!  Just  run a 32-bit OS!” you should also note that, because UEFI is new-ish and 32-bit systems are just so last decade, very, very few 32-bit distributions of any sort actually have any UEFI boot capability bundled into them at all.

I know the mantra is “never give up!”, but by this stage my fingers were twitching and the old grey-matter was sending signals to my hand to grab hold of that handy, 3kg lump-hammer and send the Z83-II and its UEFI back to meet its maker in very, very small pieces.  It was only the nagging annoyance of those extra couple of dollars for the maroon Monday “sale” price that held my arm in check.

By this point I’d read so many posts and articles on the UEFI and booting systems that I’d actually stumbled across one piece of related (and essential) information which actually worked with the Z83-II.  I’d discovered already that hitting <ESC> during initial, power-on boot would bring up the BIOS menu, but in a couple of posts related to other mini-pc systems people mentioned that <F7> would bring up the boot-device selection menu.  It worked, too.  Not only did I get a device menu (what the system had detected at boot up, rather than the BIOS preferred-device list), but it also gave a tiny bit of extra information about what the system thought it had detected on each particular device.  For the most part, to begin with anyway, that information was limited to “Windows boot manager” on the eMMC device.  This turned out to useful, though.  It quickly became apparent that having a DVD in the drive with something that the BIOS (and, presumably the UEFI) could read would result in that entry in the <F7> menu changing to give the maker’s name and model, instead of just a vanilla “USB CD/DVD” entry.  Unfortunately, very few of those DVDs would boot successfully, but at least it meant I didn’t have to go through the tedious process of having the system boot into Windows, yet again,  if there was obviously no readable disk in the drive.

I’d read in a couple of places that the latest Debian versions (greater than 8.0) had solved this 32/64-bit problem, so I burned a couple more DVDs and tried them.  I could get the extra info in the <F7> menu, but they wouldn’t boot.  A couple of other mainstream Linux distributions were also flagged (in Distrowatch) as being fixed, but none of the ones I tried actually booted.  Then I came  across a reference to Ian Morrison’s Linuxium site.  Ian obviously spends a lot of time mucking about with set-top boxes, mini-PCs and PC-sticks and has done a ton of work to get Linux booting on those devices.  He has also modded some mainstream distributions to boot on these infamous 32-cum-64 bit devices.  Ian’s modified Ubuntu 16.10 was the first thing that successfully booted on the Z83-II and proved that it could successfully boot and run something other than the dreaded “W” (thanks Ian!).  If you’re looking for a stable Linux distribution you could do a lot worse than to mosey on over to Ian’s page and check out his offerings.

Finally there was light at the end of the tunnel.  The Windows reboot cycle was broken.  I went off to see what I had to do to get OpenBSD or FreeBSD onto the system.  I didn’t have to look very far.  In another one of those “Duh!” moments, it turned out that OpenBSD had also introduced the 32/64 UEFI fix and the latest snapshot (booted from a USB thumb drive this time) not only installed, but also automatically created a dedicated UEFI “i” partition and populated it with the required boot files.  Not only that, but the BIOS now “knew” about the new, bootable drive and I could easily make it the default power-on boot device.  Yay!

So, in summary …at power on, use <ESC> to get into the BIOS and <F7> to get into the boot device selection menu and use Ian Morrison’s modified versions of Linux, or OpenBSD 6.0 or greater, to prove that you can boot and install something other than “W” on the Z83-II.

…and don’t buy anything during a turquoise Tuesday sale.


 

For anyone who’s interested, the output from “dmesg” (OpenBSD 6.0) for this system is available here.


Update –  I wrote this original article just a few days before Christmas in 2016.  It’s now mid April 2017 and this little system has been running flawlessly for four months.  I have to say that I really like it.  It chugs along running as primary for all of the main services on our home network (DNS, DHCP, NTP, BOOT, Mosquitto, syslog, etc) and also works as the back-up hub for all of our other machines.  The smaller, single-core machines on the network send their uncompressed dump files over the network and this machine pipes the data through the “xz” compressor (running on two of the four cores) before storing it to disk (the multi-core systems compress their data before sending it).  The dump disks are on the USB3 bus and the throughput with the GbE network is a big improvement over USB2 and 10/100.  The killer months are yet to come, though.  This is a fanless system and, over the last four winter months it has been just mildly warm.  It remains to be seen how it will  deal with a hot, humid Japanese summer.  I’ll be sure to let you know, either way.


Update – Sept 2017 –   Well, we’re “over the hump” of the blazingly hot and steamily humid summer weather and this little system has just chugged along, right through the worst of it.  I also threw some fairly heavy-duty, very large (hundreds of gigs) compression jobs at it during the height of August and monitored the CPU temperatures fairly closely (this wasn’t any sort of benchmark; it was work that needed to be done and I was quite worried that this fanless system might shut itself down half-way through, so I was keeping a close eye on it).  With an ambient temperature hovering around 40C, the CPU reading never got above 82C, with the “xz” compression tasks limited to two cores (“xz  -T2”).  That’s hot, but not hot enough to melt anything.

 

A non-ESP8266 aside …getting OpenBSD to boot on the SolidRun CuBox-i4

ESP8266 readers …normal service will be resumed as soon as possible; I just wanted to get this info out somewhere where the bots/spiders would pick it up.

Important– There are several updates appended to the bottom of this article.  Even if you don’t read anything else, please read the updates.  There are now so many updates that they’re longer than the original article, so here’s a mini index:-

  1.  – Getting a USB keyboard to work with the CuBox.
  2.  – Getting external USB devices to work.
  3.  – Network issues on 10/100Mbs networks during install.
  4.  – Installing OpenBSD onto an external device.
  5.  – Enabling default boot from an external device.

     ‡   – Note on accessing U-Boot.

I recently bought a CuBox-i4 for use as a gateway, mainly based on the fact that it would (according to the blurb) run a gazzillion different versions of Linux, Android (whatever that is! :-)) and, according to the latest info on the OpenBSD ARMV7 page, OpenBSD 5.8, too.

Well, as usual with these things, all did not go according to plan.  The OpenBSD installation notes don’t have anything specific for the CuBox, but the general instructions are “dd the miniroot-cubox-58.fs to your SD card, bung it back into the slot and apply power” (I paraphrase slightly).  Having connected a monitor via HDMI and a USB keyboard, I dd’ed, bunged and powered.  The monitor sprang into life, came up with the SolidRun header and a very brief (3-second) countdown, flashed another 10 odd lines on the screen much too quickly for anyone to read and then …went black again.  I repeated the process several times (and was never able to read the quick-as-a-flash message), but with no success.  I tried several different SD cards – no change.  I tried a couple of the other images – yes, something changed …the red light no longer came on and the monitor didn’t even show the initial countdown.  The bottom line was though, I couldn’t seem to get OpenBSD to boot.  It’s also worth noting that the “Hit any key to interrupt boot sequence” did NOT work with the USB keyboard (interesting, since there doesn’t seem to be any other way of connecting a keyboard to the system [See Update#1, below]).

Just to make sure that everything was okay with the CuBox itself, I loaded a couple of different Linux distributions and booted them successfully.  I also ran SolidRun’s “Ignition” initializer/chooser, which worked fairly well, but slowly (if you can use “dd” it’s not really worthwhile waiting for Ignition to do its stuff).  The bottom line was that the CuBox itself and the SD cards all worked fine with different distributions.

Finding the Micro-USB port
CuBox4i Ports – Photo courtesy of SolidRun

Back to the OpenBSD installation guide …the instructions for the BeagleBone (the only detailed instructions in the guide) were based around a serial console connection, so the next step was obviously to try to access the console on the CuBox.  I had completely overlooked the micro-USB connector in the specs when I ordered the box and then, going to the SolidRun web site and browsing their forums, things started to become clear murky, very, very murky (hence this post).  On the SolidRun product spec page they label this port (number “9” in the photo) as “Micro-USB to RS232” and that’s basically it.  In the forums there’s a whole load of waffle about what this actually means and what voltages are available where, what sort of USB-to-Dsub adapter you need(?!?!), etc, etc.  What a load of cobblers!  Plug a damn USB cable into the Micro-USB port, plug the other end into a USB socket on whatever machine you have handy.  Fire up minicom, screen, pooty, or whatever other comms program you have, setting the baud-rate to 115200 along the way and you’re in business.  [SolidRun – The world doesn’t care if you have a fully-fledged RS232 port hidden inside your amazingly small box.  Just try to de-obfuscate your specs a little and try to give the rest of us a bit of a clue …something like “Micro-USB console connector (default 115200 baud)” would do fine]

Okay, so now I plug in the same SD card, with the same miniroot image and lo, the machine boots into the OpenBSD 5.8 installer just fine. Phew!

Now I said it booted …I didn’t say I actually managed to get it to install.  So far I’ve booted it from SD and across the net, using tftpboot.  I’m blown away by how good U-Boot‡ is (very, very cool!), but disappointed with my installation attempts so far.  It seems that the installer kernel doesn’t recognize any other device plugged into the (normal) USB ports and, in addition, throws I/O errors whenever I try to do anything with the SD card, so at the moment, I have the installer, but I can’t actually install anything.  Duh!  I’ll keep trying and update this post when (if) I find the answer.  In the meantime, if anyone has already got this to work, please do add a comment to enlighten the rest of us.

TLDR;Summary:-  You need to connect a USB cable between the micro-USB port on the CuBox and another system running a terminal-emulator/comms program to be able to interact with U-Boot‡ and to see the output from the OpenBSD kernel/installer.

Update #1 – The USB keyboard issue (not interrupting the U-Boot‡ process).  It turns out that the answer to this one is quite simple …the USB keyboard must be plugged directly into the bottom of the two USB ports.  This is one of those things where even just half a page of documentation in the box would save a lot of people a whole shirt-load of time.

Update #2 – This is really just an addition to #1 …as well as the keyboard, other devices will only work reliably if they are plugged into the bottom port.  So, if you want to install to a USB drive (USB-thumb, or HD), you’ll need to plug it into the bottom port, or plug a powered hub into the bottom port and plug your USB drives and devices into that.  This, it turns out, is a known issue with OpenBSD on the CuBox-i4.

Update #3 – When the going gets weird, the weird get …baffled.  You’ll remember that I noted above that I’d successfully booted the installer using TFTP from another server on my home network.  Well, after going through all of the initial set-up in the installer, I selected the HTTP install type, hit and …”Unable to retrieve file list from ftp.openbsd.org”.  I changed the target server and tried again …same result.  Dropping back into the shell and doing an ifconfig -a showed the status on interface imxenet0 as “no carrier” (this was the same interface which had just downloaded the tftpboot image a few minutes earlier). WTDF!?! (where “D” = Double).  Trying to bring the interface back on line with ifconfig imxenet0 up had no effect. Trying to alter the media type produced weird results; the media line in the ifconfig display would show the requested media type, but followed by a completely different setting in parentheses, for example media: 100baseTX full-duplex (10baseT half-duplex).  I knew for a fact that the network switch which the cable was plugged into was a 100baseT full-duplex connection, so it was logical that the 100baseTX selection should have worked, but it didn’t.  I worked through the various types that ifconfig imxenet0 media showed for that interface (wet-string, paper-cups, sneaker-net, etc) and, finally, 1000baseT mediaopt full-duplex gave me a live network (with the media line of ifconfig telling me “1000baseT full-duplex (100baseTX full-duplex)“.  I have absolutely no idea what’s going on with the imxenet driver, but it seems like copying the code from the U-Boot repository might be a safe bet for the next release.

Okay, so we can now get our interface initialized and working, but how do we use it inside the installer?  Fairly simply, as it turns out.  Boot the installer, go through the first few steps, including the network set-up using the actual values for IP addresses, gateway and DNS server that you’d like to use and then just interrupt the installer (with a C) when you get to the network “done” stage.  Then, at the shell prompt, reinitialize your interface using the same IP address, but with the media type and options specified as above, so it looks something like this:-

ifconfig imxenet0 media 1000baseT mediaopt full-duplex 192.168.1.200 netmask 255.255.255.0 up

…and check that your interface is now live (you should be able to ping local IP addresses and to ping your CuBox-i4 from other systems).

You can now get back into the installer by simply typing install.  When you restart using this method, the installer will give you your previously input answers as the defaults when going through the prompts, making it easy to speed through the stuff you’ve already done.

-Important-  When you reach the “network interface to configure? [imxenet0]: ” you must type “done" to prevent the installer from changing the configuration you’ve just gone to such pains to get working.  From this point onwards you can simply follow your normal installation procedure.   Phew!

It’s worth noting here that this problem only seems to occur when installing on a 10/100Mbs link; when I plug the CuBox into a Gbe switch connection the install goes all the way through without a hiccough. The issue (on the slower network) still occurs with OpenBSD 6.0.

Update #4 – Well, there’s yet another wrinkle here that you need to work around to complete the install and that’s how to write to the SD card (which shows up as drive “sd0”) from the OpenBSD installer.  As you may already have found, you can’t.  Selecting “sd0” as your target disk in the installer leads to a long string of “I/O error” and “write failed” messages, with the labelling,  partitioning, filesystem build and mount procedures all just ignoring the failures and speeding merrily on their way (doesn’t anyone check return values, nowadays?!?).  It seems that the installer can’t write to the MMC slot on the CuBox, even though it can read it (earlier on we booted the installation image from it).

The answer to this is to use a USB card reader/writer plugged into the bottom USB socket on the CuBox .  Plug a second SD card into the reader/writer and restart the installer.  The second card should show up as “sd1” (it’s worth making sure that you positively identify your target card at this point …it could make a bad day even worse if you scribble over something else by accident) and should be writeable by the installer.  As the OpenBSD /etc/fstab uses the drive serial identifier (rather than the old fashioned device name) nowadays, you should be able to move sd1 from the reader/writer into the SD slot on the CuBox without any issues, once the installation has successfully completed.

Once your system has rebooted into the newly installed 5.8 on the second SD card (now installed in the CuBox SD card slot) it will somehow, magically be able to write to it and you can take your CuBox out for a test drive …just don’t try to run “top” (C’mon! I just told you not to do that!).

Update #5 – Once you have OpenBSD booting and that first flush of exhilaration is gone, you realize that you need to get your OS onto something a little speedier and a lot more robust.  The issue you then hit is that the CuBox itself is pretty much a bare metal device and won’t boot unless it has an SD card in the slot …and once it finds that SD card, no matter what the fstab says, it doesn’t want to let it go and will stubbornly refuse to mount root from the external disk.  That kinda’ defeats the purpose of the exercise.

However, it turns out that U-Boot‡ can help us with that.  Buried deep within the environmental settings is “boot_target”, which is basically the same as the old BIOS settings for a preferred boot-device list.  The default list is “mmc0 sd0 pxe dhcp”, so all we need to do is to change it to boot the SCSI disk as it primary, using this command:-

setenv boot_target sd0 mmc0 pxe dhcp

saveenv

The “saveenv” is critical, as it (as the name implies) makes the change permanent across power cycles.  Note that there’s no “=” between the setting name “boot_target” and the list of devices and there are no quotes around the members of the list; everything on the command line is simply space-separated.

 

‡ Accessing U-Boot is simply a matter of pressing any key (on the USB keyboard you have attached to the -lower- USB port, or on the terminal you have connected to the mini-USB, front-panel port) within three seconds of powering on the CuBox.  Type “help” to get a list of commands (-warning-, steep learning curve ahead).

§ The secret incantation to enable booting the CuBox from an external disk is in “Update #5”, above (just in case you’re a Ooleg-bot and missed it).