proprietary firmware

[Neng-Yu Tu (Tony Tu)]

joerg ??:
> Am Fr  15. Februar 2008 schrieb Brandon Kruse:
>> In that case it is not an open phone or platform. 
> It's a philosophical question, where "open" has it's limits. E.g. you probably 
> consider a plain vanilla x86 GNU/linux desktop system to be pretty much "true 
> open". However i guess you have no idea at all of the firmware that's 
> managing your harddisk in this system. That's for a simple reason: IDE 
> interface is age old (and so all HD's (SATA, SCSII) inherited this way we are 
> looking at these devices), it is "just working", and it's well documented. 
> Virtually nobody cares about the firmware behind this interface, mainly 
> because it doesn't have a chance to stop you from doing anything you like on 
> the _main_system_. I'm almost certain there's a hacker somewhere out there, 
> who likes to mod his HD so the head motors will produce funny sounds, and 
> another one thinks he can tune transfer rates even another 10k/s. However i 
> never seen FOSS HD firmware.

When things down to that low level, it's not only firmware issue. It 
also about chip selection for specific design. For example, every HD has 
some write cache mechanism in firmware, but some of read/wirte acceleron 
also chipset related, some chip vender's read/write cache command for 
SDRAM just faster and stable than others. And you will need these 
details specification to do the hardware ans firmware design.

Chip selection also is the balance of 
performance/usability/price/marketing, especially for mass production 
products like hard disk, user won't even notice the changes on chips and 
cause of change chips.

And transfer rate is a myth: means write into cache/or write on the disk 
and then verified it write correct. It has some many detais for a single 
  bit from keyboard to your hard disk. If anyone could get 10% transfer 
faster algorithm for any hard disk, no vendor would refuse it :)

> 
>> It is well worth the   
>> investigation to go fully open somehow IMO.
> Sure. But it's a silly idea to try and force the subsystem manufacturers by 
> refusing to support their closed source firmware updates. When Seagate comes 
> with a DOS-only firmware updater to add some cool new features to their 
> drives, OM says "No, it's not FOSS!". Seagate (or here, the chip fabs) don't 
> care. But OM deprives NEO owners of any means to have a new firmware for 
> these subsystems. If a user doesn't like to have closed source on his device, 
> she is free delete or not install it. But OM will not achieve anything by 
> refusing to provide closed source drivers. I think all they get is a huge 
> number of returns, or less sales (at least for me). 
> And OM(!) isn't willing or able to provide circuit diagrams, so any open 
> drivers are extremely hard to develop. In my opinion they can't do both, 
> refuse to support closed source updates *and* keep the hw specs closed. Not 
> if they care about their customers.
> Not to mention, NEO will not be "open" at all as long as the hardware is 
> a 'big mystery'. A laugh to start with closed firmware topic.
> 

Most function on GTA was exist in module format, and do a lot 
negotiation with vendor to open their document or firmware update 
utility. It is not OM say: We want this open. Then the vendor say: no 
problem, just open it. Usually comes with the answer that: Well, we need 
to ask our legal department first, and what's the quantities you want to 
buy. I think if we could buy their whole company, the openness should 
not be an issue anyway. But before that happens, we have to through long 
negotiation for each of the components for better hardware openness.

I think GTA is not as complex as ps3 or close hardware as Aphone, you 
could almost ask any question in the kernel development mailing list for 
the details for hardware related except ask for full schematics directly :)

I could not speak for OM, but open anything we did is the target, also 
the times we spent to talk with vendors, and we will keep persuade 
hardware vendor/industries anyway :)

>> But I guess we could be like olpc and have a MOSTLY open platform  
>> (wifi chip is not, as you could have guessed)
> I'd like it more to see OM pushing manufacturers to provide a guaranteed API, 
> which is specified by community, and not to care about _how_ the mfactrs 
> achieve to fulfill this contract. Than to nag manufacturers to open the 
> sources of firmware, "because we can do better, and do not want to use what 
> we paid for".

Maybe you imply a open standard for each hardware module access here :)

Tony Tu