I am happy to tell you that flashrom (which was is a grown up former daughter project of coreboot) got one of the coreboot slots in Google Summer of Code 2010. A big thank you to Stefan Reinauer for managing the combined flashrom+coreboot GSoC projects this year.
Welcome to the coreboot developers’ blog. This will become the place where our awesome Google Summer of Code students will log their progress during this summer. I’m really looking forward to all the great projects we are going to have this year. Of course, if you are a coreboot developer, and want to post here, drop me a note.
Buying the board
The particular board is not sold by Xilinx anymore, but the company that actually designed the board for Xilinx, Digilent Inc., still sell it.
Installing and setting up the tools
Once again I downloaded and installed the 32-bit ISE WebPack 11.1 software on 32-bit Linux. It's a 2.8GB download which installs to roughly 5GB. (After deleting 1GB of .xinstall folders left from the installation.. wtf..) It seems that version 12.1 was released just recently and if you're using a version other than 11.1, or another operating system, then you may of course run into fewer problems, more problems, or just different problems.
Installation ran fine as a regular user. At the end of the installation I tried to do the upgrade to version 11.5 but didn't have enough disk space left. Now I can source the settings32.sh file in the directory I installed to and then run ise, impact, and the other programs.
I struggled for a while with iMPACT not finding the built-in Xilinx programmer cable on the starter kit board. There were two issues:
- Wrong firmware downloaded to the USB controller
- iMPACT stubbornly trying to use kernel windrvr instead of libusb
USB controller firmware
Xilinx provides a driver setup script which puts files in /etc/udev/rules.d and /usr/share but I prefered to make an ebuild for the Xilinx firmware package and have added it to my Portage overlay "stuge" which was included in the official layman list on 2010-06-14. If you're not using Gentoo you could most likely run the setup_pcusb script included in the tarball without issues, but note that newer versions of udev require some changes in the supplied rules.
iMPACT insists on ignoring libusb
Older versions of iMPACT used a really nasty kernel driver for accessing USB devices, but now it instead prefers to use libusb for the programmer access. Yay! But not so fast...
On my system iMPACT kept trying to use the old drivers, which I did not have installed and do not want to pollute my system with. According to Xilinx this means that "libusb is not installed", which is absolutely useless of course. It's very frustrating, and typical for closed source software, that information is not sufficiently specific. They need to document the actual assumptions made by their software, instead of publishing some nonsense high level description for what is a very low level system issue. Of course libusb was installed! Stupid.
Eventually I found the problem. It seems that iMPACT uses dlopen() to load "libusb.so", which is arguably a mistake by Xilinx developers. I believe that they should specify a filename with an explicit version instead, such as "libusb-0.1.so.4". The libusb-0.12-r5 package that I had installed unfortunately did not allow the unversioned dlopen() to work. The file found by dlopen("libusb.so") was /usr/lib/libusb.so, which was a small text file (a GNU ld script) used to redirect the linker to /lib/libusb.so when I compiled programs that used libusb. Similar files exist for other libraries. dlopen() needs a binary file however, it doesn't understand the linker script, so iMPACT was unable to load libusb, quietly resorted to requiring windrvr, and complained loudly when it wasn't found. There were no error messages about the failure to load libusb. I can't fix iMPACT, so I solved the problem by doing what I should have done long ago anyway; I removed libusb-0.1 and installed the libusb-compat-0.1.3 package instead, which provides backwards compatibility for libusb-0.1 applications and uses the much improved libusb-1.0 for communication. libusb-compat installs the binary library file in /usr/lib and /usr/lib/libusb.so is a symlink to it. Once it was installed iMPACT could find the programming cable via libusb without problems.
Downloading a logic analyzer
There's not much documentation for the sump.org logic analyzer package, which is too bad since it's a really useful design. There's even a minimal and pretty open hardware made explicitly for the sump.org design, and it costs only $45; the Open Logic Sniffer. If you have use for a LA and don't already have a suitable FPGA board around then I think the OLS is amazing value for money.
On the sump.org project page there are a few different versions available for download. The experimental Spartan 3E source is for the board that I used. The zip includes source for the PC Client (Java) and for the logic analyzer hardware design (VHDL). I added a sump-analyzer-0.8.1.ebuild to my overlay that builds the client and installs a launcher script called sump-analyzer. Non-Gentooers can download the slightly older v0.8 binary package to get a pre-built analyzer.jar, or compile their own with the following commands:
$ cd client/ $ javac -encoding iso-8859-1 $(find -name '*.java') $ jar cfm analyzer.jar Manifest.txt $(find -name '*.class' -o -name '*.png')
Another great option is the highly portable sigrok open source software, which supports the sump hardware design as well as several other logic analyzer products.
From files to hardware
The fpga directory has the VHDL code that makes up the actual logic analyzer, and the UCF (User Constraint File) that specifies how the FPGA chip is connected. Now, let's make hardware from them:
Open ISE, create a new project, select Top-level source type HDL, click Next, set Family Spartan3E, Device XC3S500E, Package FG320, Speed -4 and Preferred Language VHDL, click Next twice (skip the "Create New Source" step), and in the "Add Existing Sources" step make sure to add all files in the fpga subdirectory except for la.ucf, la.vhd and license.txt, in particular la-S3ESK.ucf and la-S3ESK.vhd must be included. When you OK the "Project Summary" then ISE should add all 23 files without problems. Double click "Configure Target Device" under "Processes: la - Behavioral" in the lower half of the Design tab in the Design panel in ISE to run through Synthesis, Place & Route, and bitstream generation.
You may get a message about no iMPACT project file, just OK that so that iMPACT starts. Double-click "Boundary Scan" in the iMPACT Flows panel, then press Ctrl-I or select File->Initialize Chain in the menu. A dialog with settings for the three discovered devices appears, just OK that too. Double click the xc3s500e icon and assign the la.bit file created by ISE. Say No to the SPI or BPI PROM question. Right-click the xc3s500e icon and select Program. OK the same properties dialog again to send the bitstream to the FPGA.
- SW1:0 sets baud rate: 00=115k2 01=57k6 10=38k4 11=19k2
- LED4:3 shows the baud rate set by SW1:0.
- LED1:0 shows the (active low) TX and RX signals.
- BTN_SOUTH is reset. LED6 shows the reset signal.
- LED7 shows the external clock signal. (DIP-8 socket)
- If capturing without an actual signal connected then remember to disable Noise Filter, or the logic analyzer doesn't see any data, and the capture seems to hang. Either apply an actual signal or close the capture, press BTN_SOUTH and then try again, making sure to disable the filter.
- iMPACT uses a SysV IPC semaphore to "lock" the download cable. If it isn't closed cleanly or if it crashes, it may start saying "Cable is LOCKED. Retrying..." in the log, which is of course wrong. Remove the semaphore with semget(0x240157b1,1,0),0,IPC_RMID,NULL) in a C program, or reboot, to get iMPACT to find the cable again.
- Look at la-S3ESK.ucf for the connections. All input channels are in the FX2 connector, but the first twelve are also on the more convenient J1, J2 and J4 headers.
As you may know there's a Google Summer of Code program again this year.
The deadline for student applications is April 9th at 19:00 UTC, so if you're a student and you want to work on a coreboot (open-source BIOS / PC firmware) or flashrom (open-source BIOS chip flasher) project, please apply in time.
The following coreboot/flashrom GSOC project ideas have been proposed so far (but you can also suggest your own ideas, of course):
- Infrastructure for automatic code checking
- TianoCore on coreboot
- coreboot port to Marvell ARM SOCs with PCIe
- coreboot port to AMD 800 series chipsets
- coreboot mass-porting to AMD 780 series mainboards
- coreboot panic room
- coreboot cheap testing rig
- coreboot GeodeLX port from v3 to v4
- Drivers for libpayload
- Board config infrastructure
- Refactor AMD code
- Payload infrastructure
- flashrom: Multiple GUIs for flashrom
- flashrom: Recovery of dead boards and onboard flash updates
- flashrom: SPI bitbanging hardware support
- flashrom: Generic flashrom infrastructure improvements
- flashrom: Laptop support
See this wiki page for why and how to apply for a coreboot/flashrom project.
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!
Quick public service announcement (which probably comes a bit too late, sorry):
There's a coreboot developer room at this year's FOSDEM (Free and Open-Source Software Developer's European Meeting), which starts roughly... um... today. In 20 minutes, actually. Unfortunately I cannot be there, hopefully there will be video archives of the talks. If you're at FOSDEM already, here's the list of talks:
Sat 13:00-14:00 coreboot introduction (Peter Stuge)
Sat 14:00-15:00 coreboot and PC technical details (Peter Stuge)
Sat 15:00-16:00 ACPI and Suspend/Resume under coreboot (Rudolf Marek)
Sat 16:00-17:00 coreboot board porting (Rudolf Marek)
Sat 17:00-18:00 Flashrom, the universal flash tool (Carl-Daniel Hailfinger)
Sat 18:00-19:00 Flash enable BIOS reverse engineering (Luc Verhaegen)
Highly recommended stuff if you're interested in an open-source BIOS and/or open-source, cross-platform flash EEPROM programmer software.
coreboot® is running on a multitude of different computers, ranging from tiny embedded systems as small as the palm of your hand over desktop and server systems to super computers with thousands of nodes. However, one might say that in the area of mobile computers coreboot has to catch up, compared to its support of other devices.
Thus, I am especially glad to announce that ">coresystems GmbH is releasing coreboot® for the Roda RK886EX a.k.a Rocky III+ notebook today. It's a rugged notebook, protected against shock, vibration, dust and humidity:
We have been testing various Linux distributions as well as Windows XP and Windows 7 booting on this nice notebook.
I want to sincerely thank those who made this project possible with their funding:
- secunet Security Networks AG
- Bundesamt für Sicherheit in der Informationstechnologie (Federal Office for Information Security, BSI)
A big thank you also goes to everyone who worked with coresystems on this project.
The committed patch series includes improved support for the Intel i945 / ICH7 chipset (which was also written by coresystems), the SMSC LPC47N227 Super I/O, the Texas Instruments Cardbus+Firewire bridge TI PCI7420, and finally the Renesas M3885x Embedded Controller (EC).
Btw, the latter, the so-called embedded controller (sometimes integrated in the Super I/O, sometimes it's an extra chip) is one of the major problems for coreboot support on laptops. They are almost always undocumented (i.e., no public datasheets are available), but they have low-level control over power/battery management, early power-up sequence, and often include keyboard controller functionality and other important stuff. Luckily, for this notebook an EC datasheet is available. Checkout the coreboot EC support code for the Renesas M3885x for an impression of what this stuff is all about.
Anyway, there is hope that this laptop will only be the first in a row of multiple supported ones in the future. Interested developers and contributors are of course always welcome on the coreboot mailing list :-)
In order to install Rockbox on an iPod, it needs to be formatted in FAT32, not HFS+. The relevant wiki page over at the Rockbox site suggest either connecting the iPod to an iTunes install on Windows, or using one of the bootsectors they have available for download from that page.
Those boot sectors assume your iPod has one of the factory disks installed. I’ve got an old 4th gen iPod that I converted to compact flash after its disk died. It happens to have an 8G CF card in there.
Since I don’t do Windows, I downloaded the 20G 4th gen bootsector, put that on the iPod, and used fdisk to change the size of the FAT32 partition. And that worked fine.
Anton Borisov's article Coreboot at Your Service! explains the basic ideas behind coreboot, how to build an image for your board, which payloads are available and how they are used, e.g. GRUB2, SeaBIOS if you need legacy BIOS callbacks (e.g. for booting Windows), Etherboot/GPXE, or more fun stuff such as space invaders or tint (a tetris clone) in your flash ROM chip...
If you read the article and think the build process is a bit complicated and ugly, do not despair! We're currently in the process of converting the whole coreboot code base to use kconfig (the widely-known configuration tool used by the Linux kernel, busybox, and other projects), so in the very near future the whole process for building a coreboot image will work like this:
$ make menuconfig $ make
Flashing the image can then be done using an EEPROM programmer and/or via the user-space utility flashrom (available for Linux, Mac OS X, FreeBSD, etc.)...
It's nice to see that coreboot is getting more and more coverage in "mainstream" media and is growing both in number of deployments and in number of supported chipsets and boards.
We are desperately in need of more developers though, there are just way too many chipsets, boards, and datasheets out there; we're happy about every patch and every new tester or developer who likes to mess with code that runs in the very first few (micro)seconds after power-on.
If you think kernel hacking and related low-level development is nice, you might also be interested in writing code where there's no RAM yet (as coreboot has to initialize it), there's no serial port for debugging (coreboot has to initialize it), no PCI devices have been set up, most of your auxiliary hardware is not yet up (ethernet NIC, parallel port, audio, IDE, SATA, USB, you name it). It's a fun environment to work in and you'll learn a lot about PC hardware, even if you (so far) thought you knew everything there is to know.