[LinuxBIOS] RFC Winflashrom Architecture -- Current device driver (testbed)
stepan at coresystems.de
Mon Jun 11 18:17:38 CEST 2007
Oh I love playing advocatus diaboli ;-)
* Jeremy Jackson <jerj at coplanar.net> [070611 16:58]:
> Overall I disagree with flashrom being in userspace.
I have mixed feelings about the approach. As a hardware driver, it
strictly belongs to the kernel. Oh, wait, in modern systems hardware
drivers strictly belong into userspace, but Linux is not one of them.
At some point more than 50% of my effort went into keeping up with minor
and major interface changes in the driver and while I thought I was
maintaining it well, it suffered from bitrot and features like pci card
flashing broke away since things in the kernel changed.
> There is the issue of mapping PCI roms to free areas, locking (can you
> use the EEPROM socket on a NIC while it's receiving a frame?).
This depends very well on the card. The PCI standard forbids this
anyways. Either the ROM or MEM/IO must be enabled, not both at the same
Nonetheless, you can make sure it does not happen by unloading the
network card module.
> bloat and eases updates for new flash parts. This would let whole
> chip/sector erase, sector program of varying sector sizes, and any other
> chip specific functions be supported safely.
One rule of thumb you have to follow is: Do not run flashrom on an
otherwise loaded machine. Then the timing is uncritical.
> A simple whole-chip programming could be done with
> # cat bios.rom > /dev/bios
cat for example always uses 4k blocks, which might lead to early
destruction of the chip. dd bs=512k ... is much better.
> With the hardware access moved into the kernel, the userspace tool(s)
> could focus on partial updates of code (boot block vs fallback vs normal
> images), userspace initramfs, kernels (on 2MB flash parts).
At what gain? And at what loss?
If you want to block other hw completely like /dev/bios did, you can
just do cli/sti in a userspace program as well. That keeps timing issues
I agree flashrom should set itself to running with realtime policy
> One thing that should really drive this home, is that using this
> architecture on Linux *and* Windows, the same userspace tool could be
> used on both, so the fancy code for incremental updates, writing
> parameter blocks, etc., wouldn't have to be duplicated.
It should not be duplicated anyways. The Windows driver currently only
takes care of mapping memory into user space if I remember correctly.
> Isn't MTD framework capable of handling most of this already?
Yes, it is. And it is incredibly complicated and complex for such a
simple task. ie. it can be done, but MTD is designed for larger flash
parts with filesystems on them. For BIOS chips it is a bit of a PITA.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
More information about the coreboot