Fix broken image links in go/faft doc
For some reason, the image links provided as <img src="..." /> render
properly when viewed in-browser from the filesystem, but not when viewed
through Gitiles. The latter is how go/faft is shown. Hence, go/faft was
not displaying images.
This CL replaces the image links in faft-design-doc.md with the ![]()
syntax used by wifi-basics-codelab.md, which does seem to render
properly in Gitiles:
https://chromium.googlesource.com/chromiumos/third_party/autotest/+/
refs/heads/master/docs/wifi-basics-codelab.md
TEST=Open the Base and Patchset Gitiles links of this CL from Gerrit.
Expect to see no images when viewing Base, and yes images for Patchset.
BUG=None
Change-Id: Iefd51088e186a7ed8971e9adced23e5f56864c96
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/2041693
Tested-by: Greg Edelston <gredelston@google.com>
Reviewed-by: Kevin Shelton <kmshelton@chromium.org>
Commit-Queue: Greg Edelston <gredelston@google.com>
diff --git a/docs/faft-design-doc.md b/docs/faft-design-doc.md
index 30fb98b..48b7df1 100644
--- a/docs/faft-design-doc.md
+++ b/docs/faft-design-doc.md
@@ -54,7 +54,7 @@
The U-Boot software stack looks like the following graph: [cl/70339149](https://critique.corp.google.com/#review/70339149)
-<img src="assets/faft-u-boot-stack.png" />
+
Most of the verified boot logic and crypto algorithms are inside the vboot_reference library. The main control logic in U-Boot is simple, just like reading some headers from SPI and filling them in a data structure which is then passed to vboot_reference.
@@ -62,7 +62,7 @@
The firmware boot path is like the following graph:
-<img src="assets/faft-firmware-boot-path.png" />
+
Our tests are mostly focused on VBoot Bootstub and VBoot Main Firmware since they are complicated and many decision branches. U-Boot initialization and kernel booting are simple and single path decisions. So full system regression tests are enough.
@@ -79,7 +79,7 @@
vboot_reference provides a lot of tests varying from crypto algorithms to vboot main logic and control flows. These tests stub the underlying APIs as all success functions. So it is unable to validate the correctness of underlying BIOS platform and the hardware behaviors.
-<img src="assets/faft-vboot-reference-tests.png" />
+
<a name="u-boot-vbexport-vboot-tests" />
@@ -89,7 +89,7 @@
Almost all the U-Boot drivers are abstracted into couple of major APIs: VBExport APIs and main logic used driver APIs. U-Boot provides a CLI for manual diagnostic. We wrote some commands to test these APIs. For example, for testing the disk read/write functions, a test command is to write some patterns to the disk and read them back to verify. However, some of these tests needs human involved, like inserting an USB stick to check if it is detectable.
-<img src="assets/faft-u-boot-vbexport-vboot-test.png" />
+
<a name="saft-semi-automated-firmware-test" />
@@ -101,7 +101,7 @@
SAFT assumes the whole firmware as a black-box and tests the whole system from firmware, kernel, to rootfs. For example, it corrupts firmware RW A/B to see if it enters recovery mode success. However, SAFT also needs human involved in many cases.
-<img src="assets/faft-saft.png" />
+
<a name="factory-regression-testing-using-servo" />
@@ -137,7 +137,7 @@
- get console output via UART;
- simulate USB plug in/out, by either muxing a physical USB stick or emulating a USB storage gadget in the host machine.
-<img src="assets/faft-test-environment.png" />
+
<a name="test-harness" />
@@ -162,7 +162,7 @@
Here is our proposed FAFT framework. The red pieces are missing and need to be implemented in this project.
-<img src="assets/faft-software-architecture.png" />
+
All the FAFT test cases are server side tests, meaning that all the actions are controlled by Host. It is flexible to keep states after sequential reboot. However, we still want to get the DUT state and run some command on it, like getting current firmware version, setting the fw_try_b flag, etc. These actions should be completed in the DUT. So we setup a FAFT Client for this purpose and use RPC to communicate with it.
@@ -269,7 +269,7 @@
In order to increase the test coverage and verify the underlying BIOS functions and drivers, a good entry is to re-run all existing vbexport / vboot tests in an automated way using our test framework!. See more detail in the State of the Art Section. We can catch bugs easily if any drivers changed or the BIOS source rebased.
-<img src="assets/faft-u-boot-vbexport-vboot-test.png" />
+
<a name="scope-3" />