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!
This is what I set up for backups recently using a cheap USB-enclosure which can house 2 SATA disks and shows them as 2 USB mass-storage devices to my system (using only one USB cable). Without any further introduction, here goes the HOWTO:
First, create one big partition on each of the two disks (/dev/sdc and /dev/sdd in my case) of the exact same size. The cfdisk details are omitted here.
$ cfdisk /dev/sdc $ cfdisk /dev/sdd
Then, create a new RAID array using the mdadm utility:
$ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
The array is named md0, consists of the two devices (--raid-devices=2) /dev/sdc1 and /dev/sdd1, and it's a RAID-1 array, i.e. data is simply mirrored on both disks so if one of them fails you don't lose data (--level=1). After this has been done the array will be synchronized so that both disks contain the same data (this process will take a long time). You can watch the current status via:
$ cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdd1 sdc1 1465135869 blocks super 1.1 [2/2] [UU] [>....................] resync = 0.0% (70016/1465135869) finish=2440.6min speed=10002K/sec unused devices:
Some more info is also available from mdadm:
$ mdadm --detail --scan ARRAY /dev/md0 metadata=1.01 name=foobar:0 UUID=1234578:1234578:1234578:1234578 $ mdadm --detail /dev/md0 /dev/md0: Version : 1.01 Creation Time : Sat Feb 6 23:58:51 2010 Raid Level : raid1 Array Size : 1465135869 (1397.26 GiB 1500.30 GB) Used Dev Size : 1465135869 (1397.26 GiB 1500.30 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Sun Feb 7 00:03:21 2010 State : active, resyncing Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Rebuild Status : 0% complete Name : foobar:0 (local to host foobar) UUID : 1234578:1234578:1234578:1234578 Events : 1 Number Major Minor RaidDevice State 0 8 33 0 active sync /dev/sdc1 1 8 49 1 active sync /dev/sdd1
Next, you'll want to create a big partition on the RAID device (cfdisk details omitted)...
$ cfdisk /dev/md0
...and then encrypt all the (future) data on the device using dm-crypt+LUKS and cryptsetup:
$ cryptsetup --verbose --verify-passphrase luksFormat /dev/md0p1 Enter your desired pasphrase here (twice) $ cryptsetup luksOpen /dev/md0p1 myraid
After opening the encrypted container with cryptsetup luksOpen you can create a filesystem on it (ext3 in my case):
$ mkfs.ext3 -j -m 0 /dev/mapper/myraid
That's about it. In future you can access the RAID data by using the steps below.
Starting the RAID and mouting the drive:
$ mdadm --assemble /dev/md0 /dev/sdc1 /dev/sdd1 $ cryptsetup luksOpen /dev/md0p1 myraid $ mount -t ext3 /dev/mapper/myraid /mnt
Shutting down the RAID:
$ umount /mnt $ cryptsetup luksClose myraid $ mdadm --stop /dev/md0
That's all. Performance is shitty due to all the data being shoved out over one USB cable (and USB itself being too slow for these amounts of data), but I don't care too much about that as this setup is meant for backups, not performance-critical stuff.
Update 04/2011: Thanks to Bohdan Zograf there's a Belorussian translation of this article now!
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 :-)
I recently almost died from a heart attack because after a really horrible crash (don't ask), Debian unstable on my laptop wouldn't boot anymore. The system hung at "Waiting for root filesystem...", and I was in panic mode as I feared I lost all my data (and as usual my backups were waaay too old).
At first I was suspecting that something actually got erased or mangled due to the crash, either at the dm-crypt layer, or the LVM layer, or the ext3 filesystem on top of those. After various hours of messing with live CDs, cryptsetup, lvm commands (such as pvscan, pvs, vgchange, vgs, vgck) and finally fsck I still had not managed to successfully boot my laptop.
I finally was able to boot by changing the initrd from initrd.img-2.6.30-2-686 to initrd.img-2.6.30-2-686.bak in the GRUB2 menu (at boot-time), at which point it was clear that something was wrong with my current initrd. A bit of debugging and some initrd comparisons revealed the cause:
Both, the cryptsetup and lvm2 packages were no longer installed on my laptop, which made all update-initramfs invokations (e.g. upon kernel package updates) create initrds which did not contain the proper dm-crypt and lvm functionality support. Hence, no booting for me. I only noticed because of the crash, as I usually do not reboot the laptop very often (two or three times per year maybe).
Now, as to why those packages were removed I have absolutely no idea. I did not remove them knowingly, so I suspect some dist-upgrade did it and I didn't notice (but I do carefully check which packages dist-upgrade tries to remove, usually)...