Feature roadmap/Faster imaging: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Automated import of articles)
 
No edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 17: Line 17:
# On next reboot of the XO its running the new image. Subsequent boots do not do this multicast listening unless configured specifically by the user.
# On next reboot of the XO its running the new image. Subsequent boots do not do this multicast listening unless configured specifically by the user.
|Specification=
|Specification=
See also: [[Multicast NAND FLASH Update]]<br>
See also: [[Nandblaster|Multicast NAND FLASH Update]]<br>


Some open issues to be addressed by the design proposal:
Some open issues to be addressed by the design proposal:
Line 26: Line 26:
* Any other security points?
* Any other security points?


|Owners=Greg, Reuben, Mitch
|Owners=Gregorio, Reuben, wmb@firmworks.com
|Priority=2
|Helps deployability=yes
|Target for 9.1=yes

}}
}}

Latest revision as of 06:32, 4 August 2010

Feature subcategory Is part of::Category:Security, activation and deployability
Requesters {{#arraymap:Ethiopia, Rwanda, Haiti|,|x|Requested by::x}}
Requirements This feature request is needed to minimize the time to install a custom image over a wireless or wired network. It will be used when an XO comes from the factory with an older release. The deployment then needs to upgrade to the latest release and possibly install some customizations (e.g. content, language pack, activities, see also separate customization requirement below). The solution must be faster than imaging via USB sticks for imaging more than 1,000 XOs. Must allow install of new image via wireless or wired network. Possibly sub-variants of in school case for Mesh, Wireless AP, XS.

Workflow example for the network case above:

  1. XOs leave the factory with an older image (e.g. 8.2.1) which includes this OFW code.
  2. A custom image based on the same or a later release including activities, content, language and maybe other customizations is prepared and loaded on the XS.
  3. An AP is setup and wired to the server.
  4. The XOs are turned on, as many as they have power jacks for. On boot up we can require that they hold down some special keys (game keys).
  5. Release the keys and the XOs find the AP and start listening on preconfigured multicast broadcast address.
  6. The XS broadcasts on the preconfigured address and each XO starts receiving.
  7. In case of errors which are more than what can be recovered by error correction the XOs, pick up again on the second broadcast or third or up to ... n (where is configurable or they just turn t he server off).
  8. When the XO has a complete image it notifies by putting a special image on the screen.
  9. On next reboot of the XO its running the new image. Subsequent boots do not do this multicast listening unless configured specifically by the user.
Specification See also: Multicast NAND FLASH Update

Some open issues to be addressed by the design proposal:

  • Do we pre-configure an ESSID and multicast addresses and hard code those in the factory?
  • Can we get it down to no intervention of hold down games keys only?
  • What happens if you turn on "too many" XOs? Can we just let them turn on as many as they want and we'll fill them in some order or should we

limit it to set # of XOs at a time? Can we scale it by using more "channels" or more APs?

  • Any other security points?
Owners {{#arraymap:Gregorio, Reuben, wmb@firmworks.com|,|x|Contact person::User:x}}
Priority Priority::2
Helps deployability? Helps deployability::yes
Target for 9.1? Target for 9.1::yes