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)...
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.
I've been using CRM114 as spam filter for a while now, and I'm quite happy with it. Due to bug #529720 though (incompatible upstream file format changes) I decided to start my setup from scratch with a recent CRM114 version from unstable. Here's a short HOWTO, hope it's useful for others.
First you need to install crm114 and set up a few files in your $HOME directory.
$ sudo apt-get install crm114 $ mkdir ~/.crm114 $ cd ~/.crm114 $ cp /usr/share/doc/crm114/examples/mailfilter.cf.gz . $ gunzip mailfilter.cf.gz $ cp /usr/share/crm114/mailtrainer.crm . $ touch rewrites.mfp priolist.mfp
Edit ~/.crm114/mailfilter.cf and set the following variables (some are optional, but that's what I currently use):
:spw: /mypassword/ :add_verbose_stats: /no/ :add_extra_stuff: /no/ :rewrites_enabled: /no/ :spam_flag_subject_string: // :unsure_flag_subject_string: // :log_to_allmail.txt: /no/
The :log_to_allmail.txt: /no/ option should probably stay at "yes" for the first few days until you have tested your setup and everything works OK. The ~/.crm114/allmail.txt file will contain all your mails, in case something goes wrong.
Now set up empty spam and nonspam files like this:
$ cssutil -b -r spam.css $ cssutil -b -r nonspam.css
Test the setup by invoking mailreaver.crm as follows, typing some test text and then pressing CTRL+d:
$ /usr/share/crm114/mailreaver.crm -u ~/.crm114 test [CTRL-d] ** ACCEPT: CRM114 PASS osb unique microgroom Matcher ** CLASSIFY fails; success probability: 0.5000 pR: 0.0000 Best match to file #0 (nonspam.css) prob: 0.5000 pR: 0.0000 Total features in input file: 8 #0 (nonspam.css): features: 1, hits: 0, prob: 5.00e-01, pR: 0.00 #1 (spam.css): features: 1, hits: 0, prob: 5.00e-01, pR: 0.00 X-CRM114-Version: 200904023-BlameSteveJobs ( TRE 0.7.6 (BSD) ) MF-35EB8B9A [pR: 0.0000] X-CRM114-CacheID: sfid-20090920_151224_574131_D290E589 X-CRM114-Status: UNSURE (0.0000) This message is 'unsure'; please train it!
The output should look similar to the above. If there are errors instead, you should check your settings in ~/.crm114/mailfilter.cf.
Now you have to setup a procmail rule for crm114:
:0fw: crm114.lock | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114 :0: * ^X-CRM114-Status: SPAM.* IN.spam-crm114
Finally, in .muttrc I have the following configs so I can press SHIFT+x to mark a mail as spam, and SHIFT+h to mark it as non-spam (ham).
macro index X '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --spam' macro index H '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --good' macro pager X '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --spam' macro pager H '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --good'
Important: crm114 is most effective if you start with empty CSS files (as shown above) and only train it by marking mails as spam/ham when it gets them wrong. The process will take a few hours or maybe a day (depending on how many mails per day you get), then the misclassification rate gets very low...
Update 2009-09-23: Changed --spam/--nonspam to the correct options for mailreaver/mailtrainer, --spam/--good.
There is no advertising budget. If you happen to like this album, please take the time to recommend it to your friends and colleagues.