As with the previous post, please forgive this essentially non-ESP8266 related article (it is actually loosely connected, as the CuBox-i4p will be a gateway server). Normal (ESP8266) service will be resumed as soon as possible.
As you may have seen from the previous post, I’m having difficulty getting OpenBSD installed on the CuBox-i4p (four-core ARM with 2GB of memory and a Gbit Ethernet interface). As I wasn’t getting anywhere fast with OpenBSD, I decided to give FreeBSD a go, as I already have an ARM box (an RPi-B) running 10.2 quite happily. Downloading the FreeBSD release was a doddle (once you realize that you can ignore the “build using crotchet” advice scattered around on the web) and I dd’ed it to an SD card without any special, magical options. Booting wasn’t quite so trouble free, though.
Having learnt (a little) from the OpenBSD experience, I plugged the USB keyboard into the bottom port, inserted the newly minted SD card and powered on. The monitor sprang into life and the SolidRun header appeared (Yay!), but there was no countdown from U-Boot, so there was nothing to interrupt with a key-press. And there it stuck.
It seemed likely that the CuBox was squirting boot info to the semi-secret micro-USB port, so I dutifully connected up my laptop and started “screen” (and, in yet another aside, I’d just like to say a big “Thank You!” to the guys and girls at the Technical University of Berlin for a program which has been invaluable to me for more years than I care to remember) and found myself at a “loader>” prompt. Not quite what I’d expected, or hoped for, but at least there was life in the little beastie. Typing in “boot” got me a semi-sane looking initial boot sequence, but immediately after starting to load from the SD filesystem it bombed out with “No device tree blob found”. Duh!
On my previous foray into the land of U-Boot I was impressed how versatile it was and how easy it was to boot the OpenBSD installer from my tftpboot server. Having said that though, I’m definitely a U-Boot newbie and, besides, it looked rather as though the problem lay with the FreeBSD loader, rather than U-Boot itself (which rather surprised me, as I’d assumed that the 10.2 release would just work — feel free to correct me if you know that I’m pointing the finger of blame in the wrong direction). Anyway, I vaguely remembered a short thread on the FreeBSD mailing list about boot problems with the Hummingboard (another SolidRun product) and, in the course of searching for that thread, came across another, much longer one where the inimitable Ian Lepore came up with the answer:-
setenv fdt_file imx6q-cubox-i.dtb
It took me a little while to realize that this was, in fact, to be executed from the U-Boot prompt, not the loader, but once I’d restarted, interrupted the countdown from the console and typed in the magic incantation, everything sprang into life and the kernel loaded without a problem. It turns out that U-Boot passes some environmental variables to the FreeBSD loader and, for whatever reason, the initial set-up of those variables isn’t working quite right for the SolidRun hardware and, while the device-tree blob file (under /boot/dtb) is actually there, it’s not being correctly identified. The
setenv command (above) sets the correct file name in U-Boot, which is then imported by the loader, leading to much joy and jubilation. The
saveenv ensures that the variable remains set between reboots. Once your FreeBSD system comes up, you probably still won’t have anything on the monitor, but you will be able to access your system via the network (remember, SSH root access is disabled, so use the “freebsd” username [passwd “freebsd”] to access the system and then su to root from there).
So there you have it …even if we can’t get OpenBSD to install quite yet, we can still get FreeBSD up and running (and, for those people who are about to leave a “Why don’t you use Linux, it just works” comment, I would ask you in return to try this little experiment — boot a *BSD system and a Linux system. On each machine, type “ps ax” and then for each running process just try doing “man <process-name>” and let me know how you get on). 😛