Skip to content

Commit

Permalink
docs: unify firmare-action name in README
Browse files Browse the repository at this point in the history
- consistently use form "firmware-action" across README.md
- also note a support for universal module

Signed-off-by: AtomicFS <[email protected]>
  • Loading branch information
AtomicFS committed Jan 13, 2025
1 parent 52d5cd8 commit c948e47
Showing 1 changed file with 8 additions and 7 deletions.
15 changes: 8 additions & 7 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,26 +5,27 @@
[![dagger](https://github.com/9elements/firmware-action/actions/workflows/docker-build-and-test.yml/badge.svg)](https://github.com/9elements/firmware-action/actions/workflows/docker-build-and-test.yml)
[![go test](https://github.com/9elements/firmware-action/actions/workflows/go-test.yml/badge.svg)](https://github.com/9elements/firmware-action/actions/workflows/go-test.yml)

Firmware-Action is a tool to simplify building firmware. Think of it as `Makefile` or `Taskfile` but specifically for firmware. The tool it-self is written entirely in [Golang](https://go.dev/).
Firmware-action is a tool to simplify building firmware. Think of it as `Makefile` or `Taskfile` but specifically for firmware. The tool it-self is written entirely in [Golang](https://go.dev/).

Motivation behind the creation is to unify building of firmware across development environments. The goal of firmware action is to run on your local machine but also in your CI/CD pipeline, with the same configuration producing the same output.
Motivation behind the creation is to unify building of firmware across development environments. The goal of firmware-action is to run on your local machine but also in your CI/CD pipeline, with the same configuration producing the same output.

There is also an independent python tool to prepare Docker containers to be used with Firmware-Action. These are hosted on GitHub and are freely available (no need to build any Docker containers yourself).
There is also an independent python tool to prepare Docker containers to be used with firmware-action. These are hosted on GitHub and are freely available (no need to build any Docker containers yourself).

There is also a GitHub action integration allowing you to use Firmware-Action in your GitHub CI/CD.
There is also a GitHub action integration allowing you to use firmware-action in your GitHub CI/CD.

At the moment Firmware-Action supports:
At the moment firmware-action has modules to build:
- [coreboot](https://coreboot.org/)
- [linux](https://www.kernel.org/)
- [tianocore / edk2](https://www.tianocore.org/)
- firmware stitching (populating IFD regions with binaries)
- [u-root](https://github.com/u-root/u-root)
- universal module (run arbitrary commands in arbitrary Docker container)

This list should expand in the future (see [issue 56](https://github.com/9elements/firmware-action/issues/56)).

Firmware-Action is using [dagger](https://docs.dagger.io/) under the hood, which makes it a rather versatile tool. When Firmware-Action is used, it automatically downloads user-specified Docker containers in which it will attempt to build the firmware.
Firmware-action is using [dagger](https://docs.dagger.io/) under the hood, which makes it a rather versatile tool. When firmware-action is used, it automatically downloads user-specified Docker containers in which it will attempt to build the firmware.

If your firmware consists of multiple components, such as `coreboot` with `linux` as the payload, you can simply define each as a module and define dependency between them. Each module is built separately, but can use the output of another module as input. In the `coreboot` + `linux` example, you can call Firmware-Action to build `coreboot` recursively, which will also build `linux` due to the dependency definition. This way, you can build complex stacks of firmware in a single call.
If your firmware consists of multiple components, such as `coreboot` with `linux` as the payload, you can simply define each as a module and define dependency between them. Each module is built separately, but can use the output of another module as input. In the `coreboot` + `linux` example, you can call firmware-action to build `coreboot` recursively, which will also build `linux` due to the dependency definition. This way, you can build complex stacks of firmware in a single call.

[Documentation is hosted in pages](https://9elements.github.io/firmware-action/).

Expand Down

0 comments on commit c948e47

Please sign in to comment.