I guess it's time to finally announce libopenstm32, a Free Software firmware library for STM32 ARM Cortex-M3 microcontrollers me and a few other people have been working on in recent weeks. The library is licensed under the GNU GPL, version 3 or later (yes, that's an intentional decision after some discussions we had).
The code is available via git:
$ git clone git://libopenstm32.git.sourceforge.net/gitroot/libopenstm32/libopenstm32 $ cd libopenstm32 $ make
Building is done using a standard ARM gcc cross-compiler (arm-elf or arm-none-eabi for instance), see the summon-arm-toolchain script for the basic idea about how to build one.
The current status of the library is listed in the wiki. In short: some parts of GPIOs, UART, I2C, SPI, RCC, Timers and some other basic stuff works and has register definitions (and some convenience functions, but not too many, yet). We're working on adding support for more subsystems, any help with this is highly welcome of course! Luckily ARM stuff (and especially the STM32) has pretty good (and freely available) datasheets.
The current list of projects where we plan to use this library is Open-BLDC (an Open Hardware / Free Software brushless motor controller project by Piotr Esden-Tempski), openmulticopter (an Open Hardware / Free Software quadrocopter/UAV project), openbiosprog (an Open Hardware / Free Software BIOS chip flash programmer I'm in the process of designing using gEDA/PCB), and probably a few more.
If you plan to work on any new (or existing) microcontroller hardware- or software-projects involving an STM32 microcontroller, please consider using libopenstm32 (it's the only Free Software library for this microcontroller family I know of) and help us make it better and more complete. Thanks!
If you recently upgraded your kernel to the 2.6.29 Debian package, you might have noticed some (e.g. graphics) drivers stopped working or are working slower. In my case, this was the radeon driver, which inexplicably seemed to cause lots of slowdowns in some applications and games. A quick look into dmesg revealed the reason:
[drm] Initialized radeon 1.29.0 20080528 on minor 0 agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode pci 0000:01:00.0: putting AGP V2 device into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin radeon_cp: Failed to load firmware "radeon/R200_cp.bin" [drm:radeon_do_init_cp] *ERROR* Failed to load firmware!
As noted in the changelog file, the radeon firmware R200_cp.bin has been removed from the kernel, and is now available in the separate firmware-linux Debian package. So the simple fix for this issues is:
$ apt-get install firmware-linux $ dpkg -L firmware-linux | grep R200_cp.bin /lib/firmware/radeon/R200_cp.bin
After restarting X, the dmesg output looks more sane again:
agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode pci 0000:01:00.0: putting AGP V2 device into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin [drm] writeback test succeeded in 2 usecs
When trying to port coreboot (previously LinuxBIOS) to a new mainboard you're often confronted with a big problem: the BIOS/ROM chip on the respective motherboard is soldered onto the board (i.e., not in a socket).
This means that you cannot easily (hot-)swap the chip during development or for recovery purposes. So you basically have exactly one try to flash the ROM chip with a fully working/booting coreboot image. If that goes wrong your board is bricked.
This makes it pretty much impossible to develop a coreboot port for such boards (and soldered-on ROM chips are becoming more and more common, unfortunately).
However, I've recently tried to replace the soldered-on (PLCC) ROM chip on one of my boards with a socket. What sounds pretty scary at first, especially given that I have almost non-existant soldering skills, turned out to be really not that hard. Also, it can be done with relatively cheap and readily available equipment.
I have written a short HOWTO for desoldering chips and soldering on sockets in the coreboot wiki, and also finished a video showing most of the process, which I hope will be helpful for others:
$ youtube-dl -t 'http://www.youtube.com/watch?v=30x4oxyczH4'
I also tried to upload the video to Vimeo, but first they told me to install the Flash 10 abomination (and there's no way I will do that). After browsing the help/forum pages a bit I found a traditional, non-flash upload form, but that then tells me that I cannot upload Ogg Theora videos. WTF?
The Ogg Theora video support feature request has been open for more that a year. Until that issue is fixed I'll just use other video services, thanks...
Here's a nice opportunity for everyone to learn more about coreboot, a Free Software / Open Source firmware/BIOS for x86 PCs.
Ron Minnich, founder of the LinuxBIOS (now called coreboot) project, Peter Stuge of Stuge Konsult, and Stefan Reinauer of coresystems GmbH have given a presentation for the Google Tech Talks series recently. The topic was (of course) coreboot, its history, goals, features and technical details, surrounding tools and libraries such as flashrom and libpayload, as well as an automated test system for running a hardware test-suite upon every checkin in the coreboot repository.
A video of the talk, aptly named coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware (134 MB), is available from Youtube, get it for instance via:
$ apt-get install youtube-dl $ youtube-dl http://www.youtube.com/watch?v=X72LgcMpM9k
The talk includes various demos of coreboot and various payloads you can use with coreboot. One nice example is the TINT payload, a Tetris-like game for Linux (
apt-get install tint for the curious), which has been reworked to be usable as a coreboot payload.
So, yes, you can now put Tetris in your BIOS ROM chip and play it from there (no hard drive required).
Other demos included some cluster nodes with coreboot, and a "normal" x86 desktop board booting coreboot + Linux in a very few seconds (much room left for optimizing there though, if you really want to get into fast booting).
Check out the full talk for more infos, and if you're willing to give it a try (see the list of currently supported boards), contact us on the mailing list or join the #coreboot IRC channel on Freenode.