Can everybody hear? Yes. Okay, hi. I'm Carl Daniel Heifinger. I'm the lead developer of the FlashOM open source project. You're here to listen to a talk which says update your BIOS and EFI from any free OS.

That's actually the subtitle. The real title is The Open Source Flash Programmer. I'm glad to be able to speak here about FlashOM and let's just dive in. What is FlashOM? FlashOM is a tool for Flash ER prompts. Most of you know those chips as BIOS chips,

but some know it perhaps as ROM chips on a network card. Usually those are Flash ER prompts. FlashOM can identify those chips, read them, write them, erase them, lock them, unlock them, pretty much everything you can do with them. FlashOM supports all Flash interfaces we know,

which means parallel LPC, FWH, SPI. Those are the most common buses you find on x86 mainboards, on network cards, SATA controllers, whatever. FlashOM does not care about the chip form factor, so sometimes people ask us, okay, does FlashOM work with a PLCC32 flash chip?

And we say, well, we don't care about the form factor. It's all about the flash interface and the chip itself. FlashOM is pretty extensive. It supports over 270 flash chips, 150 x86 chipsets, 260 mainboards are listed in our database. We have quite a backlog.

Actually realistic is probably 500 mainboards, maybe more, most more mainboards are supported out of the box, so we don't get reports for that. And 55 external programmers. I have to explain what that means later. Just a short hint. External programmers means it's not part of the original mission of FlashOM

to update a BIOS or to replace a BIOS with core boot, so anything which is not a mainboard is an external programmer. FlashOM has quite nice features. It works in the environment you're used to, so if you are used to Linux, FlashOM can be run under Linux.

It says later it's also portable. Linux FreeBSD, NetBSD, OpenBSD, DragonflyBSD, Mac OS X, OpenSolaris, FreeDOS, partially Windows, pretty much every operating system you can mention, it's easy to port. Mostly easy. FlashOM doesn't need physical access,

so if you have the old problem, you have a server stored somewhere, and then you would have to plug in a keyboard, you have to plug in a monitor to run a DOS-based utility, maybe install a floppy drive. That's horrible. Who would want to do that? So FlashOM can just log in over SSH to that machine

and update the BIOS EFI remotely or Flash core boot remotely, whatever you want. Or you update your network card boot ROM, whatever. It can all be done remotely. You can do this from a running system, which means that if you have to administrate a huge cluster

or something like that, the cluster keeps running while we reflash, or while you reflash. It keeps running even if flashing fails can happen, maybe the chip dies or whatever. I once had a chip die on me, and the machine kept running, I think,

I kept it running for one month without a flash chip at all, without a BIOS chip, while the machine is running you don't need that unless, well, you use FlashOM and want to test the chip, then of course you need a chip, but otherwise you can recover if it fails. You just go on IRC, mail us and say,

hey, I didn't shut down the machine, can you help me? And then we usually can help you recover. So that's pretty cool in my opinion. It's a command line application, which means you can also script it easily. I already mentioned it's portable, maybe one additional point to the scriptability.

This also means FlashOM will not wait for user input. If something is wrong, or FlashOM can't decide what to do, for example ambiguous chip detection or whatever, it will simply abort and leave your system untouched. So you can easily deploy it everywhere.

It's pretty fast. We have run timings, and we are up to ten times faster than vendor utilities. You can do hot flashing. For example, you erased the flash chip of one board by accident, then you boot another board, put it up, remove the flash chip while the board is running,

plug in the erased flash chip, run FlashOM again, and flash the image you want to have in there, and then you have recovered one machine without having to buy an expensive programmer. It can do cross-flashing. So if you have an Asus board with NVIDIA chipset,

you can, without any problem, flash a chip for a gigabyte board with AMD chipset or whatever, as long as the buses of the flash chip are compatible, there are only four different buses, so the chance is pretty high. Most modern systems have SPI flash chips, so it's easy to interchange.

Well, use cases. Update your BIOS, update your EFI flash core boot, update your network bootrom or write one, mod your graphics firmware. Some people like that because they believe that when they just lock down the graphics card without any need,

you can mod your SATA or PATA controller. PROMIS controllers, PATA controllers, in the past, you had only to flip one bit and it immediately became a RAID controller, which was fun. You can do recovery with hot-flashing, cross-flashing, for example, your friend, break his or her device,

and say, okay, give me the flash chip, and then you rip out your flash chip while your machine is running, plug in the other flash chip, run FlashROM, be happy. You can flash any chip with any programmer. So if you have a network bootrom which fits in your network card, and you have a socket and a compatible flash bus,

and there are only four flash buses on an older mainboard, plug in the network bootrom into your mainboard with this hot and cross-flashing, flash it, remove it, be happy. The other way around works as well. You can update your mainboard BIOS if you have a self-built AVR-based programmer.

You can update your graphics card ROM with a parallel port cable with a few resistors soldered on. It's all pretty much fun. The design is clean and reliable because if people try FlashROM and it fails, they will come and complain,

and we want to make users happy, and supporting people after the fact, after something is broken is much more difficult than doing it right from the start. So yes, supporting a new flagship or a new programmer is very easy. Usually it's just adding a new line to a table.

We did not have to write a new flash chip driver in the last two years, so that should probably tell you how well it works. The programmer is selected by a command line parameter. For example, if you have a network card, a graphics card, and your mainboard, FlashROM can't know which one to flash, and you should specify it,

because FlashROM will by default say, okay, I don't know which one, so please tell me. It has a compatibility checker, so it checks whether the flash chip and the programming interface are compatible. It does not check whether the board and the image you want to flash are compatible, because that would make cross-fleshing impossible.

FlashROM probes always for a chip, but it will never read, never write, nor erase if you don't explicitly tell it. And FlashROM verifies everything by default, I think two or three times at every step. So it's all about reliability,

because, hey, you won't use a machine afterwards. Problems? Well, we do have some. People love to flash DVD drives. We say, no, we won't support that, because DVD drives do not offer the ability to verify the contents, and so we don't know if flashing worked,

and then people would just complain that FlashROM killed their DVD burner. So we just don't support it. Oh, yeah, datasheets are wrong. Really, really wrong. Jetty compliant means, yeah, well, you encrypt the spec, and then try to read that garbage, and then it works out. Fast means, yeah, we had a chip,

and it was about 100 times slower than the others which were not labeled as fast. Standard, of course, means you can use the standard commands, but please wait one millisecond instead of one microsecond. After every write, so a write needs only one hour. It's proven in the sense of,

it's proven that the chip dies. Then there are multiple incompatible chips with identical ID, because vendors decide, oh, let's keep the ID and just change the interface. And chipset designers try to be clever, and they add security features which stop us from verifying,

but they don't stop us or any malware from writing. It's really, really funny. Okay, programmers, what do we support? This is only a small selection. I'll just skip quickly. Mainboards, a PCI Express solid state disk. We support this since, I think, 13 hours.

I just commented that. We support network cards, SATA controllers, the open graphics card, self-built AVR-based devices, the bus pirate,

the expensive daddy programmer, a designer of Uwe Herrmann, who is also a member of the Flash On project. It pretty much does the same as the extremely expensive daddy prog at the same speed, but it costs, I think, material about, whatever,

$10 or so. Then you can use some development hardware. You can do the parallel port cable hack with some resistors. If you like it ghetto style, at midnight, nothing else is available. You want to recover your machine. Okay, a demo run.

Where is the escape button? Sorry, could you help me? Oh, looked in the wrong place. Sorry. This one should... A purple one.

Okay, and F11. Okay, I'll just replay a Flash Run because I don't want to do this on hardware. Well, not with the presentation hardware. First you read the backup. This is the original timing,

so it's pretty quick. And then you write a new ROM, and it's also not that slow. I made that time yesterday. It's erasing, writing, done, verifying, of course, and that's it. So, I do exit this again.

And F5. Okay. If Flash Run doesn't find your chip, it can happen. Maybe we just need a new ID. Maybe a new chip driver, but we haven't needed that in the last two years. Maybe your chipset is unsupported if it's very new, but unlikely because we track chipset updates. Or the Flash chip is hiding behind some obscure controller which performs translation.

Or you have a laptop. Just send us a report, and we'll take care of it. So, the laptop nightmare. I should mention this. I have a few seconds left, I think. The Flash chips are so large, so you can't just exchange them. The mainboards are custom, extremely expensive,

and the laptop is two computers. You have the x86 CPU, you know, and an extra embedded controller, which does battery charging, power management, the stuff. And they share the same Flash chips. So, if you start erasing the normal BIOS, well, your embedded controller will die, power off while you're erasing, not great. It will hang, power off the backlight, stop charging, whatever.

There are no standards, no docs, no test software. And, of course, if you get anything, it's only under draconian NDAs. We're making slow progress. We support a few embedded controllers, but their interface not only depends on the hardware, but also on the software they are running. It's horrible.

We support, I think, one laptop. Okay, maybe two, but, yeah. So, new users, please try Flash on, but not in crazy expensive hardware, not in laptops. If it works, please send us a report. We're happy to hear about it, and we'll add it to our support list. If Flash on fails, just join us on IRC.

Give us a few minutes, maybe a few hours to respond. Your machine can keep running, just don't power it off. We can help you recover. We are pretty successful with recovery. We have, I think, roughly 99% recovery success. So, that's, in my opinion, pretty okay.

And please use latest Flash on. Don't use older versions. Use latest one from subversion. It's reliable, and it has automatic recovery. We'll add your report to our to-do list if it doesn't work at first. Okay, spare the vote. Tell everybody, write in your blog. Tell your friends. Tell the admins and your company. They may actually use it. And tell hardware vendors, but please not.

You must support us, but rather in a pretty friendly way. Yes, if you have questions, please visit us at our booth in AW Building, booth number 8. We share a booth with Corbut and Flashom at flashom.org on the web. Mail us at flashom at flashom.org. Join us on Freenode at hasflashom.

Okay, thanks to everybody who helps, contributes, and sends reports, and thanks to FOSTEM. Thank you.