Archives For ARM

VCHIQ drivers work again

January 13, 2013 — 7 Comments

I synced both vchiq-freebsd and userland to latest and greatest.

As I mentioned earlier – OS compatibility shim was removed from upstream sources so I had to create Linux KPI implementation layer which turned out not that awful task because I managed to reuse a lot of code from Max Khon’s DAHDI port. I had to implement (in somewhat hackish fashion) kthread API, re-implement semaphores support using condvar and mutex in order to get _interruptible part of API working properly and create dumb implementation of rather small subset of Linux list.h API.

With latest code I got pretty much all demos in hello_pi working except hello_jpeg(crashes system) and hello_encode(didn’t test). The most exciting bit for me was watching H.264 video playing on Raspberry Pi in hello_video demo. Network throughput still sucks so I had to copy file to tmpfs partition in order to get smooth playback though.

If you want to test VCHIQ – in addition to sources you’ll need latest firmware files. For demos you’ll also have to install freetype2 and manually hack Makefile.include in hello_pi. I’m planning to create ports/packages for both drivers and userland some time next week.

On the related note: Aleksandr Rybalko got XOrg working on Efika MX Smartbook so FreeBSD/Pi will get graphic interface soon :)

In ARM, FreeBSD, Raspberry Pi
permalink

FreeBSD/armv6: what’s new and exciting?

December 30, 2012 — 15 Comments

It’s been a while since last update on the project status so it might seem as there was no progress in this area. The reality is: there is a bunch of activities happening with various levels of success. So I decided to give kind of end-of-the-year round-up of ongoing projects, plans and obstacles ARM hackers face.

First of all we tried switching default cache type from write-through to write-back type. It should have increased performance but instead opened a can of worms. Memory corruption debugging led to L2 cache driver on Pandaboard, EHCI driver code and subsequently to busdma code. Whole process took quite a few days full of hair-pulling and nagging various people and ended up in committing USB fixes and Ian Lepore’s busdma patches. PL310 (L2 cache controller) driver is being tested at this very moment. Original issue (WB caches) still stands and postponed till next year.

Then there are two projects by Andrew Turner aimed at modernizing FreeBSD/armv6 subsystem: switching to EABI and clang support for ARM. Daisuke Aoyama took both of them and produced working image for Raspberry Pi. He also fixed two issues with event timers on Raspberry Pi so now the platform is much more stable. I ran buildkernel in a loop overnight and by the morning Pi had survived 7 cycles and still was alive and kicking. I also managed to get python built and working on it. Didn’t have 100% success with perl 5.14/5.16, ports were built but failed at install stage segfaulting in do_clean_objs function.

My Pandaboard survived overnight buildkernel loop with L2 cache disabled, but acting up if I enable it. Investigating.

Then there are also several platform bring-ups in progress. Alexander Rybalko works on getting FreeBSD running on Efika MX Smartbook. Ganbold Tsagaankhuu hacks on Allwinner 10. Alexander Dutkowski’s hardware of choice is BeagleBoard-xM.
Ruslan Bukin experiments with Exynos4412 and Thomas Skibo reported about FreeBSD running on Zedboard (Xilinx Zynq-7000).

But what about devices/platform we have in tree? I have limited knowledge about some platforms so here is summary of the ones I’m aware of. If you have more information on any of these targets (or any other ARM-related projects) – let me know, I’ll update post.

  • BCM2835 Raspberry Pi the most accessible and therefore the one that gets the most exposure and testing. Pretty stable, considering. Supported devices: USB, network, MMC, GPIO, framebuffer, GPU. The rest is on ToDo list. VCHIQ driver is BSD-licensed now and I’m planning on getting it to sys/contrib. Userland bits of OpenGL ES should be added as a port though.
  • (update) LPC32x0 No first hand experience but judging by the code it supports MMC, FB, GPIO and USB
  • Marvel Armada XP I don’t have information about this one, sorry
  • Nvidia Tegra2 Just barebone boot stuff.
  • TI AM335x Examples: BeagleBone, TI Sitara EVM. Network was reported working but unstable on BeagleBone. USB is not supported. Haven’t tested GPIO yet.
  • TI OMAP3 Example: BeagleBoard-xM. See Alexander Dutkowski’s project
  • TI OMAP4 The hw I have – Pandaboard ES. Supported devices: USB, network, MMC, GPIO. Some issues with L2 cache
  • Versatile Platform Board Exists only as emulation target for QEMU. Supported hardware: PCI, network, framebuffer. Seems to be fairly stable, no extensive testing performed.

BeagleBone, PandaBoard ad Raspberry Pi images can be built using Tim Kientzle’s scripts.

Not really stellar list of supported peripherals I’d say. I tend to blame several things.

First – experimental and unstable state of FreeBSD/armv6 in general. It’s no fun adding new hardware support when you’re not confident in underlying subsystems stability. “I flush cache for this TX descriptor but is it really gets flushed?”. Been there, no fun at all. That’s why I believe task #1 for nearest future is maximum performance and rock-solid stability of what we have.

Then there is the case of syscons. It’s old, it’s inflexible and it’s mostly i386-centric. Just until recently most of our so-called embedded targets were headless so there were no pressure from this side to reorganize things. My experience with coding two framebuffer drivers or trying to add PS/2 keyboard support on non-i386 platform was not very pleasant. It’s messy and there is a lot of code duplication. newsyscons project may be the way to go, I haven’t looked at it yet. We just need someone(tm) to finish it and get into the tree.

Fix these two issues should make bring-up process easier. It leaves us with question of GPU support. But it’s different story for different post…

Happy New Year, everybody!

In ARM, FreeBSD
permalink

FreeBSD/armv6 in QEMU

December 5, 2012 — 3 Comments

First take at getting FreeBSD/armv6 running in simulators. Simulators are great for tracking down nasty bugs and building packages.

So here is support for Versatile Platform Board machine supported by QEMU. Most likely this code will not run on real VersatilePB because I do not have this hardware and timing code (or lack of it) on CLCD driver and Keyboard/Mouse interface (PL050) is pure guesswork.

Back to gory details:

Build

You’ll need this patch and this script. Apply patch, use script to get freebsd-versatilepb.flash.

As for userland – it’s fully compatible with Raspberry Pi’s userland, or Pandaboard’s one. So you can use latest RPi SD card image. As for now it’s freebsd-pi-r243778.img.gz (124Mb)

Run QEMU

I believe that at least QEMU 1.2.0 is required. It’s still 1.1.1 in ports due to some blockers that prevent upgrade to 1.3.0. This patch updates port to 1.3.0 and it worked for me. Also I tested images with QEMU on windows and OS X – works fine.

qemu-system-arm -M versatilepb -m 128M -kernel freebsd-versatilepb.flash  -cpu arm1176 -hda freebsd-pi-r243778.img

Caveats

  • Serial console is off by default, use graphics console. If you need headless mode, rebuild image with “device sc” and related options disabled or use prebuilt flash image for headless mode
  • root device name is hardcoded so if you’re using some other image or building your own – be sure that’s ROOTDEV actually match real root
  • Memory size is hardcoded – 128M. For getting this information run-time we’ll need uboot and ubldr added to boot chain

Prebuilt kernels

freebsd-versatilepb.flash (4Mb)
freebsd-versatilepb-headless.flash (4Mb)
MD5 (freebsd-versatilepb-headless.flash) = 24a41807bf94c5fec0565adcfef48678
MD5 (freebsd-versatilepb.flash) = 085dedae67895ac1d1a7c04c7cda8468

In ARM
permalink

FreeBSD on Pi: more stuff

November 29, 2012 — 24 Comments

Long overdue update on how the things are going with FreeBSD on Raspberry Pi. We’ve made some good progress so far:

  • Hans Petter Selasky fixed low-speed interrupt endpoints problem which means we have working USB keyboard now
  • GPIO driver by Luiz Otavio O Souza. So now you can blink OK LED (gpioctl -f /dev/gpioc0 -t 16). Not the most productive activity though.
  • Kernel now obtains information about display resolution, memory layout, MAC address from firmware
  • Framebuffer/syscons support added
  • Some stability fixes for SDHCI/li>
  • Initial port of VCHIQ interface (vchiq-freebsd)
  • Port of userland libraries (userland)

Overall stability and performance is still a problem, but it’s what we’re going to work on next.

And if you missed previous post: freebsd-pi is no more, use HEAD from FreeBSD subversion repository.

Boot process has been changed and now it looks like: firmware → uboot → ubldr → kernel. So old script for building image is no longer relevant. Here is new one. Tim Kientzle’s scripts collection for building images for BeagleBone, Pandaboard and RPi uses more systematic approach but RPi part hasn’t caught up to latest boot chain changes yet. Once it is up to date I suggest using Tim’s scripts.

Building FreeBSD does not require any additional tools but if you want VideoCore bits you’ll need following packages installed:

  • devel/cmake
  • devel/git
  • devel/gmake

If you don’t need VideoCore binaries, just comment build_videocore and install_videocore calls. This script will also install OpenGL ES hello_triangle demo to /root folder. To run it run perform following steps:

# cd /root
# kldload vchiq
# ./hello_triangle.bin

I tried to build Qt5 with OpenGL ES support, but build choked on compile-time assert triggered by FreeBSD using OABI. Good news though: EABI work is almost done, so there is a fat chance we’ll see Qt5 with eglfs backend running on FreeBSD in near future.

You can try pre-built image (124Mb, MD5 sums). Login is “root”, no password. Use dd to write it to SD card. U-Boot seems to be somewhat finicky about SD cards, so if you get “** Unrecognized filesystem type **” message try another card. First boot might take some time because sshd will generate keys. U-Boot output goes to serial port and monitor, FreeBSD console messages go only to monitor, but by the end of boot sequence you should get login prompt on serial.

This image is a snapshot of work in progress and by no means a production system.

UPDATE

** Unrecognized filesystem type ** U-Boot issue seems to be more widespread then I thought. I’m working on it.

In ARM, FreeBSD, Raspberry Pi
permalink