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. ...
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.
FDT overlay is an extension to FDT format that lets user to modify base FDT run-time: add new nodes, add new properties to existing nodes or modify existing properties. It’s useful when you have base board and some extension units like cape/shield for Pi/BBB or loadable FPGA logic for Zynq. I will not go into details you can find internals described on Adafruit or Raspberry Pi websites. When dealing with overlays there are two options where to handle them: loader or kernel. Managing overlays at kernel level gives more flexibility but requires more related logic, e.g. re-init pinmux after applying overlay, re-run newbus probe/attach. On the other hand loader-level support is quite straightforward and involves nothing but DTB modifications and it’s a natural first step to adding FDT overlays to FreeBSD. ...
Build SD card image using crochet-freebsd with option VideoCore enabled. Mount either SD card itself of image to build host mount /dev/mmcsd0s2a /pi Checkout Qt5 sources and patch them cd /src git clone git://gitorious.org/qt/qt5.git qt5 cd qt5 git checkout 5.4.0 MODULES=qtbase,qtdeclarative,qtgraphicaleffects,qtimageformats,qtquick1,qtquickcontrols,qtscript,qtsvg,qtxmlpatterns ./init-repository --module-subset=$MODULES fetch -q -o - http://people.freebsd.org/~gonzo/arm/rpi/qt5-freebsd-pi.diff | patch -p1 Configure, build and install Qt5 to SD card ./configure -platform unsupported/freebsd-clang -no-openssl -opengl es2 -device freebsd-rasp-pi-clang -device-option CROSS_COMPILE=/usr/armv6-freebsd/usr/bin/ -sysroot /pi/ -no-gcc-sysroot -opensource -confirm-license -optimized-qmake -release -prefix /usr/local/Qt5 -no-pch -nomake tests -nomake examples -plugin-sql-sqlite gmake -j `sysctl -n hw.ncpu` sudo gmake install You need BSD-specific plugins to enable mouse and keyboard input in EGLFS mode ...
With stable VCHIQ driver next obvious target was to add VCHIQ-based audio support. So let me introduce to you: vchiq_audio, first take. It’s part of vchiq-freebsd repo so if you use Crochet to build SD card image just enable option VideoCore in config file and module will be automatically included. From shell run kldload vchiq_audio and you’re good to do. I believe that audio output is picked up automatically by VideoCore so if you have HDMI connected it’s probably going to be HDMI. I do not have device to confirm this. Adding knob to control audio output (auto, headphones, HDMI) is on my ToDo list. ...
QEMU support in FreeBSD/armv6 regressed since I tried it last time few months back. Changes in FreeBSD kernel and in QEMU itself revealed bugs that were masked by previous behaviour. In FreeBSD it was r248467: the way memory/IO resources are activated on FDT bus has been changed and it triggered bug in versatile_pci.c The other issue is more complex. It seems that PCI IRQ routing in QEMU was out of sync with real hardware. So after commit 66a96d7018b9cbabb73c9b87b62a37e4cc46580a IRQ numbers assigned to PCI devices by FreeBSD kernel by default were invalid. Authors of QEMU eventually added compatibility knob to fall back to previous logic. So if you’re using QEMU 1.5 or later add this option to your command line: ...
Quick hint. If you did not disable “device sc” in kernel config all the message from kernel go to video console. But if something bad happened after kernel started and before framebuffer driver is activated all you’ll see would be “Kernel args: (null)” message on serial console which is not very helpful. So in order to debug this problem and have kernel boot messages on both monitor and serial port without recompiling kernel just add following line to /boot/loader.rc on SD card: ...
I’m trying to wrap up some project I started working on quite some time ago and this is first chunk of clean-up. Patchcontains: Kernel config for AM335x EVM dts file for AM335x EVM with TFT panel info LCD controller driver with some functionality missing: only 24/32 bit depth and only TFT mode is supported Really simple PWM driver. LCD backlight is controlled through eCAS submodule of PWMSS0 module. I tested it only on evaluation module, although I think with proper panel/pinmux configuration it should work with BeagleBone’s LCD caps too. Parts missing: adjusting clock to proper pixel frequency, proper allocation of framebuffer memory.
Writing new driver for FDT-based device always involves several simple steps: writing generic newbus driver skeleton Checking for compatibility of node in probe routine Allocate memory/IRQ resources in attach routine I can’t say for other developers but I just copy existing driver, remove all device-specific stuff and rewrite generic stuff. Which is less time-consuming then writing it from scratch but time-consuming it is. Being huge fan of automation of any kind I decided to let computer do all this dumb work and leave creative part (copy-pasting registers definition from spec to code) to myself. the result is this script. ...