wireless firmware not in-house.

[David Woodhouse]

We need our own wireless firmware. Lack of visibility and debugging ability is a real technical problem.

[AlbertCahalan]

This is a dupe of ticket #46.

Anyway, send me the info.

[cjb]

I don't understand why this could change from "blocker" to "low" with no comment, so I suspect some miscommunication. Michailis, has the situation changed?

[Michail Bletsas]

Replying to cjb:

I don't understand why this could change from "blocker" to "low" with no comment, so I suspect some miscommunication. Michailis, has the situation changed?

Yes, the situation has changed dramatically. Basically, I have to deliver fully working firmware by the end of the month, well before any other component of the laptop is done. So, I really don't care if the firmware is in house or not, and I cannot consider this ticket a blocker or even high priority at this point.

M.

[AlbertCahalan]

Perhaps you could deliver working firmware if you trusted the community to help you.

We'll write new firmware one way or another, even if we have to disassemble the blob.

You really should be providing everything, many months ago. I'm told there is a 3rd-party OS involved; fine you can still provide all the rest even if it won't run.

[Michail Bletsas]

Replying to AlbertCahalan:

You are banging on the wrong door, this is not OLPC's intellectual property that you are asking OLPC to provide.

M.

[AlbertCahalan]

Replying to mbletsas:

Replying to AlbertCahalan:

You are banging on the wrong door, this is not OLPC's intellectual property that you are asking OLPC to provide.

Hmmm, OK, but you destroyed your bargaining position the moment you admitted that you'd be willing to ship with a binary blob. Open Source and/or open hardware documentation should have been a requirement of every contract, complete with penalties for non-performance of the contract.

According to bug #46, "much/most of the code now in the firmware is not encumbered". Is this not true? The unencumbered portion should be released immediately, even if it won't build without the missing parts.

[Jim Gettys]

This is really a Walter issue to resolve.

And as we get into the field it becomes much more important.

As of last night, the base driver/firmware got to a "all serious problems are believed resolved"; but debugging in the field with no insight to what is going in becomes a true problem.

Please, no one add to this discussion except Walter at this point, who is very much aware of the issue and has been working it for quite a while. Further discussion here is pointless.

[David Woodhouse]

This is going to hurt us.

Lots.

Soon.

We should explore the possibility of opening at least the high-level parts of the firmware -- the 802.11 protocol bits, and the module<->host communication -- at least to OLPC under an NDA, if not completely. The low-level parts which deal with the transceiver hardware itself could remain in binary form for now, if they really must.

As long as we can poke at and rebuild the high-level parts, it shouldn't be _quite_ so much of a problem for us if we have only binary object files for the low-level code, and we just link those binary blobs into our own firmware builds.

[Walter Bender]

That Woodhouse has been cleaning up the Linux driver side of things gives us an excuse to revisit this with Marvell again...