本帖最后由 sinanjj 于 2010-3-13 22:08 编辑
我对marvell VS ralink的 选型产生了一些怀疑:
wiki对marvell的记录中有:
"Founded in 1995 by a husband-and-wife pair of Indonesian Chinese immigrants who met at UC Berkeley, "
"In October 2006, Marvell was criticized for failing to publicly provide specifications of their hardware in enough detail to support their wireless devices in the One Laptop Per Child program. Marvell was criticized by Richard Stallman of the Free Software Foundation and Theo de Raadt of OpenBSD. "
就是: 1, marvell的boss是印度尼西亚华人.
2, 2006年在OLPC项目中被批. 详细被批记录正在查.
还有, ralink是wifi**项目大力支持的. BT3也是个华人(taiwan)做的, 支援应该比较强.
2006年. 开源界与marvell冲突的一篇记录**
| Making sense of the One Laptop Per Child proprietary software row |  |  |  |
| Written by Jem Matzan | | Oct 09, 2006 at 07:12 PM | Theo de Raadt, the leader of the OpenBSD project and a vociferous crusader for hardware (especially networking) documentation, recently went public with his concerns about the One Laptop Per Child project's choice to use a wireless networking chip from Marvell, a company with an unusually poor record of supporting free software operating systems, in the 2B1 laptop computer that it is developing. Marvell is unwilling to freely supply hardware documentation so that programmers can create device drivers that properly interface with its wireless chips, and beyond that, Marvell also refuses to allow OpenBSD and other free software operating systems to freely distribute firmware binaries that are necessary to use Marvell wireless devices. So why, then, was it chosen for the OLPC project, which claims to "support open source?" If de Raadt's email was the first you heard of the conflict, you're probably confused as to what's going on. Below are explanatory interviews with various people who were or are involved with this situation: Theo de Raadt, Richard Stallman, Jim Gettys, and Jonathan Corbet.
One proprietary laptop per child?The One Laptop Per Child (OLPC) initiative, sponsored by MIT and Red Hat (which is developing a Fedora Core-based operating system for the device) aims to sell low-cost, energy efficient, GNU/Linux-based, education-oriented laptop computers to third-world governments for use in schools. On the one hand, this can be seen as a monumental victory for free software: it proves not only its viability in the realm of user-friendly desktop operating systems, but also as a means of reducing the overall cost of a computer. But is all of the software really free (as in rights, not price)? When faced with a choice among networking manufacturers, the project's developers chose the Marvell 88W8388 wireless chip because of its unique ability to create ad-hoc "mesh" wireless networks without having to use the computer's CPU. A "mesh" network allows each computer to act as a sort of wireless access point unto itself, removing the need for external wireless routers. By doing this without requiring the use of the CPU, the amount of battery power necessary to maintain the network is dramatically reduced. Since the OLPC laptop is designed for low energy consumption, and will likely see much use in environments that do not have reliable or readily-available electricity, the need to eliminate a dependence on discrete access points and use less power is important.
The Linux driver for the Marvell 88W8388 is already complete and licensed under the GNU General Public License, but the driver only interfaces with an ARM processor that in turn makes the wireless radio devices work. That processor requires its own tiny operating system in order to function, and this operating system is the firmware in question. Without the firmware, the processor is brain dead, and the device driver -- and by association, the device itself -- is useless.
The problem is, this Marvell wireless chip requires proprietary firmware, and as the license agreement in the preceding link shows, it is not free-as-in-rights to use, distribute, modify, or study. To the end users who want to use this wireless chip, the proprietary firmware problem can be solved in two ways: by convincing the manufacturer to license the firmware so that it can be redistributed by anyone to anyone, or by convincing the manufacturer to make the hardware's complete documentation available to free software developers so that they can write their own firmware code. According to OLPC representative Jim Gettys, both approaches are in progress. There is an ongoing effort to negotiate with Marvell for the right to freely redistribute this proprietary code, while at the same time some OLPC-contracted developers have signed a non-disclosure agreement (NDA) to access Marvell's hardware documentation in order to create a free software replacement for it.
Understanding the OLPC project's choicesI exchanged several emails with OLPC's vice president of software, Jim Gettys -- who was also one of the original designers of the X11 windowing system and the W3C editor in charge of the HTTP 1.1 specification, among other achievements in the computer technology industry -- in an effort to figure out what the uproar was about and what was actually going on. Excerpts follow:
Did you know when you selected the Marvell 88W8388 chip that it required proprietary firmware?
Jim Gettys: Yes, but there was no choice of wireless chips that met either power or price needs. And Marvell was not in a position itself to wave any magic wand to change the situation. The Marvell wireless driver is open source (GPL, as usual). Theo [de Raadt, of OpenBSD] is complaining that the firmware is not open, and to write code to run on the ARM processor in the Marvell wireless chip right now, you have to sign an NDA.
The firmware on that runs on the wireless chip's processor was built using a proprietary microkernel that Marvell does not own. So to have access to the firmware source requires an NDA, as access to that microkernel would in the first place. So until we have alternate microcode (which is, in fact being developed), there isn't any simple solution for Marvell (or us) to the situation.
What was your role in making this decision?
JG: I concurred entirely with others working on the project evaluating our options that this is our best (in fact only) option for this generation of the laptop. All other alternatives were worse both from an openness perspective (e.g. Atheros' closed HAL), and would have made power consumption so high that the very viability of the project would be called into question.
Why couldn't you have used a different chip by a more cooperative manufacturer?
JG: The Marvell wireless chip is in fact unique at the moment. Many or most children in the world do not have electric power, nor do they have computer networking. Without power being available, even if access points cost nothing, you have no network. So we are deploying mesh networking, to allow a child's laptop to forward packets for their neighbor's laptop.
Even as low power as the AMD Geode is, if it is turned on, it will consume 5-10 times the power that the Marvell wireless chip will consume. So for it to be feasible to have a human-powered laptop, which we have done, and a mesh network to connect the kids machines to each other and often to the Internet, we had to have some way to allow the mesh network to operate while the main Geode processor is suspended entirely (powered down), so that the mesh network can realistically stay up between battery charges: we cannot expect that a child spend much of their day generating electricity. We expect the Marvell part to consume about 300mw in typical use.
Not only does the Marvell part have an ARM processor, it has enough RAM to be able to store a good sized routing table and have enough space for packets. At anything like this price and power point, there simply isn't anything else on the market that remotely resembles that particular Marvell part. There are *no* other viable alternatives given our constraints on power and cost.
Marvell has been very helpful, and gone out of their way to help make it possible for us to have a machine as open as we and they can possibly make it. Here's a concrete example: there is an SD (Secure Digital) interface in the OLPC, using a part also made by Marvell. If you go look at the draconian NDA requirements of the SD Card Association, you'll see that it is effectively impossible to release a specification for an SD hardware interface without violating their legal terms (which is why SD interface support has been so difficult on free platforms until recently). So, to enable us to ship an SD interface where the SD association's own SD host controller interface specification would enable us to have open documentation and drivers, Marvell did a significant redesign at significant cost to make their part match that specification, at our request.
In the wireless chip case, they did not have that option: the code was not theirs to give away.
I've not signed more than my employee agreement with OLPC (which is quite unique as such agreements go; it is *not* the typical employee agreement). If I want to go look at the firmware for the Marvell chip in its current form, I very well might have to sign such a document. I'm not personally working on either the driver or firmware. Again, this is outside of Marvell's immediate control, the result of decisions they took years ago about how to develop their firmware.
There was no way to break this contradiction instantly: between the unique capabilities of the Marvell hardware, and Marvell having decided, well in the past, to use someone else's embedded operating system. And we are supporting people to make free and open firmware for the Marvell chip.
If the firmware is to remain closed and proprietary, how can this be justified when the Red Hat OLPC page paraphrases project founder Nicholas Negroponte by saying: "But the movement isn't about the laptop. It's not even about technology. It's about making knowledge open, so the next generation of children can learn from it, build upon it, and use it to create." How can the next generation of children learn from this machine if parts of it are restricted, as Marvell's firmware is?
JG: Well, let's see: You start at the boot sequence on OLPC, and you can see the first instructions in LinuxBIOS execute. Can you do that on your machine you typed your mail message to me on? No, you can't: you can on the OLPC.
You watch it go through truly unique strange VSA emulation code that makes the Geode able to look like a normal x86: you go to laptop.org's git and look at that unique piece of code, that AMD was kind enough to make available to us about a week ago, per agreements made with OLPC over 6 months ago.
You go through the X Window System (which I helped start, BTW): the driver source is in the X.org source repository already; same goes for our unique dual mode touch driver.
You will also note that the one part of that code that AMD could not distribute (the VESA emulation code, for similar reasons to Marvell; they did not own that code), no longer matters on OLPC: we no longer need it, now that we use the fbdev driver, and therefore have all the code we use in our BIOS ROM where you can see how the machine works.
You look at the kernel you are executing in the kernel, and through the user stack through applications, and so on.
And it is entirely possible, that by the time the machine ships in high volume months from now, it is possible that there may be available other firmware for the Marvell chip; but as that code it isn't running yet, we can't make that promise. As I've told Theo and you in other mail, we're working on it.
Free software advocates are most concerned with the reliance on and distribution of proprietary software; others are less demanding, but still need the right to distribute the proprietary firmware. From what I have read of Marvell's license agreement for this chip, neither faction will be satisfied.
JG: Free to distribute the blob is a done deal, as I understand it, other than getting the wording right; Marvell doesn't know enough about how to draft the wording, and we're working with their lawyers to get that done. This is a new world to Marvell, and it takes time to explain to the lawyers how to get the wording right; that starts by explaining the whole software distribution model, which is fundamentally different from proprietary software. Wording that seems fine presuming conventional software just doesn't work with derivative distributions. Until that understanding has had a chance to sink in, it is easy to talk past each other. And we had to get the firmware out in some form to start our ATest cycle, so we couldn't wait for that to be finished first.
Under what terms will the in-development free replacement firmware be licensed?
JG: Dunno to be completely honest. There are merits/demerits to the various licenses with different incentives; I'd expect one of the big three (MIT/BSD, LGPL or GPL), but beyond that, I don't think we've figured out the incentives yet.
Making a deal with the devil?Most people probably know Jonathan Corbet from his work on LWN.net (formerly Linux Weekly News), however, he is also a programmer. Corbet agreed to work on a Linux driver for another Marvell device -- a camera controller in the OLPC 2B1 laptop system. To enjoy the privilege of viewing the hardware documentation (which is necessary to quickly and correctly develop the driver), he had to sign a non-disclosure agreement. I asked him more questions than the ones printed below, but he did not respond to more than just these two at the time of this writing.
I see that you are working on the OLPC project with a different Marvell product -- the camera controller. Could you tell me if that device will require any proprietary (non-free) software, either in the form of a driver or firmware?
Jonathan Corbet: Yes, I am working on the camera controller; the first version of the driver was posted on the OLPC development list this very day. You can see the full source there if you are interested. A look at that driver will confirm (1) that it is a GPL-licensed driver, and (2) that it is not dealing with any firmware under any license.
If you had access to the Marvell hardware specs, were you asked to sign an NDA? Lastly, if you are developing software based on "secret" hardware specifications, will the resulting program be filled with so-called "magic numbers" that won't make sense to developers who wish to port the software to other operating systems (in other words, will the driver be reasonably portable to other platforms)?
JC: I will confirm that I have signed an NDA with OLPC.
As for what's in the driver, I would invite you to look at the code (see http://mailman.laptop.org/pipermail/devel/2006-October/002557.html) and decide for yourself. The driver itself is not immediately portable -- it is a Linux driver, not a BSD driver - but the principles of operation for the controller device should come through very well. I'm not much of a fan of "magic numbers" in any code.
That said, there is no doubt that having access to the hardware documentation makes an immense difference for anybody wishing to port or maintain a driver.
Concessions and compromises, or hard-line determination?The issues of restrictively licensed firmware and secret hardware specifications are not isolated to the Marvell 88W8388 wireless network chip, nor are they exclusive to wireless networking components. By hoarding necessary source code and device documentation, computer hardware manufacturers force many free software operating systems to either forgo full hardware support of the offending devices, or to make some sort of compromise. No one would like to see the end of restrictive software licenses and hardware manufacturer uncooperativeness as much as Free Software Foundation and GNU Project founder Richard Stallman and OpenBSD leader Theo de Raadt. So to better understand what concessions and compromises must be made in order to achieve better hardware compatibility -- or indeed whether such things end up actually benefiting anyone -- I interviewed both men. (Ed. note: Though the format of this article makes it appear differently, each was interviewed separately, asked the same or functionally similar questions, and was not made aware of the content of the other's replies before the interview. Both were, however, actively involved in a group discussion on this matter with OLPC and Red Hat representatives -- including Jim Gettys -- before and during the writing of this article.)
How would children benefit from the One Laptop Per Child computer system being totally free (as in rights)? If parts are proprietary, what will be lost?
Richard Stallman: Well, children as such probably won't know how to program, but later some will learn how, and will want to see the source code. Then they may want to modify the programs and distribute them, and others will want to use their modified versions.
What's lost through this decision is the opportunity to take a stand for freedom. To treat a non-free program as a legitimate thing is accept a situation where a developer has power over us. Once you treat this situation as acceptable, it tends to grow.
Theo de Raadt: At first I thought only the wireless device was undocumented, and required an NDA with Marvell. Now we know that the SD (Secure Digital) interface is insufficiently documented and requires an NDA with the SD Card Association. And the camera interface is also undocumented and requires an NDA with OmniVision. I wonder how many more parts of this laptop will be proprietary? If I am careful in selection, I can buy a laptop on the market today that has fewer proprietary parts.
Has the One Laptop Per Child project misled the free software community by choosing -- even temporarily -- to use hardware that requires proprietary firmware? Various OLPC representatives have repeatedly told me that they support "open source" (not "free software"), but that this support is secondary to their goal of getting inexpensive laptop computers to children.
RMS: I would say that they have done something very disappointing. I was starting to promote the OLPC last August in India. At the time I did not know about the non-free program, and when I found out about it, it was very disappointing to me. I tried to talk to some of the people involved with this decision, but it took some time to get in contact with them. Eventually I talked with them, but was unable to persuade them to drop it. Now I will wait and see what happens with the free replacement. It is always a mistake to remove freedom for some other goal. In the long term, you regret it.
TdR: I feel they have misled the community by acting as if they are open; they rode on our coat-tails. Now it turns out they are going to ship GPL'd code mixed with NDA-requiring proprietary drivers in the end. Even their LinuxBIOS will need to link into drivers that no one can repair because the documentation is locked up.
Once their developers' interest wanes (because probably the next revision of the laptop will use different chips) the lack of documentation will make the code less maintainable than a standard laptop from HP, IBM, or even Apple. It is astounding that a company like Red Hat would jump so eagerly into the proprietary computer business.
It's possible that the free firmware that Jim Gettys says has been commissioned will not be useful in anything other than the 2B1 OLPC computer. This angers some free software developers -- they feel it is a wasted effort. Is there an ethical problem in developing free firmware that can't reasonably be ported to another operating system?
TdR: We don't want open firmware which no one can maintain. We have not asked for firmware in source code. We have asked for interface documentation so that a driver could be written -- AND THEN MAINTAINED IN THE FUTURE. We have also asked for re-distribution rights to the firmware BINARIES, because otherwise our users would have to go through hurdles to get the firmware images.
RMS: No -- that doesn't matter. It is not an ethical requirement to make software that others can use. It's not the fault of the software if the chips are different. This is not a question of ethics at all.
What was your impression of the OLPC project before the Marvell incident?
RMS: I was looking forward to a laptop computer that has only free software. I might still use an OLPC, but I would disable the internal wireless chip, and use an external device that doesn't require me to install non-free software. If you go to the FSF.org Web site, there is a list of wireless network devices that use free drivers.
TdR: I had no particular impression. I have been to plenty of poor places in my life, but did not take the time to consider it critically, for good or bad. Then about three months ago I read an article about OLPC and Argentina in particular which made me realize the financial burden this would be on countries. The math is very bad, and this is just Argentina, which is not really a poor country. I go on extensive hiking trips around the world, and integrating that writeup with my experiences in the poorer parts of South America have significantly clouded things. I have of course previously said absolutely nothing about OLPC's efforts in this regard, but only focused on the fact that they are undermining open documentation efforts. And I wish this particular discussion would not stray from the open documentation problem that Red Hat is creating.
Do you think it is a reasonable compromise for free software developers to sign an NDA in order to create a free replacement for proprietary drivers or firmware? Do you think that programmers who do this are telling hardware companies that this practice is acceptable, in effect setting a precedent for future NDA demands?
RMS: A free replacement would solve the problem.
This is an interesting question. I would not sign such an agreement, for the same reason I started the free software movement: I think it is wrong to do so. I have never signed an NDA for generally useful technical information, and I don't want to start now. On the other hand, I can see how, since it eliminates a greater wrong, it can be justified in this case. It is an unfortunate example, but it could also eliminate the problem.
TdR: The open/free software development community is struggling to get more documentation completely exposed to the public. When someone with a very large budget signs an NDA, it sends the wrong message to the chip vendors. It says "there is no need to release documentation, we still get buyers". When that someone is a supposed Open Source vendor like Red Hat, the chip makers say "Red Hat signed an NDA, why won't you?"
Driver developers are being left in the cold. We struggle to write the drivers that the Linux and *BSD kernels need for operation, and more and more we do so without documentation. The things we need access to are being denied us, precisely because of the actions of companies like Red Hat who should be defending our access to information. They are trading a few OLPC drivers (which will be unmaintainable in the future) against the documentation needs of theentire developer community.
Do you think it is a reasonable compromise for free software operating systems like GNU/Linux and OpenBSD, etc. to have the ability to distribute non-free firmware? In other words, obtaining permission from the manufacturer to redistribute proprietary firmware with the operating system? What if it were stored permanently inside the hardware in a ROM, like most other devices do?
RMS: They shouldn't distribute the software -- that's wrong. It is a sign of how weak our community is in regard to freedom. If they are willing to give up freedom for convenience, they may end up getting some convenience -- in the short term, at least, but not in the long term. If the OLPC developers can't program a free replacement, then other people can. If the companies won't give out hardware documentation to create the free replacement, then people can reverse engineer it.
Having firmware on a ROM is okay because it isn't a computer which provides for installation of software. It is just a circuit. I don't mind that my microwave, for example, might have a computer with proprietary software in it, because it isn't designed for software to be installed.
When a device is designed for installation of software, then users deserve freedom in using that software.
TdR: The firmware is an integral part of the device, but unfortunately due to cost savings not stored on the device itself. Operating systems must supply the firmware, and then an open source driver can communicate with the combination of device+firmware. Every device these vendors make has a totally custom operating environment, different registers here, different bugs there, and no public documentation at all. It would be a herculean effort to write a free firmware for any of these devices, since a developer would be utterly blindly trying to talk to registers. The Intel wireless devices use a processor we do not even know the instruction set for. For an example of such an effort, see http://prism54.org/freemac.html where some people have been trying to write a completely free replacement firmware for a chip that shipped during the period 1999-2002. Read the history too. Note that the prism54 is a simpler-than-the-average 802.11 firmware-driven chip. The Broadcom and Intel chips are way more complicated (and buggy) internally.
But firmware replacement is precisely the kind of effort we may eventually get into if the vendors do not give us permission. We may have to reverse engineer their firmwares to write replacements. Those replacements will be of very poor quality for a very long time, due to the incredibly difficult programming environment. These vendor programmers used simulators and jtag to write the the firmware for these chips, and they knew all the registers and had the hardware designers next door. In our efforts, we might even melt some devices, and cause all sorts of spectrum damage. It is in everyone's best interest if the vendors would simply, through copyright law, grant re-distribution rights of the firmware binaries by other operating systems in the same way they allow Microsoft to distribute these binaries.
Some people (mostly just RMS) insist on firmware source code. We do not feel that we need or even want firmware source code -- just the missing binary component that allows the device to operate. Our #1 goal is that our users be able to use the devices they purchased. We feel that when RMS insists on things which vendors will never give, he confuses the vendors, and the vendors back off and end up giving us nothing at all. As a result, everyone loses -- RMS, the vendors, the operating system suppliers, and the users. This is not (yet) the time or place to make such strict statements.
What could the OLPC and/or Red Hat people have done differently to meet their technological goals without closing off parts of the hardware or software, keeping in mind that an OLPC representative has said that sales of the 2B1 laptop are in the vicinity of 8 million machines?
TdR: To this day, OLPC has not been transparent as to the exact reasons they chose the Marvell parts. There are at least 20 other vendors on the market who sell wireless chips with CPUs on them. Some have morememory than others. Some use less power than others. Some have SDIO buses, others do not. OLPC keeps saying that no other chip could do the task, but they have never stated how they came to that conclusion. Then they signed an NDA.
OLPC should say exactly what their needs are, and why they chose Marvell. Right now it sure looks like they were pre-disposed to use Marvell parts due to relationships that MIT 'roofnet' developers already had with Marvell.
RMS: I think they could have used that as leverage -- they should have been able to get more than they got.
Putting customers last?I managed to contact Marvell's outsourced PR agency, and a representative at that agency who handles the Marvell account agreed to ask relevant Marvell employees if they would go on record to explain why the company can't freely provide basic hardware documentation that would tell free software developers how to interact with Marvell chips, and why operating system projects like OpenBSD aren't allowed to redistribute firmware that anyone can easily download from the Web. I did not receive any comments from Marvell employees or Marvell's PR agency before the time of this writing. If I do hear anything, you'll see it in this space.
Perhaps, though, Marvell doesn't see a reason to bother explaining the logic behind its closed-door polices. We are, after all, only lowly end-users. Technically end-users are not Marvell's customers because it neither makes nor sells the actual hardware that people use. Instead, it makes chips that OEMs in turn buy and integrate into other components or finished electronic goods like PC motherboards, handheld devices, and peripheral cards. Marvell is abstracted from the people who actually use its products, and in a twisted sort of way, it's entirely possible that Marvell's actual OEM customers are completely satisfied with its performance and behavior, even if end-users are not.
Discuss this article or get technical support on our forum.
Copyright 2006 Jem Matzan.
问题的关键在于firmware是否开源. 那么.....我查查ralink是怎么处理的.(台湾人的firmware开源了么?)
|
|
楼主
