Lines Matching +full:rootfs +full:- +full:arm
5 _Self-link: [go/faft-design-doc](https://goto.google.com/faft-design-doc)_
9 - [FAFT (Fully Automated Firmware Test)](#faft)
10 - [FAFT Related Documents](#faft-related-documents)
11 - [Introduction](#introduction)
12 - [Backgrounds](#backgrounds)
13 - [State of the Art](#state-of-the-art)
14 - [VBoot_Reference Library Tests](#vboot-reference-library-tests)
15 - [U-Boot vbexport/vboot Tests](#u-boot-vbexport-vboot-tests)
16 - [SAFT (Semi Automated Firmware Test)](#saft-semi-automated-firmware-test)
17 - [Factory Regression Testing Using Servo](#factory-regression-testing-using-servo)
18 - [U-Boot Test System ](#u-boot-test-system)
19 - [FAFT Implementation Details](#faft-implementation-details)
20 - [Test Environment](#test-environment)
21 - [Test Harness](#test-harness)
22 - [Software Architecture](#software-architecture)
23 - [Test Case Example](#test-case-example)
24 - [FAFT Scopes](#faft-scopes)
25 - [Scope 1: Enhance SAFT in Automated Way on Autotest Harness](#scope-1)
26 - [Scope 2: Test the Layer of VBExport APIs](#scope-2)
27 …- [Scope 3: Verify Recovery, Factory Install, Firmware AU, RMA, and Many Complicated Flows](#scope…
28 - [Scope 4: Monkey Test during Firmware/EC update](#scope-4)
29 - [Other Ideas](#other-ideas)
31 <a name="faft-related-documents" />
35 - [FAFT Setup Instructions](https://chromium.googlesource.com/chromiumos/third_party/autotest/+/ref…
36 - FAFT Test Coverage (Google internal only): [http://goto/faft-coverage](http://goto/faft-coverage)
37 - FAFT Comparing Existing Manual Test Cases (Google internal only): [http://goto/faft-comparison](h…
43 … of this secured castle. In addition, part of the firmware is marked as read-only, that means we a…
46 - Fully automatic, no human involved;
47 - Real test of physical hardware, like USB plug-in, Ctrl-D key press;
48 - High test coverage of complicated verified boot flows;
49 - Easy to integrate to our existing test infrastructure, i.e. deploy to test lab, run remotely, con…
55 This document uses [U-Boot](http://en.wikipedia.org/wiki/Das_U-Boot) as an example to discuss the F…
57 The U-Boot software stack looks like the following graph:
59 
61 …gorithms are inside the vboot_reference library. The main control logic in U-Boot is simple, just …
63 The underlying U-Boot drivers are abstracted into VBoot Export APIs and some (not too many) APIs wh…
67 
69 …VBoot Main Firmware since they are complicated and many decision branches. U-Boot initialization a…
71 <a name="state-of-the-art" />
75 <a name="vboot-reference-library-tests" />
84 
86 <a name="u-boot-vbexport-vboot-tests" />
88 ### U-Boot vbexport/vboot Tests
90 Source: src/third_party/u-boot/files/common/cmd_vb*_test.c
92 Almost all the U-Boot drivers are abstracted into couple of major APIs: VBExport APIs and main logi…
94 
96 <a name="saft-semi-automated-firmware-test" />
102 First of all, SAFT only works on x86 and hasn’t ported to ARM yet.
104 SAFT assumes the whole firmware as a black-box and tests the whole system from firmware, kernel, to…
106 
108 <a name="factory-regression-testing-using-servo" />
112 …om/document/d/1XZgX4_v-Ps7YBRnjZmCFYjrjyBZQz5YmRrg7YWBFfV0/edit?hl=en_US](https://docs.google.com/…
114 …-going project to ensure the whole factory install flow work fine. It downloads a factory bundle f…
118 <a name="u-boot-test-system" />
120 ### U-Boot Test System
124 …-Boot native test system to split the U-Boot components into platform code and generic U-Boot code…
126 <a name="faft-implementation-details" />
130 <a name="test-environment" />
136 - flash a new firmware image;
137 - run regression tests;
138 - simulate lid close, power cycles, gpios, and key presses;
139 - get console output via UART;
140 - simulate USB plug in/out, by either muxing a physical USB stick or emulating a USB storage gadget…
142 
144 <a name="test-harness" />
150 - easy to integrate to buildbot;
151 - easy to run remotely;
152 - easy to deploy to the test lab.
156 - src/third_party/autotest/files/server/site_tests/platform_CloseOpenLid
157 - src/third_party/autotest/files/server/site_tests/platform_LongPressPower
161 <a name="software-architecture" />
167 
171 <a name="test-case-example" />
176 1. FW A normal boot -> enable devsw + set try_fwb -> reboot -> press ctrl-d
177 2. FW B developer boot -> do nothing -> reboot -> press ctrl-d
178 3. FW A developer boot -> disable devsw -> reboot -> do nothing
179 4. FW A normal boot -> finished
185 # ------------------------- step 1 -------------------------
190 # ------------------------- step 2 -------------------------
195 # ------------------------- step 3 -------------------------
200 # ------------------------- step 4 -------------------------
216 <a name="faft-scopes" />
222 <a name="scope-1" />
261 - Create a separated FAFT client and wrap all existing SAFT libraries into it;
262 - Setup RPC to invoke FAFT client instead of using SSH tunnel like the demo;
263 - Enhance the functions of FAFT server side utilities;
264 - Make FAFT framework more generalized to fit any possible test cases;
265 - Keep the state and backup firmware/kernel in the server side instead of USB;
266 - Automatic setup DUT disk and USB image when given a buildbot image.
268 <a name="scope-2" />
272 … and verify the underlying BIOS functions and drivers, a good entry is to re-run all existing vbex…
274 
276 <a name="scope-3" />
293 …/ccc?key=0AoHv3bO2oLIjdGQ5cnJ6eWc1ZnpjYzlaWFA4T0xlVVE&hl=en_US&authkey=CJWF8-gP#gid=8). Reset shim…
295 <a name="scope-4" />
304 <a name="other-ideas" />
308 - Run FAFT on every build, integrated with buildbot
309 - Stress test to ensure the stability of hardware and drivers
310 - Cold reboot test
311 - Use HDMI capture device or camera + image recognition to verify the display output