diff --git a/.markdownlint.yaml b/.markdownlint.yaml index 18c3383e..ea46f81f 100644 --- a/.markdownlint.yaml +++ b/.markdownlint.yaml @@ -140,7 +140,7 @@ MD031: # MD033/no-inline-html - Inline HTML MD033: # Allowed elements - allowed_elements: ["br"] + allowed_elements: ["br", "center", "img", "script"] # MD034/no-bare-urls - Bare URL used MD034: true diff --git a/README.md b/README.md index f92666d3..a81f1f92 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ This repository contains source code for Dasharo documentation webpage ```shell virtualenv -p $(which python3) venv source venv/bin/activate -pip install mkdocs mkdocs-material +pip install -r requirements.txt mkdocs build ``` @@ -36,11 +36,15 @@ There should be no TBD or TODO visible on website. # pre-commit hooks -- [Install pre-commit](https://pre-commit.com/index.html#install) +- [Install pre-commit](https://pre-commit.com/index.html#install), if you + followed [local build](#local-build) procedure `pre-commit` should be + installed + +- [Install go](https://go.dev/doc/install) - Install hooks into repo: -``` +```bash pre-commit install --hook-type commit-msg ``` @@ -52,3 +56,12 @@ pre-commit install --hook-type commit-msg ```bash pre-commit run --all-files ``` + +## To skip verification + +In some cases it may be needed to skip `pre-commit` tests, to do that please +use: + +```bash +git commit --no-verify +``` diff --git a/docs/common-coreboot-docs/dasharo_tools_suite.md b/docs/common-coreboot-docs/dasharo_tools_suite.md new file mode 100644 index 00000000..ea39284a --- /dev/null +++ b/docs/common-coreboot-docs/dasharo_tools_suite.md @@ -0,0 +1,37 @@ +# Dasharo Tools Suite + +## Introduction + +Dasharo Tools Suite (DTS) is a set of tools for deploying, updating and +maintaining firmware on Dasharo supported devices. DTS is integrated into the +firmware in Dasharo supported devices and can be used to update the firmware +even when no OS is installed. + +## Requirements + +- Dasharo device with DTS functionality integrated +- Wired network connection +- Secure Boot disabled + +## Launching DTS + +To access Dasharo Tools Suite: + +- Attach a wired network cable to the device's Ethernet port +- Power on the device, holding down the Boot Menu entry key +- In the Boot Menu, select the `iPXE Network Boot` option +- In the Network Boot menu, select the `Dasharo Tools Suite` option +- Login as `root` (no password) + +The DTS shell will now appear. + +## Using DTS + +Within DTS, you may use the `flashrom` and `fwupdmgr` utilities to update, +downgrade, or reinstall your firmware. + +To update your firmware to the latest version: + +```bash +fwupdmgr update +``` diff --git a/docs/dev-proc/smbios-rules.md b/docs/dev-proc/smbios-rules.md index 0d0cd125..8ad32550 100644 --- a/docs/dev-proc/smbios-rules.md +++ b/docs/dev-proc/smbios-rules.md @@ -10,15 +10,16 @@ for Dasharo developers. ### Vendor field -The Vendor field, for firmware with initial release date after 13 January 2021, is set as follows: +The Vendor field, for firmware with initial release date after 13 January 2021, +is set as follows: -``` +```bash 3mdeb ``` For firmware with initial release date before 13 January 2021: -``` +```bash 3mdeb Embedded Systems Consulting ``` @@ -35,10 +36,11 @@ Dasharo ([major_framework]+[minor_framework]) v[version] - `minor_framework` is the secondary framework, a supporting component for the primary framework, e.g. a coreboot payload. May not always be used, e.g. if `edk2` is used as the primary framework. -- `version` means version according to official [Dasharo Versioning](../versioning) documentation. +- `version` means version according to official + [Dasharo Versioning](../versioning) documentation. -*For [TianoCore UEFIPayloadPkg](https://github.com/Dasharo/edk2/tree/workstation/master/UefiPayloadPkg), -we use the simpler and more recognizable UEFI name.* +_For [TianoCore UEFIPayloadPkg](https://github.com/Dasharo/edk2/tree/workstation/master/UefiPayloadPkg), +we use the simpler and more recognizable UEFI name._ Examples: diff --git a/docs/dev-proc/source-code-structure.md b/docs/dev-proc/source-code-structure.md index d8dae221..33d8a498 100644 --- a/docs/dev-proc/source-code-structure.md +++ b/docs/dev-proc/source-code-structure.md @@ -5,7 +5,9 @@ branch structure: * `master` - follows upstream project master branch * `/release` - contains all code releases for given ``, - list of supported platforms is in [Hardware Compatibility List](../variants/hardware-compatibility-list.md) section + list of supported platforms is in + [Hardware Compatibility List](../variants/hardware-compatibility-list.md) + section * `/rel_vX.Y.Z` - release branch for version X.Y.Z * `/develop` - contains most recent development and is periodically synced with `master` branch diff --git a/docs/ecosystem/overview.md b/docs/ecosystem/overview.md index ebbae2fc..a3a22ca8 100644 --- a/docs/ecosystem/overview.md +++ b/docs/ecosystem/overview.md @@ -1,5 +1,6 @@ -Ecosystem Overview ------------------- +# Ecosystem Overview + +--- Dasharo ecosystem contain multiple components on various levels of organization. This section overview role of every component. @@ -18,11 +19,11 @@ organization. This section overview role of every component. development infrastructure, build environment, CI/CD and build publishing methods. We also cover how production interacts with Dasharo Transparent Validation System. -* Customer Infrastructure - Some customers may have the need of replicating part of - Dasharo Production process and infrastructure in their own environment, which - leads to repositories synchronization, different CI/CD setup and other needs. - This section describes interaction with Customer Infrastructure and which part - of Dasharo Production is deployable on the customer site. +* Customer Infrastructure - Some customers may have the need of replicating part + of Dasharo Production process and infrastructure in their own environment, + which leads to repositories synchronization, different CI/CD setup and other + needs. This section describes interaction with Customer Infrastructure and + which part of Dasharo Production is deployable on the customer site. * Transparent Validation - Dasharo Transparent Validation (DTV) is a set of software, firmware and hardware components with the goal of simplifying and improving long term maintenance of Dasharo firmware. In this section we diff --git a/docs/ecosystem/roadmap.md b/docs/ecosystem/roadmap.md index ab217cdb..0ee58e7b 100644 --- a/docs/ecosystem/roadmap.md +++ b/docs/ecosystem/roadmap.md @@ -3,14 +3,15 @@ Each features on below roadmap should be placed in public issue tracker, so it can be publicly referenced. Some places where issues can be discussed: -* [Dasharo Github issues repo](https://github.com/Dasharo/dasharo-issues/issues) - especially issues -tagged `enhancement`. +* [Dasharo Github issues repo](https://github.com/Dasharo/dasharo-issues/issues) + - especially issues tagged `enhancement`. * coreboot issues tracker * edk2 bugzilla ## Backlog -* [TrenchBoot Roadmap](https://github.com/TrenchBoot/documentation/blob/master/roadmap/Roadmap.pdf) firmware related issues. +* [TrenchBoot Roadmap](https://github.com/TrenchBoot/documentation/blob/master/roadmap/Roadmap.pdf) + firmware related issues. * Dasharo Reference OS on USB stick to simplify firmware deployment * fwupd/LVFS for firmware deployment * ipxe for firmware deployment diff --git a/docs/images/gpu_activity_win10.png b/docs/images/gpu_activity_win10.png new file mode 100755 index 00000000..b566ea97 Binary files /dev/null and b/docs/images/gpu_activity_win10.png differ diff --git a/docs/images/ns50mu_board_chips.jpg b/docs/images/ns50mu_board_chips.jpg new file mode 100644 index 00000000..f2524037 Binary files /dev/null and b/docs/images/ns50mu_board_chips.jpg differ diff --git a/docs/images/nvidia_win10.png b/docs/images/nvidia_win10.png new file mode 100755 index 00000000..c6a6fc00 Binary files /dev/null and b/docs/images/nvidia_win10.png differ diff --git a/docs/index.md b/docs/index.md index f4d4e064..970e1499 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,6 +1,6 @@ - +# -## About +# About Dasharo is open-source firmware distribution focusing on clean and simple code, long-term maintenance, transparent validation, privacy-respecting diff --git a/docs/osf-trivia-list/deployment.md b/docs/osf-trivia-list/deployment.md index 75f3b538..1f212180 100644 --- a/docs/osf-trivia-list/deployment.md +++ b/docs/osf-trivia-list/deployment.md @@ -8,7 +8,11 @@ If you can't find the answer to your questions feel free to contact us through [Community Channels](../index.md#community) or submit issue through [Dasharo Github](https://github.com/Dasharo/dasharo-issues). -## What to do when flashrom returns `Could not get I/O privileges (Operation not permitted)`? +## Flashrom + +Following sections explain how to deal with most common `flashrom` errors. + +### `Could not get I/O privileges (Operation not permitted)` If you see a flashrom error like this: @@ -21,7 +25,7 @@ Error: Programmer initialization failed. It means you have insufficient privileges to perform initialization. Please use `sudo` before `flashrom` command. -## What to do when flashrom returns `/dev/mem mmap failed: Operation not permitted`? +### `/dev/mem mmap failed: Operation not permitted` ``` console /dev/mem mmap failed: Operation not permitted @@ -82,7 +86,7 @@ If the above does not resolve the problem, the kernel may be compiled with stric devmem, which prohibits accessing the IOMEM. You should then take different Linux system. -## What to do when flashrom returns `Transaction error between offset ...`? +### `Transaction error between offset ...`? ``` console SPI Configuration is locked down. diff --git a/docs/osf-trolling-list/build_process.md b/docs/osf-trolling-list/build_process.md index 28f8814f..a3f0f45e 100644 --- a/docs/osf-trolling-list/build_process.md +++ b/docs/osf-trolling-list/build_process.md @@ -13,8 +13,8 @@ This is because knowing hashes of firmware components, we can calculate expected TPM PCRs values. By knowing good PCR values and being able to predict further values after firmware update, we are gaining the following advantages: -* We can easily confirm if the firmware is valid by reading TPM PCRs and compare to - reference integrity measures (RIM), RIM can be calculated by build exactly +* We can easily confirm if the firmware is valid by reading TPM PCRs and compare + to reference integrity measures (RIM), RIM can be calculated by build exactly the same version of OSF. **NOTE**: Please note that depending on your threat model using TPM chip with @@ -87,8 +87,8 @@ Some more detailed notes related to `coreboot-sdk` issues are presented below. 3. `coreboot-sdk` is based on moving target Debian sid. It is close to impossible to build the same Docker images at 2 different points in time. 4. coreboot-sdk enforce given version of ACPI spec - this may not always be - a good thing to use the most recent compiler and update code accordingly since it - can easily break OSes. + a good thing to use the most recent compiler and update code accordingly + since it can easily break OSes. #### Why we care? @@ -123,7 +123,8 @@ Open-source firmware development and build environment SHOULD have: of Yocto or Buildroot. Another path could be Nix or Guix, which is currently pursued in the community [OSFW #guix-buildstack channel](http://osfw.slack.com/) - this is a private channel; feel free to ping anyone from 3mdeb Team to join. -2. coreboot toolchain is built by its own build system, which would be hard to couple with Dockerfile or something else. +2. coreboot toolchain is built by its own build system, which would be hard to + couple with Dockerfile or something else. 3. Docker images can be signed using `docker trust` commands as described [here](https://docs.docker.com/engine/security/trust/#signing-images-with-docker-content-trust). 4. Other idea would be to use `wget` and `dpkg -i` for every needed package in diff --git a/docs/osf-trolling-list/trusted_computing.md b/docs/osf-trolling-list/trusted_computing.md index 214934dc..2aba5850 100644 --- a/docs/osf-trolling-list/trusted_computing.md +++ b/docs/osf-trolling-list/trusted_computing.md @@ -1,5 +1,6 @@ -`[OSFI002]` Trusted computing -------------------------- +# `[OSFI002]` Trusted computing + +--- # `[OSFI0020]` CRTM what it stand for? diff --git a/docs/projects/trenchboot-aem.md b/docs/projects/trenchboot-aem.md new file mode 100644 index 00000000..eed3a343 --- /dev/null +++ b/docs/projects/trenchboot-aem.md @@ -0,0 +1,299 @@ +--- +template: giscus.html +--- + +# Trenchboot as Anti Evil Maid + +## Abstract + +The firmware is the heart of the security of a given system and should always +be up-to-date to maintain the computer's security. However, being up to date +does not prevent the firmware vulnerabilities from appearing. The Static Root +of Trust (SRT) like Unified Extensible Firmware Interface (UEFI) Secure Boot +and measured boot provided by the firmware is not always sufficient to +establish a secure environment for an operating system. If the firmware is +compromised, it could inject malicious software into operating system +components and prevent the machine owner from detecting it. Silicon vendors +implement alternative technologies to establish a Dynamic Root of Trust (DRT) +to provide a secure environment for operating system launch and integrity +measurements. Either from SRT or DRT, these integrity measurements can be used +for operating system attestation. However, DRT technologies are designed to +provide the ability to establish a secure environment for integrity +measurements at any arbitrary point of time instead of relying on the firmware, +which requires machine reset to establish the aforementioned secure +environment. + +The usage of DRT technologies like Intel Trusted Execution Technology (TXT) or +AMD Secure Startup becomes more and more significant, for example, Dynamic Root +of Trust for Measurement (DRTM) requirements of + +[Microsoft Secured Core PCs][ms_sec_core]. DRTM hasn't found its place in +open-source projects yet, but that gradually changes. The demand on having +firmware independent Roots of Trust is increasing, and projects that satisfy +this demand are growing, for instance, [TrenchBoot][tb_org]. TrenchBoot is a +framework that allows individuals and projects to build security engines to +perform launch integrity actions for their systems. The framework builds upon +Boot Integrity Technologies (BITs) that establish one or more Roots of Trust +(RoT) from which a degree of confidence that integrity actions were not +subverted. The project has grown a lot thanks to the previous +[NLnet NGI0 PET grant][nlnet_open_drtm] and now it looks for further expansion +into extensive use of the DRT technologies in open-source and security-oriented +operating systems like [Qubes OS][qubes_os_org]. +[Qubes OS Anti Evil Maid (AEM)][it_aem] software heavily depends on the +availability of the DRTM technologies to prevent the +[Evil Maid attacks][em_attacks]. However, the project hasn't evolved much since +the beginning of 2018 and froze on the support of TPM 1.2 with Intel TXT in +legacy boot mode (BIOS). Because of that, the usage of this security software +is effectively limited to older Intel machines only. TPM 1.2 implemented SHA1 +hashing algorithm, which is nowadays considered weak in the era of +forever-increasing computer performance and quantum computing. The solution to +this problem comes with a newer TPM 2.0 with more agile cryptographic +algorithms and SHA256 implementation by default. Qubes OS AEM software suffers +from the following: + +1. Lack of TPM 2.0 support to handle more secure hashes and safer design of the + TPM firmware according to a newer specification. +2. Lack of UEFI mode support. All modern systems boot in UEFI mode only. Legacy + boot modes are being deprecated and dropped from the PC firmware. The AEM + usage is not possible on most if not all modern machines. +3. Qubes OS AEM has never supported AMD processors with AMD Secure Startup + technology. Implementing AMD support would make a significant impact and + broaden the usage of DRTM technologies. + +The initial AEM implementation relied on the [Trusted Boot][tboot_wiki], +Intel's reference implementation of Intel TXT. It never had any plans to +support AMD processors. TrenchBoot is filling this gap, supporting both Intel +and AMD hardware which makes it an ideal target to replace Trusted Boot in +Qubes OS AEM implementation. Furthermore, the project grant would be used to +implement the missing pieces in the Qubes OS AEM software to cover the AMD and +Intel support for both TPM 1.2 and TPM 2.0. + +## Compare your own project with existing or historical efforts + +3mdeb is a licensed provider for quality coreboot consulting services since +2016. We are well-known in the open-source community for maintaining the +firmware of the PC Engines APU series platform since 2016. Delivering +high-quality firmware releases each month and providing technical support on PC +Engines and OPNSense forums. 3mdeb embedded systems developers are experienced +engineers accustomed to operating systems development. Our developers have +contributed to the [fwupd support for Qubes OS][qubes_fwupd]. 3mdeb is also +regularly co-organizing mini-conference events with Qubes OS maintainer Marek +Marczykowski-Górecki, where various topics related to Qubes OS security are +discussed. Among them, the Anti Evil Maid was frequently presented by 3mdeb +engineers: + +- [Anti Evil Maid for Intel coreboot-based platform][aem_intel] +- [Anti Evil Maid for modern AMD UEFI-based platform][aem_amd] + +A similar approach was already tried by Assured Information Security (AIS) to +boot [Xen in UEFI mode with Intel TXT DRTM technology][ais_aem]. However, this +is only a tiny portion of the work covered by our proposal. Additionally, +Qubes OS does not launch using Xen.efi like in the AIS work but uses +[Multiboot2 protocol with GRUB2][qubes_mb2] instead, making this approach +unusable. Moreover, the Xen.efi approach is much more complex and assumes usage +of Trusted Boot, limiting the feature to Intel hardware only. + +## What are the significant technical challenges you expect to solve + +First of all, Qubes OS AEM software consists of software packages providing +Trusted Boot and the [Qubes OS TPM scripts][aem_scripts]. These software +packages would need to replace the Trusted Boot with TrenchBoot supported GRUB2 +and Xen. Secondly, the TPM scripts require adding support for TPM 2.0 +equivalent functionality. AEM requires access to non-volatile RAM inside TPM, +which is defined differently in the TPM 2.0 specification compared to TPM 1.2. + +Another challenge would be to make Xen possible to boot in UEFI boot mode +without Boot Services defined in UEFI specification. Boot Services are a set of +functions exposed in UEFI structures that are used to help with handling the +boot process. However, the main principle of DRTM technologies is to not depend +on any external code that is not a part of the operating system software to be +executed after DRTM. UEFI Boot Services are a part of the firmware of which +DRTM tries to be independent. The whole security concept of DRTM depends on +cutting the ties with firmware. Thus the work includes implementing the +capability in Xen not to use the UEFI Boot Services, which GRUB2 would +terminate before DRTM is executed. Xen also contains an option not to use the +UEFI Runtime Services. Runtime Services is a set of functions available +throughout the whole machine lifetime, which means some firmware +functionalities are available even when the operating system is launched. + +Removing the Boot Services from Xen brings certain drawbacks to the system +because the Boot Services hold essential information like memory map, TPM event +log, graphics framebuffer, etc. This information must be extracted by GRUB +before Boot Services are terminated and passed to the Xen. The proposed +solution is to pass this information via the Multiboot2 tags defined in the +specification for this particular Boot Services information. + +Another challenge would be to get the work merged in the upstream repositories. +It would ensure the long-term support and maintenance of the solution and +availability. Providing software packages to be used out of the box is crucial +for technology availability. + +## Requested support + +1. Phase 1: TrenchBoot Intel TXT and TPM 1.2 support + + + Add TPM 1.2 support for Intel TXT in TrenchBoot GRUB2 + + The TrenchBoot support hasn't been implemented and verified with TPM + 1.2 on Intel TXT path. This requirement ensures that the TPM 1.2 is also + supported for older Intel hardware with Intel TXT. + + + Xen Secure Launch - Intel TXT support in Xen for TrenchBoot + + Due to the requirements of Intel TXT and how it is utilized, it is + impossible to use the Xen boot protocols defined in the UEFI or + Multiboot2 specifications. This task aims to create a custom Intel TXT + entry point for Xen, which would hand off to the standard Multiboot2 + entry point and enable the direct launch of Xen by GRUB via DRTM on + Intel hardware. Additionally, there is no support for launching Xen + with Intel TXT other than Trusted Boot. It has to be ported from + Trusted Boot specific code: + + * constructing MLE header + * waking up APs + * restoring MTRRs + * reserving the TXT memory + * reenabling SMIs + * handling TXT shutdown and S3 resume/suspend + * TPM event log finding + + + Test the solution on Intel hardware with TPM 1.2 with legacy boot mode + +2. Phase 2 - Qubes OS AEM TPM 2.0 support: + + + Extend the AEM scripts to detect TPM version on the platform + + As TPM 1.2 and TPM 2.0 use different software stacks and tools, it is + necessary to distinguish the TPM module family and use the appropriate + software. The task will implement the logic to distinguish the TPM + families. + + + Extend the AEM scripts to use the appropriate software stack for TPM 2.0 + + While AEM fully supports TPM 1.2, there is no support for TPM 2.0 at + all. When the TPM family is determined, the script should use the + appropriate software stack for the given TPM. The task implements the + AEM TPM 1.2 equivalent functionalities using TPM 2.0 software stack and + as a result allowing the use of TPM 2.0 with Qubes OS AEM. It will + require implementing the access to TPM 2.0 NVRAM, sealing and unsealing + the secret data, and generating TOTP. + + + Test the solution on Intel hardware with TPM 2.0 with legacy boot mode + +3. Phase 3 - Qubes OS AEM AMD support: + + + Rebase and refresh TrenchBoot GRUB2 for QubesOS + + Some work to implement TrenchBoot support for Qubes OS on AMD hardware + has been done. GRUB2 with TrenchBoot support has been added to Qubes + building system on [3mdeb fork](https://github.com/3mdeb/qubes-grub2/tree/trenchboot_support) + The task aims to refresh the work and align with the upstream + [Qubes OS GRUB2 repository](https://github.com/QubesOS/qubes-grub2) + + + Clean up the Secure Kernel Loader (formerly LandingZone) package support + for QubesOS + + Since the initial work done by 3mdeb engineers for AMD AEM in Qubes OS, + a lot of time has passed, and Secure Kernel Loader - SKL (formerly + Landing Zone) has improved a lot and added new features. SKL is an + open-source module written by TrenchBoot developers required by AMD + Secure Startup technology to perform DRTM launch. The task aims to + refresh the previous work and update the SKL package for Qubes OS to + the newest revision. + + + TrenchBoot Secure Kernel Loader (SKL) improvements for AMD server CPUs with + multiple nodes + + While SKL was extensively tested on System on Chip and single CPU + platforms, it was not tested on workstation/server segment CPUs which + are more complex. For example, one server CPU package may contain two + independent CPUs inside called nodes. Each node will enable protection + on the SKL during DRTM execution, and this protection must be disabled + on each node when TrenchBoot DRTM tasks are done. The task implements + the correct support for server CPUs in TrenchBoot SKL. + + + Test the solution on AMD hardware with TPM 2.0 and TPM 1.2 with legacy boot + mode + +4. Phase 4 - Xen UEFI boot mode with DRTM: + + + TrenchBoot support for UEFI boot mode for AMD in GRUB + + While TrenchBoot DRTM was extensively tested on Intel hardware with + UEFI firmware and Linux, it was not on AMD platforms. This task ensures + that DRTM works with UEFI boot mode on AMD processors in GRUB2 and + Linux without UEFI Boot Services. + + + TrenchBoot support for UEFI boot mode in Xen + + When UEFI boot mode with TrenchBoot is working with GRUB2 and Linux, + all that is missing to fully support AMD and Intel hardware with Qubes + OS AEM is the Xen support to boot in UEFI mode without Boot Services. + This requires a significant amount of work to ensure that all + information that Xen would obtain from UEFI Boot Services would still + be available. The information has to be passed by GRUB2 to Xen via + Multiboot2 protocol: + + * EFI memory map + * Framebuffer information + * PCI devices information with their option ROMs + + Additionally "EFI boot services not terminated" Multiboot2 tag must not + be passed to Xen by GRUB2 on DRTM launch when GRUB2 will terminate Boot + Services. Xen should detect such situations and act according to the + state of Boot Services. Xen will be implemented to: + + * parse the EFI memory map, framebuffer information, and PCI devices + information passed by GRUB2 + * do not expose the "EFI boot services" Multiboot2 tag indicating that + Xen can be executed without UEFI Boot Services presence + * allocate the memory space for the trampoline used to launch other + processors or use the allocation done by GRUB2 if necessary + * do not go error path when Boot Services are not present and skip all + calls to UEFI Boot Services by using the information provided by + GRUB2 + + + Test the solution on AMD and Intel hardware with TPM 2.0 and TPM 1.2 with + legacy and UEFI boot mode + +## Projects or organizations relevant to this project before? + +1. [Qubes OS](https://www.qubes-os.org/) +2. [Xen Hypervisor](https://xenproject.org/) +3. [GNU GRUB](https://www.gnu.org/software/grub/) +4. [TrenchBoot](https://trenchboot.org/) +5. [Invisible Things Lab](https://invisiblethingslab.com/) +6. [Apertus Solutions](https://apertussolutions.com/) +7. [Oracle](https://www.oracle.com/) +8. [3mdeb](https://3mdeb.com/) + +## The ecosystem of the project + +3mdeb has a good relationship with the maintainers of relevant projects which +will participate in the review of the work: + +- Marek Marczykowski-Górecki (Invisible Things Lab CTO) - Qubes OS maintainer +- Andrew Cooper (Citrix) - Xen Hypervisor Maintainer +- Daniel Kiper (Oracle) - GRUB2 Maintainer +- Daniel Smith (Apertus Solutions) - TrenchBoot founder and maintainer + +## Review + +Further reviews and suggestions are welcome. You can do it in two ways: + +- using Giscus on the bottom of this page +- contributing to this repository directly via Pull Request + +[ms_sec_core]: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure#what-makes-a-secured-core-pc +[tb_org]: https://trenchboot.org/ +[nlnet_open_drtm]: https://nlnet.nl/project/OpenDRTM/ +[qubes_os_org]: https://www.qubes-os.org/ +[it_aem]: https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html +[em_attacks]: http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html +[tboot_wiki]: https://sourceforge.net/p/tboot/wiki/Home/ +[qubes_fwupd]: https://blog.3mdeb.com/2020/2020-07-14-qubesos-fwupd-core/ +[aem_intel]: https://www.youtube.com/watch?v=YE2FbFlszI4 +[aem_amd]: https://www.youtube.com/watch?v=rM0vRi6qABE +[ais_aem]: https://www.youtube.com/watch?v=6NScGNSg3ks +[qubes_mb2]: https://github.com/QubesOS/qubes-issues/issues/4902 +[aem_scripts]: https://github.com/QubesOS/qubes-antievilmaid/blob/master/sbin/ diff --git a/docs/transparent-validation/muxpi/basic-validation.md b/docs/transparent-validation/muxpi/basic-validation.md index 683f29ed..55dc111d 100644 --- a/docs/transparent-validation/muxpi/basic-validation.md +++ b/docs/transparent-validation/muxpi/basic-validation.md @@ -1,7 +1,8 @@ # muxPi board validation > In case of any troubles, first it is recommended to read -[comprehend Theory of Operations](theory-of-operations.md) for muxPi devices. + [comprehend Theory of Operations](theory-of-operations.md) for muxPi + devices. ## Necessary components preparation @@ -19,9 +20,9 @@ 1. Prepare microSD card (minimum 8GB) for NanoPi NEO operating system. 1. Download and extract image - -[link](https://cloud.3mdeb.com/index.php/s/n42rLcAQ5cWcxgW/download) -1. Flash image into microSD card ([Etcher](https://www.balena.io/etcher/) tool -could be helpful) + [link](https://cloud.3mdeb.com/index.php/s/n42rLcAQ5cWcxgW/download) +1. Flash image into microSD card ([Etcher](https://www.balena.io/etcher/) + tool could be helpful) ## muxPi setup @@ -32,29 +33,35 @@ could be helpful) 1. Plug microUSB<->USB cable to muxPi and your machine. 1. Plug in power supply. 1. Make sure that jumpers are correctly set according to image: -![](../../images/muxpi1.4_jumpers.png) -1. Connect to NanoPi using terminal + ![](../../images/muxpi1.4_jumpers.png) - sudo minicom -D /dev/ttyUSB0 -o -b 115200` +1. Connect to NanoPi using terminal: + + ```bash + sudo minicom -D /dev/ttyUSB0 -o -b 115200` + ``` 1. Save ip address: - ifconfig + ```bash + ifconfig + ``` 1. Connect to NanoPi via ssh (with password: `fa`): -```bash -ssh root@192.168.4.XXX -``` + ```bash + ssh root@192.168.4.XXX + ``` -1. Or via serial connection -> NOTE: Connecting with MuxPi through serial will automatically login as non -root user `pi` with password `pi`. +1. Or via serial connection. + + > NOTE: Connecting with MuxPi through serial will automatically login as + non root user `pi` with password `pi`. ## Validation steps -#### 1. Install WiringNP +### 1. Install WiringNP ```bash git clone https://github.com/friendlyarm/WiringNP @@ -140,18 +147,19 @@ progress). To flash muxPi's microcontroller, follow steps below: From now on, muxPi's LCD should light on and display: ```bash -* MuxPi * -HW: 1.0 SW: 0.5 + * MuxPi * + HW: 1.0 SW: 0.5 ``` #### 3. SD Adapter 1. Connect IDC-uSD adapter to the muxPI board: -![](../../images/muxPi-sd.png) -2. Insert the microSD card to microSD card slot accessible on the bottom side of + ![](../../images/muxPi-sd.png) + +1. Insert the microSD card to microSD card slot accessible on the bottom side of muxPi board. -3. To enable microSD card reader, connect to Cortex from MuxPi via minicom: +1. To enable microSD card reader, connect to Cortex from MuxPi via minicom: ```bash minicom -D /dev/ttyS2 @@ -169,22 +177,20 @@ HW: 1.0 SW: 0.5 dut ``` - > NOTE: Each command should return `OK` + > NOTE: Each command should return `OK` -4. Connect IDC-uSD adapter to a SD card adapter plugged into your machine - > NOTE: You need to force IDC-uSD adapter to insert into SD card adapter +1. Connect IDC-uSD adapter to a SD card adapter plugged into your machine -5. (On your machine) Check if device is connected: `dmesg -w` + > NOTE: You need to force IDC-uSD adapter to insert into SD card adapter + +1. (On your machine) Check if device is connected: `dmesg -w` should help. You should also be able to read and write data to uSD card from file manager. - -6. Flash image into microSD card (for RPI or other device -bootable form SD card.) - -7. Disconnect uSD adapter form a SD card adapter and connect +1. Flash image into microSD card (for RPI or other device +bootable form SD card). +1. Disconnect uSD adapter form a SD card adapter and connect to the device (e.g. RPI). - -8. Connect device to the power supply, now device should boot +1. Connect device to the power supply, now device should boot via IDC-uSD adapter. #### 4. Screening @@ -237,7 +243,8 @@ Minicom quick guide: 1. Connect via minicom: `sudo minicom -D /dev/ttyS2 -o -b 115200` 1. Type: `help` -> NOTE: If output is the same as above then basic validation for muxPi is done. + > NOTE: If output is the same as above then basic validation for muxPi is + done. --- diff --git a/docs/transparent-validation/muxpi/theory-of-operations.md b/docs/transparent-validation/muxpi/theory-of-operations.md index fb1b58c0..df1e612f 100644 --- a/docs/transparent-validation/muxpi/theory-of-operations.md +++ b/docs/transparent-validation/muxpi/theory-of-operations.md @@ -6,7 +6,7 @@ ## muxPi setup -#### NanoPi NEO +### NanoPi NEO Preparation of the muxPi's "heart": @@ -23,51 +23,50 @@ There are two methods to setup serial communication with muxPi: * with microUSB<->USB cable -![](../../images/muxPi-board-bottom.png) + ![](../../images/muxPi-board-bottom.png) * with UART/USB converter -Attach USB/UART converter to muxPi's left addon female header (`GND`, `DBG UART -RX`, `DBG UART TX` on pinout image below): + Attach USB/UART converter to muxPi's left addon female header (`GND`, + `DBG UART RX`, `DBG UART TX` on pinout image below): -![](../../images/muxPi-addon-left.png) + ![](../../images/muxPi-addon-left.png) -and plug USB connector to the computer. Next, open connection in PC terminal by -typing: + and plug USB connector to the computer. Next, open connection in PC + terminal by typing: -```bash -sudo minicom -D /dev/ttyUSB0 -o -b 115200. -``` + ```bash + sudo minicom -D /dev/ttyUSB0 -o -b 115200. + ``` -> `/dev/ttyUSB0` is example device - check whether `USB0` is the correct one + > `/dev/ttyUSB0` is example device - check whether `USB0` is the correct one #### Jumpers configuration ![](../../images/muxpi1.4_jumpers.png) -* UART - pins `Vloc` & `VCC` - if jumped then internal voltage generator is used - as voltage reference for data lines and powers up target device. If open then - voltage reference for data lines comes from target device and internal voltage - generator is unused. +* UART - pins `Vloc` & `VCC` - if jumped then internal voltage generator is + used as voltage reference for data lines and powers up target device. If + open then voltage reference for data lines comes from target device and + internal voltage generator is unused. * USB/ETH - determines what USB data lines of one USB HUB are connected to. If - first two pins are jumped then USB lines are connected to add-on connector. If - last two pins are jumped then these lines are connected tu USB<->ETH converter. - If none of the pins are jumped then the only connection is the upper socket of - double connector. + first two pins are jumped then USB lines are connected to add-on connector. + If last two pins are jumped then these lines are connected tu USB<->ETH + converter. If none of the pins are jumped then the only connection is the + upper socket of double connector. -> NOTE: The upper socket of double USB-A connector must be left empty if -USB<->ETH is selected or add-on connector is selected and something is connected -to these data lines on the addon! - -> NOTE: Both jumpers must be placed in the same position! + > NOTE: The upper socket of double USB-A connector must be left empty if + USB<->ETH is selected or add-on connector is selected and something is + connected to these data lines on the addon! + > NOTE: Both jumpers must be placed in the same position! * VDD - if this pins are jumped then the VDD and 3V3 are always on. If this is - left open then VDD and 3V3 are controlled by NanoPi. The usage example is - setting value of USB ID potentiometer (which is located underneath NanoPi). - But when NanoPi NEO is removed there is no way to turn on power for - microcontroller (that is when VDD jumper is helpful). + left open then VDD and 3V3 are controlled by NanoPi. The usage example is + setting value of USB ID potentiometer (which is located underneath NanoPi). + But when NanoPi NEO is removed there is no way to turn on power for + microcontroller (that is when VDD jumper is helpful). -> NOTE: If there is no particular need then leave this jumper open. + > NOTE: If there is no particular need then leave this jumper open. #### Power supply @@ -82,7 +81,7 @@ then 1A assuming no addons connected. To check which IP address has been assigned, type in terminal: `ifconfig`. OPTIONAL STEP: -To set static IP, create following file: +To set static IP, create the following file: ```bash sudo vi /etc/NetworkManager/NetworkManager.conf @@ -228,7 +227,7 @@ HW: 1.0 SW: 0.5 > NOTE: It is recommended to cross-compile muxPi's software on your host machine -#### Building using docker +### Building using docker Prerequisites: `Docker`, `Make`. @@ -247,11 +246,11 @@ Prerequisites: `git`, `go (1.10+)` 1. Download dependencies: `go get ./...` 1. Build binaries: -```bash -mkdir -p bin -GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/stm ./cmd/stm/ -GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/fota ./cmd/fota/ -``` + ```bash + mkdir -p bin + GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/stm ./cmd/stm/ + GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/fota ./cmd/fota/ + ``` #### Install muxpi-power @@ -264,12 +263,12 @@ GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/fota ./cmd/fota/ scp power/systemd/muxpi-power.service root@192.168.4.XXX:/etc/systemd/system ``` -2. On your MuxPi device, enable and start muxpi-power service: +1. On your MuxPi device, enable and start muxpi-power service: -```bash -systemctl enable muxpi-power.service -systemctl start muxpi-power.service -``` + ```bash + systemctl enable muxpi-power.service + systemctl start muxpi-power.service + ``` #### Install stm @@ -285,14 +284,14 @@ systemctl start muxpi-power.service scp stm/stm root@192.168.4.XXX:/usr/local/bin/stm ``` -2. On your MuxPi device - create group stm and add your user: +1. On your MuxPi device - create group stm and add your user: ```bash groupadd stm usermod -aG stm root ``` -3. On your MuxPi device - enable stm sockets: +1. On your MuxPi device - enable stm sockets: ```bash systemctl daemon-reload @@ -310,7 +309,7 @@ systemctl start muxpi-power.service scp bin/fota_armv7 root@192.168.4.XXX:/usr/bin/fota ``` -2. On your MuxPi device - create a symlink from `/usr/local/bin/fota` to +1. On your MuxPi device - create a symlink from `/usr/local/bin/fota` to `/usr/bin/fota/`. Only `/usr/local/bin/fota/` should be used by software interfacing with MuxPi. This allows to swap fota implementation to your preferred tool: @@ -321,7 +320,7 @@ preferred tool: ## DUT setup -#### DUT power supply +### DUT power supply MuxPi is capable of: @@ -373,17 +372,16 @@ Example configuration for OrangePi (DUT) uart connection: 1. Connect GND, RX and TX (without crossing). 1. Open connection: `screen /dev/ttyS1 115200,cs8,ixon,ixoff` - > NOTE: `RX`, `TX`, `XTS`, `RTS` are crossed on the board so you don't need +> NOTE: `RX`, `TX`, `XTS`, `RTS` are crossed on the board so you don't need to cross the wires by yourself. - - > NOTE: A device powered from `Vloc` mustn't draw more than 50mA of current. +> NOTE: A device powered from `Vloc` mustn't draw more than 50mA of current. #### Add-ons Add-ons headers are extensions for attaching new shields or simply using NanoPi and CortexM0 interfaces: - ![](../../images/muxPi-addon-left.png) +![](../../images/muxPi-addon-left.png) * `5V` - power supply - not switchable - always present * `3V3` - switchable (controlled by NanoPi) 3.3V power supply @@ -411,10 +409,10 @@ and CortexM0 interfaces: dealing with them. * `GND` - ground lines -NOTE: PI GPIO 1 has additional special function. It is connected to Cortex-M0 -Boot0 pin which enables firmware download mode during microcontroller boot. 1 - -enables this mode while 0 disables it. So it is useless as GPIO when the -microcontroller is being booted. +>NOTE: PI GPIO 1 has additional special function. It is connected to Cortex-M0 + Boot0 pin which enables firmware download mode during microcontroller boot. + 1 - enables this mode while 0 disables it. So it is useless as GPIO when + the microcontroller is being booted. #### DyPers @@ -470,7 +468,7 @@ and enter in minicom following commands: ts ``` -and then +and then: ```bash dut @@ -485,7 +483,7 @@ card contains appropriate OS. ## Interacting with muxPi -#### Connection with NanoPi +### Connection with NanoPi User can simply open SSH connection by (password: `fa`): @@ -494,7 +492,7 @@ User can simply open SSH connection by (password: `fa`): * or use serial connection mentioned [here](#serial-communication) > NOTE: Connecting with MuxPi through serial will automatically login as non -root user `pi` with password `pi`. + root user `pi` with password `pi`. #### User interface diff --git a/docs/transparent-validation/rte/introduction.md b/docs/transparent-validation/rte/introduction.md index 15f29331..d6bc4b06 100644 --- a/docs/transparent-validation/rte/introduction.md +++ b/docs/transparent-validation/rte/introduction.md @@ -44,12 +44,12 @@ Full Remote Testing Environment set includes: > _test your device from any location._ * efficiency -> *simplify validation: write one script and run it on unlimited platforms. - Don’t repeat yourself!* +> _simplify validation: write one script and run it on unlimited platforms. + Don’t repeat yourself!_ * independent development -> *open hardware license: modify, upgrade and set it as you like. All blueprints - are at your disposal.* +> _open hardware license: modify, upgrade and set it as you like. All blueprints + are at your disposal._ * instant setup > _intuitive connection: you do not need to be a certified engineer._ diff --git a/docs/transparent-validation/rte/v1.1.0/specification.md b/docs/transparent-validation/rte/v1.1.0/specification.md index 19eb56b3..1b43fea1 100644 --- a/docs/transparent-validation/rte/v1.1.0/specification.md +++ b/docs/transparent-validation/rte/v1.1.0/specification.md @@ -2,9 +2,10 @@ ![](../../../images/rte-v1.1.0-interface-desc.png) -* **UART0 header** - 1x3 Orange Pi Zero system debug output and console (pins: `RX`, `TX`, `GND`). -* **SPI header** - 2x4 standard 2.5mm IDC compatible header with all necessary signals to flash SPI - chips. +* **UART0 header** - 1x3 Orange Pi Zero system debug output and console + (pins: `RX`, `TX`, `GND`). +* **SPI header** - 2x4 standard 2.5mm IDC compatible header with all necessary + signals to flash SPI chips. * **Orange Pi Zero GPIO** - 1x3 GPIO pin header directly connected to Orange Pi zero platform. * **I2C header** - 1x4 populated pins: `3.3V`, `SCK`, `SDA`, `GND`. diff --git a/docs/transparent-validation/sd-wire/getting-started.md b/docs/transparent-validation/sd-wire/getting-started.md index ceb35b21..f861d8de 100644 --- a/docs/transparent-validation/sd-wire/getting-started.md +++ b/docs/transparent-validation/sd-wire/getting-started.md @@ -1,4 +1,4 @@ -SDWire is a small board with two features: +# SDWire is a small board with two features * SD card reader * SD card MUX diff --git a/docs/transparent-validation/sd-wire/specification.md b/docs/transparent-validation/sd-wire/specification.md index 32729bbb..06e3fd3e 100644 --- a/docs/transparent-validation/sd-wire/specification.md +++ b/docs/transparent-validation/sd-wire/specification.md @@ -1,4 +1,4 @@ -## Hardware design +# Hardware design Design of this board is based on [SD MUX](https://wiki.tizen.org/SD_MUX). SDWire does not have power switch or USB switch but has built in USB SD card reader. SD @@ -6,7 +6,7 @@ card multiplexer itself is exactly the same in both devices. There are four LEDs on the board: -``` +```bash red - power presence from USB blue - USB reader activity blue - card connected to TS (Test Server) diff --git a/docs/transparent-validation/sd-wire/usage-validation.md b/docs/transparent-validation/sd-wire/usage-validation.md index 86e5dc53..42e16f14 100644 --- a/docs/transparent-validation/sd-wire/usage-validation.md +++ b/docs/transparent-validation/sd-wire/usage-validation.md @@ -11,7 +11,7 @@ To prepare the environment reproduce the following steps: 1. Clone the repository: - ``` + ```bash git clone https://git.tizen.org/cgit/tools/testlab/sd-mux ``` @@ -19,7 +19,7 @@ To prepare the environment reproduce the following steps: * libftdi1 1.4 development library is installed. To do this, open the terminal and type the following command: - ``` + ```bash dpkg -L libftdi1-dev ``` @@ -28,7 +28,7 @@ To prepare the environment reproduce the following steps: * popt development library is installed. To do this, open the terminal and type the following command: - ``` + ```bash dpkg -L libpopt-dev ``` @@ -37,7 +37,7 @@ To prepare the environment reproduce the following steps: * cmake binary tool is installed. To do this, open the terminal and type the following command: - ``` + ```bash cmake --version ``` @@ -51,21 +51,21 @@ To prepare the environment reproduce the following steps: * libftdi1 1.4 development library. To do this, open the terminal and type the following command: - ``` + ```bash sudo apt-get install libftdi1-dev ``` * popt development library. To do this, open the terminal and type the following command: - ``` + ```bash sudo apt-get install libpopt-dev ``` * cmake binary tool. To do this, open the terminal and type the following command: - ``` + ```bash sudo apt-get install cmake ``` @@ -74,19 +74,19 @@ To prepare the environment reproduce the following steps: * open directory in terminal * create 'build' directory by the following command: - ``` + ```bash mkdir build ``` * enter into 'build' directory by the following command: - ``` + ```bash cd build ``` * run the following commands one by one: - ``` + ```bash cmake .. make ``` @@ -94,7 +94,7 @@ To prepare the environment reproduce the following steps: 5. In the above-described directory (`sd-mux/build`) run the following command to build binary: - ``` + ```bash sudo make install ``` @@ -102,13 +102,13 @@ To prepare the environment reproduce the following steps: If you want to install files in directory rather than the default one add an argument to cmake command: - ``` + ```bash cmake -DCMAKE_INSTALL_PREFIX=/usr .. ``` Then it is obligatory to run again the following commands: - ``` + ```bash make make install ``` @@ -140,14 +140,14 @@ reproduce the following steps: 5. Check whether SDWire is configured by reproducing the following steps: * run in TS terminal the following command: - ``` + ```bash dmesg -w ``` * connect the SDWire to your machine using micro-USB --> USB cable. * after connecting your `dmesg` output should looks like this: - ``` + ```bash (...) [73278.307591] usb-storage 3-1.1:1.0: USB Mass Storage device detected [73278.307823] scsi host6: usb-storage 3-1.1:1.0 @@ -162,33 +162,33 @@ reproduce the following steps: * open new terminal window and run the following command: - ``` + ```bash sudo sd-mux-ctrl --list ``` If output looks like below, it means that SDWire is configured and ready to use. Now, you can go to point 6 in this section. - ``` + ```bash Number of FTDI devices found: 1 Dev: 0, Manufacturer: SRPOL, Serial: sd-wire_11, Description: sd-wire ``` Otherwise, if output shows no devices (like in the example below): - ``` + ```bash Number of FTDI devices found: 0 ``` you have to configure SDWire: - ``` + ```bash sudo sd-mux-ctrl --device-serial=DB007V7V --vendor=0x0403 --product=0x6015 --device-type=sd-wire --set-serial=sd-wire_11 ``` where: - ``` + ```bash --device-serial= (from dmesg output) --vendor=0x (from dmesg output) @@ -201,20 +201,20 @@ reproduce the following steps: After above-desribed procedure check again if SDWire is properly configured: - ``` + ```bash sudo sd-mux-ctrl --list ``` Should output: - ``` + ```bash Number of FTDI devices found: 1 Dev: 0, Manufacturer: SRPOL, Serial: sd-wire_11, Description: sd-wire ``` 6. Connect SD card to the TS (Test Server): - ``` + ```bash sudo sd-mux-ctrl --device-serial=sd-wire_11 --ts ``` @@ -225,25 +225,25 @@ reproduce the following steps: * to do this by `bmaptool` reproduce the following steps: - install bmaptool by opening terminal and typing the following command: - ``` + ```bash sudo apt install bmap-tools ``` - create the bmap by typing the following command: - ``` + ```bash bmaptool create /path/to/your/image > /path/where/you/want/bmap/file/saved/bmapfilename.bmap ``` - flash image to the SD card by typing the following command: - ``` + ```bash sudo bmaptool copy --bmap ~/path/where/your/bmap/file/is/located /path/where/your/image/is/located /path/to/memory/device ``` 8. Connect SD card to the DUT using `sd-mux-ctrl`: - ``` + ```bash sudo sd-mux-ctrl --device-serial=sd-wire_11 --dut ``` @@ -272,13 +272,13 @@ Using SDWire there is no need to disconnect SD card from DUT. automated and remote power control of the connected device). 4. Check serial no. of SDWire: - ``` + ```bash sudo sd-mux-ctrl --list ``` Output: - ``` + ```bash Number of FTDI devices found: 1 Dev: 0, Manufacturer: SRPOL, Serial: sd-wire_11, Description: sd-wire ``` @@ -286,14 +286,15 @@ Using SDWire there is no need to disconnect SD card from DUT. 5. Disconnect power supply using RTE. 6. Connect SD card to the TS (using sd-mux-ctrl) - ``` + ```bash sudo sd-mux-ctrl --device-serial=sd-wire_11 --ts ``` -7. Flash the SD card using `bmaptool` or `balenaEtcher` as described in the [First use](#first-use) section +7. Flash the SD card using `bmaptool` or `balenaEtcher` as described in the + [First use](#first-use) section 8. Connect SD card to the DUT (using sd-mux-ctrl) - ``` + ```bash sudo sd-mux-ctrl --device-serial=sd-wire_11 --dut ``` @@ -303,7 +304,7 @@ Using SDWire there is no need to disconnect SD card from DUT. > Command `sudo sd-mux-ctrl --device-serial=sd-wire_11 --status` returns information if SDWire is connected to DUT or TS. - ``` + ```bash ➜ ~ sudo sd-mux-ctrl --device-serial=sd-wire_11 --status SD connected to: TS ``` diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md b/docs/unified-test-documentation/dasharo-compatibility/100-coreboot-base-port.md similarity index 54% rename from docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md rename to docs/unified-test-documentation/dasharo-compatibility/100-coreboot-base-port.md index 7c6d4222..97a8caa4 100644 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md +++ b/docs/unified-test-documentation/dasharo-compatibility/100-coreboot-base-port.md @@ -2,48 +2,49 @@ ## Test cases -### CBP001.001 Firmware building - -Refer to [building manual](../building-manual.md) - -### CBP002.001 Firmware flashing - external programmer - -Refer to [setup](../setup.md#spi) - -### CBP004.001 Boot into coreboot stage bootblock - -**Test description** - -This test verifies whether the DUT during booting procedure reaches -stage bootblock. The bootblock is the first stage executed after CPU reset, -its main task is to set up everything for a C-environment. - -**Test configuration data** - -1. `FIRMWARE` = coreboot +### Common **Test setup** 1. Proceed with the - [Generic test setup: firmware](generic-test-setup.md#firmware) -2. Connect to the UART debug interface and open a serial console. + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Connect to the UART debug interface and open a serial console. + +### CBP001.001 Boot into coreboot stage bootblock + +**Test description** + +This test aims to verify that DUT during booting procedure reaches +stage bootblock. The bootblock is the first stage executed after CPU reset, +its main task is to set up everything for a C-environment. + +**Test setup** + +1. Proceed with the [Common](#common) section. **Test steps** 1. Power ON the DUT. 2. By using the serial console read the booting procedure stage. +**Test steps** + +1. Power on the DUT. +2. Read the booting procedure stage. + **Expected result** 1. The console output should contain string with the phrase: - bootblock starting + ```bash + bootblock starting + ``` -### CBP004.002 Boot into coreboot stage romstage +### CBP002.001 Boot into coreboot stage romstage **Test description** -This test verifies whether the DUT during booting procedure reaches +This test aims to verify that DUT during booting procedure reaches stage romstage. The romstage initializes the DRAM and prepares everything for device init. @@ -53,9 +54,7 @@ for device init. **Test setup** -1. Proceed with the - [Generic test setup: firmware](generic-test-setup.md#firmware) -2. Connect to the UART debug interface and open a serial console. +1. Proceed with the [Common](#common) section. **Test steps** @@ -66,13 +65,15 @@ for device init. 1. The console output should contain string with the phrase: - romstage starting + ```bash + romstage starting + ``` -### CBP004.003 Boot into coreboot stage postcar +### CBP003.001 Boot into coreboot stage postcar **Test description** -This test verifies whether the DUT during booting procedure reaches +This test aims to verify that DUT during booting procedure reaches stage postcar. The postcar tears down CAR and loads the ramstage. **Test configuration data** @@ -81,9 +82,7 @@ stage postcar. The postcar tears down CAR and loads the ramstage. **Test setup** -1. Proceed with the - [Generic test setup: firmware](generic-test-setup.md#firmware) -2. Connect to the UART debug interface and open a serial console. +1. Proceed with the [Common](#common) section. **Test steps** @@ -94,13 +93,15 @@ stage postcar. The postcar tears down CAR and loads the ramstage. 1. The console output should contain string with the phrase: - postcar starting + ```bash + postcar starting + ``` -### CBP004.004 Boot into coreboot stage ramstage +### CBP004.001 Boot into coreboot stage ramstage **Test description** -This test verifies whether the DUT during booting procedure reaches +This test aims to verify that DUT during booting procedure reaches stage ramstage. The ramstage does the main device init. **Test configuration data** @@ -109,9 +110,7 @@ stage ramstage. The ramstage does the main device init. **Test setup** -1. Proceed with the - [Generic test setup: firmware](generic-test-setup.md#firmware) -2. Connect to the UART debug interface and open a serial console. +1. Proceed with the [Common](#common) section. **Test steps** @@ -122,14 +121,16 @@ stage ramstage. The ramstage does the main device init. 1. The console output should contain string the with phrase: - ramstage starting + ```bash + ramstage starting + ``` ### CBP005.001 Resource allocator v4 - gathering requirements **Test description** -This test aims to verify that DUT reaches the `gathering requirements` stage for -Resource Allocator v4 during booting procedure. +This test aims to verify that DUT reaches the `gathering requirements` +stage for Resource Allocator v4 during booting procedure. **Test configuration data** @@ -137,9 +138,7 @@ Resource Allocator v4 during booting procedure. **Test setup** -1. Proceed with the - [Generic test setup: firmware](generic-test-setup.md#firmware) -2. Connect to the UART debug interface and open a serial console. +1. Proceed with the [Common](#common) section. **Test steps** @@ -150,9 +149,11 @@ Resource Allocator v4 during booting procedure. 1. The console output should contain a string with the phrase: - Pass 1 (gathering requirements) + ```bash + Pass 1 (gathering requirements) + ``` -### CBP005.002 Resource allocator v4 - allocating resources +### CBP006.001 Resource allocator v4 - allocating resources **Test description** @@ -165,9 +166,7 @@ Resource Allocator v4 during booting procedure. **Test setup** -1. Proceed with the - [Generic test setup: firmware](generic-test-setup.md#firmware) -2. Connect to the UART debug interface and open a serial console. +1. Proceed with the [Common](#common) section. **Test steps** @@ -178,4 +177,6 @@ Resource Allocator v4 during booting procedure. 1. The console output should contain a string with the phrase: - Pass 2 (allocating resources) + ```bash + Pass 2 (allocating resources) + ``` diff --git a/docs/unified-test-documentation/dasharo-compatibility/301-memory-hcl.md b/docs/unified-test-documentation/dasharo-compatibility/301-memory-hcl.md new file mode 100644 index 00000000..669e3e92 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/301-memory-hcl.md @@ -0,0 +1,43 @@ +# Dasharo compatibility: Memory HCL + +## Test cases + +### HCL001.001 Memory HCL - boot into OS (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the DUT can boot with the memory +module combinations specified in the HCL. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Prepare the memory modules specified in the HCL. +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). + +**Test steps** + +1. Insert the memory module into the DUT's memory port, starting with the first + position from the HCL. +1. Power on the DUT. +1. Boot into the system. +1. Power off the DUT. +1. Repeat the `test steps` for all positions in the HCL. + +**Expected result** + +1. The expected result is that the OS boots successfully with all memory + combinations specified in the HCL +* If the `OPERATING_SYSTEM` boots, note the success and power the DUT OFF +* If the `OPERATING_SYSTEM` doesn't boot, check the logs (optional - if + connected over serial console) for the + `FSP Memory Init has returned an error` and note the failure diff --git a/docs/unified-test-documentation/dasharo-compatibility/303-custom-boot-menu-key.md b/docs/unified-test-documentation/dasharo-compatibility/303-custom-boot-menu-key.md new file mode 100644 index 00000000..3788803e --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/303-custom-boot-menu-key.md @@ -0,0 +1,32 @@ +# Dasharo compatibility: Custom boot menu key + +## Test cases + +### CBK001.001 Custom boot menu key + +**Test description** + +This test aims to verify that the DUT is configured to use custom boot menu and +setup menu (if it exists) hotkeys. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). + +**Test steps** + +1. Power on the DUT. +1. Hold the `BIOS_SETUP_KEY` to enter the UEFI Setup Menu. +1. Once the DUT has booted into the setup menu, power it off using the power + button. +1. Power on the DUT again. +1. Hold the `BOOT_MENU_KEY` to enter the UEFI Boot Menu. + +**Expected result** + +The DUT boots into an UEFI Setup menu and Boot menu using the specified hotkeys. diff --git a/docs/unified-test-documentation/dasharo-compatibility/304-custom-logo.md b/docs/unified-test-documentation/dasharo-compatibility/304-custom-logo.md new file mode 100644 index 00000000..0dac4a5b --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/304-custom-logo.md @@ -0,0 +1,29 @@ +# Dasharo compatibility: Custom Logo + +## Test cases + +### CLG001.001 Custom boot logo + +**Test description** + +This test aims to verify that the DUT is configured to display the specified +(customized) logo at boot. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). + +**Test steps** + +1. Power on the DUT. +1. Wait for the boot logo to appear. + +**Expected result** + +The logo that is displayed should be in accordance with [custom logo] +documentation. diff --git a/docs/unified-test-documentation/dasharo-compatibility/306-usb-hid-and-msc-support.md b/docs/unified-test-documentation/dasharo-compatibility/306-usb-hid-and-msc-support.md new file mode 100644 index 00000000..4737ea7e --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/306-usb-hid-and-msc-support.md @@ -0,0 +1,225 @@ +# Dasharo compatibility: USB HID and MSC Support + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). + +### USB001.001 USB devices detection (firmware) + +**Test description** + +This test aims to verify that the external USB devices are detected +correctly by the firmware and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Connect the flash drive using the USB port. + +**Test steps** + +1. Power on the DUT. +1. Enter the boot menu using the `BIOS_SETUP_KEY`. +1. Select the `Boot Menu`, press `Enter` and note the result. + +**Expected result** + +1. Flash drive entry is listed in the boot menu. + +### USB001.002 USB devices detection in OS (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the external USB devices are detected +correctly by the `OPERATING_SYSTEM` and all basic keys work according to their +labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and run the follwing command: + + ```bash + watch -n1 lsusb + ``` + +1. Connect external USB devices to DUT USB A port and note the result. + +**Expected result** + +1. After each device is connected to the USB port, a new USB device entry + in `lsusb` command output should appear. + +### USB001.003 USB devices detection in OS (Windows 11) + +**Test description** + +This test aims to verify that the external USB devices are detected correctly +by the `OPERATING_SYSTEM` and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open PowerShell and and run the follwing command: + + ```bash + while (1) {Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^USB' }; sleep 5; clear} + ``` + +1. Connect external USB devices to DUT USB A port and note the result. + +**Expected result** + +1. After each device is connected to the USB port, a new USB device entry in the + output of the command should appear. + +### USB002.001 USB keyboard detection (firmware) + +**Test description** + +This test aims to verify that the external USB keyboard is detected correctly +by the firmware and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Connect the external USB keyboard using the USB port. + +**Test steps** + +1. Power on the DUT +1. Enter the boot menu using the `BIOS_SETUP_KEY`. +1. Use the arrow keys, Esc key and the Enter key to navigate the menus. + +**Expected result** + +1. All menus can be entered using the external USB keyboard. + +### USB002.002 USB keyboard detection (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the external USB keyboard is detected correctly +by the `OPERATING_SYSTEM` and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install `libinput-tools` on the DUT. +1. Connect the external USB keyboard using the USB port. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and run the follwing command: + + ```bash + lsusb + ``` + +1. Run the follwing command in the terminal: + + ```bash + libinput debug-events --show-keycodes + ``` + +1. Test the alphanumeric keys and note the generated keycodes. +1. Test non-alphanumeric keys and verify that they generate the correct + keycodes. +1. Test key combinations with the `Shift`, `Ctrl` and `Alt` modifier keys + (this tests 2-key rollover). + +**Expected result** + +1. The extarnal USB keyboard is detected in OS. +1. All standard keyboard keys generate the correct keycodes and events as per + their labels. +1. Key combinations are detected correctly. + +### USB002.003 USB keyboard detection (Windows 11) + +**Test description** + +This test aims to verify that the external USB keyboard is detected correctly +by the `OPERATING_SYSTEM` and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Connect the external USB keyboard using the USB port. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open `notepad`. +1. Test the alphanumeric keys and note the generated characters. +1. Test non-alphanumeric keys and verify that they generate the signs. +1. Test key combinations with the `Shift`, and `Alt` modifier keys. +1. Open `On-Screen Keyboard` and press `Ctrl` key on the hardware keyboard. + Check if `On-Screen Keyboard` correctly highlights it. +1. Open `Start menu` and press `Esc`. Check if `Start menu` is properly closed. + +**Expected result** + +1. All standard keyboard keys generate correct characters + or actions when pressed. +1. Key combinations are detected correctly. diff --git a/docs/unified-test-documentation/dasharo-compatibility/307-freebsd-support.md b/docs/unified-test-documentation/dasharo-compatibility/307-freebsd-support.md new file mode 100644 index 00000000..ba5e226c --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/307-freebsd-support.md @@ -0,0 +1,37 @@ +# Dasharo Compatibility: FreeBSD support + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). + +### BSD001.001 FreeBSD installation and boot + +**Test description** + +This test verifies that FreeBSD distribution could be installed on +the DUT and works properly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = FreeBSD 13 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Wait for the `OPERATING_SYSTEM` to boot and note the result. + +**Expected result** + +The `OPERATING_SYSTEM` login screen should be displayed. diff --git a/docs/unified-test-documentation/dasharo-compatibility/308-debian-stable-and-ubuntu-lts-support.md b/docs/unified-test-documentation/dasharo-compatibility/308-debian-stable-and-ubuntu-lts-support.md new file mode 100644 index 00000000..eb39a95a --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/308-debian-stable-and-ubuntu-lts-support.md @@ -0,0 +1,62 @@ +# Dasharo Compatibility: Debian Stable and Ubuntu LTS support + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). + +### LBT001.001 Debian Stable installation and boot + +**Test description** + +This test verifies that Debian stable distribution could be installed on +the DUT and works properly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Debian 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Wait for the `OPERATING_SYSTEM` to boot and note the result. + +**Expected result** + +The `OPERATING_SYSTEM` login screen should be displayed. + +### LBT002.001 Ubuntu LTS installation and boot + +**Test description** + +This test verifies that Ubuntu LTS modern ditribution could be installed +on the DUT and works properly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Wait for the `OPERATING_SYSTEM` to boot and note the result. + +**Expected result** + +The `OPERATING_SYSTEM` login screen should be displayed. diff --git a/docs/unified-test-documentation/dasharo-compatibility/30A-custom-network-boot-entries.md b/docs/unified-test-documentation/dasharo-compatibility/30A-custom-network-boot-entries.md new file mode 100644 index 00000000..ce43b757 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/30A-custom-network-boot-entries.md @@ -0,0 +1,29 @@ +# Dasharo Compatibility: Custom Network Boot entries + +## Test cases + +### CNB001.002 Only one iPXE in boot menu + +**Test description** + +This test aims to verify that thenetwork boot option with iPXE appears only +once in the boot option list. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). + +**Test steps** + +1. Power on the DUT. +1. Hold the `BOOT_MENU_KEY` to enter the UEFI Boot Menu. +1. Check the iPXE is listed only once on the boot option list. + +**Expected result** + +1. There is only one iPXE entry on the boot option list. diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/memtest.md b/docs/unified-test-documentation/dasharo-compatibility/30L-memtest-payload-support.md similarity index 60% rename from docs/variants/asus_kgpe_d16/dasharo-compatibility/memtest.md rename to docs/unified-test-documentation/dasharo-compatibility/30L-memtest-payload-support.md index 20543e2b..16fa52b6 100644 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/memtest.md +++ b/docs/unified-test-documentation/dasharo-compatibility/30L-memtest-payload-support.md @@ -1,21 +1,22 @@ -# Dasharo Compatibility: Memtest86+ +# Dasharo Compatibility: Memtest payload support ## Test cases -### MEM001.001 Memtest86+ availability +### MEM001.001 Memtest availability **Test description** -This test aims to verify that the Memtest86+ entry is available in DUT boot menu. +This test aims to verify that the Memtest entry is available in DUT boot + menu. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` +1. `FIRMWARE` = coreboot **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -28,20 +29,20 @@ This test aims to verify that the Memtest86+ entry is available in DUT boot menu The `Payload [memtest]` option should be visible as the one of boot menu options. -### MEM001.002 Enter Memtest86+ +### MEM002.001 Enter Memtest **Test description** -This test aims to verify that the DUT enters the Memtest86+ boot option. +This test aims to verify that the DUT enters the Memtestboot option. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` +1. `FIRMWARE` = coreboot **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -55,20 +56,20 @@ This test aims to verify that the DUT enters the Memtest86+ boot option. The `Memtest86+` is visible at the top of the output. -### MEM001.003 Memtest86+ stability +### MEM003.001 Memtest stability **Test description** -This test aims to verify that the Memtest86+ starts does not hang under DUT. +This test aims to verify that the Memtest starts does not hang under DUT. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` +1. `FIRMWARE` = coreboot **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -83,20 +84,20 @@ This test aims to verify that the Memtest86+ starts does not hang under DUT. The `State: - Running...` is visible after a few seconds and confirms that the the test is in progress. -### MEM001.004 Memtest86+ refreshing by 'L' key +### MEM004.001 Memtest refreshing by 'L' key **Test description** -This test aims to verify that DUT refreshes Memtest86+ properly. +This test aims to verify that DUT refreshes Memtest properly. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` +1. `FIRMWARE` = coreboot **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -111,20 +112,20 @@ This test aims to verify that DUT refreshes Memtest86+ properly. The `Memtest86+` is visible before and after pressing `L`. -### MEM001.005 Memtest86+ refreshing by 'l' key +### MEM005.001 Memtest refreshing by 'l' key **Test description** -This test aims to verify that DUT refreshes Memtest86+ properly. +This test aims to verify that DUT refreshes Memtest properly. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` +1. `FIRMWARE` = coreboot **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -139,18 +140,18 @@ This test aims to verify that DUT refreshes Memtest86+ properly. The `Memtest86+` is visible before and after pressing `l`. -### MEM001.006 Memtest86+ completing +### MEM006.001 Memtest completing **Test description** -This test aims to verify that DUT completes Memtest86+. +This test aims to verify that DUT completes Memtest. -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` +1. `FIRMWARE` = coreboot **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** diff --git a/docs/unified-test-documentation/dasharo-compatibility/30M-uefi-compatible-interface.md b/docs/unified-test-documentation/dasharo-compatibility/30M-uefi-compatible-interface.md new file mode 100644 index 00000000..14154761 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/30M-uefi-compatible-interface.md @@ -0,0 +1,74 @@ +# Dasharo Compatibility: UEFI compatible interface + +## Test cases + +### EFI001.001 Boot into UEFI OS (Ubuntu 20.04) + +**Test description** + +This test verifies the presence of UEFI compatible interface by booting +UEFI-aware Operating System. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). + +**Test steps** + +1. Power on the DUT. +1. Enter the boot menu using the `BIOS_SETUP_KEY`. +1. Select the `Boot Menu` and press `Enter`. +1. Select the USB stick and press `Enter`. +1. Select the `Ubuntu (safe graphics)` in the GRUB menu. +1. Wait for the `OPERATING_SYSTEM` to boot finalize booting, by either of the: + - `OPERATING_SYSTEM` installer initialization, + - login form initialization. +1. Power OFF the DUT. + +**Expected result** + +1. Either the login screen or the `OPERATING_SYSTEM` installer appears on the + internal LCD. + +### EFI001.002 Boot into UEFI OS (Windows 11) + +**Test description** + +This test aims to verify the presence of UEFI compatible interface by booting +UEFI-aware Operating System. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). + +**Test steps** + +1. Power on the DUT. +1. Enter the boot menu using the `BIOS_SETUP_KEY`. +1. Select the `Boot Menu` and press `Enter`. +1. Select the USB stick and press `Enter`. +1. Wait for the `OPERATING_SYSTEM` to boot finalize booting, by either of the: + - `OPERATING_SYSTEM` installer initialization, + - login form initialization. +1. Power OFF the DUT. + +**Expected result** + +1. Either the login screen or the `OPERATING_SYSTEM` installer appears on the + internal LCD. diff --git a/docs/unified-test-documentation/dasharo-compatibility/30P-uefi-shell.md b/docs/unified-test-documentation/dasharo-compatibility/30P-uefi-shell.md new file mode 100644 index 00000000..f34b5394 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/30P-uefi-shell.md @@ -0,0 +1,49 @@ +# Dasharo Compatibility: UEFI Shell + +## Test cases + +### USH001.001 UEFI Shell + +**Test description** + +This test aims to verify that the DUT has the ability to boot into an integrated +UEFI Shell application. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: Firmware](../../generic-test-setup#firmware). + +**Test steps** + +1. Power on the DUT. +1. While the DUT is booting, hold the `BOOT_MENU_KEY` to enter the UEFI Boot + Menu. +1. Select the `UEFI Shell` option using the arrow keys and press `Enter`. + +**Expected result** + +The DUT boots into an UEFI Shell successfully, as indicated by the example +console output shown on the screen: + +```text +UEFI Interactive Shell v2.2 +EDK II +UEFI v2.70 (EDK II, 0x00010000) +Mapping table + FS0: Alias(s):HD1b:;BLK2: + PciRoot(0x0)/Pci(0x6,0x0)/Pci(0x0,0x0)/NVMe(0x1,9C-BB-50-01-BB-38-25-5 +-4BB4-4FDD-9534-B097CD497222,0x800,0x100000) + FS1: Alias(s):HD1c:;BLK3: + PciRoot(0x0)/Pci(0x6,0x0)/Pci(0x0,0x0)/NVMe(0x1,9C-BB-50-01-BB-38-25-1 +-C6AB-4400-AE03-0BF2960DD525,0x100800,0x1D0C5000) + BLK1: Alias(s): + PciRoot(0x0)/Pci(0x6,0x0)/Pci(0x0,0x0)/NVMe(0x1,9C-BB-50-01-BB-38-25-) + BLK0: Alias(s): + PciRoot(0x0)/Pci(0x14,0x0)/USB(0x0,0x2) + Press ESC in 1 seconds to skip startup.nsh or any other key to continue. +``` diff --git a/docs/unified-test-documentation/dasharo-compatibility/312-nvme-support.md b/docs/unified-test-documentation/dasharo-compatibility/312-nvme-support.md new file mode 100644 index 00000000..54cb5bed --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/312-nvme-support.md @@ -0,0 +1,108 @@ +# Dasharo Compatibility: NVMe support + +## Test cases + +### NVM001.001 NVMe support (firmware) + +**Test description** + +This test aims to verify that firmware is able to correctly +detect NVMe disk in the M.2 slot. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). + +**Test steps** + +1. Insert a NVMe disk into the M.2 slot on the DUT. +1. Power on the DUT. +1. While the DUT is booting, hold the `BOOT_MENU_KEY` to enter + the UEFI Boot Menu and note the result. + +**Expected result** + +1. The NVMe disk should be listed on the bootable devices list. + +### NVM001.002 NVMe support (Ubuntu 20.04) + +**Test description** + +This test aims to verify booting the Operating System from NVMe disk in +the M.2 slot. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Insert a NVMe disk into the M.2 slot on the DUT. +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the follwing command: + +```bash +sudo mount | grep 'on / ' +``` + +**Expected result** + +1. The `OPERATING_SYSTEM` has been booted from the NVMe disk correctly. +1. Output in Terminal indicates that system partition is installed on the NVMe + disk: + +```bash +/dev/nvme* on / tpe ext4 (rw,relatime,errors=remount-ro) +``` + +### NVM001.003 NVMe support in OS (Windows 11) + +**Test description** + +This test aims to verify booting the Operating System from NVMe disk in the +M.2 slot. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Insert a NVMe disk into the M.2 slot on the DUT. +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open device manager. +1. Select `Disk drives` option and find correct drive. +1. Right click the drive entry and select `Properties` option +1. Go to `Details` tab. +1. In the `Property` menu select `Hardware Ids` option. +1. Find the `Value` window and note the result. + +**Expected result** + +1. The `OPERATING_SYSTEM` booting from the NVMe disk +1. `NVMe` text found in the `Hardware Ids` `Values` window diff --git a/docs/unified-test-documentation/dasharo-compatibility/315-network-boot.md b/docs/unified-test-documentation/dasharo-compatibility/315-network-boot.md new file mode 100644 index 00000000..24b95a14 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/315-network-boot.md @@ -0,0 +1,37 @@ +# Dasharo Compatibility: Network Boot + +## Test cases + +### PXE001.001 iPXE network boot + +**Test description** + +This test aims to verify that the DUT is capable of network booting from a PXE +server. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). + +**Test steps** + +1. Power on the DUT. +1. Hold the `BOOT_MENU_KEY` to enter the UEFI Boot Menu. +1. Select the `iPXE Network boot` option using the arrow keys and press `Enter`. +1. Press `Ctrl+B` when prompted to stop iPXE from booting automatically. +1. Type in `dhcp` to obtain an IP address. +1. Type in `chain --autofree http://boot.netboot.xyz/` to load a boot menu +1. Enter the "Live CDs" submenu using the arrow keys and Enter. +1. Select `Debian` -> `Debian Live 11 (bullseye)` -> `Debian 11 Gnome` and + press Enter. + +**Expected result** + +1. The iPXE application boots successfully. +1. iPXE obtains an IP address. +1. iPXE boots an `Debian 11` from netboot.xyz. diff --git a/docs/unified-test-documentation/dasharo-compatibility/316-sdcard-reader.md b/docs/unified-test-documentation/dasharo-compatibility/316-sdcard-reader.md new file mode 100644 index 00000000..320e0da4 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/316-sdcard-reader.md @@ -0,0 +1,159 @@ +# Dasharo Compatibility: SD Card Reader + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). +1. Insert an SD card into the SD Card reader. + +### SDC001.001 SD Card reader detection (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the SD Card reader is enumerated correctly and +can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the follwing command: + +```bash +lspci | grep RTS522A +``` + +**Expected result** + +The output from the command should contain the line: + +```bash +2d:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01) +``` + +### SDC001.002 SD Card reader detection (Windows 11) + +**Test description** + +This test aims to verify that the SD Card reader is enumerated correctly and +can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open `Device Manager` +1. Find `Memory technology devices` category and expand it +1. In the expanded section, find `Realtek PCIE CardReader` device +1. Double click `Realtek PCIE CardReader` and note the result + +**Expected result** + +1. `Realtek PCIE CardReader` should be listed in the `Device Manager` +and should not report any error. + +### SDC002.001 SD Card read/write (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the SD Card reader is initialized correctly and +can be used from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following commands as root: + +```bash +dd if=/dev/urandom of=/tmp/in.bin bs=4K count=100 +dd if=/tmp/in.bin of=/dev/mmcblk0 bs=4K count=100 +dd if=/dev/mmcblk0 of=/tmp/out.bin bs=4K count=100 +sha256sum /tmp/in.bin /tmp/out.bin +``` + +**Expected result** + +The output from the last command should contain 2 indentical checksums: + +```bash +2083776668ed0c8095a9ac42188153c02f360e116c14b36d2ef5c98665d75dcb /tmp/in.bin +2083776668ed0c8095a9ac42188153c02f360e116c14b36d2ef5c98665d75dcb /tmp/out.bin +``` + +### SDC002.002 SD Card read/write (Windows 11) + +**Test description** + +This test aims to verify that the SD Card reader is initialized correctly and +can be used from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open `Windows Explorer` and go to `This PC` +1. Find SD card icon and double click it +1. Click the right mouse button and choose `New` then choose `Text Document` +1. Name the new file and double click the icon to open it in `Notepad` +1. Write any text and press Ctrl+s +1. Close `Notepad` +1. In the `Windows Explorer` use the right mouse button to click icon + of the SD Card and click `Eject` +1. Remove the SD Card and insert it again +1. Find SD card icon and double click it again +1. Find created text file, double click to open it and note the result + +**Expected result** + +Saved text should be readable ofter opening saved file in the `Notepad`. diff --git a/docs/unified-test-documentation/dasharo-compatibility/317-usb-camera.md b/docs/unified-test-documentation/dasharo-compatibility/317-usb-camera.md new file mode 100644 index 00000000..16dcef8d --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/317-usb-camera.md @@ -0,0 +1,89 @@ +# Dasharo Compatibility: USB Camera + +## Test cases + +### CAM001.001 USB Camera (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the integrated USB camera is initialized +correctly and can be accessed from the operating system + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). +1. Install ffprobe: `sudo apt install ffmpeg`. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and run the following commands: + +```bash +ffprobe /dev/video0 +ffprobe /dev/video2 +``` + +**Expected result** + +1. The output from the first command should contain the lines: + + ```bash + Input #0, video4linux2,v4l2, from '/dev/video0': + Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 640x480, 147456 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc + ``` + +1. The output from the second command should contain the lines: + + ```bash + Input #0, video4linux2,v4l2, from '/dev/video2': + Stream #0:0: Video: rawvideo (Y800 / 0x30303859), gray, 640x360, 55296 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc + ``` + +### CAM001.002 USB Camera (Windows 11) + +**Test description** + +This test aims to verify that the integrated USB camera is initialized +correctly and can be accessed from the operating system + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../generic-test-setup#os-boot-from-disk). + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open `Camera` app and note the result. + +**Expected result** + +1. In the `Camera` app, an image from the integrated USB camera should be shown. diff --git a/docs/unified-test-documentation/dasharo-compatibility/318-m2-wifi-bluetooth.md b/docs/unified-test-documentation/dasharo-compatibility/318-m2-wifi-bluetooth.md new file mode 100644 index 00000000..781df7a0 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/318-m2-wifi-bluetooth.md @@ -0,0 +1,264 @@ +# Dasharo Compatibility: M.2 WiFi/Bluetooth + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). + +### WLE001.001 Wireless card detection (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the Wi-Fi/Bluetooth card is enumerated correctly +and can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following command: + +```bash +lspci | grep AX20 +``` + +**Expected result** + +The output of the command should contain the line: + +```bash +2f:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) +``` + +The exact name and revision may be different depending on hardware configuration. + +### WLE001.002 Wireless card detection (Windows 11) + +**Test description** + +This test aims to verify that the Wi-Fi/Bluetooth card is enumerated correctly +and can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open PowerShell and execute following command: + +```bash +Get-PnpDevice -PresentOnly | Select-String -Pattern "Wi-Fi" +``` + +1. Note the result. + +**Expected result** + +The output of the command should contain a line starting with: + +```bash +Intel(R) Wi-Fi 6AX200 160MHz +``` + +or a line starting with: + +```bash +Intel(R) Wi-Fi 6AX201 160MHz +``` + +### WLE002.001 Wi-Fi scanning (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the Wi-Fi functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Make sure to have any Wi-Fi signal available. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following commands as root: + +```bash +nmcli radio wifi on +nmcli device wifi rescan +# Wait ~5 seconds +nmcli device wifi list +``` + +**Expected result** + +The output of the last command should return a list of available Wi-Fi networks, +for example: + +```bash +IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY + 36:78:EE:05:03:45 DIRECT-ny Infra 6 65 Mbit/s 75 ▂▄▆_ WPA2 +* 60:38:E0:D6:46:9A 3mdeb_abr_5GHz Infra 48 405 Mbit/s 72 ▂▄▆_ WPA2 + 60:38:E0:D6:46:99 3mdeb_abr Infra 11 54 Mbit/s 69 ▂▄▆_ WPA2 + D8:D7:75:02:F9:BF FunBox2-F9BF_2.4GHz Infra 1 130 Mbit/s 50 ▂▄__ WPA1 WPA2 + 30:5A:3A:A1:46:B0 H_Office Infra 2 270 Mbit/s 35 ▂▄__ WPA2 + 9E:93:4E:74:C0:3F DIRECT-xpPhaser 3330 Infra 1 65 Mbit/s 34 ▂▄__ WPA2 + D8:A7:56:D9:A7:9F Orange_Swiatlowod_A79A Infra 108 540 Mbit/s 32 ▂▄__ WPA2 + 86:25:19:05:D4:A0 DIRECT-KRM288x Series Infra 11 54 Mbit/s 22 ▂___ WPA2 + D8:A7:56:D9:A7:9A Orange_Swiatlowod_A79A Infra 11 130 Mbit/s 20 ▂___ WPA2 + 9E:93:4E:74:C0:57 DIRECT-ejPhaser 3330 Infra 1 65 Mbit/s 17 ▂___ WPA2 + B0:BE:76:06:9F:22 NED-WIFI Infra 11 270 Mbit/s 17 ▂___ WPA2 +``` + +### WLE002.002 Wi-Fi scanning (Windows 11) + +**Test description** + +This test aims to verify that the Wi-Fi functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Make sure to have any Wi-Fi signal available + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Locate in the bottom right corner of the screen `Internet access` + icon and click it. +1. Enable Wi-Fi and note the result. + +**Expected result** + +After enabling Wi-Fi available networks should appear +in the `Internet access` menu. + +### WLE003.001 Bluetooth scanning (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the Bluetooth functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Enable Bluetooth and make it discoverable in any device nearby DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following commands: + +```bash +bluetoothctl +power on +scan on +# Wait ~5 seconds +devices +``` + +**Expected result** + +The output of the last command should return a list of detectable Bluetooth +devices, for example: + +```bash +Device 48:24:57:E0:61:74 48-24-57-E0-61-74 +Device 88:BD:45:74:FA:A5 Wojtek N +Device CE:9E:7B:BF:69:F2 Mi Smart Band 4 +Device 56:62:93:8B:1A:F9 Galaxy Watch4 Classic (PHLM) +Device 64:F2:FD:1E:26:BC Galaxy Watch4 Classic (PHLM) +Device 0F:18:A1:D9:23:F6 0F-18-A1-D9-23-F6 +Device 8C:EA:48:B1:59:B3 [Signage] Samsung QMR Series +Device 8C:EA:48:B1:57:EB [Signage] Samsung QMR Series +Device 76:C7:FD:86:9B:0E 76-C7-FD-86-9B-0E +Device 40:5E:96:43:3A:6A 40-5E-96-43-3A-6A +Device 4C:58:3B:C1:37:90 4C-58-3B-C1-37-90 +Device 6A:93:A2:6A:E5:20 6A-93-A2-6A-E5-20 +``` + +### WLE003.002 Bluetooth scanning (Windows 11) + +**Test description** + +This test aims to verify that the Bluetooth functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Enable Bluetooth and make it discoverable in any device nearby DUT + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Enter `Notification Center` in the bottom right part of the screen. +1. Using right mouse button click on the Bluetooth icon. +1. In shown drop-down menu click `Go to settings`. +1. Click the `+` icon described as `Add Bluetooth or other device`. +1. In the `Add a device` menu click `Bluetooth`. +1. Wait a few moments until DUT scans for nearby Bluetooth devices and note + the result. + +**Expected result** + +Available Bluetooth devices should appear in the `Add a device` window. diff --git a/docs/unified-test-documentation/dasharo-compatibility/319-nvidia-graphics.md b/docs/unified-test-documentation/dasharo-compatibility/319-nvidia-graphics.md new file mode 100644 index 00000000..463d2c92 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/319-nvidia-graphics.md @@ -0,0 +1,185 @@ + +# Dasharo Compatibility: NVIDIA Graphics support + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). + +### NVI001.001 NVIDIA Graphics detect (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the NVIDIA graphics card is correctly +initialized and can be detected by the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + lspci | grep -i nvidia + ``` + +**Expected result** + +1. The command should return one line containing the name of the graphics + card, e.g: + + ```bash + 2d:00.0 3D controller: NVIDIA Corporation TU117M (rev a1) + ``` + +### NVI001.002 NVIDIA Graphics detect (Windows 11) + +**Test description** + +This test aims to verify that the NVIDIA graphics card is correctly +initialized and can be detected by the operating system + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install the driver for the graphics card (GTX 1650) from + [the official page](https://www.nvidia.com/). + +**Test steps** + +1. Open the Start menu. +1. Type in `Device Manager`. +1. Click on the Device Manager icon to open the Device Manager. +1. Open the `Display adapters` section to wiew the GPUs present in the system. + +**Expected result** + +1. The list should contain the NVIDIA graphics card present in the system: + +![Device Manager](../../images/nvidia_win10.png) + +### NVI002.001 NVIDIA Graphics power management (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the NVIDIA graphics power management is functional +and the card powers on only while it's used. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install the package `mesa-utils` with the following command: + + ```bash + sudo apt install mesa-utils + ``` + +**Test steps** + +1. Open a terminal window. +1. Run the following command to see whether the card is off: + + ```bash + cat /sys/class/drm/card1/device/power/runtime_status + ``` + +1. Launch a test application on the discrete graphics card using the following + command: + + ```bash + __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears + ``` + +1. Run the following command to see whether the card has turned on: + + ```bash + cat /sys/class/drm/card1/device/power/runtime_status + ``` + +1. Close the test application and wait ~20 seconds to let the graphics card + shut itself down. +1. Run the following command to see whether the card has turned off again: + + ```bash + cat /sys/class/drm/card1/device/power/runtime_status + ``` + +**Expected result** + +1. The output from the first command should be the word `suspended`. +1. The output from the second command should be the word `active`. +1. The output from the third command should be the word `suspended`. + +### NVI002.002 NVIDIA Graphics power management (Windows 11) + +**Test description** + +This test aims to verify that the NVIDIA graphics power management is functional +and the card powers on only while it's used. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install the driver for the graphics card (GTX 1650) from + [the official page](https://www.nvidia.com/). +1. Download and extract `gputest` from [Geeks3D](geeks3d.com/gputest). + +**Test steps** + +1. Open the NVIDIA Control Panel window. +1. In the menu bar, open the Desktop menu. +1. Enable the `Display GPU Activity Icon in Notification Area` option. +1. Open the system tray located in the bottom right corner of the screen + and locate the GPU activity icon: + +![GPU activity icon](../../images/gpu_activity_win10.png) + +1. Open the previously extracted gputest directory and open the `GPUTest_GUI` + application. +1. Click on the `Run stress test` button to start the test application. +1. Locate the GPU activity icon and check that it indicates that the GPU has + powered on. +1. Close the test application. +1. Locate the GPU activity icon and check that it indicates that the GPU has + powered off again. + +**Expected result** + +1. The GPU activity icon should indicate that the GPU is OFF when no application + is using the GPU. +1. The GPU activity icon should indicate that the GPU is ON when an application + is using the GPU. +1. The GPU activity icon should indicate that the GPU is OFF again after the + test application is closed. diff --git a/docs/unified-test-documentation/dasharo-compatibility/31A-windows-booting.md b/docs/unified-test-documentation/dasharo-compatibility/31A-windows-booting.md new file mode 100644 index 00000000..3dce404e --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31A-windows-booting.md @@ -0,0 +1,31 @@ +# Dasharo Compatibility: Windows 11 booting + +## Test cases + +### WBT001.001 Windows 11 installation and boot + +**Test description** + +This test aims to verify that Windows 11 OS could be installed on the Device +Under Test and works properly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the + [Generic test setup: Firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). + +**Test steps** + +1. Power on the DUT. +1. Wait for the `OPERATING_SYSTEM` to boot and note the result. + +**Expected result** + +The Windows 11 login screen should be displayed. diff --git a/docs/unified-test-documentation/dasharo-compatibility/31E-display-ports-and-lcd.md b/docs/unified-test-documentation/dasharo-compatibility/31E-display-ports-and-lcd.md new file mode 100644 index 00000000..83decb85 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31E-display-ports-and-lcd.md @@ -0,0 +1,262 @@ +# Dasharo Compatibility: Display ports and LCD support + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). + +### DSP001.001 Internal LCD (firmware) + +**Test description** + +This test aims to verify initialization of the laptop's embedded LCD screen +during firmware execution phase. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). + +**Test steps** + +1. Power on the DUT. +1. Observe the internal LCD during firmware execution phase. +1. Power off the DUT. + +**Expected result** + +1. Logo appears on the screen during firmware execution phase. + +### DSP001.002 Internal LCD in OS (Ubuntu 20.04) + +**Test description** + +This test aims to verify initialization of the laptop's embedded LCD in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Observe the internal LCD after the `OPERATING_SYSTEM` has booted. + +**Expected result** + +1. Either the login screen or the `OPERATING_SYSTEM` installer appears on the + internal LCD. + +### DSP001.003 Internal LCD in OS (Windows 11) + +**Test description** + +This test aims to verify initialization of the laptop's embedded LCD in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Observe the internal LCD after the `OPERATING_SYSTEM` has booted. + +**Expected result** + +1. Either the login screen or the `OPERATING_SYSTEM` installer appears on the + internal LCD. + +### DSP002.001 External HDMI display in OS (Ubuntu 20.04) + +**Test description** + +This test aims to verify initialization of the external HDMI display in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. If using more than one display, switch the display mode between `Mirror` and + `Join Displays`. + +**Expected result** + +1. The image should be displayed on the external HDMI display in `Mirror` and + `Join Displays` modes. + +### DSP002.002 External HDMI display in OS (Windows 11) + +**Test description** + +This test aims to verify initialization of the external HDMI display in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. If using more than one display, switch the display mode between `Duplicate` + and `Extend`. + +**Expected result** + +1. The image should be displayed on the external HDMI display in `Duplicate` + and `Extend` modes. + +### DSP002.003 External HDMI display in firmware + +This test aims to verify initialization of the external HDMI display +during firmware execution phase. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). + +**Test steps** + +1. Power on the DUT. +1. Observe the external HDMI display during firmware execution phase. +1. Power off the DUT. + +**Expected result** + +1. Logo appears on the screen during firmware execution phase. + +### DSP003.001 External DP display in OS (Ubuntu 20.04) + +**Test description** + +This test aims to verify initialization of the external Display Port connected +in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +2. Connect a Display Port cable to the DUT and a display. + +**Test steps** + +1. Power on the DUT. +2. Boot into the system. +3. Log into system by using the proper login and password. +4. If using more than one display, switch the display mode between `Mirror` and + `Join Displays`. + +**Expected result** + +1. The image should be displayed on the external Display Port connected display + in `Mirror` and `Join Displays` modes. + +### DSP003.002 External DP display in OS (Windows 11) + +**Test description** + +This test aims to verify initialization of the external Display Port connected +display in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +2. Connect a Display Port cable to the DUT and a display. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. If using more than one display, switch the display mode between `Duplicate` + and `Extend`. + +**Expected result** + +1. The image should be displayed on the external Display Port connected display + in `Duplicate` and `Extend` modes. + +### DSP003.003 External DP display in firmware + +This test aims to verify initialization of the external Display Port connected +display during firmware execution phase. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +2. Connect a Display Port cable to the DUT and a display. + +**Test steps** + +1. Power on the DUT. +2. Observe the external Display Port connected display during firmware + execution phase. +3. Power off the DUT. + +**Expected result** + +1. Logo appears on the screen during firmware execution phase. diff --git a/docs/unified-test-documentation/dasharo-compatibility/31F-audio-subsystem.md b/docs/unified-test-documentation/dasharo-compatibility/31F-audio-subsystem.md new file mode 100644 index 00000000..e5718014 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31F-audio-subsystem.md @@ -0,0 +1,472 @@ +# Dasharo Compatibility: Audio subsystem + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). +1. Install the `alsa-utils` package: + `sudo apt install alsa-utils`. + +### AUD001.001 Audio subsystem detection (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the audio subsystem is initialized correctly +and can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following command: + +```bash +cat /sys/class/sound/card0/hwC0D*/chip_name +``` + +**Expected result** + +The output of the command should return a list of detected audio devices: + +```text +ALC293 +Tigerlake HDMI +``` + +### AUD001.002 Audio subsystem detection (Windows 11) + +**Test description** + +This test aims to verify that the audio subsystem is initialized correctly +and can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open `Start Menu`, find and open `Device Manager`. +1. Find `Audio inputs and outputs` group and expand it. Note the result. + +**Expected result** + +1. `Microphone (Realtek(R) Audio)` and `Speakers (Realtek(R) Audio)` + should be listed in the `Audio inputs and outputs` group. +1. Both audio devices should not report any error. + +### AUD002.001 Audio playback (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the audio subsystem is able to playback audio +recordings. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following command: + +```bash +pactl set-sink-mute alsa_output.pci-0000_00_1f.3.analog-stereo 0 +pactl set-sink-volume alsa_output.pci-0000_00_1f.3.analog-stereo 65535 +speaker-test +``` + +**Expected result** + +Sound should be played from the integrated speakers. + +### AUD002.002 Audio playback (Windows 11) + +**Test description** + +This test aims to verify that the audio subsystem is able to playback audio +recordings. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Find the `Speakers` icon in the bottom right part of the screen and click + it using the left mouse button to open volume menu. +1. In the volume menu, click the rightmost part of it and note the reult. + +**Expected result** + +Sound should be played from the integrated speakers. + +### AUD003.001 Audio capture (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the audio subsystem is able to capture audio. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following command: + +```bash +arecord -f S16_LE -d 10 -r 16000 /tmp/test-mic.wav +``` + +1. Make some noise aroud DUT. For example, say something. +1. Execute the following command: + +```bash +aplay /tmp/test-mic.wav +``` + +**Expected result** + +Recorded audio clip is recorded correctly and played back. + +### AUD003.002 Audio capture (Windows 11) + +**Test description** + +This test aims to verify that the audio subsystem is able to capture audio. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Find the `Speakers` icon in the bottom right part of the screen and click + it using the right mouse button and then using the left mouse button + click `Open Sound Settings`. +1. Locate the `Test your microphone` section and observe it. +1. Create some noise for the DUT to capture and note the result. + For example, say something. + +**Expected result** + +Audio level bar located in the `Test your microphone` should raise when +some noise is being created. + +### AUD004.001 External headset recognition (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the external headset is properly recognized +after plugging in the 3.5 mm jack into the slot. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Plug in a headset jack into micro jack slot located on the right side of the + laptop. +1. When the `Select Audio Device` menu appears, select what type of external + device has been connected to the laptop (headset). +1. Open a terminal window and execute the following command: + +```bash +amixer -c 0 contents | grep -A 2 'Front Headphone Jack' +``` + +1. Disconnect the headset from the laptop. +1. Execute the following command again: + +```bash +amixer -c 0 contents | grep -A 2 'Front Headphone Jack' +``` + +**Expected result** + +1. The output of the first command should not be empty and contains the line: + +```text +: values=on +``` + +1. The output of the second command should not be empty and contains the line: + +```text +: values=off +``` + +### AUD004.002 External headset recognition (Windows 11) + +**Test description** + +This test aims to verify that the external headset is properly recognized +after plugging in the 3.5 mm jack into the slot. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Plug in a headset jack into micro jack slot located on the right + side of the laptop. +1. After the `Which device did you plug in` menu appearing, select what type + of external device has been connected to the laptop (headset). +1. Find the `Speakers` icon in the bottom right part of the screen and click + it using the right mouse button and then using the left mouse button + click `Open Sound Settings`. +1. Locate `Input` section and click on the `Device properties` option. +1. In `Device properties` window select option `Additional device properties`. +1. Locate in `General` the section field named `Jack Information`. +1. Close the window `Microphone properties`. +1. Disconnect a headset from the laptop. +1. Select again the `Addtional device properties` option and locate again + field named `Jack information`. + +**Expected result** + +1. `Jack Information` field in the first case should show the position + `Front Panel 3.5 mm Jack`. +1. After disconnecting a headset from the laptop and checking again + option `Addtional device properties` field `Jack Information` should not + contain the phrase `Front Panel 3.5 mm Jack`. + +### AUD005.001 External headset audio playback (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the audio subsystem is able to playback audio +recordings by using the external headset speakers. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Plug in a headset jack into micro jack slot located on the right side of the + laptop. +1. Open a terminal window and execute the following command: + +```bash +pactl set-sink-mute alsa_output.pci-0000_00_1f.3.analog-stereo 0 +pactl set-sink-volume alsa_output.pci-0000_00_1f.3.analog-stereo 65535 +speaker-test +``` + +**Expected result** + +Sound should be played from the external speakers. + +### AUD005.002 External headset audio playback (Windows 11) + +**Test description** + +This test aims to verify that the audio subsystem is able to playback audio +recordings by using the external headset speakers. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Plug in a headset jack into micro jack slot located on the right side of the + laptop. +1. Find the `Speakers` icon in the bottom right part of the screen and click + it using the left mouse button to open volume menu. +1. In the volume menu, click the rightmost part of it and note the reult. + +**Expected result** + +Sound should be played from the external speakers. + +### AUD006.001 External headset audio capture (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the audio subsystem is able to capture audio +from external headset. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Plug in a headset jack into micro jack slot located on the right side of the + laptop. +1. Open a terminal window and execute the following command: + +```bash +arecord -f S16_LE -d 10 -r 16000 /tmp/test-mic.wav +``` + +1. Make some noise for the headset. For example, say something. +1. Execute the following command: + +```bash +aplay /tmp/test-mic.wav +``` + +1. Execute the following command: + +```bash +arecord -f S16_LE -d 10 -r 16000 /tmp/test-mic-1.wav +``` + +1. Make some noise for the DUT. For example tap a few times in the laptop casing. +1. Execute the following command: + +```bash +aplay /tmp/test-mic.wav +``` + +**Expected result** + +1. During playback of the first recording, all noise that was made for headset + should be clearly heard. +2. During playback of the second recording, all noise that was made for DUT + should be quiet or not heard. + +### AUD006.002 External headset audio capture (Windows 11) + +**Test description** + +This test aims to verify that the audio subsystem is able to capture audio +from external headset. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Plug in a headset jack into micro jack slot located on the right side of the + laptop. +1. Find the `Speakers` icon in the bottom right part of the screen and click + it using the right mouse button and then using the left mouse button + click `Open Sound Settings`. +1. Locate the `Test your microphone` section and observe it. +1. Create some noise for the headset to capture and note the result. + For example, say something. +1. Create some noise for the DUT. For example tap a few times in the laptop + casing. + +**Expected result** + +1. Audio level bar located in the `Test your microphone` should raise when + some noise have been created for the headset. +1. Audio level bar located in the `Test your microphone` should not raise when + some noise have been created for the DUT. diff --git a/docs/unified-test-documentation/dasharo-compatibility/31G-ec-and-superio.md b/docs/unified-test-documentation/dasharo-compatibility/31G-ec-and-superio.md new file mode 100644 index 00000000..2783e8f8 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31G-ec-and-superio.md @@ -0,0 +1,1288 @@ +# Dasharo Compatibility: Embedded Controller and Super I/O initialization + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). + +### ECR001.001 Battery monitoring - charge level in OS (Ubuntu 20.04) + +**Test description** + +This test verifies whether the battery charge level is reported in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Locate the power menu in the upper right corner of the screen. +1. Open the power menu and locate the battery status indicator. + +**Expected result** + +1. The battery status indicator should show the current charge level (percentage + left). + +### ECR001.002 Battery monitoring - charge level in OS (Windows 11) + +**Test description** + +This test verifies whether the battery charge level is reported in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Locate the power menu in the lower right corner of the screen. + +**Expected result** + +1. The battery status indicator should show the current charge level (percentage + left). + +### ECR002.001 Battery monitoring - charging state in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the power supply state is detected correctly in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Locate the power menu in the upper right corner of the screen. +1. Open the power menu and locate the battery status indicator. +1. Note the current state. +1. Unplug the power supply and wait for the battery charge state to change to + `Discharging`. +1. Plug in the power supply and wait for the battery charge state to change to + `Charging`. + +**Expected result** + +1. The battery charge indicator should correctly show whether the power supply + is plugged in or not. +1. The battery charge indicator should detect the AC adapter state change + within seconds of the adapter being plugged in/out. + +### ECR002.002 Battery monitoring - charging state in OS (Windows 11) + +**Test description** + +This test verifies that the power supply state is detected correctly in the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Locate the power menu in the lower right corner of the screen. +1. Open the power menu and locate the battery status indicator. +1. Note the current state. +1. Unplug the power supply and wait for the battery charge state to change to + `on battery`. +1. Plug in the power supply and wait for the battery charge state to change to + `plugged in`. + +**Expected result** + +1. The battery charge indicator should correctly show whether the power supply + is plugged in or not. +1. The battery charge indicator should detect the AC adapter state change + within seconds of the adapter being plugged in / out. + +### ECR003.001 Touchpad in OS - (Ubuntu 20.04) + +**Test description** + +This test verifies that the touchpad is initialized correctly and is detected +by the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install `libinput-tools` on the DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Verify that the cursor can be moved with the touchpad and that clicking works + (test both clicking and tapping). +1. Run `sudo libinput debug-events` in the terminal: + 1. Verify that scrolling with 2 fingers generates a `POINTER_AXIS` event, + 1. Verify that pinching with 2 fingers generates a `GESTURE_PINCH_UPDATE` event. +1. Press `Ctrl + C` to terminate the `libinput` program. + +**Expected result** + +1. Moving the cursor, clicking, zooming and scrolling are detected correctly by + the operating system. + +### ECR003.002 Touchpad in OS - (Windows 11) + +**Test description** + +This test verifies that the touchpad is initialized correctly and is detected +by the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Verify that the cursor can be moved with the touchpad and that clicking + works (test both clicking and tapping). +1. Open `C:\Windows` in `Windows Explorer` + 1. Verify that scrolling with 2 fingers moves the content of the window, + 1. Verify that pinching with 2 fingers zooms in and zooms out the content. + +**Expected result** + +1. Moving the cursor, clicking, zooming and scrolling are detected correctly by + the operating system. + +### ECR004.001 Keyboard (standard keypad) in firmware + +**Test description** + +This test verifies that the keyboard is detected correctly by the firmware +and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `BIOS_SETUP_KEY` = `F2` + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../generic-test-setup/#firmware) + +**Test steps** + +1. Power on the DUT and press the `BIOS_SETUP_KEY` to enter the setup menu. +1. Use the arrow keys and the Enter key to navigate the menus. + +**Expected result** + +1. All menus can be entered using the internal keyboard. + +### ECR004.002 Keyboard (standard keypad) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the keyboard is detected correctly by the operating +system and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `BIOS_SETUP_KEY` = `F2` +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install `libinput-tools` on the DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Run `sudo libinput debug-events --show-keycodes` in the terminal. +1. Press each keyboard key and check the generated keycode. + +**Expected result** + +1. All standard keyboard keys generate the correct keycodes and events as per + their labels. +1. Key combinations are detected correctly. + +### ECR004.003 Keyboard (standard keypad) in OS (Windows 11) + +**Test description** + +This test verifies that the keyboard is detected correctly by the operating +system and all basic keys work according to their labels. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open `notepad` + 1. Test the alphanumeric keys and note the generated characters + 1. Test non-alphanumeric keys and verify that they generate the signs + 1. Test key combinations with the `Shift`, and `Alt` modifier keys +1. Open `On-Screen Keyboard` and press `Ctrl` key on the hardware keyboard. + Check if `On-Screen Keyboard` correctly highlights it. +1. Open `Start menu` and press `Esc`. Check if `Start menu` is properly closed. + +**Expected result** + +1. All standard keyboard keys generate correct characters + or actions when pressed. +1. Key combinations are detected correctly. + +### ECR005.001 Keyboard (function key: play/pause) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the play/pause hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install `libinput-tools` on the DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Run `sudo libinput debug-events --show-keycodes` in the terminal. +1. Verify that pressing the play/pause key generates a `KEY_PLAYPAUSE` event. + +**Expected result** + +1. Pressing the play/pause hotkey generates a `KEY_PLAYPAUSE` event. + +### ECR005.002 Keyboard (function key: play/pause) in OS (Windows 11) + +**Test description** + +This test verifies that the play/pause hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Start `Groove Music` +1. Verify that when pressing the `play/pause` button, player menu apperars + in the upper left part of the screen for a few seconds. + +**Expected result** + +1. Pressing the play/pause hotkey is proreply detected by the OS + +### ECR006.001 Keyboard (function key: cooling mode) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the cooling mode hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the cooling mode hotkey (Fn + 1) once and note the effect. +1. Press the cooling mode hotkey once again and note the effect. + +**Expected result** + +1. Pressing the hotkey once should activate the cooling mode (fans should + spin up to their maximum speed). +1. Pressing the hotkey again should deactivate the cooling mode (fans should + return to normal). + +### ECR006.002 Keyboard (function key: cooling mode) in OS (Windows 11) + +**Test description** + +This test verifies that the cooling mode hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the cooling mode hotkey (Fn + 1) once and note the effect. +1. Press the cooling mode hotkey once again and note the effect. + +**Expected result** + +1. Pressing the hotkey once should activate the cooling mode (fans should + spin up to their maximum speed). +1. Pressing the hotkey again should deactivate the cooling mode (fans should + return to normal). + +### ECR007.001 Keyboard (function key: touchpad on/off) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the touchpad on/off hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Proceed with the [Common](#common) section. +1. Create a file `/etc/udev/hwdb.d/60-keyboard.hwdb` with the following contents: + + ```bash + evdev:atkbd:dmi:bvn*:bvr*:svnNotebook:pnNV4XMB,ME,MZ:* + KEYBOARD_KEY_f7=191 + KEYBOARD_KEY_f8=191 + ``` + +1. Execute the following commands: + +```bash +sudo systemd-hwdb update +sudo udevadm trigger +``` + +**Test steps** + +1. Press the touchpad on/off key and try to use the touchpad. +1. Press the touchpad on/off key once again and try to use the touchpad again. + +**Expected result** + +1. Pressing the hotkey once should deactivate the touchpad (touchpad should be + completely inoperable). +1. Pressing the hotkey again should reactivate the touchpad. + +### ECR007.002 Keyboard (function key: touchpad on/off) in OS (Windows 11) + +**Test description** + +This test verifies that the touchpad on/off hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the touchpad on/off key and try to use the touchpad. +1. Press the touchpad on/off key once again and try to use the touchpad again. + +**Expected result** + +1. Pressing the hotkey once should deactivate the touchpad (touchpad should be + completely inoperable). +1. Pressing the hotkey again should reactivate the touchpad. + +### ECR008.001 Keyboard (function key: display on/off) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the display on/off hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the display on/off hotkey once and note the effect. +1. Press any key on the keyboard and note the effect. + +**Expected result** + +1. Pressing the hotkey once should turn the internal LCD panel off. +1. Pressing any key on the keyboard should power the internal LCD panel back on. + +### ECR008.002 Keyboard (function key: display on/off) in OS (Windows 11) + +**Test description** + +This test verifies that the display on/off hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the display on/off hotkey once and note the effect. +1. Press any key on the keyboard and note the effect. + +**Expected result** + +1. Pressing the hotkey once should turn the internal LCD panel off. +1. Pressing any key on the keyboard should power the internal LCD panel + back on. + +### ECR009.001 Keyboard (function key: mute) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the volume mute hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the volume mute hotkey twice and note the effect each keypress has. + +**Expected result** + +1. Pressing the hotkey should mute or unmute the currently enabled audio output. +1. Each keypress should cause a mute/unmute notification to appear in the middle + of the screen. + +### ECR009.002 Keyboard (function key: mute) in OS (Windows 11) + +**Test description** + +This test verifies that the mute hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the mute hotkey once and check the volume indicator in the bottom right + part of the screen. +1. Press the mute hotkey once and check the volume indicator again. + +**Expected result** + +1. Pressing the hotkey once should mute the device +1. Pressing the hotkey again should reenable the sound + +### ECR010.001 Keyboard (function key: keyboard backlight) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the keyboard backlight hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the keyboard backlight hotkey 6 times and note the effect on the + keyboard backlight after each keypress. + +**Expected result** + +1. The keyboard has 6 backlight settings from 0% to 100% Each keypress should + set the keyboard to the next mode, with the last mode wrapping back around + to the first. + +### ECR010.002 Keyboard (function key: keyboard backlight) in OS (Windows 11) + +**Test description** + +This test verifies that the keyboard backlight hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the keyboard backlight hotkey 6 times and note the effect on the + keyboard backlight after each keypress. + +**Expected result** + +1. The keyboard has 6 backlight settings from 0% to 100% Each keypress should + set the keyboard to the next mode, with the last mode wrapping back around + to the first. + +### ECR011.001 Keyboard (function key: volume down) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the volume down hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the volume down hotkey once and note the effects. + +**Expected result** + +1. Pressing the hotkey should decrease the volume of the currently enabled audio + output. +1. Each keypress should cause a volume down notification to appear in the middle + of the screen. + +### ECR011.002 Keyboard (function key: volume down) in OS (Windows 11) + +**Test description** + +This test verifies that the volume down hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the volume down hotkey once and note the effects. + +**Expected result** + +1. Pressing the hotkey should decrease the volume of the currently enabled audio + output. +1. Each keypress should cause a volume down notification to appear in the upper + left part of the screen. + +### ECR012.001 Keyboard (function key: volume up) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the volume up hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the volume up hotkey once and note the effects. + +**Expected result** + +1. Pressing the hotkey should increase the volume of the currently enabled audio + output. +1. Each keypress should cause a volume up notification to appear in the middle + of the screen. + +### ECR012.002 Keyboard (function key: volume up) in OS (Windows 11) + +**Test description** + +This test verifies that the volume up hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the volume down hotkey once and note the effects. + +**Expected result** + +1. Pressing the hotkey should increase the volume of the currently enabled audio + output. +1. Each keypress should cause a volume up notification to appear in the upper + left part of the screen. + +### ECR013.001 Keyboard (function key: display switch) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the display switch hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Install `libinput-tools` on the DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Run `sudo libinput debug-events --show-keycodes` in the terminal. +1. Press the display switch hotkey once and note the effect. + +**Expected result** + +1. Pressing the hotkey should yield the following output in the terminal: + + ```bash + -event3 KEYBOARD_KEY +0.000s KEY_LEFTMETA (125) pressed + event3 KEYBOARD_KEY +0.004s KEY_P (25) pressed + event3 KEYBOARD_KEY +0.010s KEY_P (25) released + event3 KEYBOARD_KEY +0.015s KEY_LEFTMETA (125) released + ``` + +### ECR013.002 Keyboard (function key: display switch) in OS (Windows 11) + +**Test description** + +This test verifies that the display switch hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the display switch hotkey once and note the effect. + +**Expected result** + +1. Pressing the hotkey should cause the display settings bar to appear + on the right part of the screen. + +### ECR014.001 Keyboard (function key: brightness down) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the brightness down hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test steps** + +1. Press the brightness down hotkey once and note the effects. + +**Expected result** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Pressing the hotkey should decrease the brightness of the internal LCD + display. +1. Each keypress should cause a brightness down notification to appear in the + middle of the screen. + +### ECR014.002 Keyboard (function key: brightness down) in OS (Windows 11) + +**Test description** + +This test verifies that the brightness down hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the brightness down hotkey once and note the effects. + +**Expected result** + +1. Pressing the hotkey should decrease the brightness of the internal LCD + display. +1. Each keypress should cause a brightness down notification to appear in the + top left of the screen. + +### ECR015.001 Keyboard (function key: brightness up) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the brightness up hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the brightness up hotkey once and note the effects. + +**Expected result** + +1. Pressing the hotkey should increase the brightness of the internal LCD + display. +1. Each keypress should cause a brightness up notification to appear in the + middle of the screen. + +### ECR015.002 Keyboard (function key: brightness up) in OS (Windows 11) + +**Test description** + +This test verifies that the brightness down hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the brightness up hotkey once and note the effects. + +**Expected result** + +1. Pressing the hotkey should increase the brightness of the internal LCD + display. +1. Each keypress should cause a brightness up notification to appear in the + top left of the screen. + +### ECR016.001 Keyboard (function key: camera on/off) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the camera on/off hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open the terminal and run the command: `watch -n1 lsusb`. +1. Press the camera on/off hotkey twice and note the effect after each + keypress. + +**Expected result** + +1. Pressing the hotkey once should make the + `Chicony Electronics Co., Ltd Chicony USB2.0 Camera` device disappear + from the output of `lsusb`. +1. Pressing the hotkey again should make the USB device reappear. + +### ECR016.002 Keyboard (function key: camera on/off) in OS (Windows 11) + +**Test description** + +This test verifies that the camera on/off hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open the `Camera` app. +1. Press the camera on/off hotkey twice and note the effect after + a few seconds after the keypress. + +**Expected result** + +1. Pressing the hotkey once should make the camera image to disappear. +1. Pressing the hotkey again should make camera image to appear again + after a few seconds. + +### ECR017.001 Keyboard (function key: flight mode) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the flight mode hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Locate and open the power menu in the upper right corner of the screen. +1. Enter Settings and navigate to the Wi-Fi panel. +1. Note the current state of the Airplane Mode switch. +1. Press the flight mode hotkey twice and note the result of each keypress. + +**Expected result** + +1. Pressing the hotkey once should enable airplane mode. +1. Pressing the hotkey again should disable airplane mode. + +### ECR017.002 Keyboard (function key: flight mode) in OS (Windows 11) + +**Test description** + +This test verifies that the flight mode hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the camera on/off hotkey twice and note the effect after the keypress. + +**Expected result** + +1. Pressing the hotkey once should enable airplane mode and cause + `airplane mode on` notification to appear in the top right + part of the screen. +1. Pressing the hotkey again should disable airplane mode and cause + `airplane mode off` notification to appear in the top right + part of the screen. + +### ECR018.001 Keyboard (function key: sleep) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the sleep hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the sleep hotkey once and note the result. +1. Look at the power LED located next to the AC adapter plug, towards the front + end of the laptop. + +**Expected result** + +1. The laptop should go to sleep within seconds of the hotkey being pressed. +1. The power LED should be blinking green, indicating the laptop is sleeping. + +### ECR018.002 Keyboard (function key: sleep) in OS (Windows 11) + +**Test description** + +This test verifies that the sleep hotkey works correctly. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the sleep hotkey once and note the result. +1. Look at the power LED located next to the AC adapter plug, towards the front + end of the laptop. + +**Expected result** + +1. The laptop should go to sleep within seconds of the hotkey being pressed. +1. The power LED should be blinking green, indicating the laptop is sleeping. + +### ECR019.001 Buttons (button: power) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the power button is detected correctly by the operating +system. In Ubuntu 20.04 OS the default function assigned to this key is suspend +mode. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open the terminal and run the following command to check the power button + action: + + ```bash + gsettings get org.gnome.settings-daemon.plugins.power power-button-action + ``` + +1. If the status is other than `suspend` run the following command to change + the power button action: + + ```bash + gsettings set org.gnome.settings-daemon.plugins.power power-button-action "suspend" + ``` + +1. Check the power button action again by running the following command: + + ```bash + gsettings get org.gnome.settings-daemon.plugins.power power-button-action + ``` + +1. Press the power button once and note the result. +1. Press `Enter` and note the result. +1. Run the following command to check last finished operation: + + ```bash + journalctl | grep systemd-logind | tail -1 + ``` + +**Expected result** + +1. Pressing the button once should make laptop enter sleep mode. +1. The power LED should be blinking green, indicating the laptop is sleeping. +1. After completing the 5th step device should wake up. +1. The output of the last command should contain the line: + + ```bash + Operation 'sleep' finished + ``` + +### ECR019.002 Buttons (button: power) in OS (Windows 11) + +**Test description** + +This test verifies that the power button is detected correctly by the operating +system. In Windows 11 OS the default function assigned to this key is sleep +mode. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Press the power button once and note the result. + +**Expected result** + +1. Pressing the button once should make laptop enter sleep mode. +1. The power LED should be blinking green, indicating the laptop is sleeping. + +### ECR020.001 Buttons (button: lid switch) in OS (Ubuntu 20.04) + +**Test description** + +This test verifies that the lid switch is detected correctly by the operating +system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open one terminal window and run the following command: + + ```bash + sudo systemd-inhibit --what handle-lid-switch --mode block watch echo "Inhibiting lid switch" + ``` + +1. Open another terminal and run the command + `sleep 5 && cat /proc/acpi/button/lid/LID0/state` to read the state of + the lid while it is closed. +1. Close the lid and wait 5 seconds. +1. Open the lid and note the output of the command. +1. Run the command `cat /proc/acpi/button/lid/LID0/state` while the lid is + open and note the output. + +**Expected result** + +1. The output of the second command should report that the lid is closed. +1. The output of the third command should report that the lid is open. + +### ECR020.002 Buttons (button: lid switch) in OS (Windows 11) + +**Test description** + +This test verifies that the lid switch is detected correctly by the operating +system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Close the lid and note the effect on the power LED. + +**Expected result** + +1. Pressing the button once should make laptop enter sleep mode. +1. The power LED should be blinking green, indicating the laptop is sleeping. diff --git a/docs/unified-test-documentation/dasharo-compatibility/31H-usb-type-c.md b/docs/unified-test-documentation/dasharo-compatibility/31H-usb-type-c.md new file mode 100644 index 00000000..24e7c373 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31H-usb-type-c.md @@ -0,0 +1,204 @@ +# Dasharo Compatibility: USB-C/Thunderbolt support with charging and display + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). + +### UTC001.001 USB Type-A charging capability + +**Test description** + +This test verifies that the USB-A ports are able to provide charging to a +connected smartphone. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Connect a phone to the USB Type-A port located on the left side of the laptop + using a USB cable. +1. Note the charging status on the phone screen. +1. Connect a phone to the USB Type-A port located on the right side of the laptop + using a USB cable. +1. Note the charging status on the phone screen. + +**Expected result** + +1. The smartphone should indicate that it's charging when connected to either + USB Type-A port. + +### UTC002.001 Thunderbolt 4 USB Type-C charging capability + +**Test description** + +This test verifies that the Thunderbolt 4 port is able to provide charging to +a connected smartphone. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Connect a phone to the Thunderbolt 4 USB Type-C port located on the left side + of the laptop using a USB cable. +1. Note the charging status on the phone screen. + +**Expected result** + +1. The smartphone should indicate that it's charging. + +### UTC003.001 USB Type-C PD laptop charging (Ubuntu 20.04) + +**Test description** + +This test verifies that the laptop can be charged using a USB Type-C PD power +supply connected to the Thunderbolt 4 port. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Connect the charger plug to the Thunderbolt 4 USB Type-C port located on the + left side of the laptop. +1. Observe the battery indicator located in the top right corner of the screen. + +**Expected result** + +1. The battery indicator should indicate that the laptop is currently charging. + +### UTC003.002 USB Type-C PD laptop charging (Windows 11) + +**Test description** + +This test verifies that the laptop can be charged using a USB Type-C PD power +supply connected to the Thunderbolt 4 port. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Connect the charger plug to the Thunderbolt 4 USB Type-C port located on the + left side of the laptop. +1. Observe the battery indicator located in the bottom right corner of the + screen. + +**Expected result** + +1. The battery indicator should indicate that the laptop is currently charging. + +### UTC004.001 USB Type-C Display output (Ubuntu 20.04) + +**Test description** + +This test verifies that the laptop can output video to a display connected via +the Thunderbolt 4 USB Type-C port. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Connect a display to the Thunderbolt 4 USB Type-C port located on the left + side of the laptop using the USB Type-C hub. +1. Open the Settings application and select the Displays panel in the left menu. +1. Verify that the attached external monitor can be selected. +1. Select and enable the monitor. + +**Expected result** + +1. The monitor connected to the laptop via the Thunderbolt 4 port should power + on and display video from the laptop. + +### UTC004.002 USB Type-C Display output (Windows 11) + +**Test description** + +This test verifies that the laptop can output video to a display connected via +the Thunderbolt 4 USB Type-C port. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Connect a display to the Thunderbolt 4 USB Type-C port located on the left. + side of the laptop using a USB Type-C hub. +1. Right click on the desktop to open the desktop context menu. +1. Select `Display Settings` to open the display settings window. +1. Verify that the attached external monitor can be selected. +1. Select and enable the monitor. + +**Expected result** + +1. The monitor connected to the laptop via the Thunderbolt 4 port should power + on and display video from the laptop. diff --git a/docs/unified-test-documentation/dasharo-compatibility/31I-nvme-switching.md b/docs/unified-test-documentation/dasharo-compatibility/31I-nvme-switching.md new file mode 100644 index 00000000..bab5c277 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31I-nvme-switching.md @@ -0,0 +1,68 @@ +# Dasharo Compatibility: M.2 automatic SATA/NVMe switching support + +## Test cases + +### MSS001.001 M.2 automatic SATA/NVMe switching support (Ubuntu 20.04) + +**Test description** + +This test aims to verify detection of the NVMe and SATA disk in M.2 hybrid slot +via the Operating System slot. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +2. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Insert a NVMe disk into the M.2 slot on the DUT. +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). + +**Test steps** + +1. Power on the DUT. +2. Boot into the system. +3. Log into system by using the proper login and password. +4. Open a terminal window and execute `sudo parted -l`. +5. Check if the connected disk is present on the list. +6. Power off the DUT. +7. Replace the NVMe disk with SATA M.2 disk. +8. Repeat steps 1-5. + +**Expected result** + +1. The NVMe M.2 disk is detected in OS: + + ```bash + Model: SAMSUNG MZVLB256HBHQ-00000 (nvme) + Disk /dev/nvme0n1: 256GB + Sector size (logical/physical): 512B/512B + Partition Table: gpt + Disk Flags: + + Number Start End Size File system Name Flags + 1 1049kB 2097kB 1049kB + 2 2097kB 540MB 538MB fat32 EFI System Partition boot, esp + 3 540MB 67,6GB 67,1GB ext4 + 6 67,6GB 126GB 57,9GB ext4 + 4 126GB 193GB 67,7GB ext4 + 5 193GB 256GB 62,9GB ext4 + ``` + +2. The SATA M.2 disk is detected in OS: + + ```bash + Model: ATA Hoodisk SSD (scsi) + Disk /dev/sda: 32,0GB + Sector size (logical/physical): 512B/512B + Partition Table: gpt + Disk Flags: + + Number Start End Size File system Name Flags + 1 1049kB 538MB 537MB fat32 EFI System Partition boot, esp + 2 538MB 32,0GB 31,5GB ext4 + ``` diff --git a/docs/unified-test-documentation/dasharo-compatibility/31J-sleep-mode.md b/docs/unified-test-documentation/dasharo-compatibility/31J-sleep-mode.md new file mode 100644 index 00000000..11cc782d --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31J-sleep-mode.md @@ -0,0 +1,108 @@ +# Dasharo Compatibility: Sleep mode + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). + +### SLM001.001 Sleep mode - battery monitoring (Ubuntu 20.04) + +**Test description** + +This test verifies how quickly the battery discharges while in sleep mode in +the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Charge the battery fully (note: due to the manufacturer's settings the + maximum battery charge level is limited to 90%; also, the battery charging + process can only be started if the current battery level is less than 80%). +1. Disconnect the power supply. +1. Close the lid. +1. Wake up the DUT in the following timestamps and note the battery level: + * 1 hour from fully charging, + * 2 hours from fully charging, + * 3 hours from fully charging, + * 6 hours from fully charging, + * (optional) 24 hours from fully charging. + +**Expected result** + +1. The battery should discharge at a similar rate as in the table below (take + the battery wear into account). + +| Time | Battery level | +| :------------: |:----------------:| +| 0h | 90% | +| 1h | 88% | +| 2h | 86% | +| 3h | 84% | +| 6h | 80% | +| 24h (optional) | 57% | + +### SLM000.002 Sleep mode - battery monitoring (Windows 11) + +**Test description** + +This test verifies how quickly the battery discharges while in sleep mode in +the OS. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Charge the battery fully (note: due to the manufacturer's settings the + maximum battery charge level is limited to 90%; also, the battery charging + process can only be started if the current battery level is less than 80%). +1. Disconnect the power supply. +1. Close the lid. +1. Wake up the DUT in the following timestamps and note the battery level: + * 1 hour from fully charging, + * 2 hours from fully charging, + * 3 hours from fully charging, + * 6 hours from fully charging, + +**Expected result** + +1. The battery should discharge at a similar rate as in the table below (take + the battery wear into account). + +| Time | Battery level | +| :------------: |:----------------:| +| 0h | 90% | +| 1h | 79% | +| 2h | 69% | +| 3h | 58% | +| 6h | 26% | diff --git a/docs/unified-test-documentation/dasharo-compatibility/31K-minipcie-verification.md b/docs/unified-test-documentation/dasharo-compatibility/31K-minipcie-verification.md new file mode 100644 index 00000000..8a6ccd7e --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31K-minipcie-verification.md @@ -0,0 +1,300 @@ +# Dasharo Compatibility: miniPCIe slot verification + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). + +### MWL001.001 Wireless card detection (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the Wi-Fi/Bluetooth card is enumerated correctly +and can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following command: + +```bash +lspci | grep Network controller +``` + +**Expected result** + +The output of the command should contain the line: + +```bash +2f:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) +``` + +The exact name and revision may be different depending on hardware +configuration. + +### MWL001.002 Wireless card detection (Windows 11) + +**Test description** + +This test aims to verify that the Wi-Fi/Bluetooth card is enumerated correctly +and can be detected from the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open PowerShell and execute following command: + +```bash +Get-PnpDevice -PresentOnly | Select-String -Pattern "Wi-Fi" +``` + +1. Note the result. + +**Expected result** + +The output of the command should contain a line starting with: + +```bash +Intel(R) Wi-Fi 6AX200 160MHz +``` + +or a line starting with: + +```bash +Intel(R) Wi-Fi 6AX201 160MHz +``` + +### MWL002.001 Wi-Fi scanning (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the Wi-Fi functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Make sure to have any Wi-Fi signal available. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following commands as root: + +```bash +nmcli radio wifi on +nmcli device wifi rescan +# Wait ~5 seconds +nmcli device wifi list +``` + +**Expected result** + +The output of the last command should return a list of available Wi-Fi networks, +for example: + +```bash +IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY + 36:78:EE:05:03:45 DIRECT-ny Infra 6 65 Mbit/s 75 ▂▄▆_ WPA2 +* 60:38:E0:D6:46:9A 3mdeb_abr_5GHz Infra 48 405 Mbit/s 72 ▂▄▆_ WPA2 + 60:38:E0:D6:46:99 3mdeb_abr Infra 11 54 Mbit/s 69 ▂▄▆_ WPA2 + D8:D7:75:02:F9:BF FunBox2-F9BF_2.4GHz Infra 1 130 Mbit/s 50 ▂▄__ WPA1 WPA2 + 30:5A:3A:A1:46:B0 H_Office Infra 2 270 Mbit/s 35 ▂▄__ WPA2 + 9E:93:4E:74:C0:3F DIRECT-xpPhaser 3330 Infra 1 65 Mbit/s 34 ▂▄__ WPA2 + D8:A7:56:D9:A7:9F Orange_Swiatlowod_A79A Infra 108 540 Mbit/s 32 ▂▄__ WPA2 + 86:25:19:05:D4:A0 DIRECT-KRM288x Series Infra 11 54 Mbit/s 22 ▂___ WPA2 + D8:A7:56:D9:A7:9A Orange_Swiatlowod_A79A Infra 11 130 Mbit/s 20 ▂___ WPA2 + 9E:93:4E:74:C0:57 DIRECT-ejPhaser 3330 Infra 1 65 Mbit/s 17 ▂___ WPA2 + B0:BE:76:06:9F:22 NED-WIFI Infra 11 270 Mbit/s 17 ▂___ WPA2 +``` + +### MWL002.002 Wi-Fi scanning (Windows 11) + +**Test description** + +This test aims to verify that the Wi-Fi functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Make sure to have any Wi-Fi signal available + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Locate in the bottom right corner of the screen `Internet access` + icon and click it. +1. Enable Wi-Fi and note the result. + +**Expected result** + +After enabling Wi-Fi available networks should appear +in the `Internet access` menu. + +### MWL003.001 Bluetooth scanning (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the Bluetooth functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Enable Bluetooth and make it discoverable in any device nearby DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following commands: + +```bash +bluetoothctl +power on +scan on +# Wait ~5 seconds +devices +``` + +**Expected result** + +The output of the last command should return a list of detectable Bluetooth +devices, for example: + +```bash +Device 48:24:57:E0:61:74 48-24-57-E0-61-74 +Device 88:BD:45:74:FA:A5 Wojtek N +Device CE:9E:7B:BF:69:F2 Mi Smart Band 4 +Device 56:62:93:8B:1A:F9 Galaxy Watch4 Classic (PHLM) +Device 64:F2:FD:1E:26:BC Galaxy Watch4 Classic (PHLM) +Device 0F:18:A1:D9:23:F6 0F-18-A1-D9-23-F6 +Device 8C:EA:48:B1:59:B3 [Signage] Samsung QMR Series +Device 8C:EA:48:B1:57:EB [Signage] Samsung QMR Series +Device 76:C7:FD:86:9B:0E 76-C7-FD-86-9B-0E +Device 40:5E:96:43:3A:6A 40-5E-96-43-3A-6A +Device 4C:58:3B:C1:37:90 4C-58-3B-C1-37-90 +Device 6A:93:A2:6A:E5:20 6A-93-A2-6A-E5-20 +``` + +### MWL003.002 Bluetooth scanning (Windows 11) + +**Test description** + +This test aims to verify that the Bluetooth functionality of card is initialized +correctly and can be used from within the operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Windows 11 + +**Test setup** + +1. Proceed with the [Common](#common) section. +1. Enable Bluetooth and make it discoverable in any device nearby DUT + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Enter `Notification Center` in the bottom right part of the screen. +1. Using right mouse button click on the Bluetooth icon. +1. In shown drop-down menu click `Go to settings`. +1. Click the `+` icon described as `Add Bluetooth or other device`. +1. In the `Add a device` menu click `Bluetooth`. +1. Wait a few moments until DUT scans for nearby Bluetooth devices and note + the result. + +**Expected result** + +Available Bluetooth devices should appear in the `Add a device` window. + +### MWL004.001 LTE card detection (Ubuntu 20.04) + +**Test description** + +This test aims to verify that the LTE card is detected correctly in the +operating system. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +2. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. +2. Plug the LTE card into miniPCIe slot. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute `lsusb` + +**Expected result** + +The output of the command should return a list of USB devices including LTE +module, for example: + +```bash +Bus 001 Device 004: ID 05c6:9215 Qualcomm, Inc. Quectel EC20 LTE modem +``` + + diff --git a/docs/unified-test-documentation/dasharo-compatibility/31L-smbios.md b/docs/unified-test-documentation/dasharo-compatibility/31L-smbios.md new file mode 100644 index 00000000..0714e933 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31L-smbios.md @@ -0,0 +1,288 @@ +# Dasharo compatibility: SMBIOS + +## Test cases + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup#os-boot-from-disk). +1. Install the `dmidecode` package: `sudo apt-get install dmidecode`. + +### DMI001.001 Verify the serial number + +**Test description** + +This test aims to verify that the serial number field is filled in correctly +according to the +[Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t system + ``` + +1. In the `BIOS Information` section, check the `Serial number` field against the + [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The fields should be filled in according to the Dasharo SMBIOS guidelines. + +### DMI002.001 Verify the firmware version + +**Test description** + +This test aims to verify that the firmware version field is filled in correctly +according to the +[Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t bios + ``` + +1. In the `BIOS Information` section, check the `Version` field against the + [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The fields should be filled in according to the Dasharo SMBIOS guidelines. + +### DMI003.001 Verify the firmware product name + +**Test description** + +This test aims to verify that the firmware product name fields are filled in +correctly according to the +[Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t system + ``` + +1. In the `System Information` section, check the `Product Name` field against + the [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). +1. Execute the following command in the terminal: + + ```bash + dmidecode -t baseboard + ``` + +1. In the `Base Board Information` section, check the `Product Name` field + against the [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The fields should be filled in according to the Dasharo SMBIOS guidelines. + +### DMI004.001 Verify the firmware release date + +**Test description** + +This test aims to verify that the firmware release date field are filled in +correctly according to the +[Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t bios + ``` + +1. In the `System Information` section, check the `Release Date` field + against the + [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The field should be filled in according to the Dasharo SMBIOS guidelines. + +### DMI005.001 Verify the firmware manufacturer + +**Test description** + +This test aims to verify that the firmware manufacturer fields are filled in +correctly according to the +[Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t system + ``` + +1. In the `System Information` section, check the `Manufacturer` field against + the [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). +1. Execute the following command in the terminal: + + ```bash + dmidecode -t baseboard + ``` + +1. In the `Base Board Information` section, check the `Manufacturer` field + against the + [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The fields should be filled in according to the Dasharo SMBIOS guidelines. + +### DMI006.001 Verify the firmware vendor + +**Test description** + +This test aims to verify that the firmware vendor field is filled in correctly +according to the +[Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t bios + ``` + +1. In the `BIOS Information` section, check the `Vendor` field against the + [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The field should be filled in according to the Dasharo SMBIOS guidelines. + +### DMI007.001 Verify the firmware family + +**Test description** + +This test aims to verify that the firmware family field is filled in correctly +according to the +[Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t system + ``` + +1. In the `System Information` section, check the `Family` field against the + [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The field should be filled in according to the Dasharo SMBIOS guidelines. + +### DMI008.001 Verify the firmware type + +**Test description** + +This test aims to verify that the firmware type field is filled in correctly +according to the [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + + ```bash + dmidecode -t chassis + ``` + +1. In the `Chassis Information` section, check the `Type` field against the + [Dasharo SMBIOS guidelines](https://docs.dasharo.com/dev-proc/smbios-rules/). + +**Expected result** + +1. The field should be filled in according to the Dasharo SMBIOS guidelines. diff --git a/docs/unified-test-documentation/dasharo-compatibility/31M-emmc-support.md b/docs/unified-test-documentation/dasharo-compatibility/31M-emmc-support.md new file mode 100644 index 00000000..419efb8d --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31M-emmc-support.md @@ -0,0 +1,47 @@ +# Dasharo Compatibility: eMMC support + +## Test cases + +### MMC001.001 eMMC support (Ubuntu 20.04) + +**Test description** + +This test aims to verify detection of the eMMC driver via the Operating System. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +2. `OPERATING_SYSTEM` = Ubuntu 20.04 + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). +2. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup#os-installer). + +**Test steps** + +1. Power on the DUT. +2. Boot into the system. +3. Log into system by using the proper login and password. +4. Open a terminal window and execute `sudo parted -l`. +5. Check if the eMMC is present on the list. + +**Expected result** + +1. The eMMC disk is detected in OS: + + ```bash + Model: MMC 8GTF4R (sd/mmc) + Disk /dev/mmcblk0: 7818MB + Sector size (logical/physical): 512B/512B + Partition Table: msdos + Disk Flags: + + Number Start End Size Type File system Flags + 1 1049kB 538MB 537MB primary fat32 + 2 538MB 1076MB 538MB primary fat32 boot, esp + 3 1077MB 7817MB 6740MB extended + 5 1077MB 7817MB 6740MB logical ext4 + ``` diff --git a/docs/unified-test-documentation/dasharo-compatibility/31M-platform-suspend-and-resume.md b/docs/unified-test-documentation/dasharo-compatibility/31M-platform-suspend-and-resume.md new file mode 100644 index 00000000..dc66be26 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31M-platform-suspend-and-resume.md @@ -0,0 +1,62 @@ +# Dasharo Compatibility: Platform suspend and resume + +## Test cases + +### SUSP001.001 Platform suspend and resume + +**Test description** + +This test verifies whether the DUT might be put into suspend mode and then, by +using the power button, might be properly resumed. This test case may be +re-done several times to specify the platform stability. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup#firmware). + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open a terminal window and execute the following command: + + ```bash + date + ``` + +1. Write down the output of the above-mentioned command. +1. Execute the following command in the terminal: + + ```bash + systemctl suspend -i + ``` + +1. Check the status of the platform. +1. Press the power button once and note the result. +1. Execute the following command in the terminal: + + ```bash + journalctl | grep suspend + ``` + +**Expected result** + +1. After running suspend command the platform should enter the suspend mode. +1. After pressing power button the platform should initiate the resume + procedure. +1. Output of the last command should contains the line with the following + statement: + + ```bash + systemd-suspend.service: Succeeded + ``` + +1. Date of the above-described event should be later than date from + command `date` from the test steps' fourth point. diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/usb-boot.md b/docs/unified-test-documentation/dasharo-compatibility/31N-usb-boot.md similarity index 60% rename from docs/variants/asus_kgpe_d16/dasharo-compatibility/usb-boot.md rename to docs/unified-test-documentation/dasharo-compatibility/31N-usb-boot.md index 85a50505..15c67915 100644 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/usb-boot.md +++ b/docs/unified-test-documentation/dasharo-compatibility/31N-usb-boot.md @@ -6,20 +6,20 @@ **Test description** -This test aims to verify that the DUT properly detects USB device and boots into -the operating system after coldboot (reboot realized by power supply cutting off -then restoring back). This test case may be re-done several times to specify the -platform and connection stability. +This test aims to verify that the DUT properly detects USB device and boots +into the operating system after coldboot (reboot realized by power supply +cutting off then restoring back). This test case may be re-done several times +to specify the platform and connection stability. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -36,24 +36,24 @@ platform and connection stability. The `Debian GNU/Linux` is visible and confirms successful boot into OS after coldboot. -### UBB001.002 USB detect and boot after warmboot +### UBB002.001 USB detect and boot after warmboot **Test description** -This test aims to verify that the DUT properly detects USB device and boots into -the operating system after warmboot (reboot realized by device turning off then -turning on). This test case may be re-done several times to specify the platform -and connection stability. +This test aims to verify that the DUT properly detects USB device and boots +into the operating system after warmboot (reboot realized by device turning +off then turning on). This test case may be re-done several times to specify +the platform and connection stability. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -69,24 +69,24 @@ and connection stability. The `Debian GNU/Linux` is visible and confirms successful boot into OS after warmboot. -### UBB001.003 USB detect and boot after system reboot +### UBB003.001 USB detect and boot after system reboot **Test description** -This test aims to verify that the DUT properly detects USB device and boots into -the operating system after system reboot (reboot performed by relevant command). -This test case may be re-done several times to specify the platform and -connection stability. +This test aims to verify that the DUT properly detects USB device and boots +into the operating system after system reboot (reboot performed by relevant +command). This test case may be re-done several times to specify the +platform and connection stability. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/usb-detect.md b/docs/unified-test-documentation/dasharo-compatibility/31O-usb-detect.md similarity index 74% rename from docs/variants/asus_kgpe_d16/dasharo-compatibility/usb-detect.md rename to docs/unified-test-documentation/dasharo-compatibility/31O-usb-detect.md index 362207f1..e26a2f65 100644 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/usb-detect.md +++ b/docs/unified-test-documentation/dasharo-compatibility/31O-usb-detect.md @@ -7,19 +7,19 @@ **Test description** This test aims to verify that the DUT properly detects USB device after -coldboot (reboot realized by power supply cutting off then restoring back). This -test case may be re-done several times to specify the platform and connection -stability. +coldboot (reboot realized by power supply cutting off then restoring back). +This test case may be re-done several times to specify the platform and +connection stability. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -34,7 +34,7 @@ stability. The `USB_STICK` entry is visible which confirms successful detection after coldboot. -### USB001.002 USB detect and boot after warmboot +### USB002.001 USB detect and boot after warmboot **Test description** @@ -44,13 +44,13 @@ may be re-done several times to specify the platform and connection stability. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** @@ -64,7 +64,7 @@ may be re-done several times to specify the platform and connection stability. The `USB_STICK` entry is visible which confirms successful detection after warmboot. -### USB001.003 USB detect and boot after system reboot +### USB003.001 USB detect and boot after system reboot **Test description** @@ -74,13 +74,13 @@ several times to specify the platform and connection stability. **Test configuration data** -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` **Test setup** -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). **Test steps** diff --git a/docs/unified-test-documentation/dasharo-compatibility/31P-flash-write-protection.md b/docs/unified-test-documentation/dasharo-compatibility/31P-flash-write-protection.md new file mode 100644 index 00000000..f6e320e1 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/31P-flash-write-protection.md @@ -0,0 +1,160 @@ +# Dasharo Security: Flash write protection + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Make yourself familiar with + [SPI hardware write protection](../../../variants/asus_kgpe_d16/spi-wp/). + +### HWP001.001 Hardware flash write protection support + +**Test description** + +This test aims to verify whether the DUT supports hardware write protection +mechanism. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + +```bash +sudo ./flashrom -p internal --wp-list +``` + +**Expected result** + +The output of the command should contain the information about lst of +available write protection ranges, exmaple has been shown below: + +```bash +Available write protection ranges: + start=0x00000000 length=0x00000000 (none) + start=0x00000000 length=0x00001000 (lower 1/2048) + start=0x007ff000 length=0x00001000 (upper 1/2048) + start=0x00000000 length=0x00002000 (lower 1/1024) + start=0x007fe000 length=0x00002000 (upper 1/1024) + start=0x00000000 length=0x00004000 (lower 1/512) + start=0x007fc000 length=0x00004000 (upper 1/512) + start=0x00000000 length=0x00008000 (lower 1/256) + start=0x007f8000 length=0x00008000 (upper 1/256) + start=0x00000000 length=0x00020000 (lower 1/64) + start=0x007e0000 length=0x00020000 (upper 1/64) + start=0x00000000 length=0x00040000 (lower 1/32) + start=0x007c0000 length=0x00040000 (upper 1/32) + start=0x00000000 length=0x00080000 (lower 1/16) + start=0x00780000 length=0x00080000 (upper 1/16) + start=0x00000000 length=0x00100000 (lower 1/8) + start=0x00700000 length=0x00100000 (upper 1/8) + start=0x00000000 length=0x00200000 (lower 1/4) + start=0x00600000 length=0x00200000 (upper 1/4) + start=0x00000000 length=0x00400000 (lower 1/2) + start=0x00400000 length=0x00400000 (upper 1/2) + start=0x00000000 length=0x00600000 (lower 3/4) + start=0x00200000 length=0x00600000 (upper 3/4) + start=0x00000000 length=0x00700000 (lower 7/8) + start=0x00100000 length=0x00700000 (upper 7/8) + start=0x00000000 length=0x00780000 (lower 15/16) + start=0x00080000 length=0x00780000 (upper 15/16) + start=0x00000000 length=0x007c0000 (lower 31/32) + start=0x00040000 length=0x007c0000 (upper 31/32) + start=0x00000000 length=0x007e0000 (lower 63/64) + start=0x00020000 length=0x007e0000 (upper 63/64) + start=0x00000000 length=0x007f8000 (lower 255/256) + start=0x00008000 length=0x007f8000 (upper 255/256) + start=0x00000000 length=0x007fc000 (lower 511/512) + start=0x00004000 length=0x007fc000 (upper 511/512) + start=0x00000000 length=0x007fe000 (lower 1023/1024) + start=0x00002000 length=0x007fe000 (upper 1023/1024) + start=0x00000000 length=0x007ff000 (lower 2047/2048) + start=0x00001000 length=0x007ff000 (upper 2047/2048) + start=0x00000000 length=0x00800000 (all) +``` + +### HWP002.001 Hardware flash write protection enable / disable + +**Test description** + +This test aims to verify whether there is a possibility to set and erase +hardware write protection on the DUT. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Based on [the documentation](../../../variants/asus_kgpe_d16/spi-wp/) + erase current write protection. +1. Based on [the documentation](../../../variants/asus_kgpe_d16/spi-wp/) + set write protection for a specific range. +1. Execute the following command in the terminal to check the status and the + range of write protection: + + ```bash + sudo ./flashrom -p internal --wp-status + ``` + +**Expected result** + +1. The output of the command should contain the information about protection + mode: + + ```bash + Protection mode: hardware + ``` + +1. Protection range: read from the command output and set before should be the + same. + +### CBMEM003.001 Serial boot measure: coreboot booting time after system reboot + +**Test description** + +This test aims to verify whether the DUT boots after system reboot and how long +this process takes. This test case may be re-done several times to to average +the results and specify the platform stability. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + +```bash +sudo ./cbmem -T +``` + +**Expected result** + +The output of the command should contain the information about duration of +all boot stages. diff --git a/docs/unified-test-documentation/dasharo-compatibility/S30-fan-control.md b/docs/unified-test-documentation/dasharo-compatibility/S30-fan-control.md new file mode 100644 index 00000000..9cae4a55 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/S30-fan-control.md @@ -0,0 +1,112 @@ +# Dasharo Compatibility: custom fan curve + +## Test cases + +### FAN001.001 Custom fan curve: CPU fan + +**Test description** + +The fan has been configured to follow a custom curve. This test aims to verify +that the fan curve is configured correctly and the fan spins up and down +according to the defined values. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). +1. Install `lm-sensors` and `stress-ng` on the DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open the terminal window and execute the following command: + +```bash +sensors | grep 'Package id 0' +``` + +1. Verify using `sensors` that the temperature is below 40°C +1. If the temperature is above 40, enable fan turbo mode (Fn + 1) until it cools + down +1. Flip the laptop over and check if the CPU fan (located under the Backspace + key) is spinning +1. In the terminal window, run following command: + +```bash +stress-ng -c 8 +``` + +1. Verify using `sensors` that the temperature increases above 40 +1. Flip the laptop over and check if the CPU fan is spinning + +**Expected result** + +1. The fan should not be spinning while the temperature is below 40 degrees +1. The fan should be spinning while the temperature is above 40 degrees + +### FAN002.001 Custom fan curve: GPU fan (NV41MB) + +**Test description** + +The fan has been configured to follow a custom curve. This test aims to verify +that the fan curve is configured correctly and the fan spins up and down +according to the defined values. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `BOOT_MENU_KEY` = `F7` + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). +1. Install `nvidia-smi` and `mesa-utils` on the DUT. + +**Test steps** + +1. Power on the DUT. +1. Boot into the system. +1. Log into system by using the proper login and password. +1. Open the terminal window and execute the following command: + +```bash +watch -n1 nvidia-smi +``` + +1. Verify using that the temperature is below 40°C +1. If the temperature is above 40, enable fan turbo mode (Fn + 1) until it cools + down +1. Flip the laptop over and check if the GPU fan (located under the Escape + key) is spinning +1. In another terminal window, run following command: + +```bash +_NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __GL_SYNC_TO_VBLANK=0 glxgears +``` + +1. Verify that the temperature increases above 40 +1. Flip the laptop over and check if the GPU fan is spinning + +**Expected result** + +1. The fan should not be spinning while the temperature is below 40 degrees +1. The fan should be spinning while the temperature is above 40 degrees diff --git a/docs/unified-test-documentation/dasharo-compatibility/S31-coreboot-fan-control.md b/docs/unified-test-documentation/dasharo-compatibility/S31-coreboot-fan-control.md new file mode 100644 index 00000000..5b4d3494 --- /dev/null +++ b/docs/unified-test-documentation/dasharo-compatibility/S31-coreboot-fan-control.md @@ -0,0 +1,91 @@ +# Dasharo Compatibility: coreboot Fan Control + +## Test cases + +### FAN001.001 Check CPU entry temperature and CPU fan speed + +**Test description** + +This test aims to verify that data for CPU temperature and CPU fan speed is +available. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). + +**Test steps** + +1. Power on the DUT. +1. Wait for boot until `BOOT_MENU_STRING` appears. +1. Press `BOOT_MENU_KEY` to enter the boot menu. +1. Select the proper number for `USB_STICK` option. +1. Wait for `debian login:`. +1. Type proper login. +1. Wait for `Password:`. +1. Type the proper password. +1. Wait for `root@debian:~#`. +1. Execute `watch -n 1 "sensors w83795g-i2c-1-2f |grep fan1 -A 16"`. + +**Expected result** + +There are visible data for `fan1` and `temp7` which represents CPU fan speed and +CPU temperature. + +### FAN001.002 Check if increasing CPU temperature increases CPU fan speed + +**Test description** + +This test aims to verify that CPU fan speed responds properly to increasing CPU +temperature. + +**Test configuration data** + +1. `FIRMWARE` = coreboot + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Proceed with the + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). + +**Test steps** + +1. Power on the DUT. +1. Wait for boot until `BOOT_MENU_STRING` appears. +1. Press `BOOT_MENU_KEY` to enter the boot menu. +1. Select the proper number for `USB_STICK` option. +1. Wait for `debian login:`. +1. Type proper login. +1. Wait for `Password:`. +1. Type the proper password. +1. Wait for `root@debian:~#`. +1. Install `stress-ng` package by executing: `sudo apt install stress-ng`. +1. Confirm installation by typing `Y` and pressing `Enter` when asked. +1. Execute command: `watch -n 1 "sensors w83795g-i2c-1-2f |grep fan1 -A 16"` + and check current CPU temperature and CPU fan speed. +1. Execute command: + `stress-ng --cpu 16 --io 8 --vm 4 --vm-bytes 4G --timeout 30s --metrics`. +1. Wait 2 minutes. +1. Execute command: `watch -n 1 "sensors w83795g-i2c-1-2f |grep fan1 -A 16"` + and check current CPU temperature and CPU fan speed. + +**Expected result** + +1. The CPU temperature after the second check is higher at least 20 degrees. +1. The CPU fan speed after the second check is higher at least 1000 RPM. diff --git a/docs/unified-test-documentation/dasharo-performance/400-coreboot-boot-measure.md b/docs/unified-test-documentation/dasharo-performance/400-coreboot-boot-measure.md new file mode 100644 index 00000000..fd85dbec --- /dev/null +++ b/docs/unified-test-documentation/dasharo-performance/400-coreboot-boot-measure.md @@ -0,0 +1,106 @@ +# Dasharo Performance: coreboot boot measure + +## Test cases + +### Common + +**Test setup** + +1. Proceed with the + [Generic test setup: firmware](../../generic-test-setup/#firmware). +1. Proceed with the + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). +1. Proceed with the + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). +1. Download `cbmem` from + to the DUT. + +### CBMEM001.001 Serial boot measure: coreboot booting time after coldboot + +**Test description** + +This test aims to verify whether the DUT boots after coldboot and how long this +process takes. This test case may be re-done several times to to average the +results and specify the platform stability. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + +```bash +sudo ./cbmem -T +``` + +**Expected result** + +The output of the command should contain the information about duration of +all boot stages. + +### CBMEM002.001 Serial boot measure: coreboot booting time after warmboot + +**Test description** + +This test aims to verify whether the DUT boots after warmboot and how long this +process takes. This test case may be re-done several times to to average the +results and specify the platform stability. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + +```bash +sudo ./cbmem -T +``` + +**Expected result** + +The output of the command should contain the information about duration of +all boot stages. + +### CBMEM003.001 Serial boot measure: coreboot booting time after system reboot + +**Test description** + +This test aims to verify whether the DUT boots after system reboot and how long +this process takes. This test case may be re-done several times to to average +the results and specify the platform stability. + +**Test configuration data** + +1. `FIRMWARE` = coreboot +1. `OPERATING_SYSTEM` = `Debian 11.0` + +**Test setup** + +1. Proceed with the [Common](#common) section. + +**Test steps** + +1. Open a terminal window and execute the following command: + +```bash +sudo ./cbmem -T +``` + +**Expected result** + +The output of the command should contain the information about duration of +all boot stages. diff --git a/docs/unified-test-documentation/dasharo-security/201-verified-boot.md b/docs/unified-test-documentation/dasharo-security/201-verified-boot.md index 6a3ab0d8..42d83a12 100644 --- a/docs/unified-test-documentation/dasharo-security/201-verified-boot.md +++ b/docs/unified-test-documentation/dasharo-security/201-verified-boot.md @@ -13,7 +13,7 @@ functional. **Test setup** 1. Proceed with the - [Generic test setup: firmware](../dasharo-compatibility/generic-test-setup.md#firmware). + [Generic test setup: firmware](../../generic-test-setup/#firmware). 1. Disable Secure Boot. **Test steps** @@ -45,13 +45,13 @@ functional. **Test setup** 1. Proceed with the - [Generic test setup: firmware](../../dasharo-compatibility/generic-test-setup/#firmware). + [Generic test setup: firmware](../../generic-test-setup/#firmware). 1. Proceed with the - [Generic test setup: OS installer](../../dasharo-compatibility/generic-test-setup/#os-installer). + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). 1. Proceed with the - [Generic test setup: OS installation](../../dasharo-compatibility/generic-test-setup/#os-installation). + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). 1. Proceed with the - [Generic test setup: OS boot from disk](../../dasharo-compatibility/generic-test-setup/#os-boot-from-disk). + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). 1. Download `cbmem` and `flashrom` from to the DUT. 1. Disable Secure Boot. @@ -91,7 +91,7 @@ proceed to boot from Slot A. **Test setup** 1. Proceed with the - [Generic test setup: firmware](../dasharo-compatibility/generic-test-setup.md#firmware). + [Generic test setup: firmware](../../generic-test-setup/#firmware). 1. Disable Secure Boot. **Test steps** @@ -122,13 +122,13 @@ proceed to boot from Slot A. **Test setup** 1. Proceed with the - [Generic test setup: firmware](../../dasharo-compatibility/generic-test-setup/#firmware) + [Generic test setup: firmware](../../generic-test-setup/#firmware). 1. Proceed with the - [Generic test setup: OS installer](../../dasharo-compatibility/generic-test-setup/#os-installer) + [Generic test setup: OS installer](../../generic-test-setup/#os-installer). 1. Proceed with the - [Generic test setup: OS installation](../../dasharo-compatibility/generic-test-setup/#os-installation) + [Generic test setup: OS installation](../../generic-test-setup/#os-installation). 1. Proceed with the - [Generic test setup: OS boot from disk](../../dasharo-compatibility/generic-test-setup/#os-boot-from-disk) + [Generic test setup: OS boot from disk](../../generic-test-setup/#os-boot-from-disk). 1. Download `cbmem` and `flashrom` from to the DUT. 1. Disable Secure Boot. diff --git a/docs/unified-test-documentation/dasharo-security/206-secure-boot.md b/docs/unified-test-documentation/dasharo-security/206-secure-boot.md index be7e2d88..8bbcf75b 100644 --- a/docs/unified-test-documentation/dasharo-security/206-secure-boot.md +++ b/docs/unified-test-documentation/dasharo-security/206-secure-boot.md @@ -51,7 +51,7 @@ The output of the command should contain the line: secureboot: Secure boot enabled ``` -### SBO001.002 UEFI Secure Boot (Windows 10) +### SBO001.002 UEFI Secure Boot (Windows 11) **Test description** @@ -62,7 +62,7 @@ Tianocore and, after the DUT reset, it is seen from the OS. **Test configuration data** 1. `FIRMWARE` = coreboot -1. `OPERATING_SYSTEM` = Windows 10 +1. `OPERATING_SYSTEM` = Windows 11 **Test setup** diff --git a/docs/unified-test-documentation/generic-test-setup.md b/docs/unified-test-documentation/generic-test-setup.md index 71f00547..ee9dadd8 100644 --- a/docs/unified-test-documentation/generic-test-setup.md +++ b/docs/unified-test-documentation/generic-test-setup.md @@ -1,4 +1,4 @@ -# Dasharo Compatibility: generic test setup +# Dasharo Compatibility: Generic test setup ## Test setup @@ -16,7 +16,7 @@ need to execute the setup actions before each independent case. 1. or you can build one yourself as shown in the `building` document dedicated for platform which is used by you. 1. Flash `FIRMWARE` binary to the DUT. Device flashing procedure should be - carried out in accordance with the guidelines in `Flashing` doucment + carried out in accordance with the guidelines in `Flashing` doucment dedicated for platform which is in use. #### OS installer diff --git a/docs/unified-test-documentation/overview.md b/docs/unified-test-documentation/overview.md new file mode 100644 index 00000000..e4261dc0 --- /dev/null +++ b/docs/unified-test-documentation/overview.md @@ -0,0 +1,41 @@ +# Dasharo Test Specifiaction - overview + +The release procedure is always preceded by validation procedure. It is done +on the basis of the test documentation, which can be found in this submenu. +To properly use the documentation, it is advisable to read the following +brief description of its components. + +## Test Matrix + +Test Matrix is the document which shows platform-dedicated test suites and +test cases. Based on it, the customer may scope the checks performed by the +validation team each time before firmware release. + +## Generic test setup + +Generic test setup is the document which describes all the steps that are +performed before testing the various functionalities. + +## Dasharo modules + +Tests preformed during validation procedure can be divided into test modules, +test suites and test cases. + +Test cases are the smallest component of validation procedure. Their task +is to check, that the given functionallity works properly under a certain +conditions. + +Test suites group test cases related to the given functionality, while +test modules groups test cases related to the similar functionalities +(i. e. test suites which task is to check if differently OS boot properly +on the platform). + +Currently in Dasharo test specification the following test modules can +be distinguished: + +* `Dasharo Compatibility` which contains test suites related to the basic + functionailited of the device. +* `Dasharo Security` which contains test suites related to the platform + security and supporting security modules. +* `Dasharo Performance` which contains test suites related to the platform + booting performance. diff --git a/docs/unified-test-documentation/test-matrix.md b/docs/unified-test-documentation/test-matrix.md new file mode 100644 index 00000000..a7066946 --- /dev/null +++ b/docs/unified-test-documentation/test-matrix.md @@ -0,0 +1,183 @@ +# Test matrix + +## About + + + +## Test matrix - ASUS KGPE-D16 + +### Module: Dasharo compatibility + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | coreboot base port | CBP | All | +| 2. | SMBIOS | DMI | DMI002.001, DMI003.001 | +| 3. | coreboot fan control | CFN | All | +| 4. | Custom boot menu key | CBK | All | +| 5. | Debian Stable and Ubuntu LTS support | LBT | LBT001.002 | +| 6. | Network boot | PXE | All | +| 7. | USB detect | USB | All | +| 8. | USB boot | UBB | All | +| 9. | Platform suspend and resume | SUSP | All | +| 10. | Flash write protection | FWP | All | + +### Module: Dasharo security + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | TPM Support | TPM | TPM001.001 | +| 2. | Verified Boot support | VBO | VBO001.001, VBO002.001, VBO003.001 | + +### Module: Dasharo performance + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | coreboot bring up time measurement | CBMEM | All | + +## Test matrix - Clevo NV41MZ + +### Module: Dasharo compatibility + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | Memory HCL | HCL | All | +| 2. | UEFI compatible interface | EFI | All | +| 3. | Display ports and LCD support | DSP | All | +| 4. | Embedded Controller and Super I/O initialization | ECR | All | +| 5. | NVMe support | NVM | All | +| 6. | Custom logo | CLG | All | +| 7. | Custom boot menu key | CBK | All | +| 8. | USB HID and MSC Support | USB | All | +| 9. | Debian Stable and Ubuntu LTS support | LBT | All | +| 10. | UEFI Shell | USH | All | +| 11. | Windows 11 booting | WBT | All | +| 12. | Audio subsystem | AUD | All | +| 13. | USB-C/Thunderbolt | UTC | All | +| 14. | Network boot | PXE | All | +| 15. | M.2 WiFi/Bluetooth | WLE | All | +| 16. | SD card support | SDC | All | +| 17. | USB Camera verification | CAM | All | +| 18. | Nvidia Graphics support | NVI | All | +| 19. | Custom fan curve | FAN | All | +| 20. | SMBIOS | DMI | DMI002.001, DMI003.001, DMI005.001, | +| | | | DMI006.001, DMI007.001, DMI008.001 | + +### Module: Dasharo security + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | TPM Support | TPM | All | +| 2. | Verified Boot support | VBO | VBO001.002, VBO002.002, VBO003.001 | +| 3. | Measured Boot support | MBO | All | +| 4. | Secure Boot support | SBO | All | + +## Test matrix - Clevo NV41MB + +### Module: Dasharo compatibility + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | Memory HCL | HCL | All | +| 2. | UEFI compatible interface | EFI | All | +| 3. | Display ports and LCD support | DSP | All | +| 4. | Embedded Controller and Super I/O initialization | ECR | Whithout ECR010.001 and ECR010.002 | +| 5. | NVMe support | NVM | All | +| 6. | Custom logo | CLG | All | +| 7. | Custom boot menu key | CBK | All | +| 8. | USB HID and MSC Support | USB | All | +| 9. | Debian Stable and Ubuntu LTS support | LBT | All | +| 10. | UEFI Shell | USH | All | +| 11. | Windows 11 booting | WBT | All | +| 12. | Audio subsystem | AUD | All | +| 13. | USB-C/Thunderbolt | UTC | All | +| 14. | Network boot | PXE | All | +| 15. | M.2 WiFi/Bluetooth | WLE | All | +| 16. | SD card support | SDC | All | +| 17. | USB Camera verification | CAM | All | +| 18. | Custom fan curve | FAN | FAN001.001 | +| 19. | SMBIOS | DMI | DMI002.001, DMI003.001, DMI005.001, | +| | | | DMI006.001, DMI007.001, DMI008.001 | + +### Module: Dasharo security + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | TPM Support | TPM | All | +| 2. | Verified Boot support | VBO | VBO001.002, VBO002.002, VBO003.001 | +| 3. | Measured Boot support | MBO | All | +| 4. | Secure Boot support | SBO | All | + +## Test matrix - Talos II + +### Module: Dasharo compatibility + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | coreboot base port | CBP | CBP001.001, CBP002.001, CBP004.001 | + +## Test matrix - Clevo NS50 + +### Module: Dasharo compatibility + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:----:|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | Memory HCL | HCL | All | +| 2. | UEFI compatible interface | EFI | All | +| 3. | Display ports and LCD support | DSP | All | +| 4. | Embedded Controller and Super I/O initialization | ECR | Whithout ECR010.001 and ECR010.002 | +| 5. | NVMe support | NVM | All | +| 6. | Custom logo | CLG | All | +| 7. | Custom boot menu key | CBK | All | +| 8. | USB HID and MSC Support | USB | All | +| 9. | Debian Stable and Ubuntu LTS support | LBT | All | +| 10. | Windows 11 booting | WBT | All | +| 11. | Audio subsystem | AUD | All | +| 12. | USB-C/Thunderbolt | UTC | All | +| 13. | M.2 WiFi/Bluetooth | WLE | All | +| 14. | SD card support | SDC | All | +| 15. | USB Camera verification | CAM | All | +| 16. | Custom fan curve | FAN | FAN001.001 | +| 17. | SMBIOS | DMI | DMI002.001, DMI003.001, DMI005.001, | +| | | | DMI006.001, DMI007.001, DMI008.001 | + +### Module: Dasharo security + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | TPM Support | TPM | All | +| 2. | Verified Boot support | VBO | VBO001.002, VBO002.002 | +| 3. | Measured Boot support | MBO | All | +| 4. | Secure Boot support | SBO | All | + +## Test matrix - Protectli VP4620 + +### Module: Dasharo compatibility + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:----:|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | Memory HCL | HCL | All | +| 2. | UEFI compatible interface | EFI | EFI001.001 | +| 3. | Display ports | DSP | DSP002.001,DSP002.003, DSP003.001, DSP003.003 | +| 4. | Network boot | PXE | All | +| 5. | NVMe support | NVM | NVM001.001, NVM001.002 | +| 7. | Custom logo | CLG | All | +| 8. | Custom boot menu key | CBK | All | +| 9. | USB HID and MSC Support | USB | USB001.001, USB001.002, USB002.001, USB002.002 | +| 10. | FreeBSD support | BSD | All | +| 11. | Debian Stable and Ubuntu LTS support | LBT | All | +| 12. | USB-C/Thunderbolt | UTC | UTC004.001 | +| 13. | M.2 WiFi/Bluetooth | WLE | WLE001.001, WLE002.001, WLE003.001 | +| 14. | miniPCIe LTE/WiFi/Bluetooth | MWL | MWL004.001 | +| 15. | eMMC support | MMC | MMC001.001 | +| 16. | SMBIOS | DMI | DMI002.001, DMI003.001, DMI004.001, DMI005.001, DMI006.001 | +| 17. | Custom network boot entries | CNB | CNB001.002 | +| 18. | M.2 automatic SATA/NVMe switching support | MSS | MSS001.001 | + +### Module: Dasharo security + +| No. | Supported test suite | Test suite ID | Supported test cases | +|:-----|:--------------------------------------------------|:-------------:|:-------------------------------------| +| 1. | TPM Support | TPM | TPM001.001 | diff --git a/docs/value-prop/certification-program/overview.md b/docs/value-prop/certification-program/overview.md index 21bef503..0a951f71 100644 --- a/docs/value-prop/certification-program/overview.md +++ b/docs/value-prop/certification-program/overview.md @@ -6,4 +6,5 @@ What this section will consist of: - introduction to features covered by Dasharo Certification Program (DCP) per Dasharo module per feature certification requirements - issues and proposals on how to address those -- guidelines how DCP helps fill other certifications and compliance criteria (AWS, Google, Azure, OCP, UEFI, ACPI) +- guidelines how DCP helps fill other certifications and compliance criteria + (AWS, Google, Azure, OCP, UEFI, ACPI) diff --git a/docs/value-prop/overview.md b/docs/value-prop/overview.md index 6250bda1..8febfdf4 100644 --- a/docs/value-prop/overview.md +++ b/docs/value-prop/overview.md @@ -5,11 +5,13 @@ will try to structure and present whole value that Dasharo can bring to your hardware. * [Marketing](marketing.md) - Dasharo Marketing Module was created to resolve - problems of hardware vendors with communicating [Embedded Firmware](../glossary.md#embedded-firmware) value. + problems of hardware vendors with communicating + [Embedded Firmware](../glossary.md#embedded-firmware) value. Finally, we agree with John Hennessy and David Patterson that we enter era of [New Golden Age](https://www.youtube.com/watch?v=3LVeEjsn8Ts) of domain specific computing with open architectures and open-source implementations. -What eventually will lead to more [firmware everywhere](../osf-trivia-list/introduction.md#where-is-firmware). Addressing mentioned areas is just -beginning for Dasharo we think following years would need way more firmware -expertise then at any other point in time. +What eventually will lead to more +[firmware everywhere](../osf-trivia-list/introduction.md#where-is-firmware). +Addressing mentioned areas is just beginning for Dasharo we think following +years would need way more firmware expertise then at any other point in time. diff --git a/docs/value-prop/performance.md b/docs/value-prop/performance.md index fb1e8efb..5e577328 100644 --- a/docs/value-prop/performance.md +++ b/docs/value-prop/performance.md @@ -1,3 +1,5 @@ # Dasharo Performance Module -TBD: explain what performance improvement features, use cases and success stories this module offer (CPU Performace Boost, CPU Turbo, power consumption optimization etc.) +TBD: explain what performance improvement features, use cases and success +stories this module offer (CPU Performace Boost, CPU Turbo, power consumption +optimization etc.) diff --git a/docs/variants/asus_kgpe_d16/building-manual.md b/docs/variants/asus_kgpe_d16/building-manual.md index f71f30e4..fd06a5bc 100644 --- a/docs/variants/asus_kgpe_d16/building-manual.md +++ b/docs/variants/asus_kgpe_d16/building-manual.md @@ -59,5 +59,7 @@ TPM 1.2 and TPM 2.0 support. Now the possible confis to use are: - `configs/config.asus_kgpe_d16_vboot_tpm2` - 2MB target with vboot and TPM 2.0 - `configs/config.asus_kgpe_d16_8M_vboot_tpm12` - 8MB target with vboot and TPM 1.2 - `configs/config.asus_kgpe_d16_8M_vboot_tpm2` - 8MB target with vboot and TPM 2.0 -- `configs/config.asus_kgpe_d16_16M_vboot_tpm12` - 16MB target with vboot and TPM 1.2 -- `configs/config.asus_kgpe_d16_16M_vboot_tpm2` - 16MB target with vboot and TPM 2.0 +- `configs/config.asus_kgpe_d16_16M_vboot_tpm12` - 16MB target with vboot and + TPM 1.2 +- `configs/config.asus_kgpe_d16_16M_vboot_tpm2` - 16MB target with vboot and + TPM 2.0 diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/custom-boot-menu-key.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/custom-boot-menu-key.md deleted file mode 100644 index 2c63ee62..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/custom-boot-menu-key.md +++ /dev/null @@ -1,30 +0,0 @@ -# Dasharo Compatibility: Custom boot menu key - -## Test cases - -### CBK001.001 Custom boot menu key - -**Test description** - -This test aims to verify that the DUT is configured to use the custom boot menu -hotkey. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). - -**Test steps** - -1. Power on the DUT. -2. Wait until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. - -**Expected result** - -The DUT boots into the boot menu using a specified hotkey. Depending on attached -devices boot options should be visible. diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/dmidecode.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/dmidecode.md deleted file mode 100644 index 47cd7136..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/dmidecode.md +++ /dev/null @@ -1,236 +0,0 @@ -# Dasharo Compatibility: Dmidecode - -## Test cases - -### DMI001.001 Verify the serial number - -**Test description** - -This test aims to verify that the DUT serial number is the same as specified in -coreboot configuration. - -**Test configuration data** - -1. `FIRMWARE` = coreboot -2. `BOOT_MENU_KEY` = `ESC` -3. `OPERATING_SYSTEM` = `Debian 11.0` - -**Test setup** - -1. Proceed with the - [Generic test setup: firmware](generic-test-setup#firmware) - -**Test steps** - -1. Power on the DUT -1. Boot into OS -1. Run `dmidecode -t baseboard` -1. Power off the DUT - -**Expected result** - -1. An output from the command should be similar to: - - ``` - root@debian:~# dmidecode -t baseboard - # dmidecode 3.3 - Getting SMBIOS data from sysfs. - SMBIOS 3.0 present. - - Handle 0x0002, DMI type 2, 14 bytes - Base Board Information - Manufacturer: ASUS - Product Name: KGPE-D16 - Version: 1.0 - Serial Number: 123456789 - Asset Tag: Not Specified - Features: None - Location In Chassis: Not Specified - Chassis Handle: 0x0003 - Type: Motherboard - - Handle 0x000A, DMI type 41, 11 bytes - Onboard Device - Reference Designation: SATA controller - Type: SATA Controller - Status: Enabled - Type Instance: 0 - Bus Address: 0000:00:11.0 - - Handle 0x000B, DMI type 41, 11 bytes - Onboard Device - Reference Designation: VGA compatible controller - Type: Video - Status: Enabled - Type Instance: 0 - Bus Address: 0000:e8:01.0 - - root@debian:~# - ``` - -2. The character string after `Serial Number:` should be the same as in the - coreboot config file. - -### DMI001.002 Verify the firmware version - -**Test description** - -This test aims to verify that the firmware version on the DUT is the same as in -the firmware filename. - -**Test configuration data** - -1. `FIRMWARE` = coreboot -1. `BOOT_MENU_KEY` = `ESC` -1. `OPERATING_SYSTEM` = `Debian 11.0` - -**Test setup** - -1. Proceed with the - [Generic test setup: firmware](generic-test-setup#firmware) - -**Test steps** - -1. Power on the DUT -1. Boot into OS -1. Run `dmidecode -t bios` -1. Power off the DUT - -**Expected result** - -1. An output from the command should be similar to: - - ``` - root@debian:~# dmidecode -t bios - # dmidecode 3.3 - Getting SMBIOS data from sysfs. - SMBIOS 3.0 present. - - Handle 0x0000, DMI type 0, 26 bytes - BIOS Information - Vendor: 3mdeb Embedded Systems Consulting - Version: Dasharo (coreboot+SeaBIOS) v0.2.0 - Release Date: 12/09/2021 - ROM Size: 16 MB - Characteristics: - PCI is supported - PC Card (PCMCIA) is supported - BIOS is upgradeable - Selectable boot is supported - ACPI is supported - Targeted content distribution is supported - BIOS Revision: 4.14 - Firmware Revision: 0.0 - ``` - -1. The character string after `Version:` should be the same as the firmware - fileneme indicates. - -### DMI001.003 Verify the product name - -**Test description** - -This test aims to verify that the DUT product name and manufacturer is correct. - -**Test configuration data** - -1. `FIRMWARE` = coreboot -2. `BOOT_MENU_KEY` = `ESC` -3. `OPERATING_SYSTEM` = `Debian 11.0` - -**Test setup** - -1. Proceed with the - [Generic test setup: firmware](generic-test-setup#firmware) - -**Test steps** - -1. Power on the DUT -1. Boot into OS -1. Run `dmidecode -t system` -1. Power off the DUT - -**Expected result** - -1. Output from the command should be similar to: - - ``` - root@debian:~# dmidecode -t system - # dmidecode 3.3 - Getting SMBIOS data from sysfs. - SMBIOS 3.0 present. - - Handle 0x0001, DMI type 1, 27 bytes - System Information - Manufacturer: ASUS - Product Name: KGPE-D16 - Version: 1.0 - Serial Number: 123456789 - UUID: Not Settable - Wake-up Type: Reserved - SKU Number: Not Specified - Family: Not Specified - - Handle 0x0009, DMI type 32, 11 bytes - System Boot Information - Status: No errors detected - - root@debian:~# - ``` - -2. The character string after `Product Name:` should be `KGPE-D16` and after - `Manufacturer` should be `ASUS`. - -### DMI001.004 Verify the release date - -**Test description** - -This test aims to verify that the firmware release date on the DUT is the same -as the tag of given Dasharo version on the Dasharo repository. - -**Test configuration data** - -1. `FIRMWARE` = coreboot -2. `BOOT_MENU_KEY` = `ESC` -3. `OPERATING_SYSTEM` = `Debian 11.0` - -**Test setup** - -1. Proceed with the - [Generic test setup: firmware](generic-test-setup#firmware) - -**Test steps** - -1. Power on the DUT -1. Boot into OS -1. Run `dmidecode -t bios` -1. Power off the DUT - -**Expected result** - -1. Output from the command should be similar to: - - ``` - # dmidecode 3.3 - Getting SMBIOS data from sysfs. - SMBIOS 3.0 present. - - Handle 0x0000, DMI type 0, 26 bytes - BIOS Information - Vendor: 3mdeb Embedded Systems Consulting - Version: Dasharo (coreboot+SeaBIOS) v0.2.0 - Release Date: 12/09/2021 - ROM Size: 16 MB - Characteristics: - PCI is supported - PC Card (PCMCIA) is supported - BIOS is upgradeable - Selectable boot is supported - ACPI is supported - Targeted content distribution is supported - BIOS Revision: 4.14 - Firmware Revision: 0.0 - ``` - -2. The character string after `Release date:` should point to the date of the - tag of given Dasharo version on Dasharo the repository. diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md deleted file mode 100644 index 08af7159..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md +++ /dev/null @@ -1,80 +0,0 @@ -# Dasharo Compatibility: Fan Control - -## Test cases - -### FAN001.001 Check CPU entry temperature and CPU fan speed - -**Test description** - -This test aims to verify that data for CPU temperature and CPU fan speed is -available. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). - -**Test steps** - -1. Power on the DUT. -2. Wait for boot until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. -4. Select the proper number for `USB_STICK` option. -5. Wait for `debian login:`. -6. Type proper login. -8. Wait for `Password:`. -9. Type the proper password. -10. Wait for `root@debian:~#`. -11. Execute `watch -n 1 "sensors w83795g-i2c-1-2f |grep fan1 -A 16"`. - -**Expected result** - -There are visible data for `fan1` and `temp7` which represents CPU fan speed and -CPU temperature. - -### FAN001.002 Check if increasing CPU temperature increases CPU fan speed - -**Test description** - -This test aims to verify that CPU fan speed responds properly to increasing CPU -temperature. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). - -**Test steps** - -1. Power on the DUT. -2. Wait for boot until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. -4. Select the proper number for `USB_STICK` option. -5. Wait for `debian login:`. -6. Type proper login. -8. Wait for `Password:`. -9. Type the proper password. -10. Wait for `root@debian:~#`. -11. Install `stress-ng` package by executing: `sudo apt install stress-ng`. -12. Confirm installation by typing `Y` and pressing `Enter` when asked. -13. Execute command: `watch -n 1 "sensors w83795g-i2c-1-2f |grep fan1 -A 16"` - and check current CPU temperature and CPU fan speed. -14. Execute command: `stress-ng --cpu 16 --io 8 --vm 4 --vm-bytes 4G --timeout 30s --metrics`. -15. Wait 2 minutes. -16. Execute command: `watch -n 1 "sensors w83795g-i2c-1-2f |grep fan1 -A 16"` - and check current CPU temperature and CPU fan speed. - -**Expected result** - -1. The CPU temperature after the second check is higher at least 20 degrees. -2. The CPU fan speed after the second check is higher at least 1000 RPM. diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/generic-test-setup.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/generic-test-setup.md deleted file mode 100644 index 5886f23c..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/generic-test-setup.md +++ /dev/null @@ -1,19 +0,0 @@ -# Dasharo Compatibility: Generic test setup - -## Test setup - -Test setup is a set of procedures to be executed before the test execution. -Typically, the same setup can be reused by multiple test cases, so there is no -need to execute the setup actions before each independent case. - -### Generic test setup - -#### Firmware - -1. Obtain `FIRMWARE` binary - * you can download it from [releases](../releases.md) - section - * also you can build one yourself as shown in the - [Building manual](../building-manual.md) section -1. Flash `FIRMWARE` binary to the DUT - * If coreboot is not yet installed: Refer to [setup](../setup.md#spi) diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/index.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/index.md deleted file mode 100644 index 665a07b5..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/index.md +++ /dev/null @@ -1,9 +0,0 @@ -# Dasharo Compatibility Specification - -* [Generic test setup](generic-test-setup.md) -* [coreboot base port](coreboot-base-port.md) -* [Custom boot menu key](custom-boot-menu-key.md) -* [Fan control](fan-control.md) -* [Memtest86plus](memtest.md) -* [Operating system](os.md) -* [SMBIOS/DMI tables verification](dmidecode.md) diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md deleted file mode 100644 index e5e61335..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md +++ /dev/null @@ -1,43 +0,0 @@ -# Dasharo Compatibility: Network Boot - -## Test cases - -### PXE001.001 iPXE network boot - -**Test description** - -This test aims to verify that the DUT is capable of network booting and logging -into `Debian` from an iPXE server. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). - -**Test steps** - -1. Power on the DUT. -2. Wait for boot until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. -4. Select the key with a proper number for `iPXE`. -5. Press `Ctrl+B` when prompted to stop iPXE from booting automatically. -6. Wait until `iPXE>` prompt appears. -7. Type in `dhcp` to obtain an IP address. -8. Type in `chain` and local iPXE address after a single space to load a network -boot menu. -8. Select `Debian stable netboot 4.14.y` option below `iPXE boot menu` header. -9. Wait for `debian login:`. -10. Type the `root` login. -11. Wait for `Password:`. -12. Type the proper password. -13. Wait for `root@debian:~#`. - -**Expected result** - -1. The iPXE application boots successfully. -2. iPXE obtains an IP address. -3. iPXE boots a `Debian` from the local network. diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/os.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/os.md deleted file mode 100644 index f4fce314..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/os.md +++ /dev/null @@ -1,63 +0,0 @@ -# Dasharo Compatibility: Debian Stable and Ubuntu LTS support - -## Test cases - -### LBT001.001 Debian boot from USB - -**Test description** - -This test aims to verify that DUT boots properly Debian from USB. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). - -**Test steps** - -1. Power on the DUT. -2. Wait for boot until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. -4. Select the proper number for `USB_STICK` option. -5. Wait for `Debian GNU/Linux` - -**Expected result** - -The `Debian GNU/Linux` is visible and confirms successful boot into OS. - -### LBT001.002 Log into booted Debian - -**Test description** - -This test aims to verify that DUT logs properly into Debian booted from USB. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](generic-test-setup.md#firmware). - -**Test steps** - -1. Power on the DUT. -2. Wait for boot until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. -4. Select the proper number for `USB_STICK` option. -5. Wait for `debian login:`. -6. Type proper login -8. Wait for `Password:` -9. Type the proper password -10. Wait for `root@debian:~#` - -**Expected result** - -The `root@debian:~#` is visible after successful login. diff --git a/docs/variants/asus_kgpe_d16/dasharo-compatibility/platform-suspend-and-resume.md b/docs/variants/asus_kgpe_d16/dasharo-compatibility/platform-suspend-and-resume.md deleted file mode 100644 index 6892f146..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-compatibility/platform-suspend-and-resume.md +++ /dev/null @@ -1,44 +0,0 @@ -# Dasharo Compatibility: platform suspend and resume - -## Test cases - -### SUSP001.001 Platform suspend and resume - -**Test description** - -This test verifies whether the DUT might be put into suspend mode and then, by -using the power button, might be properly resumed. This test case may be re-done -several times to specify the platform stability. - -**Test configuration data** - -1. `FIRMWARE` = coreboot -2. `BOOT_MENU_KEY` = `ESC` -3. `OPERATING_SYSTEM` = `Debian 11.0` - -**Test setup** - -1. Proceed with the - [Generic test setup: firmware](generic-test-setup#firmware) - -**Test steps** - -1. Power on the DUT. -1. Boot into OS. -1. Run command `date` and write down output of the command. -1. Run command `systemctl suspend -i`. -1. Check the status of the platform. -1. Press the power button once and note the result. -1. Run the following command: `journalctl | grep suspend`. - -**Expected result** - -1. After running suspend command the platform should enter the suspend mode. -1. After pressing power button the platform should initiate the resume - procedure. -1. Output of the last command should contains the line with the statement: - - systemd[1]: systemd-suspend.service: Succeeded - -1. Date of the above-described event should be later than date from - command `date` from the test steps' third point. diff --git a/docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md b/docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md deleted file mode 100644 index 50630376..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md +++ /dev/null @@ -1,137 +0,0 @@ -# Dasharo Security: TPM Support - -## Test cases - -### TPM001.001 TPM Support (Debian) - -**Test description** - -This test aims to verify that the TPM is initialized correctly and the PCRs can -be accessed from the operating system. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` -3. `USB_STICK` = `USB MSC Drive General USB Flash Disk 1100` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](../dasharo-compatibility/generic-test-setup.md#firmware). - -**Test steps** - -1. Power on the DUT. -2. Wait for boot until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. -4. Select the proper number for `USB_STICK` option. -5. Wait for `debian login:`. -6. Type `root` login. -7. Wait for `Password:`. -8. Type the proper password. -9. Wait for `root@debian:~#`. -10. For TPM2.0 - Install `tpm2-tools` package by executing: - - ``` - apt install tpm2-tools - ``` - -11. For TPM2.0 - Execute command. - -``` -tpm2_pcrread -``` - -12. For TPM1.2 - Execute command: - -``` -cat /sys/class/tpm/tpm0/pcrs -``` - -**Expected result** - -1. The command should return a list of PCRs and their contents. - -Example for TPM2.0: - -``` -sha1 : - 0 : 3a3f780f11a4b49969fcaa80cd6e3957c33b2275 - 1 : 8a074fdf65a11e5dbf02d25e7f26b00c26c98b41 - 2 : c36c2509d636c9cfa075d6d0a03b7a37bec14ee9 - 3 : 3a3f780f11a4b49969fcaa80cd6e3957c33b2275 - 4 : 2d247bb671ec17ded623ca45967df5482517291b - 5 : 49d543eb1d1df3439d9fca695ee47b8cdf4b9e2f - 6 : 3a3f780f11a4b49969fcaa80cd6e3957c33b2275 - 7 : 3a3f780f11a4b49969fcaa80cd6e3957c33b2275 - 8 : 0000000000000000000000000000000000000000 - 9 : 0000000000000000000000000000000000000000 - 10 : 0000000000000000000000000000000000000000 - 11 : 0000000000000000000000000000000000000000 - 12 : 0000000000000000000000000000000000000000 - 13 : 0000000000000000000000000000000000000000 - 14 : 0000000000000000000000000000000000000000 - 15 : 0000000000000000000000000000000000000000 - 16 : 0000000000000000000000000000000000000000 - 17 : ffffffffffffffffffffffffffffffffffffffff - 18 : ffffffffffffffffffffffffffffffffffffffff - 19 : ffffffffffffffffffffffffffffffffffffffff - 20 : ffffffffffffffffffffffffffffffffffffffff - 21 : ffffffffffffffffffffffffffffffffffffffff - 22 : ffffffffffffffffffffffffffffffffffffffff - 23 : 0000000000000000000000000000000000000000 -sha256 : - 0 : d27cc12614b5f4ff85ed109495e320fb1e5495eb28d507e952d51091e7ae2a72 - 1 : b29a64bd6895966b777eb803f45e6bbffade81cc1b996a34f7cbd26f1d04028b - 2 : 3122422e43b9fbfc0cb70eb467b55e99ec61462370e6b15c515484f821e1d4d9 - 3 : 909e4261938378c0556a4c335c38718d1c313bd151fdf222df674aabb7aeee97 - 4 : 984763b42633ee11e5167e2f67c2e6879bd6efac683f1df1ef16d7ce96d4b49b - 5 : dab92c45eeb765e29784f8cc33f92d0a39afed173f2b07e0e328586c3c3b19ed - 6 : d27cc12614b5f4ff85ed109495e320fb1e5495eb28d507e952d51091e7ae2a72 - 7 : d27cc12614b5f4ff85ed109495e320fb1e5495eb28d507e952d51091e7ae2a72 - 8 : 0000000000000000000000000000000000000000000000000000000000000000 - 9 : 0000000000000000000000000000000000000000000000000000000000000000 - 10 : 0000000000000000000000000000000000000000000000000000000000000000 - 11 : 0000000000000000000000000000000000000000000000000000000000000000 - 12 : 0000000000000000000000000000000000000000000000000000000000000000 - 13 : 0000000000000000000000000000000000000000000000000000000000000000 - 14 : 0000000000000000000000000000000000000000000000000000000000000000 - 15 : 0000000000000000000000000000000000000000000000000000000000000000 - 16 : 0000000000000000000000000000000000000000000000000000000000000000 - 17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - 18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - 19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - 20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - 21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - 22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff - 23 : 0000000000000000000000000000000000000000000000000000000000000000 -``` - -Example for TPM1.2: - -``` -PCR-00: B3 F3 60 E1 D5 1F 82 D4 62 E6 B9 69 92 2F 65 F4 9F 1A 5F 8E -PCR-01: 21 9F 1F 4A C1 AD AD 4D F1 8B 9F AB 98 23 68 B1 73 A6 32 87 -PCR-02: 40 CF E3 DC A7 FF 67 FB AA BB 20 85 A4 39 43 D8 54 A7 AB 98 -PCR-03: E3 E7 E6 89 CA FB F5 75 38 95 D0 CD 83 96 F6 0C 38 04 DC D5 -PCR-04: 01 7A 3D E8 2F 4A 1B 77 FC 33 A9 03 FE F6 AD 27 EE 92 BE 04 -PCR-05: 93 6A 12 98 07 73 85 9D 91 27 61 82 E7 11 C5 1D 08 98 C4 28 -PCR-06: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75 -PCR-07: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75 -PCR-08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -PCR-17: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF -PCR-18: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF -PCR-19: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF -PCR-20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF -PCR-21: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF -PCR-22: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF -PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -``` diff --git a/docs/variants/asus_kgpe_d16/dasharo-security/verified-boot.md b/docs/variants/asus_kgpe_d16/dasharo-security/verified-boot.md deleted file mode 100644 index 3fc74f77..00000000 --- a/docs/variants/asus_kgpe_d16/dasharo-security/verified-boot.md +++ /dev/null @@ -1,107 +0,0 @@ -# Dasharo Security: Verified Boot support - -## Test cases - -### VBO001.001 Verified boot support - -**Test description** - -Verified Boot is a method of verifying that the firmware compents come from a -trusted source. This test aims to confirm that verified boot is enabled and -functional. - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](../dasharo-compatibility/generic-test-setup.md#firmware). - -**Test steps** - -1. Connect to the DUT using the serial port. -2. Power on DUT. -3. Read coreboot loading logs. - -**Expected result** - -The logs should indicate that vboot is enabled and verstage has been entered: - -``` -VBOOT: Loading verstage. -``` - -### VBO002.001 Verified boot: Booting from Slot A - -**Test description** - -If the signatures for firmware stored in vboot Slot A are correct, vboot should -proceed to boot from Slot A. - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](../dasharo-compatibility/generic-test-setup.md#firmware). - -**Test steps** - -1. Connect to the DUT using the serial port. -2. Power on the DUT. -3. Read coreboot loading logs. - -**Expected result** - -The logs should indicate that vboot has chosen to boot from slot A: - -``` -Slot A is selected -``` - -### VBO003.001 Verified boot: Booting from Recovery (Debian) - -**Test description** - -If the signatures for firmware stored in vboot Slot A are incorrect, vboot -should revert to booting from the recovery slot. - -**Test configuration data** - -1. `BOOT_MENU_KEY` = `ESC` -2. `BOOT_MENU_STRING` = `Press ESC for boot menu` - -**Test setup** - -1. Proceed with the [Generic test setup: firmware](../dasharo-compatibility/generic-test-setup.md#firmware). -2. Obtain [coreboot binary](https://cloud.3mdeb.com/index.php/s/DAn2sdk3osSxG8A) - signed with wrong vboot keys - -**Test steps** - -1. Power on the DUT. -2. Wait for boot until `BOOT_MENU_STRING` appears. -3. Press `BOOT_MENU_KEY` to enter the boot menu. -4. Select the proper number for `USB_STICK` option. -5. Wait for `debian login:`. -6. Type `root` login. -7. Wait for `Password:`. -8. Type the proper password. -9. Wait for `root@debian:~#`. -10. Install `flashrom` by `apt-get install flashrom` command. -11. Flash coreboot signed with wrong vboot keys by executing the following -command: - - flashrom -p internal --fmap -i RW_SECTION_A -w [coreboot binary] - -12. Power off the DUT -13. Connect to the DUT using the serial port. -14. Power on the DUT -15. Read coreboot loading logs. - -**Expected result** - -The logs should indicate that vboot has chosen to boot from -the recovery slot. - -Example: - -``` -VB2:vb2_check_recovery() Recovery reason from previous boot: 0x3 / 0x3 -VB2:vb2_check_recovery() We have a recovery request: 0x3 / 0x0 -Recovery requested (1009000e) -``` diff --git a/docs/variants/asus_kgpe_d16/fan-control.md b/docs/variants/asus_kgpe_d16/fan-control.md index 1e1e9249..e17eeda2 100644 --- a/docs/variants/asus_kgpe_d16/fan-control.md +++ b/docs/variants/asus_kgpe_d16/fan-control.md @@ -21,7 +21,7 @@ modprobe w83795 The `dmesg` should contain the following message after loading the module: -``` +```shell i2c i2c-1: Found w83795g rev. B at 0x2f w83795 1-002f: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). @@ -36,7 +36,7 @@ sensors The output should be similar to the one below: -``` +```shell k10temp-pci-00cb Adapter: PCI adapter temp1: +36.5°C (high = +70.0°C) diff --git a/docs/variants/asus_kgpe_d16/hardware-matrix.md b/docs/variants/asus_kgpe_d16/hardware-matrix.md index 683c6629..9e3882a4 100644 --- a/docs/variants/asus_kgpe_d16/hardware-matrix.md +++ b/docs/variants/asus_kgpe_d16/hardware-matrix.md @@ -7,24 +7,27 @@ environment for ASUS KGPE-D16 boards available in 3mdeb testing laboratory. | Component | Description | Board connection | |----------------------------|--------------------------------------------------------------|--------------------------------------------| -| CPU: | AMD Opteron(TM) Processor 6282 SE | `CPU1` slot | +| CPU | AMD Opteron(TM) Processor 6282 SE | `CPU1` slot | | | CPU Cooler | `CPU_FAN1` connector | +| | AMD Opteron(TM) Processor 6282 SE | `CPU2` slot | +| | CPU Cooler | `CPU_FAN2` connector | | RAM | DDR3 16GB Kingston KVR16R11D4/16 | `DIMM_B2` slot | +| | DDR3 16GB Kingston KVR16R11D4/16 | `DIMM_F2` slot | | Flash memory | Winbond W25Q64FV 8MB | `BIOS` slot | | Network | Local network wired connection | `LAN1` port | | Attached devices | 1. Goodram 16GB USB stick | `USB1` port | | | 2. ASUS TPM-L R2.0 module (chip Infineon SLB9665 TT2.0) | `TPM1` connector | | Power Supply | 700 W ATX type power supply | `SSIPWR1`, `SSI12V1` connectors | -| Power Control: | 1. Sonoff S20 switch | N/A | +| Power Control | 1. Sonoff S20 switch | N/A | | | 2. Goldpin cables (RTE <-> Board connection) | `PANEL1` connector | -| Remote Testing Environment:| 1. RTE `v1.0.0` (firmware `v0.5.3`) connected via RS232 | `COM1` port | +| Remote Testing Environment | 1. RTE `v1.0.0` (firmware `v0.5.3`) connected via RS232 | `COM1` port | | | 2. Goldpin cables + qspimux (RTE <-> flash memory connection)| `BIOS` slot | ## Board No. 2 | Component | Description | Board connection | |----------------------------|----------------------------------------------------------------------|--------------------------------------------| -| CPU: | AMD Opteron(TM) Processor 6282 SE | `CPU1` slot | +| CPU | AMD Opteron(TM) Processor 6282 SE | `CPU1` slot | | | CPU Cooler | `CPU_FAN1` connector | | RAM | DDR3 16GB Kingston KVR16R11D4/16 | `DIMM_B2` slot | | Flash memory | Winbond W25Q128JV 16MB | `BIOS` slot | @@ -35,7 +38,7 @@ environment for ASUS KGPE-D16 boards available in 3mdeb testing laboratory. | Power Supply | 700 W ATX type power supply | `SSIPWR1`, `SSI12V1`, `SSI12V2` connectors | | Power Control: | 1. Sonoff S20 switch | N/A | | | 2. Goldpin cables (RTE <-> Board connection) | `PANEL1` connector | -| Remote Testing Environment:| 1. RTE `v1.0.0` (firmware `v0.5.3`) connected via RS232 | `COM1` port | +| Remote Testing Environment | 1. RTE `v1.0.0` (firmware `v0.5.3`) connected via RS232 | `COM1` port | | | 2. POMONA Clip + DIP8/SOIC8 adapter (RTE <-> flash memory connection)| `BIOS` slot | ASUS KGPE-D16 board ports, slots, and connectors description is available in the diff --git a/docs/variants/asus_kgpe_d16/releases.md b/docs/variants/asus_kgpe_d16/releases.md index c55811d7..670af705 100644 --- a/docs/variants/asus_kgpe_d16/releases.md +++ b/docs/variants/asus_kgpe_d16/releases.md @@ -6,7 +6,14 @@ ASUS KGPE-D16. For details about our release process please read [Dasharo Standard Release Process](../../dev-proc/standard-release-process.md). -[Subscribe to ASUS KGPE-D16 Dasharo Release Newsletter](https://newsletter.3mdeb.com/subscription/ozes4Jxuo){ .md-button .md-button--primary .center } +
+ +[Subscribe to Release Newsletter][newsletter] +{ .md-button .md-button--primary .center } + +[newsletter]: https://newsletter.3mdeb.com/subscription/ozes4Jxuo + +
Feel free to contact us on our [Matrix Dasharo space](https://matrix.to/#/#dasharo:matrix.org). @@ -29,39 +36,63 @@ Feel free to contact us on our [Matrix Dasharo space](https://matrix.to/#/#dasha - 2MB vboot TPM 1.2 -[asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom][v0.3.0_2m_tpm12_rom]{ .md-button } +[sha256][v0.3.0_2m_tpm12_sha]{ .md-button } +[sha256.sig][v0.3.0_2m_tpm12_sig]{ .md-button } + +[v0.3.0_2m_tpm12_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom +[v0.3.0_2m_tpm12_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom.sha256 +[v0.3.0_2m_tpm12_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM1.2.rom.sha256.sig - 2MB vboot TPM 2.0 -[asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom][v0.3.0_2m_tpm20_rom]{ .md-button } +[sha256][v0.3.0_2m_tpm20_sha]{ .md-button } +[sha256.sig][v0.3.0_2m_tpm20_sig]{ .md-button } + +[v0.3.0_2m_tpm20_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom +[v0.3.0_2m_tpm20_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom.sha256 +[v0.3.0_2m_tpm20_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_2M_vboot_TPM2.0.rom.sha256.sig - 8MB vboot TPM 1.2 -[asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom][v0.3.0_8m_tpm12_rom]{ .md-button } +[sha256][v0.3.0_8m_tpm12_sha]{ .md-button } +[sha256.sig][v0.3.0_8m_tpm12_sig]{ .md-button } + +[v0.3.0_8m_tpm12_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom +[v0.3.0_8m_tpm12_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom.sha256 +[v0.3.0_8m_tpm12_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM1.2.rom.sha256.sig - 8MB vboot TPM 2.0 -[asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom][v0.3.0_8m_tpm20_rom]{ .md-button } +[sha256][v0.3.0_8m_tpm20_sha]{ .md-button } +[sha256.sig][v0.3.0_8m_tpm20_sig]{ .md-button } + +[v0.3.0_8m_tpm20_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom +[v0.3.0_8m_tpm20_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom.sha256 +[v0.3.0_8m_tpm20_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_8M_vboot_TPM2.0.rom.sha256.sig - 16MB vboot TPM 1.2 -[asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom][v0.3.0_16m_tpm12_rom]{ .md-button } +[sha256][v0.3.0_16m_tpm12_sha]{ .md-button } +[sha256.sig][v0.3.0_16m_tpm12_sig]{ .md-button } + +[v0.3.0_16m_tpm12_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom +[v0.3.0_16m_tpm12_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom.sha256 +[v0.3.0_16m_tpm12_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM1.2.rom.sha256.sig - 16MB vboot TPM 2.0 -[asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom][v0.3.0_16m_tpm20_rom]{ .md-button } +[sha256][v0.3.0_16m_tpm20_sha]{ .md-button } +[sha256.sig][v0.3.0_16m_tpm20_sig]{ .md-button } + +[v0.3.0_16m_tpm20_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom +[v0.3.0_16m_tpm20_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom.sha256 +[v0.3.0_16m_tpm20_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.3.0_16M_vboot_TPM2.0.rom.sha256.sig ### SBOM (Software Bill of Materials) @@ -85,21 +116,33 @@ Feel free to contact us on our [Matrix Dasharo space](https://matrix.to/#/#dasha - 2MB target -[asus_kgpe-d16_v0.2.0_2M.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_2M.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_2M.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_2M.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.2.0_2M.rom][v0.2.0_2m_rom]{ .md-button } +[sha256][v0.2.0_2m_sha]{ .md-button } +[sha256.sig][v0.2.0_2m_sig]{ .md-button } + +[v0.2.0_2m_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_2M.rom +[v0.2.0_2m_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_2M.rom.sha256 +[v0.2.0_2m_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_2M.rom.sha256.sig - 8MB target -[asus_kgpe-d16_v0.2.0_8M.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_8M.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_8M.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_8M.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.2.0_8M.rom][v0.2.0_8m_rom]{ .md-button } +[sha256][v0.2.0_8m_sha]{ .md-button } +[sha256.sig][v0.2.0_8m_sig]{ .md-button } + +[v0.2.0_8m_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_8M.rom +[v0.2.0_8m_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_8M.rom.sha256 +[v0.2.0_8m_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_8M.rom.sha256.sig - 16MB target -[asus_kgpe-d16_v0.2.0_16M.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_16M.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_16M.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_16M.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.2.0_16M.rom][v0.2.0_16m_rom]{ .md-button } +[sha256][v0.2.0_16m_sha]{ .md-button } +[sha256.sig][v0.2.0_16m_sig]{ .md-button } + +[v0.2.0_16m_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_16M.rom +[v0.2.0_16m_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_16M.rom.sha256 +[v0.2.0_16m_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.2.0_16M.rom.sha256.sig ### SBOM (Software Bill of Materials) @@ -120,11 +163,15 @@ Feel free to contact us on our [Matrix Dasharo space](https://matrix.to/#/#dasha ### Binaries -[asus_kgpe-d16_v0.1.0.rom](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.1.0.rom){ .md-button } +[asus_kgpe-d16_v0.1.0.rom][v0.1.0_rom]{ .md-button } -[asus_kgpe-d16_v0.1.0.rom.sha256](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.1.0.rom.sha256){ .md-button } +[asus_kgpe-d16_v0.1.0.rom.sha256][v0.1.0_sha]{ .md-button } -[asus_kgpe-d16_v0.1.0.rom.sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.1.0.rom.sha256.sig){ .md-button } +[asus_kgpe-d16_v0.1.0.rom.sha256.sig][v0.1.0_sig]{ .md-button } + +[v0.1.0_rom]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.1.0.rom +[v0.1.0_sha]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.1.0.rom.sha256 +[v0.1.0_sig]: https://3mdeb.com/open-source-firmware/Dasharo/asus_kgpe-d16/asus_kgpe-d16_v0.1.0.rom.sha256.sig ### SBOM (Software Bill of Materials) diff --git a/docs/variants/asus_kgpe_d16/setup.md b/docs/variants/asus_kgpe_d16/setup.md index 9a8b4a51..b6f09122 100644 --- a/docs/variants/asus_kgpe_d16/setup.md +++ b/docs/variants/asus_kgpe_d16/setup.md @@ -1,4 +1,5 @@ -RTE v.0.5.3 with Asus KGPE-D16 connection +# RTE v.0.5.3 with Asus KGPE-D16 connection + ========================================= ![](/images/kgpe_overview.png) @@ -48,7 +49,7 @@ The proposed connections used: Simple flashing script looks as follows: -``` +```bash # select flash <-> programmer echo "0" > /sys/class/gpio/gpio400/value # deassert SPI HOLD# @@ -62,7 +63,7 @@ echo "1" > /sys/class/gpio/gpio400/value Controlling state of #WP: -``` +```bash # configure direction of the pin echo "out" > /sys/class/gpio/gpio402/direction diff --git a/docs/variants/asus_kgpe_d16/spi-wp.md b/docs/variants/asus_kgpe_d16/spi-wp.md index 2203c1ee..f33a8246 100644 --- a/docs/variants/asus_kgpe_d16/spi-wp.md +++ b/docs/variants/asus_kgpe_d16/spi-wp.md @@ -1,4 +1,5 @@ -SPI hardware write protection +# SPI hardware write protection + ============================= In order to from a Root of Trust in the firmware, e.g. in the immutable piece @@ -118,7 +119,7 @@ measurements and verification of next stages. First let's see how much space we need to protect. Take your coreboot.rom file and use cbfstool to show its contents: -``` +```bash cd /path/to/coreboot/build ./cbfstool coreboot.rom print FMAP REGION: COREBOOT @@ -148,7 +149,7 @@ flash. Converting 12KB to hex would be equal to `0x3000` but we must cover a little bit more than that. Let's see what protection ranges are available for the chip (running from the tagret machine to be protected): -``` +```bash ./flashrom -p internal --wp-list ... Available write protection ranges: @@ -293,7 +294,7 @@ Protection mode: disabled It must indicate `Protection mode: disabled`. Now you may reconfigure the range, e.g. -``` +```bash ./flashrom -p internal --wp-range=0x007e0000,0x00020000 ``` @@ -356,7 +357,7 @@ size of 2097152 bytes. These numbers are in decimal, so one must convert them to hex. Either use an online hex converter or use the command in bash like a pro :) -``` +```bash printf "0x%x\n" 6291456 0x600000 printf "0x%x\n" 2097152 @@ -374,7 +375,7 @@ Otherwise a whole image must be rebuilt. After custo mkeys have been used to sign the ifmrware image and the image has been flashed proceed with enalbing the protection: -``` +```bash ./flashrom -p internal --wp-range=0x00600000,0x00200000 ``` diff --git a/docs/variants/asus_kgpe_d16/tpm-mboot.md b/docs/variants/asus_kgpe_d16/tpm-mboot.md index aae40457..a8897861 100644 --- a/docs/variants/asus_kgpe_d16/tpm-mboot.md +++ b/docs/variants/asus_kgpe_d16/tpm-mboot.md @@ -45,7 +45,7 @@ and the measurements could be faked before they are migrated to the TPM. If you check the boot logs either on serial port on via cbmem utility you should see: -``` +```bash coreboot-asus_kgpe-d16_v0.2.0-15-g521dec6dff Wed Dec 15 11:43:34 UTC 2021 bootblock starting (log level: 8)... CPU INIT detected 00000000 Found TPM SLB9665 TT 2.0 by Infineon @@ -70,7 +70,7 @@ When vboot is enabled and the verstage is being located, the bootblock measures itself and the verstage, but the measurements are sent to the TPM PCRs not in bootblock, but in verstage: -``` +```bash coreboot-asus_kgpe-d16_v0.2.0-15-g521dec6dff Wed Dec 15 11:43:34 UTC 2021 bootblock starting (log level: 8)... CPU INIT detected 00000000 VBOOT: Loading verstage. diff --git a/docs/variants/clevo_nv41/building.md b/docs/variants/clevo_nv41/building.md index 6dba1941..616155d0 100644 --- a/docs/variants/clevo_nv41/building.md +++ b/docs/variants/clevo_nv41/building.md @@ -46,9 +46,9 @@ $ docker run -u $UID --rm -it -v $PWD:/home/coreboot/coreboot -w /home/coreboot/ coreboot/coreboot-sdk:0ad5fbd48d /bin/bash ``` -*Warning: Do not run `docker` as root. This command should be executed as your +_Warning: Do not run `docker` as root. This command should be executed as your current user. If you're having trouble running `docker` on your user account, -follow the steps outlined in [Requirements](#requirements).* +follow the steps outlined in [Requirements](#requirements)._ You should be inside the Docker container. Now run following script to build the image: diff --git a/docs/variants/clevo_nv41/ec_update.md b/docs/variants/clevo_nv41/ec_update.md index 3b2ae036..709172e9 100644 --- a/docs/variants/clevo_nv41/ec_update.md +++ b/docs/variants/clevo_nv41/ec_update.md @@ -13,7 +13,7 @@ Insyde BIOS firmware. To check the current EC firmware version while running stock Insyde BIOS, run the following command: -``` +```bash # dmidecode -t 0 | grep `Firmware Revision` Firmware Revision: 7.5 diff --git a/docs/variants/clevo_nv41/flashing_external.md b/docs/variants/clevo_nv41/flashing_external.md index d2bc96b5..26dd2361 100644 --- a/docs/variants/clevo_nv41/flashing_external.md +++ b/docs/variants/clevo_nv41/flashing_external.md @@ -64,7 +64,7 @@ if the programmer is detected properly, run the following command: The output should contain the following text: -``` +```bash Found GigaDevice flash chip "GD25Q128B" (16384 kB, SPI) on linux_spi. Found GigaDevice flash chip "GD25Q128C" (16384 kB, SPI) on linux_spi. Multiple flash chip definitions match the detected chip(s): "GD25Q128B", "GD25Q128C" diff --git a/docs/variants/clevo_nv41/flashing_internal.md b/docs/variants/clevo_nv41/flashing_internal.md index c88582af..3f8cd91a 100644 --- a/docs/variants/clevo_nv41/flashing_internal.md +++ b/docs/variants/clevo_nv41/flashing_internal.md @@ -1,8 +1,8 @@ -# coreboot internal flashing (Ubuntu 20.04) +# Dasharo internal flashing (Ubuntu 20.04) ## Intro -Flashing coreboot can be done from Linux using flashrom with the internal +Flashing Dasharo can be done from Linux using flashrom with the internal programmer. This document describes the process of building, installing and running flashrom on Ubuntu 20.04. @@ -45,23 +45,23 @@ following command: # flashrom -p internal -r dump.rom ``` -## Flashing coreboot +## Flashing Dasharo -To flash coreboot to the laptop, execute the following command - replace [path] -with the path to the coreboot image you want to flash, e.g. `build/coreboot.rom`. +To flash Dasharo to the laptop, execute the following command - replace [path] +with the path to the Dasharo image you want to flash, e.g. `build/coreboot.rom`. -If stock firmware or coreboot version below v0.5.0 is currently installed: +If stock firmware or Dasharo version below v1.1.0 is currently installed: ```bash # flashrom -p internal -w [path] --ifd -i bios ``` -If version v0.5.0 or higher is currently installed, only the RW_SECTION_A -partition of the flash can be flashed from the operating system. Flash it using -the following command: +If version v1.1.0 or higher is currently installed, only the RW_SECTION_A +partition of the flash needs to be updated. Flash it using the following +command: ```bash # flashrom -p internal -w [path] --fmap -i RW_SECTION_A ``` -This command also preserves UEFI settings and the boot order. +This command also preserves the bootsplash, UEFI settings and the boot order. diff --git a/docs/variants/clevo_nv41/fwupd_usage.md b/docs/variants/clevo_nv41/fwupd_usage.md index 5768c96a..59811713 100644 --- a/docs/variants/clevo_nv41/fwupd_usage.md +++ b/docs/variants/clevo_nv41/fwupd_usage.md @@ -14,57 +14,56 @@ using different distribution, you might need to 1. Download and extract the fwupd archive: -```bash -$ wget --content-disposition \ - https://cloud.3mdeb.com/index.php/s/peqT6xsrCn5pzRk/download \ - https://cloud.3mdeb.com/index.php/s/TPKDpzedRi7sEJJ/download \ - https://cloud.3mdeb.com/index.php/s/C58L5c5RmbjKWWz/download -$ unzip fwupd-novacustom-v1.0.0.zip -``` + ```bash + $ wget --content-disposition \ + https://cloud.3mdeb.com/index.php/s/RHRtf72d6MoMdy2/download \ + https://cloud.3mdeb.com/index.php/s/DqXD2So3eYrNf2y/download \ + https://cloud.3mdeb.com/index.php/s/FqH7akAq6XPaweF/download + $ unzip fwupd-novacustom-v1.0.2.zip + ``` -2. This is an example how to verify the binaries (in this case `fwupd-novacustom-v1.0.0.zip`): +1. This is an example how to verify the binaries (in this case `fwupd-novacustom-v1.0.2.zip`): -```bash -$ gpg --fetch-keys https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/master/keys/master-key/3mdeb-master-key.asc -$ gpg --fetch-keys https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/oss_master_key/open-source-software/3mdeb-open-source-software-master-key.asc -$ gpg --fetch-keys https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/master/customer-keys/novacustom/novacustom-open-source-firmware-release-1.x-key.asc + ```bash + $ gpg --fetch-keys https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/master/keys/master-key/3mdeb-master-key.asc + $ gpg --fetch-keys https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/oss_master_key/open-source-software/3mdeb-open-source-software-master-key.asc + $ gpg --fetch-keys https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/master/customer-keys/novacustom/novacustom-open-source-firmware-release-1.x-key.asc -$ sha256sum -c fwupd-novacustom-v1.0.0.zip.sha256 -$ gpg -v --verify fwupd-novacustom-v1.0.0.zip.sha256.sig fwupd-novacustom-v1.0.0.zip.sha256 -``` + $ sha256sum -c fwupd-novacustom-v1.0.2.zip.sha256 + $ gpg -v --verify fwupd-novacustom-v1.0.2.zip.sha256.sig fwupd-novacustom-v1.0.2.zip.sha256 + ``` -3. flashrom packages are located inside `flashrom-1.2-2-3mdeb.zip`: +1. flashrom packages are located inside `flashrom-1.2-2-3mdeb.zip`: -```bash -$ unzip flashrom-1.2-2-3mdeb.zip -$ sudo apt install ./flashrom_1.2-2_amd64.deb -$ sudo apt install ./libflashrom1_1.2-2_amd64.deb -$ sudo apt install ./libflashrom-dev_1.2-2_amd64.deb -``` + ```bash + $ unzip flashrom-1.2-2-3mdeb.zip + $ sudo apt install ./flashrom_1.2-2_amd64.deb + $ sudo apt install ./libflashrom1_1.2-2_amd64.deb + $ sudo apt install ./libflashrom-dev_1.2-2_amd64.deb + ``` -4. fwupd packages are located inside `fwupd-1.7.3-3mdeb.zip`: +1. fwupd packages are located inside `fwupd-1.7.3-3mdeb.zip`: -```bash -$ unzip fwupd-1.7.3-3mdeb.zip -$ sudo apt install ./fwupd_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./fwupd-doc_1.7.3+r68+gf3a5e4d1_all.deb \ - ./fwupd-tests_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./gir1.2-fwupd-2.0_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./gir1.2-fwupdplugin-1.0_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./gir1.2-gusb-1.0_0.3.5-1_amd64.deb \ - ./libfwupd2_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./libfwupd-dev_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./libfwupdplugin4_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./libfwupdplugin-dev_1.7.3+r68+gf3a5e4d1_amd64.deb \ - ./libgusb2_0.3.5-1_amd64.deb \ - ./libgusb-dev_0.3.5-1_amd64.deb -``` + ```bash + $ unzip fwupd-1.7.3.2-3mdeb.zip + $ sudo apt install ./fwupd_1.7.3+r70+ge720ed96_amd64.deb \ + ./fwupd-doc_1.7.3+r70+ge720ed96_all.deb \ + ./fwupd-tests_1.7.3+r70+ge720ed96_amd64.deb \ + ./gir1.2-fwupd-2.0_1.7.3+r70+ge720ed96_amd64.deb \ + ./gir1.2-fwupdplugin-1.0_1.7.3+r70+ge720ed96_amd64.deb \ + ./gir1.2-gusb-1.0_0.3.5-1_amd64.deb \ + ./libfwupd2_1.7.3+r70+ge720ed96_amd64.deb \ + ./libfwupd-dev_1.7.3+r70+ge720ed96_amd64.deb \ + ./libfwupdplugin4_1.7.3+r70+ge720ed96_amd64.deb \ + ./libfwupdplugin-dev_1.7.3+r70+ge720ed96_amd64.deb \ + ./libgusb2_0.3.5-1_amd64.deb \ + ./libgusb-dev_0.3.5-1_amd64.deb + ``` ### Building from source > There is no need to do any of these steps unless you can't use the packages > provided in [the previous step](#using-binary-packages) - > You might need to adjust the package manager commands and package names to > your distribution. @@ -72,131 +71,133 @@ $ sudo apt install ./fwupd_1.7.3+r68+gf3a5e4d1_amd64.deb \ 1. Install build dependencies: -```bash -$ sudo apt update -$ sudo apt install -y build-essential pciutils libpci-dev libusb-1.0-0-dev \ - cmake meson pkg-config libftdi1-dev debhelper git wget python3-markdown \ - gcab -``` + ```bash + $ sudo apt update + $ sudo apt install -y build-essential pciutils libpci-dev libusb-1.0-0-dev \ + cmake meson pkg-config libftdi1-dev debhelper git wget python3-markdown \ + gcab + ``` -2. Obtain source code: +1. Obtain source code: -```bash -$ git clone https://github.com/Dasharo/flashrom.git -b v1.2.0.1 -$ cd flashrom -``` + ```bash + $ git clone https://github.com/Dasharo/flashrom.git -b v1.2.0.1 + $ cd flashrom + ``` -3. Build and install flashrom: +1. Build and install flashrom: -```bash -$ meson build -$ ninja -C build -$ sudo ninja -C build install -``` + ```bash + $ meson build + $ ninja -C build + $ sudo ninja -C build install + ``` #### fwupd 1. Obtain source code: -```bash -$ git clone https://github.com/Dasharo/fwupd.git -b v1.7.3.1 -$ cd fwupd -``` + ```bash + $ git clone https://github.com/Dasharo/fwupd.git -b v1.7.3.2 + $ cd fwupd + ``` -2. Install build dependencies: +1. Install build dependencies: -```bash -$ ./contrib/setup -``` + ```bash + $ ./contrib/setup + ``` -3. Build and install fwupd: +1. Build and install fwupd: -```bash -$ sudo depmod -$ meson build -Ddocs=none -Dplugin_flashrom=true -$ ninja -C build -$ sudo ninja -C build install -``` + ```bash + $ sudo depmod + $ meson build -Ddocs=none -Dplugin_flashrom=true + $ ninja -C build + $ sudo ninja -C build install + ``` ## Updating firmware from LVFS +1. Disable Secure Boot. To do this you can follow steps described in + [Secure Boot test](https://docs.dasharo.com/unified-test-documentation/dasharo-security/206-secure-boot/). + 1. Use the following command to update firmware with fwupd: - *Note: You may be asked which device to update. If you see a prompt, select - NV4XMB,ME,MZ* + _Note: You may be asked which device to update. If you see a prompt, select + NV4XMB,ME,MZ_ -```bash -$ sudo fwupdmgr update + ```bash + $ sudo fwupdmgr update -Selected device: NV4XMB,ME,MZ -╔══════════════════════════════════════════════════════════════════════════════╗ -║ Update NV4XMB,ME,MZ to 0.5.0? ║ -╠══════════════════════════════════════════════════════════════════════════════╣ -║ This release adds the following features: ║ -║ ║ -║ • vboot Verified Boot ║ -║ • TPM Measured Boot ║ -║ • Custom fan curve ║ -║ • Microcode for Tiger Lake stepping 0x2 ║ -║ ║ -║ This release changes the following features: ║ -║ ║ -║ • Disabled unused DPTF device ║ -║ ║ -║ NV4XMB,ME,MZ and all connected devices may not be usable while updating. ║ -╚══════════════════════════════════════════════════════════════════════════════╝ + Selected device: NV4XMB,ME,MZ + ╔══════════════════════════════════════════════════════════════════════════════╗ + ║ Update NV4XMB,ME,MZ to 0.5.0? ║ + ╠══════════════════════════════════════════════════════════════════════════════╣ + ║ This release adds the following features: ║ + ║ ║ + ║ • vboot Verified Boot ║ + ║ • TPM Measured Boot ║ + ║ • Custom fan curve ║ + ║ • Microcode for Tiger Lake stepping 0x2 ║ + ║ ║ + ║ This release changes the following features: ║ + ║ ║ + ║ • Disabled unused DPTF device ║ + ║ ║ + ║ NV4XMB,ME,MZ and all connected devices may not be usable while updating. ║ + ╚══════════════════════════════════════════════════════════════════════════════╝ -Perform operation? [Y|n]: -Downloading… [***************************************] -Downloading… [***************************************] -Decompressing… [***************************************] -Decompressing… [***************************************] -Authenticating… [***************************************] -Authenticating… [***************************************] -Restarting device… [***************************************] -Writing… [***************************************] -Decompressing… [***************************************] -Writing… [***************************************] -Verifying… [***************************************] -Writing… [***************************************] -Restarting device… [***************************************] -Waiting… [***************************************] -Successfully installed firmware + Perform operation? [Y|n]: + Downloading… [***************************************] + Downloading… [***************************************] + Decompressing… [***************************************] + Decompressing… [***************************************] + Authenticating… [***************************************] + Authenticating… [***************************************] + Restarting device… [***************************************] + Writing… [***************************************] + Decompressing… [***************************************] + Writing… [***************************************] + Verifying… [***************************************] + Writing… [***************************************] + Restarting device… [***************************************] + Waiting… [***************************************] + Successfully installed firmware -An update requires the system to shutdown to complete. Shutdown now? [y|N]: -``` + An update requires the system to shutdown to complete. Shutdown now? [y|N]: + ``` -2. Shut down the computer when prompted, or manually later on +1. Shut down the computer when prompted, or manually later on. +1. Power on the laptop again. +1. Log in and run the following command to verify results: -3. Power on the laptop again -4. Log in and run the following command to verify results: + ```bash + $ sudo fwupdmgr get-results -```bash -$ sudo fwupdmgr get-results + Choose a device: + 0. Cancel + 1. 4bde70ba4e39b28f9eab1628f9dd6e6244c03027 (11th Gen Intel Core™ i7-1165G7 @ 2.80GHz) + 2. 5792b48846ce271fab11c4a545f7a3df0d36e00a (Display controller) + 3. 073c01931cb0e9889bbfb2ea4a4c2fc558805fc6 (Display controller) + 4. dbee8bd3b1ae0316ad143336155651eedb495a0e (NV4XMB,ME,MZ) + 5. 71b677ca0f1bc2c5b804fa1d59e52064ce589293 (SSD 980 PRO 1TB) + 6. c6a80ac3a22083423992a3cb15018989f37834d6 (TPM) + 7. eefcbd318bd31fc1eba6358e628b3f9dceb87206 (USB4 host controller) + ``` -Choose a device: -0. Cancel -1. 4bde70ba4e39b28f9eab1628f9dd6e6244c03027 (11th Gen Intel Core™ i7-1165G7 @ 2.80GHz) -2. 5792b48846ce271fab11c4a545f7a3df0d36e00a (Display controller) -3. 073c01931cb0e9889bbfb2ea4a4c2fc558805fc6 (Display controller) -4. dbee8bd3b1ae0316ad143336155651eedb495a0e (NV4XMB,ME,MZ) -5. 71b677ca0f1bc2c5b804fa1d59e52064ce589293 (SSD 980 PRO 1TB) -6. c6a80ac3a22083423992a3cb15018989f37834d6 (TPM) -7. eefcbd318bd31fc1eba6358e628b3f9dceb87206 (USB4 host controller) -``` +1. Select `NV4XMB,ME,MZ` when prompted, and the results will be displayed: -5. Select `NV4XMB,ME,MZ` when prompted, and the results will be displayed: - -```bash -NV4XMB,ME,MZ: - Device ID: dbee8bd3b1ae0316ad143336155651eedb495a0e - Previous version: 0.5.0 - Update State: Success - Last modified: 2022-01-13 11:09 - GUID: 230c8b18-8d9b-53ec-838b-6cfc0383493a - Device Flags: • Internal device - • Updatable - • System requires external power source - • Needs shutdown after installation - • Cryptographic hash verification is available -``` + ```bash + NV4XMB,ME,MZ: + Device ID: dbee8bd3b1ae0316ad143336155651eedb495a0e + Previous version: 0.5.0 + Update State: Success + Last modified: 2022-01-13 11:09 + GUID: 230c8b18-8d9b-53ec-838b-6cfc0383493a + Device Flags: • Internal device + • Updatable + • System requires external power source + • Needs shutdown after installation + • Cryptographic hash verification is available + ``` diff --git a/docs/variants/clevo_nv41/lvfs_report.md b/docs/variants/clevo_nv41/lvfs_report.md index 9f883c6f..094cf8c5 100644 --- a/docs/variants/clevo_nv41/lvfs_report.md +++ b/docs/variants/clevo_nv41/lvfs_report.md @@ -1,6 +1,6 @@ -## NovaCustom fwupd/LVFS support service +# NovaCustom fwupd/LVFS support service -### Introduction +## Introduction This document contains the report of the discovery of the most appropriate fwupd/LVFS firmware update method, including potential risks and roadblocks. diff --git a/docs/variants/clevo_nv41/openness_analysis.md b/docs/variants/clevo_nv41/openness_analysis.md index 73fd01d1..ae3857a0 100644 --- a/docs/variants/clevo_nv41/openness_analysis.md +++ b/docs/variants/clevo_nv41/openness_analysis.md @@ -2,9 +2,11 @@ This document aims to compare the openness of Dasharo Firmware and Insyde BIOS. -There is an [ongoing discussion](https://github.com/Dasharo/dasharo-issues/issues/43) about the methodology of the openness metric. +There is an +[ongoing discussion](https://github.com/Dasharo/dasharo-issues/issues/43) +about the methodology of the openness metric. -#### BIOS versions used in the analysis +## BIOS versions used in the analysis * [Dasharo coreboot v0.5.0](https://cloud.3mdeb.com/index.php/s/xM8FcCsMc8kfmKB) * [Insyde BIOS](https://cloud.3mdeb.com/index.php/s/6Pte9F9nefxQEMN) diff --git a/docs/variants/clevo_nv41/post_install.md b/docs/variants/clevo_nv41/post_install.md index b8269304..4a2f61cd 100644 --- a/docs/variants/clevo_nv41/post_install.md +++ b/docs/variants/clevo_nv41/post_install.md @@ -10,7 +10,7 @@ enable the touchpad hotkey to work under Linux, follow the steps below: 1. Create a file `/etc/udev/hwdb.d/60-keyboard.hwdb` with the following contents: - ``` + ```bash evdev:atkbd:dmi:bvn*:bvr*:svnNotebook:pnNV4XMB,ME,MZ:* KEYBOARD_KEY_f7=191 KEYBOARD_KEY_f8=191 @@ -18,7 +18,7 @@ enable the touchpad hotkey to work under Linux, follow the steps below: 1. Execute the following commands: - ``` + ```bash sudo systemd-hwdb update sudo udevadm trigger ``` diff --git a/docs/variants/clevo_nv41/releases.md b/docs/variants/clevo_nv41/releases.md index cb95a471..4843caac 100644 --- a/docs/variants/clevo_nv41/releases.md +++ b/docs/variants/clevo_nv41/releases.md @@ -6,7 +6,41 @@ Clevo NV41MZ For details about our release process please read [Dasharo Standard Release Process](../../dev-proc/standard-release-process.md). -[Subscribe to Clevo NV41MZ Dasharo Release Newsletter](https://newsletter.3mdeb.com/subscription/T61MyO2sP){ .md-button .md-button--primary .center } +[Subscribe to Clevo NV41MZ Dasharo Release Newsletter] +[newsletter]{ .md-button .md-button--primary .center } + +[newsletter]: https://newsletter.3mdeb.com/subscription/T61MyO2sP + +## v1.1.0 - 2022-03-23 + +### Added + +- Add Dasharo Tools Suite network boot integration +- Add a persistent bootlogo implementation + +### Known issues + +- [UCM-UCSI ACPI device displays an error in Windows Device Manager](https://gitlab.com/novacustom/dasharo-compatibility/-/issues/19) +- [USB4 Root Device Router device displays an error in Windows 11 Device Manager](https://gitlab.com/novacustom/dasharo-compatibility/-/issues/18) +- [Windows 10 SD card reader driver needs manual installation on NV41MB](https://gitlab.com/novacustom/dasharo-compatibility/-/issues/16) +- [Low level interfering crackling/popping of the speakers while playing no sound](https://gitlab.com/novacustom/dasharo-compatibility/-/issues/13) +- [Laptop cannot output video via the Tunderbolt 4 USB Type-C port](https://gitlab.com/novacustom/dasharo-compatibility/-/issues/7) + +### Binaries + +[clevo_nv41mz_v1.1.0.rom][v1.1.0_rom]{ .md-button } +[sha256][v1.1.0_sha]{ .md-button } +[sha256.sig][v1.1.0_sig]{ .md-button } + +[v1.1.0_rom]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.1.0.rom +[v1.1.0_sha]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.1.0.rom.sha256 +[v1.1.0_sig]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.1.0.rom.sha256.sig + +### SBOM (Software Bill of Materials) + +- [coreboot based on ae9a8447 revision 0722fdf0](https://github.com/Dasharo/coreboot/tree/0722fdf0) +- [edk2 based on 2020.03.17 revision ec6805c2](https://github.com/Dasharo/edk2/tree/ec6805c2) +- [Blobs based on v1.0 revision 39d95913](https://gitlab.com/novacustom/blobs/-/tree/39d95913) ## v1.0.1 - 2022-03-01 @@ -39,11 +73,15 @@ For details about our release process please read ### Binaries -[clevo_nv41mz_v1.0.1.rom](https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.1.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.1.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.1.rom.sha256.sig){ .md-button } +[clevo_nv41mz_v1.0.1.rom][v1.0.1_rom]{ .md-button } +[sha256][v1.0.1_sha]{ .md-button } +[sha256.sig][v1.0.1_sig]{ .md-button } -### SBOM (Software Bill of Materials): +[v1.0.1_rom]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.1.rom +[v1.0.1_sha]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.1.rom.sha256 +[v1.0.1_sig]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.1.rom.sha256.sig + +### SBOM (Software Bill of Materials) - [coreboot based on ae9a8447 revision 3a3808f9](https://github.com/Dasharo/coreboot/tree/3a3808f9) - [edk2 based on 2020.03.17 revision e0334c22](https://github.com/Dasharo/edk2/tree/e0334c22) @@ -62,7 +100,8 @@ For details about our release process please read ### Fixed - The touchpad ON/OFF switch Fn key is not functional -- Charging indicator displays wrong state if power adapter was unplugged while in sleep mode +- Charging indicator displays wrong state if power adapter was unplugged while + in sleep mode - Bluetooth does not work under Windows ### Known issues @@ -73,9 +112,13 @@ For details about our release process please read ### Binaries -[clevo_nv41mz_v1.0.0.rom](https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.0.rom){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.0.rom.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.0.rom.sha256.sig){ .md-button } +[clevo_nv41mz_v1.0.0.rom][v1.0.0_rom]{ .md-button } +[sha256][v1.0.0_sha]{ .md-button } +[sha256.sig][v1.0.0_sig]{ .md-button } + +[v1.0.0_rom]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.0.rom +[v1.0.0_sha]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.0.rom.sha256 +[v1.0.0_sig]:https://3mdeb.com/open-source-firmware/Dasharo/clevo_nv41mz/clevo_nv41mz_v1.0.0.rom.sha256.sig ### SBOM (Software Bill of Materials) @@ -110,9 +153,13 @@ For details about our release process please read ### Binaries -[dasharo_clevo_nv41mz_0.5.0.SHA256](https://cloud.3mdeb.com/index.php/s/ywZtKFR3J3Y3sbG){ .md-button } -[dasharo_clevo_nv41mz_0.5.0.SHA256.sig](https://cloud.3mdeb.com/index.php/s/6BeLRkSaawB42T6){ .md-button } -[dasharo_clevo_nv41mz_0.5.0.rom](https://cloud.3mdeb.com/index.php/s/xM8FcCsMc8kfmKB){ .md-button } +[dasharo_clevo_nv41mz_v0.5.0.rom][v0.5.0_rom]{ .md-button } +[sha256][v0.5.0_sha]{ .md-button } +[sha256.sig][v0.5.0_sig]{ .md-button } + +[v0.5.0_rom]:https://cloud.3mdeb.com/index.php/s/ywZtKFR3J3Y3sbG +[v0.5.0_sha]:https://cloud.3mdeb.com/index.php/s/6BeLRkSaawB42T6 +[v0.5.0_sig]:https://cloud.3mdeb.com/index.php/s/xM8FcCsMc8kfmKB ### SBOM (Software Bill of Materials) @@ -148,9 +195,13 @@ For details about our release process please read ### Binaries -- [dasharo_clevo_nv41mz_0.4.0.rom](https://cloud.3mdeb.com/index.php/s/MZnCrbWqaKPc8st){ .md-button } -- [dasharo_clevo_nv41mz_0.4.0.SHA256](https://cloud.3mdeb.com/index.php/s/2SkwmGFoyAf2e7d){ .md-button } -- [dasharo_clevo_nv41mz_0.4.0.SHA256.sig](https://cloud.3mdeb.com/index.php/s/HZxynzX3zDscTXr){ .md-button } +[dasharo_clevo_nv41mz_v0.4.0.rom][v0.4.0_rom]{ .md-button } +[sha256][v0.4.0_sha]{ .md-button } +[sha256.sig][v0.4.0_sig]{ .md-button } + +[v0.4.0_rom]:https://cloud.3mdeb.com/index.php/s/MZnCrbWqaKPc8st +[v0.4.0_sha]:https://cloud.3mdeb.com/index.php/s/2SkwmGFoyAf2e7d +[v0.4.0_sig]:https://cloud.3mdeb.com/index.php/s/HZxynzX3zDscTXr ### SBOM (Software Bill of Materials) @@ -179,9 +230,13 @@ For details about our release process please read ### Binaries -- [dasharo_clevo_nv41mz_0.3.0.rom](https://cloud.3mdeb.com/index.php/s/D7atioMH5Ega6JZ){ .md-button } -- [dasharo_clevo_nv41mz_0.3.0.SHA256](https://cloud.3mdeb.com/index.php/s/j7RxnDWEzreD6w3){ .md-button } -- [dasharo_clevo_nv41mz_0.3.0.SHA256.sig](https://cloud.3mdeb.com/index.php/s/NLbgZiyiMFRyZt7){ .md-button } +[dasharo_clevo_nv41mz_v0.3.0.rom][v0.3.0_rom]{ .md-button } +[sha256][v0.3.0_sha]{ .md-button } +[sha256.sig][v0.3.0_sig]{ .md-button } + +[v0.3.0_rom]:https://cloud.3mdeb.com/index.php/s/D7atioMH5Ega6JZ +[v0.3.0_sha]:https://cloud.3mdeb.com/index.php/s/j7RxnDWEzreD6w3 +[v0.3.0_sig]:https://cloud.3mdeb.com/index.php/s/NLbgZiyiMFRyZt7 ### SBOM (Software Bill of Materials) @@ -211,9 +266,13 @@ For details about our release process please read ### Binaries -- [dasharo_clevo_nv41mz_0.2.1.rom](https://cloud.3mdeb.com/index.php/s/9f9S9zNHZDYW8NM){ .md-button } -- [dasharo_clevo_nv41mz_0.2.1.rom.SHA256](https://cloud.3mdeb.com/index.php/s/q7aZz4LFA6B5byD){ .md-button } -- [dasharo_clevo_nv41mz_0.2.1.rom.SHA256.sig](https://cloud.3mdeb.com/index.php/s/YnNXcyQyfKkabDG){ .md-button } +[dasharo_clevo_nv41mz_v0.2.1.rom][v0.2.1_rom]{ .md-button } +[sha256][v0.2.1_sha]{ .md-button } +[sha256.sig][v0.2.1_sig]{ .md-button } + +[v0.2.1_rom]:https://cloud.3mdeb.com/index.php/s/9f9S9zNHZDYW8NM +[v0.2.1_sha]:https://cloud.3mdeb.com/index.php/s/q7aZz4LFA6B5byD +[v0.2.1_sig]:https://cloud.3mdeb.com/index.php/s/YnNXcyQyfKkabDG ### SBOM (Software Bill of Materials) @@ -237,7 +296,8 @@ For details about our release process please read ### Changed - Replaced CorebootPayloadPkg with Dasharo UEFIPayloadPkg -- Changed the behavior of airplane mode to match stock firmware (now it can be disabled in software) +- Changed the behavior of airplane mode to match stock firmware (now it can be + disabled in software) ### Known issues @@ -248,9 +308,13 @@ For details about our release process please read ### Binaries -- [dasharo_clevo_nv41mz_0.2.0.rom](https://cloud.3mdeb.com/index.php/s/BnWwH7X8RYinm7x){ .md-button } -- [dasharo_clevo_nv41mz_0.2.0.SHA256](https://cloud.3mdeb.com/index.php/s/xrwfNdC9PnfoMEL){ .md-button } -- [dasharo_clevo_nv41mz_0.2.0.SHA256.sig](https://cloud.3mdeb.com/index.php/s/yWitrxMRrCHYPE4){ .md-button } +[dasharo_clevo_nv41mz_v0.2.0.rom][v0.2.0_rom]{ .md-button } +[sha256][v0.2.0_sha]{ .md-button } +[sha256.sig][v0.2.0_sig]{ .md-button } + +[v0.2.0_rom]:https://cloud.3mdeb.com/index.php/s/BnWwH7X8RYinm7x +[v0.2.0_sha]:https://cloud.3mdeb.com/index.php/s/xrwfNdC9PnfoMEL +[v0.2.0_sig]:https://cloud.3mdeb.com/index.php/s/yWitrxMRrCHYPE4 ### SBOM (Software Bill of Materials) @@ -272,9 +336,16 @@ For details about our release process please read ### Binaries -[Clevo NV41MZ Dasharo](https://cloud.3mdeb.com/index.php/s/zzWBdLkF78Ax6pP/download){ .md-button } [SHA256](https://cloud.3mdeb.com/index.php/s/mYzWRma6CYQpZg6/download){ .md-button } [SHA256.sig](https://cloud.3mdeb.com/index.php/s/d6bsNzpnWyqLbqC/download){ .md-button } +[clevo_nv41mz_v0.1.2.rom][v0.1.2_rom]{ .md-button } +[sha256][v0.1.2_sha]{ .md-button } +[sha256.sig][v0.1.2_sig]{ .md-button } -[All in one zip](https://cloud.3mdeb.com/index.php/s/LXQizpTxg7C9g94/download){ .md-button } +[All in one zip][v0.1.2_aio] + +[v0.1.2_rom]:https://cloud.3mdeb.com/index.php/s/zzWBdLkF78Ax6pP/download +[v0.1.2_sha]:https://cloud.3mdeb.com/index.php/s/mYzWRma6CYQpZg6/download +[v0.1.2_sig]:https://cloud.3mdeb.com/index.php/s/d6bsNzpnWyqLbqC/download +[v0.1.2_aio]:https://cloud.3mdeb.com/index.php/s/LXQizpTxg7C9g94/download ### SBOM (Software Bill of Materials) diff --git a/docs/variants/clevo_nv41/testing_configuration.md b/docs/variants/clevo_nv41/testing_configuration.md index 88a82fed..286fd7a8 100644 --- a/docs/variants/clevo_nv41/testing_configuration.md +++ b/docs/variants/clevo_nv41/testing_configuration.md @@ -9,25 +9,25 @@ coreboot port. ## NV41MZ #1 -- SSD: NVMe Samsung 980 PRO 250GB -- Memory: - + Slot 1: KVR29S21S6/8 - + Slot 2: KVR29S21S6/8 -- Monitor: HDMI 1920x1080p -- USB: - + Pi-KVM virtual mouse and keyboard - + USB SanDisk 3.2Gen1 16 GB +1. SSD: NVMe Samsung 980 PRO 250GB. +1. Memory: + * Slot 1: KVR29S21S6/8, + * Slot 2: KVR29S21S6/8. +1. Monitor: HDMI 1920x1080p. +1. USB: + * Pi-KVM virtual mouse and keyboard, + * USB SanDisk 3.2Gen1 16 GB. ## NV41MZ #2 -- SSD: NVMe Samsung 980 PRO 250GB -- Memory: - + Slot 1: KVR29S21S8/16 - + Slot 2: KVR29S21S8/16 +1. SSD: NVMe Samsung 980 PRO 250GB. +1. Memory: + * Slot 1: KVR29S21S8/16, + * Slot 2: KVR29S21S8/16. ## NV41MB #1 -- SSD: NVMe Samsung 980 PRO 250GB -- Memory: - + Slot 1: KVR29S21D8/32 - + Slot 2: KVR29S21D8/32 +1. SSD: NVMe Samsung 980 PRO 250GB. +1. Memory: + * Slot 1: KVR29S21D8/32, + * Slot 2: KVR29S21D8/32. diff --git a/docs/variants/dell_optiplex/initial-deployment.md b/docs/variants/dell_optiplex/initial-deployment.md index cb0565a5..7b969316 100644 --- a/docs/variants/dell_optiplex/initial-deployment.md +++ b/docs/variants/dell_optiplex/initial-deployment.md @@ -138,7 +138,7 @@ questionable redistributability. To avoid potential issues we transfer non-redistributable components from your original BIOS to Dell OptiPlex 9010 Dasharo binary using [fwdeploy](https://github.com/Dasharo/fwdeploy). -``` +```bash $ wget https://raw.githubusercontent.com/Dasharo/fwdeploy/main/run.sh $ chmod +x run.sh $ ./run.sh @@ -231,8 +231,8 @@ If you will face any issues please refer to [troubleshooting section](#troublesh 2. Shut down machine, move the jumper to the original place 3. Power on the machine. 4. After rebooting, you should see the Dasharo Workstation logo when booting. - When the logo appears, you may press ++esc++ to select the boot device if you want to - reboot from another source. + When the logo appears, you may press ++esc++ to select the boot device if + you want to reboot from another source. ![](../../images/dasharo-black.jpg) diff --git a/docs/variants/dell_optiplex/releases.md b/docs/variants/dell_optiplex/releases.md index 672dc40b..80f1c619 100644 --- a/docs/variants/dell_optiplex/releases.md +++ b/docs/variants/dell_optiplex/releases.md @@ -6,7 +6,8 @@ Dell OptiPlex 7010 SFF, DT and Dell OptiPlex 9010 SFF. For details about our release process please read [Dasharo Standard Release Process](../../dev-proc/standard-release-process.md). -[Subscribe to Dell OptiPlex 7010/9010 Dasharo Release Newsletter](https://newsletter.3mdeb.com/subscription/8dp1vv5mR){ .md-button .md-button--primary .center } +[Subscribe to Dell OptiPlex 7010/9010 Dasharo Release Newsletter](https://newsletter.3mdeb.com/subscription/8dp1vv5mR) +{ .md-button .md-button--primary .center } ## Unreleased @@ -56,9 +57,11 @@ Software BOM: ### Binaries -[Dell OptiPlex 7010/9010 Dasharo](#){ .md-button } [SHA256](#){ .md-button } [SHA256.sig](#){ .md-button } +[Dell OptiPlex 7010/9010 Dasharo](TBD){ .md-button } +[SHA256](TBD){ .md-button } +[SHA256.sig](TBD){ .md-button } -[All in one zip](#){ .md-button } +[All in one zip](TBD){ .md-button } ### SBOM (Software Bill of Materials) diff --git a/docs/variants/novacustom_ns5x/building.md b/docs/variants/novacustom_ns5x/building.md new file mode 100644 index 00000000..7d8c13b0 --- /dev/null +++ b/docs/variants/novacustom_ns5x/building.md @@ -0,0 +1,52 @@ +# Dasharo for NovaCustom NS5X - Building manual + +## Intro + +This documents describes the procedure for compiling coreboot for NovaCustom NS5X. + +## Requirements + +- Docker + + follow [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/) + + follow [Post-installation steps for Linux](https://docs.docker.com/engine/install/linux-postinstall/) +- Git + +## Procedure + +The easiest way to build coreboot is to use the official Docker image. + +Obtain the image: + +```bash +$ docker pull coreboot/coreboot-sdk:0ad5fbd48d +``` + +Obtain coreboot source code for NovaCustom NS5X: + +```bash +$ git clone https://github.com/Dasharo/coreboot.git +``` + +Navigate to the source code directory and checkout to the desired revision: + +> Replace the REVISION with one of the: +> - `novacustom_ns5x/release` for the latest released version +> - `novacustom_ns5x/vVERSION` (e.g. `v1.0.0`) for the given release + +```bash +$ cd coreboot +$ git checkout REVISION +$ git submodule update --init --recursive --checkout +``` + +```bash +$ ./build.sh build +``` + +The resulting coreboot image will be placed in +`artifacts/dasharo_novacustom_ns5x_VERSION.rom`. + +**Warning**: Do not run `./build.sh` as root. This command uses docker and should +be executed as your current user. If you're having trouble running `build.sh` +on your user account, follow the `Docker` instructions outlined in +[Requirements](#requirements).* diff --git a/docs/variants/novacustom_ns5x/installation.md b/docs/variants/novacustom_ns5x/installation.md new file mode 100644 index 00000000..48833e0e --- /dev/null +++ b/docs/variants/novacustom_ns5x/installation.md @@ -0,0 +1,87 @@ +# Dasharo for NovaCustom NS5X - Installation manual + +## Intro + +Flashing coreboot can be done from Linux using flashrom with the internal +programmer. This document describes the process of building, installing and +running flashrom on Ubuntu 20.04. + +## Build flashrom + +Currently, the latest flashrom release lacks support for Tiger Lake-U internal +flashing. Because of this, we need to build flashrom from source. + +Install build dependencies: + +```bash +# apt install git build-essential debhelper pkg-config libpci-dev libusb-1.0-0-dev libftdi1-dev meson +``` + +Obtain source code: + +```bash +$ git clone https://review.coreboot.org/flashrom.git +$ cd flashrom +``` + +Build flashrom: + +```bash +$ make +$ sudo make install +``` + +## Reading flash contents + +To read from the flash and save them to a file (`dump.rom`), execute the +following command: + +```bash +# flashrom -p internal -r dump.rom +``` + +## Installing Dasharo + +### Initial Installation + +During initial installation of Dasharo, you should deploy supported Intel ME +version (and configuration) on the device. + +> Publicly released binaries do not contain ME binary. If you need an Intel ME +> update for your device, contact us via already established commercial support +> channel. + +When flashing binaries with ME binary included, flashing of the whole chip is +required. Additionally, the firmware has to be flashed externally using an +external programmer like a `ch341a_spi`. + +![ns50mu chips](../../images/ns50mu_board_chips.jpg) + +Steps for initial Dasharo installation: + +- Open the laptop +- Disconnect the primary battery (1) +- Disconnect the CMOS battery (2) +- Attach an external programmer with a SOIC-8 clip to the SPI flash chip (3) +- Execute the following command, replaceing [path] with the path to the firmware + image you want to flash, e.g. `novacustom_ns5x_full_v1.0.0.rom` + + ```bash + # flashrom -p ch341a_spi -w [path] + ``` + +- Detach the SOIC-8 clip +- Connect the primary battery (1) - do **not** connect the CMOS battery yet (2) +- Power on the laptop. The laptop may shut down once after training the memory. +- Once Dasharo is booted, shut down the laptop and reconnect the CMOS battery. + +### Updating Dasharo + +If Dasharo is currently installed, only the RW_SECTION_A partition of the flash +needs to be updated. Flash it using the following command: + +```bash +# flashrom -p internal -w [path] --fmap -i RW_SECTION_A +``` + +This command also preserves UEFI settings and the boot order. diff --git a/docs/variants/novacustom_ns5x/post_install.md b/docs/variants/novacustom_ns5x/post_install.md new file mode 100644 index 00000000..88f9b1f2 --- /dev/null +++ b/docs/variants/novacustom_ns5x/post_install.md @@ -0,0 +1,27 @@ +# Post-installation setup + +This document contains extra steps to perform after installing Dasharo in order +to enable full functionality. + +## Touchpad hotkey enablement (Linux) + +The touchpad hotkey needs extra setup to function correctly under Linux. To +enable the touchpad hotkey to work under Linux, follow the steps below: + +1. Create a file `/etc/udev/hwdb.d/60-keyboard.hwdb` with the following contents: + + ```bash + evdev:atkbd:dmi:bvn*:bvr*:svnNotebook:pnNS50_70MU:* + KEYBOARD_KEY_f7=191 + KEYBOARD_KEY_f8=191 + ``` + +1. Execute the following commands: + + ```bash + sudo systemd-hwdb update + sudo udevadm trigger + ``` + +After executing these steps, it should be possible to enable and disable the +touchpad using the touchpad hotkey (Fn+F1) on the keyboard when using GNOME. diff --git a/docs/variants/novacustom_ns5x/releases.md b/docs/variants/novacustom_ns5x/releases.md new file mode 100644 index 00000000..f20158c9 --- /dev/null +++ b/docs/variants/novacustom_ns5x/releases.md @@ -0,0 +1,43 @@ +# NovaCustom NS5x Dasharo Release Notes + +Following Release Notes describe status of Open Source Firmware development for +NovaCustom NS5x + +For details about our release process please read +[Dasharo Standard Release Process](../../dev-proc/standard-release-process.md). + +[Subscribe to NovaCustom NS5x Dasharo Release Newsletter] +[newsletter]{ .md-button .md-button--primary .center } + +[newsletter]: https://newsletter.3mdeb.com/subscription/T61MyO2sP + +## v1.0.0 - 2022-03-23 + +### Added + +- Support for NovaCustom NS5x +- Support for EC firmware 1.07.07 +- UEFI Boot Support +- Configurable boot order +- Configurable boot options +- UEFI Secure Boot support +- NovaCustom boot logo + +### Known issues + +- [The touchpad ON/OFF switch Fn key is not functional](https://github.com/Dasharo/dasharo-issues/issues/38) + +### Binaries + +[novacustom_ns5x_v1.0.0.rom][v1.0.0_rom]{ .md-button } +[sha256][v1.0.0_sha]{ .md-button } +[sha256.sig][v1.0.0_sig]{ .md-button } + +[v1.0.0_rom]:https://3mdeb.com/open-source-firmware/Dasharo/novacustom_ns5x/novacustom_ns5x_v1.0.0.rom +[v1.0.0_sha]:https://3mdeb.com/open-source-firmware/Dasharo/novacustom_ns5x/novacustom_ns5x_v1.0.0.rom.sha256 +[v1.0.0_sig]:https://3mdeb.com/open-source-firmware/Dasharo/novacustom_ns5x/novacustom_ns5x_v1.0.0.rom.sha256.sig + +### SBOM (Software Bill of Materials) + +- [coreboot based on 4.16 revision ecf1e9b8](https://github.com/Dasharo/coreboot/tree/ecf1e9b8) +- [tianocore based on e0334c228ce4ba51f47ff79a118f214031d4650f revision ec6805c2](https://github.com/Dasharo/edk2/tree/ec6805c2) diff --git a/docs/variants/protectli_vp4620/building-manual.md b/docs/variants/protectli_vp4620/building-manual.md new file mode 100644 index 00000000..411b1830 --- /dev/null +++ b/docs/variants/protectli_vp4620/building-manual.md @@ -0,0 +1,17 @@ +# Protectli Dasharo on VP4620 - building manual + +To build Dasharo firmware image, follow the steps below: + +1. Clone the coreboot repository: + + ```bash + $ git clone https://github.com/Dasharo/coreboot.git -b protectli_vault_cml/release + ``` + +2. Start build process (note it requires certain blobs to proceed): + + ```bash + $ cd coreboot + # you will need to put the ZIP with blobs at this point + $ ./build.sh vp4620 + ``` diff --git a/docs/variants/protectli_vp4620/hardware-matrix.md b/docs/variants/protectli_vp4620/hardware-matrix.md new file mode 100644 index 00000000..525ea327 --- /dev/null +++ b/docs/variants/protectli_vp4620/hardware-matrix.md @@ -0,0 +1,32 @@ +# Hardware configuration matrix + +## Introduction + +This document describes the hardware configurations used for validation of the +coreboot port. + +## Protectli VP4620 Dasharo v1.0.13 + +1. CPU: Intel Core i7-10510U +1. SSD: + * M.2 SSD SATA: Hoodisk SSL032GTTC7-S9A-2S + * M.2 SSD PCIE4X: Samsung MZVLB256HBHQ-00000 + * external SATA 2.5 inch: Goodram SSDPR-CL100-240-G2 240GB +1. Memory (all possible combinations in 2 slots for HCL): + * CRUCIAL CT4G4SFS824A + * SAMSUNG M471A4G43MB1-CTD + * SAMSUNG M471A1K43CB1-CTD + * SAMSUNG M471A5244BB0-CRC + * KINGSTON KVR24S17S8/8 + * KINGSTON KVR26S19S8/16 +1. Wireless card: Intel Wi-Fi 6 AX201 +1. LTE miniPCIe card: Quectel EC-20 +1. Display: HDMI 1920x1080p, DP 1920x1080p +1. Ethernet: 6x intel i225 (on-board) +1. USB: + * USB mass storage device x3: USB SanDisk 3.2Gen1 16 GB + * USB-C Hub with display: USB Type-C Hub Pro UCN3286 +1. USB Keyboard: DELL KB216 +1. MMC drive: SAMSUNG KLM8G1GETF-B041 (on-board) +1. TPM: PC Engines TPM1A LPC TPM +1. Power supply: Channel Well Technology 12V, 7.5A 90W diff --git a/docs/variants/protectli_vp4620/installation-manual.md b/docs/variants/protectli_vp4620/installation-manual.md new file mode 100644 index 00000000..1556eed0 --- /dev/null +++ b/docs/variants/protectli_vp4620/installation-manual.md @@ -0,0 +1,72 @@ +# Protectli Dasharo on VP4620 - installation manual + +Flashing coreboot can be done from Linux using flashrom with the internal +programmer. This document describes the process of building, installing and +running flashrom on Ubuntu 20.04. + +## Build flashrom + +Currently, the latest flashrom release lacks support for Comet Lake U internal +flashing. Because of this, we need to build flashrom from source. + +Install build dependencies: + +```bash +apt install git build-essential debhelper pkg-config libpci-dev libusb-1.0-0-dev libftdi1-dev meson +``` + +Obtain source code: + +```bash +$ git clone https://review.coreboot.org/flashrom.git +$ cd flashrom +``` + +Build flashrom: + +```bash +$ make +$ sudo make install +``` + +## Reading flash contents + +Always prepare a backup of the current firmware image. To read from the flash +and save them to a file (`dump.rom`), execute the following command: + +```bash +flashrom -p internal -r dump.rom +``` + +## Flashing Dasharo + +To flash Dasharo on the platform, execute the following command - replace `[path]` +with the path to the Dasharo image you want to flash, e.g. `protectli_vault_cml_v1.0.13.rom`. + +If stock firmware is currently installed: + +```bash +flashrom -p internal -w protectli_vault_cml_v1.0.13.rom +``` + +This will flash the full image including Intel ME. The operation requires a +hard reset of the platform. To perform a hard reset: + +1. Power off the platform. Note, it may not power off completely due to flashed + ME. +2. Disconnect power supply from the board when OS finishes all tasks before + power off (the screen goes dark or black). +3. Disconnect the RTC/CMOS battery OR clear the CMOS using the pin header + located near memory slots. Wait about half a minute (unshort the pins). +4. Connect the power supply back. +5. The platform should power on normally now. You can connect the battery back + if it was disconnected. + +If Dasharo is currently installed, only the COREBOOT partition of the flash +needs to be updated. Flash it using the following command: + +```bash +flashrom -p internal -w protectli_vault_cml_v1.0.13.rom --fmap -i COREBOOT +``` + +This command also preserves Dasharo UEFI settings and the boot order. diff --git a/docs/variants/protectli_vp4620/releases.md b/docs/variants/protectli_vp4620/releases.md new file mode 100644 index 00000000..e21d3ed4 --- /dev/null +++ b/docs/variants/protectli_vp4620/releases.md @@ -0,0 +1,47 @@ +# Protectli VP4620 Dasharo Release Notes + +Following Release Notes describe status of Open Source Firmware development for +Protectli VP4620 + +For details about our release process please read +[Dasharo Standard Release Process](../../dev-proc/standard-release-process.md). + +
+[Subscribe to Protectli VP4620 Dasharo Release Newsletter] +[newsletter]{.md-button .md-button--primary .center} +
+ +## v1.0.13 - 2022-03-22 + +### Added + +- UEFI boot support +- i225 network controller network boot support +- Customized boot menu keys +- Customized setup menu keys +- Configurable boot order +- Configurable boot options + +### Changed + +- ME version to 14.0.47.1558 + +### Known issues + +- [i225 network controller initialization takes too much time](https://github.com/Dasharo/dasharo-issues/issues/65) + +### Binaries + +[protectli_vault_cml_v1.0.13.rom][v1.0.13_rom]{.md-button} +[sha256][v1.0.13_hash]{.md-button} +[sha256.sig][v1.0.13_sig]{.md-button} + +### SBOM (Software Bill of Materials) + +- [coreboot based on 4.16 revision 546e1c86](https://github.com/Dasharo/coreboot/tree/546e1c86) +- [edk2 based on 7f90b9cd revision 7f90b9cd](https://github.com/Dasharo/edk2/tree/7f90b9cd) + +[newsletter]: https://newsletter.3mdeb.com/subscription/n2EpSxtqL +[v1.0.13_rom]: https://3mdeb.com/open-source-firmware/Dasharo/protectli_vault_cml/protectli_vault_cml_v1.0.13.rom +[v1.0.13_hash]: https://3mdeb.com/open-source-firmware/Dasharo/protectli_vault_cml/protectli_vault_cml_v1.0.13.rom.sha256 +[v1.0.13_sig]: https://3mdeb.com/open-source-firmware/Dasharo/protectli_vault_cml/protectli_vault_cml_v1.0.13.rom.sha256.sig diff --git a/docs/variants/talos_2/building-manual.md b/docs/variants/talos_2/building-manual.md index 3cd1e182..f9258ebe 100644 --- a/docs/variants/talos_2/building-manual.md +++ b/docs/variants/talos_2/building-manual.md @@ -19,7 +19,7 @@ To build coreboot image, follow the steps below: 1. Start docker container: - ``` + ```bash $ docker run --rm -it \ -v $PWD:/home/coreboot/coreboot \ -w /home/coreboot/coreboot \ @@ -28,7 +28,7 @@ To build coreboot image, follow the steps below: 1. Inside of the container, configure and start the build process: - ``` + ```bash (docker)$ cp configs/config.raptor-cs-talos-2 .config (docker)$ make olddefconfig (docker)$ make @@ -44,7 +44,7 @@ To build coreboot image, follow the steps below: 1. Start docker container: - ``` + ```bash $ docker run --rm -it -v $PWD:$PWD -w $PWD 3mdeb/heads-docker:2.3.0 /bin/bash ``` diff --git a/docs/variants/talos_2/hardware-matrix.md b/docs/variants/talos_2/hardware-matrix.md index 7adc2e43..170fb2f4 100644 --- a/docs/variants/talos_2/hardware-matrix.md +++ b/docs/variants/talos_2/hardware-matrix.md @@ -5,7 +5,7 @@ Dual CPU setup not supported currently. Following RAM configurations were tested and are proved to be properly initialized. -``` +```bash MCS0, MCA0 DIMM0: 1Rx4 16GB PC4-2666V-RC2-12-PA0 DIMM1: not installed diff --git a/docs/variants/talos_2/releases.md b/docs/variants/talos_2/releases.md index dcf8aff6..82826368 100644 --- a/docs/variants/talos_2/releases.md +++ b/docs/variants/talos_2/releases.md @@ -6,7 +6,14 @@ Raptor Computing Systems Talos II For details about our release process please read [Dasharo Standard Release Process](../../dev-proc/standard-release-process.md). -[Subscribe to Raptor Computing Systems Talos II Dasharo Release Newsletter]( https://newsletter.3mdeb.com/subscription/w2Y2G4Rrj){ .md-button .md-button--primary .center } +
+ +[Subscribe to Release Newsletter][newsletter] +{ .md-button .md-button--primary .center } + +[newsletter]: https://newsletter.3mdeb.com/subscription/w2Y2G4Rrj + +
## v0.4.1 - 2022-01-10 @@ -31,17 +38,29 @@ For details about our release process please read ### Binaries -[dasharo_talos_2_bootblock_v0.4.1.signed.ecc](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_bootblock_v0.4.1.signed.ecc){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_bootblock_v0.4.1.signed.ecc.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_bootblock_v0.4.1.signed.ecc.sha256.sig){ .md-button } +[dasharo_talos_2_bootblock_v0.4.1.signed.ecc][v0.4.1_bootblock_rom]{ .md-button } +[sha256][v0.4.1_bootblock_sha]{ .md-button } +[sha256.sig][v0.4.1_bootblock_sig]{ .md-button } -[dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc.sha256.sig){ .md-button } +[v0.4.1_bootblock_rom]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_bootblock_v0.4.1.signed.ecc +[v0.4.1_bootblock_sha]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_bootblock_v0.4.1.signed.ecc.sha256 +[v0.4.1_bootblock_sig]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_bootblock_v0.4.1.signed.ecc.sha256.sig -[dasharo_talos_2_zImage_v0.4.1.bundled](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_zImage_v0.4.1.bundled){ .md-button } -[sha256](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_zImage_v0.4.1.bundled.sha256){ .md-button } -[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_zImage_v0.4.1.bundled.sha256.sig){ .md-button } +[dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc][v0.4.1_rom]{ .md-button } +[sha256][v0.4.1_sha]{ .md-button } +[sha256.sig][v0.4.1_sig]{ .md-button } + +[v0.4.1_rom]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc +[v0.4.1_sha]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc.sha256 +[v0.4.1_sig]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_coreboot_v0.4.1.rom.signed.ecc.sha256.sig + +[dasharo_talos_2_zImage_v0.4.1.bundled][v0.4.1_bundled_rom]{ .md-button } +[sha256][v0.4.1_bundled_sha]{ .md-button } +[sha256.sig][v0.4.1_bundled_sig]{ .md-button } + +[v0.4.1_bundled_rom]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_zImage_v0.4.1.bundled +[v0.4.1_bundled_sha]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_zImage_v0.4.1.bundled.sha256 +[v0.4.1_bundled_sig]: https://3mdeb.com/open-source-firmware/Dasharo/raptor-cs_talos-2/dasharo_talos_2_zImage_v0.4.1.bundled.sha256.sig ### SBOM (Software Bill of Materials) @@ -68,17 +87,29 @@ For details about our release process please read ### Binaries -[dasharo_talos_2_bootblock_v0.4.0.signed.ecc](https://cloud.3mdeb.com/index.php/s/54MDtRgBNEmyKo6){ .md-button } -[sha256](https://cloud.3mdeb.com/index.php/s/DwpWdgfZyD9StBW){ .md-button } -[sha256.sig](https://cloud.3mdeb.com/index.php/s/5xawXEissBZN6rT){ .md-button } +[dasharo_talos_2_bootblock_v0.4.0.signed.ecc][v0.4.0_bootblock_rom]{ .md-button } +[sha256][v0.4.0_bootblock_sha]{ .md-button } +[sha256.sig][v0.4.0_bootblock_sig]{ .md-button } -[dasharo_talos_2_coreboot.rom.signed.ecc](https://cloud.3mdeb.com/index.php/s/5Pbw5EtmNimrdrj){ .md-button } -[sha256](https://cloud.3mdeb.com/index.php/s/TNcLAz3CZo4QzeD){ .md-button } -[sha256.sig](https://cloud.3mdeb.com/index.php/s/9Fr6Kn57mP2bbwS){ .md-button } +[v0.4.0_bootblock_rom]: https://cloud.3mdeb.com/index.php/s/54MDtRgBNEmyKo6 +[v0.4.0_bootblock_sha]: https://cloud.3mdeb.com/index.php/s/DwpWdgfZyD9StBW +[v0.4.0_bootblock_sig]: https://cloud.3mdeb.com/index.php/s/5xawXEissBZN6rT -[zImage_v0.4.0.bundled](https://cloud.3mdeb.com/index.php/s/o5RE7oj4r9kFXS2){ .md-button } -[sha256](https://cloud.3mdeb.com/index.php/s/FgeHfa4LzcZK6Pj){ .md-button } -[sha256.sig](https://cloud.3mdeb.com/index.php/s/awNSefJrN4d2tAD){ .md-button } +[dasharo_talos_2_coreboot.rom.signed.ecc][v0.4.0_coreboot_rom]{ .md-button } +[sha256][v0.4.0_coreboot_sha]{ .md-button } +[sha256.sig][v0.4.0_coreboot_sig]{ .md-button } + +[v0.4.0_coreboot_rom]: https://cloud.3mdeb.com/index.php/s/5Pbw5EtmNimrdrj +[v0.4.0_coreboot_sha]: https://cloud.3mdeb.com/index.php/s/TNcLAz3CZo4QzeD +[v0.4.0_coreboot_sig]: https://cloud.3mdeb.com/index.php/s/9Fr6Kn57mP2bbwS + +[zImage_v0.4.0.bundled][v0.4.0_bundled_rom]{ .md-button } +[sha256][v0.4.0_bundled_sha]{ .md-button } +[sha256.sig][v0.4.0_bundled_sig]{ .md-button } + +[v0.4.0_bundled_rom]: https://cloud.3mdeb.com/index.php/s/o5RE7oj4r9kFXS2 +[v0.4.0_bundled_sha]: https://cloud.3mdeb.com/index.php/s/FgeHfa4LzcZK6Pj +[v0.4.0_bundled_sig]: https://cloud.3mdeb.com/index.php/s/awNSefJrN4d2tAD ### SBOM (Software Bill of Materials) diff --git a/docs/variants/trustworthy-computing.md b/docs/variants/trustworthy-computing.md index de8a4085..abf430cd 100644 --- a/docs/variants/trustworthy-computing.md +++ b/docs/variants/trustworthy-computing.md @@ -1,3 +1,4 @@ # Dasharo Trustworthy Computing -TBD: move all information related to Insurgo Dasharo Trustworthy Computing POWER9 support +TBD: move all information related to Insurgo Dasharo Trustworthy Computing +POWER9 support diff --git a/docs/variants/tuxedo_ibs15/building.md b/docs/variants/tuxedo_ibs15/building.md index c36e69fc..8f2f6757 100644 --- a/docs/variants/tuxedo_ibs15/building.md +++ b/docs/variants/tuxedo_ibs15/building.md @@ -7,8 +7,8 @@ This documents describes the procedure for compiling coreboot for Tuxedo IBS15. ## Requirements - Docker - - follow [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/) - - follow [Post-installation steps for Linux](https://docs.docker.com/engine/install/linux-postinstall/) + + follow [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/) + + follow [Post-installation steps for Linux](https://docs.docker.com/engine/install/linux-postinstall/) - Git ## Procedure @@ -46,7 +46,7 @@ $ ./build.sh build The resulting coreboot image will be placed in `artifacts/dasharo_tuxedo_ibs15_VERSION.rom`. -*Warning: Do not run `./build.sh` as root. This command uses docker and should +_Warning: Do not run `./build.sh` as root. This command uses docker and should be executed as your current user. If you're having trouble running `build.sh` on your user account, follow the `Docker` instructions outlined in -[Requirements](#requirements).* +[Requirements](#requirements)._ diff --git a/docs/variants/tuxedo_ibs15/installation.md b/docs/variants/tuxedo_ibs15/installation.md index 0dafd66e..3e310ba0 100644 --- a/docs/variants/tuxedo_ibs15/installation.md +++ b/docs/variants/tuxedo_ibs15/installation.md @@ -40,16 +40,42 @@ following command: # flashrom -p internal -r dump.rom ``` -## Flashing coreboot +## Installing Dasharo -To flash coreboot to the laptop, execute the following command - replace [path] -with the path to the coreboot image you want to flash, e.g. `build/coreboot.rom`. +### Initial Installation -If stock firmware is currently installed: +During initial installation of Dasharo, you should deploy supported Intel ME +version (and configuration) on the device. -```bash -# flashrom -p internal -w [path] --ifd -i bios -``` +> Publicly released binaries do not contain ME binary. If you need an Intel ME +> update for your device, contact us via already established commercial support +> channel. + +When flashing binaries with ME binary included, flashing of the whole chip is +required. Additionally, the firmware has to be flashed externally using an +external programmer like a `ch341a_spi`. + +![ns50mu chips](../../images/ns50mu_board_chips.jpg) + +Steps for initial Dasharo installation: + +- Open the laptop +- Disconnect the primary battery (1) +- Disconnect the CMOS battery (2) +- Attach an external programmer with a SOIC-8 clip to the SPI flash chip (3) +- Execute the following command, replaceing [path] with the path to the firmware + image you want to flash, e.g. `tuxedo_ibs15_full_v1.0.0.rom` + + ```bash + # flashrom -p ch341a_spi -w [path] + ``` + +- Detach the SOIC-8 clip +- Connect the primary battery (1) - do **not** connect the CMOS battery yet (2) +- Power on the laptop. The laptop may shut down once after training the memory. +- Once Dasharo is booted, shut down the laptop and reconnect the CMOS battery. + +### Updating Dasharo If Dasharo is currently installed, only the RW_SECTION_A partition of the flash needs to be updated. Flash it using the following command: diff --git a/docs/variants/tuxedo_ibs15/post_install.md b/docs/variants/tuxedo_ibs15/post_install.md index b3df6cb8..fb7dc0d7 100644 --- a/docs/variants/tuxedo_ibs15/post_install.md +++ b/docs/variants/tuxedo_ibs15/post_install.md @@ -9,13 +9,16 @@ The touchpad hotkey needs extra setup to function correctly under Linux. To enable the touchpad hotkey to work under Linux, follow the steps below: 1. Create a file `/etc/udev/hwdb.d/60-keyboard.hwdb` with the following contents: - ``` + + ```bash evdev:atkbd:dmi:bvn*:bvr*:svnNotebook:pnNS50MU:* KEYBOARD_KEY_f7=191 KEYBOARD_KEY_f8=191 ``` + 1. Execute the following commands: - ``` + + ```bash sudo systemd-hwdb update sudo udevadm trigger ``` diff --git a/docs/variants/tuxedo_ibs15/releases.md b/docs/variants/tuxedo_ibs15/releases.md index c86e4b0a..cf951a50 100644 --- a/docs/variants/tuxedo_ibs15/releases.md +++ b/docs/variants/tuxedo_ibs15/releases.md @@ -6,4 +6,40 @@ Tuxedo IBS15 For details about our release process please read [Dasharo Standard Release Process](../../dev-proc/standard-release-process.md). -[Subscribe to Tuxedo IBS15 Dasharo Release Newsletter](https://newsletter.3mdeb.com/subscription/FIXME){ .md-button .md-button--primary .center } +
+ +[Subscribe to Tuxedo IBS15 Dasharo Release Newsletter](https://newsletter.3mdeb.com/subscription/7IPf_aUHR) +{ .md-button .md-button--primary .center } + +
+ +## v1.0.0 - 2022-03-15 + +### Added + +- Support for Tuxedo InfinityBook S 15 Gen6 +- Support for EC firmware 1.07.02 +- Support for Intel ME version 15.0.30.1776 +- UEFI Boot Support +- Configurable boot order +- Configurable boot options +- UEFI Secure Boot support +- Tuxedo boot logo + +### Known issues + +- [The touchpad ON/OFF switch Fn key is not functional](https://github.com/Dasharo/dasharo-issues/issues/38) + +### Binaries + +[tuxedo_ibs15_v1.0.0.rom](https://3mdeb.com/open-source-firmware/Dasharo/tuxedo_ibs15/tuxedo_ibs15_v1.0.0.rom +){ .md-button } +[sha256](https://3mdeb.com/open-source-firmware/Dasharo/tuxedo_ibs15/tuxedo_ibs15_v1.0.0.rom.sha256 +){ .md-button } +[sha256.sig](https://3mdeb.com/open-source-firmware/Dasharo/tuxedo_ibs15/tuxedo_ibs15_v1.0.0.rom.sha256.sig +){ .md-button } + +### SBOM (Software Bill of Materials) + +- [coreboot based on 4.16 revision cf13d6c7](https://github.com/Dasharo/coreboot/commit/cf13d6c7) +- [tianocore based on 9522071f7497a1a0b1077d2b0d5fcc97a126cfd0 revision 7f90b9cd](https://github.com/Dasharo/edk2/commit/7f90b9cd) diff --git a/docs/variants/tuxedo_ibs15/testing-configuration.md b/docs/variants/tuxedo_ibs15/testing-configuration.md new file mode 100644 index 00000000..55b1fee8 --- /dev/null +++ b/docs/variants/tuxedo_ibs15/testing-configuration.md @@ -0,0 +1,42 @@ +# Hardware configuration matrix + +## Introduction + +This document describes the hardware configurations used for validation of the +coreboot port. + +## InfinityBook S 15 #1 (used during testing procedure) + +1. CPU: Intel Core i5-1135G7. +1. SSD: + * M.2 SSD PCIE4X/SATA: Samsung 860 EVO SATA M.2 250 GB, + * M.2 SSD PCIE4X: Samsung 980 PRO NVMe M.2 250 GB. +1. Memory: + * Slot 1: Kingston 8 GB KVR29S21S6/8, + * Slot 2: Kingston 4 GB KVR29S21S6/4. +1. Wireless card: Intel Wi-Fi 6 AX201. +1. Monitor: HDMI 1920x1080p. +1. USB: + * 2x USB SanDisk 3.2Gen1 16 GB, + * Kingston DataTraveler 3.1Gen1 16 GB. +1. USB Keyboard: DELL KB216. +1. SD Card: SanDisk MicroSDHC 16 GB. +1. Headset: Sony MDR-EX15AP. + +## InfinityBook S 15 #2 + +1. CPU: Intel Core i5-1130H. +1. SSD: + * M.2 SSD PCIE4X/SATA: Samsung 860 EVO SATA M.2 250 GB, + * M.2 SSD PCIE4X: Samsung 980 PRO NVMe M.2 250 GB. +1. Memory: + * Slot 1: Kingston 8 GB KVR29S21S6/8, + * Slot 2: Kingston 4 GB KVR29S21S6/4. +1. Wireless card: Intel Wi-Fi 6 AX201. +1. Monitor: HDMI 1920x1080p. +1. USB: + * 2x USB SanDisk 3.2Gen1 16 GB, + * Kingston DataTraveler 3.1Gen1 16 GB. +1. USB Keyboard: DELL KB216. +1. SD Card: SanDisk MicroSDHC 16 GB. +1. Headset: Sony MDR-EX15AP. diff --git a/docs/variants/workstation.md b/docs/variants/workstation.md deleted file mode 100644 index 721e5f04..00000000 --- a/docs/variants/workstation.md +++ /dev/null @@ -1,5 +0,0 @@ -# Dasharo Workstation - -## About - -**TBD**: _Define how this Dasharo segment meets workstation criteria, what that means for end user, what typically value prop this line of products offer_ diff --git a/fixme.txt b/fixme.txt index b0655ec1..f276b6dd 100644 --- a/fixme.txt +++ b/fixme.txt @@ -1,54 +1,33 @@ -docs/transparent-validation/muxpi/theory-of-operations.md:9 MD001/heading-increment/header-increment Heading levels should only increment by one level at a time [Expected: h3; Actual: h4] -docs/transparent-validation/muxpi/theory-of-operations.md:57 MD028/no-blanks-blockquote Blank line inside blockquote -docs/transparent-validation/muxpi/theory-of-operations.md:87 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:98 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:114 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:120 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:131 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:144 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:211 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:220 MD001/heading-increment/header-increment Heading levels should only increment by one level at a time [Expected: h3; Actual: h4] -docs/transparent-validation/muxpi/theory-of-operations.md:239 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:251 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:256:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 2; Style: 1/1/1] -docs/transparent-validation/muxpi/theory-of-operations.md:258 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:269 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:277:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 2; Style: 1/1/1] -docs/transparent-validation/muxpi/theory-of-operations.md:279 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:284:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 3; Style: 1/1/1] -docs/transparent-validation/muxpi/theory-of-operations.md:286 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:298 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:302:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 2; Style: 1/1/1] -docs/transparent-validation/muxpi/theory-of-operations.md:307 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:313 MD001/heading-increment/header-increment Heading levels should only increment by one level at a time [Expected: h3; Actual: h4] -docs/transparent-validation/muxpi/theory-of-operations.md:366 MD028/no-blanks-blockquote Blank line inside blockquote -docs/transparent-validation/muxpi/theory-of-operations.md:402:81 MD013/line-length Line length [Expected: 80; Actual: 263] -docs/transparent-validation/muxpi/theory-of-operations.md:448 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:454 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:460 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:473 MD001/heading-increment/header-increment Heading levels should only increment by one level at a time [Expected: h3; Actual: h4] -docs/transparent-validation/muxpi/theory-of-operations.md:521 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/theory-of-operations.md:555 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/value-prop/performance.md:3:81 MD013/line-length Line length [Expected: 80; Actual: 170] -docs/variants/asus_kgpe_d16/building-manual.md:62:81 MD013/line-length Line length [Expected: 80; Actual: 85] -docs/variants/asus_kgpe_d16/building-manual.md:63:81 MD013/line-length Line length [Expected: 80; Actual: 84] -docs/variants/clevo_nv41/ec_update.md:16 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/clevo_nv41/flashing_external.md:67 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/clevo_nv41/lvfs_report.md:1 MD002/first-heading-h1/first-header-h1 First heading should be a top-level heading [Expected: h1; Actual: h2] -docs/variants/clevo_nv41/lvfs_report.md:1 MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "## NovaCustom fwupd/LVFS suppo..."] -docs/variants/talos_2/hardware-matrix.md:8 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/ecosystem/overview.md:1 MD002/first-heading-h1/first-header-h1 First heading should be a top-level heading [Expected: h1; Actual: h2] -docs/ecosystem/overview.md:1 MD003/heading-style/header-style Heading style [Expected: atx; Actual: setext] -docs/ecosystem/overview.md:1 MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "Ecosystem Overview"] -docs/ecosystem/overview.md:21:81 MD013/line-length Line length [Expected: 80; Actual: 83] -docs/ecosystem/roadmap.md:6:81 MD013/line-length Line length [Expected: 80; Actual: 100] +docs/variants/clevo_nv41/openness_analysis.md:5:81 MD013/line-length Line length [Expected: 80; Actual: 131] docs/ecosystem/roadmap.md:13:81 MD013/line-length Line length [Expected: 80; Actual: 124] -docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md:35 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md:41 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md:45:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 12; Style: 1/1/1] -docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md:47 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md:57 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/asus_kgpe_d16/dasharo-security/tpm-support.md:112 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] +docs/variants/asus_kgpe_d16/setup.md:252:1 MD033/no-inline-html Inline HTML [Element: script] +docs/variants/clevo_nv41/releases.md:9:81 MD013/line-length Line length [Expected: 80; Actual: 149] +docs/variants/clevo_nv41/releases.md:42:81 MD013/line-length Line length [Expected: 80; Actual: 124] +docs/variants/clevo_nv41/releases.md:43:81 MD013/line-length Line length [Expected: 80; Actual: 114] +docs/variants/clevo_nv41/releases.md:44:81 MD013/line-length Line length [Expected: 80; Actual: 122] +docs/variants/clevo_nv41/releases.md:77:81 MD013/line-length Line length [Expected: 80; Actual: 124] +docs/variants/clevo_nv41/releases.md:78:81 MD013/line-length Line length [Expected: 80; Actual: 114] +docs/variants/clevo_nv41/releases.md:79:81 MD013/line-length Line length [Expected: 80; Actual: 122] +docs/variants/clevo_nv41/releases.md:114:81 MD013/line-length Line length [Expected: 80; Actual: 102] +docs/variants/clevo_nv41/releases.md:115:81 MD013/line-length Line length [Expected: 80; Actual: 106] +docs/variants/clevo_nv41/releases.md:116:81 MD013/line-length Line length [Expected: 80; Actual: 99] +docs/variants/clevo_nv41/releases.md:152:81 MD013/line-length Line length [Expected: 80; Actual: 101] +docs/variants/clevo_nv41/releases.md:153:81 MD013/line-length Line length [Expected: 80; Actual: 104] +docs/variants/clevo_nv41/releases.md:154:81 MD013/line-length Line length [Expected: 80; Actual: 108] +docs/variants/clevo_nv41/releases.md:183:81 MD013/line-length Line length [Expected: 80; Actual: 101] +docs/variants/clevo_nv41/releases.md:184:81 MD013/line-length Line length [Expected: 80; Actual: 104] +docs/variants/clevo_nv41/releases.md:185:81 MD013/line-length Line length [Expected: 80; Actual: 108] +docs/variants/clevo_nv41/releases.md:215:81 MD013/line-length Line length [Expected: 80; Actual: 101] +docs/variants/clevo_nv41/releases.md:216:81 MD013/line-length Line length [Expected: 80; Actual: 108] +docs/variants/clevo_nv41/releases.md:217:81 MD013/line-length Line length [Expected: 80; Actual: 112] +docs/variants/clevo_nv41/releases.md:253:81 MD013/line-length Line length [Expected: 80; Actual: 101] +docs/variants/clevo_nv41/releases.md:254:81 MD013/line-length Line length [Expected: 80; Actual: 104] +docs/variants/clevo_nv41/releases.md:255:81 MD013/line-length Line length [Expected: 80; Actual: 108] +docs/variants/clevo_nv41/releases.md:277:81 MD013/line-length Line length [Expected: 80; Actual: 272] +docs/variants/clevo_nv41/releases.md:279:81 MD013/line-length Line length [Expected: 80; Actual: 92] +docs/dev-proc/source-code-structure.md:8:81 MD013/line-length Line length [Expected: 80; Actual: 117] +docs/transparent-validation/sd-wire/specification.md:23:1 MD033/no-inline-html Inline HTML [Element: center] +docs/transparent-validation/sd-wire/specification.md:33:1 MD033/no-inline-html Inline HTML [Element: center] docs/variants/asus_kgpe_d16/releases.md:9:81 MD013/line-length Line length [Expected: 80; Actual: 150] docs/variants/asus_kgpe_d16/releases.md:32:81 MD013/line-length Line length [Expected: 80; Actual: 159] docs/variants/asus_kgpe_d16/releases.md:33:81 MD013/line-length Line length [Expected: 80; Actual: 132] @@ -80,143 +59,11 @@ docs/variants/asus_kgpe_d16/releases.md:102:81 MD013/line-length Line length [Ex docs/variants/asus_kgpe_d16/releases.md:123:81 MD013/line-length Line length [Expected: 80; Actual: 127] docs/variants/asus_kgpe_d16/releases.md:125:81 MD013/line-length Line length [Expected: 80; Actual: 141] docs/variants/asus_kgpe_d16/releases.md:127:81 MD013/line-length Line length [Expected: 80; Actual: 149] -docs/variants/clevo_nv41/post_install.md:13 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/clevo_nv41/post_install.md:21 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/trustworthy-computing.md:3:81 MD013/line-length Line length [Expected: 80; Actual: 89] -docs/variants/tuxedo_ibs15/releases.md:9:81 MD013/line-length Line length [Expected: 80; Actual: 145] -docs/transparent-validation/rte/introduction.md:47 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/transparent-validation/rte/introduction.md:51 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/value-prop/certification-program/overview.md:9:81 MD013/line-length Line length [Expected: 80; Actual: 114] -docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md:40 MD046/code-block-style Code block style [Expected: fenced; Actual: indented] -docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md:69 MD046/code-block-style Code block style [Expected: fenced; Actual: indented] -docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md:97 MD046/code-block-style Code block style [Expected: fenced; Actual: indented] -docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md:125 MD046/code-block-style Code block style [Expected: fenced; Actual: indented] -docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md:153 MD046/code-block-style Code block style [Expected: fenced; Actual: indented] -docs/variants/asus_kgpe_d16/dasharo-compatibility/coreboot-base-port.md:181 MD046/code-block-style Code block style [Expected: fenced; Actual: indented] -docs/variants/asus_kgpe_d16/setup.md:1 MD003/heading-style/header-style Heading style [Expected: atx; Actual: setext] -docs/variants/asus_kgpe_d16/setup.md:51 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/asus_kgpe_d16/setup.md:65 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/asus_kgpe_d16/setup.md:251:1 MD033/no-inline-html Inline HTML [Element: script] -docs/variants/clevo_nv41/releases.md:9:81 MD013/line-length Line length [Expected: 80; Actual: 149] -docs/variants/clevo_nv41/releases.md:42:81 MD013/line-length Line length [Expected: 80; Actual: 124] -docs/variants/clevo_nv41/releases.md:43:81 MD013/line-length Line length [Expected: 80; Actual: 114] -docs/variants/clevo_nv41/releases.md:44:81 MD013/line-length Line length [Expected: 80; Actual: 122] -docs/variants/clevo_nv41/releases.md:65:81 MD013/line-length Line length [Expected: 80; Actual: 92] -docs/variants/clevo_nv41/releases.md:76:81 MD013/line-length Line length [Expected: 80; Actual: 124] -docs/variants/clevo_nv41/releases.md:77:81 MD013/line-length Line length [Expected: 80; Actual: 114] -docs/variants/clevo_nv41/releases.md:78:81 MD013/line-length Line length [Expected: 80; Actual: 122] -docs/variants/clevo_nv41/releases.md:113:81 MD013/line-length Line length [Expected: 80; Actual: 102] -docs/variants/clevo_nv41/releases.md:114:81 MD013/line-length Line length [Expected: 80; Actual: 106] -docs/variants/clevo_nv41/releases.md:115:81 MD013/line-length Line length [Expected: 80; Actual: 99] -docs/variants/clevo_nv41/releases.md:151:81 MD013/line-length Line length [Expected: 80; Actual: 101] -docs/variants/clevo_nv41/releases.md:152:81 MD013/line-length Line length [Expected: 80; Actual: 104] -docs/variants/clevo_nv41/releases.md:153:81 MD013/line-length Line length [Expected: 80; Actual: 108] -docs/variants/clevo_nv41/releases.md:182:81 MD013/line-length Line length [Expected: 80; Actual: 101] -docs/variants/clevo_nv41/releases.md:183:81 MD013/line-length Line length [Expected: 80; Actual: 104] -docs/variants/clevo_nv41/releases.md:184:81 MD013/line-length Line length [Expected: 80; Actual: 108] -docs/variants/clevo_nv41/releases.md:214:81 MD013/line-length Line length [Expected: 80; Actual: 101] -docs/variants/clevo_nv41/releases.md:215:81 MD013/line-length Line length [Expected: 80; Actual: 108] -docs/variants/clevo_nv41/releases.md:216:81 MD013/line-length Line length [Expected: 80; Actual: 112] -docs/variants/clevo_nv41/releases.md:240:81 MD013/line-length Line length [Expected: 80; Actual: 100] -docs/variants/clevo_nv41/releases.md:251:81 MD013/line-length Line length [Expected: 80; Actual: 101] -docs/variants/clevo_nv41/releases.md:252:81 MD013/line-length Line length [Expected: 80; Actual: 104] -docs/variants/clevo_nv41/releases.md:253:81 MD013/line-length Line length [Expected: 80; Actual: 108] -docs/variants/clevo_nv41/releases.md:275:81 MD013/line-length Line length [Expected: 80; Actual: 272] -docs/variants/clevo_nv41/releases.md:277:81 MD013/line-length Line length [Expected: 80; Actual: 92] +docs/variants/dell_optiplex/initial-deployment.md:7:1 MD033/no-inline-html Inline HTML [Element: center] docs/variants/dell_optiplex/releases.md:9:81 MD013/line-length Line length [Expected: 80; Actual: 160] docs/variants/dell_optiplex/releases.md:59:81 MD013/line-length Line length [Expected: 80; Actual: 106] docs/variants/dell_optiplex/releases.md:59:1 MD042/no-empty-links No empty links [Context: "[Dell OptiPlex 7010/9010 Dasha..."] docs/variants/dell_optiplex/releases.md:61:1 MD042/no-empty-links No empty links [Context: "[All in one zip]()"] -docs/variants/tuxedo_ibs15/building.md:49 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/transparent-validation/rte/v1.1.0/specification.md:5:81 MD013/line-length Line length [Expected: 80; Actual: 98] -docs/transparent-validation/rte/v1.1.0/specification.md:6:81 MD013/line-length Line length [Expected: 80; Actual: 99] -docs/value-prop/overview.md:8:81 MD013/line-length Line length [Expected: 80; Actual: 110] -docs/value-prop/overview.md:13:81 MD013/line-length Line length [Expected: 80; Actual: 145] -docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md:32:1 MD029/ol-prefix Ordered list item prefix [Expected: 9; Actual: 8; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md:33:1 MD029/ol-prefix Ordered list item prefix [Expected: 10; Actual: 9; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md:34:1 MD029/ol-prefix Ordered list item prefix [Expected: 11; Actual: 10; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md:35:1 MD029/ol-prefix Ordered list item prefix [Expected: 12; Actual: 11; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md:36:1 MD029/ol-prefix Ordered list item prefix [Expected: 13; Actual: 12; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/network-boot.md:37:1 MD029/ol-prefix Ordered list item prefix [Expected: 14; Actual: 13; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/os.md:57:1 MD029/ol-prefix Ordered list item prefix [Expected: 7; Actual: 8; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/os.md:58:1 MD029/ol-prefix Ordered list item prefix [Expected: 8; Actual: 9; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/os.md:59:1 MD029/ol-prefix Ordered list item prefix [Expected: 9; Actual: 10; Style: 1/2/3] -docs/variants/asus_kgpe_d16/fan-control.md:24 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/asus_kgpe_d16/fan-control.md:39 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/talos_2/building-manual.md:22 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/talos_2/building-manual.md:31 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/talos_2/building-manual.md:47 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/tuxedo_ibs15/post_install.md:13 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/tuxedo_ibs15/post_install.md:21 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/workstation.md:5:81 MD013/line-length Line length [Expected: 80; Actual: 154] -docs/transparent-validation/muxpi/basic-validation.md:3:81 MD013/line-length Line length [Expected: 80; Actual: 136] -docs/transparent-validation/muxpi/basic-validation.md:21:81 MD013/line-length Line length [Expected: 80; Actual: 96] -docs/transparent-validation/muxpi/basic-validation.md:47 MD001/heading-increment/header-increment Heading levels should only increment by one level at a time [Expected: h3; Actual: h4] -docs/transparent-validation/muxpi/basic-validation.md:49 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:58 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:64 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:131 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:145 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:151 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:157 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:163:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 4; Style: 1/1/1] -docs/transparent-validation/muxpi/basic-validation.md:166:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 5; Style: 1/2/3] -docs/transparent-validation/muxpi/basic-validation.md:170:1 MD029/ol-prefix Ordered list item prefix [Expected: 2; Actual: 6; Style: 1/2/3] -docs/transparent-validation/muxpi/basic-validation.md:173:1 MD029/ol-prefix Ordered list item prefix [Expected: 3; Actual: 7; Style: 1/2/3] -docs/transparent-validation/muxpi/basic-validation.md:176:1 MD029/ol-prefix Ordered list item prefix [Expected: 4; Actual: 8; Style: 1/2/3] -docs/transparent-validation/muxpi/basic-validation.md:188 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/muxpi/basic-validation.md:233 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/transparent-validation/sd-wire/specification.md:1 MD002/first-heading-h1/first-header-h1 First heading should be a top-level heading [Expected: h1; Actual: h2] -docs/transparent-validation/sd-wire/specification.md:1 MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "## Hardware design"] -docs/transparent-validation/sd-wire/specification.md:9 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/transparent-validation/sd-wire/specification.md:23:1 MD033/no-inline-html Inline HTML [Element: center] -docs/transparent-validation/sd-wire/specification.md:33:1 MD033/no-inline-html Inline HTML [Element: center] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:30:1 MD029/ol-prefix Ordered list item prefix [Expected: 7; Actual: 8; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:31:1 MD029/ol-prefix Ordered list item prefix [Expected: 8; Actual: 9; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:32:1 MD029/ol-prefix Ordered list item prefix [Expected: 9; Actual: 10; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:33:1 MD029/ol-prefix Ordered list item prefix [Expected: 10; Actual: 11; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:65:1 MD029/ol-prefix Ordered list item prefix [Expected: 7; Actual: 8; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:66:1 MD029/ol-prefix Ordered list item prefix [Expected: 8; Actual: 9; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:67:1 MD029/ol-prefix Ordered list item prefix [Expected: 9; Actual: 10; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:68:1 MD029/ol-prefix Ordered list item prefix [Expected: 10; Actual: 11; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:69:1 MD029/ol-prefix Ordered list item prefix [Expected: 11; Actual: 12; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:70:1 MD029/ol-prefix Ordered list item prefix [Expected: 12; Actual: 13; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:72:81 MD013/line-length Line length [Expected: 80; Actual: 94] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:72:1 MD029/ol-prefix Ordered list item prefix [Expected: 13; Actual: 14; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:73:1 MD029/ol-prefix Ordered list item prefix [Expected: 14; Actual: 15; Style: 1/2/3] -docs/variants/asus_kgpe_d16/dasharo-compatibility/fan-control.md:74:1 MD029/ol-prefix Ordered list item prefix [Expected: 15; Actual: 16; Style: 1/2/3] -docs/variants/asus_kgpe_d16/tpm-mboot.md:48 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/asus_kgpe_d16/tpm-mboot.md:73 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/dell_optiplex/initial-deployment.md:7:1 MD033/no-inline-html Inline HTML [Element: center] -docs/variants/dell_optiplex/initial-deployment.md:141 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/variants/dell_optiplex/initial-deployment.md:234:81 MD013/line-length Line length [Expected: 80; Actual: 88] -README.md:43 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/dev-proc/smbios-rules.md:13:81 MD013/line-length Line length [Expected: 80; Actual: 98] -docs/dev-proc/smbios-rules.md:15 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/dev-proc/smbios-rules.md:21 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] -docs/dev-proc/smbios-rules.md:38:81 MD013/line-length Line length [Expected: 80; Actual: 98] -docs/dev-proc/smbios-rules.md:40 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/dev-proc/source-code-structure.md:8:81 MD013/line-length Line length [Expected: 80; Actual: 117] -docs/osf-trivia-list/deployment.md:11:81 MD013/line-length Line length [Expected: 80; Actual: 93] -docs/osf-trolling-list/trusted_computing.md:1 MD002/first-heading-h1/first-header-h1 First heading should be a top-level heading [Expected: h1; Actual: h2] -docs/osf-trolling-list/trusted_computing.md:1 MD003/heading-style/header-style Heading style [Expected: atx; Actual: setext] -docs/osf-trolling-list/trusted_computing.md:1 MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "`[OSFI002]` Trusted computing"] -docs/transparent-validation/sd-wire/getting-started.md:1 MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "SDWire is a small board with t..."] -docs/variants/clevo_nv41/fwupd_usage.md:25:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 2; Style: 1/1/1] -docs/variants/clevo_nv41/fwupd_usage.md:36:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 3; Style: 1/1/1] -docs/variants/clevo_nv41/fwupd_usage.md:45:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 4; Style: 1/1/1] -docs/variants/clevo_nv41/fwupd_usage.md:67 MD028/no-blanks-blockquote Blank line inside blockquote -docs/variants/clevo_nv41/fwupd_usage.md:82:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 2; Style: 1/1/1] -docs/variants/clevo_nv41/fwupd_usage.md:89:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 3; Style: 1/1/1] -docs/variants/clevo_nv41/fwupd_usage.md:106:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 2; Style: 1/1/1] -docs/variants/clevo_nv41/fwupd_usage.md:112:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 3; Style: 1/1/1] -docs/variants/clevo_nv41/fwupd_usage.md:125 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/variants/clevo_nv41/fwupd_usage.md:169:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 2; Style: 1/2/3] -docs/variants/clevo_nv41/fwupd_usage.md:171:1 MD029/ol-prefix Ordered list item prefix [Expected: 2; Actual: 3; Style: 1/2/3] -docs/variants/clevo_nv41/fwupd_usage.md:172:1 MD029/ol-prefix Ordered list item prefix [Expected: 3; Actual: 4; Style: 1/2/3] -docs/variants/clevo_nv41/fwupd_usage.md:188:1 MD029/ol-prefix Ordered list item prefix [Expected: 1; Actual: 5; Style: 1/1/1] -docs/variants/clevo_nv41/openness_analysis.md:5:81 MD013/line-length Line length [Expected: 80; Actual: 131] -docs/variants/clevo_nv41/openness_analysis.md:7 MD001/heading-increment/header-increment Heading levels should only increment by one level at a time [Expected: h2; Actual: h4] docs/variants/talos_2/releases.md:9:81 MD013/line-length Line length [Expected: 80; Actual: 171] docs/variants/talos_2/releases.md:34:81 MD013/line-length Line length [Expected: 80; Actual: 169] docs/variants/talos_2/releases.md:35:81 MD013/line-length Line length [Expected: 80; Actual: 139] @@ -230,58 +77,5 @@ docs/variants/talos_2/releases.md:44:81 MD013/line-length Line length [Expected: docs/variants/talos_2/releases.md:71:81 MD013/line-length Line length [Expected: 80; Actual: 112] docs/variants/talos_2/releases.md:75:81 MD013/line-length Line length [Expected: 80; Actual: 108] docs/variants/talos_2/releases.md:79:81 MD013/line-length Line length [Expected: 80; Actual: 90] -docs/osf-trolling-list/build_process.md:16:81 MD013/line-length Line length [Expected: 80; Actual: 83] -docs/osf-trolling-list/build_process.md:90:81 MD013/line-length Line length [Expected: 80; Actual: 84] -docs/osf-trolling-list/build_process.md:126:81 MD013/line-length Line length [Expected: 80; Actual: 120] -docs/transparent-validation/sd-wire/usage-validation.md:14 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:22 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:31 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:40 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:54 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:61 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:68 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:77 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:83 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:89 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:97 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:105 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:111 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:143 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:150 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:165 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:172 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:179 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:185 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:191 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:204 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:210 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:217 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:228 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:234 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:240 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:246 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:275 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:281 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:289 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:293:81 MD013/line-length Line length [Expected: 80; Actual: 107] -docs/transparent-validation/sd-wire/usage-validation.md:296 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/transparent-validation/sd-wire/usage-validation.md:306 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: " ```"] -docs/variants/clevo_nv41/building.md:49 MD049/emphasis-style Emphasis style should be consistent [Expected: underscore; Actual: asterisk] -docs/index.md:1:1 MD033/no-inline-html Inline HTML [Element: img] -docs/index.md:1 MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: " +

{{ lang.t("meta.comments") }}

+ + + + + +{% endblock %} diff --git a/requirements.txt b/requirements.txt new file mode 100644 index 00000000..93f85b49 --- /dev/null +++ b/requirements.txt @@ -0,0 +1,3 @@ +mkdocs +mkdocs-material +pre-commit