To those who do not track FreeBSD commit messages: I committed gpiokeys driver to -CURRENT as r299475. The driver is not enabled in any of the kernels but can be built as a loadable module. For now it stays disconnected from main build because it breaks some MIPS kernel configs. Configs in question include “modules/gpio” as part of MODULES_OVERRIDE variable and since gpiokeys can be built only with FDT-enabled kernel the build fails. ...
Qt 5.6 is finally out so I thought I’d give it a spin on my Raspberry Pi. Previously I used cross-compilation but this time I thought I’d spend some time in trying to create ports Qt modules. There is Qt 5.5.1 in ports and it’s nicely split into sub-ports and most of gory details are hidden in bsd.qt.mk library. The problem with it is it’s highly coupled with Xorg stuff and I didn’t find easy way to squeeze non-desktop use cases into current infrastructure. So I just created new custom devel/qt56 port. ...
Being able to power cycle ARM boards remotely (without spending a lot of $$$) was on my wish list for way to long, so I finally got around to put something together. The obvious way to do this is power relay controlled by GPIO + remotely accessible GPIO port. For the former I picked up this relay by Digital Loggers. It was four ports, only two of them are connected at a time, you can switch selected pair by setting control port level. For a controller part I picked up RIoTBoard but actually any ARM board with sshd running on it and user-accessible GPIO pin would do. ...
Back from vacation and back to work. Once I got RIoTboard up and running next natural step was to wrap up some i.MX6 project I had in “almost finished” state for months. So now they’re in “going through review” state: drivers for HDMI framer and IPU. They add basic 1024x768 console for iMX6 board. Video mode management requires more sophisticated timers framework, that is being work on as a part of Jetson TK1 port.
My career as a trendy videoblogger starts to pay off. Nice people from Newark element14 offered to send me some hardware for experiments (no strings attached) I took them up on their offer and few days later received RIoTboard. It’s iMX6 Solo in developer-friendly package, not as compact as Beaglebone but nicely built and comes with more connectors. FreeBSD’s iMX6 support is very good, so it took two one-line fixes to FreeBSD kernel code to make it work on RIoTboard. The other chunk of work was U-Boot package. Took more time than it should have due to some operator errors. The bring up process is more or less the same as for any other iMX6 system, so it should be really easy to add this board to crochet. Step by step it looks like this (some of the code came from crochet): ...
Quick update on progress in FreeBSD’s support of Raspberry Pi: VCHIQ driver was updated to the latest vendor code and bunch of FreeBSD-specific problems was fixed: locking, handling of non-cacheline aligned data Raspberry Pi userland code was updated to the latest vendor code Mikael Urankar created misc/raspberrypi-userland for userland libraries/utilities Mikael also created multimedia/omxplayer port for OMXPlayer, video player developed for RPi. It’s also used in Kodi player on Pi. I created misc/ioquake-pi port to make it easier for people to try it out I put together all this stuff on my brand new Pi 2 and recorded demo that showcases, OpenGL, Quake3, omxplayer, camera, and audio. I hope all these ports will be committed/updated before next round of armv6 packages build. ...
Received yesterday and had to assembly it first thing today. Display part works like a charm without any system modifications. Haven’t researched touchscreen part though.
And yet another demo of 4DCAPE-43T, this time it’s touchscreen. On AM335x SoC touchscreen controller is coupled with analog-to-digital converter, for which there is a driver in FreeBSD HEAD: ti_adc. I had to implement touchscreen part and add driver userland communication protocol. For proof of concept I used significantly dumbed-down version of Linux input event protocol. tslib serves as a userland part of the demo. I believe it’s de-facto standard for touchscreen devices interface in Linux world. Only two things were changed comparing to stock one: I added bsd-raw input plugin to communicate with kernel and rewrote framebuffer-related routines. ...
I like Qt. It runs on everything. More than 10 years ago you could run it on Linux/ARM on Sharp Zaurus and now you can run it on FreeBSD/Pi. I thought it would look neat on LCD screen on BBB and coded small demo player (qt-demo-player sources) just for the fun of it. Stock Qt does not have FreeBSD framebuffer support so I had to hack it up (qt-platform-scfb sources). Also it seems they still consider FreeBSD/clang second class citizen comparing to FreeBSD/gcc which causes some minor POSIX-related incompatibility fallout. But other than that it was smooth sailing, patch against vendor tree is really small. I’ll post it later along with build instructions. In addition to scfb platform support Qt console input plugins required: qt5-bsd-input ...
Short demo of FreeBSD running on Beaglebone Black with 4DCAPE-43T https://www.youtube.com/watch?v=4Vn_L_UzQhc I used vendor-provided am335x-boneblack-4dcape-43t.dts file to generate dtb, you can download compiled blob here. The system running on demo is gpiokeys branch of my git repo: . Patch against -head is here. If you’re interested only in LCD screen - it’s supported by -head but you’ll need to either add device gpiobacklight to BEAGLEBONE kernel config or enable LCD backlight manually using gpioctl: gpioctl -f /dev/gpioc1 18 1. gpiokeys is somewhat more complex thing and still WIP, there are some pieces missing in HEAD I had to hack around to make them work. And I haven’t started research on touchscreen yet.