Ticket #429 (new defect)

Opened 7 years ago

Last modified 5 years ago

wireless firmware not in-house.

Reported by: dwmw2 Owned by: walter
Priority: high Milestone: Future Release
Component: wireless Version:
Keywords: Cc: sjoerd, gdesmott, sph0lt0n, mtd, grantbow
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description (last modified by jg) (diff)

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

Change History

  Changed 7 years ago by jg

  • description modified (diff)

  Changed 7 years ago by jg

  • milestone changed from BTest-2 to BTest-3

  Changed 7 years ago by AlbertCahalan

This is a dupe of ticket #46.

Anyway, send me the info.

  Changed 7 years ago by mbletsas

  • priority changed from blocker to low

follow-up: ↓ 6   Changed 7 years ago by 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?

in reply to: ↑ 5   Changed 7 years ago by mbletsas

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.

follow-up: ↓ 8   Changed 7 years ago by 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.

in reply to: ↑ 7 ; follow-up: ↓ 9   Changed 7 years ago by 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.

M.

in reply to: ↑ 8   Changed 7 years ago by 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.

  Changed 7 years ago by jg

  • owner changed from mbletsas to walter
  • priority changed from low to high

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.

  Changed 7 years ago by jg

  • verified unset
  • milestone changed from BTest-4 to Trial-2

  Changed 7 years ago by jg

  • milestone changed from Trial-2 to Trial-3

  Changed 7 years ago by jg

  • milestone changed from Trial-3 to V1.1

  Changed 6 years ago by dwmw2

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.

  Changed 6 years ago by sjoerd

  • cc sjoerd added

  Changed 6 years ago by gdesmott

  • cc gdesmott added

  Changed 6 years ago by walter

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

  Changed 6 years ago by sph0lt0n

  • cc sph0lt0n added

  Changed 6 years ago by mtd

  • cc mtd added
  • next_action set to never set

  Changed 5 years ago by grantbow

  • cc grantbow added
Note: See TracTickets for help on using tickets.