proprietary firmware

Wolfgang Spraul wolfgang at openmoko.com
Sat Feb 16 08:54:53 CET 2008


Tony -

> ... 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, ...

FANTASTIC!
Tony, your explanation settles this topic once and for all...
Way to go!

Wolfgang

On Feb 16, 2008, at 12:42 PM, Neng-Yu Tu (Tony Tu) wrote:

> 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
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community





More information about the community mailing list