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.)