diff options
-rw-r--r-- | docs/fingerprint/fingerprint-factory-requirements.md | 20 | ||||
-rw-r--r-- | docs/fingerprint/fingerprint.md | 21 |
2 files changed, 32 insertions, 9 deletions
diff --git a/docs/fingerprint/fingerprint-factory-requirements.md b/docs/fingerprint/fingerprint-factory-requirements.md index dfd66d8eb1..9849cdd393 100644 --- a/docs/fingerprint/fingerprint-factory-requirements.md +++ b/docs/fingerprint/fingerprint-factory-requirements.md @@ -7,8 +7,8 @@ fingerprint sensor. ## Contact -For questions regarding this document, please contact the [Chrome OS -Fingerprint Team]. +For questions regarding this document, please contact the +[Chrome OS Fingerprint Team]. ## Terminology @@ -44,13 +44,20 @@ directory since multiple sensors may be used across a single "board" (e.g., the `hatch` board can use either `bloonchipper` or `dartmonkey`). The correct firmware type to use for a given board can be discovered with the -following command: +[Chrome OS Config] tool: ```bash (dut) $ cros_config /fingerprint board dartmonkey ``` +OR + +```bash +(chroot) $ cros_config_host -c /build/<BOARD>/usr/share/chromeos-config/yaml/config.yaml -m <MODEL> get /fingerprint board +dartmonkey +``` + The corresponding firmware for the above command would be `/opt/google/biod/fw/dartmonkey_*.bin`. @@ -64,7 +71,8 @@ When the FPMCU is completely blank a low-level flashing tool must be used to program an initial version of the FPMCU firmware. It’s possible to use the [`flash_fp_mcu`] script as this low-level flashing tool, though since it requires the AP and is not necessarily robust against failures, it is not -recommended for mass-production. +recommended for mass-production. More details about [`flash_fp_mcu`] are in the +[Fingerprint flashing documentation]. The initial version of the FPMCU firmware should be flashed either by the module house or by the factory. Once an initial version of the FPMCU firmware has been @@ -89,7 +97,7 @@ device). `timberslide` is the daemon that periodically sends commands to the FPMCU to read the latest FPMCU logs. It writes the results to `/var/log/cros_fp.log`. It should be fine to leave running during tests, though it should be stopped before -running the `flash_fp_mcu` script, since that script erases the entire FPMCU: +running the [`flash_fp_mcu`] script, since that script erases the entire FPMCU: ```bash (dut) $ stop timberslide LOG_PATH=/sys/kernel/debug/cros_fp/console_log @@ -467,3 +475,5 @@ Wrote /tmp/fp.1.png (14025 bytes) [Chrome OS Fingerprint Team]: http://go/cros-fingerprint-docs [Factory Fingerprint Sensor Testing for `nocturne`]: http://go/fingerprint-factory-testing-nocturne [`flash_fp_mcu`]: https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/flash_fp_mcu +[Fingerprint flashing documentation]: ./fingerprint.md#factory-rma-dev-updates +[Chrome OS Config]: https://chromium.googlesource.com/chromiumos/platform2/+/master/chromeos-config/README.md diff --git a/docs/fingerprint/fingerprint.md b/docs/fingerprint/fingerprint.md index 21ce372755..2c11992a7a 100644 --- a/docs/fingerprint/fingerprint.md +++ b/docs/fingerprint/fingerprint.md @@ -31,13 +31,20 @@ building the EC code) are for fingerprint: * Support for the STM32F412 for the FPMCU is not yet fully complete, but it is functional enough for testing. -If you have access to a shell on your Chromebook, you can run the following -command to determine the FPMCU that it contains: +If you have access to a shell on your Chromebook, you can use [Chrome OS Config] +to determine the FPMCU that it contains: ```bash (dut) $ cros_config /fingerprint board ``` +Alternatively, if you have a Chromium OS build, you can use [Chrome OS Config] +in the chroot to determine the FPMCU: + +```bash +(chroot) $ cros_config_host -c /build/<BOARD>/usr/share/chromeos-config/yaml/config.yaml -m <MODEL> get /fingerprint board +``` + ## Building FPMCU Firmware Locally ### See `Makefile` target options @@ -168,7 +175,7 @@ that do not have write protect enabled (dogfood devices, EVT, etc.) In production, only the RW portion of the firmware can be updated (unless the user disables [hardware write protection]). -## Factory / RMA / Development Updates +## Factory / RMA / Development Updates {#factory-rma-dev-updates} ### `flash_fp_mcu` @@ -185,10 +192,14 @@ flash (both RO and RW). The FPMCU can only be put into bootloader mode when [hardware write protection] is disabled, which means [`flash_fp_mcu`] can only be used when [hardware write protection] is disabled. +[`flash_fp_mcu`] is available in the [Chromium OS test image]. + ### `stm32mon` [`stm32mon`] is a tool used to send commands to the STM32 bootloader. We use it -for development (through `flash_fp_mcu`) to erase and flash the entire chip. +for development (through [`flash_fp_mcu`]) to erase and flash the entire chip. + +[`stm32mon`] is available in the [Chromium OS test image]. ## Keys @@ -316,3 +327,5 @@ This would make it a lot easier during both development and testing. [`timberslide`]: https://chromium.googlesource.com/chromiumos/platform2/+/master/timberslide [cros_ec_debugfs]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9db44685934a2e4bc9180ea2de87a6c429672395/drivers/platform/chrome/cros_ec_debugfs.c [Fingerprint Factory Requirements]: ./fingerprint-factory-requirements.md +[Chromium OS test image]: https://chromium.googlesource.com/chromiumos/platform/factory/+/master/README.md#building-test-image +[Chrome OS Config]: https://chromium.googlesource.com/chromiumos/platform2/+/master/chromeos-config/README.md |