|FOSDEM: Coreboot and X.org Schedules.
||[Jan. 22nd, 2010|02:23 am]
|[||Tags|||||coreboot, fosdem, xorg||]|
|||||Fingathing - SuperHero Music - SuperHero Music||]|
This year, at FOSDEM, there is a coreboot DevRoom, and for the hardware-lover, there are some really interesting talks there. When putting together the final schedule, I actually had to spend some time on containing people's enthusiasm and limiting their ideas to something feasible for FOSDEM. A rather good sign, and i am sure that many people will enjoy the truly interesting and juicily in-depth talks there.
Here is a quick copy of the saturday afternoon schedule:
* 13:00 : Peter Stuge - coreboot introduction.
* 14:00 : Peter Stuge - coreboot and PC technical details.
* 15:00 : Rudolf Marek - ACPI and Suspend/Resume under coreboot.
* 16:00 : Rudolf Marek - coreboot board porting.
* 17:00 : Carl-Daniel Hailfinger - Flashrom.
* 18:00 : Luc Verhaegen - Flash Enable BIOS Reverse Engineering.
So yeah, i have a talk at 18:00 which promises to be fun.
Basically, for flashrom, we sometimes need to find out what write protection certain motherboards implement, so we can disable that from within flashrom. This usually means that someone (usually Michael Karcher or me) has to go and disassemble the BIOS to find out which GPIO line needs to be toggled.
For a single board, this is usually not a hard task (and actually fun), but the overal amount of work in flashrom is sizable, and the two of us are not available 24/7 to do this for every user in need. So this talk is meant to alleviate that.
I just wrote the slides for it, and while i might alter the notes and twiddle it a bit still in the next two weeks, it should be pretty much finished.
The structure of the talk is the following:
* quick overview of how flashes are usually wired up on motherboards.
* quick overview of how to handle Award, ASUS, AMI and phoenix BIOSes.
* example of disassembly of a BIOS.
The BIOS that is being disassembled is an especially crafted one, with an award style flash enable for a fictitious board. It's mostly filled with 0xFF, apart from the flash enable itself. And the talk itself is pretty accessible, you do not have to know much of assembly or hardware to be able to participate.
If you are visiting the talk, and you want to join in, then you might already want to download the image, and make sure that you have hexdump and ndisasm installed (as there are about 4000 others trying to use the wireless at FOSDEM).
It promises to be a blast!
On sunday there is of course the X.org DevRoom, for which the schedule is also online.
It seems to be a tradition that I have to go and beg people to talk at truly great event like FOSDEM.
Last year, we had 7 talks in the brochure, while there was room for 13, and we eventually had 9 talks. All these talks were hugely popular, with almost full capacity usage most of the time, but the actual talk coverage itself left much to be desired.
This year I decided to split the usual two day X.org DevRoom into coreboot (saturday afternoon) and X.org (sunday), so that the X.org schedule could be tighter and more exciting.
Here is the result;
* 10.00: ...
* 11.00: ...
* 12.00: ...
* 13.00: Daniel Stone : Polishing X11 and making it shiny.
* 14.00: Luc Verhaegen : The free software desktop’s graphics driver stack.
* 15.00: Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status.
* 16.00: Mikhail Gusarov : X on e-Paper.
I, and a lot of fosdem visitors with me, thank Daniel, Jerome and Mikhail for their commitment. These talks seem very interesting and will no doubt draw in a lot of visitors and carry out the good name of X.org.
It does make one think. There seems to be a direct and inverse relationship between the size and status of a free software project, and the willingness of its members to go and promote this project on the biggest free software event on that continent that holds the majority of its current developers and the largest potential of future contributors.
In any case, I have been communicated that, as there are many very worthwhile and also very willing projects who get denied a DevRoom each year, a project with such a poor showing will not be given another DevRoom.
While I start putting together the slides for my X.org talk, I can only concede.