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 anymore.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.
Understood.
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 ROM.
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 such distinctions.
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 correct?
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".
Regards, Carl-Daniel