[coreboot] [Fwd: Re: Contact Intel]
c-d.hailfinger.devel.2006 at gmx.net
Sat May 3 18:50:46 CEST 2008
On 02.05.2008 23:13, Richard M Stallman wrote:
> > If the "proprietary low-level chipset initialization code" is in ROM
> > on the chips that it initializes, then it is tolerable. (It might as
> > well be circuits on that chip.) Otherwise, it is insufficient unless
> > made complete.
> None of the current mainstream x86 board manufacturers uses real ROMs
> We may be partly miscommunicating, talking about different questions.
> I'm talking about where we should draw the line of what's acceptable.
> What is done in any particular product is a different question. Both
> questions are important, but they are different.
> If memory is physically writable, but is never updated once users get
> the product, that is more or less equivalent to ROM in my view. Thus,
> an EEPROM in a chip (or in a device) that contains the code to
> initialize the chip (or device) is tolerable if people treat it as a
The x86 world is difficult. We have network cards where the firmware
EEPROM is updatable, but the vendor will never offer an update. That
would qualify as ROM in your definition. However, another network card
with exactly the same chips and the same firmware, but a different model
number, may get firmware updates from the vendor. That would _not_
qualify as ROM in your definition, at least as I understand it.
The technical side of the ROM equivalence question does not allow for
It gets even worse once you look at CD/DVD burners and hard disks.
Depending on the model number (not the product itself), a vendor may
offer updates for such storage devices or not. CD/DVD burners very often
offer firmware updates, but it is extremely uncommon for hard disk
vendors to do that.
Firmware blobs which are loaded into devices, but where the blob never
changes even for different versions of the driver, would be tolerable
according to your definition (please correct me if I'm wrong).
> ISTR that it was necessary for free BIOSes to run some initialization
> code for the video card which is stored on the video card. Is that
Yes and no. It depends on the model of the video card.
> Is this still necessary?
There is free/open source code which can initialize some graphics
chipsets without having to run non-free code stored in the ROM of a
video card. This depends a lot on vendor cooperation and since the code
for each grapics card is different, you lose a lot of flexibility by
avoiding the execution of on-card routines.
> If so, it is an example of what I am talking about.
As I explained above, free software politics based on "ROM equivalence"
in the firmware category do not make sense from a technical point of view.
Please note that any laptop where the manufacturer refuses to provide
BIOS updates would be tolerable according to you because "memory is
physically writable, but is never updated once users get the product".
More information about the coreboot