Author: wmb Date: 2009-12-13 21:22:36 +0100 (Sun, 13 Dec 2009) New Revision: 1594
Added: cpu/x86/pc/olpc/via/mfgtests.txt Log: Via manufacturing tests - checked in documentation file.
Added: cpu/x86/pc/olpc/via/mfgtests.txt =================================================================== --- cpu/x86/pc/olpc/via/mfgtests.txt (rev 0) +++ cpu/x86/pc/olpc/via/mfgtests.txt 2009-12-13 20:22:36 UTC (rev 1594) @@ -0,0 +1,159 @@ +=== Manufacturing Test Sequencing === + +Version as of 2009-12-11 + +The manufacturing process is sequenced by setting the BD tag, which +controls OFW's boot-device list. BD has different values at different +stages, thus controlling the way that the system boots. For a given +manufacturing phase, BD points to a list of boot scripts from local +devices or network servers that are available at that station. The +boot script performs phase-dependent activities. + +The TS tag identifies the test station. Its primary use, other than +as a human-readable indicator of the system's progress through the +manufacturing flow, is to fine-tune the selftest diagnostics for the +needs of the particular test station. + +Test results and other information about the system are sent to a +station-dependent server whose location and credentials are given by +the MS tag. That server uses a tag-exchange protocol to receive +information about the system and to return information that is used +to setup the machine for the next phase. That setup typically includes +new values for BD, TS, and MS that are suitable for the next station. + +The starting values for those tags are: + + TS=SMT + MS=cifs:\bekins:bekind2@10.60.0.2\nb2_fvs + BD=u:\boot\olpc.fth cifs:\bekins:bekind2@10.60.0.2\nb2_fvs\olpc.fth + +They are initialized by running a script to inject those tags into the +initially-blank manufacturing data area in the OLPC-released firmware +image. That creates a new master image that is used to preprogram (via +a gang programmer) the SPI FLASH chips before they are soldered to the +boards. + +=== SMT state === + +Entry condition: + + TS=SMT + MS=cifs:\bekins:bekind2@10.60.0.2\nb2_fvs + BD=u:\boot\olpc.fth cifs:\bekins:bekind2@10.60.0.2\nb2_fvs\olpc.fth + +The booted script performs selftest in test-station=1 mode. Upon success, +it performs tag exchange with the "MS" server and rewrites the tags to +the value the server specified (examples below). + +=== ASSY state === + +Entry condition: + + TS=ASSY + MS=cifs:\Administrator:qmssdl@10.0.0.2\olpc_mono1 + BD=u:\boot\olpc.fth net + +The booted (from the net, using TFTP etc) script does the tag +exchange, runs the download (with command line given by the tag +exchange response), and rewrites the tags. The next state is RUNIN. +The "DL" state never shows up in the tags. + +The response includes one or more "Command:<Forth_commands>" lines. +Those lines are executed to perform the download steps. +An example value for such a line is "fs-update http:\10.0.0.1\os41.zd". +The Doing it this way instead of hardcoding it in the script permits +country-specific +images without having to edit the script. The file could also be +served from a Windows server if desired; it need not be http. + +The response tags from this stage include the ones shown in entry +condition for the RUNIN state. + +The script also needs to know the URI for a directory containing +files for KA values. The filename is <ka-dir><filename> where +<filename> is what the server sends after "KA:" . For now, the +test script hardcodes the value of <ka-dir>. + + +=== RUNIN state === + + TS=RUNIN + BD=u:\boot\olpc.fth int:\runin\olpc.fth int:\boot\olpc.fth + MS=<URI for final server> + +Initially, the boot file is int:\boot\olpc.fth from the OS +distribution. The Linux-based runin tests will create +int:\runin\fail.log when finished. If the runin tests failed, +they will create int:\runin\fail.log prior to creating +int:\runin\olpc.fth. + +The script in int:\runin\olpc.fth does the following: + +# Check for the existence of int:\runin\fail.log. If it exists, + display it on the screen with a red background and stop. Later + rebooting will continue to show the red-screen error message + until the user manually deletes int:\runin\fail.log and + int:\runin\olpc.fth by manually executing the command "re-runin" + (that command is defined in \runin\olpc.fth . It first deletes + \runin\olpc.fth and then \runin\fail.log ) . + +# Otherwise (pass case) + a) Starts selftest in final mode + b) (The test are ordered so the non-interactive ones are first) + c) When the sd card insertion point happens, a big check is displayed + d) The operator moves the unit from carousel to the final test line and inserts SD card + ??? Do we need to insert a USB stick too? + ??? Do we need to insert scanner and wlan here too to give the USB test something to work on? + e) final test steps continue until pass or fail + +# If selftest passed + Tell operator to move to the download station and insert USB LAN + wait-lan + wait-scanner + tag exchange with server + barcode scan of serial number to verify that the board and case are still paired + ??? Is the filename the MB (B#) or the case serial number (SN) ? + ??? If the filename is the SN, why is the SN in the request file? + The server can't verify if it only has the SN and not the board# + delete MS and BD tags, insert tags from server + ??? what is the format of the WP:N and AK:N info from the server? Is it WP:0 / WP:1, or presence/absence ? + TS should be SHIP at this point + ??? Does the server send TS:SHIP or does the script inject it verbatim? + +# If selftest failed, red screen and stop. State of machine (BD tag, + \runin\olpc.fth) left the same as at the start of this phase so + the phase can be rerun. + +=== SHIP state === + +Entry condition + + TS=SHIP + MS (deleted) + BD (deleted) + +=== Design Features === + +The above design has the following features: + +* Once the machine leaves the factory, it does not contain any + information about factory server names or their credentials. + (The tags containing that information are deleted for CUSTOMER + state, and the Linux-based runin scripts contain no hardcoded + factory server identification.) + +* The boot scripts that perform the test sequencing do not have to + change to accomodate server changes. (The server information + is stored in mfg data tags.) + +* OFW contains very little "hardcoded" information about the + process steps - it just boots from the specified device at + each stage. This minimizes the changes to the OFW startup + sequence - the only change is to set "boot-device" from BD + if it exists. If BD doesn't exist, the normal default list + is used, which supports booting from USB, so you can recover + a system that is out of sequence. + +* At any step, the normal server-based process can be overridden by + plugging in a USB stick with a custom \boot\olpc.fth . (Each BD + list has "u:\boot\olpc.fth" at the beginning.)