proprietary firmware

[joerg]

Am Sa  9. Februar 2008 schrieb Steven Kurylo:
> > I don't
> > want to know how 802.11b protocol is handled in the wlan-chip. I want to 
> > have a powerfull bugfree API for the subsystem.
> 
> In a Free software world, we do want to know.  
Ok, agreed. But where ends SW and starts HW. Dedicated custom processor; 
bootload-firmware; flashrom-fw; OTP-rom fw; mask programmed rom fw; FPGA; 
even hardwired comparators and adders? The src is worth nothing for an alien 
cpu command set, the whole fw src is nothing without register documentation. 
Where to stop? FW of the DVD-writer with burn-receipes, of the HD with the 
algos of the head-amp-DSP therein? This is valuable IP of the 
DVD/HD-Manufacturer, they won't disclose. Power management of WiFI exactly 
the same.

> For various reasons, 
> one of which is because there is no "powerful bugfree API". 
True. For every level API. No matter if that's driver API (to the "firmware") 
or HW-API (description of registers and chip functions).

> They'll 
> be bugs and we (as in the Free software community) can fix them; I
> don't want to be at the mercy of some random company. 
You *always* are, one way or the other. If the description of a register (e.g 
timing) is faulty, you won't fix anything, neither the driver nor the chip 
itself, unless you have the chip design data (masks etc). See actual 
processor bug, would you like to have microcode documentation, so you can 
decide whether or not, and how you may fix it with a microcode patch? You 
have to learn how the CPU works internally (down to gate-level timing) to do 
so. And this means open HW, what nearly never will happen.

I feel quite like you, but i don't think anyone may *force* hw-manufacturers 
to do it our way. Instead they should offer more support and information. And 
guarantee a clean API.

j