Skip to content

initial commit for dasharo naming convention v2 #1154

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

initial commit for dasharo naming convention v2 #1154

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
10be62e
initial commit for dasharo naming convention v2
pietrushnic Sep 19, 2025
9e3ee05
docs/dasharo-naming-convention.md: introduce concept of rapid/assured…
pietrushnic Sep 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 41 additions & 41 deletions docs/dasharo-naming-convention.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,78 +1,78 @@
# Dasharo Product Naming Convention

Following documentation is results of [RFC](https://github.com/Dasharo/dasharo-issues/issues/762).
Following documentation is v2 of naming convention following results of
[RFC](https://github.com/Dasharo/dasharo-issues/issues/762).

## Synopsis

```plain
Dasharo (firmware_framework[+payload]) [customer_type] Package for
market_segment
Dasharo (framework[+payload]) [edition] [release] Package for [platform]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now we include Dasharo (framework[+payload]) this part only in SMBIOS, I wonder if we should include more. Possibly related to: #1154 (comment) if we needed to tell which update given platform would need.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SMBIOS has other ways of expressing things. There are also things like compliance profiles in UEFI, as well as OS features in variables, which we do not leverage, and I doubt there is anything like that in coreboot.

```

## Description

Dasharo's naming scheme is crafted to convey the essential details of each
firmware package. It includes the base firmware framework, an optional payload,
the targeted market segment, and the customer type. This structure assists in
identifying the most suitable package for specific technological needs, market
segments, and customer categories.
the target `platform`, and the `edition`. This structure helps identify the
most suitable package for `platform`-specific needs and customer categories.

Components of the naming scheme:

```plain
Dasharo (firmware_framework[+payload]) [customer_type] Package for
market_segment
```

- `firmware_framework`: Mandatory. Specifies the base firmware framework used
in the package. Available options:
- `framework`: Mandatory. Specifies the base firmware framework used in the
package. Available options:

+ `coreboot` - [Dasharo downstream](https://github.com/Dasharo/coreboot) of
[coreboot](https://coreboot.org) open source project.
+ `UEFI` - [Dasharo downstream](https://github.com/Dasharo/edk2) of
[Tianocore EDK II](https://github.com/tianocore/edk2) reference
implementation of the UEFI Specification.
+ `coreboot` - Dasharo downstream of coreboot open source project.
+ `UEFI` - Dasharo downstream of Tianocore EDK II reference implementation of
the UEFI Specification.
+ `Slim Bootloader` - upstream or downstream version of Slim Bootloader.

- `payload` (optional): Details the additional software loaded by the firmware.
Available options:
Available options:

+ `UEFI` - [Dasharo downstream](https://github.com/Dasharo/edk2) of
[Tianocore EDK II](https://github.com/tianocore/edk2) reference
implementation of the UEFI Specification.
+ `SeaBIOS` - upstream or downstream version of [SeaBIOS](https://www.seabios.org)
+ `Heads` - upstream or downstream version of [Heads](https://github.com/linuxboot/heads/)
+ `UEFI` - Dasharo downstream of EDK II.
+ `SeaBIOS` - upstream or downstream version of SeaBIOS.
+ `Heads` - upstream or downstream version of Heads.
+ `U-Boot` - upstream or downstream version of U-Boot.

The omission of this component implies no additional payload.

- `market_segment`: Indicates the target market segment for the package.
Possible segments:

```plain
Network Appliance/Embedded | Laptop | Desktop | Workstation | Server
```

- `customer_type`: Specifies whether the package is aimed at professional
retail customers or enterprise business customers. Options are:

```plain
Pro | Enterprise
```
- `platform`: Indicates the target platform for the package. Platform is
mandatory in public names. Platform name should follow [supported hardware
list](/variants/overview).
- `edition`: Community | Pro | Enterprise (edition codes: DCP, DPP, DEP)

- `release`: Rapid | Assured | LTS. Defines QA scope and support cadence. Codes
are for internal use in filenames; public names spell out the release tier.
+ `Rapid` - minimal regression only, scope depends on target hardware and
configuration, so that it can be 3 or 10 tests, it is very likely <=10% of
LTS,
+ `Assured` in between Rapid and LTS, adding to `Rapid` only tests which
validate areas of firmware that experience change,s e.g., USB
improvements/fixes leads to test USB, measured boot changes then only TPM and
measured boot,
+ `LTS` - full scope, typically once a year unless budget is available.

This naming convention aims to provide clarity and precision, facilitating ease
of understanding across Dasharo's firmware offerings.

## Examples

```plain
Dasharo (coreboot+Heads) Pro Package for Laptop
Dasharo (coreboot+Heads) Pro Rapid Package for Novacustom NV4x 12th Gen
```

A package aimed at professional retail customers with laptops, incorporating
coreboot with the Heads payload.

```plain
Dasharo (UEFI) Enterprise Package for Desktop
Dasharo (Slim Bootloader+UEFI) Pro Assured Package for Hardkernel ODROID-H4
```

A package that uses Slim Bootloader with UEFI payload on Hardkernel ODROID-H4.

```plain
Dasharo (UEFI) Enterprise LTS Package for MSI PRO Z690-A
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where the PC Engines releases with their characteristic versioning scheme would land in this convention?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It really depends on which release, one that the PET Team does:

Dasharo (coreboot+SeaBIOS) Pro LTS Package for PC Engines apu2/3/4/6

Copy link
Contributor

@philipanda philipanda Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should update the Overview pages then to make sure that every page shows the platform name in a visible place. It's not the case for PC Engines APU https://docs.dasharo.com/variants/pc_engines/overview/

Dasharo/dasharo-issues#1650

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get the problem. What is expectation, and how is it related to this discussion?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • platform: Indicates the target platform for the package. Platform is
    mandatory in public names. Platform name should follow supported hardware
    list    .

Oh, it says to look in variants/overview, not the overview of a given platform. The names are there then, so all's good.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be resolved?

```

A package for enterprise business customers for desktops, employing UEFI with
no additional payload specified.
A package for enterprise business customers for MSI PRO Z690-A, employing UEFI
as framework with no additional payload.
56 changes: 28 additions & 28 deletions docs/osf-trivia-list/dasharo.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -320,7 +320,7 @@ of the project documentation.

Dasharo Support coming in form of three following packages:

- Dasharo Community Support (DCP) - donation-driven development.
- Dasharo Community Package (DCP) - donation-driven development.
- Dasharo Support Package (DSP) - annual firmware support package.
- Dasharo Enterprise Package (DEP) - custom SLA, corporate, and open roadmap
alignment advisory.
Expand All @@ -330,8 +330,8 @@ initiative that leverages the expertise of community members and developers to
improve firmware solutions for a range of hardware models.

Platforms in scope of the program should comply with Dasharo quality criteria,
which we slowly gather in [Dasharo Certification
Program](#what-is-dasharo-certification-program).
which we slowly gather in [Dasharo Certified Firmware
Program](#what-is-dasharo-certified-firmware-program).

3mdeb supports and maintains DCP-approved firmware through Dasharo Support
Package (DSP) and Dasharo Enterprise Package (DEP). These packages offer
Expand Down Expand Up @@ -365,34 +365,34 @@ Certification Program providing certain quality criteria including test
results. We always trying to minimize delta, but sometimes it can be up to 5k
SLOC (or more I guess e.g. Talos II coreboot support).

## What is Dasharo Certification Program?

The Dasharo Certification Program (DCP) is a highly specialized certification
program that benchmarks open-source firmware ecosystem deliverables. The
program ensures that firmware is stable, secure, and dependable while aligning
with the Dasharo values. DCP encourages developers to create their version of
Dasharo or contribute to the Dasharo project or coreboot upstream, enabling
them to leverage the power of open-source development to create custom firmware
tailored to their specific needs based on years of Dasharo quality assurance
results. The program's rigorous certification process entails comprehensive
testing in the Dasharo Certification Lab, ensuring that the firmware binary
meets the strict standards established by the program. By aligning with the
Dasharo values, the certification program improves the overall posture of the
open-source firmware ecosystem, making it long-term maintainable, sustainable,
and trustworthy and providing specific service level agreements and warranties
to commercial customers and the community.

## What is DCP-approved firmware?

The Dasharo-certified firmware provides long-term maintenance over ten years
## What is Dasharo Certified Firmware Program?

The Dasharo Certified Firmware (DCF) Program is a highly specialized
certification program that benchmarks open-source firmware ecosystem
deliverables. The program ensures that firmware is stable, secure, and
dependable while aligning with the Dasharo values. DCF encourages developers to
create their version of Dasharo or contribute to the Dasharo project or
coreboot upstream, enabling them to leverage the power of open-source
development to create custom firmware tailored to their specific needs based on
years of Dasharo quality assurance results. The program's rigorous
certification process entails comprehensive testing in the Dasharo
Certification Lab, ensuring that the firmware binary meets the strict standards
established by the program. By aligning with the Dasharo values, the
certification program improves the overall posture of the open-source firmware
ecosystem, making it long-term maintainable, sustainable, and trustworthy and
providing specific service level agreements and warranties to commercial
customers and the community.

## What is DCF-approved firmware?

The Dasharo Certified Firmware provides long-term maintenance over ten years
after the CPU microarchitecture release, which means that OEM, ODM, hardware
vendors, and other companies can rely on the firmware for a long time without
worrying about end-of-life issues. Moreover, DCP-approved firmware vendors must
provide professional support channels to ensure that other business entities
can rely on those channels for long-term support regarding firmware and
software.
worrying about end-of-life issues. Moreover, DCF-approved vendors must provide
professional support channels to ensure that other business entities can rely
on those channels for long-term support regarding firmware and software.

The validation process for DCP firmware is transparent. Test results and bug
The validation process for DCF is transparent. Test results and bug
reports are always publicly available, allowing the community to continually
identify issues and improve the firmware. However, in case of a security
embargo, the results can be kept under a strict but well-defined policy,
Expand Down