Another x86 SBC

I wonder what the likelihood might be that the Jaguarboard kickstarter SBC could work with FreeBSD. (Apparently it uses an Intel Z3735G (Atom?)). It's interesting because the power requirements seem very modest (2A@5V) - which means I could probably re-use my Pi and Odroid supplies with this x86 board. I still occasionally have a need to use the x86 software that my ARM SoC SBCs can't run.

It's also quite a bit less expensive than most of the other x86 SBC boards I've looked at. What else would be comparable, and known to work with FreeBSD, that has low power consumption (the main requirement)?
 
Wow, they aren't doing themselves any favors with that kind of checkout. The board's a little skimpy on GPIO (4) and I2c (only 1), but I guess it's kind of relative to what else is out there. Since you could'nt check out, I guess I'm still looking for a guinea tester so I don't end up with another adornment on the bottom of my junk drawer :)
 
I was able to checkout but opted not to pull the trigger. It was not a breezy checkout. I did it to see the shipping cost.

You mentioned GPIO so I thought I would throw this out there. x86-amd64 GPIO's will not work unless you write a driver. There is only 2 drivers I know of for Intel GPIO's. Soekris and APU1C. Turbot would be a nice board for GPIO's but no driver.

I also thought of hacking together a serial port driver to work with gpioctl. It is a nice interface for controlling pins. Serial ports might be generic enough to write a driver for multiple platforms.
 
Phishfry: The board's main site includes a tutorial for using a Ubuntu GPIO driver, so it seems that it could be ported to FreeBSD:

http://jaguarboard.org:8090/display/ED/An+example+of+using+GPIO+in+Jaguarboard

But yes, the problems with mixing the x86 platform and GPIO send me running back to the ARM boards. I do sometimes need to use the x86 platform, so I'm searching for a low power offering that could do the job, and not break my battery bank. The board's <=10 watts of power dissipation beats the 95W that my ASUS uses by a country mile. (Perhaps this particular board is not the end of the search. I can't say that I know very much about it, other than seeing both positive and negative reviews). To make the x86 boards talk to GPIO I've considered using the USB/GPIO units that I mentioned in another thread, but lately I've been playing with a work-around that uses the Photon boards, which are nifty little GPIO laden devices that can be controlled from a FreeBSD box via WiFi.
 
Turbot would be a nice board for GPIOs ...

In terms of stability, how is the Turbot doing with FreeBSD + graphics (X)? It seems it could be a very convenient low-power-rate x86 desktop. It might be nice to be able to use a USB (DisplayLink) monitor with it, since that seems to halve the normal power consumption rate of monitors (~7 watts for a 16" AOC monitor - albeit this seems to be done (IIRC) at the cost of lower brightness specs). Most reviews say the brightness is acceptable on them. Don't know the state of DisplayLink on FreeBSD though ...
 
I also thought of hacking together a serial port driver to work with gpioctl. It is a nice interface for controlling pins. Serial ports might be generic enough to write a driver for multiple platforms.

For some things, that's probably viable. It doubles the GPIO one would ordinarily have on a Minnowboard. I don't know if you remember the parallel port hacking days or not. Kinda similar. I found a nice article for using FTDI in that way. The ftdi code is there already - in libftdi - and it should be pretty easy to match that up with gpioctl, or just write something else as a control interface:

http://hackaday.com/2009/09/22/introduction-to-ftdi-bitbang-mode/

Anyway - the Photon is cause for me not to want to mess with any of those "alternate" GPIO methods. It runs FreeRTOS, is so simple to use, and seems to be the easiest bridge between the main monitoring system (say, FreeBSD on x86 or ARM) - and the sensor banks. I think for me that device is taking over almost all of the GPIO related stuff relative to my needs. The caveat is that it is still fairly new, and of course might still have "issues" to work out. Also, I have to consider that some things are not appropriate for WiFi monitor or control links (since WiFi can be interrupted). But, I like the idea that I have only one target to devote energies to ...
 
Turbot works with xorg via scfb. That may have changed for the better. There was also a small issue with booting off the microSD.
The expansion board on the bottom is nice for working msata and wifi. A GPIO driver would make it more versatile.
My complaint is the UEFI-only firmware. This limits the choice of operating systems.
It can take coreboot/seabios but requires the SPI flasher I believe.
The board was very stable. I fried mine testing it with a 6V SLA battery. It was a costly mistake. I am always pushing things.

I wonder if the other $89 small Intel boards are using UEFI-only firmware.
http://hackerboards.com/udoo-spins-89-dollar-intel-braswell-hacker-sbc/
https://www.solid-run.com/intel-braswell-family/

I investigated GPIO over serial and usage maybe possible to use a couple of pins. LPT ports were more common for DIO as you note.

The Baytrail GPIO driver from OpenBSD has a different layout with ACPI stuff. Might strip those bits out and see what it does.
 
Turbot works with xorg via scfb. That may have changed for the better. There was also a small issue with booting off the microSD.
The expansion board on the bottom is nice for working msata and wifi. A GPIO driver would make it more versatile.
My complaint is the UEFI-only firmware. This limits the choice of operating systems.
It can take coreboot/seabios but requires the SPI flasher I believe.
The board was very stable. I fried mine testing it with a 6V SLA battery. It was a costly mistake. I am always pushing things.

I wonder if the other $89 small Intel boards are using UEFI-only firmware.
http://hackerboards.com/udoo-spins-89-dollar-intel-braswell-hacker-sbc/
https://www.solid-run.com/intel-braswell-family/

I investigated GPIO over serial and usage maybe possible to use a couple of pins. LPT ports were more common for DIO as you note.

The Baytrail GPIO driver from OpenBSD has a different layout with ACPI stuff. Might strip those bits out and see what it does.

I guess the UEFI problem will eventually be solved, but for some of the more obscure hobby OSes, it may be a long wait. I don't think NetBSD has tackled the problem yet, but I'm not sure about that. FreeBSD and Linux seem to be the choices now. For a BIOS system, one can always retreat a few years, and try to find a good deal on a liquidation of older boards like the 800 MHz Vortex86DX. IIRC those boards usually came with an AMI SPI flash BIOS, and I have read somewhere (I think) that they worked with older versions of FreeBSD (7/8). Also - the power consumption (my main concern) - is about two watts on those older CPUs.

Edit 10/26: I managed to find a good deal on one of the older (2007) Vortex86DX boards. It has 1x16 GPIO, three serial ports, three USB2, 1 RS485, LVDS, 1 parallel port, VGA, IDE, i586 BIOS, 512 RAM, 800 MHz, JTAG, audio stereo (in and out), three wired ethernet ports, and seems to work fine with the FreeBSD-10.2 i386 CD running on a USB/CD/DVD drive. For some reason, it doesn't yet boot on a stick, but haven't played too much with it yet. The power supply is a 5V, 2A wall wart, which is only a little warm after a half hour. It's about 6 x 4 inches in size. The trick now will be to find drivers to work with it (like GPIO) ... probably those have to come from Linux, and ported. Supposedly it'll run XP, but I'd never do that.

In any case, this one won't be an adornment on the bottom of my junk drawer (voice of experience)!
 
Last edited:
Back
Top