I have recently written about using FreeDOS to perform BIOS updates and I stated that before going that route I have been using flashrom – coming out of the coreboot project – that allows for hot update of BIOS without requiring booting into DOS at all.
The project in the past months started supporting pretty well a long list of motherboards, including one for which I added support myself (an ASUS Pentium 4 board I had to update for a customer, one where USB support didn’t seem to work properly without a BIOS update), but the other day I hit a very nasty problem linked to it.
I wanted to update the BIOS of the small frontend system I use as a desktop (Yamato is now working headless), even though the only thing that it would improve is USB 3 support and I have no USB 3 device (yet); on the board (ASUS based on nVidia ION platform) flashrom worked quite fine, so I flashed the BIOS, restarted, removed the backup and… just then I noticed I had no network.
The problem is that the Realtek 8169 integrated on the board reads its MAC address from somewhere in the BIOS flash; when updating with the ASUS tools it would have been preserved, but when using flashrom, well, it doesn’t know what it shouldn’t erase and rewrite. This caused the MAC address on that box to be overwritten with garbage. Luckily it doesn’t really matter, for that system, since I simply used the mac_eth0 setting to change the mac address to the one it used before, so that the same IP addresses would be used.
Speaking with the developers of the software suggested me that there are many ways in which the mac address could be encoded into the BIOS, and also noted that the same is true for DMI and SMBIOS data, which is no issue for me most of the time, since I don’t have any (I am my own OEM), but can be quite a problem for customer’s computers.
Also, clumsiness ants that I were to delete the backup file I read from the previously-used BIOS before I noticed the lack of network access, otherwise I would have been able to compare it with the stock BIOS (for the same version) provided by ASUS; looking for the new mac address as a binary string in the data as read back by flashrom, with the help of bgrep (which is not in Portage, does anybody know if there is something like that in Portage already or if I should rather add that one?) does not yield any useful result, either, so I can’t seem to be able to find where it’s actually stored.
This probably also explains why Yamato reports 88:aa:99:bb:dd:ee and 60:50:40:30:20:10 as mac addresses.. and I thought it was the BMC’s fault! I guess I should re-flash the Tyan firmwares and see if I can reprogram the network cards (if I remember correctly, their utilities allow to do a permanent change of mac address). Could possibly make the BMC-over-LAN access more reliable, it doesn’t seem to be much right now.
At any rate, I’m not going to suggest against the use of flashrom, but definitely I suppose I learnt to trust it a bit less, and be more wary about it than I was before; I’m happy it happened with a box of mine and not a customer’s, that could have been quite an issue.